SaaSFort A compliance lead at a 140-person fintech opens a fresh Excel and types “NIS2 Article 21 controls” in the first cell. Two hours later, the spreadsheet has six rows, three colors, and one quietly-confused stakeholder. The hard part is not building the columns. The hard part is knowing what counts as evidence for each of the ten Article 21(2) measures — and how strict the column called “Status” really needs to be.
This article walks through every Article 21(2) measure with the populated answer auditors expect. The free Excel template gives you the structure. This guide gives you the fill.
The Ten Article 21(2) Measures (And Why Each Trips Teams Up)
Article 21(2) of NIS2 (EU 2022/2555) lists ten categories of cybersecurity risk-management measures that essential and important entities must implement. The categories are listed at the directive level — meaning they are deliberately broad. Member states translate them through national law (in Germany, §30 BSIG); the BSI then publishes interpretive guidance. The ten categories are operationally inseparable, which is why an audit by control rather than by document tends to land on one of two cliffs: either every row reads “Yes” with no evidence behind it, or every row reads “Partial” and nobody knows what to remediate first.
The template forces a discipline: each row must have status (Yes / Partial / No), priority (P0 / P1 / P2 / P3), evidence required, owner, and deadline. The COUNTIF readiness score at the bottom updates as you fill. You finish with a percentage you can defend in a board meeting and a remediation plan ranked by priority — not by whoever shouted loudest.
21(2)(a) — Risk analysis and information system security policies
What auditors expect: A documented information security policy, board-approved, reviewed at least annually. A risk register that maps assets to threats and to the controls in 21(2)(b)–(j).
Common failure: A policy document written three years ago by someone who has since left, never reviewed, never linked to the actual risk register. Status: No. Priority: P0.
Fillable evidence: policy document filename + version + last review date; risk-register link + last review date; named ISMS owner.
21(2)(b) — Incident handling
What auditors expect: A documented IR runbook, a 24-hour notification procedure aligned with Article 23, evidence of at least one tabletop or post-mortem in the past 12 months.
Common failure: Runbook exists in a Notion page; notification procedure is “ping the CTO on Slack.” Status: Partial. Priority: P0.
Fillable evidence: IR runbook URL; last tabletop date; 24h notification template (the incident-readiness bundle gives you all three).
21(2)(c) — Business continuity, backup management, crisis management
What auditors expect: BCP / DRP with stated RTO and RPO objectives, tested in the past 12 months. Backup integrity verification (not just backup existence).
Common failure: Backups run nightly. Restore has never been tested. Status: Partial. Priority: P1.
Fillable evidence: BCP/DRP document + version; last DR test date + result; backup integrity verification frequency.
21(2)(d) — Supply chain security
What auditors expect: A critical-supplier inventory, contractual security clauses with each, a vendor risk-assessment process, evidence that the assessment runs at onboarding and at renewal.
Common failure: “We use AWS” treated as the entire supply chain. Status: No. Priority: P0.
Fillable evidence: vendor inventory link; sample DPA / security addendum; vendor-risk-assessment process owner. The NIS2 supply chain compliance gap article covers what auditors actually look for here.
21(2)(e) — Security in network and information systems acquisition, development, and maintenance
What auditors expect: Vulnerability management policy, defined patching SLA by severity, software bill of materials (SBOM) for production dependencies, coordinated vulnerability disclosure policy.
Common failure: Patching is reactive — “we patch when something breaks.” No SLA, no SBOM, no disclosure policy. Status: No. Priority: P0.
Fillable evidence: patching policy + SLA matrix; SBOM tool / process; disclosure policy URL. See our API security best practices for what counts as “secure by default” in the development lane.
21(2)(f) — Policies and procedures to assess effectiveness of cybersecurity risk-management measures
What auditors expect: External vulnerability scans run regularly, KPI dashboard with mean time to detect (MTTD) and mean time to respond (MTTR), evidence that findings drive action.
Common failure: A pentest from 18 months ago is the only artifact. Status: Partial. Priority: P1.
Fillable evidence: external scanner / scan cadence; MTTD/MTTR baseline + current; remediation log linked to scan findings. A free SaaSFort scan populates this row in under an hour.
21(2)(g) — Basic cyber hygiene practices and cybersecurity training
What auditors expect: Annual security awareness training records for all employees. Critically: §38 BSIG mandates board-level cybersecurity training in Germany — most teams forget the board.
Common failure: Training exists for engineers, not for finance, sales, or the board. Status: Partial. Priority: P0 if the board has not been trained.
Fillable evidence: training platform; completion rate; board-training date. The board personal-liability article explains the §38 BSIG personal-liability angle that makes this row unusually load-bearing.
21(2)(h) — Policies and procedures regarding the use of cryptography
What auditors expect: TLS 1.2+ enforced everywhere, encryption-at-rest for sensitive data, documented key management, no deprecated ciphers in production.
Common failure: TLS 1.0 / 1.1 still enabled on a forgotten subdomain. Status: Partial. Priority: P0 (this is a free, automatic finding for any external scanner).
Fillable evidence: TLS configuration audit; encryption-at-rest scope; key-management procedure. The HTTP security headers guide covers the externally-visible portion.
21(2)(i) — Human resources security, access control policies, and asset management
What auditors expect: Role-based access control (RBAC), quarterly access reviews, privileged access management (PAM) for admins, joiner-mover-leaver process documented and executed.
Common failure: Access reviews happen “annually” — meaning never, or on an ad-hoc spreadsheet. Status: Partial. Priority: P1.
Fillable evidence: RBAC matrix; last access-review date; PAM tool; offboarding checklist. See our audit preparation evidence guide for what regulators ask to see here.
21(2)(j) — Multi-factor authentication, secured voice/video/text communications, secured emergency communication
What auditors expect: MFA enforced on all corporate access, FIDO2 / hardware tokens for privileged accounts, encrypted communication channels for incident response.
Common failure: MFA is enforced for engineers via SSO, but the marketing team still logs into HubSpot with email + password. Status: Partial. Priority: P0.
Fillable evidence: MFA enforcement scope; FIDO2 deployment for privileged users; emergency-comms channel.
How to Run the Audit (90-Minute Method)
The template fits a single 90-minute working session if you have the right people in the room.
Minute 0–15. Roles. One owner per row. The CTO does not own all ten. Spread the load: ISMS lead owns 21(2)(a), security ops owns (b) and (f), platform team owns (c) and (h), procurement owns (d), engineering leadership owns (e) and (i), HR/people ops owns (g), and IT owns (j). Without named owners, status defaults to “unknown” and the audit goes nowhere.
Minute 15–60. Status. Populate status (Yes / Partial / No) for each row using a strict rule: “Yes” requires a named artifact and a date in the past 12 months. Anything older or anything verbal is “Partial.” Anything with no artifact is “No.” This rule is harsh on first pass and accurate by design.
Minute 60–75. Priority. The template defaults to P0 / P1 / P2 / P3. The non-obvious rule: priority follows residual risk, not status. A “No” on 21(2)(j) MFA is P0 because the residual risk is catastrophic; a “No” on 21(2)(g) board training is also P0 because the personal-liability exposure is direct. A “Partial” on 21(2)(c) DR test is P1 because the residual risk depends on what got tested.
Minute 75–90. Owners and deadlines. Fill the “Owner” and “Deadline” columns for every row that is not “Yes.” A row without an owner is a row that will not change. A deadline pushed past October 2026 is a deadline you will not defend in front of the BSI.
The COUNTIF readiness percentage at the bottom of the template gives you a single number to present in a board meeting. Below 60% with three months to deadline is a board-level conversation. Below 40% is a board-level conversation that should happen this week.
What the Template Cannot Do
Three honest limitations.
It cannot generate evidence. A populated template is a self-audit, not a third-party attestation. The “evidence required” column lists what you need; the template does not produce it.
It cannot validate the technical controls behind the rows. A row that reads “TLS 1.2+ enforced” is true if and only if TLS 1.2+ is actually enforced — not if the policy says so. External validation is the missing half. A free SaaSFort scan populates the technical evidence for rows (e), (f), (h), and parts of (j) automatically.
It cannot make the §38 BSIG personal-liability problem go away. Board members of essential entities in Germany face direct personal liability for failures of organization. The template documents whether your board has been trained. Fixing “No” in that row is a calendar invite, not a spreadsheet update.
Use the Template, Then Validate
The Article 21 self-audit template is free, email-gated, and built for compliance teams without a €50K consultant budget. Its companion is the incident-readiness bundle, which operationalizes the Article 23 24-hour notification process — the operational counterpart to Article 21’s control framework.
Templates document. Scans verify. Use both before October 2026 and you walk into the next BSI conversation with a populated readiness percentage, a remediation plan ranked by priority, and an external scan validating the technical posture behind your “Yes” rows.
FAQ
Is the Article 21 self-audit template legally sufficient for NIS2 compliance?
No template is legally sufficient on its own. The template is the structured documentation regulators expect to see — but Article 21 compliance ultimately requires the underlying controls to actually exist and be tested. Use the template to map your posture; use external validation (scans, pentests, audits) to verify it.
What’s the difference between Article 21 and Article 23?
Article 21 mandates the controls — what you must implement to manage cybersecurity risk. Article 23 mandates the process — how and when you must notify authorities about significant incidents. They are operationally inseparable: weak Article 21 controls produce more Article 23 incidents.
How long should a populated audit take?
A first pass with the right people in the room is 90 minutes. Filling in evidence and remediating “No” rows takes weeks to months depending on starting posture. Most teams finish the structural audit in one session and treat remediation as a six-month project.
Do I need a separate audit for §30 BSIG vs. Article 21?
§30 BSIG is the German implementation of Article 21. The required controls are the same; the supervisory authority and case law differ. The template covers Article 21(2) directly — which is one-to-one with §30 BSIG for German essential entities.
Can the template be used by importance entities, not just essential entities?
Yes. Article 21 applies to both essential and important entities, with proportionality based on size and risk. Important entities can use the template as-is and adjust priorities based on their risk profile.
The October 2026 enforcement deadline is six months out. Six months is enough time to populate this template, prioritize the gaps, and validate the technical posture if work starts now. It is not enough time for companies that wait until September.
Download the free NIS2 Article 21 self-audit template — Excel, email gate only. Validate the technical posture rows with a free SaaSFort scan — 66 external checks against your live domain, A-F grade, NIS2 mapping. For the complete compliance framework, grab our free SaaS Security Playbook 2026. Companion: NIS2 24-hour incident notification template + tabletop.
Von der Theorie zur Praxis
Scannen Sie Ihre Domain kostenlos. Erste Ergebnisse in unter 10 Sekunden — ohne Registrierung.