Privacy by design and the GDPR

Privacy is a design property

Security and privacy overlap but are not the same. Security asks whether data is protected from people who should not have it. Privacy also asks whether the organisation itself should collect the data at all, what it may do with it, for how long, and what control the person it describes keeps. A system can be free of breaches and still invade privacy, for example by keeping every courier's location trail for ever or by quietly reusing order histories to train a pricing model.

The food-delivery platform is a good example of why privacy is architectural. It holds names, phone numbers and home addresses; order histories that can reveal religion or health through dietary choices; payment references; and a continuous stream of courier locations. These data flow from the apps through dozens of services, events, caches, logs, analytics stores and backups, and to processors such as the payment provider, the SMS gateway and the support-desk SaaS. Decisions about where personal data is stored, how it is keyed and how it can be found and removed are expensive to change later, which is exactly the test for architectural significance.

The law in brief: the GDPR and the UK GDPR

The General Data Protection Regulation, Regulation (EU) 2016/679, has applied since 25 May 2018. It protects personal data, which Article 4(1) defines as any information relating to an identified or identifiable natural person, directly or indirectly, for example by a name, an identification number, location data or an online identifier. The controller decides why and how data is processed and carries primary responsibility; a processor processes on the controller's behalf under a contract (Article 28), as the platform's SMS gateway does. The GDPR applies to organisations established in the EU and, under Article 3, to others that offer goods or services to, or monitor the behaviour of, people in the EU.

In the United Kingdom the GDPR was retained after Brexit as the UK GDPR, which operates alongside the Data Protection Act 2018. The Data (Use and Access) Act 2025 amended both; most of its data protection changes came into force on 5 February 2026, including changes to lawful bases, automated decision-making and international transfers, and a requirement for controllers to handle data protection complaints follows from 19 June 2026. The European Commission renewed its adequacy decisions for the UK in December 2025, so personal data can continue to flow from the EU to the UK without extra safeguards. For architects, the two regimes share the same principles, rights and design duties; the differences are matters of detail for lawyers.

Maximum fines for the most serious infringements are EUR 20 million or 4% of worldwide annual turnover under the GDPR (GBP 17.5 million or 4% under the UK GDPR), whichever is higher, though the more common consequences are orders to stop processing, reputational damage and the cost of re-engineering. In November 2025 the European Commission proposed amendments to the GDPR as part of a Digital Omnibus package; at the time of writing these are still going through the legislative process and change nothing yet.

Lawful bases, briefly

Article 6 permits processing only on one of six lawful bases: consent, performance of a contract with the person, a legal obligation, vital interests, a task in the public interest, or legitimate interests that are not overridden by the person's interests and rights. Special categories of data, such as health or religious belief, need an additional condition under Article 9. The basis is chosen per purpose, not per system, and it changes what the architecture must do. On the food-delivery platform, the delivery address is processed to perform the contract; invoices are kept to meet a legal obligation under tax law; fraud screening typically relies on legitimate interests; and marketing e-mails normally need consent, which electronic marketing rules also govern.

Consent has the strictest mechanics. Under Article 7 the controller must be able to demonstrate that consent was given, it must be specific to a purpose, and withdrawing it must be as easy as giving it. That means consent cannot be a single boolean column: the system needs an append-only record of what the person agreed to, when, through which channel and in response to which wording, and every consumer must honour a withdrawal promptly.

{
  "event": "ConsentGiven",
  "subjectRef": "cust_4411",
  "purpose": "marketing_email",
  "noticeVersion": "privacy-notice-2026-09",
  "wording": "Send me offers from restaurants near me",
  "channel": "ios-app 7.3.0",
  "method": "unticked checkbox, user ticked",
  "at": "2026-10-03T18:22:41Z"
}
{
  "event": "ConsentWithdrawn",
  "subjectRef": "cust_4411",
  "purpose": "marketing_email",
  "channel": "email unsubscribe link",
  "at": "2026-10-19T07:05:12Z"
}

Data protection by design and by default

Article 25 turns privacy by design into a legal duty. Article 25(1), data protection by design, requires the controller, both when deciding how to process and during processing, to implement appropriate technical and organisational measures, such as pseudonymisation, that put the principles into effect, taking into account the state of the art, the cost, the nature and purposes of processing and the risks. Article 25(2), by default, requires that only the data necessary for each specific purpose is processed by default, covering the amount collected, the extent of processing, the storage period and accessibility; in particular, data must not be made accessible to an unlimited number of people without the person's intervention. The European Data Protection Board's Guidelines 4/2019 on Article 25 give practical examples.

The law borrowed the idea from Ann Cavoukian, Information and Privacy Commissioner of Ontario, who developed privacy by design in the 1990s and published its seven foundational principles in 2009; the international conference of data protection commissioners endorsed them in 2010. They remain a useful design review checklist.

Rights that the architecture must support

Data subjects' rights are where privacy law most directly becomes system requirements. A controller must normally respond within one month of a request, extendable by up to two further months for complex or numerous requests (Article 12(3)), and must be able to find the person's data wherever it lives. In a system of twenty services, five SaaS processors and a data warehouse, that is impossible without a maintained data map: the record of processing activities that Article 30 already requires, kept close enough to the code to be accurate. Under the UK's 2025 amendments, a controller responding to an access request is required only to make reasonable and proportionate searches, which a good data map makes quick.

