If you sell software into Europe, three sets of rules have landed in quick succession - NIS2, DORA, and the EU AI Act - and the honest state of most SaaS founders right now is quiet confusion about which of them, if any, actually applies to their company.
It’s a fair place to be confused. These are regulations, not certifications, so nobody sends you a tidy checklist. They overlap in places, they use different language for similar ideas, and the question founders really want answered - what do I personally have to do? - depends entirely on who you sell to and what you build.
Here’s the short version, and then we’ll take each one in turn.
Broad cybersecurity law
- Since
- October 2024
- Applies to
- Companies by sector and size
Financial-sector resilience
- Since
- January 2025
- Applies to
- Finance firms and their ICT providers
AI governance
- Status
- Foundational rules live
- Applies to
- By what your AI does
The thing to understand first
NIS2, DORA and the AI Act are laws. ISO 27001 is a certification. They are not competing options - they operate at different levels.
The laws tell you what outcomes you must achieve (manage your risk, report incidents on a clock, oversee your suppliers). They do not tell you how, and crucially, none of them can be “certified.” You can’t hold up a NIS2 certificate, because there’s no such thing.
ISO 27001 is how you demonstrate, in a structured and externally-audited way, that you’re meeting most of what those laws demand. That relationship - law sets the obligation, certification proves you’re meeting it - is the whole key to cutting through the confusion. We’ll come back to it, because it’s where this gets practical.
NIS2: the broad one
In short: the EU’s general cyber law. It can reach a small SaaS company through its enterprise customers.
NIS2 is the EU’s general cybersecurity law, and it’s the one most likely to touch a general SaaS company.
Who it covers. NIS2 applies to “essential” and “important” entities across 18 sectors - and companies with 50 or more staff, or annual turnover above €10M, operating in those sectors are in scope. The sectors include digital infrastructure, cloud and data-centre providers, and managed service providers, which is where a lot of B2B SaaS lands.
The part founders miss. Even if you’re a small company below those thresholds, a company with fewer than 50 staff is generally not directly in scope unless it is a critical ICT provider to a NIS2- or DORA-regulated entity - in which case it is affected indirectly. In plain terms: if your enterprise customer is regulated, their obligations flow down to you through the contract, whether or not the law names you directly. This is the mechanism that quietly pulls small SaaS vendors into scope - not the law reaching them, but their customers reaching them.
What it requires. Managing supply-chain risk including SaaS and AI vendors, maintaining a complete inventory of information systems, reporting significant incidents to the competent authority, and senior-management oversight of cybersecurity with mandatory training.
An early warning within 24 hours of becoming aware of a significant incident, and a fuller notification within 72 hours.
This is what makes NIS2 different from a best-practice framework. In both cases, executives carry personal liability.
You don’t have to be named by NIS2 to be bound by it. If a regulated company is your customer, their obligations arrive on your desk as contract clauses - supplier security requirements, audit rights, incident-notification duties. This is the exact moment most SaaS companies first encounter the certification question.
DORA: the financial one
In short: strict resilience rules for finance. They reach SaaS vendors through bank and insurer contracts.
DORA is narrower and deeper. It governs digital operational resilience in the financial sector, and it’s prescriptive in a way NIS2 is not.
Who it covers. The financial sector - banks, insurers, investment firms, payment providers, and fintech and crypto-asset companies - and, critically, their critical ICT providers, such as cloud and SaaS vendors.
Why it matters even if you’re not a bank. That last clause is the one. If you’re a SaaS company serving financial clients - a fintech tool, a payments integration, anything a bank or insurer runs on - DORA’s third-party-risk requirements reach you through your customers. Third-party risk is the pillar most relevant to SaaS: it requires a provider registry, risk assessments, specific contract clauses covering audit rights, incident notification, data portability and exit plans, and monitoring of provider concentration.
Far tighter than NIS2 - an initial notification within 4 hours of an incident being classified as major, and no later than 24 hours from becoming aware of it.
The EU AI Act
In short: rules for AI systems, scaled to risk. They matter most if AI is core to what you sell.
The EU AI Act governs how AI systems are built and deployed, on a risk-tiered basis - and its timeline has moved. The foundational pieces are already live: prohibited AI practices have applied since February 2025, the rules for general-purpose AI models since August 2025, and the Act became generally applicable in August 2026.
But the heavy obligations - the ones for “high-risk” AI systems - were pushed back by a reform package during 2026. The requirements originally due in August 2026 now apply from December 2027, with a further tier following in August 2028. So if you were bracing for the full weight of the Act to land this year, you have more room than the original timeline suggested.
That matters less for whether this applies to you and more for when. If AI is core to your product, the direction of travel is clear even if the deadlines have slipped: governance of how AI is built and deployed is becoming an expectation, not an option. It’s also the regulation that pairs with ISO 42001, the new AI-management-system standard, in the same way the others pair with ISO 27001. For an AI-native SaaS company, building that governance foundation early - well before the 2027 deadlines bite - is the same move as getting ISO 27001 in place ahead of a customer demanding it.
So where does ISO 27001 actually fit?
Here’s the practical heart of it, and the reason this matters for how you spend your time and money.
You cannot certify to NIS2 or DORA - there is no such certificate. But ISO 27001 gives you a certifiable management system that maps well to DORA and NIS2 themes, including governance, risk management, incident response, supplier controls and continuous improvement. In practice, it gives you a strong control foundation and a reusable evidence model across frameworks - you build the ISMS once, and most of what the regulations ask for is already documented and operating.
The sensible approach, and the one we take with clients, is to start from your ISO 27001 control set and Statement of Applicability, then map each control to the specific NIS2 and DORA obligations. One control framework, evidenced once, pointed at multiple regulations.
But ISO 27001 does not cover everything, and it’s important to be honest about the gaps:
So ISO 27001 is the foundation, not the finish line. It does the heavy lifting - the controls, the evidence, the structure - and then the regulation-specific requirements (the reporting clocks, the registers, the contractual clauses) sit on top of it.
The honest answer to “which one do I need?”
Most SaaS founders asking this question don’t actually have a free choice between frameworks - the situation chooses for them.
In nearly every case, the thread running through all three is the same: ISO 27001 is the certification that proves you’re meeting the baseline these laws demand. It’s why, when an enterprise or financial customer sends you a security review driven by their own NIS2 or DORA obligations, the requirement that lands on your desk is so often "get ISO 27001 certified." The law is the reason; the certificate is the answer they’ll accept.
That’s the real shape of it. You don’t usually get to pick which regulation touches you - your customers and your product decide that. But you do get to choose how efficiently you respond, and building one solid ISO 27001 foundation that answers most of what all three demand is, for a growing SaaS company, by far the most economical way through.
Stenward helps Series A and B SaaS companies build the ISO 27001 foundation that answers enterprise security reviews: including the ones driven by NIS2 and DORA.
If a regulated customer is asking you to certify, and you want an honest view of what it takes, get in touch.
Book a call