Building GDPR Compliant Software: Privacy by Design

GDPR compliant software answers three questions before it stores a single record: what lawful basis covers this field, how long do we keep it, and how does it get deleted. European regulators issued roughly EUR 1.2 billion in GDPR fines in the year to 28 January 2026, bringing the running total since 2018 to EUR 7.1 billion.

Here is the part that should change how you build: Article 83(2)(d) of the GDPR tells supervisory authorities to weigh "the degree of responsibility of the controller or processor taking into account technical and organisational measures implemented by them pursuant to Articles 25 and 32" when they set a fine. Your architecture is not just a compliance risk. It is a documented mitigating factor in the penalty calculation.

This guide walks through privacy by design at the level where it actually gets decided — schema, auth flow, scheduled jobs and integration contracts. If you are looking for the banner-and-policy layer instead, start with our guide to website cookie compliance.

Table of Contents

• What GDPR compliant software actually means
• The 2026 enforcement picture
• Step 1: Map the data before you design the schema
• Step 2: Put the lawful basis in the data model
• Step 3: Build consent that holds up
• Step 4: Retention and deletion as scheduled jobs
• Step 5: Minimisation, pseudonymisation and encryption
• Step 6: The auth flow that cost EUR 30 million
• Step 7: Ship data subject rights as product features
• Step 8: When your project needs a DPIA
• Step 9: Processors, sub-processors and transfers
• Retrofit versus privacy by design: what the difference costs
• A 12-point pre-launch privacy checklist
• Frequently Asked Questions

What GDPR compliant software actually means

GDPR compliant software is not a product category you can buy a badge for — there is no certificate. Article 25 puts the duty on the controller, and it does so in two parts that map onto two different engineering activities.

Article 25(1) requires appropriate technical and organisational measures "such as pseudonymisation, which are designed to implement data-protection principles, such as data minimisation, in an effective manner" — and it says you must do this "both at the time of the determination of the means for processing and at the time of the processing itself." In plain terms: at design time and for the whole life of the system.

Article 25(2) is stricter than most teams realise. It requires measures "for ensuring that, by default, only personal data which are necessary for each specific purpose of the processing are processed," and that obligation "applies to the amount of personal data collected, the extent of their processing, the period of their storage and their accessibility." It then adds a specific default: personal data must not be made accessible "without the individual's intervention to an indefinite number of natural persons."

Read as a spec, GDPR compliant software ships with four defaults already hard-coded:

If you sell software rather than operate it, you are usually a processor, not a controller. That does not get you out of Article 25 — your customers cannot comply if your product makes compliance impossible. A product with no retention setting, no export endpoint and no field-level access control forces every customer into a manual workaround, which is the opposite of GDPR compliant software.

The 2026 enforcement picture

The eighth annual DLA Piper GDPR fines and data breach survey, published in January 2026, is the clearest public dataset on where enforcement actually lands.

Two details in that table matter for anyone budgeting GDPR compliant software. First, average breach notifications crossed 400 per day for the first time since the GDPR applied — the baseline assumption is now that incidents get reported, not buried. Second, nine of the ten largest fines ever imposed went to big tech, which means the headline numbers tell you very little about your own exposure. The mid-size fines tell you much more, and we will get to several of them.

The two fine tiers in Article 83 are worth memorising because they split along a line engineers care about:

Weak encryption sits in the cheaper tier. Collecting data you had no basis to collect, or failing to honour a deletion request, sits in the expensive one. That is the opposite of how most backlogs are prioritised.

Step 1: Map the data before you design the schema

Every GDPR compliant software project that works starts with an inventory, and every one that stalls starts with a policy document. The inventory you need is not a legal register kept in a shared drive — it is an annotated description of your schema.

The practical method: enumerate every column that holds personal data, then complete each row with four facts.

Filling in that table is the hardest hour of most compliance projects, because it surfaces columns that serve no current purpose. That is the point. Article 5(1)(c) requires personal data to be "adequate, relevant and limited to what is necessary in relation to the purposes," and 5(1)(e) requires it kept "no longer than is necessary."

One strong recommendation: keep the inventory in the repository, not in a spreadsheet. A data-catalog.yml reviewed in the same pull request as the migration stays accurate. A separate document drifts out of date within two quarters, and an inaccurate inventory is worse than none — it becomes the document a regulator compares against reality.

Step 2: Put the lawful basis in the data model

In GDPR compliant software, consent is one of six lawful bases, not the default. Contract performance, legal obligation, vital interests, public task and legitimate interests cover most of what a business application does, and each one behaves differently in code.

This matters because consent comes with a withdrawal right attached. Tie a delivery address to consent and the user who withdraws breaks your fulfilment flow. Tie the same field to contract performance and it is both legally correct and operationally stable. Reserve consent for processing that sits outside the service itself: marketing messages, profiling, tracking, optional recordings, location history.

