NIS2, DORA, NIST and the ISO management-system core each pair a review interval with a list of events, and only the interval fits in a calendar. Here is what each text asks for, who it names as reviewer, and what the review has to leave behind.
NIS2, DORA, NIST and the ISO management-system core each pair a review interval with a list of events, and only the interval fits in a calendar. Here is what each text asks for, who it names as reviewer, and what the review has to leave behind.
Point 1.1.2 of the annex to Commission Implementing Regulation (EU) 2024/2690 is one sentence long, plus a short second one:
"The network and information system security policy shall be reviewed and, where appropriate, updated by management bodies at least annually and when significant incidents or significant changes to operations or risks occur. The result of the reviews shall be documented."
The sentence holds four separate requirements. There is a floor on the interval: at least annually. There is an event trigger: significant incidents, or significant changes to operations or risks. There is a named reviewer: the management bodies. And there is a record: the result is documented. Point 1.1.1(k) adds a fifth detail on the policy itself. It has to "indicate the date of the formal approval by the management bodies".
A review date in a spreadsheet answers the first of these. The other three need something else.
A note on scope. The Implementing Regulation binds a specific list of NIS2 entities: DNS service providers, TLD registries, cloud and data center providers, content delivery networks, managed and managed security service providers, online marketplaces, search engines, social networks and trust service providers. For everyone else it is a reference text, and a useful one, because it puts the interval, the events, the reviewer and the record into one sentence.
Most of the texts leave the number to you.
NIST SP 800-53 Rev. 5 opens nineteen of its control families with a policy-and-procedures control. AC-1, for access control, reads at point (c):
"Review and update the current access control:1. Policy [Assignment: organization-defined frequency] and following [Assignment: organization-defined events]; and2. Procedures [Assignment: organization-defined frequency] and following [Assignment: organization-defined events]."
The policy wording is identical in all nineteen, AC-1 through SR-1. The frequency is yours to assign. So are the events. AC-1(b) also asks you to designate "an [Assignment: organization-defined official]" to manage the policy. The catalog leaves you three blanks: an interval, a list of events, and a person.
The ISO management-system core says even less about policies. ISO/IEC 27001 is built on the Harmonized Structure, the common text that ISO's management-system standards share. In its normative text, "planned intervals" appears twice: for internal audit in 9.2.1, and for management review in 9.3.1:
"Top management shall review the organization's XXX management system, at planned intervals, to ensure its continuing suitability, adequacy and effectiveness."
ISO/IEC 27001 adds its own text on top of this core. The standard is paywalled, and I have neither quoted nor paraphrased it here. The common text asks you to plan the interval and gives you no number.
The EU texts set a floor. Point 1.1.2 says "at least annually". DORA Art. 6(5) says the ICT risk management framework, which under Art. 6(2) includes its policies, is reviewed "at least once a year, or periodically in the case of microenterprises". A floor is not an interval. Across the annex of 2024/2690, "planned intervals" appears 30 times and "at least annually" only three times: for the security policy, for the risk assessment and treatment plan, and for the assignment of people to roles. Everywhere else the interval is left to the entity.
No text lets the calendar stand alone. Each one names events next to the interval.
DORA Art. 6(5) gives the longest list:
"The ICT risk management framework shall be documented and reviewed at least once a year, or periodically in the case of microenterprises, as well as upon the occurrence of major ICT-related incidents, and following supervisory instructions or conclusions derived from relevant digital operational resilience testing or audit processes."
The discussion under NIST AC-1 lists "assessment or audit findings, security incidents or breaches, or changes in laws, executive orders, directives, regulations, policies, standards, and guidelines". The Harmonized Structure puts the events into the management review itself: 9.3.2 requires the review to include "changes in external and internal issues that are relevant to the XXX management system" and "changes in needs and expectations of interested parties that are relevant to the XXX management system".
| Text | Interval | Events that pull the review forward | Who reviews | What it leaves behind |
|---|---|---|---|---|
| NIS2 IR 2024/2690, 1.1.2 | At least annually | Significant incidents; significant changes to operations or risks | Management bodies | "The result of the reviews shall be documented" |
| DORA Art. 6(5); RTS 2024/1774 Art. 27 | At least once a year (periodically for microenterprises) | Major ICT-related incidents; supervisory instructions; testing or audit conclusions | Function named in the report | A report on the review, available to the authority on request |
| NIST SP 800-53 AC-1 | Organization-defined | Organization-defined; the discussion lists findings, incidents, legal change | Organization-defined official | Updated policy and procedures |
| ISO Harmonized Structure 9.3 | Planned intervals | Changes in internal and external issues and in interested parties' needs, as review inputs | Top management | "Documented information … as evidence of the results" |
The interval column is the easy one. Put a date on it and a tool can remind you. The events column is harder, because the event does not happen in the policy. It happens in the incident register, in a supervisor's letter, in an audit report, in a reorganization, in a new contract. Nothing on the policy's page changes on the day a significant incident is closed. Someone has to carry that fact across to the policy owner and ask whether the text still holds.
Suppose a significant incident in March shows that the access policy no longer matches how access is actually granted. If the only trigger is the calendar, that finding waits for the annual review in January. The interval was honored, the event trigger was not, and the review log shows nothing wrong.
In practice, write the event list down next to each policy, as concretely as you can: "any incident classified significant", "any change of hosting provider", "any new regulation in scope". Then name who is responsible for noticing the event and raising the review. The owner of the incident register or the change process is better placed for that job than the policy owner, who may never see the event.
Point 1.1.2 says "reviewed and, where appropriate, updated". Point 1.2.6 uses the same pair for roles and responsibilities. The pair separates two acts. The review is a judgment about whether the text still fits. The update is an edit, and it only follows when the judgment says so.
That makes "no change needed" a legitimate outcome of a review, and it still has to leave a record. 1.1.2 requires the result to be documented, whatever the result is. The Harmonized Structure asks for "review and approval for suitability and adequacy" when documented information is created and updated (7.5.2), and for documented information "as evidence of the results of management reviews" (9.3.3). A policy whose last version is two years old and whose file shows no review since tells an auditor one of two things, and neither helps you: nobody reviewed it, or somebody did and left no trace.
DORA's technical standards go furthest on what the record contains. Commission Delegated Regulation (EU) 2024/1774 Art. 27(2) lists the content of the report on the framework review. Among other points, the report includes:
"(c) a description of the reason for the review of the ICT risk management framework in accordance with Article 6(5) of Regulation (EU) 2022/2554.;(d) the start and end dates of the review period;(e) an indication of the function responsible for the review;"
It also asks for "a list of past reviews to date". Where the review followed ICT-related incidents, the report "shall contain the list of all ICT-related incidents with incident root-cause analysis". Art. 2(2) of the same regulation requires the ICT security policies to "indicate the date of the formal approval of the ICT security policies by the management body".
The reason is the field a log of dates cannot hold. A log with one row per year shows the interval was honored. It says nothing about whether any review was ever started by an event. If every row reads "annual", an auditor can reasonably ask what happened after the incident you reported last spring.
A usable review record therefore has five parts: the date, the person or role who judged, the trigger (the interval, or a named event), the outcome (no change, or a new version), and a short reason. The reason can be one sentence: "Reviewed after the hosting migration; access section still accurate."
devguard released periodic review cadences for policies, records, evidence and assignments in App 2.2.0. The policy part follows the distinctions above, and it covers the calendar half only.
A policy carries a review schedule, picked from the organization's shared schedules. The next review date is derived from that schedule and shown on the policy with the date it was last reviewed; once the date passes, the policy is marked overdue. Approving a new version counts as a review and restarts the clock. A review that concludes no change is recorded with Mark as reviewed, which stamps the date without publishing a version. Only members of the policy's approver role can mark it reviewed. The same role is reminded ahead of the date and again when the review is overdue, and due reviews appear on the Deadlines page. On the roles list, a Responsible for column counts, per role, the policies it approves. That count is the review workload a person takes on by joining the role. Editing a published policy's text returns it to draft until a new version is approved.
[screenshot: the Periodic review card in the policy editor, with review schedule, next review, last reviewed and the Mark as reviewed button]
Three limits follow from how it is built.
First, devguard does not detect the event trigger. Closing a significant incident or changing a vendor does not move any policy's review date. The one change it does notice is an edit to the policy text itself. Someone has to open the policy after the event and record the review.
Second, the next date is counted from the last review. With a plain yearly schedule, a policy reviewed two months late comes due again a year after that late review, so one late review moves every later date. A schedule pinned to a calendar date, such as every 15 January, avoids the drift, at the cost of a short cycle after a late review.
Third, Mark as reviewed records who and when, in the activity log, and nothing else. It takes no reason. The trigger and the one-sentence reason from the previous section belong in the policy's comment thread, and writing them there is a separate step that the product does not enforce.
Before the next annual review comes round, write two columns next to each policy: the interval with the reason you chose it, and the events that would bring the review forward, each with the role that has to raise it.
devguard derives each policy's next review date from the schedule you attach and reminds the approver role when it falls due; the changelog has the details.
Vadim leads engineering, the architecture, automation, and integrations that let compliance live. He's set on making a serious, audit-grade system genuinely easy to run.
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.