Risk workflows — register, treat, review

Risk workflows

The Risk register is your record of known risks to the trust. It’s not a live alarm system — it’s a deliberate, reviewed list of things that could go wrong and what you’re doing about them. Use it for the kinds of risk you’d take to a governors’ meeting: data loss, safeguarding gaps, contractor failures, financial exposure, reputational damage.

Logging a new risk

From Governance → Risks → New:

1. Title — one short sentence. Aim for the consequence, not the cause. “Single point of failure on the school’s MIS database” is better than “DB needs backup”.
2. Description — the detail. Who is affected, what could go wrong, what’s currently in place to mitigate it.
3. Category — pulled from the risk-categories taxonomy in admin. If the right category isn’t there, ask an admin to add it rather than picking the closest fit.
4. Likelihood × Impact — both 1–5. The product is the inherent risk score (1–25). Keystone shows the score colour-coded so you can see at a glance which entries are red.
5. Owner — the person accountable for the treatment plan. Not the person doing the work — the person whose job depends on the risk being handled.

The default status on creation is Active. The risk shows on the register from the moment you save.

Treatment plans

Each risk has mitigations, each of which is typed by posture:

• Control — apply controls to reduce likelihood or impact. The most common.
• Accept — accept the risk as-is. Use sparingly; document why.
• Transfer — push the risk to a third party (insurance, contractor SLA).
• Avoid — stop doing the activity that creates the risk.

Once you’ve applied controls, set the residual likelihood and residual impact. The residual score is what governors look at — the inherent score is the worst-case “if we did nothing”.

Review cadence

Risks have a review date. By default it’s set 90 days from creation. The risk register surfaces overdue reviews in red — a risk that hasn’t been looked at in six months is a risk you’ve forgotten about, not a risk that’s gone away.

When a review is due, the owner gets an email. Reviewing a risk is a deliberate action: you confirm the description still applies, the controls are still working, the residual scores are still right, and you push the next review date forward.

Spawning an action

If a treatment plan needs work, click Spawn action on the risk page. This creates a Governance action linked back to the risk, with the treatment plan pre-filled as the action description. The action goes through its own approval/completion workflow and shows on the risk page so you can see what’s actively being done about each entry.

Closing a risk

A risk is Closed when the underlying threat no longer exists — not when it’s well-managed. Well-managed risks stay open with an updated residual score. Closing a risk you’re still actively treating loses the audit trail; keep it open with a clear treatment plan instead.