Data protection: masked fields, encrypted secrets, and GDPR by design
Data protection is enforced where it cannot be bypassed. Sensitive fields are masked in the API for roles without the specific permission (masked, not blanked); payment details such as bank information live in dedicated encrypted fields; deletion is soft and traceable; hosting is on UK and EU Azure regions; and sign-in federates to your identity provider, typically Microsoft Entra ID or Google, so your MFA and access policies apply.
What does the capability do?
It treats personal data as a liability to be minimised, not a table to be queried, across every module.
- Field-level masking in the API. Roles without a specific permission receive sensitive fields masked by the handlers themselves, so no client, script, or integration can see what the role should not. Masked rather than blanked: consumers get an explicit mask, never an ambiguous empty value.
- Encryption where it counts. Sensitive payment data, such as a Direct Debit mandate’s bank details, is held in dedicated encrypted fields, and platform secrets live in a managed key vault rather than configuration files.
- Soft, traceable deletion. Records are marked deleted rather than destroyed, which keeps the audit trail intact and makes data-subject processes demonstrable rather than take-our-word-for-it.
- UK and EU hosting. The platform runs on Microsoft Azure in UK and EU regions, with managed SQL, storage, and monitoring, under an organisation that is ISO 27001 certified and Cyber Essentials Plus accredited.
- Federated identity. Staff sign in through your identity provider, typically Microsoft Entra ID or Google. Single sign-on is seamless for users, and MFA, conditional access, and leaver deprovisioning stay under the policies your organisation already enforces.
Why masking in the handler is the control that matters
Most products hide sensitive fields in the user interface, which protects exactly nothing from an export, an API call, or a curious integration. Enforcing masking in the API handlers makes the boundary real: the data never leaves the server for an unauthorised role, in any client, ever. And returning a mask rather than a blank keeps downstream consumers honest, because an explicitly masked value cannot be mistaken for data that was never captured.
Why it matters
Operators hold names, contact details, medical notes, and bank details for thousands of members, and often for children. GDPR obligations, insurer questionnaires, and enterprise due diligence all ask the same question: who can see what, and how do you know? API-enforced masking, encryption, soft deletion, certified hosting, and federated identity give the platform an answer that survives scrutiny. Read more in our approach to GDPR and ISO 27001.
Frequently asked questions
How is personal data protected from staff who do not need it?
Where is data hosted?
How does sign-in work?
More Platform capabilities
Audit and accountability: every change has a who, a when, and a why
How the platform records change: audit events on every entity, event-sourced financial history for charges, payments, refunds, and mandates, and flagged head-office interventions.
Roles and permissions: one model across every module
How the platform controls access: a module-and-action permission matrix enforced at the API, roles scoped from network to site, field-level masking, and federated sign-in.
Internationalisation: multi-language, multi-currency, by construction
How the platform handles international operation: translation catalogues with build-enforced parity, multi-currency amounts, per-jurisdiction tax, and UTC times displayed locally.
See this working in a demo
Book a consultation and we will demonstrate this capability on the Platform accelerator, against your own scenarios.
Book a demo