Risk registers are written in workshops. A room of senior people assembles once a year, lists the risks they can remember, assigns likelihood and impact scores based on instinct, agrees on mitigation owners, and files the result. Twelve months later, another workshop. The register exists. Nobody could argue it is not there. But risk does not run on an annual cycle, and the register written in January does not reflect what the business is exposed to in September.
The gap between a risk register and the actual risk posture of a company is a function of time. Risks move. Vendors change their products. Regulatory obligations tighten. Staff turn over and the controls they owned atrophy. A company that was compliant in Q1 may have a different exposure in Q3 — and nothing in the register reflects that, because the register has not moved. What the board sees at its December governance meeting is a description of the risk environment as imagined in January, dressed in current formatting and presented as current insight.
This is not a failure of diligence. It is a structural failure of the model. A register that is built by a workshop, scored by gut feel, and reviewed annually will always lag reality. The systems where risk actually lives — identity providers, cloud infrastructure, SaaS platforms, vendor relationships — change continuously. The register that does not connect to those systems is not a record of risk. It is a record of what a room thought risk looked like on a particular day.
01 / Why the static register fails
The core problem is a mismatch between risk velocity and review cadence. Controls on user access in Okta can be changed by an administrator in minutes. A vendor can ship a new AI capability into your environment mid-contract. An employee in a key risk-owner role can leave. None of these events wait for the annual workshop, and none of them appear in the register unless someone updates it by hand.
Risk ratings are a second failure point. A score of "medium likelihood, high impact" is only as useful as the reasoning behind it. When that reasoning is undocumented — when the score is what the room agreed to in a two-hour session three months ago — the rating cannot be defended. Auditors ask what evidence supports the rating. Enterprise customers ask what evidence supports the rating. Boards ask what evidence supports the rating. The honest answer, in most cases, is that the rating reflects the collective opinion of the people in the room at the time. Opinion is not evidence.
Ownership is the third failure point. A risk with an assigned owner is only as well-managed as that person's engagement with it. When the owner changes roles, when the team restructures, when the person who accepted accountability for a risk leaves the company — the register does not automatically know. The risk sits in a row with a name attached to it, and the name may no longer correspond to anyone with authority over the relevant systems. Risk ownership that decays undetected is ownership in name only.
02 / What connects a register to reality
A register that reflects actual risk posture has to be linked to the controls that mitigate each risk — and each of those controls has to be linked to live evidence from the systems where it operates. That chain is what separates a document from a record.
Take a risk entry for unauthorised access to production systems. The mitigating control might be MFA enforcement for all users with access to those systems. To know whether that control is operating, you need evidence from Okta — current MFA enforcement rates, the population in scope, any exceptions that exist. That evidence should not be a screenshot taken before the annual review. It should be the current state of the system, confirmed by an independent process, timestamped, and held in a form that is auditable. The risk rating for that entry should reflect what the evidence shows, not what the room decided twelve months ago.
The same logic applies across the stack. A risk entry for data leakage through CRM platforms connects to controls in Salesforce — permission sets, profile access, field-level security. A risk entry for cloud infrastructure exposure connects to controls in AWS — logging configuration, encryption settings, access policies. A risk entry for third-party data handling connects to vendor oversight records. Each risk, each control, each piece of evidence. The chain has to close at the system level, not at the assertion level.
A risk register that is not linked to live evidence is a record of opinion, not a record of posture. The difference matters every time someone asks whether you can prove it.
When that chain is in place, the register reflects the actual state of the business. A control that degrades — because a policy was changed, because an exception was granted, because a new user population was provisioned outside the standard process — appears in the evidence record immediately. The register does not wait for the next workshop to reflect the change. It reflects reality because it is linked to reality.
03 / Risk acceptance as a documented decision
Every mature risk programme includes risks that are accepted rather than mitigated. The business has weighed the cost of additional controls against the probability and impact of the risk, and decided to carry it. That is a legitimate governance decision. The problem is how most organisations record it — or fail to.
Risk acceptance should be a documented, dated decision: who accepted it, on what authority, on what basis, with what conditions, and with what review date. Instead, it is usually folklore. The risk sits in the register with a low mitigation score, and the institutional knowledge that someone decided not to mitigate it is stored in the memory of the person who was in the room. When that person leaves, the decision leaves with them. The next reviewer either re-opens the risk unnecessarily or accepts the status quo without understanding why it was set that way.
A living register treats acceptance as a structured record, not a status. The acceptance entry captures the rationale, the authority, and the expiry condition. It is a governance artefact that can be reviewed, challenged, and renewed — or revoked if the risk environment changes. It does not disappear when the person who made the call moves to a different role.
This matters for audits. Auditors ask not only what risks the company carries, but whether the decision to carry them was made deliberately. Documented acceptance with a named authority and a dated rationale is a defensible answer. Undocumented acceptance — a score in a register with no supporting reasoning — is not.
04 / Board reporting on current posture
A board that receives risk reporting from a static register is receiving last year's information with today's formatting. The risk landscape presented at the December board meeting was assessed in January, with the controls and the threat environment that existed then. If a significant risk has moved — if a control has degraded, if a new exposure has emerged, if a vendor has introduced a capability that changes the surface — the board does not know unless someone has manually updated the register and ensured the update reached the reporting pack.
Current posture reporting is only possible when the register is live. When each risk entry reflects the current state of its mitigating controls, and each control reflects the current evidence from the systems where it operates, the board is looking at the actual position of the business. That is a materially different governance conversation than the one that happens with a static register. It is also the conversation that regulators and sophisticated investors expect a board to be having.
The board's exposure in a risk reporting failure is concrete. Directors who receive and approve a risk report based on outdated information have, in practice, discharged their governance obligation on the basis of stale data. When a risk that was assessed as "managed" in January materialises in October, the question of what the board knew and when they knew it turns on the quality of the reporting they received. A living register provides defensible reporting. A static register provides documentation of past opinion.
05 / The AI entry problem
The pace of change in the risk environment has accelerated in ways the annual workshop model cannot absorb. AI is the clearest example. A Salesforce instance that was assessed in January may have had Agentforce features enabled by March. A Microsoft 365 tenant that was reviewed in Q1 may have Copilot processing a significantly larger scope of content by Q3. A Google Workspace configuration that was approved at the start of the year may have new AI features active by mid-year. None of these changes triggered a procurement event. None of them required a new vendor approval. They happened inside tools the business had already approved, on schedules the vendors set, with capabilities the business did not specifically choose to enable.
Each of those changes alters the risk register. The risk entry for AI-processed data exposure needs to reflect the current scope of what AI features are active across the stack. The mitigating controls need to reflect what is actually configured in each platform. The evidence needs to reflect the current state, not the state at the time of the last review.
A register that waits for the annual workshop to incorporate new AI feature risks is a register that is structurally behind. The gap between when the risk changed and when the register reflects it is not measured in days. It is measured in months. During that gap, the board is receiving risk reporting that describes a risk surface that no longer exists — because the actual surface is larger, and the controls that were assessed to mitigate it were designed for a different version of the platform.
The living register connects to the AI governance layer of the same systems it already monitors. When a new AI feature is active in Salesforce, the risk entry that covers CRM data exposure is updated. When Copilot access is extended in Microsoft 365, the relevant risk entries reflect the change. The register does not wait to be told. It is connected to the systems, and the systems are the record of what is actually in place.
06 / What changes when the register lives
A living risk register is not a more frequently updated static document. It is a different kind of artefact. It is linked to the controls that mitigate each risk. Those controls are linked to live evidence from the systems where they operate. Acceptance decisions are documented and dated. The board sees current posture, not historical opinion. AI feature changes appear in the register as the risk surface shifts, not twelve months after the fact.
The practical benefit is not just audit readiness, though that is real. It is governance quality. A board that can look at a risk register and know that the ratings reflect the current state of the controls — that the MFA enforcement rate is as of today, that the Salesforce access review was as of this quarter, that the AWS logging status is confirmed — is a board that can make decisions on the basis of actual information. That is what governance is for.
Enterprise customers performing vendor security assessments ask about risk management processes. They are not looking for a list of risks written in a workshop. They are asking whether the company has a programme that reflects the actual state of its exposure. A living register answers that question with evidence rather than assertion. It is the difference between saying "we have a risk register" and being able to show that the register operates continuously, is linked to the systems it covers, and reflects the company's real position.
The companies that operate living registers are not doing more work than the companies that run annual workshops. They are doing different work — connecting governance to the systems where risk actually lives, rather than reassembling it by hand once a year. The scramble is replaced by a record. The record is the answer.
See it on your company.
This is the desk work of the office we embed. A structured governance review shows you, on your own documents and systems, exactly where your proof is strong, fragile, and missing — in plain language, no data required.