Legitimate interests is the basis teams reach for most and document least. The Dutch supervisory authority fined a credit reference agency EUR 2.7m in 2025 after concluding, per the DLA Piper survey, that the company "did not clearly show why processing certain personal data was strictly necessary — rather than just 'nice to have'" and could therefore not rely on legitimate interests. The regulator added that a very short retention period tailored to the processing could have been the key safeguard, but the company followed outdated industry guidelines instead.

"Nice to have" is a product decision that becomes a legal finding. If a field exists because someone thought it might be useful later, legitimate interests will not carry it.

The Italian regulator made the design-time point even more directly. In 2025 it fined Luka Inc. EUR 5m over its Replika chatbot, citing breaches of Articles 5.1(a), 6, 12, 13, 5.1(c), 24 and 25.1 — for failing to identify the legal basis for the processing carried out through the service and failing to provide an adequate privacy notice. It also found the company had implemented no age verification at registration or during use, despite stating that minors were excluded. Article 25(1) was not cited because the encryption was weak. It was cited because nobody decided what the lawful basis was before shipping.

Step 3: Build consent that holds up

Where consent is the basis, the GDPR requires it to be freely given, specific, informed and unambiguous — and withdrawal must be as easy as giving it. In interface terms that rules out three common patterns: one checkbox covering several purposes, a "reject" path buried two screens deeper than "accept," and marketing consent presented as a condition of completing a purchase.

Model consent as records, not as a boolean column:

Never delete a consent record on withdrawal — flag it. A regulator does not ask whether you had consent. It asks which wording, on which screen, for which purpose, on a given date. Only a versioned consent log answers that, and that log is also your defence against a complaint filed a year later.

Keep the withdrawal path symmetrical with the opt-in path. If users subscribed in two clicks inside the app, they should be able to unsubscribe in two clicks inside the app — not by emailing support.

Step 4: Retention and deletion as scheduled jobs

Storage limitation is where otherwise-solid GDPR compliant software fails, because deletion is the one requirement no setting can satisfy. Something has to run on a schedule.

A workable retention design has four parts: a retention value declared per table, a job that enforces it, an audit record of what the job deleted, and alignment between that schedule and every copy of the data.

Those copies are the hard part. Four of them get missed almost every time:

• Soft deletes. Setting deleted_at is not deletion; the data is still there and still queryable. Use soft delete as a short user-facing undo window, then trigger a real delete.
• Backups. A record you deleted in production lives on in backups. Backup retention has to be aligned with your deletion schedule, and rotation has to actually expire old snapshots.
• Logs and error trackers. Application logs, crash reports and message queues carry personal data in unstructured form. A logger that never writes an email address or an identifier is cheaper than any cleanup job you will write later.
• Analytics and the warehouse. ETL copies personal data into a second system. If a deletion request only hits the primary database, the warehouse is now non-compliant and nobody can see it.

Verification matters as much as the schedule when a third party holds the data. The Higher Regional Court of Dresden (case 4 U 940/24) held that a controller must exercise its deletion rights against its processor and obtain written confirmation that deletion happened; a processor's announcement that it intends to delete data in future is not an adequate substitute. In that case, the processor announced deletion twice and only confirmed it years later, after a breach had already been reported.

So "we asked them to delete it" is not a control. "We have written confirmation dated X" is.

Step 5: Minimisation, pseudonymisation and encryption

Article 32(1) names four measure families: "the pseudonymisation and encryption of personal data"; the ability to ensure ongoing confidentiality, integrity, availability and resilience; the ability to restore availability and access after an incident; and "a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures."

That last one is a process requirement, not a tool requirement, and it is the one audits catch. A system hardened once in 2024 and never retested does not satisfy it.

The distinction worth getting right is pseudonymisation versus anonymisation. Pseudonymised data — identifiers swapped for tokens — is still personal data, because a mapping table reverses it. Anonymised data falls outside the GDPR entirely, but only if re-identification is genuinely impossible. Removing names and emails while keeping location, device, timestamps and browsing patterns does not clear that bar.

The pattern that works in practice:

• The operational database holds real values; the analytics schema holds age bands instead of birth dates, districts instead of addresses, months instead of exact timestamps.
• Development and test environments never receive a copy of production data. Use synthetic or masked datasets — this also removes a whole class of accidental-exposure incidents.
• Admin interfaces mask by default. Support staff rarely need a full identifier; the last four characters usually do the job.
• Encryption keys live in a managed key service with their own rotation policy, separate from the database credentials.

Step 6: The auth flow that cost EUR 30 million

In March 2025 the German federal supervisory authority fined Vodafone GmbH EUR 30 million for insufficient security measures on its online customer service portal. Per the EDPB's summary of the decision, investigators found weaknesses in the authentication process for customer accounts — used in combination with the company's hotline — that could lead to misuse of eSIMs. The authority opened the investigation after receiving external information, with no complaint and no notified breach.

