NIS2 Technical Security Requirements: What SaaS CTOs Must Implement

Germany’s BSI has already fined three organizations for NIS2 non-compliance in Q1 2026. None of them were hacked. They simply couldn’t demonstrate that the technical security measures required by Article 21 were in place. October 2026 is the EU-wide enforcement deadline, but if you sell SaaS to German enterprises, you’re already late.

This article breaks down every technical requirement in NIS2 Article 21 and maps it to specific actions in a typical SaaS stack. No theory — just what you need to build, configure, or buy.

Article 21 at a Glance: The 10 Required Measures

NIS2 Article 21(2) lists ten categories of security measures that essential and important entities must implement. As a SaaS vendor in their supply chain, your enterprise customers will require you to demonstrate compliance with most of these — particularly (a), (d), (e), and (g).

#	Measure	SaaS Relevance
(a)	Risk analysis and information system security policies	High — your ISMS documentation
(b)	Incident handling	High — breach notification SLAs in contracts
(c)	Business continuity and crisis management	High — DR/BCP for your SaaS platform
(d)	Supply chain security	Critical — you ARE the supply chain
(e)	Security in network and systems acquisition, development, maintenance	Critical — your SDLC and vulnerability management
(f)	Policies for assessing cybersecurity measures effectiveness	High — continuous monitoring and testing
(g)	Basic cyber hygiene practices and training	Medium — applies to your team
(h)	Policies on cryptography and encryption	High — TLS, data-at-rest, key management
(i)	Human resources security, access control, asset management	High — IAM policies, RBAC
(j)	Multi-factor authentication and secured communication	Critical — MFA for your product and internal access

Measure (a): Risk Analysis and Security Policies

Your enterprise buyers won’t accept “we follow best practices” as an answer anymore. They need to see a documented risk assessment methodology.

What to implement:

A risk register covering your SaaS application, infrastructure, and data flows. Update it quarterly at minimum.
Information security policies covering acceptable use, access control, change management, and incident response. ISO 27001 Annex A provides the structure — you don’t need certification to follow it. (ISO 27001 guide for SaaS vendors)
Evidence that leadership has reviewed and approved these policies. NIS2 Article 20 holds management bodies personally liable for cybersecurity failures — your CEO needs to sign off.

Priority: Start here. Every other measure references your policies. Budget 2-3 weeks for initial documentation if starting from scratch.

Measure (d): Supply Chain Security — You’re on Both Sides

This is where SaaS vendors face a dual obligation. Your NIS2-regulated customers must assess YOUR security posture. And you must assess the security of YOUR dependencies — cloud providers, third-party APIs, open-source libraries.

What to implement:

An SBOM (Software Bill of Materials) generated from your CI/CD pipeline. Tools like Syft or CycloneDX automate this.
A vendor risk assessment process for your own critical suppliers (AWS/GCP, payment processors, auth providers).
Contractual security clauses with your own vendors, including incident notification timelines that match your commitments to customers.
A Deal Report — a shareable security posture summary your buyers can attach to their NIS2 supply chain documentation.

According to SaaSFort analysis, 67% of enterprise DDQs now include a dedicated NIS2 supply chain section separate from standard SOC 2 questions. If you can’t produce supply chain evidence on demand, you’re losing deals to vendors who can. (More on NIS2 supply chain requirements)

Measure (e): Secure Development and Vulnerability Management

This is the measure that directly tests your engineering maturity. NIS2 doesn’t prescribe specific tools, but enterprise buyers will map your answers to recognized frameworks.

Minimum viable implementation:

OWASP Top 10 scanning on every release — automated in CI/CD, not just annual pen tests. (OWASP Top 10 for SaaS)
Dependency vulnerability scanning — Dependabot, Snyk, or Trivy running on every PR.
Security regression testing — tests that verify past vulnerabilities don’t reappear.
Responsible disclosure policy — a public security.txt and a process for handling external reports.
Patch management SLA — critical vulnerabilities remediated within 72 hours, high within 14 days.

Enterprise security questionnaires now routinely ask: “When was your last vulnerability scan?” If the answer is more than 30 days ago, you’re flagged. Continuous monitoring isn’t optional — it’s what procurement teams verify first.

Measure (h): Cryptography and Encryption

NIS2 requires “policies and procedures regarding the use of cryptography and, where appropriate, encryption.” For SaaS, this translates to three non-negotiable items:

TLS configuration:

TLS 1.2 minimum, TLS 1.3 preferred. Disable TLS 1.0 and 1.1 entirely.
HSTS header with max-age of at least one year and includeSubDomains.
Strong cipher suites only — no RC4, no 3DES, no SHA-1.

Data at rest:

AES-256 for database encryption. Both AWS RDS and GCP Cloud SQL support this natively.
Encryption key rotation on a defined schedule (annually at minimum).

