GDPR Articles 25, 28 and 32: Software Evidence in Safeguard Compliance

Safeguard helps a controller or processor produce the software side of GDPR evidence: its compliance and GRC suite (GA) checks six GDPR requirements on every product scan, covering Articles 5(2), 25, 28, 30, 32 and 33, and tracks your evidence for the controls a scan cannot see. Third Party Risk Manager (GA) adds supplier software visibility for Article 28 diligence. Safeguard does not make you GDPR compliant, does not decide your lawful basis or judge a DPIA, and does not notify a supervisory authority for you.

This post is for the DPO, privacy engineer or security lead at a processor selling into the EU who keeps hearing one request: show us that the systems processing personal data are secure, inventoried and supplier controlled. It covers what the GDPR and the European Data Protection Board (EDPB) say, the Safeguard flow step by step, and what stays with you.

Key takeaways

• Article 32 asks controllers and processors for security appropriate to the risk, including the ongoing integrity and resilience of processing systems. Article 28 lets a controller use only processors that provide sufficient guarantees, and the EDPB says that duty continues for the life of the contract.
• The Compliance and GRC suite (GA) includes a GDPR framework with six scan requirements, all decided by a scan, plus catalogue controls you evidence yourself with uploaded evidence, policies, linked tests or an attestation.
• A separate GDPR Article 25 framework (GA, same suite) adds scan requirements and controls for privacy by design and by default.
• Scans run on SBOM generation and analysis (GA) and software composition analysis (SCA) with vulnerability management (GA), so every check is tied to a dated inventory.
• Third Party Risk Manager, or TPRM (GA), requests and monitors SBOMs from processors and suppliers. It does not replace a data processing agreement.
• Lion, called Lino in the docs, maps evidence and drafts summaries (GA). Approvals stay with people; the assistant and MCP clients never accept or approve.
• The Trust Center (GA) is a way to share material with customers, not proof of compliance. A readiness score is not an audit opinion or a certification.

What the GDPR asks of the software behind processing

Below are the articles that touch software and suppliers, read through the EDPB's own guidelines. The official text is the Regulation (EU) 2016/679 on EUR-Lex; read it alongside this post.

Article 5(2): accountability

Article 5(1) sets the processing principles: lawfulness, fairness and transparency, purpose limitation, data minimisation, accuracy, storage limitation, and integrity and confidentiality. Article 5(2) adds the accountability principle: the controller is responsible for compliance with those principles and must be able to demonstrate it.

The EDPB ties this principle to records: its breach guidelines link the duty to document every breach, notifiable or not, to Article 5(2), and encourage an internal breach register. For software teams the key word is "demonstrate". A measure you cannot show is one you will struggle to defend.

Article 25: data protection by design and by default

Article 25(1) asks the controller to build in appropriate technical and organisational measures, such as pseudonymisation, both when it decides the means of processing and during the processing itself. Article 25(2) asks that, by default, only the personal data necessary for each purpose is processed.

The EDPB's Guidelines 4/2019 make three points that matter for software. The "time of determination of the means" includes procuring and implementing data processing software and services, so choosing a library or SaaS component is an Article 25 decision. The obligation continues after launch, including for legacy systems. And the state of the art is, in the EDPB's words, a "dynamic concept": a measure that once gave adequate protection may stop doing so. Article 25 addresses controllers, but the EDPB says they remain responsible for data protection by design in what their processors do.

Article 28: processors and sub-processors

Article 28 is the supplier article. Its main requirements, as the EDPB's Guidelines 07/2020 on controller and processor describe them:

• Article 28(1). A controller may use only processors "providing sufficient guarantees" to implement appropriate measures. The EDPB weighs expert knowledge, reliability, resources and reputation, and calls this a continuous obligation, verified at appropriate intervals, including through audits where appropriate.
• Article 28(2). A processor needs the controller's prior specific or general written authorisation to engage another processor, and under general authorisation must give the controller a chance to object to changes. The EDPB says the controller needs a list of intended sub-processors with their locations, tasks and safeguards.
• Article 28(3). The contract must cover set terms. Among them: confidentiality commitments for authorised staff; that the processor takes all measures required under Article 32, point (c); that it respects the sub-processor conditions, point (d); that it assists the controller with Articles 32 to 36, point (f); and that it makes available all information needed to demonstrate compliance and allows for audits, point (h).
• Article 28(4). The original processor stays fully liable to the controller for a sub-processor's performance.

