Files
ISMS/05-guidance/risk-and-exception-writing-guidance.md
Paul Jenkins 5eade2d99b Initial commit
2026-03-26 09:35:22 +00:00

75 lines
1.8 KiB
Markdown

# 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`