What Auditors Actually Ask For Under NIS2 Article 21

NIS2 Article 21(2) lists ten risk-management measures. Most teams read the list, write a policy for each, and file it. Then an auditor or an enterprise customer’s reviewer asks one question: “Show me.” A policy that says you use strong encryption is not evidence. A scan that shows TLS 1.3 on every endpoint is.

This is the gap that loses accounts. The measure is written down. The proof is missing.

Below, four of the Article 21 measures that map directly to your external posture, what the auditor actually asks for each one, and the concrete artifact that answers it.

The Pattern: Policy vs Proof

Article 21 is principles-based. It says you must take “appropriate and proportionate technical, operational and organisational measures.” It does not list a single product or setting. That vagueness is deliberate, and it is also why audits drag.

A reviewer cannot grade a principle. So they convert each measure into a check they can pass or fail. Their mental model is simple:

1. Does the measure exist on paper?
2. Is it actually live on your systems right now?
3. Can you show me without a two-week scramble?

Question 1 is your policy doc. Questions 2 and 3 are technical evidence. The rest of this article is about questions 2 and 3.

TLS and Encryption in Transit (Art. 21(2)(h))

Article 21(2)(h) covers “the use of cryptography and, where appropriate, encryption.” For a SaaS, the first thing a reviewer checks is what an outsider sees on your public endpoints.

What they ask:

• Which TLS versions does your domain accept? TLS 1.0 and 1.1 are a fail in 2026.
• Are weak cipher suites disabled?
• Is HSTS set, and is the certificate chain complete and valid?

What proves it: a live scan of your domain showing TLS 1.2 and 1.3 only, no deprecated ciphers, HSTS present, and a valid certificate chain. A screenshot of your config file is weaker, because it shows intent, not the running state. The reviewer trusts what is observable from outside. For the full breakdown of how grading works here, see our guide on TLS and SSL configuration for SaaS security grade.

Patch Cadence and Vulnerability Handling (Art. 21(2)(e))

Article 21(2)(e) covers “security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure.” Translation: you patch, and you can prove the patch window is short.

What they ask:

• How fast do you patch a critical CVE? A defensible answer is 14 days or less for critical, 30 for high.
• Are you running outdated JavaScript libraries with known CVEs on your public app?
• Is any server software version exposed in headers and is it current?

What proves it: an external scan that flags outdated JS libraries, exposed software versions, and known-vulnerable components, paired with a short note on your patch SLA. The auditor wants to see that the scan is recent. A report from six months ago tells them nothing about today. A scan dated this week tells them the control is live.

Access Control and Exposure (Art. 21(2)(i) and (j))

Article 21(2)(i) covers human resources security and access control policies. Article 21(2)(j) adds multi-factor authentication and secured communications. For external posture, the reviewer checks what you have left open to the internet.

What they ask:

• Are admin panels, staging environments, or dashboards reachable from the public internet?
• Are there exposed source maps or debug endpoints leaking internal structure?
• Is MFA enforced on the systems you control?

What proves it: a scan that maps your external attack surface and flags exposed admin panels, open directories, and source map leaks. Access-control policy lives in your IdP, but the auditor’s first move is to look for what should not be reachable and is. One exposed admin login does more damage to your audit than a missing policy line.

Incident Logging and Detection (Art. 21(2)(b) and (g))

Article 21(2)(b) covers incident handling. Article 21(2)(g) covers basic cyber hygiene and security monitoring. The reviewer wants to know you would notice an incident, and that you log enough to report one inside the NIS2 24-hour early-warning window.

What they ask:

• Do you have security headers that reduce attack surface and support detection?
• Do you log access and changes in a way you could hand to a regulator?
• Is there a documented path from detection to the 24-hour notification?

What proves it: security headers present and correct on every response, plus a logging and notification runbook. The scan covers the external hygiene half. The runbook covers the process half. We walk through the reporting clock in the NIS2 24-hour incident notification template.

How Auditors Score You in Practice

Across all four measures, the reviewer is doing the same thing: turning a written principle into an observable check, then asking you to show the running state. The teams that pass are not the ones with the thickest policy binder. They are the ones who can produce a current, mapped report in the meeting.

This is also why a self-attestation form rarely closes the question. The auditor has read attestations before. What moves the call forward is a third-party-readable artifact tied to your live domain. If you want the full live-call playbook, read how to prove security posture in a NIS2 vendor audit call, and for a fixed timeline, the 30-day NIS2 audit checklist.

The Shortcut: A Mapped Evidence PDF

Here is what SaaSFort does. We scan your domain across 60 external checks. Then we map each finding to the Article 21 measure it answers: TLS to 21(2)(h), outdated libraries to 21(2)(e), exposed panels to 21(2)(i), security headers to 21(2)(g). The output is one PDF, A to F graded, that you hand to the auditor or attach to the security review.

It costs 39 EUR for the one-time audit pack. No subscription, no card on the first scan. You see the sample before you decide: SaaSFort NIS2 sample audit report.

The point is not that the PDF replaces your policies. It does not. The point is that it answers question 2 and question 3 from the top of this article in 60 seconds, so the audit call stops being a scramble and becomes a screen-share.

Get your Article 21 evidence pack for 39 EUR

FAQ

Does a SaaSFort scan make me NIS2 compliant? No. NIS2 compliance is broader than external posture. The scan produces evidence for the technical measures an auditor can observe from outside: encryption, vulnerability exposure, access exposure, and hygiene headers. It does not cover internal governance, training, or supply-chain contracts.

Which Article 21 measures does the report map to? The external checks map to 21(2)(b) incident handling hygiene, 21(2)(e) vulnerability handling, 21(2)(g) cyber hygiene and monitoring, 21(2)(h) cryptography, and 21(2)(i) and (j) access control and MFA exposure. The PDF labels each finding with its measure.

How recent does the evidence need to be? Treat external evidence like a perishable. A reviewer trusts a scan from this week over one from last quarter, because posture drifts as you ship. Re-scan before any audit call.

Is 39 EUR a subscription? No. The audit pack is a one-time report. Run the free scan first, see your grade, then buy the mapped PDF only if you need the document.