Privacy policies tend to appear towards the end of a project.
Privacy shouldn’t.
By the time someone is writing the legal page, an application may already have databases full of personal information, production logs containing customer data, third-party integrations, analytics platforms and backups nobody has thought about deleting.
At that point, privacy is no longer a policy-writing exercise.
It’s an engineering problem.
Start by collecting less
One of the most effective ways of reducing the risk surrounding personal information is not collecting unnecessary information.
It’s remarkably easy for databases to accumulate fields simply because somebody thinks they might be useful later.
Date of birth. Home address. Telephone number. Location. Employer. Device identifiers.
Every additional field creates something else to secure, govern, export and eventually delete.
Before adding personal information to a schema, ask what feature actually requires it.
If there isn’t a good answer, don’t collect it.
The original Jublo privacy article recognised that personal information extends beyond someone’s name and can include identifiers, contact information, location information, cookies and IP addresses.
Know where the data goes
A modern application rarely consists of a single database.
Personal information can end up in:
- production databases;
- logs;
- search indexes;
- message queues;
- caches;
- analytics platforms;
- support systems;
- monitoring tools;
- warehouses;
- object storage;
- backups.
It can also leave your infrastructure entirely through third-party APIs.
A privacy-conscious architecture understands those flows.
If a customer requests deletion, deleting one row from the primary database may not be enough if their information has been replicated into five other systems.
Data mapping is therefore not merely a compliance exercise. It’s useful system documentation.
Encrypt sensitive information properly
Encryption is valuable, but it isn’t a magic privacy switch.
Information in transit should be protected using secure transport. Sensitive information at rest may require encryption depending upon the data and threat model.
But application-level encryption introduces another question:
Where are the keys?
If the encrypted value and the key required to decrypt it are effectively stored together with identical access controls, much of the benefit disappears.
Key management, access control and rotation need to be part of the design.
Passwords are different again.
Applications generally should not need to recover the user’s original password at all, which means passwords should be securely hashed rather than reversibly encrypted.
Be careful what you log
Logs are particularly good at quietly becoming a second database.
A developer troubleshooting a problem adds the incoming request body to a log statement. It fixes the immediate issue. Six months later the same log is still recording email addresses, authentication tokens or personal information in production.
Observability should help you understand an application without unnecessarily copying sensitive information into the monitoring platform.
That means redacting sensitive fields, avoiding credentials altogether and being deliberate about what enters logs.
The same applies to exception reporting.
An excellent stack trace accompanied by somebody’s access token is not excellent observability.
Access should reflect responsibility
Not every developer needs unrestricted production database access.
Not every support user needs to see every customer field.
And a compromised application account should not automatically provide access to the entire organisation’s dataset.
Role-based access controls and the principle of least privilege reduce both accidental and malicious exposure.
For particularly sensitive operations, an audit trail can be equally important: who accessed something, what they changed and when.
Think about deletion before you need it
Systems are often very good at creating data and surprisingly poor at removing it.
Retention therefore needs to be designed.
What happens when a customer account is deleted?
What happens to related records?
What happens to uploaded documents?
What happens to cached data?
How long do application logs remain?
What about backups?
In some systems, complete immediate deletion from immutable backups isn’t practical. That doesn’t mean the problem can be ignored; it means the backup and restoration process needs a defined approach.
Development data matters too
Production is not the only environment capable of leaking information.
Copying a production database onto a developer’s laptop because it makes debugging easier can undermine a large part of the security work done elsewhere.
Where practical, development and test environments should use synthetic, generated or appropriately anonymised information.
If production information genuinely is required for diagnosis, access should be deliberate, restricted and temporary.
Third parties become part of your architecture
Payment processors, analytics platforms, email providers, cloud services, error-reporting tools and AI APIs can all process information on behalf of an application.
Software teams should know what they are sending to those platforms.
Adding a convenient SDK shouldn’t accidentally mean sending entire user objects to somebody else’s infrastructure.
Privacy isn’t a document
The original Jublo article made a useful point: when someone provides an organisation with personal information, they are placing trust in that organisation.
A privacy policy explains what an organisation intends to do.
The software determines what it actually does.
Good privacy engineering brings those two things together.