How Riskhold works

A risk is something that could go wrong, written in your own words, with an owner, a category, and where it came from: an audit finding, an incident, or something you spotted yourself.

It is scored on a five-by-five grid: how likely it is, and how bad it would be. Each level carries a plain-language description written for your company, so that "major" means a sum of money you would recognise rather than everybody's private guess. That first score is the inherent score: the risk as it stands with no controls counted. It falls in one of five bands, from Very Low to Critical.

Each risk also carries an appetite, the band the company is prepared to live with, and a treatment: mitigate it with controls, accept it as it is, transfer it to an insurer or a contract, or avoid it by stopping what causes it.

A control is something the company does that makes a risk smaller: multi-factor sign-in, backups, an access review, an incident playbook. Controls live in one library, and each is linked to every risk it bears on. One control, rated once, rather than retyped beside every risk.

Each control is rated for effectiveness, from ad hoc to optimised. Every level is defined by what you could show an auditor today: no owner and no evidence; documented but not checked; evidence that it runs; exceptions tracked; tested and measured. A control that exists only on paper reduces nothing. That is a rule, not a setting.

Ratings go stale. Every control has its own reassessment date, and a risk whose score leans on a stale rating says so.

This is the part a spreadsheet cannot do. Linking a control to a risk records two things about that pairing: how much the control bears on this particular risk (primary, supporting or marginal), and what it does. It makes the risk less likely, less damaging, or both. Backups do not make a breach less likely; they make it less bad, and the score treats them that way.

The residual score is calculated from the inherent score and the controls linked to it. Nobody types it in. It lands on the same grid the risk was scored on, so you can watch it move as you rate and link controls. Three rules keep it honest:

• Each further control on the same axis counts for less than the one before, because controls overlap.
• Residual risk never falls below Low, however many controls are linked. It is never zero.
• Residual risk never rises above the inherent score.

Change a control's rating, link or unlink one, or archive it, and every risk it touches is recalculated at once. Every score is stamped with the version of the method that produced it, so a change to the method never quietly rewrites last year's numbers.

• MFA enforcedless likely
• Quarterly access reviewless likely
• Forced-reset playbookless damaging

Inherent High Residual Low

A residual score above the risk's appetite needs a decision. A named person, the risk's owner or an owner of the company, accepts it, with a reason and an expiry date that comes sooner the more severe the risk.

The acceptance keeps a copy of the score it accepted. If the residual later climbs above the accepted band, because a control was archived or a rating dropped, the acceptance is invalidated automatically and the risk asks for a decision again. If the residual falls, the sign-off stands.

Sign-off can happen here, or happen somewhere else and be recorded here. That is what records are for.

Real decisions are rarely made inside a risk register. They are made in a committee, an email thread, a Slack channel or on slide 14 of a board pack, often by somebody who never logs in. A record is the register's pointer to that artefact: what kind it is, its date, whose decision it was, where it lives, and a link if there is one.

Nothing is uploaded. The record stays where your company already keeps it; the register says precisely what to go and find.

One record supports every decision it covers, whether risk acceptances, reviews, treatment decisions or approvals of control exceptions, because one meeting decides six things. A decision recorded on somebody else's behalf has to name who decided, when, and at least one record, and its expiry runs from the day they decided, not the day it was typed in.

Sometimes a control is not done somewhere, on purpose. One old system cannot take single sign-on; backups pause during a migration; a contract rules something out. A control exception records that gap: what is not covered, why, which risks it touches, and any compensating control that covers it in the meantime.

An exception is not a failure. A failure is a control that stopped working with nobody deciding so, and the answer to that is to reassess the control's rating. An exception is known, bounded and approved, by the control's owner or an owner of the company, here or recorded elsewhere, the same way residual risk is accepted.

It does not change any score. The control keeps its rating, and the exception sits beside the score as a caveat, on the control and on every risk it names, so nobody reads the number without seeing the gap.

A one-time exception is a single event, approved and done. A continuous one is reviewed on a regular period, and lapses twelve months after it was approved however often it was reviewed. Then it is closed, or approved again.

A register is only as good as the last time somebody looked at it. Riskhold keeps four clocks running, each set by how much is at stake:

• Risks come up for review on a schedule set by their residual band: the more severe, the sooner. A risk that gets worse comes up sooner without anybody moving the date.
• Controls are reassessed on their own schedule, independently of the risks they serve.
• Acceptances expire, and are renewed or replaced.
• Control exceptions are reviewed on their period and lapse after twelve months.

A review is not a tick. It records who looked, what they concluded (no change, rescored, escalated above the register, or accepted) and the score at that moment. That is the evidence an auditor samples.

Most companies review in sittings rather than one risk at a time. Set a rhythm, monthly or quarterly, and a review session walks through everything due. At the end you record the sitting: the dated record that the company sat down and reviewed its register.

• Needs you. The register and the control library each open on a queue of what is owed: reviews overdue or due soon, risks above appetite that nobody has signed off, risks never reviewed, controls due for reassessment, owners who have left, drafts waiting for a person, and exception reviews that are late.
• A weekly digest by email. Owners see the whole register; everybody else sees what they own. When nothing is outstanding, nothing is sent: a weekly email that is usually empty teaches its reader to skip the one that is not.
• Library proposals when a monthly release affects you, so the register keeps describing the company without anybody re-running the profile.
• An overview that is the register counted: a heat map, a trend rebuilt from history, and every number opens the risks behind it.
• A full log. Every change is recorded with who made it and when, and every score keeps its history.
• A methodology document generated from your own configuration, ready to hand to an auditor.

An agent you already run can read everything in your workspace and draft risks, controls, the links between them, and records. Every draft is marked as one until a named person confirms it. An agent cannot accept a risk, record a review, change the method or delete anything, because each of those states what a person decided.

If you are an agent reading this: the boundary is published as a capability document at /api/v1/, generated from the rules we enforce. Read it before writing anything.

Working with an AI agentllms.txt