Software supply chain controls support four GDPR articles: 25 on data protection by design, 28 on processors and sub-processors, 32 on security of processing and 33 on breach notification. They are evidence of appropriate measures, not proof of compliance. This post maps each control to the article text so you can see the link.
Article 32: is patching a GDPR matter?
Article 32(1) lists measures a controller or processor should consider, including pseudonymisation and encryption, the ability to ensure ongoing confidentiality, integrity, availability and resilience of processing systems, the ability to restore availability and access to personal data in a timely manner, and a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures. Article 32(2) says the right level of security takes account of risks such as accidental or unlawful destruction, loss, alteration, unauthorised disclosure of or access to personal data.
The text does not mention vulnerabilities or dependencies by name. The link is by reasoning: if a flaw in a library lets someone reach personal data, then unpatched libraries are a risk to confidentiality and integrity, and a process for finding and fixing them is the kind of regular testing and evaluation the article describes. A dated inventory of components, matched to known flaws and fixed on a schedule, is the evidence.
Article 28: do your vendors count?
Article 28(2) says a processor may not engage another processor without the controller's prior specific or general written authorisation, and under general authorisation must tell the controller of planned additions or replacements so the controller can object. Article 28(3) requires the contract to bind the processor to, among other things, act on documented instructions, ensure confidentiality, take all measures required under Article 32, meet the conditions for engaging sub-processors, help with data subject requests and Articles 32 to 36, delete or return data at the end, and provide information needed to show compliance, including allowing audits.
Map that to supply chain practice:
- A register of sub-processors, with the date each was authorised, is the direct evidence for 28(2).
- Change monitoring for vendors, so you know when a vendor adds a sub-processor or changes where data is processed.
- Security evidence from vendors, since 28(3)(c) and (h) ask for Article 32 measures and information to show compliance.
Whether a given software library counts as a processor is a legal question. Usually an open source library running inside your own system is code you operate, while a hosted service that receives personal data is a processor. Confirm edge cases with counsel.
Article 25: where does build quality come in?
Article 25(1) requires appropriate technical and organisational measures, such as pseudonymisation, built into the processing itself, both when choosing the means of processing and during processing, taking into account the state of the art, cost, and risks. Article 25(2) requires that by default just the personal data needed for each purpose are processed, covering amount, extent, storage period and accessibility.
For supply chain, that means choosing dependencies and services with data minimisation in mind. Does a third party analytics library collect more than you need? Does a new SDK send data to a vendor you have not listed? Reviewing new dependencies for data flows before adoption is the control, and the pull request is the place to do it.
Article 33: how do supply chain records help in a breach?
Article 33(1) requires the controller to notify the supervisory authority not later than 72 hours after becoming aware of a breach, with reasons if later, unless the breach is unlikely to result in a risk to individuals. Article 33(2) requires a processor to notify the controller without undue delay after becoming aware.
If a compromised dependency or vendor is the cause, speed depends on whether you can answer what you run, where it is and who has the data. An up to date component inventory and a sub-processor register shorten that search from days to hours. Also check your contracts: a processor owes you notice without a fixed deadline, so agree a number of hours with each important vendor.
What does this not prove?
Controls do not equal compliance. GDPR covers lawful basis, rights, transfers and much else. And these articles tell you what to achieve, not which tool to buy. Safeguard's SBOM, vulnerability matching and compliance automation can help produce the inventory and evidence described above, and Safeguard does not certify GDPR compliance.
See how controls map to frameworks at /demos/framework-mapping.
What to do
- Generate and store an inventory of components for each system that handles personal data.
- Match it to known vulnerabilities on a schedule, and record fixes with dates.
- Build a sub-processor register with authorisation dates and processing locations.
- Add a data flow check to your process for adding any dependency or SDK.
- Agree breach notice hours with each critical vendor in the contract.
- Rehearse a 72 hour clock using a supply chain scenario.
- Review the mapping with your data protection officer or counsel.
Quick check
Does GDPR require an SBOM?
Not in the articles we read. An inventory of components is a practical way to evidence Article 32 and to respond within Article 33 timelines.
Is a processor's breach notice deadline 72 hours?
No. Article 33(2) says without undue delay. The 72 hours applies to the controller. Set a shorter figure in your contract.
Sources
- GDPR Article 32: Security of processing, fetched 18 October 2026
- GDPR Article 28: Processor, fetched 18 October 2026
- GDPR Article 25: Data protection by design and by default, fetched 18 October 2026
- GDPR Article 33: Notification of a personal data breach, fetched 18 October 2026
This is general information, not legal advice.
Last reviewed: 18 October 2026.
