Six risk management strategies, mnemonic: TAAAME
- Transfer — move financial consequences to another party (insurance)
- Accept — tolerate the risk deliberately (documented decision)
- Accept with exemption — policy cannot be applied (permanent barrier)
- Accept with exception — temporary policy deviation (operational conflict)
- Mitigate — reduce likelihood or impact (controls added)
- Eliminate / Eliminate (Avoid) — stop the activity (risk completely removed)
Quick classification question: "Did the risk go away completely?" Yes = Avoid. "Did money move to another party?" Yes = Transfer. "Did they add controls to reduce risk?" Yes = Mitigate. "Did they decide to live with it?" Yes = Accept. "Is there a policy conflict?" Yes = Exemption or Exception.
Key fact: Avoid is the ONLY strategy that eliminates risk completely. Every other strategy involves some residual risk remaining. If a question says the risk was "completely removed" or "fully eliminated" and asks which strategy was used, the answer is avoidance.
The exemption/exception distinction is a frequently tested nuance. One simple question resolves it every time:
"Could the policy ever apply to this situation?"
- No, it fundamentally cannot apply = Exemption. The policy is structurally incompatible with this specific case. Example: industrial equipment that cannot be patched without voiding manufacturer warranty. The patching policy can never apply here as long as this device exists.
- Yes, but not right now due to a temporary conflict = Exception. The policy is valid and will eventually be applied. Example: patches are delayed because they crash the ERP system. Once the vendor fixes the compatibility issue, the policy will be re-applied. This is a time-limited deviation, not a permanent incompatibility.
Both require: formal documentation, management approval, compensating controls, and periodic review. Neither is an informal workaround or an excuse to ignore security policy indefinitely.
Exam trap: "The organization granted an exception for all legacy servers." If the reason is permanent (vendor no longer supports patches), this should be an exemption, not an exception. Exception implies future compliance is expected.
A persistent exam trap: equating risk transfer (insurance) with risk elimination. They are completely different.
- Risk transfer: shifts the financial burden to another party. The threat still exists. The incident still happens. The insurer pays for recovery after the fact.
- What transfer does NOT accomplish: prevent the attack, reduce the likelihood of the incident, limit the operational disruption, avoid the reputational damage, or protect the data.
Scenario: "The company had cyber insurance and the insurer paid $500,000 after the breach." The insurance transferred the financial consequence, but the breach still: exposed customer data, triggered regulatory notification, disrupted operations for a week, damaged customer trust, and consumed months of staff time for recovery.
Insurance also has limits: insurers may deny claims if minimum security controls (MFA, patch management, backup testing) were not in place at the time of the incident. Insurance is not a substitute for security controls.
Best practice: transfer + mitigate together. Mitigation reduces the likelihood and impact; insurance covers residual financial exposure.
Risk reporting is a communication tool for leadership, not a technical document for the security team. The exam will describe risk report content and ask who the intended audience is, or describe the audience and ask what should be in the report.
Risk report audience = senior management, executives, board of directors.
These people have decision-making authority over budget and risk acceptance, but typically lack deep technical expertise. Risk reports must:
- Use business impact language, not technical CVE references
- Include financial impact estimates (ALE values) leadership can use for budget decisions
- Highlight critical risks (highest severity) AND emerging risks (not yet under control)
- Provide recommended actions with cost-benefit context
Exam trap: "Emerging risks should not be reported to the board until a mitigation plan is in place." WRONG. The board needs to know about emerging risks to authorize budget for mitigation. Withholding them prevents informed decision-making.
Exam trap: "The risk report should include detailed vulnerability scan output and CVE lists for the board." WRONG. CVE lists are for the technical team. The board receives business impact summaries.
Practice Scenarios
Classify each of the following actions into the correct risk management strategy: (A) The organization purchases a $50,000/year cybersecurity insurance policy covering ransomware incidents. (B) A legacy POS system cannot be patched because the vendor no longer supports it; management formally documents that patches cannot be applied and implements network isolation as a compensating control. (C) The security team deploys MFA on all remote access systems and installs endpoint detection and response software. (D) After analysis, management decides that the risk of a minor website outage is within their risk appetite and documents this decision without implementing additional controls. (E) The company discontinues its public WiFi service after determining it creates unmanageable security risk to corporate systems.
Classify each (A-E) and explain the key indicator.
Answer: (A) Risk Transfer. Key indicator: financial consequences shift to the insurance company; the ransomware threat itself is not reduced; the insurer pays if a covered incident occurs. The organization still faces ransomware attacks; insurance funds recovery. (B) Risk Acceptance with Exemption. Key indicators: the patching policy cannot be applied (permanent barrier -- vendor EOL); formal documentation of the exemption; compensating controls (network isolation) implemented in place of the original control. This is exemption, not exception, because the policy can never be applied to this device -- it is permanently incompatible. (C) Risk Mitigation. Key indicators: security controls (MFA, EDR) are added to reduce likelihood and impact of attacks. Internet access still exists; the threat of remote access attacks still exists; the risk is lowered but not eliminated. (D) Risk Acceptance. Key indicators: management evaluates the risk and decides to take no additional action because the risk falls within their appetite; the decision is formally documented. This is proper acceptance (documented decision), not negligence (undocumented inaction). (E) Risk Avoidance. Key indicator: the risky activity (public WiFi service) is completely stopped. The threat of public WiFi security risk is completely eliminated because the WiFi no longer exists. This is the only scenario where the risk is completely removed.
A security policy states all systems must use TLS 1.3 for encrypted communications. Two situations arise: (A) A medical imaging device manufactured in 2018 only supports TLS 1.0. The manufacturer states the device cannot be upgraded and that TLS 1.3 support was never included in the firmware. Updating firmware voids warranty and could affect FDA regulatory compliance for the medical device. (B) A web application currently supports TLS 1.2 because TLS 1.3 was not available when it was built. The development team can upgrade to TLS 1.3 but needs 6 weeks for testing and deployment.
Determine whether each situation requires an exemption or exception, and describe the correct process for each.
Answer: (A) Medical imaging device = Exemption. The TLS 1.3 policy fundamentally cannot apply to this device: the firmware cannot be updated (technically impossible), updating voids warranty (operational limitation), and FDA compliance concerns create regulatory barriers. This is not a temporary conflict -- the device will never support TLS 1.3 without replacement. Process: (1) Document the specific device, why the policy cannot apply, and the regulatory/technical barriers. (2) Obtain management and compliance team approval. (3) Implement compensating controls: network isolation (VLAN isolation from general network), enhanced logging for all traffic to/from the device, physical access controls. (4) Schedule periodic review to assess whether device replacement should be prioritized given the residual risk. (B) Web application = Exception. TLS 1.3 support IS achievable -- it just requires 6 weeks of development work. The policy can eventually be applied; the conflict is temporary and operational. Process: (1) Document the specific application, why TLS 1.2 will be used during the exception period, and the planned TLS 1.3 implementation date. (2) Obtain management approval with a defined expiration date (6 weeks). (3) Compensating controls during the exception: ensure TLS 1.2 with strong cipher suites only (no TLS 1.0 or 1.1), enhanced monitoring, WAF protection. (4) Create a project task with a hard deadline for the TLS 1.3 upgrade. (5) Confirm exception expires and policy is re-applied once upgrade is complete.
A CISO must present a quarterly risk report to the board of directors. The security team has produced a 120-page technical report including: full vulnerability scan output with CVE details, detailed penetration test findings with exploit code snippets, network topology diagrams with IP addresses, a traffic light risk matrix summarizing 15 key risk areas, three critical risks requiring board authorization for remediation budget, two emerging risks from new threat intelligence, and recommended budget amounts for five security investments with ROI analysis.
Which elements belong in the board-level risk report, which should stay in the technical report, and what format should the board report take?
Answer: Board-level risk report should include: (1) Traffic light risk matrix summarizing 15 key risk areas -- ideal for board audience; visual, accessible, shows overall posture at a glance. (2) Three critical risks requiring authorization -- board must authorize budget; these need business impact descriptions (not technical CVE details), financial exposure estimates (ALE), recommended mitigation with cost, and a clear request for budget approval. (3) Two emerging risks from threat intelligence -- board must be informed of newly identified risks to make informed risk appetite decisions; brief descriptions in business terms, no technical details. (4) Budget recommendations with ROI analysis -- the board approves budgets; financial justification belongs at board level. Technical report only (not for board): Full vulnerability scan output and CVE details (too technical, too voluminous, potentially sensitive if the report is leaked), penetration test findings with exploit code (security-sensitive; board does not need exploitation details; a summary of findings categories and severity is sufficient), network topology diagrams with IP addresses (operational security concern -- this document could be leaked). Board report format: executive summary (1-2 pages), risk matrix (1 page visual), critical risks (1 page each with business impact + cost + recommendation), emerging risks (1/2 page each), budget request summary (1-2 pages). Total: 8-12 pages maximum. Boards cannot process 120-page technical documents and should not be given security-sensitive technical details.