On point (c), the EDPB says the contract should reference the actual security measures, require approval before changing them and provide for regular review. On point (h), the information flow can include how the systems function, security measures, data location, access and sub-processors. Read as a software engineer, that describes a dependency inventory with an owner, a change log and a supplier list.

Article 30: records of processing activities

Article 30(1) requires a controller to keep a record of its processing activities, and Article 30(2) requires a processor to keep a record of the categories of processing it carries out for each controller. The EDPB's guide for small businesses summarises the content of a controller's record: the purpose, the categories of data, the recipients, transfers outside the European Economic Area where applicable, the storage period where possible, and, where possible, a general description of the security measures. The record must be in writing, including electronic form, and available to the supervisory authority on request.

That last item is where software evidence lands. Article 30 does not ask for an SBOM, but a description of security measures is easier to keep honest when it points to an inventory regenerated on every build.

Article 32: security of processing

Article 32(1) asks controllers and processors to implement technical and organisational measures for a level of security appropriate to the risk, taking into account the state of the art, the costs, and the nature, scope, context and purposes of processing. It lists examples: pseudonymisation and encryption; the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services; the ability to restore availability and access to personal data in a timely manner after a physical or technical incident; and a process for regularly testing, assessing and evaluating the effectiveness of the measures. Article 32(2) asks you to weigh the risks of accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data.

The EDPB's breach guidelines quote points (b) and (c) and treat the ability to detect, address and report a breach in time as an essential element of Article 32 measures. Its Guidelines 01/2021, a casebook of breach examples, are blunter about software: discussing ransomware, the EDPB calls patch management that keeps systems current and fixes known vulnerabilities one of the most important measures, and recommends logs of which patches were applied and when. That is why a vulnerable component in a processing system is a GDPR matter, not only a security one.

Article 33: the 72 hour clock

Article 33(1) says that in the case of a personal data breach the controller shall notify the supervisory authority, in the words the EDPB quotes, "without undue delay and, where feasible, not later than 72 hours" after becoming aware of it, unless the breach is unlikely to result in a risk to people's rights and freedoms. A late notification must come with reasons for the delay. Article 33(2) requires a processor to notify its controller without undue delay. Article 33(4) allows information to be given in phases. Article 33(5) requires the controller to document every breach: the facts, its effects and the remedial action taken.

Per the EDPB, a controller becomes "aware" when it has a reasonable degree of certainty that an incident has compromised personal data; a short investigation is allowed but should start as soon as possible, and the risk assessment happens inside the 72 hours. Processors should notify controllers promptly, in phases. A published vulnerability in a library you use is not a breach. It becomes an Article 33 matter when you must work out, fast, whether it was exploited against systems holding personal data, and which systems those are. The second question is an inventory question.

Article 35: data protection impact assessments

Article 35 requires a DPIA where processing is likely to result in a high risk to people's rights and freedoms. The EDPB's small business guide says it should describe the processing and purpose, assess necessity and proportionality, and set out the risks and the measures to address them. Software evidence can inform the measures; it cannot make the judgement.

Why a software inventory is GDPR evidence

Each of those articles depends on knowing exactly which software performs the processing. You cannot patch under Article 32 what you have not inventoried. You cannot list sub-processors under Article 28 without knowing which hosted services your code calls. Article 30 wants a description of security measures, Article 33 wants a risk assessment inside about three days, Article 25 wants continued review against the state of the art, and Article 5(2) wants you to demonstrate all of it.

Without a current inventory, every answer is a reconstruction from build logs and memory. That fails during an incident, and it fails quietly during due diligence, when a customer's DPO receives an answer that was accurate six months ago. The EDPB's own recommendations, a register of every breach, logs of which patches were applied and when, regular review of processor security measures, are all easier when the inventory is a by-product of every build.

How Safeguard covers GDPR

Safeguard's Compliance and GRC suite (GA) organises compliance work into areas in the app: Overview, Frameworks, Controls, Evidence, Monitoring, Tests, Policies, Questionnaires, Risks, Vendors, Trust Center and Connectors. GDPR is one framework in a library of hundreds, which also includes national data protection laws across Europe.

According to Safeguard's docs, every framework is covered in up to four ways:

