Privacy & Data Protection (GDPR)
Personal data is borrowed, not owned. We hold it on a specific lawful basis, for a specific purpose, for as long as that purpose lasts. The person it belongs to has rights over it the whole time, and can enforce them. Treat every field of personal data as something you may one day have to justify, show, or erase on request.
GDPR turns privacy into concrete engineering requirements: a lawful basis for every processing activity, data minimisation, purpose limitation, security, retention limits, and the ability to honour data-subject rights (access, rectification, erasure, portability, objection). These are not legal abstractions. They map directly to your schema, code paths, and logs.
We carry a heavier burden: KYC means we process special-category biometric data (Article 9), which needs a stronger lawful basis and stronger protection. The Finperiti audit found biometric data exposed to cross-tenant risk through a shared secret. This is exactly the kind of failure GDPR treats most seriously. Build privacy in by default and by design.
Collect and process lawfully
- AlwaysSet and record a lawful basis before processing personal data, and process it only for the purpose that basis covers.
- DoMinimise: collect and keep only the personal data you actually need, and no more. Every extra field is extra liability.
- DoApply data protection by design and by default. The privacy-protective setting is the one you ship with.
- DoGive special-category data (biometrics, health) stronger protection: a valid Article 9 basis, encryption, and tight access.
- ConsiderPseudonymising or tokenising personal data where the operation does not need the full identity.
- NeverProcess special-category data without a valid lawful basis, or expose it across tenant boundaries.
- NeverCopy production personal data, especially PII, KYC, or biometric data, into dev, test, or personal environments. Use synthetic or properly masked data.
Honour rights & limits
- DoBuild for data-subject rights: be able to find, export, correct, and (where lawful) erase a person's data without heroics.
- DoEnforce retention: personal data is deleted or anonymised when its purpose ends and no legal hold requires keeping it (see Data Retention & Erasure).
- DoTrack where personal data flows, including to processors and third parties, so you can answer where it is and who has it.
- ConsiderReconciling the right to erasure with AML retention obligations clearly. When the law requires keeping a record, record that exception rather than ignore it.
- Do notLog full PII or special-category data, or scatter copies into caches, exports, and screenshots you cannot account for later.
- NeverRetain personal data with no defined purpose or retention limit, "just in case".
log.Info($"KYC for {name}, DOB {dob}, doc {passportNumber}");
This writes special-category and identity data into logs that many people can read and that are kept for a long time. That is an ongoing GDPR breach. Log a customer id reference, never the personal data itself.
log.Info("KYC processed for customer {CustomerId}", customerId);
The operation can still be observed and audited. The personal data stays in the protected store, where access is controlled and retention is enforced.
Self-review checklist
- AskWhat is the lawful basis for collecting each piece of personal data here, and is special-category data treated more strictly?
- AskAm I collecting or keeping anything I do not actually need?
- AskIf this person asked for access or erasure, could we honour it and reconcile it with AML retention?
- AskCould personal data leak into logs, caches, exports, or a non-production environment?