NIS2, for a software company

NIS2 for a SaaS company: you are a cloud computing service provider, and this is what follows

Recital 33 of the Directive names Software as a Service as a cloud service model, so a SaaS company of medium size or larger is an entity of NIS2 as a cloud computing service provider: important below the medium ceilings, essential above them. What follows, in the order it arrives: the state of your main establishment, the registry you had to be in by 17 January 2025, the measures of Implementing Regulation 2024/2690, the four incident thresholds of its Article 7 and the Article 23 clocks, and the line between this and the CRA.

NIS2 for managed service providers and MSSPs: an Annex I entity by definition, and the supplier every customer's due diligence lands on

Article 6(39) makes anyone who installs, manages, operates or maintains ICT for customers, on site or remotely, a managed service provider, and Article 6(40) makes the ones who help with cybersecurity risk management MSSPs. Both are Annex I types: important at medium size, essential above the ceilings, under the law of the main establishment, in ENISA's registry, under Implementing Regulation 2024/2690 directly, with Article 10's four incident thresholds. And recital 86 tells every essential and important customer to exercise increased diligence in choosing you.

NIS2 for online marketplaces, search engines and social networks: the Annex II digital providers, and why they are never essential by size

Three definitions borrowed from three other acts decide whether a platform is a digital provider under NIS2: a marketplace where consumers conclude distance contracts, a search engine that searches in principle all websites, a platform where end users connect and share. In scope at medium size, important under Article 3(2) however large, under the law of the main establishment, in ENISA's registry, under Implementing Regulation 2024/2690 with its own incident thresholds in Articles 11 to 13: no 30-minute rule, a share of users instead.

Essential or important under NIS2: the size rule, the size-blind rules and the seven ways to be essential

Whether NIS2 reaches a company is Article 2; whether it is essential or important is Article 3; and the difference is ex ante supervision, a higher fine ceiling and a stricter reading of everything else. The two articles quoted, the size classes of Recommendation 2003/361/EC as they are actually counted, the rules that ignore size, and the cases a software company gets wrong: a cloud provider with 40 staff, a large machinery maker, a registrar, a company outside the Union.

NIS2 registration: the two lists you may be on, what you submit, by when, and to whom (Article 3(4) and Article 27)

NIS2 has two registrations, not one. Every essential and important entity submits four items to its competent authority so that the member state can establish its list by 17 April 2025 (Article 3(3) and (4)), with changes notified within two weeks. Eleven types of digital entity, cloud providers and managed service providers among them, also submit six items by 17 January 2025 for ENISA's registry (Article 27), with changes within three months. Which state receives it (Article 26), what the two lists are for, what registering does not decide, and the record to keep.

The ten measures of NIS2 Article 21(2), as a checklist: each point quoted, the Regulation sections behind it, and the ISO 27001 controls that already produce it

Article 21(2) lists ten measures every essential and important entity must take, from risk analysis policies to multi-factor authentication. For cloud, managed service and the other digital providers, Implementing Regulation 2024/2690 details each in 13 sections written from ISO/IEC 27001 and 27002. One table: the ten points as the Directive words them, the sections that detail each, and the ISO 27001 clauses and Annex A controls that produce the evidence, with the two places an ISMS does not reach.

NIS2 Article 20 for the board: what the management body must approve, oversee and learn, the twelve places the Implementing Regulation names it, and what liability means

Article 20 of NIS2 makes the management body of an essential or important entity approve the cybersecurity risk-management measures, oversee their implementation, be liable for the entity's infringements of Article 21, and follow training. Implementing Regulation 2024/2690 then names the management body in twelve places of its Annex: a dated approval of the policy, an annual review, a direct reporting line, acceptance of residual risk, compliance reporting, an awareness programme. Each of the twelve as a record, the ISO 27001 clause that already produces it, and what Article 32 and Article 34 say liability looks like.

ISO 27001 vs NIS2: what the certificate covers and what it does not

NIS2 is law and ISO 27001 is a certifiable standard, so they are not alternatives. Here is where an existing ISMS satisfies the directive's requirements, and the two places it does not.

CRA or NIS2: which one applies to a software company, and can it be both?

The Cyber Resilience Act regulates products placed on the market; NIS2 regulates entities that provide services. A software company can be under one, the other, both or neither, and the answer turns on two questions: do you place a product on the market, and are you a medium-sized or larger entity in a listed sector. The dates, the reporting clocks, the fines and the decision table, from the two texts.

NIS2 transposition, state by state: what the Commission's own register shows

Not a law firm's tracker: the national measures the member states have communicated to the Commission as transposing Directive (EU) 2022/2555, read from the Publications Office on 12 September 2026. 25 of the 27 states have communicated at least one, 303 measures in all; Spain and Ireland none; France 15 texts, all older than the Directive. The act each state calls its NIS2 law, when it entered into force, and what a software company does with the answer.

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/2690 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.

The NIS2 incident clock for a software company: the 24-hour early warning, the 72-hour notification, the one-month final report, what makes an incident significant for a cloud provider, and a page that writes the three reports

Article 23(4) of NIS2 runs three clocks from the moment an essential or important entity becomes aware of a significant incident: an early warning within 24 hours, an incident notification within 72, and a final report within one month of that notification, with an intermediate report on request and a progress report where the incident is still open. For a cloud computing service provider, Implementing Regulation (EU) 2024/2690 says when an incident is significant: a direct financial loss over EUR 500 000 or 5 % of turnover, whichever is lower, a service completely unavailable for more than 30 minutes, availability limited for more than 5 % or 1 million of its users in the Union for more than an hour, or a suspectedly malicious compromise of data. What each report contains, which CSIRT it goes to, and a free page that computes the deadlines and writes all three in six languages.

Which CSIRT do you report to under CRA Article 14? All 27 coordinators, as ENISA lists them

Every guide to the Cyber Resilience Act's reporting duty says 'notify your national CSIRT' and stops. Since 10 September 2026 ENISA publishes the CSIRT designated as coordinator for each of the 27 member states. Here is that list, the rule that picks the state, and the two states where the coordinator is not the national CSIRT.

Which EU countries name ISO 27001 in public tenders: 1,548 German notices, 829 Polish, and Greece has the highest share

Over 365 days, ISO 27001 appears in 3,415 TED notices. Germany and Poland account for 70% of them, Greece names it in 2% of everything it buys, and France, Spain and Italy barely name it at all. The numbers by country, and the query to re-run them.

ISO 27001 vs SOC 2 in Europe: which one buyers actually ask for

Selling into Europe, get ISO 27001: EU public tenders named it 3,408 times in a year against 104 for SOC 2. Selling to US customers, it runs the other way. The numbers, the public TED query to re-run them, and when you need both.

DORA for a software vendor: the Article 30 contract clauses your bank customer will send, the register of information you will appear in, and what ISO 27001 already answers

Since 17 January 2025 every bank, insurer, investment firm and payment institution in the Union manages its software vendors under Regulation (EU) 2022/2554, DORA. The vendor is not regulated; the contract is. Article 30 lists nine clauses every ICT service contract must carry and six more when the service supports a critical or important function: locations, data return, incident assistance at a pre-set cost, cooperation with the customer's authorities, termination notice, audit rights, exit strategies. Each clause read from the Regulation, the register of information the customer files yearly, the three delegated acts behind it, and which of the clauses an ISO 27001 system already produces the evidence for.