Security, privacy and reliability

1. Certifications

A cyber insurance policy is in place. The UK Information Commissioner’s Office (ICO) is our supervisory authority for data protection.

For transparency: Scoutworks has not yet undergone independent penetration testing. It is planned, and we welcome scoping input from groups and districts that would like to see it happen.

2. Where data lives

• Your group’s data is hosted in the EU (Amsterdam, the Netherlands) and processed under UK GDPR, with Scoutworks as your data processor and every sub-processor named in our privacy policy. Application, database and file storage run on Railway, a platform that is SOC 2 Type 2 audited and encrypts data at rest.
• All traffic passes through Cloudflare, which absorbs large-scale attacks and filters malicious requests before they reach the application.
• Backups of the database and uploaded files are taken automatically every day. File backups are held with a separate provider (Backblaze, Amsterdam).
• Transactional and group email is sent from the EU (Resend, Ireland). Product analytics run in the EU (PostHog, Frankfurt).
• Data is kept in the UK and EU wherever possible. The providers based in the United States — subscription billing (Stripe), engineering issue tracking (Linear), and the AI providers (Google Gemini, with xAI as the backup) — are covered by the UK International Data Transfer Addendum to the EU Standard Contractual Clauses.

3. Sub-processors

The complete list of third parties that process personal data on our behalf — what each is used for and where it holds data — is maintained in section 6.4 of the privacy policy, which is the single register we keep, so it is never out of step with this page. It is reviewed whenever a provider is added or removed.

4. Security practices

Encryption

• In transit — every connection uses TLS 1.2 or higher.
• At rest — AES-256 at the infrastructure level. Sensitive credentials held by the platform are additionally encrypted at the application level (AES-256-GCM).
• Passwords are never stored — only a one-way bcrypt hash. New passwords are screened against databases of known-breached passwords using a k-anonymity check, so the password itself never leaves our servers.
• Payment details are never held by Scoutworks. Direct Debit and instant bank payments are handled by GoCardless (FCA-authorised); subscription billing by Stripe (PCI-DSS Level 1). We store only provider reference identifiers.

Signing in

• Passkeys — sign in with Face ID, Touch ID, Windows Hello or a hardware security key. A passkey lives on the user’s device, so there is nothing to phish or reuse.
• Two-factor authentication — an authenticator app, an emailed code or a single-use backup code as the second factor. Group admins can require it for everyone in the group and choose whether trusted devices may be remembered for 30 days.
• Google and Microsoft sign-in, plus passwordless magic links by email.
• Sessions are short-lived — access tokens expire after 15 minutes and sessions time out after 30 minutes of inactivity. Authentication, payment and other sensitive endpoints are rate-limited.

Access control

• Each Scout group is an isolated tenant. Every database query is scoped to the group, and every request passes identity, group-membership, subscription, role and section-level checks in sequence.
• Role-based access — Group Admin, Leader, Young Leader or Parent — with section-level scoping, so leaders see only the members in their own sections. Parents have read-only access to their own children.
• Reversible suspension — a volunteer’s access can be suspended in one action, keeping their record and history intact, and reinstated later.
• Workflows that run from an email link, such as a parent completing a consent form, use cryptographically random, time-limited tokens stored only as one-way hashes.
• Sensitive fields are excluded from logs. Medical and dietary information is redacted from all system logs, alongside passwords, tokens and credentials.

How we build and run it

• Every code change is reviewed and must pass static analysis, type checks and automated tests before it can be merged.
• Dependency and secret scanning block merges. Every change is scanned against the OSV vulnerability database and for leaked credentials; findings at moderate severity or above, or verified secrets, prevent the merge. Independent nightly scans run outside the development cycle.
• Production deployments are deliberate. Changes go to a staging environment first; production is a separate, human-confirmed step that is blocked unless the checks have passed. Database changes are screened for destructive operations before they run.
• Continuous monitoring — structured logging, metrics and real-time alerting around the clock, behind zero-trust access controls.
• AI transparency — see section 5 for what the AI features are told, what they are never told, and how to run them on your own AI account.

The Security & Access feature page describes the sign-in and permissions features from a leader’s point of view, and the knowledge base has a plain-English guide to keeping your data safe.

5. Artificial intelligence