• Scan requirements. Requirements Safeguard checks on each scan of a product, against what the scan found, including the product's SBOM. They appear as controls on the framework's Controls tab.
• Catalogue controls. For many frameworks, Safeguard's control catalogue adds more of the framework's controls. You evidence these with automated tests, uploaded evidence, policies and attestations.
• Automated tests. Systems you connect run tests that map directly to SOC 2, ISO/IEC 27001, the HIPAA Security Rule, PCI DSS, NIST CSF 2.0 and the CIS benchmarks. For GDPR, the docs say no automated tests map to it directly, but you can link any automated test to its controls yourself.
• Policy templates. A standard set adapted to the framework, plus templates written for it.

For GDPR, the docs page says the framework is on in your workspace unless someone switches it off in Compliance › Manage. That differs from the national data protection laws, which start switched off.

The six scan checked GDPR requirements

Each scan of a product checks these six requirements against what the scan found. The docs mark all six as decided by a scan: the scan alone can mark each one met or not met.

The right hand column is not in the docs. It is the honest reading of what each check covers: every one of the six is a statement about the product's software composition, a precondition for the article it names rather than the article itself. In practice, EU-GDPR-32 needs components identified precisely enough, with versions and integrity data, to tell what is running from what should be running. EU-GDPR-28 fails most often on transitive components with a blank supplier field. EU-GDPR-5-2 wants an SBOM that says who generated it and when; an anonymous spreadsheet does not qualify.

The GDPR Article 25 framework

The library also has a separate GDPR Article 25 framework for privacy by design and by default. Its docs page lists four scan requirements (privacy by design components, data minimisation assessment, pseudonymisation components and controller accountability) and catalogue controls such as data minimisation at design stage, privacy review before system changes, privacy preserving defaults and retention limits by default. The docs describe each scan requirement in one line, so open it in your workspace before relying on it. A scan can see whether components that support pseudonymisation are present; it cannot see whether your code uses them correctly. Treat a pass as "the building blocks are there" and keep the design judgement in your DPIA.

Catalogue controls you evidence yourself

The GDPR framework's Controls tab also lists catalogue controls that need your evidence. Per the docs page they cover lawfulness, fairness and transparency (Article 5), lawful basis (6), consent (7), information at collection (13 and 14), a data subject rights process (15 to 22), privacy by design (25), data processing agreements (28), records of processing (30), security measures (32), breach notification to the authority (33) and to data subjects (34), and DPIAs (35).

None of these can be decided by a scan. Notice that Articles 28, 30, 32 and 33 appear twice: once as a scan requirement about software composition, and once as a catalogue control about the wider obligation. Both have to pass for your GDPR view to be honest. A green scan requirement next to an empty catalogue control is the most common misreading of a GDPR dashboard.

Policy templates for GDPR

The docs list three templates written for GDPR: the GDPR Data Protection Policy, the GDPR Personal Data Breach Response Policy and the GDPR Processor Management Policy. The standard set, adapted to GDPR, adds subjects such as vendor risk management, vulnerability and patch management, and incident response. The GDPR Article 25 framework adds a Privacy by Design and by Default Policy and a Data Protection Impact Assessment Procedure. Templates are starting points, not legal advice; they do not know your purposes, lawful bases or retention periods.

Step by step: from switching on GDPR to a reviewable evidence set

This is the flow for a processor that builds a SaaS product handling customer personal data. Screen names are from Safeguard's docs. Where the docs describe an outcome rather than a screen, so does this walkthrough.

1. Confirm GDPR, and decide on Article 25 and national laws

Open Compliance › Manage, then the Frameworks tab. Find GDPR by region (Europe), country or scope (European Union), sector (Privacy) or by search. It is on by default; if someone switched it off, switch it on and select Save. It then appears on Compliance › Frameworks, Controls and Overview. Decide in the same place whether to switch on GDPR Article 25 as well, and which national laws apply to you (more on those below). If a framework does not appear, your plan does not include it; your Safeguard administrator manages the list.

2. Map processing activities to products

In Safeguard, a product groups projects, and a project is a repository, a scanned URL or an uploaded artifact. Scan requirements are checked per product, so the grouping decides what counts as "the system processing personal data".

Start from your Article 30 record, not your repository list. A payroll processing activity might span the web application, a payslip worker, an export service and a migration image; all of them belong in the product. Leaving out the worker is how an inventory ends up describing a different system from your record.

