Opening Framing
Risk assessment without action is just an academic exercise. Risk treatment transforms analysis into decisions and decisions into implemented controls. Every risk requires a deliberate choice: invest in reducing it, transfer it to someone else, accept it as a cost of doing business, or restructure to avoid it entirely. These decisions must align with organizational risk appetite and available resources.
Effective risk treatment requires understanding the full menu of options, selecting appropriate controls, building business cases for investment, managing implementation, and tracking progress over time. It also requires formal processes for accepting risk—when an organization decides not to treat a risk, that decision should be documented, approved by appropriate authority, and revisited periodically.
This week covers risk treatment options, control selection and implementation, risk appetite and tolerance frameworks, risk acceptance processes, remediation tracking, and ongoing risk management. You'll learn to turn risk analysis into actionable treatment plans and track them to completion.
Key insight: Accepting risk is a valid treatment option—but it must be a conscious decision by someone with authority.
1) Risk Treatment Options
Four fundamental options exist for treating any risk:
Risk Treatment Strategies:
THE FOUR T's (or MATA):
┌─────────────────────────────────────────────────────────────┐
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ MITIGATE │ │
│ │ (Reduce/Modify) │ │
│ │ │ │
│ │ Implement controls to reduce likelihood or impact │ │
│ │ Example: Deploy MFA to reduce credential theft │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ TRANSFER │ │
│ │ (Share) │ │
│ │ │ │
│ │ Shift risk to another party │ │
│ │ Example: Cyber insurance, outsourcing │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ ACCEPT │ │
│ │ (Retain) │ │
│ │ │ │
│ │ Acknowledge risk and continue without action │ │
│ │ Example: Accept low-probability/low-impact risks │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ AVOID │ │
│ │ (Terminate) │ │
│ │ │ │
│ │ Eliminate the activity creating the risk │ │
│ │ Example: Don't collect data you don't need │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
DETAILED TREATMENT OPTIONS:
MITIGATE (Most Common):
┌─────────────────────────────────────────────────────────────┐
│ Reduce Likelihood: │
│ - Preventive controls (firewalls, access controls) │
│ - Training and awareness │
│ - Patch management │
│ - Security architecture improvements │
│ │
│ Reduce Impact: │
│ - Detective controls (monitoring, alerting) │
│ - Incident response capabilities │
│ - Backup and recovery │
│ - Business continuity planning │
│ - Segmentation (limit blast radius) │
│ │
│ When to use: │
│ - Risk exceeds appetite but activity must continue │
│ - Cost-effective controls available │
│ - Most common treatment for security risks │
└─────────────────────────────────────────────────────────────┘
TRANSFER:
┌─────────────────────────────────────────────────────────────┐
│ Methods: │
│ - Cyber insurance (transfer financial impact) │
│ - Outsourcing (transfer operational risk) │
│ - Contracts (liability clauses, indemnification) │
│ - Hedging (for financial risks) │
│ │
│ Important: │
│ - Cannot transfer reputational risk │
│ - Cannot transfer regulatory accountability │
│ - Contractual transfer may not survive legal challenge │
│ - Insurance has limits, exclusions, and conditions │
│ │
│ When to use: │
│ - Risk exceeds ability to mitigate effectively │
│ - Specialized expertise required │
│ - Financial impact is primary concern │
│ - Risk is insurable at reasonable cost │
└─────────────────────────────────────────────────────────────┘
ACCEPT:
┌─────────────────────────────────────────────────────────────┐
│ Types of Acceptance: │
│ - Informed acceptance (documented, approved) │
│ - Residual acceptance (after controls, risk remains) │
│ - Temporary acceptance (pending control implementation) │
│ │
│ Requirements: │
│ - Formal documentation │
│ - Approval by appropriate authority │
│ - Defined review period │
│ - Within risk appetite │
│ │
│ When to use: │
│ - Cost of treatment exceeds potential loss │
│ - Risk within acceptable tolerance │
│ - No viable treatment options │
│ - Business benefit outweighs risk │
│ │
│ Warning signs of improper acceptance: │
│ - "We accept all risks" (no real analysis) │
│ - Acceptance by security team (should be business) │
│ - No documentation │
│ - Never reviewed │
└─────────────────────────────────────────────────────────────┘
AVOID:
┌─────────────────────────────────────────────────────────────┐
│ Methods: │
│ - Stop the risky activity │
│ - Don't enter the risky market │
│ - Remove the risky technology │
│ - Don't collect/store the risky data │
│ │
│ When to use: │
│ - Risk exceeds all appetite │
│ - No viable mitigation or transfer options │
│ - Business benefit doesn't justify risk │
│ - Regulatory prohibition │
│ │
│ Examples: │
│ - Not expanding into high-risk market │
│ - Decommissioning legacy system │
│ - Not collecting SSN when not required │
│ - Exiting business line │
└─────────────────────────────────────────────────────────────┘Key insight: Treatment choice depends on risk level, available options, cost, and business context—not just security preference.
2) Control Selection and Implementation
Selecting the right controls requires balancing effectiveness, cost, and operational impact:
Control Selection Framework:
CONTROL TYPES:
┌─────────────────────────────────────────────────────────────┐
│ By Function: │
│ │
│ PREVENTIVE: Stop incidents before they occur │
│ - Access controls, firewalls, encryption │
│ - Training, policies, segregation of duties │
│ - Hardening, patching, secure configuration │
│ │
│ DETECTIVE: Identify incidents when they occur │
│ - Monitoring, logging, alerting │
│ - IDS/IPS, SIEM, anomaly detection │
│ - Audits, reviews, reconciliations │
│ │
│ CORRECTIVE: Respond to and recover from incidents │
│ - Incident response, backup/restore │
│ - Business continuity, disaster recovery │
│ - Patch deployment, configuration correction │
│ │
│ DETERRENT: Discourage threat actors │
│ - Warning banners, security cameras │
│ - Prosecution policies, background checks │
│ │
│ COMPENSATING: Alternative when primary control not feasible │
│ - Additional monitoring when patching delayed │
│ - Manual review when automated control unavailable │
└─────────────────────────────────────────────────────────────┘
CONTROL SELECTION CRITERIA:
┌─────────────────────────────────────────────────────────────┐
│ Effectiveness: │
│ - How much does it reduce risk? │
│ - Does it address root cause or symptoms? │
│ - Evidence of effectiveness (proven vs. theoretical)? │
│ │
│ Cost: │
│ - Initial implementation cost │
│ - Ongoing operational cost │
│ - Training and support costs │
│ - Opportunity cost │
│ │
│ Operational Impact: │
│ - Effect on business processes │
│ - User experience impact │
│ - Performance impact │
│ - Maintenance requirements │
│ │
│ Feasibility: │
│ - Technical compatibility │
│ - Skills available to implement/operate │
│ - Timeline to implement │
│ - Organizational readiness │
│ │
│ Compliance: │
│ - Does it satisfy regulatory requirements? │
│ - Does it align with framework controls? │
│ - Audit evidence generated │
└─────────────────────────────────────────────────────────────┘Building the Business Case:
Control Business Case:
BUSINESS CASE COMPONENTS:
┌─────────────────────────────────────────────────────────────┐
│ 1. PROBLEM STATEMENT │
│ - What risk are we addressing? │
│ - What's the current exposure? │
│ - What's happened (incidents, near misses)? │
│ │
│ 2. PROPOSED SOLUTION │
│ - What control(s) are recommended? │
│ - Why this approach vs. alternatives? │
│ - How does it address the risk? │
│ │
│ 3. COST ANALYSIS │
│ - Implementation costs (one-time) │
│ - Operational costs (annual) │
│ - Total cost of ownership (3-5 years) │
│ │
│ 4. BENEFIT ANALYSIS │
│ - Risk reduction (quantified if possible) │
│ - Compliance benefits │
│ - Operational benefits │
│ - Competitive/business benefits │
│ │
│ 5. ROI/ROSI CALCULATION │
│ - Risk reduction value │
│ - Net benefit │
│ - Payback period │
│ │
│ 6. IMPLEMENTATION PLAN │
│ - Timeline and milestones │
│ - Resources required │
│ - Dependencies │
│ - Risks to implementation │
│ │
│ 7. RECOMMENDATION │
│ - Clear ask │
│ - Decision required │
└─────────────────────────────────────────────────────────────┘
EXAMPLE BUSINESS CASE:
┌─────────────────────────────────────────────────────────────┐
│ Problem: Phishing attacks succeed 15% of the time │
│ 3 successful compromises in past year │
│ Average cost per incident: $150,000 │
│ Annual exposure: ~$450,000 │
│ │
│ Solution: Advanced email security + enhanced training │
│ │
│ Costs: │
│ - Email security platform: $80,000/year │
│ - Training program: $30,000/year │
│ - Implementation: $20,000 (one-time) │
│ - Total Year 1: $130,000 │
│ - Annual ongoing: $110,000 │
│ │
│ Benefits: │
│ - Expected reduction: 80% (industry data) │
│ - New annual exposure: $90,000 │
│ - Risk reduction: $360,000/year │
│ │
│ ROI: ($360,000 - $110,000) / $110,000 = 227% │
│ │
│ Recommendation: Approve $130,000 Year 1 investment │
└─────────────────────────────────────────────────────────────┘Key insight: Frame security investments as risk reduction purchases, not costs. Executives understand buying down risk.
3) Risk Appetite and Tolerance
Risk appetite frameworks guide treatment decisions by defining acceptable risk levels:
Risk Appetite Framework:
APPETITE HIERARCHY:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ RISK APPETITE STATEMENT │ │
│ │ │ │
│ │ Board-level statement of overall risk-taking │ │
│ │ willingness in pursuit of business objectives │ │
│ │ │ │
│ │ Example: "We accept moderate risk in pursuit of │ │
│ │ growth but will not accept risks that could │ │
│ │ result in regulatory action or significant │ │
│ │ customer harm." │ │
│ └─────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ RISK TOLERANCE │ │
│ │ │ │
│ │ Specific boundaries for risk categories │ │
│ │ │ │
│ │ Example: "No more than $5M annual cyber risk │ │
│ │ exposure. No unpatched critical vulnerabilities │ │
│ │ on internet-facing systems for more than 7 days." │ │
│ └─────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ RISK LIMITS │ │
│ │ │ │
│ │ Operational triggers requiring action │ │
│ │ │ │
│ │ Example: "Any risk rated Critical must be │ │
│ │ escalated within 24 hours. Residual risk above │ │
│ │ $1M requires CISO approval." │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
RISK APPETITE BY CATEGORY:
┌─────────────────────────────────────────────────────────────┐
│ Risk Category │ Appetite │ Tolerance │
├────────────────────┼─────────────┼─────────────────────────┤
│ Data Breach │ Very Low │ Max 10K records exposed │
│ │ │ per incident │
├────────────────────┼─────────────┼─────────────────────────┤
│ System Availability│ Low │ Max 4 hrs downtime for │
│ │ │ critical systems │
├────────────────────┼─────────────┼─────────────────────────┤
│ Regulatory │ Very Low │ No material findings, │
│ Compliance │ │ no sanctions │
├────────────────────┼─────────────┼─────────────────────────┤
│ Financial Fraud │ Low │ Max $100K annual loss │
├────────────────────┼─────────────┼─────────────────────────┤
│ Reputation │ Low │ No national negative │
│ │ │ media coverage │
├────────────────────┼─────────────┼─────────────────────────┤
│ Third-Party │ Moderate │ Critical vendors must │
│ │ │ meet security standards │
└────────────────────┴─────────────┴─────────────────────────┘
USING APPETITE IN DECISIONS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ Risk Level vs. Appetite: │
│ │
│ ┌───────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ Risk exceeds │ MUST treat (mitigate, transfer, │ │
│ │ appetite │ or avoid). Cannot accept. │ │
│ │ ─────────────────┼──────────────────────────────────│ │
│ │ Risk within │ MAY treat or accept based on │ │
│ │ appetite but │ cost-benefit analysis │ │
│ │ above target │ │ │
│ │ ─────────────────┼──────────────────────────────────│ │
│ │ Risk below │ No treatment required. May still │ │
│ │ target │ treat if cost-effective │ │
│ │ │ │
│ └───────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘Key insight: Risk appetite isn't set by security—it's a business decision that security helps inform and implement.
4) Risk Acceptance Process
Formal risk acceptance ensures informed decisions with appropriate accountability:
Risk Acceptance Framework:
WHEN ACCEPTANCE IS APPROPRIATE:
┌─────────────────────────────────────────────────────────────┐
│ Accept when: │
│ - Risk is within defined appetite/tolerance │
│ - Cost of treatment exceeds potential loss │
│ - No feasible treatment options exist │
│ - Business benefit clearly outweighs risk │
│ - Residual risk after treatment (always some acceptance) │
│ │
│ Do NOT accept when: │
│ - Risk exceeds appetite without business justification │
│ - Regulatory requirements mandate controls │
│ - Risk involves potential harm to individuals │
│ - Accepting to avoid difficult conversations │
│ - No real analysis performed │
└─────────────────────────────────────────────────────────────┘
ACCEPTANCE AUTHORITY LEVELS:
┌─────────────────────────────────────────────────────────────┐
│ Risk Level │ Acceptance Authority │
├───────────────┼─────────────────────────────────────────────┤
│ Critical │ Board / CEO (or not acceptable) │
├───────────────┼─────────────────────────────────────────────┤
│ High │ Executive Committee / C-Suite │
├───────────────┼─────────────────────────────────────────────┤
│ Medium │ Senior Management / VP level │
├───────────────┼─────────────────────────────────────────────┤
│ Low │ Department Manager / Risk Owner │
└───────────────┴─────────────────────────────────────────────┘
Note: Security team ADVISES on risk but does NOT accept risk
Business owners accept risk for their domainsRisk Acceptance Documentation:
Risk Acceptance Form:
┌─────────────────────────────────────────────────────────────┐
│ RISK ACCEPTANCE REQUEST │
├─────────────────────────────────────────────────────────────┤
│ Risk ID: R-2024-042 │
│ Date: 2024-01-15 │
│ Requestor: Jane Smith, VP Engineering │
├─────────────────────────────────────────────────────────────┤
│ RISK DESCRIPTION: │
│ Legacy payment application (PayApp v2.3) running on │
│ unsupported operating system (Windows Server 2012) with │
│ known vulnerabilities. System processes $2M daily. │
├─────────────────────────────────────────────────────────────┤
│ RISK RATING: │
│ Likelihood: High (4) Impact: High (4) Score: 16 │
│ Quantified Annual Exposure: $800,000 │
├─────────────────────────────────────────────────────────────┤
│ WHY TREATMENT IS NOT FEASIBLE: │
│ - Vendor no longer supports application │
│ - Replacement project scheduled for Q3 2024 │
│ - Immediate replacement would cost $500K + 6 month delay │
│ - Moving to supported OS breaks application │
├─────────────────────────────────────────────────────────────┤
│ COMPENSATING CONTROLS IN PLACE: │
│ - Network segmentation (isolated VLAN) │
│ - Enhanced monitoring (24/7 SOC coverage) │
│ - Web application firewall │
│ - Daily backup with 4-hour recovery capability │
│ - Incident response plan specific to this system │
├─────────────────────────────────────────────────────────────┤
│ RESIDUAL RISK WITH COMPENSATING CONTROLS: │
│ Likelihood: Medium (3) Impact: High (4) Score: 12 │
│ Quantified Annual Exposure: $350,000 │
├─────────────────────────────────────────────────────────────┤
│ ACCEPTANCE PERIOD: │
│ From: 2024-01-15 To: 2024-09-30 (replacement go-live) │
│ Review Date: 2024-04-15 (quarterly review) │
├─────────────────────────────────────────────────────────────┤
│ BUSINESS JUSTIFICATION: │
│ Accepting temporary elevated risk allows continued │
│ business operations while replacement is completed. │
│ Alternative would halt $2M daily processing. │
├─────────────────────────────────────────────────────────────┤
│ SECURITY RECOMMENDATION: │
│ CISO recommends acceptance with stated compensating │
│ controls, provided replacement project remains on track. │
│ Escalate if project delays beyond Q3 2024. │
├─────────────────────────────────────────────────────────────┤
│ APPROVALS: │
│ Risk Owner: _________________ Date: _______ │
│ (VP Engineering) │
│ │
│ CISO Review: ________________ Date: _______ │
│ (Acknowledged) │
│ │
│ Executive Approval: __________ Date: _______ │
│ (CIO - required for High risk) │
└─────────────────────────────────────────────────────────────┘
ACCEPTANCE TRACKING:
┌─────────────────────────────────────────────────────────────┐
│ All acceptances must be: │
│ - Recorded in risk register │
│ - Tracked for expiration │
│ - Reviewed at stated intervals │
│ - Reported to appropriate governance body │
│ - Closed when risk is treated or avoided │
│ │
│ Expired acceptances require: │
│ - Re-assessment of risk │
│ - Renewal with current approval │
│ - Or escalation if conditions changed │
└─────────────────────────────────────────────────────────────┘Key insight: Documented risk acceptance protects the organization by ensuring decisions are informed, authorized, and traceable.
5) Remediation Tracking and Management
Effective risk treatment requires tracking implementation to completion:
Remediation Management:
REMEDIATION WORKFLOW:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │Identified│──►│ Planned │──►│In Progress│──►│Completed │ │
│ │ │ │ │ │ │ │ │ │
│ └──────────┘ └──────────┘ └──────────┘ └──────────┘ │
│ │ │ │ │ │
│ ▼ ▼ ▼ ▼ │
│ Document Assign owner Track progress Verify │
│ treatment Set deadline Report status effectiveness│
│ plan Allocate Escalate if Update risk │
│ resources delayed register │
│ │
└─────────────────────────────────────────────────────────────┘
REMEDIATION TRACKING FIELDS:
┌─────────────────────────────────────────────────────────────┐
│ - Remediation ID │
│ - Related Risk ID │
│ - Description of action │
│ - Owner (person accountable) │
│ - Assignee (person doing work) │
│ - Priority (based on risk level) │
│ - Due date │
│ - Status (Not Started/In Progress/Blocked/Completed) │
│ - Percent complete │
│ - Blockers/dependencies │
│ - Evidence of completion │
│ - Verification method │
│ - Last update date │
│ - Comments/notes │
└─────────────────────────────────────────────────────────────┘
SLA BY RISK SEVERITY:
┌─────────────────────────────────────────────────────────────┐
│ Severity │ Remediation SLA │ Escalation │
├─────────────┼────────────────────┼─────────────────────────┤
│ Critical │ 24-72 hours │ Immediate to C-suite │
├─────────────┼────────────────────┼─────────────────────────┤
│ High │ 7-14 days │ Weekly to Sr. Mgmt │
├─────────────┼────────────────────┼─────────────────────────┤
│ Medium │ 30-60 days │ Monthly to Management │
├─────────────┼────────────────────┼─────────────────────────┤
│ Low │ 90 days │ Quarterly review │
└─────────────┴────────────────────┴─────────────────────────┘Remediation Reporting:
Remediation Dashboard Metrics:
OVERALL STATUS:
┌─────────────────────────────────────────────────────────────┐
│ Open Remediation Items: 47 │
│ │
│ By Severity: By Status: By Age: │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │Critical: 3 │ │Not Started:12│ │<30 days: 28 │ │
│ │High: 12 │ │In Progress:25│ │30-60 days:11 │ │
│ │Medium: 22 │ │Blocked: 5│ │60-90 days: 5 │ │
│ │Low: 10 │ │Overdue: 5│ │>90 days: 3 │ │
│ └──────────────┘ └──────────────┘ └──────────────┘ │
│ │
│ On Track: 38 (81%) At Risk: 4 (8%) Overdue: 5 (11%) │
└─────────────────────────────────────────────────────────────┘
TREND ANALYSIS:
┌─────────────────────────────────────────────────────────────┐
│ Month │ Opened │ Closed │ Net Change │ Total Open │
├──────────┼────────┼────────┼────────────┼──────────────────┤
│ October │ 15 │ 12 │ +3 │ 42 │
│ November │ 18 │ 20 │ -2 │ 40 │
│ December │ 10 │ 15 │ -5 │ 35 │
│ January │ 22 │ 10 │ +12 │ 47 │
│──────────┴────────┴────────┴────────────┴──────────────────│
│ Note: January spike due to annual assessment findings │
└─────────────────────────────────────────────────────────────┘
OVERDUE ITEMS (Executive Escalation):
┌─────────────────────────────────────────────────────────────┐
│ ID │ Risk │ Owner │ Due │ Days │ Blocker │
│ │ Level │ │ Date │ Over │ │
├────────┼─────────┼────────────┼──────────┼────────┼─────────┤
│REM-101 │ High │ J. Smith │ Dec 15 │ 31 │ Budget │
│REM-089 │ Medium │ T. Jones │ Dec 01 │ 45 │ Vendor │
│REM-095 │ Medium │ A. Wilson │ Dec 20 │ 26 │ None │
│REM-102 │ High │ M. Brown │ Jan 05 │ 10 │ Resource│
│REM-088 │ Low │ K. Davis │ Nov 15 │ 61 │ None │
└────────┴─────────┴────────────┴──────────┴────────┴─────────┘
Required Actions:
- REM-101: CFO approval for emergency budget needed
- REM-089: Escalate to vendor management
- REM-095: Owner accountability discussion required
- REM-102: Temporary resource assignment approved
- REM-088: Close or re-justify given low priority
Verification and Closure:
Remediation Verification:
VERIFICATION METHODS:
┌─────────────────────────────────────────────────────────────┐
│ Technical Controls: │
│ - Vulnerability rescan (confirm patch applied) │
│ - Configuration audit (verify settings) │
│ - Penetration test (validate control effectiveness) │
│ - Automated compliance check │
│ │
│ Process Controls: │
│ - Policy/procedure review │
│ - Process observation │
│ - Sample testing │
│ - Interview with process owners │
│ │
│ Administrative Controls: │
│ - Documentation review │
│ - Training completion records │
│ - Access reviews │
│ - Sign-off verification │
└─────────────────────────────────────────────────────────────┘
CLOSURE CRITERIA:
┌─────────────────────────────────────────────────────────────┐
│ Before closing a remediation: │
│ │
│ □ Control implemented as designed │
│ □ Verification completed (appropriate to control type) │
│ □ Evidence documented and retained │
│ □ Risk re-assessed with control in place │
│ □ Risk register updated │
│ □ Owner sign-off obtained │
│ □ Ongoing monitoring/maintenance defined │
└─────────────────────────────────────────────────────────────┘Key insight: Remediation without verification is hope, not risk treatment. Always confirm controls work as intended.
Real-World Context
Case Study: The Cost of Improper Risk Acceptance
A retail company's IT team verbally "accepted" the risk of outdated point-of-sale systems because upgrading was expensive and disruptive. No formal documentation existed. When a breach occurred through these systems, resulting in $50M in losses and regulatory fines, leadership asked who approved this risk. The IT team pointed to business pressure; business leaders claimed they were never informed of the risk level. Without documented acceptance by appropriate authority, no one could demonstrate the decision was informed. Post-breach, the company implemented formal risk acceptance requiring business owner sign-off with clear articulation of potential consequences.
Case Study: Effective Remediation Program
A financial services firm struggled with thousands of audit findings and vulnerability remediations, many overdue for years. They implemented a remediation management program with: clear ownership assigned to business owners (not IT), SLAs by severity, weekly tracking meetings for critical/high items, executive dashboards showing aging and trends, and consequences for chronic overdue items (included in performance reviews). Within 18 months, overdue items dropped 80%, average remediation time halved, and auditors noted the improvement in their reports.
Risk Treatment Quick Reference:
Risk Treatment Checklist:
TREATMENT SELECTION:
□ All treatment options considered
□ Cost-benefit analysis completed
□ Business case documented (for significant investments)
□ Treatment aligns with risk appetite
□ Owner assigned for implementation
CONTROL IMPLEMENTATION:
□ Control designed appropriately
□ Resources allocated
□ Timeline established
□ Dependencies identified
□ Implementation plan documented
RISK ACCEPTANCE:
□ Within risk appetite
□ Compensating controls identified
□ Documented with business justification
□ Approved by appropriate authority
□ Expiration date set
□ Review schedule defined
REMEDIATION TRACKING:
□ All items in tracking system
□ Owners and due dates assigned
□ Regular status updates
□ Escalation process defined
□ Overdue items addressed
VERIFICATION:
□ Control effectiveness tested
□ Evidence documented
□ Risk register updated
□ Closure approvedRisk treatment is where risk management delivers value. Assessment without treatment is just documentation.
Guided Lab: Risk Treatment Planning
In this lab, you'll develop treatment plans for identified risks including business cases and acceptance documentation.
Lab Scenario:
- Continue with e-commerce company from previous weeks
- Risk register with 10 assessed risks
- $500K annual security budget
- Need to present treatment plan to executives
Exercise Steps:
- Categorize each risk by treatment strategy
- Develop control options for risks to mitigate
- Build business case for top investment
- Define risk appetite statement
- Complete risk acceptance form for one risk
- Create remediation tracking spreadsheet
- Design remediation dashboard
- Develop executive presentation
Reflection Questions:
- How did you decide which risks to accept vs. mitigate?
- What challenges did you face building the business case?
- How would you handle pushback on risk acceptance decisions?
Week Outcome Check
By the end of this week, you should be able to:
- Explain the four risk treatment options and when to use each
- Select appropriate controls based on effectiveness and cost
- Build business cases for security investments
- Define risk appetite statements and tolerance levels
- Document formal risk acceptance with appropriate approvals
- Track remediation activities to completion
- Create remediation dashboards and reports
- Verify control implementation effectiveness
🎯 Hands-On Labs (Free & Essential)
Apply risk treatment strategies and build practical risk management programs.
🛡️ Risk Treatment Planning Lab
What you'll do: Design risk treatment plans—select controls, document
justifications, create implementation roadmaps.
Why it matters: Risk treatment connects assessment to action—this is where
risk management becomes real.
Time estimate: 3-4 hours
⚖️ Risk Acceptance Scenarios
What you'll do: Practice risk acceptance decisions—evaluate residual risk,
document acceptance rationale, prepare board presentations.
Why it matters: Not all risks can or should be mitigated—learn when
acceptance is appropriate.
Time estimate: 2-3 hours
📋 Control Selection Exercise
What you'll do: Select and tailor NIST 800-53 controls—map to risks, customize
for organization, document overlays.
Why it matters: Control selection must balance security effectiveness with
business impact.
Time estimate: 2-3 hours
💡 Lab Strategy: Risk treatment is about trade-offs—practice balancing security, cost, usability, and business needs.
Resources
Lab
Complete the following lab exercises to practice risk treatment concepts.