NIS2 pentest for SaaS: when B2B software falls in scope and what Article 21 requires

NIS2 (Directive (EU) 2022/2555) widened the EU cybersecurity perimeter far beyond the original NIS directive, and a large share of B2B SaaS companies were pulled in without expecting it. The scoping is the part everyone gets wrong, so this page starts there before it touches testing.

This page is written for SaaS CISOs and heads of security who need to answer two questions: is my SaaS actually in scope, and if so, what does NIS2 want me to test and evidence.

When a SaaS actually falls in scope

NIS2 scopes entities by a combination of sector (Annex I and Annex II) and size. A B2B SaaS is not in scope simply because it is software. It falls in scope when it qualifies as one of the covered service types and meets the size threshold.

The service types that catch SaaS sit mostly in Annex I, sector 8 (Digital Infrastructure) and the digital-provider categories:

• Cloud computing service providers (IaaS, PaaS, and SaaS delivered as a computing service).
• Data centre service providers.
• Managed service providers (MSP) and managed security service providers (MSSP).
• Online marketplaces, online search engines, and social networking platforms (Annex II, digital providers).

On top of the sector test comes the size test. NIS2 applies to medium and large entities: broadly 50 or more staff, or more than EUR 10M annual turnover and balance-sheet total, with some size-cap exceptions where an entity is in scope regardless of size because of its critical role (for example certain DNS, TLD, and public-communications providers). A 30-person pure application SaaS with no MSP role and no infrastructure offering is usually out of direct scope. A 120-person platform that hosts customer workloads, manages customer security, or operates as a marketplace is usually in.

The category then splits into essential and important entities. Cloud computing providers, data centre providers, and MSSPs above the large-enterprise threshold tend to land as essential entities under proactive supervision (Articles 32 and 33 give supervisors on-site inspection, security audits, and the heavier sanctioning track). Most other in-scope digital providers are important entities, supervised mainly reactively after an incident. The Article 21 security baseline is identical for both; only the enforcement intensity differs.

One nuance that trips up scoping: the national transposition deadline under Article 41 was 17 October 2024, but several Member States transposed late. The Article 21 security baseline is uniform EU-wide, but the registration duties, the reporting portal, and the supervision format are national and landed on different dates.

What NIS2 actually requires for testing

NIS2 never says pentest. It sets a risk-management baseline in Article 21 and leaves the testing choice to the entity. The provisions that a SaaS pentest maps to:

• Article 21(2)(e). Security in network and information systems acquisition, development, and maintenance, including vulnerability handling and disclosure. This is the anchor. Pentest is the primary evidence that a SaaS finds, triages, and fixes vulnerabilities across its development and maintenance lifecycle.
• Article 21(2)(f). Policies and procedures to assess the effectiveness of cybersecurity risk-management measures. A pentest is the recognised way to demonstrate that the measures actually work rather than existing only on paper.
• Article 21(2)(d). Supply-chain security, including security-related aspects of relationships with direct suppliers and service providers. For a SaaS this cuts both ways: your own integrations and providers, and your obligations to in-scope customers who inherit you as a supplier.
• Article 24. Use of European cybersecurity certification schemes. Member States may require entities to use certified products, services, or processes, which can shape which testing evidence is accepted.
• Articles 32 and 33. Supervision and enforcement of essential and important entities. These give competent authorities the power to demand security audits and evidence, which is where your pentest artefacts actually get examined.
• Article 20. Governance. The management body must approve the risk-management measures and can be held personally accountable, so testing evidence has to reach board level, not sit only with the security team.

Penetration testing is therefore the primary evidence for 21(2)(e) vulnerability handling and for 21(2)(f) effectiveness assessment. Everything else in the scope conversation flows from those two.

What supervisors and auditors actually look for

Three plausible SaaS scoping situations show what the questions sound like in practice.

A mid-market cloud/PaaS provider, essential entity. They host and orchestrate customer workloads, so they land as a cloud computing service provider above the large-entity threshold. Under proactive supervision (Article 32), the competent authority asked for a security audit and focused on 21(2)(e): which vulnerabilities were identified in the multi-tenant control plane over the last 12 months, how tenant-isolation findings were rated and remediated, and what the retest evidence was. They also asked, under Article 20, who on the management body signed off the residual-risk acceptance for two unresolved medium findings. A single annual pentest report existed but the supervisor wanted the continuous vulnerability-handling record between engagements.