Key management:

Use your cloud provider’s KMS (AWS KMS, GCP Cloud KMS). Don’t roll your own.
Document who has access to encryption keys and how access is revoked.

Run a scan of your own domain to verify your TLS configuration meets these requirements. SaaSFort’s free security scan checks TLS version, cipher strength, HSTS, and certificate validity in under 15 seconds.

Measure (j): Multi-Factor Authentication

NIS2 Article 21(2)(j) specifically calls out “the use of multi-factor authentication or continuous authentication solutions.” This applies both to your internal systems and to your product.

Internal (your team):

MFA on all production infrastructure access (AWS console, K8s, CI/CD).
MFA on code repositories. A compromised GitHub account is a supply chain attack.
Hardware security keys for admin accounts — TOTP as minimum for all staff.

Product (your customers):

Offer MFA for all user accounts. Enterprise buyers expect TOTP support at minimum.
Support SSO via SAML 2.0 or OIDC for enterprise customers — this is a deal requirement, not a feature request.
Session management: idle timeout, concurrent session limits, forced re-authentication for sensitive actions.

Incident Response: The 24-Hour Clock

NIS2 requires entities to report significant incidents within 24 hours (early warning) and provide a full incident notification within 72 hours. Your enterprise customers will flow this obligation down to you contractually.

What this means for your SaaS:

An incident response playbook that your team can execute without improvising. Include classification criteria, escalation paths, and communication templates.
A logging and alerting stack that detects anomalies in real-time — not just application errors, but unauthorized access patterns, data exfiltration signals, and configuration drift.
Pre-drafted notification templates for your enterprise customers. When an incident hits, you need to communicate fast. Template first, details second.
A post-incident review process. NIS2 supervisory authorities can request your incident analysis — make it structured and defensible.

The Implementation Priority Matrix

Not every measure carries equal weight for SaaS vendors. Based on what enterprise procurement teams audit first and what carries the highest penalty risk, here’s the order:

Priority	Measure	Why First
Week 1-2	(h) Cryptography + (j) MFA	Testable externally — buyers can verify before signing
Week 3-4	(e) Secure development	Produces continuous evidence (scan reports, SBOM)
Week 5-6	(b) Incident handling	Contractual requirement in every enterprise deal
Week 7-8	(d) Supply chain + (a) Policies	Documentation that supports all other measures
Week 9-10	(f) Effectiveness assessment	Set up continuous monitoring cadence
Week 11-12	(c) Business continuity + (g) Training + (i) Access control	Important but less frequently audited by buyers

This gives you a 12-week sprint from today to a defensible NIS2 posture before the October deadline. Need a more detailed week-by-week plan? See our 90-day NIS2 action plan.

How SaaSFort Helps You Prove Compliance

SaaSFort’s scanner runs 60 checks across 21 categories that map directly to NIS2 Article 21 measures (e), (h), and (j). One scan produces a Deal Report — a branded, shareable security posture document your enterprise buyers can attach to their NIS2 supply chain file.

Three things this solves:

TLS and encryption verification — measures (h) compliance in under 15 seconds
Continuous evidence — scheduled scans prove measure (f) effectiveness assessment
Supply chain documentation — your Deal Report satisfies measure (d) for your customers

Run a free scan now →

FAQ

Does NIS2 apply directly to SaaS vendors?

It depends on size and sector. SaaS companies with 50+ employees or €10M+ revenue that provide digital services in the EU may be classified as “important entities” under NIS2. But even smaller vendors are affected indirectly: their NIS2-regulated customers must assess supply chain security, which means vendor security audits. (Full vendor assessment guide)

What are the penalties for NIS2 non-compliance?

Essential entities face fines up to €10M or 2% of global annual turnover (whichever is higher). Important entities face up to €7M or 1.4% of turnover. NIS2 Article 20 also introduces personal liability for management bodies who fail to oversee cybersecurity measures.

How is NIS2 different from SOC 2 or ISO 27001?

NIS2 is a legal requirement with enforcement and fines. SOC 2 and ISO 27001 are voluntary certifications. However, having ISO 27001 certification covers approximately 70% of NIS2 technical requirements, making it the fastest path to demonstrable compliance.

Can SaaSFort generate NIS2 compliance evidence?

Yes. SaaSFort’s scan reports map findings to NIS2 Article 21 measures and produce a Deal Report that serves as supply chain security evidence. The NIS2 audit-ready export structures your scan results specifically for NIS2 supervisory reporting.

What’s the difference between NIS2 and DORA?

DORA applies specifically to financial sector entities and their ICT service providers. NIS2 covers 18 sectors broadly. If you serve financial services customers, you likely need to comply with both — but DORA’s requirements are more prescriptive on operational resilience testing.