Legal · security

Security Overview

How we protect the data your charity entrusts to us — written for trustees, managers and anyone reviewing us as a supplier.

Last updated

Who this is for

You are trusting us with some of the most sensitive information your charity holds: supporter records, donation histories, and in many cases details of the people you support. This page explains, in plain English, how we protect it.

It is written for trustees, charity managers and anyone completing a supplier review or due-diligence questionnaire on our behalf. It is organised around the 14 cloud security principles published by the UK’s National Cyber Security Centre (NCSC), which is the framework most UK public-sector and charity buyers use to assess a cloud supplier. There is a quick-reference table at the end mapping each principle to the section that covers it.

This page describes what we do and why. It deliberately does not describe the internal workings of our systems in the kind of detail that would help somebody attack them. If you are conducting a formal assessment and need more depth than this page provides, contact us — we would rather answer a specific question properly than publish a blueprint.

Two organisations, one service

ThirdSectorBee runs on Amazon Web Services (AWS). That means the security of the service comes from two places, and it is worth being clear about which is which:

  • AWS is responsible for the security of the cloud — the data centres, the physical machines, the networking hardware, and the staff who have physical access to any of it. AWS holds independent certifications for this, including ISO 27001 and SOC 2, and is audited against them by third parties. We inherit those controls; we cannot weaken them, and neither can anyone attacking us.
  • We are responsible for the security in the cloud — how the platform is built, how your data is separated from other charities’, who can sign in, what they can see, and how we detect and respond to problems.

Everything below distinguishes the two where it matters.

Where your data lives

Your charity’s data is stored in the United Kingdom, in AWS’s London region.

We chose this deliberately rather than defaulting to a cheaper or more convenient location elsewhere. For UK charities — particularly those handling data about beneficiaries — keeping personal data in the UK removes a whole class of question about international transfers.

A small number of our suppliers process limited personal data outside the UK. Which ones, for what purpose, and under what legal safeguard, are set out in our Data Processing Agreement.

Keeping your charity’s data separate from everyone else’s

NCSC principle 3 — separation between customers

This is the question we are asked most often, and it is the one we have invested in most heavily.

Many multi-tenant platforms keep every customer’s records in one big shared database and rely on the software remembering to filter by customer on every single query. One forgotten filter, anywhere, exposes everybody.

We do not do that. Each customer’s records live in their own dedicated database tables, created when your workspace is set up and used by nobody else. A query that failed to identify the right charity would not return another charity’s data, because that data is not in the table being queried. The separation is structural rather than a rule the software has to remember.

On top of that:

  • Every request to the platform is checked twice — once to confirm the sign-in is genuine, and again to confirm that the person making the request actually belongs to the charity whose data they are asking for.
  • That second check is backed by automated tests that deliberately try to break it. Such a test simulates a request for a charity the caller does not belong to, and proves that the system performs no database read, no write and no onward action — not merely that it returns an error. Every newly built operation that touches charity data is required to carry one, and the requirement is a ratchet: it only ever widens. Parts of the platform built before we introduced the requirement are being brought under it steadily, and an operation cannot leave the list once it is on it.
  • Attempts to reach a charity the user is not a member of are recorded and raise an alert to us, so a pattern of probing is visible rather than silently returning “access denied” and leaving no trace.

Protecting data in transit and at rest

NCSC principles 1 and 2 — data in transit protection, asset protection and resilience

In transit. Every connection to ThirdSectorBee is encrypted with TLS 1.2 or better. There is no unencrypted route into the platform; browsers are instructed to refuse to downgrade. Traffic between the platform’s own internal components stays inside AWS’s London region and is encrypted there too. When you upload a file it goes straight to encrypted storage rather than passing through our application on the way.

Your browser is also given a strict policy that limits the app to loading code and sending data only to a short, named list of destinations. If the app were ever tampered with, that policy sharply limits where data could be sent.

At rest. All data stored by the platform is encrypted using AES-256, managed by AWS.

Resilience. The platform runs on AWS services that are spread across multiple physically separate data centres as standard, so the loss of any one of them does not take your data with it. Your data is under continuous point-in-time backup, which allows recovery to any moment within the recent past rather than to last night’s snapshot — the difference that matters if a problem is discovered part-way through a day’s work.

We also run an automated audit of our own storage every weekday, which fails loudly if it finds any data store that is not accounted for. Unknown assets holding personal data are a well-known way for organisations to lose track of what they hold, and we would rather be told about one at 4am than discover it in a year’s time.

Who can get in, and what they can do

NCSC principles 9 and 10 — secure user management, identity and authentication

