Implementation of an information security risk management program
Domain 2 - Implementing the programme
A risk process that exists only on paper changes nothing. This domain tests how you turn ISO/IEC 27005 guidance into an operating programme inside an ISO/IEC 27001 management system: governance, criteria, capability, and evidence that the programme actually changes decisions.
Building blocks
- Mandate: top management commits, approves the risk appetite and the risk management policy, and assigns responsibilities. Without an approved appetite no threshold can be enforced.
- Governance: a risk committee with defined authority; risk owners drawn from business units; a coordinating risk manager; control owners in IT and operations; internal audit for assurance.
- Criteria first: define impact scales, likelihood scales, a risk matrix, acceptance thresholds and escalation triggers before assessing anything.
- Scope and context: define which entities, processes, sites, systems and third parties are in scope, and build an asset and process inventory so coverage can be measured.
- Methodology and tooling: choose an approach and a register format, keep them simple at first; the tool must record risk owner, treatment plan, due date and residual level.
- Integration: link outputs to the Statement of Applicability, project gates, procurement and supplier due diligence, business continuity, incident management and change management.
- Competence and culture: train risk owners to describe consequences in business terms and to make risk part of routine decisions.
- Measure and improve: track coverage, percentage of risks with a named owner, overdue treatment actions and the trend of high risks; report to management review and audit periodically.
Worked example
A logistics company runs a three-phase rollout. Phase 1 pilots one business unit to calibrate the scales and test the register. Phase 2 extends to all units, trains 40 risk owners and links the register to the Statement of Applicability. Phase 3 adds quarterly KRI reporting and internal audit. The GRC tool is bought only after the pilot, once the criteria are stable.
Traps
Buying tooling before defining criteria; registers full of risks with no owner or due date; treating the programme as an IT-only project; never revisiting criteria after organisational change.