NIS2 Article 21 Technical Controls: A B2B SaaS Implementation Guide

NIS2 Article 21(2) lists ten cybersecurity risk-management measures every essential and important entity must put in place. The directive language is deliberately product-agnostic. That works for a regulator. It doesn’t work for a B2B SaaS engineering lead at 22:00 who has to answer “which controls do we already have, and which ones do we need to ship?”

This guide is the engineering translation. Each Article 21(2) measure, the typical B2B SaaS architecture component that satisfies it, the verification an auditor or vendor-review reviewer actually checks, and the ship-it-this-quarter implementation. No theory. The stack assumed: a multi-tenant SaaS on a managed cloud (AWS / GCP / OVH / similar), Postgres or equivalent, a single production web tier, a CI/CD pipeline.

The Measure-to-Stack Map

Article 21(2) measure	Where it lives in your stack	What an auditor verifies
(a) Risk analysis & InfoSec policies	Confluence/Notion + a quarterly cadence	Policies dated within 12 months, signed
(b) Incident handling	Runbook + on-call + Article 23 packet	A timed tabletop in the last 12 months
(c) Business continuity	Backup automation + DR runbook	A successful restore drill, dated
(d) Supply chain security	SBOM + subprocessor register + DPAs	The list, the contracts, the review cadence
(e) Secure acquisition & vuln handling	Dependabot/Renovate + SAST + SCA	Patch SLAs met for last 90 days
(f) Effectiveness assessment	Internal audit + external scan	A dated A-F grade, control mappings
(g) Cyber hygiene & training	Onboarding LMS + phishing simulation	Completion records by name
(h) Cryptography	TLS config + at-rest encryption + secrets vault	TLS chain, KMS keys, no plaintext secrets
(i) HR security & access control	SSO + RBAC + offboarding playbook	A revocation log, not a promise
(j) MFA / continuous auth	Workforce MFA + customer MFA	Coverage percentage, exception list

The rest of this guide drills into the five measures that are pure engineering: cryptography, MFA, logging, vulnerability management, and incident response.

(h) Cryptography: TLS Is the Visible Half

A regulator and a customer auditor cannot inspect your KMS configuration from outside. They can inspect your TLS chain from a browser. Most NIS2 supply-chain reviews start there because it’s the cheapest signal.

Ship-this-quarter implementation:

• TLS 1.3 enabled, TLS 1.0 / 1.1 disabled, TLS 1.2 only with strong cipher suites (no CBC, no RC4, no 3DES). Audit with testssl.sh or the open methodology in our transparent grade spec.
• Full certificate chain served (the intermediate; not just the leaf). This breaks in roughly 1 in 5 B2B SaaS production scans.
• HSTS with max-age >= 31536000 and includeSubDomains. Add preload once you’ve verified subdomains.
• HTTPS-only cookies: Secure; HttpOnly; SameSite=Lax or Strict for session cookies.
• CT log presence: every production cert in at least two CT logs. Let’s Encrypt and Cloudflare handle this automatically; private CAs often don’t.

At rest: customer data encrypted with a CMK in your KMS. Database backups inherit the encryption. Per-tenant key isolation is not required by Article 21(2)(h) but reads well at the high end of an audit conversation.

Secrets: Doppler, AWS Secrets Manager, GCP Secret Manager, HashiCorp Vault. The verification is: there is no path from “fresh-clone repo” to “production credential” that doesn’t go through the secret manager. Search your codebase for sk_live_, AKIA, and BEGIN PRIVATE KEY before the auditor does.

(j) MFA and Continuous Auth: Two Surfaces, Different Risks

Article 21(2)(j) names MFA explicitly. It does not say “for some users.” For a B2B SaaS, MFA covers two distinct populations.

Workforce MFA (employees, contractors, vendors with access):

• SSO on every production-adjacent tool (Okta, Google Workspace, Microsoft Entra). No local admin accounts on cloud consoles.
• Hardware-key MFA (WebAuthn / FIDO2) for privileged roles: cloud-console admins, production-DB access, GitHub/GitLab org owners. SMS does not count for these.
• TOTP acceptable for non-privileged roles, but the migration path to WebAuthn should be documented.
• A “break-glass” account exists, is named, is in a sealed vault, and its use triggers a page.

Customer MFA (your end users):

• MFA available on the login form, default-on for admin roles, optional for end users (NIS2 is permissive here; your enterprise customers won’t be).
• TOTP minimum; WebAuthn for plans where it’s commercially feasible.
• SCIM-based offboarding for SSO-enabled customers. Manual offboarding gets missed.

Coverage metric to track: percentage of human production-access events authenticated by a phishing-resistant factor (WebAuthn or smartcard). An auditor doesn’t ask “do you have MFA”; they ask “what’s your coverage and what’s your exception list.”

(b) Logging: The Boring Control That Decides Audits

Auditors and incident responders need to reconstruct what happened, when, by whom, and from where. Logging is how you do that. The trap is that logging without retention is theatre, and retention without integrity is worse.

The minimum surface to log:

• Authentication events: success / failure / MFA challenge / SSO assertion / token issuance, with source IP and user-agent.
• Authorisation changes: role grants, scope changes, permission elevations.
• Production access: every console session, every kubectl/psql/SSM session, with the user identity (not “the on-call team”).
• Data-export events: any bulk read or download of customer data above a threshold (e.g., >1000 rows).
• Administrative API actions in your own product: who changed what tenant configuration when.

