NIS2 for SaaS Companies: Who's in Scope and How to Comply

If you run a SaaS company with more than 50 employees or EUR 10 million in annual revenue, and you serve customers in the EU, there is a high probability that NIS2 applies to you. Cloud computing providers, managed service providers, CDN operators, and online marketplaces are all explicitly named in the directive.

Most SaaS founders have not internalized this yet. NIS2 sounds like it belongs to energy companies and hospitals. It does apply to them. But the directive’s reach into digital services is one of its most significant expansions from NIS1, and the supply chain requirements mean that even SaaS companies below the size thresholds will feel the pressure.

Why SaaS companies are in NIS2’s scope

NIS2 covers digital businesses through three distinct categories, each with different classifications.

Digital infrastructure (Annex I, essential or important)

This is the broadest category for SaaS companies. It covers:

• Cloud computing service providers (IaaS, PaaS, SaaS)
• Data center service providers
• Content delivery network (CDN) providers
• DNS service providers (in scope regardless of size)
• TLD name registries (in scope regardless of size)
• Internet Exchange Point (IXP) providers
• Trust service providers (in scope regardless of size)
• Providers of public electronic communications networks and services (in scope regardless of size)

If your SaaS platform runs on infrastructure you control and serve EU customers, you likely fall into “cloud computing service provider.” The directive uses a broad definition that captures most hosted software offerings.

ICT service management (Annex I, essential or important)

This covers:

• Managed service providers (MSPs)
• Managed security service providers (MSSPs)

If your SaaS product provides IT management, monitoring, security, or operations capabilities to other businesses, this category applies.

Digital providers (Annex II, important)

This covers:

• Online marketplaces (platforms where buyers and sellers transact)
• Online search engines
• Social networking services platforms

These are classified as important entities, subject to reactive supervision and fines up to EUR 7 million or 1.4% of global turnover.

Size thresholds: does your SaaS qualify?

For most categories, NIS2 uses a straightforward size-cap rule.

Important entity (minimum threshold):

• 50+ employees, or
• EUR 10M+ annual turnover, or
• EUR 10M+ balance sheet total

Essential entity (higher threshold for Annex I sectors):

• 250+ employees, or
• EUR 50M+ annual turnover, or
• EUR 43M+ balance sheet total

No size threshold applies to: DNS providers, TLD registries, trust service providers, and public electronic communications providers. If you operate in these categories, you are in scope even with 5 employees.

The thresholds are applied at the group level, not the subsidiary level. A small European subsidiary of a large US-based SaaS company may meet the threshold through its parent’s consolidated figures. Check how your member state has implemented this, as there is some variation.

What NIS2 requires from SaaS companies

All 10 Article 21 measures apply. But certain requirements hit SaaS companies harder than others because of how software businesses operate.

Risk analysis that covers your entire attack surface

Article 21(2)(a) requires documented risk assessments. For a SaaS company, your attack surface includes every API endpoint, every login page, every webhook, and every integration. It also includes the automated traffic hitting those surfaces.

Bots made up 51% of all internet traffic in 2024 (Imperva). For SaaS platforms, the ratio is often higher. Credential stuffing, account takeover, free trial abuse, API scraping, and fake account creation are all bot-driven threats that your risk analysis must address.

A risk analysis that says “we have a WAF” is insufficient. NIS2 requires identification of specific threats, assessment of their likelihood, and documented measures to address them.

Incident detection and the 24-hour clock

Article 21(2)(b) requires incident handling procedures. Article 23 defines the reporting timeline: 24 hours for early warning, 72 hours for full notification, 1 month for final report.

For SaaS companies, the most common “significant incidents” under NIS2 will be:

• Credential stuffing campaigns that compromise customer accounts at scale
• API abuse that exposes customer data
• Service degradation from automated traffic spikes
• Account takeover affecting multiple customers
• Data exfiltration through scraping

The 24-hour clock starts when you become aware. If your monitoring misses a credential stuffing campaign for three days because you only review logs weekly, you have already blown the reporting window. Real-time detection is not optional. It is a compliance requirement.

Supply chain: you are someone’s supplier

Article 21(2)(d) requires supply chain risk management. For most SaaS companies, this works both directions.

As a buyer: You use third-party services (cloud providers, payment processors, analytics tools, authentication services). NIS2 requires you to assess their cybersecurity posture and include security clauses in your contracts.

As a supplier: Your customers who are NIS2-regulated will audit you. Hospitals using your scheduling software, banks using your analytics platform, energy companies using your monitoring tool: they all need to prove their supply chain is secure. That means they will ask you for SOC 2 reports, security questionnaires, incident notification procedures, and evidence of ongoing security measures.

This is where the “ripple effect” matters most for SaaS companies that think they are not in scope. Even if you have 30 employees and EUR 5M in revenue (below the threshold), your enterprise customers in regulated sectors will contractually require NIS2-equivalent security from you. Compliance becomes a market access requirement, not just a legal one.

Having bot detection and device intelligence embedded in your platform gives your customers auditable evidence that your product actively manages automated threats. When a hospital asks “how do you prevent unauthorized automated access to your API?”, you can point to real data: blocked bots, device risk scores, credential stuffing attempts detected and stopped. That is the kind of proof supply chain audits demand.

Access control and device-level visibility

Article 21(2)(i) requires access control policies and asset management. For SaaS platforms, “assets” includes every device that authenticates against your system.

Traditional access control verifies credentials: username, password, MFA token. NIS2 pushes further by requiring asset management, which means knowing the devices themselves.

