Incident Response Systems That Software Companies with Users in the EU Must Have in Place by September 11, 2026

The EU’s “Cyber Resilience Act (Regulation (EU) 2024/2847; hereinafter “CRA”)” was published in the Official Journal on November 20, 2024, and has already entered into force.
Original text: REGULATION (EU) 2024/2847 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL

dated October 23, 2024

However, the obligations will be implemented in phases, and in practice, the first to take effect will be the reporting obligation under Article 14, which applies starting September 11, 2026. While the main provisions (such as compliance with security requirements and CE marking) will take effect on December 11, 2027, the reporting obligation for vulnerabilities and incidents will begin more than a year earlier.

In other words, for companies supplying software to the EU market, there are just under two months left to prepare as of the time of writing. In this article, we will outline what needs to be reported, by when, and to whom, based on the provisions of the CRA, as well as what steps companies should take to prepare starting now.

Is our company even eligible in the first place?

The scope of the CRA covers “products with digital elements,” which broadly includes software and hardware offered for commercial purposes in the EU market (Articles 2 and 3).

Not only paid software packages and mobile apps, but even free distributions can be considered “commercial activities” if there is an intent to generate revenue.

One point to note is the treatment of cloud services. While SaaS itself generally falls under the scope of the NIS 2 Directive rather than the CRA, remote data processing that is essential to a product’s functionality is included within the scope of the CRA (Article 3(2), Preamble (11) and (12)).

For example, if a mobile app cannot function without the company’s own APIs or backend, that backend component is also treated as part of the product. It’s dangerous to jump to the conclusion that “since we use the cloud, the CRA doesn’t apply to us.”

Furthermore, the term “manufacturer,” which is subject to reporting obligations, refers to companies that place products on the market under their own brand (Article 3(13)). Even Japanese companies without a presence within the EU are subject to these obligations if they supply products to the EU market.

Article 14: A Three-Step Process Consisting of Two Stages and a Final Report

The reporting obligations set forth in Article 14 apply to two broad categories of events.

The first is an “actively exploited vulnerability.” This refers to cases where there is credible evidence that a malicious third party has actually exploited the vulnerability (Article 3(42)). Discoveries made by security researchers acting in good faith for the purpose of verification or reporting are not subject to this mandatory reporting requirement (Preamble (68)).

The second category is “severe incidents that affect product security.” Article 14(5) defines the criteria for “severe,” which includes cases where (a) the availability, authenticity, integrity, or confidentiality of sensitive or critical data or functions is compromised (or has the potential to be compromised), or (b) the introduction or execution of malicious code into the product or the user’s system has occurred (or has the potential to occur).Preamble (68) provides examples such as cases where an attacker has infiltrated malware into a manufacturer’s release channel—that is, supply chain attacks.

The reporting timelines for both events follow the same structure.

The starting point is “the moment the manufacturer becomes aware.” While this is not the moment the infringement occurs, it does not mean that the clock stops while the company waits for management to make a decision after detecting the infringement internally. Given holidays and time zone differences, it is best to interpret the 24-hour deadline as effectively requiring a system in which “the reporting process begins on the very same day the infringement is detected.”

Where should I report this?

Reports are submitted via a single reporting platform operated by ENISA (the European Union Agency for Cybersecurity), ensuring that they are simultaneously received by the responsible CSIRT (the CSIRT designated as the coordinator) and ENISA (Article 14(1)(3) and Article 16).

Article 14(7) specifies which Member State’s CSIRT to report to. If the company has its principal place of business (the location where cybersecurity-related decisions are primarily made) within the EU, the report should be made to that Member State. If the company has no place of business within the EU, the reporting Member State is determined in the following order: (1) the country where the authorized representative handling the largest number of products is located; (2) the country where the importer is located; (3) the country where the distributor is located; and (4) the Member State with the largest number of users.

In the case of Japanese companies, if they wait until an emergency arises to make this determination, it will certainly take more than 24 hours; therefore, they need to determine in advance, during normal times, “who their reporting authority is.”

It Doesn't End with Reporting to the Authorities: The Obligation to Notify Users

Article 14(8) requires manufacturers who become aware of exploited vulnerabilities or serious incidents to notify affected users (and all users, if necessary) and provide guidance on mitigation and corrective measures that users can take. It is important to note that the provision explicitly states that if a manufacturer fails to do so in a timely manner, the CSIRT may provide this information to users on its behalf. This means that even if a company remains silent, the information may still become public through the authorities.

