1.8 KiB
1.8 KiB
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