Is my SaaS a 'cloud computing service' under NIS2?

If you run a B2B SaaS business in the EU, someone has probably asked you whether NIS2 applies to you as a "cloud computing service". It is a fair question with a frustrating answer: partly settled, partly not. The good news is that the uncertainty is much narrower than the internet suggests, and once you separate the two halves of the question you can usually reach a defensible position in an afternoon.

The single biggest mistake we see is conflating those two halves. Do that and you will either panic unnecessarily or wave the whole thing away. Neither is safe. Below is how to reason about it properly.

What NIS2 actually asks

NIS2 lists cloud computing as a sector. It sits in Annex I, sector 8, "Digital infrastructure". So the framework clearly contemplates cloud providers being in scope.

But "being in the sector" is not the same as "being caught". Two separate gates have to be passed. First, does your service meet the legal definition of a cloud computing service at all? Second, are you large enough for the obligations to attach? People tend to argue about the first gate when, for most SaaS companies, the second gate is the one that actually decides the matter. We will come back to that.

The two-part question

Break the definitional question into two:

• (a) Is SaaS a recognised cloud service model? This is settled.
• (b) Does your specific product satisfy the operative test in Article 6(30)? This is genuinely unsettled at the edges.

Most bad advice comes from answering (a) and pretending it also answers (b). It does not. A recital that lists service models tells you SaaS is the kind of thing that can be a cloud computing service. It does not automatically deem your particular product to be one.

Part one: SaaS is a cloud service model (settled)

There is no real argument here. NIS2 Recital 33 says it verbatim:

"The service models of cloud computing include, inter alia, Infrastructure as a Service (IaaS), Platform as a Service (PaaS), Software as a Service (SaaS)..."

The technical terms take their meaning from ISO/IEC 17788:2014. So if anyone tells you SaaS categorically cannot be a cloud service under NIS2, they are wrong. That half is closed.

What Recital 33 does not do is settle whether your product is caught. A recital lists service models; it is not a deeming provision. It informs how you read the operative article, but the operative test still has to be met on its own words.

Part two: does your product meet Article 6(30)? (unsettled)

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".

Pull out the operative words:

• "on-demand administration"
• "scalable and elastic"
• "shareable" (which implies multi-tenancy)

Apply those honestly to a typical B2B SaaS product. It is multi-tenant, it scales up and down, and customers self-serve. On the plain words, most real B2B SaaS satisfies Article 6(30). We want to be direct about that, because there is a temptation to treat the uncertainty as a way out. It usually is not.

The genuinely arguable cases are the ones that lack those attributes: single-tenant deployments, fixed-capacity offerings, or products that are manually provisioned rather than administered on demand. If that describes you, you have a real argument to make. If it does not, assume you meet the test.

The reason this is "unsettled" rather than "clear" is structural. There is no EU-wide classification test. No case law construes Article 6(30). ENISA guidance does not address it. So even a well-reasoned position is a position, not a certainty. Note also that financial entities are handled under a separate regime - if that is you, our DORA readiness work is the right starting point rather than NIS2.

Why Germany and Denmark disagree

The clearest illustration that this is unsettled is that national regulators reach opposite conclusions on the same words.

Germany (BSI) treats SaaS as generally in scope, even when it runs on third-party infrastructure. Not operating the underlying resources yourself does not preclude classification. The BSI does carve out fixed-capacity webhosting.

Belgium (CCB) is broadest of all. Its cloud definitions are read as taking in providers of SaaS, IaaS and PaaS alike.

Denmark takes the opposite view. It says classification is not automatic: a service built on third-party cloud elements cannot automatically be regarded as a cloud computing service.

So Germany and Denmark are in direct conflict on the same fact pattern. Netherlands, Ireland and Austria decline to resolve the question at all. This is not a case of one regulator being obviously right. It is a genuine open question that will likely stay open until there is guidance or litigation. The practical consequence: where you are established, and which competent authority you answer to, can change the answer.

The size threshold usually decides it first

Here is the part most cloud-definition debates miss entirely. For the majority of SaaS companies, the definition is not the gate that matters first. Size is.

Some sectors are on a "size-blind" list, caught regardless of headcount or turnover. Cloud is not on that list. So for most SaaS, the size threshold decides scope before the cloud definition ever becomes decisive.

Article 2(1) brings you into scope only if you are medium-sized or larger, measured against Commission Recommendation 2003/361/EC. The mechanics matter, because they are easy to get wrong:

• You exit the "small" category if staff are 50 or more.
• Or if the financial limb is met - but that limb is conjunctive. You only clear it if turnover and balance sheet total both exceed EUR 10m.

Work through an example. A 30-person SaaS company with EUR 15m in annual recurring revenue but a small balance sheet is out. Headcount is under 50, and although turnover is over EUR 10m, the balance sheet is not, so the conjunctive financial test is not satisfied.

One important caveat: these figures are not always assessed on your standalone company. Partner and linked-enterprise aggregation applies. If a VC owns a large stake, the ownership structure can pull an otherwise small startup over the threshold. So run the size calculation on the correct, aggregated basis before you conclude you are out.

For a company in the 50-250 person range - the readers we usually write for - the headcount limb alone will typically put you over the size threshold. At that point the definitional question stops being academic and you are back to Article 6(30).

What to do while it is unsettled

You do not need certainty to act sensibly. You need a defensible position and a plan.

• Run the size test first, on the properly aggregated basis. If you are clearly below the threshold, the cloud definition is moot for now. Document the calculation.
• If you are over the size threshold, assume Article 6(30) is met unless you are genuinely single-tenant, fixed-capacity or manually provisioned. If you are one of those edge cases, write down the argument.
• Identify which member state's competent authority you answer to, because as the German and Danish positions show, that can change the outcome.
• Do not wait for perfect clarity that is not coming. The operative test has no case law and no ENISA guidance behind it, so a documented, reasoned position is the best available protection.

A short, structured assessment is usually enough to get you from "we are not sure" to "here is our position and why". Our Mini Gap Review is built for exactly this: a focused look at where you actually stand. When you are ready to move from scoping to controls, NIS2 readiness is the next step.

The uncertainty in NIS2 is real, but it is narrow. Separate the two questions, run the size test first, and most SaaS companies will find the answer is clearer than the debate suggests.