Signing in. Accounts are individual to a person and require a verified email address. We support passkeys, and configure them so that using one always requires the person to confirm their identity on their device with a biometric or PIN. A passkey used this way is two factors at once — something you have and something you are — and it cannot be phished, because it will not work on a lookalike website. If your charity handles sensitive beneficiary information, we encourage you to move your team onto passkeys.

Sessions are short-lived and can be revoked centrally.

What people can do. ThirdSectorBee uses fine-grained permissions rather than a handful of fixed roles. Charities differ enormously in how they divide work — a two-person charity has one person doing everything, while a national one may have volunteers who should see only contact history, fundraisers who manage donations, and finance staff who handle Gift Aid. Fixed roles force every organisation into the same shape; individual permissions let you say exactly who can do exactly what.

Beyond what someone can do, you can also control what they can see. Sensitive parts of a contact record — address, contact details, consent records — can be restricted to named teams or individuals while leaving the person’s name visible, so they still appear in lists and searches without exposing the details.

Your administrators can invite, suspend, remove and archive users themselves, without waiting for us.

Automated access. If you connect another system to ThirdSectorBee using an API token, that token must carry an expiry date — we do not issue credentials without one. Personal API tokens have the shortest lifetime, chosen at creation from a fixed set of options measured in days; tokens issued to a connected application last no longer than that, so treat both kinds with correspondingly more care the more access they carry, and revoke them when the integration is retired.

Whatever its lifetime, a token can never be given a permission the person creating it does not already hold, so it cannot be used to quietly escalate access. Tokens are stored only as an irreversible cryptographic hash: we cannot retrieve one, which is why it is shown exactly once when created. A personal API token can be revoked from your workspace and stops working immediately. Revoking a connected application immediately invalidates every token it has issued — checked on every use, not just at issuance — so removing an integration cuts off its access at once rather than waiting out the token’s remaining lifetime.

Platform-administration privileges used by our own staff cannot be granted through your workspace, by you or by us acting through it.

How we build the platform

NCSC principles 5 and 7 — operational security, secure development

Every change is checked automatically before it can ship. Our build pipeline runs a large set of automated checks on every change: unit tests, end-to-end tests that drive the real application the way a user would, and a suite of bespoke checks that enforce our own security rules — including the cross-customer access tests described above.

Production is gated on a working test environment. Changes reach a staging environment first, and the automated end-to-end suite must pass there before the same change is allowed anywhere near live customer data.

The infrastructure is defined as code. The servers, databases and permissions that make up ThirdSectorBee are described in version-controlled files rather than configured by hand. Every change to them is reviewed and recorded, and there is no undocumented production setting that exists only because somebody once clicked a button.

Security is designed in, not bolted on. Significant architectural decisions are documented, including the reasoning and the trade-offs. Where a rule protects people rather than data — for example, that a contact recorded as a child can never hold marketing consent — we enforce it at every point where a record can be created or changed, including bulk imports, so that no single mistake can bypass it.

We commission security reviews of our own code, and track the findings through to resolution.

How we watch the platform

NCSC principles 5 and 13 — operational security, audit information and alerting

We monitor for reliability and for security, and they are not the same thing.

Alongside operational alarms, we run alerts specifically designed to tell us that somebody may be somewhere they should not be: repeated attempts to reach another charity’s data, unusual patterns of failed sign-ins, and changes to the AWS account itself. Access records are retained for a year — deliberately longer than the operational norm, because the gap between a security incident happening and anyone noticing is routinely measured in months, and a short retention window tends to have destroyed the evidence before anyone goes looking.

Those access records are kept to a minimum: who, when, from where, and what they asked for. We do not log the contents of your records into them.

What you can see. Within the platform, you can view the history of changes to key records, so you can see how a contact or organisation record reached its current state.

If something goes wrong. If there is a personal data breach affecting your data, we are contractually committed to telling you within 72 hours of becoming aware of it, with the detail you need to meet your own obligations to the Information Commissioner’s Office. Our access records exist in large part to make that notification accurate rather than vague. The full commitment is in the Data Processing Agreement.

Who we let near your data

NCSC principles 6, 8 and 12 — personnel security, supply chain security, secure service administration

Our suppliers. We use a small number of specialist suppliers — for hosting, payment processing, email delivery and similar. Our Data Processing Agreement sets out the terms that govern them and identifies those engaged when it was issued, together with what they do and where they process data. You can ask us for our current sub-processor list at any time, and we would encourage you to do that rather than rely on a published schedule if you are completing a formal review — suppliers change, and the list you request will be the current one.