For how products, projects, SBOMs and findings fit together, and how to count vulnerabilities without double counting, see the series post on how Safeguard data is structured.

3. Scan the products that process personal data

Connect your repositories through the web app, or scan from the Safeguard CLI (GA). The docs show the install and the first scan:

# Install the CLI
curl -fsSL https://cli.safeguard.sh/install | bash

# Open the interactive terminal, then type /login and /scan .
safeguard

Each scan produces an SBOM (SBOM generation and analysis, GA), matches components against known vulnerabilities (SCA and vulnerability management, GA, with EPSS and CISA KEV enrichment) and evaluates the six GDPR scan requirements for the product. Scanning on every merge, rather than once before an audit, is what turns the inventory into evidence of "ongoing" integrity under Article 32(1)(b). For a deeper look at what an SBOM contains and the formats Safeguard exports, see SBOM generation and analysis in Safeguard.

4. Read the six results on the Controls tab

Open GDPR on Compliance › Frameworks, then its Controls tab. The six scan requirements appear as controls, each met or not met for the product, alongside the catalogue controls.

Read the failures in this order:

1. Coverage first. If EU-GDPR-30 or EU-GDPR-25 fails, part of the product probably has not been scanned, or components could not be identified. Every other result depends on this.
2. Suppliers next. EU-GDPR-28 failures point to components without a recorded supplier: open source packages with a blank field, or SDKs for hosted services that may be sub-processors. Sort the two.
3. Provenance and integrity. EU-GDPR-5-2 and EU-GDPR-32 failures usually mean missing origin or integrity data, often closed by generating SBOMs in the build.

5. Start the GDPR policies from templates

Open GDPR on Compliance › Frameworks, then its Policies tab. Select New policy and choose Start from template. Start with the three GDPR templates:

• GDPR Data Protection Policy, your overall statement of how the organisation processes personal data.
• GDPR Personal Data Breach Response Policy, who decides whether a breach is notifiable, who notifies, and how the 72 hour clock is tracked.
• GDPR Processor Management Policy, how you select, contract, authorise and review processors and sub-processors.

Edit each to describe what you actually do; Lion (GA) can help draft, but a person decides. Use Submit for review and a compliance reviewer approves it. Per the approvals docs, an approval covers one version, the next review defaults to a year later, and editing an approved policy leaves the approved version in force until the new one is approved.

6. Attach evidence for the catalogue controls

On Compliance › Evidence, add evidence against each catalogue control. Typical items for GDPR:

Evidence starts as submitted, and a compliance reviewer chooses Accept or Reject, stamped with who, when and why. Changing accepted evidence creates a new version that goes back to submitted, and evidence with an end date becomes expiring, then expired. Set end dates on anything that ages, such as a sub-processor list.

7. Link tests where you have them

Automated tests do not map to GDPR directly, but you can link any test to a GDPR control yourself. If you connected an identity provider or cloud account for SOC 2 or ISO/IEC 27001, tests on multi factor authentication, encryption at rest or logging are natural candidates for the Article 32 control. Evidence connectors are GA; only part of the catalogue is live today, and you can ask for others through Compliance › Connectors › Request integration.

8. Bring suppliers into TPRM

For processors and suppliers whose software touches personal data, add them to Third Party Risk Manager (GA) and request SBOMs. The next section covers this in detail.

9. Record risks and decide treatment

On Compliance › Risks, record the risks your Article 32(2) assessment and DPIAs identified, with their treatment. The risk owner can accept a low or medium residual risk with a reason; high or critical needs an approver with an admin role and a review date within a year. If residual risk rises, the acceptance shows Needs re-approval.

10. Review readiness, and know what the number means

The readiness score is the share of in-scope requirements that pass, either on a scan or on a person's attestation naming its evidence. Requirements waiting for evidence count as not passing; requirements scoped out with a written justification leave the score. Safeguard's docs say the score is not an audit opinion or a certification. Use it to find gaps, and show the underlying records, not the number, to anyone who asks.

Example: what this looks like for a processor

The figures below are illustrative, not customer data. A processor runs an HR SaaS product made of five projects: a web application, an API, a payslip worker, an export service and a database migration image. After the first scans, the GDPR Controls tab shows four of the six scan requirements met. EU-GDPR-28 fails because a dozen transitive components have no recorded supplier, and EU-GDPR-5-2 fails for the migration image, which was built by hand with no generated SBOM.

