NIS2 Article 21 evidence checklist: owners and proof
A security policy can explain what should happen. It cannot show that your service recovered during a restoration test.
If you lead security at a manufacturer and management has asked for evidence of progress, that distinction matters. You need an understandable connection between the risk, the activity, the proof and the person making the decision. You do not need a second documentation project disconnected from the people running the systems.
The second Network and Information Security Directive, known as NIS2, sets a cybersecurity baseline through Directive (European Union) 2022/2555. Article 21 addresses cybersecurity risk-management measures. This NIS2 Article 21 evidence checklist turns its ten minimum areas into a working evidence plan.
The suggested records below are practical examples, not a legal minimum document list. The applicable national framework, sector and actual risks determine what is appropriate. Software cannot make legal determinations, and a completed worksheet does not establish compliance.
What matters this week, and what can wait
This week, confirm the legal entity and services you are working on, identify owners for the ten areas and test one important evidence trail. Start with something operationally meaningful: restoring a service, removing privileged access or escalating a significant incident.
Ask the owner to show the record, its result and the follow-up decision. If a critical activity has never been tested, treat that as an operational gap rather than a missing attachment.
A perfectly formatted policy library and a percentage-complete dashboard can safely wait. Known urgent weaknesses and applicable reporting duties cannot. The aim is a reliable account of what works, what does not and who is correcting it.
Confirm scope and national requirements first
Use the NIS2 scope checker as an initial indication. Check actual activities, enterprise size and relationships, size-independent cases and the national law. A supplier questionnaire is not itself proof that your organisation is directly in scope.
For a manufacturer, pay particular attention to the specific entity types in the Directive's annexes and the applicable national implementation. Do not assume every manufacturer is covered merely because manufacturing appears as a sector.
Article 21(1) requires appropriate and proportionate technical, operational and organisational measures. The assessment takes account of factors including exposure to risk, size, likelihood and severity of incidents, implementation cost, relevant standards and the state of the art.
Its all-hazards approach includes the physical environment, not just malicious activity. Power failure, fire and accidental changes may matter to service continuity as much as an external attack.
Separate management decisions from technical proof
Article 20 requires management bodies to approve the cybersecurity risk-management measures and oversee implementation. It also addresses management training. A security lead's working document is not the same thing as a management decision.
Keep two connected trails:
- Decision trail: the risk or issue, choices considered, approval, resources, conditions and accountable management role.
- Operating trail: the actual review, test, configuration, exercise or corrective action, including scope, result and unresolved limitations.
A management minute can show that a restoration programme was approved. A test record can show what recovered and what failed. Neither replaces the other.
Where evidence is reviewed by someone involved in producing it, make that visible and arrange proportionate challenge. Do not confuse a second signature with independent thinking.
The Article 21 evidence checklist
The first column paraphrases Article 21(2). The remaining columns are suggested ways to demonstrate implementation, not text from the law. Role titles are examples; assign real owners in your organisation.
| Article 21(2) area | Practical activity | Suggested evidence | Example accountable role |
|---|---|---|---|
| (a) Risk analysis and information system security policies | Assess risks and approve the security approach | Approved policies, dated assessment, treatment decisions and review record | Security lead and management |
| (b) Incident handling | Detect, assess, contain and learn from incidents | Response plan, incident log, exercise results and actions | Incident response lead |
| (c) Business continuity, including backup and disaster recovery, and crisis management | Test recovery of important services and crisis decisions | Recovery priorities, restoration results, dependency checks and exercise record | Operations lead |
| (d) Supply chain security, including direct suppliers and service providers | Review the services and dependencies you rely on | Supplier inventory, risk-based review, contract decisions and follow-up | Procurement and service owners |
| (e) Security in acquisition, development and maintenance, including vulnerability handling and disclosure | Define requirements, manage changes and address vulnerabilities | Security requirements, test results, patch decisions and vulnerability records | Engineering or technology lead |
| (f) Policies and procedures to assess effectiveness | Test whether measures work | Review plan, measurement results, findings and corrective actions | Assurance lead |
| (g) Basic cyber hygiene and cybersecurity training | Teach relevant behaviours and check understanding | Training coverage, role-based material, checks and follow-up | People and security leads |
| (h) Cryptography policies and procedures, and encryption where appropriate | Define protection and key-management responsibilities | Approved approach, configuration checks and key-access reviews | Technology lead |
| (i) Human resources security, access control policies and asset management | Maintain inventories and manage access throughout role changes | Asset records, access decisions and joiner, mover and leaver checks | People, asset and system owners |
| (j) Multi-factor or continuous authentication, secured voice, video and text communications, and secured emergency communication systems, where appropriate | Protect authentication and test communication fallbacks | Coverage review, exceptions, secured-channel decisions and fallback test | Identity and continuity leads |
Multi-factor authentication requires more than one distinct category of authentication factor, rather than simply two passwords. Record coverage and exceptions for the systems that matter, not just a screenshot showing that the feature exists somewhere.
Do not treat the ten rows as isolated projects. A supplier failure can affect continuity; a failed access review can change a risk assessment; a restoration exercise can reveal an incident communication problem.
Download the evidence worksheet
Use the blank Article 21 worksheet, the fictional worked examples, or the workbook containing both. Downloads require no registration. The blank worksheet includes a row for each Article 21(2) area, ready for your details.
For each activity, record:
- Legal entity, service and relevant national requirement.
- Measure and specific claim being tested.
- Accountable owner, evidence provider and reviewer.
- Approved decision reference and operating-evidence location.
- Coverage period, collection date and review cadence.
- Result, limitations and corrective action.
- Action owner, due date and next review.
- Source checked, source-review date and unresolved legal question.
The example sheet is wholly fictional. It illustrates the difference between a record being available and the underlying activity being effective. It does not describe a client, regulator-approved programme or model legal answer.
Keep confidential evidence in a protected system and use controlled references in the worksheet. A public download is not a suitable place for your actual system names, vulnerability details or personal information.
Review one evidence trail before expanding the programme
Take business continuity as a starting point. Ask the operations owner to select an important service and show its dependencies, recovery expectations and latest restoration result.
Check whether the result covers the service rather than just one data file. Confirm who judged success and how failed steps were handled. Record the next action and the management decision needed if recovery expectations cannot be met.
Then apply the same review questions elsewhere:
- Does the evidence cover the right entity, service and period?
- Does it demonstrate the claimed activity, rather than merely an intention?
- Are failures and exceptions visible?
- Can an authorised reviewer retrieve the original?
- Has someone acted on the result?
A valid failed-test record is useful evidence. It should not be turned into a passing control status. Article 21(4) addresses taking necessary, appropriate and proportionate corrective measures without undue delay when non-compliance with the measures is found.
Set review cadence from the activity, not the spreadsheet
There is no universal frequency in this article for every organisation and measure. Use applicable legal requirements, risk, operational change and the nature of the control to determine timing.
A recurring access review needs records for its agreed review periods. A material system change may require fresh checks before the next routine date. A closed action needs verification, not merely a new status label.
Retain the reason for the cadence, the next review date and event-based triggers. This makes the programme explainable when someone asks why one measure is reviewed more often than another.
Use implementing guidance within its proper scope
Commission Implementing Regulation 2024/2690 sets detailed requirements and significance criteria for specified digital infrastructure, technology-service and digital providers, including trust service providers. It is not a universal manufacturing checklist simply because it supports NIS2.
The European Union Agency for Cybersecurity, known as ENISA, publishes technical implementation guidance for that Regulation, with practical advice, evidence examples and mappings. The guidance is advisory and does not replace national supervisory arrangements. Do not describe every example as a mandatory record for every entity.
Check whether the Regulation applies to your entity and which national or sector guidance you should use. Keep that applicability decision with your sources rather than copying a large control catalogue without context.
Connect evidence to everyday work
GRCompliance Core documents controls, policies, risks, evidence linked to controls and an audit workspace. You can use those building blocks to organise supporting records; that does not mean the software implements every legal requirement for you.
Start with one worksheet row and evaluate how to represent its control and evidence in your chosen edition. Keep decision context and limitations in a supporting record where needed. Do not assume the worksheet has an automatic import or that a status score is a legal conclusion.
Use the incident reporting rehearsal guide for the separate reporting handoffs. Try the live demo with fictional information only, or inspect the free open-source Core. No certification or compliance outcome is guaranteed.
Frequently asked questions
Is this Article 21 checklist a mandatory document list?
No. The legal measures are mandatory where applicable, but these evidence examples are practical suggestions. Check national law, sector requirements and your actual risks before deciding what records are sufficient.
Can an approved policy prove implementation?
It can support the decision trail. You normally also need relevant operating records to show that the activity happened and to understand its result. Approval alone does not demonstrate effectiveness.
Does the implementing Regulation apply to every manufacturer?
No. Regulation 2024/2690 identifies particular types of entities. Confirm whether your actual services bring an entity within its scope rather than treating it as a universal sector checklist.
Can the worksheet or software certify compliance?
No. They organise work and evidence. Software cannot make legal determinations, and neither a completed worksheet nor a dashboard guarantees conformity, certification or a regulator's acceptance.
Sources
Reviewed 7 November 2026. Measure labels are paraphrased; evidence and owner suggestions are editorial guidance.
Try the live demo
Open the public demo to see the product. Use fictional data only.