In the event of a violation

Under Article 64, violations of the obligations set forth in Articles 13 and 14 and of the essential requirements in Annex I may be subject to a fine of up to 15 million euros or 2.5% of global annual turnover, whichever is higher.Violations of other obligations are subject to fines of up to 10 million euros or 2%, while providing false or incomplete information to the authorities is subject to fines of up to 5 million euros or 1%. Furthermore, micro and small enterprises are exempt from fines for failing to meet the 24-hour early warning deadline (Preamble (120)).

Even more effective than fines is the possibility of market regulators ordering a sales suspension or product recall. Being shut out of the EU market is a greater blow to many companies than financial penalties.

Relationship to Existing Reporting Obligations: First, Determine Your “Status” Under the GDPR

It is important to note that CRA reporting is an “add-on” to existing obligations. Furthermore, in cases involving personal data breaches, how a company responds depends largely on its status under the GDPR—that is , whether it is a controller or a processor. If this distinction remains unclear when an incident occurs, the company may mistakenly identify the correct recipient or miss the reporting deadline.

• Cases Where the Company Acts as the Controller
  A typical example is when a company directly provides apps or services to consumers and determines the purposes and means of processing end users’ personal data on its own.

  In this case, if your company becomes aware of a personal data breach, it is directly obligated to report the breach to the supervisory authority within 72 hours, in principle, pursuant to Article 33 of the GDPR. Furthermore, if the breach is likely to result in a high risk to the rights and freedoms of individuals, notification to the data subjects themselves is also required under Article 34.

• Cases Where the Company Acts as a Processor

  This refers to cases where B2B SaaS or software processes the personal data of employees or customers of client companies (i.e., administrators) based on instructions from those companies.

  In this case, the obligation to report to the supervisory authority within 72 hours rests with the controller (the client), while the company’s legal obligation as the processor is to notify the controller without undue delay upon becoming aware of the breach, in accordance with Article 33(2).

  It might seem like “the 72-hour rule doesn’t apply to us,” but in practice, things aren’t that simple. The DPAs (Data Processing Agreements) we enter into with our clients often specify concrete notification deadlines (such as 24 hours or 48 hours) that are shorter than the statutory requirement of “without undue delay.” Consequently, in order for clients to meet their own 72-hour deadlines, the time requirements they impose on data processors tend to be stricter than the statutory standards.

  The starting point for incident response as a data processor is to review the notification provisions in the DPA your company has entered into and incorporate the shortest contract term into your procedures as your de facto SLA.

It is not uncommon for the same company to act as both a controller and a processor depending on the product line or function (e.g., the parent company of a B2B SaaS provider acts as a processor, while its in-house marketing and billing departments act as controllers). Since the procedures differ depending on which role was involved when the data was compromised, it is necessary to link these roles during the data mapping phase.

It is also important to note that the obligations under the CRA arise independently of this status under the GDPR. Since the reporting obligations under Article 14 of the CRA apply directly to “manufacturers,” the reasoning that “we are a processor, so our customers will handle communications with the authorities” does not hold under the CRA . Even as a processor, if there is a serious incident affecting the security of your own products or a vulnerability that is being exploited, your company bears the obligation to report it to the CSIRT and ENISA.

As a result, multiple reporting triggers may occur simultaneously for a single incident.

• CRA Article 14: Impact on Product Security → 24-hour, 72-hour, and final reports to CSIRT/ENISA (obligation of the manufacturer regardless of their position)

• GDPR Article 33: Personal Data Breach → Data controllers must notify the supervisory authority within 72 hours; data processors must notify the data controller without undue delay (+ DPA contract deadline)

• GDPR Article 34: High-Risk Personal Data Breaches → Notification to Data Subjects by the Controller

• NIS2 Directive: Reporting Obligations for Entities That Qualify as NIS2-Covered Entities, Such as Cloud Service Providers

Since the reporting authorities, deadlines, and formats vary for each case, if you do not include a checkpoint in the incident response procedure manual to determine “which reporting obligation under which law or contract this incident falls under,” confusion is bound to arise on the front lines.

Preparations You Should Start Making Now

Based on the provisions of the law, here are the five items you should have in place by September 11 at the very least.

1. Determining the Reporting Line

   In accordance with the rule set forth in Article 14(7) above, we will identify which member country’s CSIRT serves as our company’s reporting contact and specify this in our procedures manual.

