Risk identification and analysis without action is just an expensive awareness exercise. This module teaches the full cycle of turning risk data into strategic decisions — and integrating security risk into enterprise-wide management.
Mitigate: Reduce likelihood (prevent), reduce impact (contain), or both. Always the first consideration for high-severity risks. Requires control implementation with defined owner and SLA. Transfer: Shift financial consequence — cyber insurance, contractual liability clauses. Does not reduce likelihood or technical impact; only shifts the financial burden. Accept: Documented, authorized decision to absorb the residual risk. Requires: written acceptance, risk owner signature, board/exec approval for high risks, defined review date. Avoid: Eliminate the activity creating the risk. Most complete treatment; often impractical for core business activities.
A risk treatment plan is not just a treatment decision — it is a project plan. Elements: Treatment decision rationale, specific controls to implement, risk owner, target completion date, interim controls during remediation, expected residual risk after treatment, success metrics, and sign-off approvals.
Many organizations treat cyber risk as an IT issue, separate from enterprise risk. This creates two problems: (1) Security risks are not visible at the enterprise level where capital allocation happens. (2) Security teams miss the business context needed to prioritize correctly. Integration requires: common risk taxonomy, shared risk register with business risks, board-level cyber risk reporting in ERM language, and CISO participation in the ERM process.
COSO ERM 2017 defines 20 principles across its 5 components. The security-most-relevant principles:
The organization defines risk appetite in the context of creating, preserving, and realizing value. Risk appetite must be specific enough to guide decision-making — not abstract platitudes.
The organization considers risk when selecting strategy. Business decisions (e.g., moving to cloud, entering new markets) should include a risk assessment before commitment.
Business objectives must be clear enough that risks to their achievement can be identified. Vague objectives make risk identification arbitrary.
The organization identifies risks that may affect achievement of objectives. Risk identification is continuous, not an annual event, and considers all risk categories including cyber.
Risks are assessed considering likelihood and impact. Severity = likelihood × impact. Considers both inherent and residual severity. Multiple assessment dimensions (financial, operational, reputational).
The organization selects and deploys risk responses. Considers risk tolerance, cost-benefit, and response interactions. Documents the response and expected residual risk.
Risk aggregation is the process of combining individual risks to understand the enterprise-level exposure. Individual risk analysis misses critical dynamics:
Multiple risks sharing the same threat source or vulnerability are correlated. A single ransomware event can simultaneously trigger data breach, operational downtime, regulatory notification, and reputational damage — not four separate small events but one catastrophic correlated loss.
Many risks concentrated in one area create unexpected fragility. If 60% of your critical systems depend on a single cloud provider, your actual operational risk is higher than any individual system's risk register entry suggests.
Risk A triggers Risk B triggers Risk C. A vendor breach → data exposure → regulatory investigation → reputational damage → customer churn → revenue loss. Aggregated view reveals the full cascade path.
Simple aggregation: sum ALE across correlated risks. Advanced: correlation matrices applied to Monte Carlo simulations. GRC platforms (ServiceNow, Archer) provide built-in aggregation reporting.
Risk aggregation is why a single high-risk vendor relationship can make an otherwise acceptable overall risk posture unacceptable. The board needs to see the portfolio view, not just individual risk cards.
Risk acceptance is not a passive non-decision. It is a formal governance action with specific requirements:
Why is the risk being accepted? What was the treatment option considered and why was it rejected? Cost? Technical infeasibility? Business continuity requirement? The justification must be documented in the risk register.
A named individual must accept ownership and accountability for the risk. Unowned accepted risks are governance failures — no one is watching for changes in the risk environment.
The approval authority must match the severity of the risk. Low risk: manager approval. Medium risk: CISO/director approval. High/Critical risk: executive committee or board approval. Approval authority matrices should be defined in the risk policy.
Accepted risks must have a defined review date. The risk environment changes — what was acceptable to accept today may become unacceptable in 6 months. Annual review is minimum; quarterly for high-severity accepted risks.
Governance policy must prohibit implicit risk acceptance (ignoring a risk). All acceptance decisions must be documented. If a risk is known and undocumented, that is a governance failure, not a valid acceptance.
Every treatment action must be followed by a residual risk assessment — confirming that controls actually achieved the intended risk reduction:
| Stage | Action | Output |
|---|---|---|
| 1. Initial Assessment | Assess inherent risk before controls | Inherent risk score (e.g., 5×5 = 25/25) |
| 2. Control Implementation | Deploy mitigating controls | Treatment plan with owner and date |
| 3. Control Validation | Test that controls are operating effectively (audit) | Evidence of control effectiveness |
| 4. Residual Assessment | Reassess risk with controls operating | Residual risk score (e.g., 2×2 = 4/25) |
| 5. Acceptance or Escalation | Compare residual score to risk appetite | Accept if within appetite; escalate if not |
| 6. Ongoing Monitoring | Monitor for changes in threat/vulnerability landscape | Risk register updated on schedule |
You are reviewing five risk register entries as the Risk Manager. For each risk, evaluate the likelihood, impact, ALE, and available treatment options — then make and justify a formal treatment decision using the correct risk treatment vocabulary.