Build the register around one live workflow: record each risk as a cause, event and consequence, then name the owner, existing controls, residual rating and next review trigger.
TL;DR:
- A risk register must include a clearly defined owner, treatment actions with deadlines, and tested controls to be effective governance tools.
- It should capture risks as cause, event, and consequence chains, with consistent taxonomy and scoring criteria across entries.
- Building the register should start with mapping specific workflows and involving those who perform and oversee the work for practical relevance.
- Prioritize risks using a simple likelihood-impact matrix, focusing on high residual risk entries that threaten regulatory, client, or financial stability.
- A lean, targeted register focuses on active, recent changes and high-impact areas, ensuring leadership can review and act efficiently without being overwhelmed by low-priority detail.
Table of Contents
- How a risk register fits with Basel, ISO and NIST
- Essential fields and structure: what to capture in every entry
- Step-by-step: how to build a register that people will actually use
- Scoring, prioritisation and KRIs: deciding what to fix first
- Operating rhythm: reviews, evidence and incident-triggered reassessment
- Technology, data and AI entries: what extra metadata to capture
- Worked example: a completed register entry and a template to copy
- Common pitfalls and quick fixes
- Our approach to a staged, governed rollout
- Why keep the register lean: a first-person take
- How Pattrn Data can help implement or pilot your register
- Sources
- FAQ
How a risk register fits with Basel, ISO and NIST
An operational risk register goes by several names: risk log, risk and control matrix, or simply “the register.” Whatever the label, its job is the same. It gives an organisation a structured, current view of what can go wrong operationally, who is responsible for managing it, and what is being done to keep the exposure within tolerance.
The register sits inside a wider governance structure known as the three lines of defence. The first line, the people running the process, identifies and manages risk day to day. The second line, often risk or compliance, challenges and monitors that work. The third line, internal audit, checks that the whole system holds up. A well-maintained register gives all three lines a shared reference point, and it gives the board or leadership team something concrete to review rather than a narrative account of “how things are going.”
The linked Basel Committee’s guidance, ISO 31000 implementation guidance and NIST’s risk management resources are background reading, not a combined checklist that every professional firm must follow. Use the frameworks relevant to your sector, then make the register show the workflow, owner, controls and evidence.
For the working register proposed here, agree the following disciplines. Check any sector-specific format or reporting requirement separately:
- Risks are identified against a mapped process or operating model, not invented in isolation.
- Every risk has a named owner accountable for managing it, not just recording it.
- Controls are distinguished from the risks they mitigate, and their effectiveness is tested, not assumed.
- Reporting reaches senior management and the board in a form they can actually use to make decisions.
Firms that treat the register as a live management tool, rather than a document produced for an auditor, get more value from it and spend less time maintaining it.
Essential fields and structure: what to capture in every entry
A register only works if every entry follows the same structure. Inconsistent fields make it impossible to compare risks, spot duplicates, or roll entries up into a board report. The list below covers what a workable entry needs, and nothing more. Registers fail as often from bloat as from gaps.
- Risk ID: a unique reference so the entry can be tracked, audited and cross-referenced from incident logs or audit findings.
- Risk description: a short, specific statement of the exposure, written as a cause, event and consequence chain rather than a vague label.
- Cause: the underlying driver, for example a manual data entry step or an unreviewed automated output.
- Event: what actually happens if the cause plays out, such as a client instruction being processed incorrectly.
- Consequence: the resulting harm, whether financial, regulatory, reputational or client-facing.
- Risk owner: the named individual accountable for managing the risk, not a team or department.
- Existing controls: what is currently in place, and whether each control is preventive, detective or responsive.
- Control owner: who performs the control and who is responsible for evidencing that it works.
- Inherent rating: the risk level before controls are applied, covering likelihood and impact.
- Residual rating: the risk level after existing controls are accounted for.
- Treatment action: what will change to reduce the residual rating, with an owner and a deadline.
- Target rating: the level the organisation is aiming for once treatment is complete.
- Review date: when the entry is next due for reassessment.
Keep the control description separate from the test result. A record that says a control exists does not show whether it operated when needed or justify the residual rating on its own.
Keep taxonomy consistent across the register. If one entry calls something a “process failure” and another calls the same underlying issue a “control gap,” reporting becomes unreliable. Agree a short list of risk categories up front (financial, regulatory, technology, people, third party, and so on) and stick to it.
Step-by-step: how to build a register that people will actually use
Build the first entries with the people who perform and check the workflow. They can identify handoffs and exceptions that a template alone will miss.
- Map the operating model first. Before writing a single risk, identify the workflows, systems, people and hand-offs that make up how the business actually delivers its service. Pick one workflow to start with, ideally one with client impact, regulatory exposure or recent change.
- Run a focused workshop with the person performing the task and the person reviewing it. Set enough time to map the workflow and capture its main exceptions; expand the session if those remain unclear.
- Capture risks as cause, event, consequence chains. Resist the urge to write vague labels like “system risk.” Ask what could go wrong, why, and what happens next if it does.
- Agree scoring criteria before scoring anything. Decide on a shared scale for likelihood and impact so different people rate risks consistently.
- Assign an owner to every risk. Not a team, a named person who is accountable for managing it.
- Define a treatment action for anything above tolerance. State what will change, who will do it, and by when.
- Test the controls you are relying on. Confirm they actually operate as described rather than assuming they do because they are documented somewhere.
- Set a review cadence. Decide how often each risk is revisited, and what triggers an earlier review outside that schedule.
This sequence mirrors the proportionate approach described in ISO’s implementation guidance, which stresses consultation, monitoring and continual improvement over a single point-in-time exercise. It also keeps the effort contained. A firm does not need to map every process in the business before it gets value from a register.
Pro Tip: Start with the workflow that has changed most recently, whether that is a new system, a new supplier or a new AI tool. Recent change is where undocumented risk tends to concentrate.
Once the first workflow is captured, scored and owned, move to the next priority. Limit the first pass to a manageable scope rather than treating completion of an organisation-wide register as the only useful outcome.
Scoring, prioritisation and KRIs: deciding what to fix first
A register with fifty entries and no ranking is not much more useful than no register at all. Scoring exists to answer one question: which risks need attention first?
Choose a scoring scale the team can apply consistently, such as a 3x3 or 5x5 likelihood-impact matrix. Write descriptors for each level and test them on a few entries before rating the whole register.
- Inherent rating reflects the risk before any controls are applied, useful for understanding the scale of exposure if controls failed entirely.
- Residual rating reflects the risk after current controls, and is the number that should drive prioritisation and reporting.
- Re-rating triggers include a failed control test, an incident, a system change, or a new supplier, not just the scheduled review date.
- Key risk indicators (KRIs) are measurable signals, such as the number of overdue client reviews or the volume of unreviewed AI outputs sent to clients, that give early warning before a risk materialises fully.
- Thresholds on each KRI should trigger escalation automatically, rather than relying on someone noticing a slow drift.
Keep inherent exposure, control effectiveness and residual exposure separate in the entry. Leadership needs to see both the reason for the rating and the evidence supporting it.
Distinguish preventive, detective and responsive controls. Record what each is meant to do and test that behaviour, so the rating reflects the working process rather than a policy description.
Re-rating should not wait for the next scheduled review. NIST’s continuous monitoring guidance for the monitor step sets out criteria for selecting controls for ongoing monitoring and defining reporting frequency, treating monitoring as a continuous programme rather than a periodic event.
Operating rhythm: reviews, evidence and incident-triggered reassessment
Set a review schedule that fits the workflow’s risk and rate of change. Do not wait for the scheduled date after an incident, a failed control or a material supplier change.
- Risk owners review their open risks and actions on a fixed schedule, checking whether treatment actions are progressing and whether the residual rating still holds.
- Control owners produce evidence that controls are operating, not just a statement that they exist. This might be a sample of reviewed AI outputs, a log of approvals, or a test result.
- Leadership challenges material exposures at a defined governance meeting, asking pointed questions about anything rated high residual risk or overdue on treatment.
- Incidents, supplier changes or failed control tests trigger an immediate reassessment, rather than waiting for the next scheduled cycle.
- The register is updated with the trigger recorded, so anyone reviewing it later understands why a rating changed and when.
NIST’s RMF overview frames this as a repeatable cycle, prepare, categorise, select, implement, assess, authorise and monitor, with the monitor step treated as continuous rather than a final box to tick. That framing translates well outside technology risk. A change to a key supplier, a new regulatory requirement, or a near-miss incident should all prompt the same question: does this change any residual rating in the register?
Change itself is a review trigger, not a calendar event. A firm that only reviews risk ratings at the scheduled quarterly meeting will miss the exposure created between meetings when a system is replaced or a process changes hands. Capturing the trigger, not just the new rating, keeps the register auditable and keeps leadership able to answer “why did this change” months later.
Technology, data and AI entries: what extra metadata to capture
AI and automation introduce risk types that a traditional register was not built to describe, and firms adopting Copilot, automation tools or AI agents need entries that reflect this properly rather than folding them into a generic “IT risk” category.
- Data leakage, where sensitive or client data is exposed to a tool, supplier or output beyond its intended boundary.
- Inaccurate or unreviewed outputs, where an AI system produces content or decisions that reach a client or a record without human sign-off.
- Unclear decision ownership, where it is not obvious who is accountable when an AI-assisted process produces a wrong result.
- Prompt or configuration change, where an update to a tool’s instructions or settings changes its behaviour without anyone noticing.
- Supplier outage or change, where a third-party AI or automation provider changes terms, availability or functionality.
- Weak audit trails, where there is no record of what data went in, what came out, and who reviewed it.
For technology and AI entries, add the data boundary, system and supplier owner, human review point and fallback process. These are suggested fields for this register; check the applicable framework before treating them as a prescribed requirement.
Controls worth requiring for AI-related entries include an approval gate before output reaches a client, a defined test dataset used to check the tool’s behaviour before rollout, and a documented human review point that is actually followed, not just described in a policy. Firms working through what this looks like in practice can find more detail on data boundaries when AI is involved and on connecting governance to workflow controls.
For an AI-related entry, name the reviewer and the point at which review occurs. If those are undecided, record the control gap instead of marking the review control as operating.
Worked example: a completed register entry and a template to copy
Write the risk description as a cause, event and consequence chain, then use the register fields to record who owns the risk and what action is needed.
For an AI drafting tool used for client correspondence, consider the risk of an unchecked draft being sent to a client. Record the cause and consequence, name the risk owner and reviewer, and assess the control before assigning a residual rating.
The same fields, condensed, give a simple one-row template a team can copy directly: ID, description (cause, event, consequence), owner, existing control and type, inherent rating, residual rating, treatment action and owner, target rating, review date.
Smaller, team-level registers work well for individual workflows, capturing detail that operational staff need day to day. A single governance register, drawing the highest-rated entries up from each team register, is what leadership and the board should be reviewing. Trying to run both from one document usually produces something too detailed for the board and too shallow for the team. A public sample completed risk register shows a comparable field set and layout that firms commonly adapt for their own use.
Common pitfalls and quick fixes
Check the register for the following practical gaps before rebuilding the template:
- Missing owners. An entry with no named individual accountable for it will drift. Fix: assign a person, not a department, to every open risk within one workshop.
- Untested controls. A control marked “in place” still needs evidence. Fix: agree risk-based sample tests and record their results; quarterly testing is an option, not a universal requirement.
- Oversized registers. Hundreds of low-value entries dilute attention from the risks that matter. Fix: split into team-level and governance-level registers, and only escalate the highest-rated items upward.
- Overdue treatment actions with no consequence. If nothing happens when a deadline passes, deadlines stop meaning anything. Fix: report overdue actions by name at the governance meeting, not just by count.
- Stale entries. Risks rated years ago with no reassessment since a system or supplier changed. Fix: treat any material change as an automatic trigger for re-rating, not just the scheduled review date.
For a first cleanup, sample a few high-priority controls, merge duplicate entries and revisit stale ratings. Use the findings to plan the next session rather than assuming one workshop resolves every gap.
Our approach to a staged, governed rollout
A governance-first approach works from the same starting point as the guidance above: map the workflow before touching any tool. This sets out how a firm maps its workflows, defines the data boundaries a tool or process must respect, and keeps a human accountable for review at the point where judgement actually matters.
A typical staged pilot looks like this: map one workflow with material client or regulatory exposure, run a short workshop with the people doing the work, capture risks as cause, event, consequence chains, agree scoring criteria and assign owners, test the controls already in place, and set a review cadence before expanding to the next workflow. This mirrors the proportionate, one-workflow-at-a-time approach recommended earlier, rather than attempting an organisation-wide rollout in one project.
Firms bringing AI or automation into a workflow that already has regulatory exposure, client data handling or unclear approval steps tend to benefit most from having this mapping done properly before the register is built around it, rather than after something has already gone wrong.
Why keep the register lean: a first-person take
A long register can hide the entries leadership needs to act on. Keep detailed working records where teams can use them, and give leadership a ranked view of material exposure and overdue actions.
Keep the register focused on the workflows under review. Preserve enough detail to explain each rating and action; brevity should make review easier, not exclude risks merely to shorten the document.
Rohit
How Pattrn Data can help implement or pilot your register
If the first workflow needs mapping, an AI Clarity Session can help scope that work. Confirm the current session scope and price before booking, and agree which workflow and risks it will cover.
For firms with a wider set of workflows to map, an AI Risk & Efficiency Audit goes further, mapping workflows, data boundaries and existing controls in more detail before any register or governance structure is built around them. Either route starts with the same principle covered throughout this article: map the work first, keep a human accountable for judgement, and build the register around what you find.