[{"data":1,"prerenderedAt":14},["ShallowReactive",2],{"article:en:nis2-or-cra-which-incident-clock-runs-for-a-software-company-and-what-makes-an-incident-significant":3},{"locale":4,"slug":5,"title":6,"description":7,"published":8,"answer":9,"body":13},"en","nis2-or-cra-which-incident-clock-runs-for-a-software-company-and-what-makes-an-incident-significant","NIS2 or CRA: which incident clock runs for a software company, and what makes an incident 'significant'","Both laws give you 24 hours, 72 hours and a month, and both start the clock when you 'become aware'. Almost everything else differs: what triggers it, who receives it, on which platform, and what counts. NIS2 Article 23 and Implementing Regulation 2024\u002F2690 for the company that runs a cloud service; CRA Article 14 for the company that ships a product; both for the company that does both. The thresholds, criterion by criterion, and one procedure that satisfies the two.","2026-09-11",{"who":10,"when":11,"do":12},"A software company that runs a cloud or managed service under NIS2, ships a product under the CRA, or both; each law gives 24 hours, 72 hours and a month from becoming aware, but the trigger, the recipient, the platform and the thresholds differ.","The CRA clock has run since 11 September 2026 for an actively exploited vulnerability or a severe incident in a product; the NIS2 clock runs since the national transposition for a significant incident in the service, with Implementing Regulation 2024\u002F2690 setting the thresholds for cloud and managed services.","Write one procedure with two triggers and two recipients, the CSIRT for the CRA and the national authority for NIS2, and the same reasonable-degree-of-certainty test for becoming aware; the thresholds below say which incident starts which clock.","\nA software company that reads about the Cyber Resilience Act's 24-hour early warning and a company that reads about NIS2's 24-hour early warning are reading two different laws that chose the same numbers. Regulation (EU) 2024\u002F2847, the CRA, puts the duty on the manufacturer of a product with digital elements, in Article 14. Directive (EU) 2022\u002F2555, NIS2, puts it on essential and important entities, in Article 23, and Commission Implementing Regulation (EU) 2024\u002F2690 says, for cloud and other digital providers, what \"significant\" means. [Which law reaches a software company](\u002Farticles\u002Fcra-or-nis2-which-one-applies-to-a-software-company) is decided by what it supplies: a product the customer runs, or a service the customer accesses. This article is what happens after that decision, when something goes wrong: the two clocks side by side, the thresholds, and the one procedure that serves both.\n\n## Who is under which clock\n\n**CRA Article 14** applies to the manufacturer of a product with digital elements placed on the EU market, since 11 September 2026, whatever the company's size, including for products already on the market. The triggers are an actively exploited vulnerability in the product and a severe incident having an impact on the security of the product; [the two are defined here](\u002Farticles\u002Fwhat-you-have-to-report-under-the-cra-the-two-triggers-defined).\n\n**NIS2 Article 23** applies to an essential or important entity: a public or private entity \"of a type referred to in Annex I or II\" which is at least a medium-sized enterprise under Recommendation 2003\u002F361\u002FEC, that is, not micro or small, broadly 50 staff or more, or above EUR 10 million in both turnover and balance sheet, \"and which provide their services or carry out their activities within the Union\" (Article 2(1)). Cloud computing service providers are in Annex I under digital infrastructure, and Article 6(30) defines a cloud computing service as \"a digital service that enables on-demand administration and broad remote access to a scalable and elastic pool of shareable computing resources\". Article 2(2) lists the cases that apply regardless of size, among them DNS and TLD services, trust service providers, and sole providers of a service essential for critical societal or economic activities. The trigger is \"any incident that has a significant impact on the provision of their services\", a significant incident.\n\nA company that sells an installed client backed by its own cloud, or that sells the same functionality as software and as a service, can be under both: a manufacturer for the product, an entity for the service. The deciding questions are the two above, asked separately. [The NIS2 half is answered in writing by the scope tool](\u002Fnis2\u002Fscope), with the entity type, the size rule and the state's law.\n\n## The two clocks side by side\n\n| | CRA Article 14, the manufacturer | NIS2 Article 23, the entity |\n| --- | --- | --- |\n| Trigger | An actively exploited vulnerability in the product, or a severe incident affecting the product's security (14(1), 14(3)) | A significant incident affecting the provision of the entity's services (23(1), 23(3)) |\n| Recipient | The CSIRT designated as coordinator of the manufacturer's main-establishment state, and ENISA, simultaneously (14(7)) | The entity's national CSIRT or, where the state so decides, its competent authority (23(1), 23(4)) |\n| Channel | ENISA's single reporting platform, and nothing else counts (14(7), Article 16) | As the member state provides; no Union platform |\n| Early warning | Within 24 hours of becoming aware; for a vulnerability, the member states where the product is available (14(2)(a)); for an incident, whether unlawful or malicious acts are suspected (14(4)(a)) | Within 24 hours of becoming aware; whether unlawful or malicious acts are suspected, and whether there could be a cross-border impact (23(4)(a)) |\n| Notification | Within 72 hours: general information, an initial assessment, measures taken and available to users, sensitivity (14(2)(b), 14(4)(b)) | Within 72 hours: an update of the early warning, an initial assessment including severity and impact, indicators of compromise where available (23(4)(b)); 24 hours for trust service providers |\n| Intermediate report | On request of the coordinator (14(6)) | On request of the CSIRT or competent authority (23(4)(c)) |\n| Final report | Vulnerability: within 14 days after a corrective or mitigating measure is available (14(2)(c)); incident: within one month after the 72-hour notification (14(4)(c)) | Within one month after the 72-hour notification, with the same four contents plus cross-border impact; if the incident is still ongoing, a progress report then and a final report within one month of handling it (23(4)(d), (e)) |\n| Response to you | None promised | Initial feedback \"where possible within 24 hours of receiving the early warning\", guidance on request, and pointers to law enforcement where a crime is suspected (23(5)) |\n| Users and recipients | Inform impacted users, and where appropriate all users, of the vulnerability or incident and of measures they can take (14(8)) | Notify recipients of significant incidents likely to affect them, and of significant cyber threats and remedies (23(1), 23(2)) |\n| Liability | \"The mere act of notification ... shall not subject the notifying natural or legal person to increased liability\" (Article 17(4)) | \"The mere act of notification shall not subject the notifying entity to increased liability\" (23(1)) |\n\nTwo things are identical by design. The moment: both clocks run from \"becoming aware\", and the Commission's CRA guidance says it aligned its definition with recital 31 of the NIS2 implementing regulation, so [the same reasonable-degree-of-certainty test](\u002Farticles\u002Fwhen-does-the-cra-24-hour-clock-start-becoming-aware) starts both. And the final-report structure: one month after the 72-hour notification for an incident under either law. The one clock that differs in kind is the CRA's vulnerability final report, which runs from the fix, not from awareness, and [most write-ups get it wrong](\u002Farticles\u002Fcra-final-report-clock-does-not-start-when-you-become-aware).\n\n## What \"significant\" means for a cloud provider\n\nNIS2 Article 23(3) makes an incident significant where \"it has caused or is capable of causing severe operational disruption of the services or financial loss for the entity concerned\", or \"it has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage\". For the digital providers of Article 3(1) of the Implementing Regulation, the Regulation replaces that judgment with numbers. Article 3(1) applies to all of them; an incident is significant where one or more of these is met:\n\n> (a) the incident has caused or is capable of causing direct financial loss for the relevant entity that exceeds EUR 500 000 or 5 % of the relevant entity's total annual turnover in the preceding financial year, whichever is lower;\n> (b) the incident has caused or is capable of causing the exfiltration of trade secrets ...;\n> (c) the incident has caused or is capable of causing the death of a natural person;\n> (d) the incident has caused or is capable of causing considerable damage to a natural person's health;\n> (e) a successful, suspectedly malicious and unauthorised access to network and information systems occurred, which is capable of causing severe operational disruption;\n\nplus the recurring-incident rule of Article 4, incidents that have occurred at least twice within six months, have the same apparent root cause and together meet the financial criterion, and the sector criteria of Articles 5 to 14. Article 7, for cloud computing service providers, adds four, in the Regulation's terms:\n\n- a cloud computing service provided is completely unavailable for more than 30 minutes;\n- the availability of a cloud computing service is limited for more than 5 % of the service's users in the Union, or for more than 1 million of them, whichever number is smaller, for more than one hour;\n- the integrity, confidentiality or authenticity of stored, transmitted or processed data related to the service is compromised as a result of a suspectedly malicious action;\n- the same data is compromised with an impact on more than 5 % of the service's users in the Union, or on more than 1 million of them, whichever number is smaller.\n\nArticle 3(2) excludes \"scheduled interruptions of service and planned consequences of scheduled maintenance\". Article 3(3) says how to count users: contracted customers, and the natural and legal persons associated with business customers who use the service. Managed service providers and managed security service providers have the same four criteria in Article 10; data centres, CDNs, marketplaces, search engines, social networks and trust services have their own in Articles 8, 9 and 11 to 14.\n\nRead against the CRA's \"severe\" incident of Article 14(5), which asks whether the incident affects the product's ability to protect the confidentiality, integrity, availability or authenticity of sensitive or important data or functions, or introduces malicious code, the NIS2 thresholds are about the service and its users: half an hour of complete unavailability of a cloud service is a notifiable incident under NIS2 with no further judgment, and a compromise of data by a suspected malicious action is one under both laws.\n\n## One procedure, two forms\n\nThe company under both laws does not need two incident processes. It needs one assessment with two outcomes. The suspicious event comes in through the same channels; the initial assessment asks, promptly, first whether a product's security is affected or a product vulnerability is being exploited, and second whether the service has crossed a threshold of Article 3 or Article 7; \"became aware\" is recorded once, in UTC, with the reasoning; and the two clocks run from it into two forms, one on ENISA's platform for the product, one through the national channel for the service. The final reports are due in the same month, the users and the recipients are told once, and the record that shows the timeline is the same record.\n\n[The NIS2 to ISO 27001 mapping](\u002Fnis2\u002Fiso-27001-mapping) places the reporting duty among the other Article 21 measures; [the CRA deadlines page](\u002Fcyber-resilience-act\u002Freporting-deadlines) computes the three product deadlines and names the coordinator for each state. StandardOS keeps both sets of records, with the awareness timestamp and the deadlines derived from it, in one place.\n\n## Sources\n\n- Directive (EU) 2022\u002F2555 (NIS2), Article 2(1) and (2), Article 6(30), Article 21(1), Article 23(1) to (5), Annex I.\n- Commission Implementing Regulation (EU) 2024\u002F2690, recital 31, Articles 3, 4, 7, 10 and 5 to 14, read on EUR-Lex.\n- Regulation (EU) 2024\u002F2847 (CRA), Article 14(1) to (8), Article 16, Article 17(4), Article 69(3).\n- European Commission, Commission guidance on the application of Regulation (EU) 2024\u002F2847, C(2026) 5252 of 27 July 2026, paragraph 212.\n- Commission Recommendation 2003\u002F361\u002FEC, Annex, Article 2, for the size classes.\n\nThis is not legal advice. NIS2 is a directive, so the recipient, the channel and the form of the notification are set by each member state's transposition; the clock and the thresholds above are the Union text.\n",1789383985991]