Privacy by design in software engineering means building data protection into how a system is specified, coded, tested and run, instead of adding it after launch. Day to day, that means four things: collect only the fields a feature needs, delete data on a schedule, limit which people and services can read it, and block any release that breaks those rules.
What does privacy by design mean for a software engineering team?
For an engineering team, privacy by design means privacy is a set of requirements with tests. It sits alongside latency or uptime, not in a policy document nobody reads.
Ann Cavoukian developed the idea in the 1990s as seven foundational principles. The first two are "proactive not reactive" and "privacy as the default setting". Regulators have since turned the idea into law:
- EU: Article 25 GDPR requires controllers to build data protection principles into processing through technical and organisational measures, and to process only the personal data each specific purpose needs.
- UK: The ICO says you must build data protection in from the design stage and throughout the lifecycle, which runs all the way to decommissioning. The guidance was updated on 5 February 2026 for the Data (Use and Access) Act 2025.
- US (California): Under the CCPA, collecting, using, keeping and sharing personal information must be "reasonably necessary and proportionate" to the purpose.
- Standards: Since February 2023, ISO 31700 has set out privacy by design for consumer goods and services. It is guidance, not a standard you certify against.
The ICO also publishes privacy guidance for each stage of the product lifecycle, written for software engineers, QA testers and product managers. It's a good place for your team to start.
Which privacy principles translate into engineering decisions?
Nearly every GDPR Article 5 principle maps to a concrete design or pipeline decision.
| Principle | Engineering decision | How you prove it |
|---|---|---|
| Purpose limitation | Every personal field is tagged with the purpose it serves | Schema annotations, data catalog |
| Data minimisation | Store derived values (age band, country) instead of raw ones | Migration review, field-level justification |
| Accuracy | One master record per customer, with merge rules | Match and survivorship rules, data quality checks |
| Storage limitation | Retention period set per data class, enforced by jobs | Deletion job logs |
| Integrity and confidentiality | Least-privilege access, encryption, no production data in test | Access reviews, pipeline scan results |
| Accountability | Each release records which privacy checks ran | Release evidence |
How do you design data models that collect only what you need?
To collect only what you need, start from the feature's purpose and justify every personal field before it reaches a migration.
The European Data Protection Board's guidance lists data minimisation elements that work well as review questions. Can you avoid processing personal data entirely? Can you limit how much you collect? Can you limit who has access? Can you show each field is relevant and necessary? In practice:
- Write the purpose first. A ticket that adds a personal field says what the field is for and when it stops being needed.
- Store the least precise value that works. An age check needs "over 18", not a date of birth. Regional pricing needs a country, not a street address.
- Separate identity from behaviour. Keep identifiers in one place and event data under a pseudonymous key. The EDPB recommends pseudonymisation where identification is still needed.
- Tag fields in the schema. Give every column holding personal data a classification, an owner and a retention class, so tools can read them.
- Make defaults private. Optional sharing, marketing and analytics consent start switched off.
- Keep real data out of development. The ICO covers protecting personal information in development environments. Use synthetic or masked fixtures.
How do you build retention, deletion and data subject requests into the system?
Make retention and deletion features of the system with owners and tests, not manual jobs someone runs when a request arrives.
GDPR requires personal data to be kept in identifiable form for no longer than necessary. Rights requests under Articles 15 to 22 must be answered without undue delay and in any event within one month. Every record holding personal data should follow a defined lifecycle:
Lifecycle of one personal data record, from collection to erasure or anonymisation
To make that lifecycle real:
- Store retention as configuration. Each data class has a period and an action at the end (delete or anonymise). Scheduled jobs apply it and log what they did.
- Run one deletion service. It fans out to every store: primary databases, the warehouse, search indexes, caches, logs, vector stores and third-party processors. When a team adds a store, it registers that store with the service.
- Plan for backups. Decide whether backups expire on their own schedule or get a suppression list, so a restore doesn't bring deleted records back.
- Verify identity proportionately. California regulators say businesses must not demand information beyond what is necessary for consumers to exercise their rights. Match the request against data you already hold.
- Test deletion like any other feature. Create a test user, fill every store, delete the user and check that nothing is left.
How do you put privacy checks into the CI/CD pipeline and code review?
Put privacy checks where engineers already work: as automated checks that block the build, plus a required reviewer when a change touches personal data.
How a pull request is routed through privacy checks before release
Useful checks to automate:
- Migration linter: fails when a new personal-data column has no classification or retention tag.
- PII scanners: catch personal data written to logs, error trackers or test fixtures.
- Data contracts: fail the producer's build when a schema change would break consumers or expose a field. Our Data Governance & MDM practice builds these contracts and quality SLAs into CI.
- New-processor check: flags any analytics SDK or third-party API added to the dependency tree.
- Code-owner routing: sends changes to personal-data paths to a named reviewer.
The ICO's lifecycle guidance includes pre-release privacy checks. Automating them means they run on every release, not just at launch.
What changes when AI writes the code or an LLM feature touches personal data?
AI-written code needs the same privacy gates as human-written code. LLM features need extra controls on what data reaches the model and how long prompts are kept.
AI coding assistants produce plausible code fast, and with it plausible privacy mistakes. Watch for:
- logging whole request objects
-
SELECT *queries that pull more fields than needed - new analytics libraries
- fixtures copied from real data
Our rule: whether a person or an AI wrote the change, nothing ships without tests, security checks and a senior engineer's review. Our Security & DevSecOps practice builds those checks into the pipeline.
LLM features add a request path where personal data can leak:
Where permission checks, PII redaction and retention apply in one LLM request
Each step in that path does a specific job:
- Retrieval enforces the user's permissions when the query runs, so the model never sees documents the user couldn't open.
- Guardrails strip PII the model doesn't need before the prompt leaves your systems.
- Output checks make sure the answer stays grounded and shows its sources.
- Prompt and response logs are personal data too. They get a retention class, and the deletion service covers them and the vector index.
Our Generative AI Apps work builds these steps in from the start, along with evaluation sets that run on every prompt or model change.
Who owns privacy decisions: engineering, data governance or legal?
All three own part of it. Legal decides what the law requires, data governance decides who owns each dataset and who may use it, and engineering builds the controls and proves they work.
- Legal and the DPO interpret regulations, approve purposes and lawful bases, and sign off risk assessments.
- Data governance gives each critical dataset a named business owner and technical owner. It also maintains classification and lineage, and decides which data AI models and agents may use.
- Engineering turns those decisions into schema tags, retention jobs, access controls and pipeline gates, and keeps the evidence.
The common failure is handing policy over a wall. A policy engineers can't run as a check gets ignored the first time a deadline slips.
How do you produce privacy evidence an auditor or regulator can follow?
Produce evidence as a by-product of delivery: every control should leave a record that's generated automatically, not rebuilt from memory before an audit.
Enforcement shows why this matters. A Future of Privacy Forum analysis of more than 92 cases and rulings found Article 25 is often enforced together with the general principles and the Article 32 security requirements. Auditors look at what your systems actually do, not your policy.
Keep these records:
- A data inventory: a catalog of personal data fields with owner, purpose, classification and lineage.
- Risk assessments linked to the tickets and releases they cover.
- Release records showing which privacy checks ran, what they found and who approved.
- Retention and deletion logs, including completed rights requests and how long each took.
- Access reviews for production data and AI data sources.
Our Accessibility & Compliance engineers work with your legal team so every release leaves evidence an auditor can follow.
Conclusion
Privacy by design becomes engineering practice when each principle has a matching control:
- a justified, tagged field in the schema
- a retention job with logs
- a deletion service that reaches every store, including vector stores
- a pipeline gate that blocks bad changes
- a release record someone can audit
AI makes code cheaper to write, which makes those gates more important, not less. Start with one product area: tag its personal data, build retention and deletion end to end, add the pipeline checks, then expand.
If you want a team to build this alongside your engineers, starting with a paid pilot on one real outcome, talk to an engineering lead →
Frequently asked questions
Is privacy by design a legal requirement or a best practice?
In the EU and UK it's a legal requirement: Article 25 of the GDPR and UK GDPR require data protection by design and by default. In California, the CCPA requires processing to be "reasonably necessary and proportionate" to its purpose, which leads to many of the same engineering controls. ISO 31700 offers further guidance but isn't a standard you certify against.
What is the difference between privacy by design and privacy by default?
Privacy by design means building data protection into a system from the start and throughout its lifecycle. Privacy by default means the system's out-of-the-box settings process only the data needed for each purpose. For example, optional sharing and marketing consent start switched off.
How long do we have to respond to a GDPR data subject request?
Article 12 GDPR requires a response without undue delay and in any event within one month of receiving the request. That's why deletion and access should run through an automated service that reaches every data store, not a manual process.
Do deletion requests apply to LLM logs and vector databases?
If prompts, responses or embeddings contain or link to personal data, treat them as personal data stores. Give them a retention class and include them in your deletion service, so a rights request reaches them along with your primary databases.
Can AI coding assistants be used on systems that handle personal data?
Yes, if their output goes through the same gates as any other change: tests, security and PII scans, and a senior engineer's review. Also set rules on what code and data the assistant may see, and keep production data out of prompts and test fixtures.
This article first appeared on Calidad Infotech.
Top comments (0)