SaaSContractsIT leadershipSMEsChoosing a vendor
NIS2 for SaaS companies: does it apply to you, and what will customers ask for?
11 min read
NIS2 applies directly to a SaaS company when two conditions meet: its service falls within a listed sector, most often cloud computing services, and it is at least a medium-sized enterprise (50 staff, or more than 10 million euros in both turnover and balance sheet). Below that size, the directive still reaches you through your customers: those in scope must manage the security of their suppliers, and they will write it into your contract. This guide walks through scope, duties and what buyers will ask for. It is general information based on the EU texts, not legal advice for your situation.
Where NIS2 stands across Europe (as of 6 November 2026)
Directive (EU) 2022/2555 had to be transposed into national law by 17 October 2024. Progress has been uneven:
- some member states met or came close to the deadline, Belgium and Italy among them;
- Germany’s implementing act took effect on 6 December 2025, with no general transition period;
- in July 2026 the European Commission referred Ireland, Spain, France and the Netherlands to the Court of Justice of the EU for failing to notify full transposition;
- in France, the bill carrying NIS2 passed the Senate in March 2025 and, according to the National Assembly’s legislative file, was scheduled for floor debate on 9 November 2026, after several postponements.
The practical consequence for a SaaS vendor selling in several countries: you cannot wait for one national law. Your obligations depend on where you are established, and your customers’ demands depend on where they are, and many of them already apply national NIS2 rules.
Is your SaaS in scope?
Three questions, in this order.
1. Does your activity appear in the annexes?
NIS2 lists sectors in two annexes. For a software company, the relevant entries are:
- Annex I, digital infrastructure: cloud computing service providers, data centre services, content delivery networks, DNS services, trust services;
- Annex I, ICT service management (business to business): managed service providers and managed security service providers, which covers companies that run or maintain systems for their clients;
- Annex II, digital providers: online marketplaces, online search engines and social networking platforms.
The directive 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. Recital 33 lists Software as a Service among cloud service models, next to IaaS and PaaS. Many SaaS products therefore sit in the cloud category, although how a specific service is classified remains a matter of analysis under each national law.
A vendor whose software is installed on the customer’s own systems, and who operates nothing on their behalf, is not in NIS2 scope for that activity. It may fall under the Cyber Resilience Act instead (see below).
2. How large is your company?
NIS2 generally applies from the medium-sized enterprise threshold set by Commission Recommendation 2003/361/EC.
| Category | Criteria under the Recommendation |
|---|---|
| Small | Fewer than 50 staff, and turnover or balance sheet total of 10 million euros or less |
| Medium | Fewer than 250 staff, and turnover up to 50 million or balance sheet up to 43 million |
| Large | 250 staff or more, or turnover above 50 million and balance sheet above 43 million |
Two traps catch founders:
- headcount and financials are consolidated with partner and linked enterprises. A 20-person subsidiary of a 400-person group is not a small enterprise;
- some activities are covered regardless of size, such as trust service providers, top-level domain registries, DNS providers and public electronic communications networks, and a member state can designate a smaller entity that is the sole provider of a critical service.
3. Essential or important?
| Situation | Status |
|---|---|
| Annex I sector, large enterprise | Essential entity |
| Annex I sector, medium enterprise | Important entity |
| Annex II sector, medium or large | Important entity |
| Small enterprise, outside exceptions | Not directly in scope |
The security measures are the same for both categories. The differences lie in supervision (proactive for essential entities, after the fact for important ones) and in penalties. Article 34 requires member states to set maximum fines of at least 10 million euros or 2% of worldwide annual turnover for essential entities, and at least 7 million euros or 1.4% for important ones, whichever is higher.
Which country supervises you
This is the question most guides skip, and it matters for SaaS. Under Article 26, providers of cloud computing services, data centres, content delivery networks, managed services, online marketplaces, search engines and social networks fall under the jurisdiction of the member state where they have their main establishment in the EU: broadly, where cybersecurity risk-management decisions are taken. You deal with one national authority, not 27.
A company established outside the EU that offers these services in the EU must designate a representative in one of the member states where it operates. A US or UK SaaS vendor selling to European businesses cannot assume NIS2 is someone else’s problem.
What NIS2 requires from a SaaS vendor in scope
Article 21 sets ten families of minimum measures. Here is what they mean in practice for a hosted product.
| Article 21 measure | What it means for a SaaS vendor |
|---|---|
| Risk analysis and security policies | A living document, approved by management, covering the risks of the service |
| Incident handling | Detection, logging, a written procedure, someone on call |
| Business continuity and crisis management | Backups proven by restore tests, a recovery plan, recovery objectives |
| Supply chain security | Assessing your hosting provider, third-party APIs and subcontractors |
| Secure development and maintenance | Code review, dependency management, patching, vulnerability disclosure |
| Assessing effectiveness | Audits, penetration tests, tracked indicators |
| Cyber hygiene and training | Training for the whole team, management included |
| Cryptography | Encryption in transit and at rest, key management |
| HR security, access control, asset management | Named accounts, least privilege, offboarding, an asset inventory |
| Multi-factor authentication | For your team, and offered to your users |
For cloud, managed service and several other digital providers, Implementing Regulation (EU) 2024/2690 already spells out these technical requirements and the criteria that make an incident significant. As a regulation, it applies directly to the entities covered by national NIS2 law, so a cloud provider’s duties are largely harmonised across the EU. ENISA has published technical implementation guidance that maps each requirement to examples of evidence.
Two obligations change daily life for a small team:
- incident reporting (Article 23): an early warning within 24 hours of becoming aware of a significant incident, a notification within 72 hours, and a final report one month later. Without logs and a written procedure, these deadlines cannot be met;
- management accountability (Article 20): management bodies approve the measures, oversee their implementation and must follow training. Security can no longer be left entirely to the lead developer.
What your customers will ask for
For most SaaS companies, including small ones, this is where NIS2 bites first. Article 21 requires every entity in scope to take into account the vulnerabilities specific to each direct supplier and the quality of their secure development practices. Your product is one of those suppliers.
Expect to receive:
- a security questionnaire, often long, before signature or at renewal;
- contract clauses: an incident notification deadline (sometimes shorter than the directive’s, so the customer can meet its own), a right to audit or to receive audit reports, a list of subprocessors, data location, exit and data return;
- evidence: your security policy, penetration test summaries, backup procedure and the date of the last restore test, certifications such as ISO 27001 or a SOC 2 report if you have them;
- technical features: single sign-on and multi-factor authentication, exportable access logs, encryption, isolation between customers.
Our guide to SaaS agreement clauses covers the standard documents. NIS2 turns them from an enterprise-only negotiation into something a mid-sized customer needs for its own compliance.
A vendor’s action plan, in priority order
Whether you are in scope or simply a supplier to entities that are, the order of play is the same.
- Run the scope test: activity, consolidated size, main establishment, countries you sell into. Write down the conclusion and its date.
- Build an inventory: servers, databases, third-party services, admin accounts, software dependencies.
- Close weak access: multi-factor authentication for every team account, named accounts, least privilege, offboarding.
- Run a real restore from backup and time it.
- Write the incident procedure: who decides, who informs customers, within what time, using which logs.
- Assess your own suppliers: hosting, email delivery, payments, AI providers. Customers will ask about them.
- Assemble a reusable security pack: standard questionnaire answers, an architecture diagram, your policies.
- Get management sign-off and training: the directive requires it, and it unlocks budget decisions.
Our business application security essentials covers the technical basics, and hosting a business application in Europe helps you pick a provider that procurement teams will accept.
The Cyber Resilience Act, briefly
Regulation (EU) 2024/2847, the Cyber Resilience Act, covers products with digital elements placed on the EU market, including installed software. Its duty to report actively exploited vulnerabilities has applied since 11 September 2026, and most requirements apply from 11 December 2027.
A pure online service is generally a NIS2 matter rather than a CRA one. The CRA can still reach you if you also ship a mobile app, a desktop client or a device, or if your remote service is essential to a product you sell. In that case both texts apply.
The most common mistakes
- Deciding “we are too small” too quickly, without consolidating group headcount or looking at where your customers are.
- Treating NIS2 as GDPR. GDPR protects personal data; NIS2 covers the security and continuity of the service itself. One incident can trigger both, with two separate notifications. Our GDPR checklist for a business application covers the first.
- Buying a compliance tool before having a procedure. A dashboard does not replace a tested restore or an incident playbook.
- Promising in a contract what the software cannot do: exportable logs, notification within hours, provable deletion of data. Those commitments have to be built.
When compliance becomes a product question
Part of NIS2 is organisational. Part of it lives in the software: isolation between customers, access logs, MFA and SSO, restorable backups, dependency updates, data export at the end of a contract. A SaaS built without these features adds them later at a higher cost, usually when a large customer makes them a condition of signing. The multi-tenant architecture of the product is the first place where this is decided.
LPR Studio designs and runs software, including its own products, with these requirements built in from the start. If you are planning a SaaS, or rebuilding a hosted product for demanding customers, we can present a free prototype on a video call within 5 working days, showing these features in your own screens. For the budget side, see what it costs to build a SaaS platform.