# Risk And Exception Writing Guidance

## Purpose

This guidance note helps authors write clearer risk entries, treatment actions, and exception justifications.

## Writing A Useful Risk Entry

A good risk entry should explain:

- what could happen
- what asset, service, or process is affected
- why the risk exists
- what the likely impact is
- what will be done about it

Short, vague statements such as "security risk exists" are not useful.

## Better Risk Framing

Try to describe risk in terms of:

- threat or failure scenario
- vulnerability or weakness
- business or security impact

For example, instead of:

- "Kubernetes risk"

prefer something closer to:

- "Overly permissive cluster administration could allow unauthorised production changes and service disruption."

## Writing Treatment Actions

Treatment actions should be:

- specific
- owned
- time-bounded
- observable when complete

Avoid actions such as:

- "Improve security"

Prefer:

- "Restrict production cluster administration to approved roles and complete access review by [date]."

## Writing A Good Exception Justification

A good exception request should explain:

- what requirement cannot currently be met
- why that is the case
- what temporary risk is introduced
- what compensating controls exist
- when the exception should expire or be reviewed

## Common Problems

- exception requests with no expiry or review date
- accepted risks with no named owner
- treatment actions that describe analysis but not action
- language that hides impact or uncertainty

## Related Documents

- `../../00-governance/risk-assessment-and-treatment-methodology.md`
- `../../03-procedures/risk-assessment-procedure.md`
- `../../03-procedures/exception-management-procedure.md`
- `../../04-registers/risk-register-template.md`