Device fingerprinting provides this layer. Guardian identifies every device that interacts with your platform, assigns a persistent identifier across sessions, and scores its trustworthiness. When a login comes from a recognized device with a consistent fingerprint, that is a trusted access. When it comes from a headless browser on a residential proxy with a spoofed user agent, that is a risk event. NIS2 requires you to distinguish between the two.

Continuous authentication beyond MFA

Article 21(2)(j) calls for multi-factor authentication or continuous authentication solutions. For SaaS platforms, MFA at login is table stakes. NIS2 expects more.

Continuous authentication means verifying trust throughout a session, not just at the door. Device intelligence does this passively. On every interaction, Guardian evaluates whether the device environment is consistent with the authenticated session. If a session token moves to a different device (session hijacking), if the browser fingerprint changes mid-session, or if behavioral signals indicate automation, the trust score adjusts.

This is continuous authentication in the way NIS2 envisions it: ongoing, passive, and evidence-producing. Your compliance team gets logs showing that every session was continuously evaluated, not just initially authenticated.

The supply chain pressure is already building

Do not wait for a formal NIS2 audit notice. The pressure is coming from your customers.

NIS2 requires covered entities to evaluate their suppliers’ cybersecurity posture. In practice, this means:

• Security questionnaires from enterprise prospects during sales cycles
• Contractual clauses requiring you to report incidents within specific timelines
• Audit rights allowing customers to inspect your security practices
• Certification requirements (SOC 2, ISO 27001) as procurement prerequisites
• Evidence of technical controls beyond policies on paper

If you sell to healthcare, energy, transport, banking, or government customers in the EU, you are already in the supply chain scope of NIS2. Your customers’ compliance depends partly on your security posture. If you cannot demonstrate adequate measures, you lose the deal.

SaaS companies that proactively build NIS2-aligned security capabilities are turning compliance into a competitive advantage. When two vendors offer similar products but one can provide real-time bot detection dashboards, device risk scores, and incident detection logs, the NIS2-regulated buyer will choose the one that makes their compliance easier.

Preparing for your first NIS2 audit

Whether you are directly in scope or facing supply chain pressure, here is how to get ready.

Step 1: determine your classification

Check which NIS2 category applies to your SaaS (digital infrastructure, ICT service management, or digital provider). Determine whether you are essential or important based on your size. This affects the supervision regime and penalty ceiling.

Step 2: gap-assess against Article 21

Walk through all 10 measures. For each one, answer honestly:

• Do we have documented policies? (Not just “we do this,” but written, dated, approved documents)
• Do we have technical controls in place?
• Do we have evidence of ongoing operation? (Logs, dashboards, reports)
• Has management formally approved these measures?

Step 3: prioritize the highest-risk gaps

For SaaS companies, the usual priority order is:

1. Incident handling (21b) and the 24-hour reporting capability
2. Risk analysis (21a) with continuous, automated risk assessment
3. Access control (21i) with device-level visibility
4. Continuous authentication (21j) beyond password-plus-MFA
5. Supply chain (21d) with vendor assessment and customer-facing evidence

Step 4: deploy tooling that produces evidence

NIS2 is a “show me, don’t tell me” regulation. Policies are necessary but insufficient. Auditors will ask for:

• Logs of detected and blocked threats
• Dashboards showing real-time security posture
• Risk scores with historical trends
• Incident timelines with detection, classification, and response records
• Board meeting minutes documenting cybersecurity oversight

Guardian provides the evidence layer for web-facing SaaS applications. Device-level risk scoring on every session (risk analysis evidence). Bot detection that catches automated threats before they become incidents (incident handling evidence). Persistent device identification across sessions (access control evidence). Continuous device trust evaluation (continuous authentication evidence). Real-time analytics dashboards (effectiveness assessment evidence).

Start your free trial

Step 5: brief your leadership

Article 20 requires management body members to approve cybersecurity measures and complete training. Schedule a NIS2 readiness briefing with your board or executive team. Cover:

• Your NIS2 classification and what it means
• The 10 Article 21 measures and your current gaps
• The personal liability implications for management
• Your compliance roadmap and timeline
• Budget requirements for tooling and training

Step 6: prepare for customer audits

Even before regulators audit you, your customers will. Create a “NIS2 compliance package” that you can share with prospects and existing customers:

• Summary of your Article 21 posture
• Security certifications (SOC 2, ISO 27001)
• Incident notification procedures and SLAs
• Data processing agreements with NIS2 clauses
• Evidence of technical controls (sanitized dashboards, capability descriptions)

The timeline is now

The transposition deadline passed in October 2024. Most EU member states have enacted national legislation. Germany registered 29,500 entities starting January 2026. Italy’s enforcement begins October 2026. France and the Netherlands are finalizing their laws. The first audits are underway.

For SaaS companies, the compliance path is clear:

1. Determine if you are directly in scope
2. Recognize that even if you are not, your customers’ compliance requirements will flow down to you
3. Build the technical capabilities that produce auditable evidence
4. Get your board involved and trained
5. Turn compliance into a competitive advantage

NIS2 is not going away. The companies that build compliance into their product and operations now will win deals that their competitors cannot. The companies that wait will be scrambling when the audit letter arrives, or worse, when a customer asks for evidence they do not have.

Start with visibility. If you do not know what is hitting your systems, you cannot assess risk, detect incidents, or prove access control. Device intelligence gives you that foundation. Everything else builds from there.

For a comprehensive breakdown of all 10 Article 21 measures, read our NIS2 compliance checklist.