Skip to content
Platform capability

Data protection: masked fields, encrypted secrets, and GDPR by design

Updated 4 min read

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?
By field-level masking enforced in the API handlers. A caller whose role lacks the specific permission receives sensitive fields, such as personal contact details, in a masked form, whichever client or integration they use. Masking rather than blanking means consumers see an explicit mask, not an empty value they might misread as missing data.
Where is data hosted?
On Microsoft Azure in UK and EU regions, with managed SQL, encrypted storage, and secrets held in a key vault. Talk Think Do is ISO 27001 certified and Cyber Essentials Plus accredited, and the platform is designed around GDPR obligations.
How does sign-in work?
Sign-in supports a variety of methods and typically federates to your identity provider, most commonly Microsoft Entra ID or Google. Staff get seamless single sign-on, while MFA, conditional access, and joiner-leaver processes are enforced by the identity platform your organisation already governs.
See it live

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