Two things make that decision instructive for anyone building GDPR compliant software. The finding was about an account recovery path, not a database breach. And the regulator came looking without being prompted.

Two UK cases round out the picture of what "appropriate measures" means concretely. The ICO fined Capita around EUR 16m (GBP 14m) in October 2025 over a 2023 breach, finding, as the DLA Piper survey records, that the organisation had failed to prevent privilege escalation and unauthorised lateral movement, failed to respond appropriately to security alerts, and failed to implement adequate penetration testing and risk assessment. Earlier in 2025 the ICO fined an IT and software services provider around EUR 3.49m (GBP 3.07m) after attackers reached systems holding health data through a customer account that did not have multi-factor authentication.

Translate those findings into a backlog and you get a short, unglamorous list: enforce MFA on every account that can reach customer data including service and support accounts; segment networks so a single compromised credential cannot move sideways; route security alerts to someone with an on-call duty rather than a shared mailbox; schedule penetration tests on a calendar; and treat password reset, account recovery and phone-support identity checks as part of the authentication surface. Our website security guide covers the infrastructure side, and mobile app security the client side.

Step 7: Ship data subject rights as product features

Articles 15 to 22 give individuals the right to access, rectify, erase, restrict, port and object, plus rights around automated decision-making. Article 12(3) sets the clock: you respond "without undue delay and in any event within one month of receipt of the request."

One month is tight for a manual process and generous for an automated one, which is why GDPR compliant software treats these rights as endpoints rather than tickets. Four features cover almost all of it:

• Data export. An endpoint that returns a user's records in a structured, machine-readable format. This serves both access and portability.
• Account deletion. Not just "close my account," but a screen that states what will be deleted, what must be retained for legal reasons, and for how long.
• Deletion fan-out. An event that propagates erasure to the warehouse, the email platform, the CRM and every sub-processor. If your API integration layer can carry that event, the one-month deadline stops being a problem.
• A request ledger. Date received, content, response, date answered. This is your evidence, and under Article 19 you also have to tell recipients about rectification or erasure.

Automated decision-making deserves a specific note. If your software makes a decision about someone — credit, pricing, eligibility, ranking — with legal or similarly significant effect, Article 22 limits when you may do that solely automatically, and you need a human review path. Build the override before the model, not after the first complaint.

Step 8: When your project needs a DPIA

Article 35(1) requires a data protection impact assessment where processing, "in particular using new technologies," is "likely to result in a high risk to the rights and freedoms of natural persons" — and it must happen prior to the processing. Article 35(3) makes it mandatory for systematic and extensive automated evaluation with significant effects, large-scale processing of special categories or criminal-offence data, and systematic monitoring of a publicly accessible area on a large scale.

The working test comes from the WP29/EDPB guidelines WP 248 rev.01, which list nine criteria for likely-high-risk processing:

1. Evaluation or scoring, including profiling and predicting
2. Automated decision-making with legal or similar significant effect
3. Systematic monitoring
4. Sensitive data or data of a highly personal nature
5. Data processed on a large scale
6. Matching or combining datasets
7. Data concerning vulnerable data subjects
8. Innovative use or applying new technological or organisational solutions
9. Processing that in itself prevents data subjects from exercising a right or using a service

The guidelines state the rule of thumb plainly: "In most cases, a data controller can consider that a processing meeting two criteria would require a DPIA to be carried out," while noting that in some cases one criterion is enough. Two criteria is a low bar. A recommendation engine for a consumer app hits evaluation or scoring, large-scale processing and probably innovative use — three, before you add anything else.

Practical sequencing for GDPR compliant software: run the DPIA at the end of discovery, while the architecture is still a diagram. A DPIA that concludes you need a different data model is cheap in week three and expensive in month nine.

Step 9: Processors, sub-processors and transfers

Modern software is a stack of other people's services: cloud, email delivery, error tracking, payments, chat, analytics. Each is a processor, and each needs a data processing agreement under Article 28 that binds it to your instructions, to confidentiality, to assisting with data subject requests and to notifying you of breaches without undue delay.

Signing the agreement is the easy half. Supervising it is where regulators now look. The same German decision that produced the EUR 30m portal fine also carried a separate EUR 15m fine for breaching Article 28(1) — for deficiencies in supervising and auditing processors, combined with weaknesses in the processors' own IT systems that created a risk of customer data being used for fraud.

Transfers outside the EEA remain the most expensive category. The Irish DPC fined a social media company EUR 530m in 2025 for infringing Article 46(1) by transferring personal data to a third country without ensuring and demonstrating an essentially equivalent level of protection. For most teams the practical requirements are narrower:

