The rules that reach into system design across every industry, and the difference between having a control, implementing it, and being able to evidence it.
10 published across 5 topics.
Regulation and compliance fundamentals58 short answers on one page, for revising rather than studying.Lawful basis, subject rights, consent, and where erasure collides with append-only design.
Treat the two obligations as different purposes over different columns rather than a fight over one table. Keep the narrow set you are compelled to retain in a restricted, purpose-locked store the product cannot read, delete everything else on schedule, and make your compliance function name the retained fields.
You delete from the operational store, propagate to every derived copy you can enumerate, and for the copies you cannot rewrite you rely on crypto-shredding, keyed compaction, snapshot expiry and exclusion at the next retrain.
Where data may live, cross-border transfer, and the architecture that follows.
Keep one small global directory holding only the keys needed to route a request, never the payload. Uniqueness becomes a claim on a pseudonymous token, search becomes a fan-out that returns pointers each region resolves locally, and every field promoted to the global tier is a transfer decision.
You pin every store to the region, including backups, DR, search indexes and key material, then hunt the paths that leave without anyone choosing to: telemetry labels, error traces, log shipping, support tooling and remote staff access.
Audit trails versus logs, tamper-evidence, retention, and what an auditor actually accepts.
Suspend deletion only for the scoped records, not everywhere, which means hold has to be a first-class state that overrides the retention schedule. The engineering work is scoping the hold, suppressing every deletion path including backup expiry, and paying down the deletion debt that accumulates once the hold lifts.
You need a purpose-built audit trail, not application logs: guaranteed-capture, append-only records of actor, subject identifier, action, server time, outcome and stated purpose, made tamper-evident by hash chaining and anchored write-only storage, and held where whoever can change the data cannot change its record.
Least privilege, privileged access, approval flows and toxic combinations.
Removing humans from production moves the privilege into the pipeline, so the boundary becomes who can change what it runs and which identity it assumes. Duties are separated by branch protection, environment approvals and deploying by digest, and it fails when one change alters both code and workflow.
Least privilege is a lifecycle problem rather than a grant: narrow entitlements, time-bound elevation instead of standing admin rights, and reviews that can revoke. Separation of duties exists to stop toxic combinations, where two individually reasonable permissions let one person both act and conceal it.
SOC 2, ISO 27001 and PCI DSS in engineering terms, and what certification does not mean.
You inherit only the part the provider performs, and their report names the controls it assumes you operate yourself. Your evidence is their report plus your record that you checked its scope, period and complementary user entity controls, and then evidence for the configuration that remains yours.
ISO 27001 certifies a management system against a fixed standard; SOC 2 is an attestation report whose scope you define and whose chosen controls a CPA firm opines on. Both separate the control from its implementation from the evidence, and only system-generated artefacts spanning the whole period count.