EU CRA 2026 Vulnerability Reporting Readiness Guide
It is 08:17 on a Monday morning in September 2026. Anna, the CISO of a fast-growing European SaaS company, is still thinking about last week’s board meeting. The CEO had asked the question every security leader is hearing now: “If we already prepared for NIS2 and our fintech clients keep asking about DORA, what does the Cyber Resilience Act change?”
Then the answer lands in her inbox.
An independent researcher reports a remotely exploitable vulnerability in a firmware update component used by one of the company’s connected products. The message includes a proof of concept, a dependency name, and a warning that similar exploitation has been observed in the wild.
Within minutes, everyone wants a different answer. The CTO asks whether the vulnerability is real. Legal asks whether EU Cyber Resilience Act reporting has been triggered. The product team asks which versions are affected. The CISO asks whether the dependency appears in any SBOMs. Sales asks whether financial-sector customers need DORA evidence. The compliance manager opens the ISO 27001 risk register and finds a vulnerability management process, but no clear product reporting decision path.
That is the real CRA readiness problem. Most organizations do not start from zero. They already have incident response policies, patch management routines, secure development practices, supplier reviews, vulnerability scanners and ISO 27001 evidence. But the CRA does not reward isolated documents. It demands a fast, defensible workflow that can answer five questions at the same time:
- Is this an actively exploited vulnerability or a severe incident affecting product security?
- Which products, versions, customers, dependencies and suppliers are affected?
- Which authority, customer or contractual recipient must be notified, and when?
- What evidence proves that triage, mitigation and disclosure were controlled?
- How does this align with ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF and audit expectations?
The answer is not a separate “CRA folder.” The answer is to wire CRA vulnerability reporting into the ISMS, coordinated vulnerability disclosure process, SBOM discipline, supplier governance and incident response evidence chain you already need for mature cybersecurity governance.
Why the EU Cyber Resilience Act changes the reporting model
The EU Cyber Resilience Act, Regulation (EU) 2024/2847, brings product security into the compliance mainstream. It applies to products with digital elements placed on the EU market, which can include connected devices, software, firmware, embedded systems and enterprise software products.
The operational change that matters most for CISOs, product security leaders and compliance teams begins on 11 September 2026. CRA Article 14 requires staged reporting for actively exploited vulnerabilities and severe incidents affecting the security of products with digital elements. In practical terms, manufacturers must be ready for:
| CRA reporting event | Expected timing | Practical evidence needed |
|---|---|---|
| Early warning for actively exploited vulnerability | Within 24 hours of awareness | Awareness timestamp, exploitation assessment, affected product hypothesis |
| Fuller vulnerability notification | Within 72 hours of awareness | Severity, affected products, mitigation status, SBOM evidence, initial corrective plan |
| Final vulnerability report | After corrective or mitigating measure becomes available | Root cause, impact, remediation, security update details, user guidance |
| Early warning for severe incident affecting product security | Within 24 hours of awareness | Incident timeline, product impact, operational impact, initial containment |
| Fuller severe incident notification | Within 72 hours of awareness | Impact analysis, affected users, corrective actions, coordination records |
| Final severe incident report | Within one month after initial incident notification | Complete timeline, cause, mitigation, lessons learned, residual risk |
The exact legal assessment should always be performed by qualified counsel, but the operating lesson is clear. The first 24 to 72 hours are only as good as the preparation completed months earlier.
If your SBOMs are incomplete, if your CVD inbox is monitored informally, if supplier contracts do not require vulnerability notification, or if your incident response policy does not distinguish product vulnerability reporting from privacy or operational incidents, the legal clock will move faster than your evidence process.
Use ISO/IEC 27001:2022 as the chassis for CRA readiness
ISO/IEC 27001:2022 is not a substitute for CRA legal compliance, but it is the best management system chassis for integrating CRA obligations into day-to-day governance.
Clauses 4.1 to 4.4 require the organization to understand internal and external context, interested parties, requirements, interfaces with other organizations and ISMS scope ISO/IEC 27001:2022. For CRA readiness, that means your ISMS scope should identify products with digital elements, product lifecycle responsibilities, hosted components, build pipelines, open-source dependencies, suppliers, users, importers, distributors, regulated customers and relevant authorities.
Clauses 6.1.1 to 6.1.3 require risk assessment and risk treatment, including risk owners, consequences, likelihood, treatment decisions, the Statement of Applicability and residual risk acceptance. CRA reporting should be treated as a product security risk scenario inside that process, not as an emergency legal interpretation exercise.
ISO/IEC 27002:2022 ISO/IEC 27002:2022 then gives the practical control structure. The most important controls for CRA vulnerability reporting are:
| ISO/IEC 27002:2022 control | Correct control name | CRA readiness role |
|---|---|---|
| 8.8 | Management of technical vulnerabilities | Identifies, assesses, prioritizes, treats and tracks vulnerabilities |
| 8.25 | Secure development life cycle | Embeds product security, dependency review and secure engineering into development |
| 5.21 | Managing information security in the ICT supply chain | Connects supplier components, SBOM inputs and upstream notices to product risk |
| 5.20 | Addressing information security within supplier agreements | Converts supplier obligations into enforceable contract clauses |
| 5.24 | Information security incident management planning and preparation | Defines incident roles, playbooks, escalation, reporting and evidence handling |
| 5.26 | Response to information security incidents | Supports controlled containment, eradication, recovery and communications |
| 8.15 | Logging | Preserves evidence for exploitation assessment and incident reconstruction |
| 8.16 | Monitoring activities | Detects exploitation signals and supports active exploitation decisions |
In Zenith Controls: The Cross-Compliance Guide, Clarysec maps ISO/IEC 27002:2022 control 8.8, Management of technical vulnerabilities, as a preventive control supporting confidentiality, integrity and availability. Its attributes align to Identify and Protect cybersecurity concepts, with threat and vulnerability management as the operational capability.
That framing matters. CRA reporting is not only about notifying authorities. It is about proving that a preventive vulnerability management capability existed before the report arrived.
Build the operating model around CVD, SBOM and the reporting clock
A credible CRA vulnerability workflow starts before a researcher ever contacts you. It starts with the ability to receive vulnerability reports, validate them, identify affected components, assess exploitation, coordinate mitigation, communicate with users and preserve evidence.
The first building block is a public vulnerability reporting channel. Clarysec’s Coordinated Vulnerability Disclosure Policy, Implementation Requirements clause 6.1, states:
Public Disclosure Channels: The organization shall maintain a clear channel for vulnerability reporting, such as a dedicated security contact email address (for example, security@company.com) or a web form. This information shall be published on the company website security page together with the organization’s PGP public key to enable encrypted submissions.
This solves a common audit failure. Many companies say they accept vulnerability reports, but the reporting path is hidden, unmanaged, or routed through a general support queue. Under CRA conditions, the reporting channel becomes the trigger point for legal awareness, severity assessment and evidence capture.
The second building block is triage. The Coordinated Vulnerability Disclosure Policy, Implementation Requirements clause 6.4, states:
Triage and Acknowledgement: Upon receipt of a report, the VRT shall record it and send an acknowledgement to the reporter within 2 business days, assigning a tracking reference. The VRT shall perform a preliminary severity assessment, for example using CVSS scoring, and validate the issue, including with support from IT and development teams where necessary, within a target timeframe of 5 business days. Critical vulnerabilities, such as those enabling remote code execution or a major data breach, shall be expedited.
For CRA readiness, that triage record should be extended with fields that support the legal reporting decision:
| CRA triage field | Why it matters | Evidence owner |
|---|---|---|
| Active exploitation status | Determines whether CRA vulnerability reporting may apply | Vulnerability Response Team |
| Product and version affected | Links the issue to products with digital elements and customer impact | Product Security |
| SBOM dependency match | Confirms whether affected components exist in released builds | Engineering or DevSecOps |
| Severe product incident indicator | Separates vulnerability handling from product security incident reporting | Security Operations |
| Regulatory notification decision | Records whether CRA, NIS2, DORA, GDPR or contract notice applies | Legal, CISO and Compliance |
The third building block is SBOM discipline. Clarysec’s Secure Development Policy, Governance Requirements clause 5.4, states:
The use of open-source or third-party code must be approved, tracked, and validated through: 5.4.1 Software Composition Analysis (SCA) 5.4.2 License review (GPL, MIT, BSD, etc.) 5.4.3 Known vulnerability scanning (CVEs, OSS Index, etc.)
For smaller organizations, Clarysec’s Application Security Requirements Policy - SME, Policy Implementation Requirements clause 6.4.2, sets the same expectation in practical form:
A record of each external component used must be maintained by the developer or IT provider, including:
That component record becomes the minimum evidence set for SBOM-driven vulnerability response. It should connect component name, version, source, supplier or repository, license, product version, build date and vulnerability scan status. When a CVE, researcher report or supplier notice arrives, your team should be able to answer within hours: “Which released products contain this component?”
Map CRA, NIS2, DORA and GDPR into one notification decision matrix
The Cyber Resilience Act will not operate in isolation. A single product vulnerability may trigger CRA reporting, NIS2 incident assessment, DORA customer evidence obligations, GDPR breach assessment and contractual notice duties.
NIS2 Article 21 requires essential and important entities to implement appropriate technical, operational and organizational measures. Those measures include risk analysis, incident handling, business continuity, supply chain security, secure acquisition, development and maintenance, vulnerability handling and disclosure, effectiveness assessment, cyber hygiene, cryptography, HR security, access control, asset management, MFA and secured communications.
NIS2 Article 23 sets a staged incident reporting model: early warning within 24 hours of becoming aware, incident notification within 72 hours, intermediate updates if requested and a final report no later than one month after incident notification. NIS2 Article 20 also creates management body accountability for approving and overseeing cybersecurity risk-management measures.
DORA applies from 17 January 2025 and creates a uniform EU digital operational resilience framework for financial entities. For SaaS providers, software vendors and ICT suppliers, DORA often appears through customer contracts. Your financial-sector customer may be the regulated DORA entity, but your vulnerability handling, SBOM evidence, incident support, audit rights and notification commitments may be necessary for that customer to meet its own obligations.
GDPR adds another branch. If the vulnerability or incident causes accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to personal data, a personal data breach assessment is required. GDPR Article 5 also includes integrity, confidentiality and accountability, meaning the organization must be able to demonstrate its decision-making.
Clarysec’s Incident Response Policy, Policy Implementation Requirements clause 6.4.1, already supports this multi-regime assessment:
If an incident results in confirmed or likely exposure of personal data or other regulated data, Legal and the DPO must assess the applicability of: 6.4.1.1 GDPR Article 33 (72-hour notification to the supervisory authority) 6.4.1.2 GDPR Article 34 (notification to data subjects, where high risk applies) 6.4.1.3 NIS2 Article 23 (notification within 24 hours of becoming aware of the incident) 6.4.1.4 DORA Article 17 (reporting of severe ICT-related incidents)
For CRA readiness, extend this playbook to include CRA Article 14 reporting assessment for actively exploited vulnerabilities and severe incidents affecting product security.
A unified decision matrix prevents teams from running separate, inconsistent reporting playbooks:
| Trigger question | CRA | NIS2 | DORA | GDPR | Evidence |
|---|---|---|---|---|---|
| Is the vulnerability actively exploited in a product with digital elements? | Assess CRA Article 14 reporting | May support significant incident assessment | May support ICT incident or threat classification | Assess if personal data affected | Triage record, threat intelligence, logs |
| Has product security or service provision been severely disrupted? | Assess severe incident reporting | Assess significant incident | Assess major ICT-related incident impact | Usually only if personal data breach occurred | Incident timeline, impact analysis |
| Are financial-sector customers affected? | Product reporting may still apply | Depends on entity scope | Customer may need DORA evidence | Depends on data roles | Customer list, contracts, DORA annex |
| Was personal data exposed or accessed? | May affect severity and user notice | May affect impact assessment | May affect client impact | Breach assessment required | DPO assessment, forensic evidence |
| Is a supplier component involved? | Manufacturer still needs product impact view | Supply chain risk evidence | ICT third-party evidence may be needed | Processor or controller analysis | SBOM, supplier notice, contract clause |
For SMEs, Clarysec’s Incident Response Policy - SME, Governance Requirements clause 5.3.2, gives the same principle in simpler form:
Response timelines, including data recovery and notification obligations, must be documented and aligned with legal requirements, such as the GDPR 72-hour personal data breach notification requirement.
CRA readiness simply expands that principle from personal data breach notification to product vulnerability and product security incident reporting.
Supplier evidence is now product security evidence
Many CRA-relevant vulnerabilities will originate outside your codebase. They may come from open-source packages, firmware modules, SDKs, hosted APIs, build tools, cloud services, subcontracted components or upstream libraries. That makes supplier governance central to CRA readiness.
ISO 27001:2022 clause 8.1 requires organizations to control externally provided processes, products or services relevant to the ISMS. ISO/IEC 27002:2022 control 5.21, Managing information security in the ICT supply chain, provides the control anchor.
In Zenith Controls, Clarysec maps control 5.21 as a preventive control supporting confidentiality, integrity and availability. Its operational capability is supplier relationships security, and its domains include governance, ecosystem and protection. The point is simple: supplier controls are not procurement paperwork. They are ecosystem protection controls.
Clarysec’s Third-Party and Supplier Security Policy - SME, Governance Requirements clause 5.3, sets the contractual basis:
Contracts must include mandatory clauses covering:
For enterprise programs, the Zenith Blueprint: An Auditor’s 30-Step Roadmap, Controls in Action phase, Step 23, Organizational controls 5.19 to 5.37, explains ISO/IEC 27002:2022 control 5.20, Addressing information security within supplier agreements:
Trust, when it comes to suppliers, cannot rest on assumptions. It must be codified.
For CRA readiness, supplier agreements should include product-security clauses that support fast vulnerability response:
| Supplier clause | CRA relevance | Evidence to request |
|---|---|---|
| Vulnerability notification | Ensures upstream suppliers alert you quickly when their component is affected | Supplier vulnerability notice records and SLA |
| SBOM or component inventory | Supports impact assessment across product versions | SBOM, component list or attestation |
| Secure update support | Enables corrective measures and customer guidance | Patch release notes and remediation plan |
| Disclosure coordination | Prevents inconsistent public messaging and premature disclosure | CVD coordination log |
| Incident assistance | Supports forensic analysis, user impact assessment and reporting | Support records and investigation notes |
| Audit and assurance rights | Helps satisfy customers, regulators and internal audit | Audit reports and control attestations |
DORA reinforces the same direction. Financial entities must manage ICT third-party risk, maintain registers of ICT service contracts, assess criticality, perform due diligence, manage concentration risk, define contractual safeguards, secure audit rights and plan exits. If you sell software or ICT services to financial entities, expect customers to ask whether your vulnerability reporting and SBOM process can support their DORA incident, resilience and third-party evidence needs.
The Clarysec CRA readiness workflow
Clarysec helps clients operationalize CRA reporting inside an ISO 27001:2022-aligned ISMS through a practical workflow.
1. Add CRA obligations to the ISMS requirements register
Start with ISO 27001:2022 clauses 4.1 to 4.4. Update organizational context, interested parties and scope to include products with digital elements, EU market exposure, users, importers, distributors, regulators, CSIRTs, suppliers and regulated customers.
Create requirements register entries for CRA vulnerability reporting, CRA severe product security incident reporting, NIS2 incident notification, DORA customer support obligations, GDPR personal data breach assessment, contractual incident notice, CVD commitments and researcher communications.
This gives auditors a traceable path from external obligation to internal control.
2. Create a product vulnerability intake form
Base the intake form on the Coordinated Vulnerability Disclosure Policy. It should capture reporter identity, secure contact details, product version, module, environment, proof of concept, reproduction steps, exploitation status, potential data exposure, service impact, SBOM component match, CVSS or equivalent severity, owner, tracking reference and regulatory checkpoint.
The form should automatically create a ticket in the vulnerability response queue. It should also start a notification decision timer, even if the final answer is “not reportable.”
3. Connect SBOM data to releases
For each released product version, maintain an SBOM or equivalent component inventory. The minimum useful evidence includes component name, version, source, license, supplier or repository, product version, build date and vulnerability scan status.
The Secure Development Policy and Application Security Requirements Policy - SME provide the policy basis for SCA, component review and external component records.
4. Preserve evidence from day one
Every CRA-relevant vulnerability ticket should retain:
- Original report
- Acknowledgement timestamp
- Triage notes
- CVSS or equivalent severity reasoning
- SBOM match results
- Exploitation assessment
- Logs, indicators and forensic snapshots
- Supplier communications
- Risk acceptance, if mitigation is delayed
- Patch plan, release notes and testing evidence
- Customer and authority notification decisions
- Final report inputs and lessons learned
This aligns with ISO 27001:2022 clause 8.1, which requires documented information sufficient to evidence that processes operated as planned, and clauses 8.2 and 8.3, which require documented risk assessment and risk treatment results.
5. Test with a realistic dependency scenario
Run a tabletop exercise using a simulated actively exploited dependency vulnerability. Include engineering, security, legal, privacy, product, communications, supplier management and customer-facing teams. The test should prove that your organization can identify affected versions, assess exploitation, make a notification decision, contact suppliers, prepare user guidance and preserve evidence.
How auditors will test CRA vulnerability reporting readiness
A CRA readiness review will rarely be limited to a CRA checklist. Different auditors will test the same evidence through different frameworks.
In Zenith Controls, Clarysec maps ISO/IEC 27002:2022 control 5.24, Information security incident management planning and preparation, as a corrective control supporting confidentiality, integrity and availability. It aligns to Respond and Recover, with governance and information security event management as operational capabilities.
That control is the bridge between vulnerability discovery and regulatory reporting.
| Auditor background | What they will ask | Evidence that satisfies the question |
|---|---|---|
| ISO 27001:2022 auditor | Is vulnerability reporting integrated into risk assessment, treatment, Annex A controls and documented ISMS processes? | ISMS scope, risk register, SoA, vulnerability procedure, CVD policy, incident records, management review |
| ISO/IEC 27002:2022 control assessor | Are controls 8.8, 8.25, 5.21, 5.24, 5.20 and related controls implemented consistently? | Patch logs, SBOMs, secure SDLC gates, supplier clauses, incident playbooks, evidence records |
| NIS2 authority or assessor | Are Article 20 governance, Article 21 measures and Article 23 reporting procedures operational? | Board minutes, risk measures, incident procedures, notification records, supply chain evidence |
| DORA-oriented auditor | Can ICT incidents, vulnerabilities, third-party dependencies, testing and customer communications support financial-sector resilience obligations? | ICT dependency inventory, incident classifications, testing records, supplier register, contract evidence |
| GDPR reviewer | Did the organization assess whether the vulnerability created a personal data breach and document accountability? | Breach assessment, DPO notes, Article 33 and 34 decision record, data flow map, forensic findings |
| NIST CSF 2.0 assessor | Can the organization govern, identify, protect, detect, respond and recover through one risk-based model? | Current and Target Profiles, supplier risk program, detection metrics, response and recovery evidence |
NIST CSF 2.0 is especially useful as a board-level communication layer. Its GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND and RECOVER functions help explain how product vulnerability reporting fits into enterprise cybersecurity governance rather than sitting as an engineering exception.
Common CRA readiness failures to fix before 2026
Clarysec sees the same gaps repeatedly.
The first is CVD without reporting. A company has a security email address or security.txt file, but no internal path from researcher report to legal notification assessment.
The second is SBOM without ownership. Engineering can generate an SBOM during build, but nobody owns accuracy for released products or explains how SBOM findings feed vulnerability response.
The third is an ISO certificate without product scope. The ISMS covers corporate IT and SaaS operations, but not embedded software, firmware, product update infrastructure, build pipelines or vulnerability disclosure.
The fourth is supplier contracts without vulnerability clauses. Procurement requires confidentiality and data protection, but not vulnerability notification, component transparency, incident assistance, coordinated disclosure or audit evidence.
The fifth is incident response without product vulnerability logic. The incident plan covers ransomware, phishing and personal data breaches, but not actively exploited product vulnerabilities where customer systems may be at risk before the manufacturer’s own environment is compromised.
The sixth is DORA customer evidence handled manually. Sales or customer success responds to financial-sector questionnaires case by case, while security lacks a standard evidence pack showing vulnerability handling, SBOM governance, incident support and supplier controls.
Each gap is fixable. Each becomes expensive if discovered during a live vulnerability.
A 90-day CRA vulnerability reporting readiness checklist
Use the next 90 days to establish a defensible foundation:
- Identify products with digital elements placed on or made available to the EU market.
- Update ISMS scope and interested-party analysis to include CRA stakeholders.
- Add CRA Article 14 reporting assessment to the legal and regulatory requirements register.
- Publish and monitor a secure vulnerability reporting channel.
- Create a Vulnerability Response Team with legal, product, engineering, security and communications roles.
- Maintain SBOMs or component inventories for released product versions.
- Link SCA results to vulnerability tickets and product releases.
- Add active exploitation and severe product incident criteria to triage forms.
- Create a combined CRA, NIS2, DORA, GDPR and contract notification decision matrix.
- Update supplier contracts with vulnerability notice, SBOM, incident assistance and disclosure coordination clauses.
- Maintain patch logs and remediation evidence.
- Test the workflow with a simulated actively exploited dependency vulnerability.
- Present results to management with gaps, residual risks and remediation owners.
- Add the evidence pack to internal audit and management review.
Clarysec’s Vulnerability and Patch Management Policy - SME, Policy Implementation Requirements clause 6.2.1, supports the monitoring foundation:
The IT function must monitor vulnerabilities using:
The same policy, Governance Requirements clause 5.4.1, adds the audit trail:
A patch log must be maintained and reviewed during audits and incident response activities
That patch log may become one of the most important artifacts in a CRA final report. It proves discovery, prioritization, remediation, testing and closure.
Make September 2026 boring
The best CRA reporting event is not easy because the vulnerability is simple. It is easy because the organization has already rehearsed the workflow.
Before September 2026, Clarysec can help you turn vulnerability reporting into an audit-ready system by mapping your current ISO 27001:2022 ISMS, CVD process, SBOM capability, supplier clauses and incident response playbooks against CRA, NIS2, DORA, GDPR and NIST CSF expectations.
Start with a focused CRA vulnerability reporting readiness assessment. Clarysec will review your policies, SBOM evidence, supplier contracts, vulnerability tickets, incident playbooks and audit trail. Then we will use Zenith Blueprint and Zenith Controls to build a practical remediation roadmap, not a theoretical compliance binder.
If you already use Clarysec policies, we will tune them for CRA reporting. If you do not, we can help implement the right policy set, including Coordinated Vulnerability Disclosure Policy, Secure Development Policy, Incident Response Policy, Vulnerability and Patch Management Policy - SME, Application Security Requirements Policy - SME and Third-Party and Supplier Security Policy - SME where appropriate.
September 2026 is close enough for planning and far enough for disciplined preparation. The organizations that act now will not be asking, “Who owns this vulnerability?” during the first 24 hours. They will already have the answer, the evidence and the reporting path.
Contact Clarysec to schedule a CRA vulnerability reporting readiness assessment and turn regulatory complexity into a defensible product security advantage.
Frequently Asked Questions
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
