GDPR or Cyber Resilience Act: which to pursue first
The answer depends on two questions: whether your product falls within the Cyber Resilience Act's scope (products with digital elements placed on the EU market), and whether your software or service processes personal data. For most software and connected-product makers selling into the EU, the GDPR already applies now. Its security duty under Article 32 and its breach notification duties have applied since 25 May 2018, and they cover your own processing of customer and user data. The CRA is different in timing. Its Article 14 reporting obligations began on 11 September 2026, the day ENISA launched the initial operating capability of the CRA Single Reporting Platform, while the full regulation applies from 11 December 2027.
Neither law gives you a certificate you can show the other regulator. The GDPR requires no audit, attestation or certificate, and Article 42 certification is voluntary, lasts for at most three years and does not reduce the controller's or processor's responsibility. The CRA relies mostly on self-assessment under module A, so most products need no notified body. A notified body is needed for class I important products where harmonized standards are not applied in full, and for class II and critical products. Products already on the market before 11 December 2027 fall under the full regulation only if they are substantially modified, but their Article 14 reporting duties apply whenever they were placed on the market. Confirm your product's class against Annex III and Annex IV with counsel before choosing a conformity route.
Pursue the GDPR baseline first, because it is in force and supervisory authorities can impose fines under Article 83, then start the CRA work that cannot wait. Assign one owner to a vulnerability handling and reporting runbook, confirm with your national authority which CSIRT is the coordinator for your reports, and plan to file through the ENISA platform. Share evidence across both programs: Article 32 testing records, access control reviews and patch history can also support the Annex I vulnerability handling requirements, so one evidence library can serve both. Treat any notified body engagement as a separate budget line, because a quote follows the written scope of your product and its class.
How the GDPR and the CRA differ on scope, proof and fines
This table sets Regulation (EU) 2016/679 beside Regulation (EU) 2024/2847 on what each protects, who it binds, the proof it produces, who enforces it, its fine tiers and its application dates. Read each row as a question to answer for your own products and data flows, since many firms selling into the EU fall under both.
| Dimension | GDPR (Regulation (EU) 2016/679) | Cyber Resilience Act (Regulation (EU) 2024/2847) |
|---|---|---|
| What it protects | Personal data of people, through lawful processing and security of processing | Security of products with digital elements placed on the EU market |
| Who it binds | Controllers and processors handling personal data | Manufacturers, and the importers and distributors placing products on the market |
| Proof it produces | No audit, attestation or certificate is required; Article 42 certification is voluntary | CE marking after self-assessment under module A, or a notified body where the product class requires one |
| Enforcing bodies | Independent national supervisory authorities, with the EDPB resolving disputes | Market surveillance and national authorities, with ENISA running the single reporting platform |
| Top fine tier | EUR 20 million or 4% of worldwide annual turnover under Article 83 for the most serious infringements | EUR 15 million or 2.5% of worldwide annual turnover under Article 64 for Annex I and Articles 13 and 14 breaches |
| Lower fine tier | EUR 10 million or 2% under Article 83 for infringements such as Articles 25 to 39 | EUR 10 million or 2% for other listed obligations, and EUR 5 million or 1% for misleading information |
| Key application date | Applies since 25 May 2018 (Article 99) | Reporting duties from 11 September 2026; main obligations from 11 December 2027 (Article 71(2)) |
Who the GDPR binds and who the CRA binds
The GDPR binds controllers and processors that handle personal data of people in the EU and EEA, whatever their sector or where they are established, so the question is whether your company determines the purposes and means of processing or processes data on someone else's behalf. The Cyber Resilience Act binds something different: manufacturers, importers and distributors of products with digital elements placed on the EU market. A SaaS vendor that hosts customer records is usually a processor under the GDPR, but a hosted service is generally not a product with digital elements, so it may sit outside CRA product scope. Confirm this with counsel by checking whether any software or hardware is supplied to customers for installation or operation on their own systems, since that supply is what brings a product into scope.
A connected device maker is often in both. The device handles personal data through its companion app or cloud back end, which makes the company a controller or processor under the GDPR, and the device itself is a product with digital elements under the CRA. The two regimes then need separate ownership: the privacy team maps processing and lawful basis, while the product security team maps the essential cybersecurity requirements in Annex I and the vulnerability handling duties. Product scope also depends on the class of the product, which determines whether self-assessment is available or a notified body is needed, so check the category against Annex III and the Commission's technical descriptions before planning conformity work.
Article 69 governs products already on the market. Products placed on the market before 11 December 2027 fall under the regulation only if they are substantially modified from that date. The Article 14 reporting obligations are the exception: they apply to all in-scope products whenever they were placed on the market, and manufacturer reporting began on 11 September 2026. For a maker with a installed base, this means legacy devices may need to be reportable from day one even if their design does not need to meet the full CRA requirements. Ask engineering to list every in-scope product line, its install base and its planned substantial modifications, so that reporting readiness does not wait for the 2027 application date.
Where the GDPR and CRA work overlaps
The GDPR and the Cyber Resilience Act both expect secure products and secure handling of data, but they bind different parties for different reasons. The overlap is practical engineering work that can serve both, while legal grounds, rights handling and conformity routes stay separate. Read each card for the condition under which the overlap holds.
Security of processing and essential requirements
Article 32(1) asks for measures appropriate to the risk, including encryption, confidentiality, integrity, availability and regular testing of effectiveness. CRA Annex I sets essential cybersecurity requirements for the product itself. The overlap holds when personal data is processed inside the product or the vendor's hosted service, so one security design can answer both. It does not transfer the GDPR lawful basis or data subject rights, which the CRA does not address. Confirm with counsel which role you hold for each data flow.
Vulnerability handling under Annex I Part II
Annex I Part II lists eight vulnerability handling requirements for manufacturers, covering how vulnerabilities are identified, documented, fixed and disclosed over the support period. The GDPR does not set a vulnerability process, but Article 32 expects the controller and processor to restore availability and act on known weaknesses. A single patch and advisory pipeline can serve both when the affected product also stores personal data. Check whether your support period and your customer contracts describe the same end dates.
Security testing and evidence
Article 32 names regular testing of the effectiveness of technical and organizational measures. The CRA expects manufacturers to test products and document results as part of conformity work, and most products rely on self-assessment under module A. The overlap is real when the same test reports can show both the product's essential requirements and the processing controls. Neither law accepts a certificate as a substitute for evidence, and the GDPR Article 42 certification is voluntary and does not reduce responsibility.
Incident handling and reporting channels
The GDPR requires controllers to notify the supervisory authority of personal data breaches under Article 33 and affected individuals under Article 34 when risk is high. The CRA Article 14 reports go to a single reporting platform for actively exploited vulnerabilities and severe incidents, and these channels are separate. The overlap holds when one incident record feeds both assessments, with separate decisions on whether personal data is involved. Confirm which CSIRT or authority receives each notice, since the two clocks differ.
Technical documentation and accountability
The CRA requires technical documentation and a declaration of conformity for products in scope, while the GDPR requires controllers to demonstrate compliance under the accountability principle. Architecture diagrams, risk assessments, data flow maps and test records can be shared between both files. What does not transfer is the record of processing activities, lawful basis analysis and data protection impact work, which the CRA does not require. Keep the two documents linked by version so auditors can trace each claim.
Support periods and software updates
The CRA requires manufacturers to provide security updates for a defined support period, and the GDPR requires that personal data stay protected for as long as it is processed. When a product holds customer data for longer than its support window, the gap becomes a GDPR exposure as well as a product compliance issue. The overlap holds for software vendors who host or process data on customers' behalf. Ask customers which retention and update terms apply, because the CRA does not set them for the data itself.
Who assesses each regulation and what it issues
This table compares who checks compliance under the GDPR and the Cyber Resilience Act and what each one produces, such as a certificate, a CE marking or nothing at all. Read it to see which obligations need external assessment and which rest on your own documented evidence. The main takeaway is that neither law issues a general compliance certificate, but the CRA's CE marking depends on a conformity route that may require a notified body.
| Question | GDPR | Cyber Resilience Act |
|---|---|---|
| Audit or certificate required | No audit, attestation or certificate is required | Conformity assessment is required before CE marking, with the route set by product class |
| Voluntary certification | Article 42 certification, issued for at most three years by accredited bodies or supervisory authorities | Not a substitute for conformity assessment; voluntary schemes may be relevant only where a scheme exists |
| Default route for most products | Not applicable; the controller must demonstrate compliance | Module A self-assessment by the manufacturer for most products |
| When an independent body is needed | Only if the controller chooses Article 42 certification | Class I important products where harmonized standards are not fully applied; class II and critical products |
| Notified body chapter timing | Not applicable | Chapter IV on notification of conformity assessment bodies (Articles 35 to 51) applies from 11 June 2026 |
| Output that reaches the market | No mark; evidence held by the controller or processor | CE marking affixed after conformity assessment, enabling placement on the EU market |
| Who enforces | Independent national supervisory authorities | Market surveillance and the authorities that the regulation designates, with reporting to the CSIRT designated as coordinator |
| What DeployOpen provides | Implementation, documentation and evidence preparation for your controls; no certification | Security engineering and evidence support for your technical file; no CE marking or conformity assessment |
Two reporting channels with different clocks
One incident can trigger two separate filings. A personal data breach under the GDPR is reported to the supervisory authority under Article 33 and, where the risk to individuals is high, communicated to the affected individuals under Article 34. The CRA reporting duty in Article 14 is a different obligation. It covers actively exploited vulnerabilities and severe incidents affecting a product with digital elements, and from 11 September 2026 manufacturers file those notices through the ENISA Single Reporting Platform. The notice goes to the CSIRT designated as coordinator, and the platform makes it available to ENISA at the same time. A product flaw that also exposed customer records may therefore need a GDPR filing to the data protection authority and a CRA filing to the national CSIRT, each with its own content and its own clock.
Treat the two filings as independent. Acknowledgement or closure of one does not satisfy the other, and a CRA report does not replace a breach notice to a supervisory authority. Map your incident runbook so that a single triage decision branches into both workflows: one owner for the personal data assessment, one owner for the product vulnerability and exploitation assessment, and a named contact for each national authority in every Member State where you sell. Confirm which personal data elements, product versions and Member States each clock applies to, since the two regimes count the start of the period differently.
Before relying on any timing, confirm the deadlines directly in the text of Article 33 and Article 14 of Regulation (EU) 2024/2847 and with the national data protection authority and national CSIRT that will receive your filings. Ask ENISA's Single Reporting Platform frequently asked questions for the current submission steps, and ask your legal counsel to confirm how each authority treats a combined incident. Practising one tabletop exercise that runs both branches will show gaps in ownership and contact details long before a real notice is due.
Sequencing the GDPR and CRA work
This sequence lets one team meet GDPR accountability and CRA product obligations without duplicating inventories, controls or incident processes. Each step ends with a named output that the next step depends on.
Map personal data flows and product inventory
The privacy office and product security lead build two inventories side by side. One records where personal data is processed, by which systems, as controller or processor, and where it is transferred. The other lists every product with digital elements the company makes available in the EU, including software versions and support periods. Both teams sign off on the scope of each list. Done means each product has a named owner and each personal data flow has a documented controller or processor role. Evidence from these inventories is shared, because both regimes start from the same asset list.
Confirm CRA scope and product class
Product security and legal review each product against the CRA's product categories, with particular attention to whether a product is an important product in class I or class II, or a critical product. Ask the question directly: which products fall under the regulation, and which were placed on the market before 11 December 2027 and may be outside it unless substantially modified. Confirm free and open-source components with counsel, using the Commission's non-binding guidance. Done means each product has a written scope decision and a class, with the conformity route that follows from it. Evidence here is shared with the GDPR team only where a product processes personal data.
Set the CRA reporting contact before 11 September 2026
Manufacturers must be able to report actively exploited vulnerabilities and severe incidents under Article 14, and those obligations apply from 11 September 2026 to in-scope products whenever they were placed on the market. Name a reporting owner and a deputy, register the company on ENISA's Single Reporting Platform, and confirm which national CSIRT coordinates the company's notifications. Build a short internal path that routes a suspected exploited vulnerability to that owner within the same working day. Done means a tested contact route exists and the owners can be reached outside office hours. This channel is kept separate from GDPR breach notification, which goes to the supervisory authority.
Build the Article 32 security baseline
The GDPR requires measures appropriate to the risk, and Article 32(1) names pseudonymisation and encryption, confidentiality, integrity, availability and resilience, timely restoration, and regular testing. The security engineering lead documents a baseline for systems that process personal data, covering access control, encryption, logging, backup and restoration, and a schedule for testing effectiveness. The baseline should reuse controls the product team is already building for the CRA, such as secure development and vulnerability handling, rather than create a second set. Done means a signed baseline with an owner per control and test results on file. Evidence is shared where the same control serves both regimes.
Run the Annex I gap assessment with testing
Assess each product against the essential cybersecurity requirements in Annex I, Part I, and the eight vulnerability handling requirements in Part II. Map each requirement to an existing control, a partial control or a gap. Test the gaps with security testing that matches the product, such as code review, dynamic testing of exposed interfaces and checks of default configurations. Confirm which harmonized standards or common specifications the team will apply, noting that the Commission's standardization work is still producing standards. Done means a gap register with an owner, a test result and a remediation decision for each item. Test findings that touch personal data are shared with the GDPR team, and the rest stays in the product security record.
Prepare technical documentation and the conformity route
For each in-scope product, the product team assembles technical documentation that describes the design, the risk assessment, the security measures and the support period. Confirm the conformity route with the regulation: most products follow self-assessment under module A, while a notified body is needed for class I important products where standards are not applied in full and for class II and critical products. Where a notified body is required, ask the body for its scope and timing in writing. Done means each product has a complete documentation file and a recorded route to CE marking. The GDPR team reviews only the parts of the file that describe personal data handling, and the CRA file stays separate from any certification the company holds for other purposes.
Align breach runbooks for both clocks
Last, the incident response lead merges the security incident process with two separate notification paths. A personal data breach follows GDPR Articles 33 and 34, with notice to the supervisory authority and, where risk is high, to data subjects. A reportable vulnerability or incident in a product follows the CRA reporting path set in step three. The runbook should record which facts trigger each path, who signs each notice, and where evidence is kept. Test the runbook with a tabletop exercise that includes both a personal data incident and a product vulnerability. Done means the runbook has passed the exercise and each notification owner has confirmed their role in writing. Shared evidence is limited to the incident record itself.
Questions buyers ask before engaging help
Does the GDPR issue a certificate I can show customers?
No. The GDPR requires no audit, attestation or certificate. Article 42 certification is voluntary, is issued for at most three years by accredited certification bodies or supervisory authorities, and does not reduce the controller's or processor's responsibility for compliance. When a customer asks for GDPR proof, ask for evidence they can test: a record of processing activities, data flow and personal data maps, a data protection impact assessment where one is required, the processor terms in place with your suppliers, and documented decisions on security measures under Article 32. A certificate, where one exists, supports a conversation about those records but does not replace them. Planning the GDPR work around the evidence you can produce keeps the engagement focused on what a supervisory authority would actually ask to see.
Does the Cyber Resilience Act require a notified body for my product?
Most products do not need one. Most products follow self-assessment under module A, which means the manufacturer carries out the conformity assessment itself. A notified body is needed for class I important products where harmonized standards, common specifications or certification schemes are not applied in full, and for class II important products and critical products. Annex III lists 19 categories in class I and 4 in class II, and Annex IV lists 3 categories of critical products. Commission Implementing Regulation (EU) 2025/2392 gives the technical description of each category, so start by matching each product to a category. The route can change as harmonized standards are published, since the Commission's standardization request M/606 covers 41 standards with different due dates. A notified body is independent of your implementation partner, and DeployOpen does not issue conformity assessments. Confirm the route in writing with your legal team and the relevant authority before you commit budget.
What drives the cost and effort of GDPR and CRA work?
The main cost drivers are scope size, the number of products and variants, the number of personal data flows, the depth of your supplier chain, and how much usable evidence already exists. Several parties are paid for different things. Internal engineering and legal time is the largest recurring cost. An implementation partner is paid for scoped work such as gap analysis, documentation, hardening and evidence preparation. A notified body, where your product needs one, charges for its own assessment, and counsel may be needed for interpretation. One-time work includes the initial inventory, risk assessment, technical documentation and reporting setup. Recurring work includes vulnerability handling, incident reporting readiness during product support periods, retesting and upkeep of records of processing. DeployOpen does not publish a price list. Its engagements are fixed-scope, and a quote follows from a written scope that lists deliverables, assumptions and exclusions, so ask every bidder to price each item separately.
How long does a GDPR and CRA readiness project take?
The duration depends on scope, and no supplied fact gives a single figure for it, so confirm the timeline in a written plan before work starts. The dates that set the pressure are fixed by law. The Article 14 reporting obligations under the Cyber Resilience Act apply from 11 September 2026, the Chapter IV rules on notified bodies apply from 11 June 2026, and the regulation as a whole applies from 11 December 2027. Products placed on the market before 11 December 2027 fall under the regulation only if they are substantially modified from that date, but the Article 14 reporting obligations apply to in-scope products whenever they were placed on the market. A sound plan lists milestones, owners, dependencies such as engineering availability and notified body scheduling, and the point at which each deliverable is accepted. Ask for the plan to show which work you can start now, such as reporting readiness, and which work waits on the standards and product categorization.
What does our team need to supply before work starts?
Your team supplies the facts, decisions and access that no outside party can provide. For the Cyber Resilience Act, that means a complete product inventory with versions, supported periods and the category each product falls under, plus a list of the third-party and open-source components inside each one. For the GDPR, it means architecture diagrams, data flow diagrams, a map of the personal data each system processes, the legal basis and retention approach you already use, and the list of processors and their contracts. Your team also needs named owners in engineering, security, legal and product, because decisions about risk acceptance and product scope cannot be delegated to a consultant. Access to source repositories, build pipelines, ticketing systems and existing policies shortens the evidence work. Ask the implementation partner to publish this request list in the written scope so that you can check engineering time against it before you commit.
Can our internal team handle GDPR and CRA work alone?
An internal team can handle much of this work alone, provided it has the right skills and enough protected time. The GDPR places accountability on the controller and the processor, so your privacy and legal staff must own the decisions. The Cyber Resilience Act places obligations on the manufacturer, including vulnerability handling and reporting. Those duties need people who understand threat modeling, secure development, vulnerability management and incident response, not only compliance paperwork. The reporting channel is already live: ENISA launched the initial operating capability of the CRA Single Reporting Platform on 11 September 2026, and notifications go to the CSIRT designated as coordinator and are made available to ENISA at the same time. A team that has never run a reporting process should test it before a real event. External help is most useful for an independent gap review, for a fixed-scope piece such as documentation or hardening, or for a retainer covering upgrades and continuous testing after launch.
What fines apply if we miss CRA reporting or GDPR duties?
Both regimes set maximum fines as the higher of a fixed amount or a share of worldwide annual turnover, but the tiers differ. Under Article 64 of the Cyber Resilience Act, breaches of Annex I and of Articles 13 and 14 can draw fines of up to EUR 15 million or 2.5% of total worldwide annual turnover. Other listed obligations carry up to EUR 10 million or 2%, and incorrect or misleading information given to authorities carries up to EUR 5 million or 1%. Under Article 83 of the GDPR, infringements such as those in Articles 25 to 39 carry up to EUR 10 million or 2%, and infringements of the core principles, lawful basis, data subject rights and transfer rules carry up to EUR 20 million or 4%. Fines are maximums, and the actual amount depends on the authority's assessment. Because the Article 14 reporting duty already applies, a missed report can be costly even before the product rules take effect. Plan the reporting process first, then the wider evidence.
How DeployOpen prepares readiness for both regimes
DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside your own infrastructure. For GDPR and Cyber Resilience Act readiness, we start from the scope you agree in writing and work through the controls, records and evidence each regime needs.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- We map which products, personal data flows and product lines fall under GDPR controller or processor duties and which fall under the CRA.
- We confirm with you which CRA product classes and conformity routes apply, since those depend on the product and its technical description.
How we build
- We implement and harden the security measures your GDPR Article 32 risk assessment calls for, inside your own cloud accounts or data centers.
- For CRA work, we help set up vulnerability handling, security update and reporting processes that match the product's Annex I requirements.
- We run security testing against the systems in scope and record the findings, fixes and retests in a form your auditors and regulators can review.
How we hand over
- You receive documentation covering the controls, processes, configurations and evidence produced during the engagement.
- Incident and reporting runbooks are written so GDPR breach handling and CRA reporting steps can be run by your own team.
- We confirm with you which evidence belongs to your conformity assessment body or supervisory authority, since DeployOpen does not issue certifications or attestations.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the initial engagement closes.
- Retainers can keep documentation current as the CRA reporting obligations and supporting guidance evolve for your products.
- Ask any partner, including DeployOpen, to confirm in writing what each deliverable proves and which regulator or assessor will rely on it.
Sources and further reading
- Regulation (EU) 2016/679 (GDPR), EUR-Lex ↗
- Regulation (EU) 2024/2847 (Cyber Resilience Act), EUR-Lex ↗
- Commission FAQs on the Cyber Resilience Act, version 1.4 ↗
- ENISA Single Reporting Platform: Frequently Asked Questions ↗
- Regulation (EU) 2025/2518 laying down additional procedural rules on the enforcement of Regulation (EU) 2016/679, EUR-Lex ↗
- Cyber Resilience Act implementation, Shaping Europe's digital future ↗