We are contractually required to impose obligations on our suppliers at least as strict as those we owe you, we remain fully liable to you for what they do, and we will give you 30 days’ notice before adding or replacing one — with a right to object, and to exit if we cannot resolve your objection.

We monitor the third-party software components the platform is built from for known vulnerabilities, with updates reviewed and applied on a regular cycle, and we audit their licensing.

Our own people. Very few people can reach production systems. The platform is built so that routine deployment requires no person to hold long-lived credentials at all — the release process authenticates itself directly to AWS for the duration of a single deployment, so there is no standing password or access key on anybody’s laptop to be lost, phished or reused. Where a person does need to act on the live system directly, the tooling is deliberately restricted so that read-only operations cannot become destructive ones by accident.

Changes to the AWS account itself — including use of the most privileged account and any change to the audit trail — raise an immediate alert.

Our commitments on confidentiality, background checks where lawful, and security training are set out in the Data Processing Agreement.

How we are governed

NCSC principle 4 — governance framework

ThirdSectorBee Ltd is registered in England and Wales (company number 17359072). Our Data Protection Officer is Rich Bee, co-founder.

The documents that govern our relationship with you — the Privacy Policy, the Terms and Conditions and the Data Processing Agreement — set out our obligations as your data processor under UK GDPR, including your right to audit, our sub-processor obligations, and our breach-notification commitments.

Internally, our engineering standards are written down and, wherever possible, enforced by automation rather than by memory. A rule that only exists in a document gets forgotten; a rule that fails the build does not.

Using ThirdSectorBee safely — your part

NCSC principle 14 — secure use of the service

No platform can protect a charity from every risk on its own. Some of it is genuinely yours, and being straight with you about which parts is more useful than pretending otherwise.

What we do to make the safe path the easy one:

  • Protective rules are enforced by the platform rather than left to your vigilance — for example, consent restrictions on records marked as belonging to a child.
  • Features that could send data outside the platform start switched off. Our AI features default to sharing no supporter records at all; enabling anything beyond that is a deliberate, administrator-level decision.
  • API tokens must expire, and cannot exceed the permissions of the person creating them.
  • Error messages shown to your team never expose internal system details.

What we ask you to do:

  • Give people only the permissions they need. The permission model is fine-grained precisely so that a volunteer does not need to hold a fundraiser’s access.
  • Remove people promptly when they leave. Your administrators can do this immediately; we cannot know that a volunteer has moved on.
  • Encourage passkeys, particularly for administrators and anyone who can see beneficiary data.
  • Treat API tokens like passwords. Store them somewhere safe, give them the narrowest permissions that work, and revoke them when the integration is retired.
  • If you embed our forms on your website, remember that the embed key in the page source is visible to anyone who views it. It identifies the form; it is not a secret and should not be treated as one.
  • Keep your own devices and email secure. The most common way an account is compromised is not a flaw in the platform — it is a shared password or a compromised email account used to reset one.

The NCSC 14 principles: quick reference

If you are working through a due-diligence questionnaire structured around the NCSC principles, this maps each one to the section above.

# NCSC principle Covered in
1 Data in transit protection Protecting data in transit and at rest
2 Asset protection and resilience Protecting data in transit and at rest, Where your data lives
3 Separation between customers Keeping your charity’s data separate
4 Governance framework How we are governed
5 Operational security How we build the platform, How we watch the platform
6 Personnel security Who we let near your data
7 Secure development How we build the platform
8 Supply chain security Who we let near your data
9 Secure user management Who can get in, and what they can do
10 Identity and authentication Who can get in, and what they can do
11 External interface protection Protecting data in transit and at rest, How we build the platform
12 Secure service administration Who we let near your data
13 Audit information and alerting for customers How we watch the platform
14 Secure use of the service Using ThirdSectorBee safely — your part

Reporting a security concern

If you believe you have found a security vulnerability in ThirdSectorBee, please tell us at hello@thirdsectorbee.com with enough detail for us to reproduce it. We will acknowledge your report and keep you informed as we investigate.

Please give us a reasonable opportunity to fix an issue before disclosing it publicly. We will not pursue legal action against anyone who reports a genuine vulnerability in good faith, who does not access, modify or delete data belonging to others, and who does not degrade the service for our customers.

Security is never finished

We continue to invest in the security of the platform, and this page is reviewed and updated as that work lands. It describes the position as at the date at the top — not an aspiration.

If you are assessing ThirdSectorBee as a supplier and need detail this page does not cover, please get in touch at hello@thirdsectorbee.com.