The General Data Protection Regulation (Regulation (EU) 2016/679) has been in force since 25 May 2018, and eight years on it is still the reference point most privacy laws are measured against. Developers often treat GDPR as a legal-and-policy concern, but several of its most consequential articles are engineering requirements in disguise. Data protection by design, security of processing, and the obligations you inherit when you rely on third-party components and sub-processors all end up expressed in architecture, configuration, and dependency choices. This guide translates the parts of GDPR that touch code into concrete build practices.
What GDPR is and who it binds
GDPR governs the processing of personal data — any information relating to an identified or identifiable natural person. It applies to controllers (who decide why and how data is processed) and processors (who process on a controller's behalf). Its reach is deliberately extraterritorial: under Article 3, it applies to organisations established in the EU and to those outside the EU that offer goods or services to, or monitor the behaviour of, people in the EU. If your software handles data about EU or EEA residents, you are almost certainly in scope regardless of where your servers or company are.
Enforcement sits with national data protection authorities, coordinated through the European Data Protection Board. Fines run up to EUR 20 million or 4% of total worldwide annual turnover, whichever is higher, for the most serious infringements.
The obligations that become code
Four articles do most of the work for developers:
- Article 25 — Data protection by design and by default. You must build technical and organisational measures into systems from the outset and default to the least data collection necessary. This is the article that makes privacy an architecture decision, not a bolt-on.
- Article 32 — Security of processing. You must implement appropriate security given the risk, and it explicitly names pseudonymisation and encryption, confidentiality/integrity/availability/resilience, restoration after incidents, and regular testing of effectiveness.
- Article 28 — Processors. Controllers may only use processors that provide sufficient guarantees, governed by a written contract, and processors may not engage sub-processors without authorisation. Every third-party API, hosting provider, and analytics SDK you embed is a sub-processing relationship you must be able to justify.
- Articles 33 and 34 — Breach notification. A personal-data breach must be notified to the supervisory authority within 72 hours of becoming aware of it where feasible, and to affected individuals when the risk to them is high.
Two more articles frame the program: Article 30 requires records of processing activities, and Article 35 requires a Data Protection Impact Assessment for high-risk processing.
The supply-chain and AppSec angle
The under-appreciated part of GDPR for developers is that Article 32's "appropriate security" and Article 25's "by design" both extend to the software supply chain. A vulnerable open-source dependency that leaks personal data is a security-of-processing failure just as surely as a misconfigured database. Regulators assessing whether your measures were "appropriate" will look at whether you knew what your software was built from and whether you managed known vulnerabilities in it. Likewise, every embedded component that transmits personal data to a third party is a processor or sub-processor relationship under Article 28, so an inventory of your dependencies doubles as an inventory of your data-sharing surface. Breach timelines make this concrete: to notify within 72 hours you need to know quickly whether a newly disclosed CVE affects a component that touches personal data, which is only possible if you already maintain that mapping.
Compliance checklist for engineering
| Practice | GDPR anchor | What it looks like in the build |
|---|---|---|
| Data minimisation defaults | Art 25 | Collect only required fields; short retention |
| Encryption and pseudonymisation | Art 32 | Encrypt in transit and at rest; tokenise identifiers |
| Dependency inventory | Art 32, Art 28 | Maintained SBOM tied to data-flow map |
| Vulnerability management | Art 32 | Continuous SCA with remediation SLAs |
| Sub-processor register | Art 28 | List every embedded third party and its DPA |
| Testing effectiveness | Art 32(1)(d) | Regular security testing evidence |
| Breach readiness | Art 33/34 | 72-hour runbook keyed to component-to-data mapping |
| Records of processing | Art 30 | Up-to-date ROPA |
How Safeguard helps
GDPR asks you to demonstrate that your security is appropriate and designed in, and both claims are far easier to defend with a live inventory than with an annual attestation. SBOM Studio maintains a component inventory for every application, which does double duty: it is the evidence base for Article 32's security-of-processing measures and a starting map for identifying which third-party components create Article 28 sub-processing relationships. Safeguard's SCA continuously checks those components against known vulnerabilities and ranks them by reachability, so "regular testing of the effectiveness" of your measures is a running process with time-stamped results rather than a point-in-time scan. When a new CVE lands, the same mapping tells you within minutes whether it touches a component in a system that processes personal data — the difference between a calm 72-hour breach assessment and a panicked one. Our compliance pages show how this evidence lines up against Article 32's specific expectations.
Frequently Asked Questions
Is using an open-source library a GDPR sub-processing relationship? Not by itself. A library running inside your own systems is part of your processing, not a separate processor. But an embedded SDK or API that transmits personal data to a third party's infrastructure typically creates a processor or sub-processor relationship under Article 28, which needs a data processing agreement and authorisation. The test is whether personal data leaves your control to another organisation.
Does GDPR require encryption? It does not mandate encryption in every case, but Article 32 explicitly names it as an example of an appropriate measure, and pseudonymisation alongside it. In practice, failing to encrypt personal data at rest or in transit is very hard to defend as "appropriate" for most modern systems, and several authorities treat its absence as an aggravating factor after a breach.
How does a vulnerable dependency become a GDPR problem? If an unpatched component is exploited to access personal data, you have both a security-of-processing failure under Article 32 and a notifiable breach under Article 33. Regulators assess whether your measures were appropriate, and unmanaged known vulnerabilities in software you shipped weigh heavily against you. Maintaining an SBOM and remediating known CVEs is the concrete defence.
What must happen within 72 hours of a breach? Where feasible, you must notify the competent supervisory authority within 72 hours of becoming aware of a personal-data breach, describing its nature, likely consequences, and the measures taken. If notification is delayed, you must explain why. Where the breach poses a high risk to individuals, you must also inform them without undue delay.
Building privacy in rather than bolting it on? See how our SCA engine evidences security of processing on the compliance pages, or read the setup guides in the Safeguard documentation.