Two Regulations, One Product
If your company sells software that processes personal data in the EU, you have always been subject to GDPR. Starting December 2027, you will also be subject to the Cyber Resilience Act — Regulation (EU) 2024/2847 — which applies to "products with digital elements" regardless of whether they process personal data. Every piece of software sold in the EU now sits under both.
The regulations were written by different Commission directorates (DG JUST for GDPR, DG CNECT for CRA), on different timelines (2016 vs 2024), with different enforcement mechanisms (data protection authorities vs market surveillance authorities). They share one conceptual ancestor — the EU's internal market approach to horizontal regulation — and a surprising amount of substantive overlap.
This post walks through where the two regimes converge for software teams, where they diverge, and how to build a compliance stance that serves both.
GDPR's Software Requirements (Article 32)
GDPR is mostly a data-protection regulation, but Article 32 is a security requirement. It obligates controllers and processors to implement "appropriate technical and organisational measures to ensure a level of security appropriate to the risk." The article lists examples: pseudonymisation and encryption; ongoing confidentiality, integrity, availability and resilience; ability to restore availability; and "a process for regularly testing, assessing and evaluating" the measures.
For software, Article 32(1)(d) — the testing requirement — pulls in secure-development practice. The regulation doesn't say "SBOM," but the European Data Protection Board's Guidelines 01/2021 on examples regarding personal data breach notification repeatedly cite vulnerabilities in third-party components as notifiable breaches. If a Log4Shell-style event hits a GDPR controller's software, the assessment of whether measures were "appropriate" will include whether the controller knew about the component and had a process to patch.
Article 25 (Data Protection by Design and by Default) extends this: security measures have to be integrated from the outset. Software bought from a third party carries the controller's accountability — there is no outsourcing of Article 32 through a DPA.
CRA's Scope and Core Requirements
The Cyber Resilience Act is a horizontal product regulation. It applies to "products with digital elements" — defined broadly to include hardware and software connected directly or indirectly to a device or network. That covers nearly all commercial software.
CRA's core obligations, detailed in Annex I, include:
- Part I (Cybersecurity requirements) — security by design and by default; delivered without known exploitable vulnerabilities; secure default configuration; protection against unauthorized access; confidentiality, integrity, and availability of processed data; minimization of attack surface.
- Part II (Vulnerability handling) — "identify and document vulnerabilities and components contained in products, including by drawing up a software bill of materials in a commonly used and machine-readable format" (Annex I Part II (1)). Coordinated vulnerability disclosure, security updates, and notification obligations to ENISA for actively exploited vulnerabilities.
The SBOM requirement is explicit — CRA is the first major EU regulation to name-check SBOMs directly. Article 14 adds a twenty-four-hour early-warning notification to ENISA and the CSIRT for actively exploited vulnerabilities and severe incidents.
Where GDPR and CRA Overlap
For software products that process personal data, the overlaps are substantial.
"Appropriate measures" under Article 32 ↔ Annex I Part I requirements. What the CRA calls essential cybersecurity requirements is what GDPR calls appropriate measures. A product that meets CRA Part I has a strong presumption of Article 32 adequacy for the product layer.
Breach notification under Article 33 ↔ CRA Article 14 notification. GDPR requires notification within 72 hours of a personal data breach; CRA requires 24-hour early warning for actively exploited vulnerabilities plus 72-hour incident notification. For an event that is both, you notify both — DPA under GDPR, CSIRT/ENISA under CRA — on the shorter clock.
Data protection by design (Article 25) ↔ CRA "secure by default" (Annex I Part I (3)(b)). Both require that defaults minimize the attack surface and exposure of personal data. A single set of default-configuration decisions can satisfy both.
Processor due diligence (Article 28) ↔ CRA Part II vulnerability handling. When a controller relies on a processor, due diligence under Article 28 can now include CRA compliance evidence — the processor's SBOM, vulnerability handling policy, and coordinated disclosure process all feed into GDPR accountability.
Where They Diverge
Two structural differences matter.
First, scope. GDPR applies only when personal data is processed. CRA applies to the product regardless. Software that processes no personal data (think: a CAD package, an embedded controller) is fully subject to CRA and not subject to GDPR at all. Conversely, GDPR covers data flows that CRA never reaches — marketing processing, HR records, customer service.
Second, enforcement architecture. GDPR penalties flow through DPAs and can reach 4% of global turnover. CRA penalties flow through market surveillance authorities (MSAs) and can reach 2.5% of global turnover for major compliance failures. The procedures, remedies, and redress mechanisms differ. A single incident can trigger both investigations in parallel.
The practical consequence: you cannot assume a clean GDPR record implies CRA adequacy, or vice versa. They share evidence but not conclusions.
The Integrated Stance
I advise software teams to build three bridging artifacts:
- A single SBOM pipeline that emits CycloneDX 1.5 or SPDX 2.3 at every build. Required explicitly by CRA Annex I Part II (1); implicitly required by GDPR Article 32 to support "regularly testing, assessing and evaluating" measures. One artifact, two regulators.
- A unified vulnerability handling policy with 24-hour, 72-hour, and longer-form disclosure tracks. The 24-hour CRA early warning is the tightest; building the process to that clock gives the 72-hour GDPR track room to breathe.
- A DPIA-and-CRA-conformity template that handles both. Article 35 DPIAs already require an assessment of risks to the rights and freedoms of natural persons; adding a CRA conformity section at the top captures the product-level picture.
For vendors that become Processors under GDPR, the CRA compliance evidence can be supplied alongside the DPA. Sophisticated Controllers are already asking for it.
SBOM as Lingua Franca
The SBOM is the most significant practical bridge between these regimes. Under CRA it is mandatory. Under GDPR it is the single most powerful piece of evidence for the "appropriate measures" argument when a vulnerability in a component leads to a breach. The EDPB's guidance already treats knowledge-of-component-exposure as a factor in breach notification decisions; after CRA takes effect, that factor becomes dispositive.
Teams that have been resisting SBOM adoption on GDPR grounds alone should stop. CRA settles the question.
Common Pitfalls
Treating CRA as hardware regulation. The acronym pattern (NIS2, DORA, CRA) makes people assume operational scope. CRA applies to software products directly.
Assuming open-source exemption. CRA has a nuanced treatment of open source under Article 2, introduced during trilogue. Commercial distribution and commercial support trigger full obligations; purely non-commercial development does not. Read Article 2 and Recitals 18-21 carefully before assuming an exemption.
Running two breach processes. A single security event may trigger notifications on two clocks. One incident response function, with two notification tracks, is the efficient model.
How Safeguard Helps
Safeguard produces CycloneDX 1.5 SBOMs that meet CRA Annex I Part II (1) requirements directly, and maintains continuous component inventory that supports GDPR Article 32's "ongoing confidentiality, integrity" obligation. The vulnerability intake feeds a coordinated disclosure workflow aligned to both CRA's 24-hour early warning and GDPR's 72-hour notification clock. Compliance report exports are labeled simultaneously against CRA Annex I control references and GDPR Article 32 evidence requirements, so conformity assessments for MSAs and accountability records for DPAs pull from one source of truth.