The EU Cyber Resilience Act (Regulation (EU) 2024/2847, hereinafter "CRA") was published in the Official Journal on November 20, 2024, and is already in force.
Original text: REGULATION (EU) 2024/2847 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL
of 23 October 2024
Its obligations apply in phases, however, and the first to bite in practice is the Article 14 reporting obligation, which applies from September 11, 2026. The main body of the regulation (conformity with security requirements, CE marking, and so on) applies from December 11, 2027, but the vulnerability and incident reporting obligation alone starts more than a year earlier.
In other words, for companies that supply software to the EU market, just under two months remain to prepare as of this writing. This article lays out, based on the text of the CRA, what must be reported, by when, and to whom, and what you should be preparing now.
Is Your Company in Scope at All?
The CRA applies to "products with digital elements," which broadly covers software and hardware made available on the EU market in the course of a commercial activity (Articles 2 and 3).
Paid packaged software and mobile apps are obvious examples, but even free distribution can be treated as a "commercial activity" if there is an intent to monetize.
Cloud services deserve particular attention. SaaS as such generally falls under the NIS2 Directive rather than the CRA, but remote data processing that is essential to a product's functions is within the CRA's scope (Article 3(2), Recitals (11) and (12)).
For example, if a mobile app cannot function without your own APIs or backend, that backend is treated as part of the product. Concluding on the spot that "we're a cloud company, so the CRA doesn't apply to us" is risky.
The "manufacturer" that bears the reporting obligation is any company that places a product on the market under its own name or trademark (Article 3(13)). A Japanese company with no establishment in the EU is still covered if it supplies products to the EU market.
Article 14: Two Stages Plus a Final Report
The reporting obligation under Article 14 covers two broad categories of events.
The first is an "actively exploited vulnerability." This means a vulnerability for which there is reliable evidence that a malicious actor has actually exploited it (Article 3(42)). Discoveries made by good-faith security researchers for testing or reporting purposes are not subject to this mandatory reporting (Recital (68)).
The second is a "severe incident having an impact on the security of the product." Article 14(5) defines "severe": (a) the incident negatively affects, or is capable of negatively affecting, the availability, authenticity, integrity, or confidentiality of sensitive or important data or functions, or (b) it has led, or is capable of leading, to the introduction or execution of malicious code in the product or in the user's systems. Recital (68) gives the example of an attacker injecting malware into the manufacturer's release channel, in other words a supply chain attack.
For both categories, the reporting timeline follows the same structure.
- Early warning
Deadline: Within 24 hours of becoming aware
Content: Minimal information, such as whether malicious activity is suspected and the Member States where the product is available - Notification
Deadline: Within 72 hours of becoming aware
Content: Nature of the event, initial assessment, corrective measures taken or planned, mitigations users can apply, and so on - Final report
Deadline: Vulnerabilities within 14 days of a corrective or mitigating measure being made available; incidents within one month of the notification
Content: Detailed description, severity and impact, root cause, and measures taken or under way
The clock starts when the manufacturer "becomes aware." That is not the moment the breach occurs, but neither does the clock pause while a detection sits waiting for an executive decision. Given weekends, holidays, and time zones, the 24-hour deadline effectively demands a setup in which the reporting process is already moving on the same day the issue is detected.
Where to Report
Reports go through the single reporting platform operated by ENISA (the European Union Agency for Cybersecurity), which delivers them simultaneously to the competent CSIRT (the one designated as coordinator) and to ENISA (Article 14(1) and (3), Article 16).
Article 14(7) determines which Member State's CSIRT you report to. If you have your main establishment in the EU (the place where cybersecurity decisions are predominantly taken), it is that Member State. If you have no establishment in the EU, the order is: (1) the Member State of the authorised representative handling the largest number of your products, then (2) the importer's Member State, then (3) the distributor's Member State, then (4) the Member State with the largest number of users.
For a Japanese company, working this out only after an incident starts will almost certainly blow the 24-hour deadline, so you need to settle during peacetime exactly where your reports go.
It Doesn't End with the Authorities: The Duty to Inform Users
Article 14(8) requires a manufacturer that becomes aware of an actively exploited vulnerability or severe incident to inform affected users (and, where appropriate, all users) and to tell them about mitigations and corrective measures they can take. Note that if the manufacturer fails to do so in a timely manner, the CSIRT may inform users itself. In other words, staying silent does not keep the matter private; it can become public through the authorities.
Penalties for Non-Compliance
Under Article 64, non-compliance with the obligations in Articles 13 and 14 or the essential requirements in Annex I can draw fines of up to EUR 15 million or 2.5% of worldwide annual turnover, whichever is higher. Other breaches carry fines of up to EUR 10 million or 2%, and supplying incorrect or incomplete information to authorities up to EUR 5 million or 1%. Micro and small enterprises are not fined for missing the 24-hour early warning deadline (Recital (120)).
More painful than any fine is the possibility of market surveillance authorities ordering products withdrawn or recalled. For many companies, being shut out of the EU market hurts more than a monetary penalty.
How It Interacts with Existing Obligations: First Pin Down Your GDPR Role
Keep in mind that CRA reporting is layered on top of existing obligations. And when personal data is involved, how you need to act depends heavily on your role under the GDPR, that is, whether you are a controller or a processor. If that is still unclear when an incident hits, you will get the recipient and the deadline wrong.
- When your company is a controller
The typical case is a company that provides apps or services directly to consumers and itself decides the purposes and means of processing end users' personal data.In this case, once you become aware of a personal data breach, you are directly obligated under GDPR Article 33 to report it to the supervisory authority within 72 hours as a rule. And if the breach is likely to result in a high risk to individuals' rights and freedoms, Article 34 also requires you to notify the data subjects themselves. - When your company is a processorThis is the B2B SaaS or software case: you process the personal data of a customer company's employees or customers on that company's (the controller's) instructions.Here, the 72-hour obligation to report to the supervisory authority rests with the customer as controller. Your statutory duty as processor, under Article 33(2), is to notify the controller without undue delay after becoming aware of the breach.That might read as "the 72 hours don't apply to us," but practice is not so forgiving. The DPAs (data processing agreements) you have signed with customers often set a specific notification deadline (24 hours, 48 hours, and so on) that is shorter than the statutory "without undue delay." Because customers need to protect their own 72-hour window, the timing they demand of processors tends to be stricter than the legal baseline.The starting point for incident response as a processor is to take stock of the notification clauses in every DPA you have signed and build the shortest contractual deadline into your runbook as your effective SLA.
It is also common for the same company to be both controller and processor depending on the product line or function (for example, a processor for its core B2B SaaS, but a controller for its own marketing and billing data). Because the procedure branches depending on the role under which the compromised data was handled, you need to tie each role to your data mapping in advance.
Crucially, the CRA's obligations arise independently of this GDPR role. Because the Article 14 reporting obligation falls directly on the "manufacturer," the reasoning that "we're a processor, so our customers deal with the authorities" does not hold under the CRA. Even as a processor, if there is a severe incident affecting the security of your product or an actively exploited vulnerability, the obligation to report to the CSIRT and ENISA is yours.
As a result, a single incident can set off several reporting triggers in parallel.
- CRA Article 14: impact on product security → early warning, notification, and final report to the CSIRT/ENISA at 24 hours, 72 hours, and after (a manufacturer obligation regardless of GDPR role)
- GDPR Article 33: personal data breach → as controller, report to the supervisory authority within 72 hours; as processor, notify the controller without undue delay (plus any DPA deadline)
- GDPR Article 34: high-risk personal data breach → as controller, notify the data subjects
- NIS2 Directive: reporting obligations if your company is an entity in scope of NIS2, such as a cloud service provider
Each has a different recipient, deadline, and format. Unless your incident response runbook includes a checkpoint for deciding which reporting obligation, under which law or contract, a given event triggers, your responders will be confused when it counts.
What to Prepare Now
Working backward from the text, these are the five things you should have in place by September 11 at a minimum.
- Confirm where you reportFollowing the Article 14(7) rules above, identify which Member State's CSIRT is your reporting contact and write it into your runbook.
- Build the CRA definitions into your incident classification criteriaAdd criteria to your existing incident response process for deciding whether an event is an "actively exploited vulnerability" or a "severe incident" under Article 14(5), and make sure everyone, including the people with decision-making authority, understands that the 24-hour timer starts the moment an event qualifies. The key is an escalation path that keeps decisions moving late at night and on holidays.
- Third, prepare report templates in advanceThere is only so much you can write within 24 hours. Templating the items required at each stage (early warning, 72-hour notification, and final report; Article 14(2) and (4)) means you will not have to start an incident by debating what to write.
- Plan user notificationsDecide how you will identify affected users, which channels you will use (in-product notices, email, website posts), and the approval flow for public statements. Since these may overlap with GDPR Article 34 notifications to data subjects, it is realistic to involve legal and PR from the outset.
- Clarify your GDPR roles and take stock of your DPAs Tie your data mapping to a clear determination of whether you are controller or processor for each product and feature, and list the breach notification clauses (deadlines, methods, and required content) in the DPAs you have signed with customers. Laying the CRA's 24 hours, the GDPR's 72 hours, and your DPA deadlines on a single timeline makes it concrete what has to move in parallel in the first few hours of an incident.
Looking ahead to full application in December 2027, you will also need to address the vulnerability handling process as a whole, beyond the reporting framework: a coordinated vulnerability disclosure policy, SBOMs, a support period of at least five years as a rule, free security updates, a single point of contact for users, and more (Article 13 and Annex I). Reporting compliance is best seen as the first step within that larger picture.
Conclusion
Judged by the "72 hours" figure alone, the CRA's reporting obligation looks like the GDPR's, but the substance differs considerably: there is a 24-hour early warning before it, the subject is a product security event rather than a personal data breach, the recipient is the CSIRT/ENISA rather than a data protection authority, and the obligation falls directly on the manufacturer regardless of controller or processor status. You cannot simply reuse your GDPR setup as is.
The deadline is close, but none of the five items above requires a major systems investment. They mostly involve additions to your existing incident response process and communicating them to the people involved. We recommend starting by confirming whether your products fall under the CRA and identifying the CSIRT you will report to.
That's Where Incident Lake Comes In
As we have seen, incident response in the CRA era is judged not only on how fast you respond but on your ability to keep records and stay ready to report within the deadline.
Issuing an early warning within 24 hours requires a timeline recorded from the moment of awareness. And if the root cause and the measures taken or under way that the final report demands have to be dug out afterward from information scattered across Slack and various tickets during the response, you will lose the race against the deadline. All the more so if customer notifications under your GDPR DPAs are running in parallel.
Incident Lake, the agentic AI for incident management that we are building, is designed precisely for this challenge. It consolidates in-flight response information scattered across Slack conversations, Jira, and other existing tools into a single incident record, and keeps a chronological trail of the timeline, severity decisions and their change history, response tasks, and blast radius.
Procedures discussed in this article, such as deciding whether an event is a severe incident under the CRA and managing the overlapping 24-hour, 72-hour, and one-month deadlines, can be built in as SOP checklists so nothing slips through, and because report drafts can be generated from the accumulated record, the documentation burden of the final report drops substantially.
The more you use it, the more it accumulates your organization's own decision criteria and past lessons, and the more accurate its AI assistance becomes.
If you want to turn CRA reporting compliance into a system rather than ad hoc manual work, take a look at Incident Lake.
This article provides general information based on the text of Regulation (EU) 2024/2847 (as published in the Official Journal on November 20, 2024) and does not constitute legal advice. For decisions about how it applies to your specific situation, consult a lawyer or other professional versed in EU law.