The team moves the image build into CI so the SBOM is generated at build time, and EU-GDPR-5-2 passes. For EU-GDPR-28, most unsupplied components are open source packages with blank supplier fields, which the team records. Two are SDKs for hosted services, email delivery and error reporting, that receive personal data. Those go on the sub-processor list and into TPRM, so the Article 28 catalogue control now has evidence that matches the software.

How a current inventory shortens the Article 33 assessment

A critical vulnerability is published in a widely used library, with reports of active exploitation. That is not a personal data breach, and the Article 33 clock has not started. If the library sits in a system processing personal data and was exploited, the clock starts once you confirm it. Without an inventory, the first hours go to finding the library. With one:

1. Which products contain it? Search the vulnerability or component in Safeguard. Because products map to processing activities, you now know which activities are exposed.
2. Which versions, and is there a fix? The vulnerability record shows affected and fixed versions, KEV status and EPSS.
3. Was the vulnerable code reachable? Reachability analysis (GA) ranks paths your application actually calls. Unreachable is not safe, but it changes priority.
4. Hand the scope to incident response. Logs and forensics are outside Safeguard; the inventory tells responders where to look first.
5. Record what you found. Dated scan records show when the component was present and when the fix shipped, which supports Article 33(5) documentation and phased notification under 33(4).

The inventory does not decide whether a breach occurred or whether it is likely to result in a risk to individuals; those are the controller's judgements. It removes the scramble that eats the first day of a three day window. A processor can use the same steps to notify controllers promptly, in phases, with a list of affected services.

For finding every product that carries a vulnerable version across a large estate, see the series post on portfolio sweeps and blast radius.

Article 28 diligence with Third Party Risk Manager

Article 28 runs in two directions, and Safeguard helps with each in a different way.

When you are the controller assessing processors

The EDPB says the controller must assess a processor's guarantees case by case and keep verifying them, often through documents such as security policies and audit reports. Those rarely describe the software the processor runs. Third Party Risk Manager (GA) covers that side. According to Safeguard's offering and docs, TPRM lets you:

• Keep a vendor directory with contacts, contract and SLA tracking and risk categorisation.
• Request SBOMs, projects or products from suppliers, with request templates, follow ups and response tracking.
• Analyse what suppliers send, with vulnerability mapping and risk scoring against the same data your own scans use.
• Monitor suppliers continuously, with alerts when new vulnerabilities affect what they shipped you, and periodic reassessment.

The TPRM docs suggest risk tiers: critical vendors supporting core operations, with SBOMs required quarterly, and high risk vendors with significant data access, with SBOMs required annually. For GDPR, read "significant data access" as "processes personal data on our behalf".

A sensible flow: tier each processor by the personal data it handles, request SBOMs from the top tiers, review what comes back for known exploited vulnerabilities and missing suppliers, record the result against the Article 28 catalogue control next to the signed DPA, and turn on monitoring.

Not every processor will send an SBOM, and a refusal is itself information for your assessment. TPRM does not negotiate DPAs, assess transfers or decide whether guarantees are sufficient; that judgement stays with you.

For the wider supplier risk picture under DORA, NIS2 and US federal guidance, see supplier software risk with Safeguard TPRM.

When you are the processor answering controllers

If you sell software that processes customer personal data, you are on the other side of Article 28(3)(h), and your customers' DPOs will ask for the information it covers. Your Safeguard records help you answer consistently:

• A current SBOM export, in SPDX or CycloneDX, for the product the customer uses.
• The GDPR scan requirement results for that product, dated.
• Approved policies, especially the Processor Management Policy and the Breach Response Policy.
• Your sub-processor list, kept as evidence with an end date so it does not go stale.

If you want a single place to share approved material with customers, the Trust Center (GA) is designed for that, with access requests that a reviewer approves or denies. See set up a Safeguard Trust Center. Do not present any of this as a GDPR certification.

National data protection laws in the library

The GDPR applies directly across the EU but leaves room for member state law, for example on employee data. Safeguard's library includes national laws as separate frameworks, such as Ireland's Data Protection Act 2018 and Denmark's Data Protection Act 2018, plus non EU regimes such as UK GDPR and Switzerland's revised FADP. Per the docs, national data protection and cybersecurity laws start switched off; switch on the ones that apply in Compliance › Manage.

