An Annual Risk Review Can't Catch a Change That Didn't Wait for It
Open your risk assessment and look at the date.
For most certified organizations it lands in the same month as the certification audit. The assessment was built during implementation, populated by the people running the project, reviewed once by leadership, and accepted by the auditor. Then it went into document control and stayed there.
The procedure says it gets reviewed annually. Maybe it has been. But annual review of a document usually means someone opened it, confirmed the entries still looked plausible, and closed it. The risks on it last year are on it this year. The business has changed. The register hasn't.
That is the pattern across post-certification work, and it shows up most sharply in information security — the domain where the conditions underneath a risk move fastest.
The trigger that already fired
Consider what has happened to nearly every organization in the past two years.
Artificial intelligence entered the operating environment through at least three doors at once. Teams adopted tools directly, sometimes through procurement and sometimes not. Existing vendors shipped AI capability into products already inside the perimeter, changing where data travels without generating any purchasing event to mark it. And the external threat environment changed shape, because the same capability is available to everyone.
None of that waited for a review date.
Now open the register. For most organizations AI either isn't on it, or it appears as one recently added entry with generic wording and no treatment. That gap isn't a documentation failure. It's the review mechanism failing in public, on a change large enough that nobody can claim they missed it.
The same structure governs changes that draw less attention. Entering a new market brings a different class of software vendors, with hosting arrangements and access models the original assessment was never written against. Replacing a core system redraws the data flows underneath a dozen entries at once. A service change from an existing provider can shift exposure without producing any internal event at all. Organizations building formal oversight of AI adoption through ISO 42001 tend to discover the exposure was already present and unassessed, rather than arriving with the framework.
Not every risk decays at the same rate
There is a reasonable objection here, and it deserves to be taken seriously rather than argued around.
Not everything on a register moves quickly. A control-level entry — the requirement for least privilege, the requirement that access be reviewed on a defined cycle — is relatively stable. The control either exists and functions or it doesn't. That doesn't rot month to month.
What moves is the context around it. The number of parties holding credentials. The systems those credentials reach. The technologies present in the environment. The threat activity aimed at them.
So the claim isn't that your whole register is misleading. It's that a register holds entries with wildly different rates of change, and a single annual cycle treats them identically. A properly structured information security risk assessment distinguishes between the two. A uniform cadence structurally cannot.
Even the stable entries carry trigger conditions. A general access control risk warrants reevaluation when a new vendor is onboarded, when a process changes, when a technology is introduced. The entry itself doesn't change. The conditions it was assessed under do.
The tell: documented is not verified
A related failure turns up in the same engagements, and it compounds the first one.
The organization has the control. There is a vendor contract template. It names the security requirements — vulnerability scanning, least privilege, defined access provisioning. The register shows the risk as treated and points at the contract as the treatment.
Nobody has confirmed it. Not with the vendor's IT personnel, not against evidence, not once since the clause entered the template.
So the register records a contractual requirement as though it were an operational reality. The entry looks maintained. It has a treatment, an owner, and a reference. It simply isn't attached to anything anyone has checked.
This is why reviewing the register as a document surfaces so little — the document looks fine. Verification happens by following the control down to where the work occurs and testing whether the mechanism functions there, which is also the only reliable way to learn whether a review trigger is sufficient. Programs built around a cybersecurity risk framework rather than a control inventory tend to build that verification in from the start.
Bind review to events, in two places
The fix isn't a better template or a shorter calendar. It's defining what causes a re-review, and putting that definition where it will actually be encountered.
That means two locations, not one.
In the register. Each entry carries its trigger conditions alongside its treatment and its owner. Not a review date — the conditions under which this specific risk requires reevaluation.
In the process. The review sits as a step inside the process where the triggering event actually happens. An information security risk review as a gate within supplier evaluation and approval, rather than a reminder living somewhere outside it.
The second location is what makes it fire. A trigger documented only in the register depends on someone remembering to consult the register at the moment of change — which is precisely the behavior that isn't happening. Built into vendor onboarding, it happens because the onboarding happens.
Organizations that govern external dependencies well tend to build this into supply chain risk strategy, designing monitoring around the signals that justify reassessment rather than treating supplier risk as a procurement step with an annual review bolted onto it.
Mature systems absorb the trigger in the process
Here is where a good deal of risk program effort turns out to be unnecessary.
If vendor onboarding contains a real information security review — one that evaluates access model, hosting, data handling, and contractual requirements against your standard — then the register-level re-review of access control risk may be redundant. The process already reassessed the risk at the moment the change arrived, in a form specific to that vendor. Reopening the register entry adds a meeting and no information.
That is the payoff of pushing controls down to the point of work. The principle is straightforward: push the control as close to the work where the risk can actually be controlled as feasibility and efficiency allow. Below that principle, it is case by case. There is no clean rule that sorts risks into process-absorbed and register-level in advance, and any framework claiming otherwise is selling tidiness.
What exists instead is a way to find out. Follow the control down through interviews and process review until you reach the point where the work happens, then test whether the trigger mechanism there is sufficient. Whatever the process demonstrably cannot absorb is what stays at register level. That gets discovered, not decided up front — and it is the same walk that ISO risk management consulting work uses to test whether a methodology survives contact with operations.
Organizations running several risk disciplines in parallel usually find this is where duplication lives: the same change assessed three times in three vocabularies, or missed by all three because each assumed another owned it. That fragmentation is the problem integrated risk management exists to solve.
When it can't be absorbed: a lighter review
The practical objection to trigger-based review is workload. If every new vendor fires a risk review, and a risk review means convening stakeholders, nobody does it twice.
So don't convene anyone at first.
When a trigger fires, the first pass is a preliminary scan — an assessment of potential exposure sufficient to determine whether deeper evaluation is warranted and who needs to be involved in it. That is a light activity, not a committee.
Who runs it matters, and the intuitive answer is wrong. The obvious choice is the domain expert. But a network security engineer evaluating a service change from a network services provider will assess the network implications correctly and may not see what else the change touches — supplier qualification, data residency, continuity arrangements, commitments already made to customers.
The scan works best as a pairing. The management system administrator brings breadth across the control framework and recognizes the spread. The relevant subject matter expert brings depth on the risk itself. Two questions get answered: how significant is this within its own domain, and what else does it reach.
Most triggers stop there, with a documented determination that no further evaluation is required. The ones that don't escalate to the stakeholders the scan identified — a smaller and better-targeted group than a standing review committee would ever have been. In organizations with a formal enterprise risk management program, this is also the mechanism that keeps operational triggers connected to executive-level oversight instead of running as a parallel process.
A date can be the right trigger
One clarification, because none of this is an attack on periodic review.
A frequency trigger is legitimate. Some risks are stable enough that annual reevaluation is genuinely sufficient, and saying so is a defensible position — provided somebody actually took it.
The failure isn't the calendar. It's that the calendar was never chosen. It arrived as the default, applied uniformly to every entry, with no reasoning behind it and no acceptance recorded anywhere. A frequency trigger you selected and justified is risk management. A frequency trigger you inherited from a template is an assumption wearing a procedure's clothing.
Not every risk needs the same comprehensiveness in its triggers. Some need three conditions and a process gate. Some need a date. The distinction is whether anyone decided.
Where to start
Take any entry on your risk assessment and answer three questions.
What triggers a re-review of this risk — not a review of the document, a reevaluation of this entry?
Where is that trigger written, and is it attached to a process that would actually encounter the event?
Can you defend why that trigger is sufficient for this particular risk?
Work through five entries. The pattern surfaces fast.
If the answer to the first question is consistently "the annual review," you don't have trigger-based review. You have a date doing work nobody assigned it, applied across risks that move at completely different speeds. That is a fixable problem, and fixing it doesn't require rebuilding the assessment — most risk management consulting work at this stage is deciding what should reopen each entry and putting that decision where the work happens.
