The auditor asks for the March management-review minutes as they stood at sign-off, months earlier. NIS2 Article 20(1) puts approval on the management body, and Implementing Regulation (EU) 2024/2690 keeps saying 'documented' and 'at planned intervals': a close read of what those verbs assume, and the three properties any record-keeping setup needs to satisfy them.
The auditor asks for the March management-review minutes as they stood at sign-off, months earlier. NIS2 Article 20(1) puts approval on the management body, and Implementing Regulation (EU) 2024/2690 keeps saying "documented" and "at planned intervals": a close read of what those verbs assume, and the three properties any record-keeping setup needs to satisfy them.
An auditor's document request is rarely exotic: the minutes of the March management review, the results of the last two access reviews, the latest penetration test report. The uncomfortable part is what the request actually tests. The auditor doesn't just want the document — they want the document as it stood when it was signed off, months earlier. If your honest answer is a shared drive where management-review_final_v2.docx was last modified in May, you can show what the file says today. What it said in March, when it was approved? That's a matter of memory. So let's read the texts these requests come from, because their verbs assume more than a folder.
The place to start is the governance article. NIS2 Article 20(1) reads:
"Member States shall ensure that the management bodies of essential and important entities approve the cybersecurity risk-management measures taken by those entities in order to comply with Article 21, oversee its implementation and can be held liable for infringements by the entities of that Article."
Approval, oversight, and liability of the management body sit in a single sentence. NIS2 is a directive, so these obligations reach companies through national transposition rather than directly, but the sentence Member States transpose is that one. An approval someone can be held liable for is a dated act. Somewhere, an artifact has to show that it happened.
The Commission then spelled out what the measures look like in Implementing Regulation (EU) 2024/2690 of 17 October 2024. Its Article 1 scope covers digital infrastructure and digital providers (DNS service providers, TLD name registries, cloud, data centers, CDNs, managed and managed security service providers, marketplaces, search engines, social networks, trust services), so it directly binds only those entities; for everyone else under NIS2 it's the Commission's own concretization of the Article 21(2) measures, citable as exactly that. I read its Annex as one long documentation duty with dates attached. Watch the verbs pile up:
"At planned intervals" recurs throughout the Annex: roles and responsibilities (1.2.6), risk assessment results (2.1.4), independent reviews (2.3.4), vulnerability scans with recorded evidence of the results (6.10.2(b)). Even declining a requirement produces paper: where an entity considers a "where appropriate" requirement not applicable to it, Article 2(2) says it "shall in a comprehensible manner document its reasoning". Every one of these pairs a calendar with an artifact, and several pair the artifact with a management-body signature.
Before we can file the March minutes anywhere sensible, we need names for the piles. An ISMS produces three kinds of paperwork, and they behave differently:
ENISA's Technical Implementation Guidance on 2024/2690 (June 2025) shows how assessors read this. Its evidence examples for the policy-review point 1.1.2 include "Records of the management review" and "[r]eview comments or change logs" for the policy; for post-incident reviews it lists "Minutes of the post-incident review team." The guidance is non-binding, but the pattern is consistent: when a requirement says "documented", the artifact an assessor expects is a dated document.
The common failure is filing records in one of the other two piles. Push the March minutes through the policy workflow and you get an approval ceremony wrapped around a document that is itself the trace of an approval: heavy, and semantically circular. Attach them to a control as evidence and they sit oddly, because minutes rarely prove one control; they prove that a meeting took place and decisions were made. So most records end up in the third place, the shared drive, which lacks every property the next section derives.
Now read the Annex passages again, this time as the person who has to answer the audit request. A small specification falls out.
A defined kind, with a cadence and an owner. "At planned intervals" and "at least annually" attach to kinds of documents, not to individual files. The management review recurs, the access review recurs, the scan report recurs. So the question "what should exist right now, and who owes it?" needs an answer before the request arrives. That means every record belongs to a category, and the category, not the document, knows the interval and the responsible role. If the categories exist, a missing March review is visible in April. If they don't, it's discovered in the audit.
A status you can read. A document is a draft, in progress, or signed off. Filename conventions encode this badly; is final_v2 the second version of the final document, or the second attempt at finality? Status works better as a field with defined values, so that "show me everything not yet finalized" is a query rather than an archaeology session.
An immutable version, cut at sign-off. Let me be honest about the sourcing first: 2024/2690 contains no clause requiring you to prove a document's past states. It requires results to be documented, documentation to be retained for listed durations (1.1.1(h)), and the policy to carry its formal approval date (1.1.1(k)). The immutability requirement comes from the auditor's situation, not from the regulation's text. The review happened in March; the audit is in November; in between, the file sat writable. If sign-off doesn't freeze a version, what you hand the auditor is the current state plus your assertion that nothing meaningful changed since approval. A document that carries its approval date, as 1.1.1(k) demands, is far more convincing when the state that was approved is still producible. Marking a document final cuts a snapshot; later edits create version 2 and leave version 1 untouched.
None of this needs a particular product. A git tag on a repository of Markdown minutes satisfies all three properties. So does an exported PDF in a write-once bucket plus a spreadsheet of categories and due dates, as long as the discipline holds. Any system that can freeze a snapshot and hold a schedule qualifies.
Here I owe you a disclosure: we had to make these exact calls in devguard, so let me show you what we decided — and what we left out, deliberately. We ship it as a module called Records: authored, dated compliance documents grouped into categories the team defines itself — meeting minutes, access requests, whistleblower reports, pentest results — with versions that can only be added, never rewritten.
The kind lives in the category. A category carries an owner (a business role, not an individual user, so accountability survives personnel changes), a default template copied once into new entries, and an optional cadence: monthly, quarterly, semi-annual, or annual. We left out a continuous option on purpose, because a discrete dated document has no continuous mode. The next due date is computed from the last finalized entry plus the cadence; nothing auto-creates drafts.
The status is readable on each entry and has three values — draft, in progress, final — and each entry carries a short reference like RE-012.
The version is a snapshot. Marking an entry final records who signed it off and when, and cuts an immutable version: the first finalization produces version 1, the next version 2. Editing reopens the record; the committed versions stay untouched.
Two things we deliberately didn't build, and both have a cost. First, there's no approval chain. Anyone with write access to Records can set the status by hand; there's no approval gate the way policies have one. The module won't stop someone from marking minutes final before the meeting happened. If your process needs a sign-off gate, that gate is your meeting discipline and your write permissions; the tool records the outcome and doesn't referee it.
Second, records have no effect on control coverage. Linking a category to controls or risks helps findability and does no more than that. A record proves what was written and signed off, when; filing one ticks no control and changes no coverage status. I think that restraint is the design: the moment filing minutes flipped a coverage status, teams would file minutes to flip coverage statuses.
With the three properties in place, the audit request stops being a search and becomes a lookup: a category that expected the March minutes, a status that says they were signed off, and a frozen version that shows what was signed, by whom, on which date. That's the small, concrete case of the argument in audit-ready is a state you keep: an audit samples your normal operation, and the sample is only boring if the artifacts were being produced, and frozen, all along.
The Records module described above is part of devguard: devguard.ch/platform.
Angelo runs strategy and the relationships behind devguard. He spends his time with the teams who live with compliance day to day, and keeps what we build tied to what they actually need.
Start free, bring your frameworks, and keep the evidence attached as the work ships — no setup friction, no audit-week fire drill.
Start free, bring your frameworks, and keep the evidence attached as the work ships — no setup friction, no audit-week fire drill.