• Each national framework has its own scan requirements and controls, so several will repeat some software checks. The crosswalk can link equivalent controls; a reviewer decides whether each mapping holds, and only an approved equivalent mapping lets accepted evidence count toward the target control.
• Switching on a law does not tell you whether it applies. That is a legal question about establishment and targeting.
• If you sell into the UK, treat UK GDPR as its own framework.

Using an assistant on your GDPR data, safely

To ask an assistant "which of our products that process personal data have a known exploited vulnerability?", use Safeguard's MCP server (GA), added to Claude from Claude's connector directory, where Safeguard is a community listing. The docs describe the route: open the directory entry, select Safeguard and connect, sign in to Safeguard, check the app name and the host, then select Authorize access. There is no URL to paste. On a Claude Team or Enterprise plan, an Owner adds the connector first. ChatGPT has its own apps route; follow OpenAI's documentation. Our post on Safeguard in your IDE and in the Claude and ChatGPT connector directories covers both.

Once connected, the assistant can list your products, projects and vulnerabilities, read a CVE's full record and, where your tenant returns them, read findings. Which tools appear depends on your plan and administrator settings. Use it to summarise GDPR scan results, draft the measures section of a DPIA or draft a due diligence answer from current data. Per Safeguard's approvals docs, an assistant or MCP client can draft and submit but never accept, approve, launch or acknowledge. Check every number against the app before it goes to a customer or an authority.

Requirement, what Safeguard does, what you still own

What Safeguard does not do

• It does not make you GDPR compliant, and it does not certify. GDPR certification mechanisms are a separate, formal route Safeguard does not provide, and compliance is judged by supervisory authorities and courts.
• It does not make legal judgements. Lawful basis, whether a DPIA is required, whether processing is high risk, whether a processor's guarantees are sufficient and whether a breach must be notified are all controller decisions.
• It does not see processing purposes or personal data flows. Scans see software composition: components, versions, suppliers, vulnerabilities. They do not see what personal data a system processes, why, or for how long. Your Article 30 record has to come from you.
• It does not notify anyone. Safeguard does not contact a supervisory authority, your controllers or data subjects. It helps you scope faster and document what you found.
• It does not replace a DPA or contract review. TPRM asks suppliers for software evidence. It does not draft, negotiate or check data processing agreements or transfer mechanisms.
• It does not cover every system automatically. Unscanned products, unconnected systems and paper processes are invisible to it. Define coverage from your record of processing.
• Automated tests do not map to GDPR directly. You link them yourself; only part of the connector catalogue is live today, and others are on request. The Trust Center is generally available, and your plan decides which frameworks you can switch on.

Common mistakes

Reading six green scan requirements as "GDPR done". The six checks cover software composition. The catalogue controls for lawful basis, consent, rights, DPIAs and DPAs carry most of the GDPR, and they need your evidence.

Scoping products by repository instead of by processing activity. If the product does not match the system named in your Article 30 record, every check describes the wrong thing. Start from the record.

Scanning once before a customer audit. Article 32 talks about ongoing integrity, and the EDPB treats Article 25 as continuous. Scan on every merge.

Treating every component supplier as a sub-processor. A library maintainer usually is not one; a hosted service your SDK sends personal data to may be. Sort them.

Linking tests that do not evidence the control. A DPO will ask what each linked test proves. Link only tests you can explain.

Starting the 72 hour clock at disclosure, or not at all. A published vulnerability is not a breach; confirming a breach starts the clock. Write down who decides awareness and how it is recorded, as the EDPB recommends.

Letting evidence go stale. Give sub-processor lists, restore tests and DPIAs end dates so they show as expiring rather than quietly wrong.

Quoting the readiness score to a customer. Share records, not the number. The docs say the score is not an audit opinion.

FAQ

Does Safeguard make my company GDPR compliant?

No. Safeguard's compliance suite (GA) checks six software requirements on every scan and tracks your evidence for the rest, so you can see gaps and show your records. Compliance depends on your lawful bases, your processes and your judgements, and is assessed by supervisory authorities and courts. There is no GDPR certification from Safeguard.

What does GDPR Article 32 require for software?

Article 32 requires security appropriate to the risk, with examples including encryption and pseudonymisation, ongoing integrity and resilience of processing systems, timely restoration after incidents, and regular testing of the measures. The EDPB's breach examples single out patch management and fixing known vulnerabilities as one of the most important measures.