Data protection impact assessments

Article 35 requires a data protection impact assessment (DPIA) before processing that is likely to result in a high risk to people's rights and freedoms, in particular systematic and extensive profiling with significant effects, large-scale processing of special-category or criminal-offence data, and systematic monitoring of a publicly accessible area on a large scale. Supervisory authorities publish lists of further cases; continuous tracking of couriers' locations and algorithmic management of their work are typical candidates. A DPIA describes the processing and its purposes, assesses necessity and proportionality, assesses the risks to people, and records the measures that address them; if high risk remains, the controller must consult the supervisory authority before starting (Article 36).

Architects should treat a DPIA as the privacy counterpart of the threat model in Section 8.2, done at the same time and over the same data-flow diagram. The LINDDUN framework, developed at KU Leuven, does for privacy threats what STRIDE does for security threats, with categories such as linking, identifying, detecting, data disclosure and unawareness. The DPIA's conclusions become architectural requirements, such as location trails are deleted 30 days after the delivery, which can be tested.

International transfers and data residency

Chapter V of the GDPR restricts transfers of personal data to countries outside the European Economic Area. A transfer is lawful if the Commission has found the country adequate (Article 45), if appropriate safeguards such as the Commission's standard contractual clauses are in place (Article 46), or under narrow derogations (Article 49). After the Court of Justice invalidated the EU-US Privacy Shield in the Schrems II judgment of July 2020, transfers under contractual clauses need an assessment of the destination's laws; the EU-US Data Privacy Framework, found adequate in July 2023, covers transfers to US companies that certify under it, and survived a first challenge in the EU General Court in September 2025 (Latombe v Commission), although further litigation, including any appeal to the Court of Justice, could still change the position.

Two architectural points follow. First, a transfer is not only a database in another region: remote access by a support team abroad, a SaaS processor's sub-processors and a logging service hosted elsewhere all count, so the data map must record where data is stored and from where it is accessed. Second, data residency requirements, whether legal, contractual or chosen, are easiest to meet with regional deployment cells: each region holds its customers' personal data and keys, global services see only pseudonymous references, and replication across regions is explicit and reviewed. Retrofitting residency into a single global database is one of the most expensive changes a platform can face, which is why it belongs among the constraints captured early.

Minimisation, pseudonymisation and anonymisation

The cheapest personal data to protect is the data you never collect. Minimisation shows up in small decisions: an over-18 flag instead of a date of birth, a postcode district instead of a full address for analytics, a masked phone number relayed through the platform instead of revealing the customer's number to the courier, and location sampling only while a delivery is in progress.

Pseudonymisation (Article 4(5)) processes data so that it can no longer be attributed to a person without additional information, such as a key, that is kept separately and protected. A keyed hash (HMAC) of the customer ID, with the key held by the account team, lets the analytics team count orders per customer without seeing who the customers are. It is a valuable safeguard that Article 25 names explicitly, but Recital 26 is clear that pseudonymised data which could be attributed to a person by the use of additional information is still personal data. In EDPS v SRB (Case C-413/23 P, 4 September 2025) the Court of Justice added a nuance: whether data is personal is assessed from the perspective of whoever holds it, so pseudonymised data may not be personal data for a recipient that has no reasonable means of re-identifying anyone, although it remains personal data for the controller that holds the key, and the controller must still tell people about such recipients. The EDPB's Guidelines 01/2025 on pseudonymisation describe how to do it well.

Anonymisation goes further: the data no longer relates to an identifiable person, taking into account all the means reasonably likely to be used to identify someone, and the GDPR then no longer applies. True anonymisation is hard. Removing names is not enough when a combination of postcode, birth date and sex identifies most people, or when a single courier's location trail reveals where they live. Aggregation with small counts suppressed, generalisation and, for statistics, differential privacy are the usual techniques, and the result should be tested against realistic re-identification attempts.

Retention and erasure across every copy

Storage limitation needs a retention schedule: for each category of data, how long it is kept, why, and what happens at the end (deletion, anonymisation or archiving). Schedules only work when systems enforce them automatically: TTLs on cache and key-value entries, time-partitioned tables whose old partitions are dropped, object-storage lifecycle rules, log retention settings and scheduled jobs whose success is monitored.

Erasure is hardest in the places personal data leaks into. Caches and search indexes need explicit eviction and re-indexing, with TTLs as a backstop. Analytics stores should hold pseudonymous references so that rows can be found and deleted, or the data should be anonymised on the way in. Event logs and event-sourced stores are immutable by design; the usual technique is crypto-shredding, encrypting each person's fields with a per-person key and destroying the key, as described in Section 7.5, or keeping personal data out of events and storing only references. Application logs should not contain personal data that is not needed, which Section 8.8 returns to. Backups usually cannot be edited; the UK Information Commissioner's Office accepts that data may remain in backups until they are overwritten on an established schedule, provided it is put beyond use meanwhile and the person is told clearly what will happen, and if a backup is ever restored, erasures must be re-applied, which requires keeping the list of erased IDs. Finally, processors must be instructed to delete, since they act only on the controller's instructions (Article 28), and other recipients must be told (Article 19), so erasure must reach the SMS gateway, the support desk and the marketing platform through their APIs.