ISO/IEC 27005 Risk Register Workflow

A register makes the ISO/IEC 27005 lifecycle navigable. It should show the current decision and link to the evidence that produced it, while preserving earlier versions. It can also support planned-interval and event-driven reassessment, provided the workflow does not mistake a row, score, or status for proof that the underlying process occurred.

ISO/IEC 27005 is guidance and ISO/IEC 27001 contains the certifiable ISMS requirements. Neither standard prescribes a universal register tool, column set, risk taxonomy, or review deadline. The organization chooses the record design, but it must still retain the required assessment and treatment processes and results.

For each entry, record a stable identifier; status; scope; scenario and affected objectives; risk sources, events, assets, threats, and vulnerabilities where relevant; owner; assessment date; method and criteria version; existing controls and effectiveness; consequence; likelihood; level; evaluation result; treatment priority; and rationale.

Use status values that describe a verified decision stage, such as intake, scope validation, assessment, treatment planning, implementation, residual assessment, accepted with conditions, monitoring, or superseded. Define entry and exit evidence for each status. A status change should point to the assessment, approval, test, or decision that authorized it.

At intake, record the source and describe the sequence from cause or event to unwanted consequence. Search for related entries, but merge only when the scenarios can share one assessment and treatment decision. Validate scope and assign an authorized risk owner before moving the entry into assessment.

Keep scenarios separate when they need different controls. ISO/IEC 27005 uses flooding, fire, power spikes, and vandalism affecting a data centre as examples: the exposures may be combined for corporate reporting, but treatment still needs separate scenario records because the controls differ.

Avoid orphaned entries, vague labels, silent score changes, expired acceptance, and duplicate scenarios with conflicting owners. Do not close a risk because a task was assigned or a control was installed. Record whether the control works, reassess the residual level, and obtain the required decision.

Use a strategic review when the ISMS context, objectives, scope, appetite, or interested-party requirements change. Use a shorter operational cycle for changes to scenarios, assets, threats, vulnerabilities, controls, treatment actions, likelihood, consequences, incidents, or acceptance conditions. There is no universal annual register deadline: set planned intervals appropriate to the ISMS and add event-driven reviews when significant changes are proposed or occur.