Does GDPR require an SBOM?

No article mentions SBOMs. But Articles 28, 30, 32 and 33 each assume you know which software performs the processing and who supplies it, and an SBOM generated on every build is the most direct way to show that.

Is an open source library a sub-processor under Article 28?

Usually not. A library you run in your own systems does not process personal data on your behalf. A hosted service that receives personal data through an SDK in your code may be a processor or sub-processor.

How does Safeguard help with the 72 hour breach deadline?

It does not notify anyone, and a vulnerability is not a breach. It answers the inventory questions quickly (which products contain a component, which versions, whether a fix exists, whether the code was reachable) and keeps dated records for your Article 33(5) documentation.

Can I use Safeguard to assess my processors under Article 28?

Partly. Third Party Risk Manager (GA) requests and monitors SBOMs from suppliers and scores what they send. It covers the software side of sufficient guarantees. Contract terms, transfer mechanisms and your overall sufficiency judgement stay with you.

Is GDPR switched on by default in Safeguard?

According to the docs, yes: GDPR is on unless someone switches it off in Compliance › Manage. National data protection laws, such as Ireland's or Denmark's acts, start switched off, and you turn on the ones that apply. Your plan decides which frameworks are available.

Can Claude or ChatGPT approve GDPR evidence in Safeguard?

No. Per Safeguard's approvals docs, an AI assistant or MCP client can draft and submit, but never accept, approve, launch or acknowledge. A compliance reviewer makes those decisions in the app, and the decision is recorded with who made it, when and why.

Fixing known vulnerabilities is an Article 32 measure

The EDPB's breach casebook names timely patching of known vulnerabilities as one of the most important security measures for systems processing personal data, so how fast a fix reaches production is part of your Article 32 story. Here is how Safeguard helps close that gap, including when no upstream fix exists yet.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Griffin, Safeguard's security model, opens a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Safeguard Gold rebuilds patched versions of open-source packages and images from source, signs each build, attaches an SBOM, SLSA provenance and VEX, and serves them from registry.safeguard.sh to your organization. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo shows Claude connecting to the Safeguard MCP server with an OAuth sign in and choosing which tools Claude can use. For your own setup, add Safeguard from Claude's connector directory rather than configuring it by hand. Once connected, a DPO or privacy engineer can ask which products that process personal data carry a KEV listed vulnerability, or have Claude draft the security measures paragraph of an Article 30 record from current scan data, then review it, because the assistant cannot accept or approve anything.

Click through it at your own pace, or open it full screen.

The second demo is a real Safeguard CLI session. You install the CLI, open the interactive terminal with safeguard, and ask it to fix the lodash CVE in a repository. It reads the finding and the advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. It then shows /permissions, /model and /scan . For GDPR, that last command refreshes the product's SBOM and the six scan requirements, and the dated fix is the kind of patch record the EDPB recommends keeping.

Click through it at your own pace, or open it full screen.

To try this on your own products, download Safeguard at safeguard.sh/download and read the setup guides at docs.safeguard.sh. Related reading: continuous compliance in Safeguard, who approves what in Safeguard compliance and what to keep running after a GDPR Article 32 audit.

Quick check

Sources

• EDPB: Guidelines 9/2022 on personal data breach notification under GDPR
• EDPB: Guidelines 9/2022, version 2.0 (PDF)
• EDPB: Guidelines 07/2020 on the concepts of controller and processor in the GDPR
• EDPB: Guidelines 07/2020, version 2.1 (PDF)
• EDPB: Guidelines 4/2019 on Article 25 Data Protection by Design and by Default
• EDPB: Guidelines 4/2019, version 2.0 (PDF)
• EDPB: Guidelines 01/2021 on examples regarding personal data breach notification
• EDPB: Guidelines 01/2021 (PDF)
• EDPB data protection guide for small business: Secure personal data
• EDPB data protection guide for small business: Be compliant (records of processing, DPIA)
• EDPB data protection guide for small business: Data breaches
• Safeguard docs: GDPR
• Safeguard docs: GDPR Article 25
• Safeguard docs: Compliance frameworks
• Safeguard docs: Approvals
• Safeguard docs: Third Party Risk Manager
• Safeguard docs: Claude
• Safeguard docs: Safeguard CLI

Last reviewed: 24 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.