An MSP/MSSP, essential entity. As a managed security service provider they sit in the highest-scrutiny bucket, because they hold privileged access into their clients' estates. The supervisor's line of questioning under 21(2)(f) was about effectiveness: how do you demonstrate that the controls you sell and operate for clients actually withstand attack, what is your own testing cadence on the tooling and jump hosts you use to reach client environments, and how do you evidence that a compromise of your platform would not cascade into every client. Supply-chain accountability under 21(2)(d) ran in both directions here, since the MSSP is itself a critical supplier to other in-scope entities.

A B2B workflow SaaS above the thresholds, important entity. A 200-person process-automation SaaS that qualifies as a digital service provider and sits above the size threshold. As an important entity the supervision is mostly reactive, but their real pressure came from customers: several in-scope enterprise customers, meeting their own 21(2)(d) supply-chain duty, demanded evidence that the SaaS tests effectively. The recurring question was the effectiveness-assessment evidence under 21(2)(f): a current pentest, a documented remediation trail, and management-body attestation under Article 20 that the security measures are approved and overseen.

The pattern across all three: supervisors and customers want the evidence chain, not the existence of a test. A pentest with no rating, no remediation record, and no management-body sign-off does not satisfy 21(2)(e) or 21(2)(f).

Where continuous AI pentest fits SaaS specifically

NIS2 rewards continuous validation for a SaaS for three concrete reasons:

1. Article 21(2)(e) continuous vulnerability handling. SaaS ships weekly or daily. A once-a-year snapshot cannot evidence that vulnerabilities introduced between releases were found and handled. Continuous validation produces a dated stream of identify-triage-remediate-retest records that maps directly onto the vulnerability-handling obligation.
2. Article 21(2)(f) effectiveness evidence. The effectiveness-assessment duty is about demonstrating that measures work over time, not at a single audit date. Continuous testing gives a running effectiveness record instead of one PDF, which is exactly what a supervisor or an in-scope customer wants to see.
3. Article 21(2)(d) supply-chain and integration surfaces. A SaaS lives on cloud, identity, data, and third-party API integrations. Continuous testing of those integration points (API contracts, IAM boundaries, tenant-isolation seams, webhook and OAuth surfaces) generates the evidence that the supply-chain surface is covered, both for your own suppliers and for the in-scope customers who inherit you.

The version that works: continuous validation against every release candidate on a production-equivalent environment, a periodic depth-pentest on production including tenant-isolation and authorization logic, integration testing on the supply-chain surface, and evidence flowing automatically into the compliance evidence store. The version that does not work: raw scanner output with no human triage, no retest, and no path to the management body.

Procurement checklist for SaaS CISOs scoping NIS2 pentest

• Does the vendor produce evidence supervisors accept specifically for Article 21(2)(e) vulnerability handling and 21(2)(f) effectiveness assessment, not a generic report?
• Can that evidence be packaged for both proactive supervision (if you are an essential entity) and for in-scope customers meeting their 21(2)(d) supply-chain duty on you?
• Does the vendor integrate with your CI/CD pipeline natively (GitHub Actions, GitLab CI, CircleCI), or require manual report uploads for a team that ships weekly?
• Does the vendor deliver a continuous evidence stream with dated remediation and retest records, or a single PDF per engagement?
• Does the evidence reach management-body level cleanly, so you can satisfy the Article 20 governance and accountability expectation?
• Where is the pentest data stored and under which jurisdiction? For an EU in-scope entity, a US-hosted pentest vendor is an avoidable exposure.
• Does the vendor scope multi-tenant isolation, authorization logic, and third-party integration surfaces, which are where SaaS-specific NIS2 findings concentrate?

Where Fleuret fits

Fleuret runs continuous AI pentest on SaaS environments and produces evidence mapped to NIS2 Article 21, specifically the 21(2)(e) vulnerability-handling and 21(2)(f) effectiveness-assessment obligations that supervisors and in-scope customers actually examine. Findings stream into your compliance evidence store with dated remediation and retest records, so the evidence chain is continuous rather than a once-a-year artefact. We integrate with GitHub Actions, GitLab CI, and remediation trackers so testing follows your release cadence.

Fleuret data residency is EU only. Pentest findings, tenant identifiers, and any extract from your environment stay in EU infrastructure, with no CLOUD Act exposure on the evidence you rely on to satisfy an EU competent authority.

If you are scoping NIS2 pentest for a SaaS, book a demo.

Related compliance reading

• ISO 27001 pentest for SaaS: the certification most in-scope SaaS run in parallel, mapping the same vulnerability and testing evidence onto Annex A controls.
• NIS2 pentest for telecom: the same directive applied to essential-entity digital infrastructure, where the IT and signalling boundary shapes scope.