GDPR in custom software: data minimisation by design
How data protection requirements shape the design of custom software, and the decisions that are cheap at the start and expensive later.
The short answer
Data protection by design and by default is a legal requirement, and in custom software it is mostly a set of decisions about the data model, the permissions and the lifecycle, made in the first weeks. Which fields exist at all, because a field that does not exist cannot be breached, exported, corrected or misused. Who can see each field, because role-level access to whole records is the usual default and rarely the right one. How long each record lives, because retention applied by a job is cheap and retention applied by hand never happens. What is logged, because logs are personal data too. And how data leaves, because export, correction and deletion are features that are small when designed in and enormous when retrofitted into a live system with relations, backups and integrations. None of this requires a lawyer in the standup. It requires asking, for every field and every screen, whether this data is necessary, who needs it, and when it goes away.
Decisions that are cheap early and expensive later
| Decision | Cheap at design | Expensive later |
|---|---|---|
| Which fields exist | Omit what is not needed | Removing a field used by reports and integrations |
| Field-level access | Roles see only what they need | Reworking every query and screen |
| Retention per data type | A rule and a scheduled job | Writing deletion across a mature schema |
| Deletion semantics | Soft delete, anonymisation or hard delete decided per entity | Discovering references break |
| Export | A structured export per person | Assembling from twelve tables under a deadline |
| Correction | Editable with an audit trail | Manual database work per request |
| Logging | Minimal personal detail; separate retention | Logs full of personal data with no policy |
| Pseudonymisation | Identifiers separated from behavioural data | Re-architecting |
| Third-party flows | Documented, minimal, with agreements | Discovering data went somewhere nobody recorded |
| Test data | Synthetic from the start | Production data in test environments, which is a breach |
Building it in
- Justify every field in the data model against a purpose; delete the rest from the design.
- Define access per field or per group, not per whole record, for anything sensitive.
- Attach retention to every entity and build the job that enforces it before launch.
- Decide deletion semantics per entity: hard delete, anonymise, or retain under a legal obligation.
- Build export and correction as ordinary features.
- Design logging deliberately: what is recorded, with what personal detail, kept for how long.
- Use synthetic test data; never copy production personal data into development.
- Document the data flows to third parties and put the agreements in place.
- Write the impact assessment where the processing warrants one, before building.
- Review the model whenever a new field or integration is proposed.
The rights machinery as features
An application that holds personal data will eventually receive requests: show me my data, correct this, delete me. Building those as features means a screen or an endpoint that assembles the data, a correction path with an audit trail, and a deletion routine that knows what to remove, what to anonymise and what to keep under a legal obligation, with the reasoning recorded. Built in, each is a modest piece of work. Requested for the first time on a live system without them, each is a week of careful database surgery under a one-month legal deadline.
What this means for you
In custom software, data protection is a design discipline: justify every field, restrict access at field level, attach retention and enforce it automatically, decide deletion semantics per entity, build export and correction as features, log deliberately, and never use production data in testing. These decisions cost minutes early and weeks later, and they are what the by design and by default obligation means in practice. This is general information rather than legal advice.
Frequently asked questions
What does privacy by design mean concretely in software?
Fewer fields, narrower access, shorter retention and built-in rights handling. Concretely: do not add a field because it might be useful; give each role only the data it needs rather than a full record; attach a retention rule to every data type; log access to sensitive records; and build export and deletion as ordinary features rather than as future work. Each of those is a design decision that costs minutes at the start.
Why is retrofitting so expensive?
Because deletion touches every table, every relation, every backup and every integration, and because a data model built without it usually has records whose removal breaks references. Export is similar: assembling a person's data from twelve tables and three third-party systems is straightforward if designed in and archaeological if not. A deletion feature can cost more than the original feature that collected the data.
How do we handle audit logs and deletion together?
They pull in opposite directions and the resolution is design. Keep audit logs of actions with minimal personal detail, reference records rather than copying them, and define a separate retention for the logs themselves with a documented justification. Where deletion is required, anonymise the referenced identity while keeping the action record if you have a legitimate reason to retain it. Decide this before the first log line is written.
Sources
- EUR-Lex: Regulation (EU) 2016/679, Article 25 (accessed 2026-09-14)
- European Data Protection Board: Guidelines 4/2019 on Data Protection by Design and by Default (accessed 2026-09-12)