Scoutworks uses AI in five places: drafting a term programme in the programme planner, drafting, polishing and checking an email in the composer, suggesting hazards and control measures in the risk assessment wizard, suggesting entries for the trustee strategic risk register, and reading the shop, date and total from a receipt photo on an expense claim. Every one of them produces a draft, or filled-in fields, that a leader checks, edits, approves or discards. No AI feature publishes, sends or signs off anything on its own, and none of them runs in the background — a feature only ever runs because someone pressed a button.

• No member data is sent. No young person’s name, address, date of birth, medical condition, dietary need or contact detail reaches an AI provider. The features receive only the context of the job — the activity, the venue type, the age sections, meeting length, term dates and the badge requirements in your goal.
• Free text is scrubbed first. Names, email addresses and phone numbers are stripped from anything a leader types into a notes box before it is sent, so “Sam’s mum is a chef” arrives without the name.
• Our default provider is Google (Gemini), on Google’s paid API tier, with xAI (Grok) as the backup. Both are listed in the sub-processor table alongside every other company that processes data on our behalf.
• Or use your own AI account. A group admin can connect the group’s own OpenAI, Anthropic, Google or xAI key in Settings → Integrations, and every AI feature then runs on that account. The key is verified with a live test request before it is stored, encrypted at rest with AES-256-GCM under a separate application key, never returned to the browser, and displayed only as its last four characters.
• A failing key pauses AI; it does not reroute it. If your provider rejects the key, AI features stop and every group admin is notified. We do not quietly send your data to our own provider instead — your group asked for it to go to yours.
• No training on your data. Your group’s data is not used to train any model. Providers are used through their standard API, not under a training arrangement.
• Usage is visible and capped. Groups on the Scoutworks provider get a monthly allowance of successful generations; the current allowance, the amount used and the reset date are all shown in settings. Groups on their own key are not capped by us.

The AI Assistance feature page describes each feature from a leader’s point of view, and the knowledge base explains connecting your own AI provider.

6. Reliability

• Status page — live availability and incident history are published at uptime.scoutworks.app.
• Daily backups of the database and of uploaded files, taken automatically.
• Erasure with a safety net — when a group is deleted, its data enters a 30-day recovery window before an automated process removes it permanently.
• Cloudflare sits in front of all traffic, absorbing large-scale attacks before they reach the application.
• The platform is monitored around the clock with real-time alerting (see section 4).

How the service record is measured

The service record is calculated each day from our support desk and changelog, over the last 90 days.

• Support replies count every message to our support team except in-app bug reports. A message counts once a person has replied, or once it has waited longer than 2 working days without a reply. Automatic replies do not count as a reply. Working days are Monday to Friday, 9am to 5:30pm UK time, not counting bank holidays.
• Bug fix time runs from the moment a bug is reported in the app to the moment the fix is live for every group, not merely written. Reports we close as not a bug do not count.
• Improvements shipped counts the items in our weekly changelog.
• Messages from our own team and from test systems are left out. Nothing is removed because it makes a figure look worse.

Our service-availability commitments are set out in section 12 of the Terms of Service.

7. Accessibility

This website is designed to WCAG 2.1 level AA and publishes an accessibility statement listing what we have done, the issues we know about and how to report a problem. The Scoutworks application publishes its own statement inside the app.

8. Data protection

• Controller and processor. Each Scout group is the data controller for its members’ information; Seventeen Things Ltd is the data processor, acting only on the group’s instructions. See privacy policy section 2.
• Processing terms. Our commitments as processor — acting on instructions, confidentiality, assistance with data-subject requests, breach notification and deletion at the end of the contract — are in section 10 of the Terms of Service, read with the privacy policy. Together they form the data-processing agreement between your group and us.
• Young people’s data is handled under the additional safeguards in privacy policy section 4, including parental consent before a record is shared with another group.
• Retention. How long data is kept while a subscription is active, after it ends (90 days, then deletion) and for other records is set out in privacy policy section 8. Accident and incident records are kept for 20 years, in line with safeguarding good practice.
• Your rights and subject access requests. Groups can export their data at any time, and the app logs subject access requests and tracks the one-month deadline — see the guide to handling a subject access request. Rights are described in privacy policy section 9.

9. Responsible disclosure

If you believe you have found a security vulnerability in Scoutworks or this website, please tell us before telling anyone else. Our security contact is published in the standard place, /.well-known/security.txt (RFC 9116).

10. Request documents

Trustees and district teams doing supplier due diligence can ask us for our Security and Data Protection Overview (PDF), a copy of the current sub-processor register, or answers to a supplier questionnaire. Use the contact form and choose the privacy topic, or email [email protected].