Risk monitoring

ISO 31000:2018 clause 6.6 frames monitoring and review as assuring and improving the quality and effectiveness of the process design, implementation and outcomes, and expects it in all stages of the process, not only at the end. NIST SP 800-39 names three objectives for risk monitoring: verifying compliance, meaning that planned treatments were actually implemented; determining effectiveness, meaning that they reduce risk as intended; and identifying changes to systems, environment, threats or missions that affect the risk picture. The third is the one most often missing from annual cycles.

ISO/IEC 27001:2022 spreads the requirement across several clauses. Clause 8.2 requires risk assessments at planned intervals and when significant changes are proposed or occur, so the organisation must define what counts as significant; typical triggers are major incidents, new or replaced critical systems, new suppliers or a supplier breach, mergers, new legislation and relevant shifts in the threat landscape such as a vulnerability in a widely deployed product appearing in CISA's Known Exploited Vulnerabilities catalogue. Clause 9.1 requires deciding what is monitored and measured, how, when and by whom, and clause 9.3.2 lists the results of risk assessment and the status of the risk treatment plan among the required inputs to management review. NIS2 Art. 21(2)(f) separately requires policies and procedures to assess the effectiveness of cybersecurity risk-management measures.

The practical instruments are key risk indicators (KRIs) with thresholds tied to the risk appetite, treatment-plan tracking of owners and deadlines, and control metrics such as patch latency for internet-facing systems, MFA coverage, backup restore success and privileged account counts. A KRI differs from a KPI in that it signals rising exposure before a loss, rather than measuring performance after the fact. NIST SP 800-137 on information security continuous monitoring (ISCM) and the Monitor step of SP 800-37 Rev. 2 describe how automated control data can feed ongoing authorisation instead of periodic point-in-time reassessment.

Risk monitoring differs from security monitoring. A SOC watches events to detect and respond to incidents in minutes or hours; risk monitoring aggregates that telemetry, together with threat intelligence, audit findings and business change, to decide whether ratings and treatment decisions still hold. Common failures are registers reviewed on a calendar but never on triggers, accepted risks whose review dates pass unnoticed, and metrics collected without thresholds, so that no one is obliged to act when they move.