Data protection¶
What has to be true about personal data before it crosses the boundary.
Identify personal data field by field¶
During discovery, every field in the data contract is marked for whether it is personal data under GDPR, in either direction — data you send us and data we publish to you. The contract table has a PII column for exactly this (Domain modelling has the template). "Probably fine" is not an answer; the marking drives the agreement below.
A data processing agreement precedes cutover¶
Where personal data crosses the boundary in either direction, a data processing agreement (DPA) must be signed before production cutover — not after, not "in parallel with go-live". Raise it with your legal contact during discovery, because legal turnaround is the long pole, not the engineering.
Sandbox and staging work can proceed against non-personal or synthetic test data while the DPA is in flight. What the DPA gates is production data, not the build.
Data minimisation is enforced by the field list¶
The published-field contract already limits what we send you to fields your system needs for its own function (Endpoints and contracts). That is data minimisation in practice: a field with no named consumer and stated purpose is not published, so personal data is not shipped "just in case". The same test applies inbound — we mirror what the integration needs, and the vendor-removal test keeps speculative fields out of the canonical model.
Deletion and the record's lifecycle¶
How a record's deletion propagates is part of the data contract (question 6 in Domain modelling): hard delete, soft delete, or archive, and how each side learns a record is gone. For personal data this is also a retention question — a deletion on the source side must not leave an orphaned copy in a mirror indefinitely.
Internal: the register of which integrations process personal data, and the signed DPAs, is maintained outside this repository by the data-protection owner. Link it here once the location is settled.