NIS2 Compliance Checklist for SaaS Companies (2026)
Many SaaS founders assume NIS2 only applies to banks and utilities. It doesn't. If you sell software to EU businesses, chances are your customers are asking about it — and some of them need you to be compliant before they can sign.
Not legal advice. This is a practical engineering-oriented checklist based on the public text of Directive (EU) 2022/2555. For formal obligations, consult the directive itself and your national transposition law.
Step 1: Are you actually in scope?
NIS2 distinguishes between essential entities (large energy, transport, banking, health, digital infrastructure providers) and important entities — which includes most other medium and large companies operating in the EU. The size thresholds follow the standard SME definition:
- In scope if: 50+ employees or €10M+ annual turnover, and you provide services within the EU in one of the covered sectors (Annex I or II).
- Important nuance for SaaS: even if you're under the thresholds, you may still be affected as a supplier. Essential and important entities must manage cybersecurity risks from their supply chain (Art. 21(2)(d)) — meaning your enterprise customers will send you their security questionnaires and contract clauses regardless of your own size.
- Digital providers get special treatment: DNS service providers, cloud computing service providers, data centre providers, CDNs, managed service providers (MSPs), and managed security service providers fall under Annex I as essential/important regardless of sector.
If none of that applies today, treat this checklist as preparation for your customers' vendor reviews — which is where most SaaS companies feel NIS2 first.
Step 2: The ten measures of Art. 21 — mapped to SaaS practice
Article 21 lists the risk-management measures member states must require. Here is what each means for a typical SaaS company:
| Art. 21 requirement | What it looks like in a SaaS company |
|---|---|
| Risk analysis & information system security policies | A written security policy, a threat model for your product, documented acceptance of major risks |
| Incident handling | A documented process: detect → triage → contain → notify (see Step 4) → post-mortem. Test it once a year. |
| Business continuity, backup, disaster recovery | Tested backups with defined RTO/RPO, a DR plan that isn't just a wiki page nobody has read |
| Supply chain security | Vendor register, security review of critical dependencies, DPA/security clauses with sub-processors |
| Security in acquisition, development and maintenance | Secure SDLC basics: dependency scanning, code review, secrets management, vulnerability disclosure policy |
| Policies to assess effectiveness of measures | Periodic testing — pentest reports, tabletop exercises, metrics reviewed by management |
| Cyber hygiene and training | Security training at onboarding and annually, MFA everywhere, patch discipline |
| Cryptography / encryption policies | TLS everywhere, encryption at rest for customer data, key management that is actually written down |
| HR security, access control, asset management | Least-privilege access, offboarding checklists, an inventory of systems holding customer data |
| MFA / secured communications | Multi-factor authentication for admin access and internal systems (explicitly required) |
Where to start if you can only do three things this quarter
- MFA on everything — cheapest control with the highest impact, and explicitly named in the directive.
- Write down incident handling — regulators judge you on process, not perfection. One page beats nothing.
- Fix the technical baseline of your public site — HTTPS/HSTS, security headers, no trackers firing before consent. This is what automated checks measure, and it's what shows up in your customers' scans of your domain.
Step 3: Supply chain cuts both ways
The most underrated part of NIS2 for SaaS: your position in two supply chains at once.
- Upstream: you must assess your own vendors — hosting, payment processors, analytics tools, email providers. Keep a simple register: who they are, what data they touch, what security commitments they've given you.
- Downstream: your enterprise customers must assess you. They will ask for your security documentation. Companies that answer vendor questionnaires in days instead of weeks win deals. A short, honest security overview (what's encrypted, how incidents are handled, where data lives) pays for itself in sales cycles.
Step 4: Incident reporting timelines
If you're an in-scope entity, significant incidents trigger a three-stage clock:
- 24 hours — early warning to the national CSIRT/authority
- 72 hours — incident notification with initial assessment
- Final report — within one month
You cannot improvise this during an outage. Decide today who declares an incident, who writes the notifications, and where the authority contact details live.
Step 5: Documentation is the deliverable
Regulators and enterprise buyers don't audit your infrastructure directly — they audit your evidence. For each Art. 21 measure, keep something reviewable: the policy document, the test result, the training log, the signed vendor clause. A quarterly compliance narrative that maps evidence to requirements turns "we're probably fine" into a defensible answer.
Check the technical baseline now
EUComply scans any website for the externally visible parts of the baseline: TLS/HSTS, security headers, consent mechanisms, legal pages, and pre-consent trackers. Free, no sign-up, works on any stack.
Run a free scan →EUComply Pro ($79/year per website) provides editable HTML document starters and an HTML report from the latest WordPress scan; full templates are sold separately.
Further reading
- NIS2 Vendor & Supply Chain Compliance Guide
- DORA vs NIS2 vs GDPR: What's the Difference?
- Interactive NIS2 Checklist
- NIS2 Board Liability Explained
How does EUComply compare with the established tools? See our head-to-head comparison — pricing, features and where each one falls short.