2. Incorporating the CRA Definition into Incident Classification Criteria

   Add criteria to the existing incident response process to determine whether an incident “constitutes an actively exploited vulnerability” or “qualifies as a severe incident under Article 14(5),” and ensure that everyone—including those with decision-making authority—is aware that a 24-hour timer begins running the moment an incident meets these criteria. Designing an escalation route that ensures decisions are made even late at night or on holidays is crucial.

3. Third, preparing the report template in advance

   The amount of information that can be compiled within 24 hours is limited. By creating templates for the required items in each of the early warning, 72-hour notification, and final report (Article 14(2)(4)), you can avoid having to start discussions in an emergency by asking, “What should we write?”

4. Procedure for User Notifications

   We will establish procedures for identifying affected users, determining notification methods (in-app notifications, email, and website postings), and establishing an approval process for public announcements. Since we must also anticipate cases where these procedures overlap with the GDPR’s requirement to notify data subjects (Article 34), it is practical to establish a system that involves the legal and public relations departments.

5. Clarifying Our Position Under the GDPR and Conducting a DPA Review

    By linking data mapping to clarify whether the company acts as a controller or processor for each product and feature, and by compiling a list of the breach notification provisions (notification deadlines, notification methods, and required information) in the DPAs already signed with customers, you can overlay the 24-hour deadline under the CRA, the 72-hour deadline under the GDPR, and the contractual deadlines specified in the DPAs onto a single timeline. This provides a clear picture of what actions need to be taken in parallel during the first few hours of an incident.

Furthermore, in preparation for full implementation in December 2027, in addition to the reporting framework, it will be necessary to address the overall vulnerability handling process (including a coordinated vulnerability disclosure policy, the development of SBOMs, the establishment of a support period of at least five years, the provision of free security updates, and the establishment of a single point of contact for users, etc.Article 13 and Annex I). It is advisable to view compliance with reporting obligations as the first step in this broader process.

In Closing

At first glance, the CRA’s reporting obligation appears similar to the GDPR’s requirement of “72 hours.” However, the details differ significantly: there is a 24-hour early warning period prior to the report; the reporting requirement applies to product security incidents rather than personal data breaches; reports are submitted to CSIRT/ENISA rather than data protection authorities; and the obligation falls directly on the manufacturer, regardless of whether they act as a controller or processor. Therefore, organizations cannot simply repurpose their existing GDPR compliance framework for this purpose.

Although the deadline is approaching, the five points listed above do not require major system investments; they primarily involve adding provisions to your existing incident response processes and ensuring that all relevant parties are informed. We recommend starting by confirming whether your company’s products are subject to the CRA and identifying the CSIRT to which you should report.

And so, Incident Lake

As we have seen so far, what is required in incident response following the CRA is not only the speed of the response itself but also the ability to “maintain a system capable of recording incidents and reporting them within the required timeframe.”

To issue an early warning within 24 hours, the timeline must be recorded from the moment the issue is identified. Furthermore, if we have to retroactively dig through information scattered across Slack and various ticket systems—such as the root cause analysis and descriptions of completed or ongoing countermeasures required for the final report—while the incident is still being addressed, we simply won’t be able to meet the deadline. This is especially true if customer notifications under the GDPR’s Data Protection Act (DPA) are happening simultaneously.

" Incident Lake," the Agentic AI platform we are developing that specializes in incident management, is a product designed specifically to address this challenge. It consolidates information on ongoing incidents—which is scattered across existing tools such as Slack conversations and Jira—into a single incident record, and maintains a chronological history of the timeline, severity assessments and their change history, response tasks, and scope of impact.

Procedures mentioned in this paper—such as “determining whether an event constitutes a severe incident under the CRA” and “managing multiple deadlines (24 hours, 72 hours, and one month)”—can be incorporated into an SOP checklist to prevent omissions in response efforts. Furthermore, since draft reports can be created based on accumulated records, this significantly reduces the documentation burden associated with preparing the final report.

It is designed so that, the more it is used, the more it accumulates organization-specific criteria and lessons learned from the past, thereby improving the accuracy of the AI-powered support.

If you’re looking to transform your CRA reporting compliance from a “stopgap, manual process” into a “system,” be sure to check out Incident Lake.

This article is intended to provide 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 specific applications of the regulation, please consult a professional, such as an attorney, who is knowledgeable about EU law.