Adding a SaaS tool takes five minutes technically. It can take five weeks contractually. Put the question in your architecture review, not in the retrospective.

Retrofit versus privacy by design: what the difference costs

The gap between GDPR compliant software built that way from the start and compliance bolted on later is a gap in the kind of work involved. Up front it is analysis and schema design. Afterwards it is data migration, backfill and regression testing across a live system.

The costliest row is deletion fan-out, and it is the one that scales worst. Retrofit cost there grows with the number of integrations, because every target system needs its own deletion contract, test and verification. Privacy-by-design cost is a one-time event-bus decision.

Risk belongs in the same calculation. IBM's 2026 Cost of a Data Breach study puts the global average breach cost at USD 4.99 million, rising to USD 6 million for AI-enabled malicious breaches — now one in four of all malicious breaches, a 56% increase year on year. Set against that, a DPIA in discovery and a retention job in sprint two are rounding errors. If you are sizing a build, our website cost calculator gives you a baseline to put these line items against, and custom software development covers how we scope them.

A 12-point pre-launch privacy checklist

1. Every personal-data column appears in the inventory with a documented lawful basis.
2. Fields required for the service to function rely on contract or legal obligation, not consent.
3. Each consent purpose has its own option and its own record; one click never covers several purposes.
4. Consent records store text version, channel and timestamp; withdrawal is flagged, not deleted.
5. Every table has a retention value, and a scheduled job enforces it.
6. Deletion jobs write audit records, and those records are retained on their own schedule.
7. Backup retention is aligned with deletion; backups are access-restricted and tested for restore.
8. Logs carry no personal data, or carry it under an explicit retention policy.
9. Access control is data-driven, with masking on sensitive fields in admin interfaces.
10. Export and deletion work as product features, and deletion fans out to every integration.
11. MFA is enforced on all accounts that can reach customer data, including support and service accounts.
12. Every processor has a signed DPA, a documented transfer mechanism and a current sub-processor list.

Teams that treat GDPR compliant software as a release gate rather than a compliance project see the difference six months later: the second feature does not repeat the first feature's privacy work.

Frequently Asked Questions

Is there a GDPR certification for software?

Article 42 provides for approved certification mechanisms, and Article 25(3) says such a certification "may be used as an element to demonstrate compliance." But no certificate makes a product GDPR compliant software on its own, and none transfers responsibility — the duty stays with the controller, and a vendor claim of being GDPR certified is marketing unless it names an approved scheme and a certification body.

Who is responsible if I buy software rather than build it?

You are, as controller. Your vendor is a processor and is directly liable for its own obligations, but your Article 28 duty is to choose a processor that provides sufficient guarantees and to supervise it. A German regulator fined one company EUR 15m specifically for failing to supervise and audit its processors.

Does pseudonymised data still count as personal data?

Yes. Pseudonymisation is listed in Article 32(1)(a) as a security measure, not as a way out of the GDPR, because a mapping table makes re-identification possible. Only genuinely irreversible anonymisation takes data outside the regulation, and removing names while keeping location, device and timestamp data rarely achieves it.

How long can I keep personal data?

The GDPR sets no fixed period. Article 5(1)(e) requires that you keep data no longer than is necessary for the purposes, which means you set the period, document the reasoning and enforce it. Where other law imposes a minimum — accounting or tax records, for example — that minimum governs the subset of data it covers.

When is a DPIA mandatory?

Article 35(3) makes it mandatory for large-scale special-category processing, systematic and extensive automated evaluation with significant effects, and large-scale systematic monitoring of public areas. Beyond those, the EDPB guidelines treat processing that meets two of nine high-risk criteria as generally requiring a DPIA, and it must be completed before processing starts.

How quickly do I have to answer a data subject request?

Without undue delay and within one month of receiving the request, under Article 12(3). You may extend by two further months for complex or numerous requests, but you have to tell the person within the first month and explain why.

Can I use a US cloud provider?

Yes, with a valid transfer mechanism in place — an adequacy decision covering the provider, standard contractual clauses, or binding corporate rules — supported by technical safeguards such as encryption and restricted key access. The Irish DPC's EUR 530m fine in 2025 turned on a company failing to demonstrate that transferred data enjoyed essentially equivalent protection, which is the standard you need to be able to evidence.

GDPR compliant software is not a module you install. Five decisions — the data inventory, lawful basis per field, versioned consent records, retention with a job behind it, and deletion that fans out — either live inside your data model or they do not. When they do, compliance becomes a property of the system and each new feature inherits it. When they do not, every new module, integration and report repeats the same work from scratch.

If you want to know where your current system is exposed, or you are scoping a new build and want privacy by design in the architecture from sprint one, get in touch and we will review your data model and flows with you. This guide is an engineering roadmap, not legal advice — pair it with a data protection lawyer for the legal assessment.