Data & Integrity

Data Protection & Privacy

Foundational

Privacy is mostly won or lost in the data tier. It depends on how you classify, store, encrypt, and access-control data at rest. This is the engineering side of the policy view (see Privacy & Data Protection (GDPR)). It covers the practical patterns that keep sensitive data safe where it actually lives.

Start by knowing what data you hold and how sensitive it is. Then match the protection to the sensitivity. Ordinary data, personal data, and special-category data (our biometric KYC material) each need a different level of encryption, access control, and care. The rule is least exposure: the fewest copies, the fewest readers, and the least precision that does the job.

The Finperiti audit found that biometric data was open to cross-tenant risk. This shows how a weak data tier can become a serious breach. Classification, encryption, tenant isolation, and tight access at the storage layer stop a bug elsewhere from turning into a regulatory disaster.

Classify and minimise

DoClassify data by sensitivity (public / internal / personal / special-category). Let the classification decide how it is stored and who can read it.
DoMinimise at the storage layer. Do not store sensitive fields you do not need, and do not keep them at higher precision than required.
DoIsolate tenants in the data model so one tenant's data is never reachable from another tenant's queries or keys.
ConsiderPseudonymising or tokenising direct identifiers. Keep the mapping separate and tightly controlled.
Do notCopy sensitive data into denormalised tables, caches, search indexes, or exports without giving it the same protection it has at source.
NeverCopy production personal, KYC, or biometric data into dev, test, or personal environments — use synthetic or masked data.

Protect at rest and in access

AlwaysEncrypt sensitive data at rest. Use transparent encryption for the database, and column or field encryption for special-category and high-value fields.
DoEnforce least-privilege access to data. Applications and people see only the data and columns they need for their role.
DoRedact or mask sensitive fields by default in anything secondary, such as logs, telemetry, support tools, and exports.
ConsiderKeeping the most sensitive data (biometrics) in its own store, with its own keys and access policy, to limit the damage from a breach.
Do notReturn more personal data than a caller needs. Shape each response to the consumer, not to the table.
NeverStore special-category data without a valid lawful basis, or in a way that lets it cross tenant boundaries.

Self-review checklist

AskHow sensitive is each field here, and does its protection match?
AskIs special-category data encrypted, tenant-isolated, and access-restricted at the storage layer?
AskHave I made any secondary copy (cache, index, export, non-prod) that loses the original protection?
AskDoes each caller get only the personal data it actually needs?

Why it matters: When a breach happens, what leaks is whatever the data tier failed to protect. For us that can include biometric, special-category data at the most serious end of GDPR. Classifying, minimising, encrypting, and isolating data at rest is the difference between a contained incident and a reportable disaster.