A privacy policy can say: “We delete personal data when it is no longer required.” Your database can still contain seven years of old accounts.
A policy can say: “You can withdraw consent.” Your marketing platform can still be subscribed.
That is why privacy is increasingly an engineering problem.
What privacy engineering means
Privacy engineering puts privacy requirements into product architecture, data models, APIs, access controls, consent, retention, deletion, vendor integrations and monitoring.
Instead of asking after launch whether a feature is compliant, ask during design what personal data the feature creates and what happens to it through its entire lifecycle.
Turn privacy into acceptance criteria
For a new feature:
[ ] Purpose documented
[ ] Data fields documented
[ ] Applicable basis documented
[ ] Vendors identified
[ ] Consent path tested where relevant
[ ] Retention defined
[ ] Deletion path tested
[ ] Evidence generated
This is much cheaper than reconstructing the architecture after launch.
Make retention executable
Instead of only writing “delete after 12 months,” build fields and jobs that actually enforce the lifecycle. The exact model varies by product, but the principle is constant: a retention rule should produce an action.
Make consent event-driven
A purpose-specific consent record should be able to trigger downstream state changes.
Consent state
↓
Event
↓
Processors
↓
Verification
Make deletion a workflow
The hard part of erasure is not the delete query. It is the dependency graph:
Request
↓
Identity
↓
Data map
↓
Retention check
↓
Internal systems
↓
Processors
↓
Verification
↓
Evidence
Privacy debt behaves like technical debt
A product with purpose-aware data models, centralised identity, automated deletion, vendor mapping and evidence is cheaper to operate. A product built from exports, shared databases and undocumented SaaS dependencies gets more expensive every month.
The self-test
Take one feature scheduled for the next sprint. Can engineering answer where the data goes, why it is collected, how long it remains, how a user can exercise rights, and what happens when the purpose changes? If not, privacy is entering the product too late.
Where Privra fits
Privra connects privacy requirements to the infrastructure that executes them, providing a continuously updated view of what the environment actually does.