NIS2 requires policies to assess the effectiveness of your security measures. It is the obligation most programmes fail, because it cannot be met with a document.
---
The short answer
NIS2 Article 21(2)(f) requires policies and procedures to assess the effectiveness of cybersecurity risk management measures.
Not to *have* measures. To assess whether they work.
This is the obligation most programmes fail, and the reason is structural: it cannot be discharged by producing a document. Every other item on the Article 21 list can be answered with an artefact you write. This one requires an activity you perform, with a date, a scope, and a result — including results that were not good.
"we have an incident response policy" an artefact
"we tested it in March, and the escalation
path failed at step three" an assessmentOnly the second is evidence that anything works.
---
Where it sits in Article 21
The ten measures in Article 21(2) are usually read as a checklist, and nine of them behave like one:
(a) risk analysis and information system security policies
(b) incident handling
(c) business continuity, backup, crisis management
(d) supply chain security
(e) security in acquisition, development and maintenance,
including vulnerability handling and disclosure
(f) policies and procedures to assess the EFFECTIVENESS of the measures
(g) basic cyber hygiene and training
(h) cryptography and encryption policies
(i) human resources security, access control, asset management
(j) multi-factor authentication and secured communications(f) is not a tenth item on the same plane. It is a control over the other nine.
An organisation can satisfy (a) through (e) and (g) through (j) with well-written documents and still fail (f) completely — and a supervisory authority reading the file will see that immediately, because nothing in it says whether any of it works.
---
Why it is the hardest one
It requires you to look for bad news and write it down.
Every other obligation rewards a confident answer. This one rewards an honest one, and honesty here means recording that a control did not perform. That is uncomfortable in a document that an authority may read.
But the discomfort is inverted. A review that finds nothing, year after year, is not reassuring — it reads as a review that was not really performed. A review that finds problems and shows them being fixed is the strongest evidence a programme can produce, because it demonstrates the loop is closed.
An authority is not looking for perfection. It is looking for a system that notices.
---
What counts as an effectiveness assessment
There is no prescribed method, which is a freedom and a trap. What the outputs have in common:
A tabletop exercise with recorded outcomes. Not that it happened — what broke. Who could not be reached. Which decision took four hours that should have taken twenty minutes.
A restore test, actually restoring. Backups that have never been restored are not a backup capability, they are a backup expenditure. The test result is the evidence.
A penetration test or red team, with the findings and their disposition. Findings that were accepted rather than fixed count, provided the acceptance is recorded and reasoned.
A phishing simulation with a click rate. A number that changes over time is an effectiveness measurement in the plainest sense.
An access review that found stale accounts. The count of what was wrong is the output, not the confirmation that a review policy exists.
A supplier assessment that changed a supplier relationship. Evidence that (d) has teeth.
In every case the deliverable is a result, not a confirmation.
---
The design question that decides whether this is cheap or expensive
Assessments performed as a compliance activity cost a great deal and produce little. Assessments harvested from work you already do cost almost nothing.
compliance-driven an annual exercise, scheduled, scoped to be passed
work-harvested the incident you had in April, written up honestly
the restore you performed during a migration
the access review that ran in the joiners-leavers process
the pen test procurement already pays forMost organisations already generate effectiveness evidence and throw it away — because nobody recorded the result in a place that survives, with a date and a scope.
The cheapest possible implementation of Article 21(2)(f) is a register. One row per assessment: what was tested, when, by whom, what the result was, what changed as a consequence.
---
Where the management body enters
Article 20 makes management bodies approve the risk management measures, oversee their implementation, and be liable.
Effectiveness is precisely what oversight means. A board approving a set of measures without ever receiving evidence that they work is not overseeing anything — it is ratifying a document.
And under some national transpositions the consequence is personal, including temporary prohibition from management functions in essential entities. That changes the audience for this conversation: it is not a security topic, it is a governance one.
A one-page effectiveness summary to the board, twice a year, with the failures included, discharges more of Article 20 than any amount of policy approval.
---
How it looks under DORA, which is instructive
DORA is more prescriptive about the same instinct. Digital operational resilience testing is a defined programme, and for significant entities it includes threat-led penetration testing on a multi-year cycle.
NIS2 asks the same question with far less structure. That is not leniency — it means you must define your own method and defend it, which is harder than following a prescribed one.
A financial entity building for DORA gets NIS2 effectiveness largely for free. Everyone else has to design it, and design is where most programmes stop.
---
Five things to do this quarter
- 1Create the register. One row per assessment, with a result field. It can be a spreadsheet today.
- 2Backfill honestly from the last twelve months. The incident, the restore, the pen test, the access review. Most organisations have four or five entries already earned.
- 3Run one real test with a written outcome, and let it fail if it fails. That entry is worth more than the other four.
- 4Put a summary in front of the management body, with the failures included. This discharges Article 20 as well as 21(2)(f).
- 5Attach effectiveness to work you already do, so the register grows without a compliance project.
---
The reason this matters more than it looks
"Are your measures effective?" is the question an authority asks when it wants to know whether a programme is real.
Everything else in the file can be produced by a competent writer. The effectiveness register can only be produced by an organisation that actually does the work — which is precisely why it is the question worth asking, and the one worth being able to answer.
---
Assess your own measures — free, no account
- [Free readiness assessment](/assess) — which NIS2 obligations reach you, and which artefacts are missing
- [Compliance responsibility mapper](/resources/responsibility-mapper) — who owns each measure
- [Penalty calculator](/resources/penalty-calculator) — exposure on your own turnover
---
Further reading
→ Essential versus important under NIS2 → NIS2 incident reporting timelines → What is DORA → DORA and NIS2 overlap → What counts as evidence → One evidence set across five EU regulations
---
*This is regulatory information, not legal advice, and nothing here constitutes a compliance guarantee. NIS2 obligations arrive through national transposition and differ between Member States, including on supervision and management liability. Verify against the applicable national law and consult your competent authority or a qualified adviser.*