Retention and integrity:

• 12 months minimum for security-relevant logs. Longer if supply-chain reviewers ask for it (they often do).
• Logs shipped off the machine that generated them, ideally within seconds. A self-deleting log is the same as no log.
• Tamper-evident storage (S3 Object Lock, GCS Bucket Lock, an append-only datastore). The auditor’s test is “can someone with prod access delete a log entry without it being visible?”
• A queryable layer (Loki, OpenSearch, Datadog) so you can answer auditor questions in minutes, not days.

If you log everything but cannot answer “show me every production-DB access by user X in March,” your logging is incomplete.

(e) Vulnerability Management: The Cadence Auditors Check

Article 21(2)(e) covers vulnerability handling. The pattern that satisfies it for a B2B SaaS:

• SCA: Dependabot, Renovate, or Snyk on every repo. Auto-PR for non-major versions. Weekly review cadence for the rest. SBOMs (CycloneDX or SPDX) generated per build and retained per release.
• SAST: a baseline scanner (Semgrep OSS, CodeQL, Snyk Code) in CI. Block merges on new critical / high findings; let medium / low through with a tracking ticket.
• DAST: external scan against staging and production (this is what SaaSFort runs against the production domain in 60 seconds, mapped to NIS2 controls; run it from CI to catch regressions on each deploy).
• Container & infra scanning: Trivy / Grype on every image build. Block deploys on critical CVEs in the base image.
• Patching SLAs, written down: critical 7 days, high 30 days, medium 90 days. Track adherence. Auditors ask for the dashboard.

Disclosure surface: a public security.txt per RFC 9116 at /.well-known/security.txt. A monitored security contact email. A response SLA you actually hit. The lightest possible bug-bounty (responsible-disclosure page, no paid program required) covers Article 21(2)(e)‘s disclosure obligation.

(b) Incident Response: Runbook Plus Tabletop Plus Packet

Logging tells you what happened. The runbook tells your team what to do. Article 23 tells the regulator. The auditor packet tells the customer’s reviewer at the next vendor cycle.

The minimum stack:

• A named incident commander role (rotating, not “the CTO”). On-call rotation that includes nights and weekends.
• An incident runbook with at least: detection sources, severity classification, comms templates (internal, customer, regulator), the 24-hour / 72-hour / 30-day NIS2 reporting clock.
• A timed tabletop exercise once a year. Dated. Documented outcomes. Run the free incident readiness bundle once to seed it.
• Post-incident write-ups retained for at least five years.

The verification an auditor runs: “show me your most recent tabletop.” If the answer is “we don’t do those” or “informally,” it is logged as a gap. If the answer is a dated three-page write-up with named participants and a remediation register, it closes the line.

The Cross-Cutting Controls Most Teams Forget

Three controls live across measures and get missed in compliance-led implementations.

• (d) Supply chain: a subprocessor register, DPAs with each, an annual review. A subprocessor is anything that processes customer data on your behalf: your cloud, your email sender, your error tracker, your AI provider. The register is the artefact, not a vibe.
• (i) Access control: RBAC in your own product, not just AdminUser vs RegularUser. An auditor wants to see “what roles exist, who has them, when were they last reviewed.” A quarterly access review with a sign-off is the cheapest way to pass.
• (g) Hygiene & training: phishing simulation, security-awareness onboarding, refreshers. The deliverable is completion records by name, retained.

How This Pairs With the SaaSFort Workflow

The Article 21 self-audit template is the documentation layer. The free external scan is the verification layer for the technically testable measures (h), (e), and the externally visible parts of (b). The public trust page is what your enterprise customer’s auditor opens before the call. Together: documented, scanned, published. That is the operating pattern.

FAQ

Are all ten measures mandatory or risk-based? Mandatory in scope. The directive uses “where appropriate” for cryptography and MFA, which has been read narrowly by member-state regulators. Assume mandatory in the audit until told otherwise.

Is ISO 27001 certification a shortcut? It maps tightly to Article 21(2) and satisfies most measures in spirit. It does not exempt you from being able to demonstrate the controls externally. Many ISO-certified vendors still fail vendor reviews because the external posture grade is testable and the certificate isn’t.

What’s the minimum viable Article 21 program? Documented policies (a, c, g, i), a working incident runbook with one tabletop a year (b), TLS+MFA+secrets (h, j), Dependabot+SAST+external scan (e), a subprocessor register (d), and an external grade you can show on demand (f). Everything above this baseline is incremental risk reduction, not gating.

How does this relate to DORA or SOC 2? DORA layers on top for financial-sector entities (more granular ICT-risk and incident reporting). SOC 2 Trust Services Criteria overlap roughly 70% with Article 21; the differences are in incident-reporting timelines and supply-chain depth. None of them substitute for the others under audit.

---

The Article 21(2) measures aren’t a wishlist. They’re the controls a B2B SaaS team gets asked to demonstrate live, in 45 minutes, by a customer’s reviewer who has done this twenty times this quarter. Run a free scan to see the externally testable subset graded right now, then publish your trust page so the next review starts where it should: at verification.