Module 3: Risk & Planning

Risk Register Creation

Template
25 min
+100 XP

Risk Register Creation Template

Introduction to Risk Registers

A Risk Register is the cornerstone document of your Information Security Management System (ISMS). It serves as the single source of truth for all identified risks, their assessments, treatments, and ongoing monitoring.

What is a Risk Register?

A Risk Register is a structured repository that:

  • Centralizes Risk Information: All identified risks in one location
  • Tracks Risk Evolution: Historical changes in risk levels and treatments
  • Facilitates Decision-Making: Provides data for prioritization and resource allocation
  • Demonstrates Compliance: Shows systematic risk management to auditors
  • Enables Communication: Common language for discussing risks across the organization
  • Supports Continuous Improvement: Trends and patterns inform security strategy

Why is a Risk Register Critical?

For ISO 27001 Compliance:

  • Clause 6.1.2 requires documented information about risk assessment results
  • Clause 6.1.3 requires documented information about risk treatment plans
  • Essential evidence for certification audits

For Effective Risk Management:

  • Prevents risks from being overlooked or forgotten
  • Ensures accountability through clear risk ownership
  • Tracks control effectiveness over time
  • Supports reporting to stakeholders and executive leadership

For Business Value:

  • Aligns security investments with business priorities
  • Demonstrates return on security investment (ROSI)
  • Reduces organizational exposure to cyber incidents
  • Builds stakeholder confidence in security posture

Essential Risk Register Fields

Core Identification Fields

1. Risk ID

Purpose: Unique identifier for tracking and referencing

Format: Use a consistent naming convention

  • RISK-[YEAR]-[NUMBER] (e.g., RISK-2024-001)
  • [DEPARTMENT]-[YEAR]-[NUMBER] (e.g., IT-2024-045)
  • [CATEGORY]-[NUMBER] (e.g., DATA-001, ACCESS-015)

Best Practice:

  • Choose one format and use consistently
  • Make IDs sequential and non-reusable
  • Include year to track risk age

Example: RISK-2024-045

2. Date Identified

Purpose: Track when risk was discovered

Format: ISO 8601 format (YYYY-MM-DD)

Why It Matters:

  • Shows risk management maturity (identifying risks proactively vs reactively)
  • Tracks time to risk treatment
  • Historical reference for trend analysis

Example: 2024-11-15

3. Date Last Updated

Purpose: Track currency of risk information

Format: ISO 8601 format (YYYY-MM-DD)

Best Practice:

  • Update whenever risk parameters change
  • Review at least quarterly even if no changes
  • Include update reason in notes

Example: 2024-12-01

4. Risk Category

Purpose: Group risks for reporting and analysis

Standard Categories (ISO 27001 aligned):

  • Technology: Infrastructure, systems, applications
  • Physical: Facilities, equipment, environmental
  • Human: People, insider threats, training gaps
  • Process: Procedures, change management, operations
  • Third-Party: Vendors, suppliers, partners
  • Compliance: Legal, regulatory, contractual
  • Strategic: Business model, market changes
  • Financial: Budget, investment, fraud

Example: Technology - Access Control

5. Risk Status

Purpose: Track where risk is in the management lifecycle

Status Values:

  • Identified: Newly discovered, awaiting assessment
  • Assessed: Risk calculation completed
  • Treatment Planned: Treatment decisions made
  • Treatment In Progress: Controls being implemented
  • Monitoring: Treatment complete, ongoing monitoring
  • Closed: Risk eliminated or no longer relevant
  • Escalated: Requires senior management attention

Example: Treatment In Progress


Asset and Context Fields

6. Asset Name/ID

Purpose: Link risk to specific organizational assets

Format: Reference your asset inventory

  • Asset ID from asset register
  • Clear descriptive name if no formal asset register

Asset Types:

  • Information (databases, documents, intellectual property)
  • Systems (applications, servers, networks)
  • Services (email, cloud services, payment processing)
  • People (employees, contractors)
  • Physical (devices, facilities, media)

Example: ASSET-DB-001 (Customer Database)

7. Asset Owner

Purpose: Person responsible for the asset

Best Practice:

  • Must be a business owner, not IT
  • Should have budget authority
  • Accountable for risk decisions

Example: Sarah Johnson, VP Customer Operations

8. Business Process/Function

Purpose: Link risk to business impact

Why It Matters:

  • Prioritize risks affecting critical business processes
  • Engage correct stakeholders
  • Understand broader organizational impact

Example: Customer Order Processing - Payment Collection


Risk Description Fields

9. Risk Description

Purpose: Clear, concise statement of the risk

Format: "Threat + Vulnerability + Potential Consequence"

Template:

"[Threat] could exploit [Vulnerability] leading to [Impact]"

Good Example:

"External attackers could exploit weak password controls on the customer
database, leading to unauthorized access and theft of 100,000 customer
records including personal and financial information."

Poor Example:

"Security issue with database"

Best Practices:

  • Be specific, not generic
  • Include scale/magnitude
  • Focus on business impact, not technical jargon
  • Keep to 2-3 sentences maximum

10. Threat Source

Purpose: Identify what/who could cause harm

Categories:

  • External Malicious: Hackers, cybercriminals, nation-states, competitors
  • External Non-Malicious: Natural disasters, accidents, failures
  • Internal Malicious: Disgruntled employees, contractors, insider threats
  • Internal Non-Malicious: Human error, accidents, lack of knowledge

Example: External Malicious - Opportunistic Cybercriminals

11. Vulnerability

Purpose: Identify the weakness that enables the threat

Types:

  • Technical (unpatched systems, misconfigurations, weak crypto)
  • Physical (inadequate locks, surveillance gaps)
  • Organizational (insufficient policies, lack of training)
  • Process (weak change management, inadequate reviews)

Example: Password policy allows weak passwords (minimum 8 characters, no complexity requirements). No multi-factor authentication on external access.


Risk Assessment Fields

12. Inherent Likelihood

Purpose: Probability before controls

Scale: 1-5 (Rare, Unlikely, Possible, Likely, Almost Certain)

Example: 4 (Likely)

13. Inherent Impact

Purpose: Consequence before controls

Scale: 1-5 (Insignificant, Minor, Moderate, Major, Catastrophic)

Example: 5 (Catastrophic)

14. Inherent Risk Score

Purpose: Quantify risk exposure without controls

Calculation: Likelihood × Impact

Example: 20 (Extreme)

15. Inherent Risk Rating

Purpose: Categorical risk level

Values: Very Low, Low, Medium, High, Extreme

Example: Extreme


Control Fields

16. Existing Controls

Purpose: Document current risk mitigation measures

Format: Numbered or bulleted list with control descriptions

Include:

  • Preventive controls (stop risk from occurring)
  • Detective controls (identify when risk occurs)
  • Corrective controls (respond when risk occurs)

Example:

1. Multi-factor authentication (MFA) on all external access [Preventive]
2. Password complexity policy (12+ chars, complexity) [Preventive]
3. Account lockout after 5 failed attempts [Preventive]
4. Database access logging and weekly review [Detective]
5. Intrusion detection system (IDS) monitoring [Detective]
6. Quarterly access rights reviews [Detective]
7. Annual security awareness training [Preventive]

17. Control Effectiveness Rating

Purpose: Assess how well controls mitigate risk

Scale:

  • 3 (High): 60-80% effective, well-designed, tested, monitored
  • 2 (Medium): 30-50% effective, gaps in design or implementation
  • 1 (Low): 10-20% effective, poorly implemented, inconsistent
  • 0 (None): Control doesn't exist or completely ineffective

Example:

MFA: 3 (High - 98% adoption, enforced)
Password Policy: 2 (Medium - Some users still use weak patterns)
Access Logging: 2 (Medium - Logs reviewed but not always timely)

18. Control Testing Date

Purpose: Track when effectiveness was last validated

Example: 2024-11-15

19. Control Gaps

Purpose: Document known weaknesses in controls

Example:

- MFA not enforced on internal network access
- Access logs only reviewed weekly (not real-time)
- Training completion rate only 87% (target: 100%)
- Password policy allows some common passwords

Residual Risk Fields

20. Residual Likelihood

Purpose: Probability after controls

Scale: 1-5 (Rare, Unlikely, Possible, Likely, Almost Certain)

Example: 2 (Unlikely)

21. Residual Impact

Purpose: Consequence after controls

Scale: 1-5 (Insignificant, Minor, Moderate, Major, Catastrophic)

Example: 4 (Major)

22. Residual Risk Score

Purpose: Quantify risk exposure with controls

Calculation: Likelihood × Impact

Example: 8 (Low)

23. Residual Risk Rating

Purpose: Categorical risk level

Values: Very Low, Low, Medium, High, Extreme

Example: Low


Treatment Fields

24. Risk Owner

Purpose: Person accountable for managing the risk

Responsibilities:

  • Approve risk assessment
  • Make treatment decisions
  • Allocate resources
  • Monitor risk levels
  • Escalate when needed

Best Practice:

  • Must have decision-making authority
  • Typically a business manager, not IT
  • Should own the affected asset or process

Example: Sarah Johnson, VP Customer Operations

25. Risk Treatment Option

Purpose: Document chosen strategy

Options (per ISO 27001):

  1. Modify/Treat: Apply controls to reduce risk
  2. Retain/Accept: Accept risk within risk appetite
  3. Avoid: Eliminate the risk by changing the activity
  4. Share/Transfer: Share or transfer the risk (e.g., insurance, outsourcing)

Example: Modify - Implement additional controls to reduce residual risk to acceptable level

26. Treatment Plan Summary

Purpose: High-level overview of planned actions

Example:

1. Implement advanced email threat protection (Q1 2025)
2. Deploy phishing simulation program (Q1 2025)
3. Enhance endpoint detection and response (Q2 2025)
4. Upgrade to passwordless authentication (Q3 2025)

Expected outcome: Reduce residual likelihood from 2 to 1,
residual risk score from 8 to 4 (Very Low)

27. Treatment Priority

Purpose: Rank urgency of treatment

Levels:

  • Critical: Immediate action required (within 7 days)
  • High: Urgent action required (within 30 days)
  • Medium: Timely action required (within 90 days)
  • Low: Standard timeline (within 12 months)

Factors:

  • Residual risk level
  • Business criticality
  • Regulatory requirements
  • Resource availability
  • Cost-benefit analysis

Example: High - Treatment to be completed by 2025-02-15

28. Treatment Owner

Purpose: Person responsible for executing treatment plan

Note: May differ from Risk Owner

Example: Mike Chen, IT Security Manager

29. Treatment Status

Purpose: Track implementation progress

Values:

  • Not Started: Treatment planned but not begun
  • In Progress: Treatment implementation underway
  • On Hold: Treatment paused (with reason)
  • Completed: Treatment fully implemented
  • Verified: Treatment effectiveness validated

Example: In Progress - 60% complete

30. Target Completion Date

Purpose: Expected treatment completion

Example: 2025-03-31

31. Actual Completion Date

Purpose: Actual treatment completion

Example: 2025-04-15 (delayed by 2 weeks)


Monitoring and Reporting Fields

32. Risk Acceptance Authority

Purpose: Document who approved accepting residual risk

Required When:

  • Residual risk is Medium or higher
  • Risk is being accepted without additional treatment
  • Risk treatment is delayed or on hold

Example: John Smith, CIO (Approved: 2024-11-20)

33. Next Review Date

Purpose: Schedule next risk reassessment

Standard Frequencies:

  • Extreme/High risks: Monthly
  • Medium risks: Quarterly
  • Low risks: Semi-annually
  • Very Low risks: Annually

Also Review When:

  • New threats or vulnerabilities discovered
  • Control failures occur
  • Business process changes
  • After incidents
  • Regulatory changes

Example: 2025-02-15

34. KRIs (Key Risk Indicators)

Purpose: Metrics to monitor risk trends

Examples:

- Number of failed login attempts (target: <100/month)
- Password reset requests (target: <50/month)
- Privileged access changes (target: <10/month)
- Security incidents related to access (target: 0)
- MFA adoption rate (target: >98%)

35. Related Risks

Purpose: Link connected or dependent risks

Example:

Related to:
- RISK-2024-046 (Weak authentication on application servers)
- RISK-2024-052 (Insufficient access logging on network devices)

Both share common vulnerability: inadequate access controls

36. Related Incidents

Purpose: Link risk to actual security events

Example:

- INC-2024-089: Brute force attack detected (2024-08-12) - Blocked by account lockout
- INC-2024-134: Phishing attempt targeting admin credentials (2024-10-03) - Blocked by MFA

37. Notes/Comments

Purpose: Additional context, history, decisions

Include:

  • Rationale for assessment decisions
  • Stakeholder discussions
  • Changes from previous assessments
  • Lessons learned
  • External references (threat reports, compliance requirements)

Example:

2024-11-15: Initial assessment based on industry threat intelligence
showing 40% increase in credential theft attacks targeting healthcare sector.

2024-12-01: Updated after implementing MFA. Reduced residual likelihood
from 3 to 2. Next focus: enhance monitoring capabilities.

2024-12-08: CISO requested monthly reporting on this risk due to recent
industry breaches.

Complete Risk Register Template

Excel/Spreadsheet Format

Sheet 1: Risk Register

Risk IDDate IdentifiedDate UpdatedCategoryStatusAsset IDAsset OwnerProcessRisk DescriptionThreatVulnerabilityInherent LInherent IInherent ScoreInherent RatingExisting ControlsControl EffectivenessControl Test DateGapsResidual LResidual IResidual ScoreResidual RatingRisk OwnerTreatment OptionTreatment PlanPriorityTreatment OwnerTreatment StatusTarget DateActual DateAcceptance AuthorityNext ReviewKRIsRelated RisksRelated IncidentsNotes

Sheet 2: Risk Heat Map

  • Visual matrix showing risk distribution
  • Color-coded by risk level
  • Separate maps for inherent and residual risk

Sheet 3: Risk Treatment Plan

  • Detailed treatment actions
  • Resource requirements
  • Milestones and deadlines
  • Budget allocation

Sheet 4: Risk Trends

  • Historical risk scores
  • Risk aging analysis
  • Treatment effectiveness metrics
  • KRI dashboards

Sheet 5: Definitions

  • Likelihood scale definitions
  • Impact scale definitions
  • Risk rating criteria
  • Control effectiveness criteria
  • Status definitions

Detailed Risk Register Example

Example Risk Entry: Unauthorized Database Access

RISK IDENTIFICATION
Risk ID: RISK-2024-045
Date Identified: 2024-07-15
Date Last Updated: 2024-12-01
Category: Technology - Access Control
Status: Treatment In Progress
Asset ID: ASSET-DB-001
Asset Name: Customer Database (Production)
Asset Owner: Sarah Johnson, VP Customer Operations
Business Process: Customer Order Processing - Payment Collection

RISK DESCRIPTION
Risk Description:
External attackers could exploit weak password controls on the customer
database, leading to unauthorized access and theft of 100,000 customer
records including personal identifiable information (PII) and payment
card data. This would result in GDPR penalties, PCI-DSS non-compliance,
customer notification costs, credit monitoring services, legal fees,
and severe reputational damage.

Threat Source: External Malicious - Opportunistic Cybercriminals
Threat Type: Unauthorized Access / Data Breach
Threat Motivation: Financial Gain
Threat Capability: Medium (publicly available tools)

Vulnerability:
- Password policy allows passwords as short as 8 characters
- No complexity requirements enforced
- No multi-factor authentication on external access
- Passwords rarely changed (no expiration policy)
- Common passwords not blocked
- No adaptive authentication based on risk signals

INHERENT RISK ASSESSMENT (WITHOUT CONTROLS)
Inherent Likelihood: 4 (Likely)
Likelihood Justification:
- External database breaches occur 5-10 times per year in our industry
- Threat intelligence shows targeting of healthcare databases increased 40% in 2024
- Database is internet-facing for legitimate business purposes
- Weak password controls make brute force attacks feasible
- Historical data: 3 attempted brute force attacks in past 12 months

Inherent Impact: 5 (Catastrophic)
Impact Justification:
Financial Impact:
- GDPR penalties: Up to €20M or 4% global revenue (estimated $2-5M)
- PCI-DSS fines: $5,000-$100,000 per month until compliant
- Customer notification: $50 per customer × 100,000 = $5M
- Credit monitoring: $120/customer/year × 100,000 = $12M
- Legal fees and settlements: $2-10M
- Total estimated financial impact: $25-30M

Operational Impact:
- 3-7 days critical system downtime for forensics and remediation
- Customer order processing halted
- Payment collection suspended
- Estimated revenue loss: $500K per day

Reputational Impact:
- National media coverage expected
- Customer trust severely damaged
- Potential loss of 20-30% customer base
- Difficulty acquiring new customers for 12-24 months

Regulatory Impact:
- GDPR Article 33 breach notification required
- PCI-DSS compliance suspended
- Potential regulatory investigation
- Mandatory security audits

Inherent Risk Score: 20 (4 × 5)
Inherent Risk Rating: EXTREME

EXISTING CONTROLS
Control 1: Multi-Factor Authentication (MFA)
- Type: Preventive (Likelihood Reducing)
- Description: All external database access requires password + MFA token
- Implementation: Microsoft Authenticator app
- Coverage: 98% of users (all except 2 legacy service accounts)
- Testing: Configuration review (2024-11-15), Penetration test (2024-09-20)
- Effectiveness: 3 (High)
- Evidence: Configuration screenshots, user enrollment report, failed auth logs

Control 2: Password Complexity Policy
- Type: Preventive (Likelihood Reducing)
- Description: Minimum 12 characters, requires upper/lower/number/symbol
- Implementation: Active Directory Group Policy
- Coverage: All user accounts
- Testing: Policy review (2024-11-15), Sample testing (2024-10-10)
- Effectiveness: 2 (Medium)
- Evidence: GPO export, sample of 50 passwords analyzed (all compliant)
- Gaps: Policy doesn't block common patterns (e.g., "Password123!")

Control 3: Account Lockout Policy
- Type: Preventive (Likelihood Reducing)
- Description: Account locked for 30 minutes after 5 failed login attempts
- Implementation: Active Directory Group Policy
- Coverage: All accounts
- Testing: Configuration review (2024-11-15), Manual testing (2024-10-10)
- Effectiveness: 3 (High)
- Evidence: GPO export, test results showing lockout working

Control 4: Database Access Logging
- Type: Detective (Impact Reducing)
- Description: All database connections and queries logged
- Implementation: Native database auditing + SIEM integration
- Coverage: 100% of access
- Testing: Log review (2024-11-20), SIEM alert testing (2024-09-15)
- Effectiveness: 2 (Medium)
- Evidence: Sample logs, SIEM alert reports
- Gaps: Logs reviewed weekly, not real-time alerting

Control 5: Intrusion Detection System (IDS)
- Type: Detective (Likelihood & Impact Reducing)
- Description: Network IDS monitoring database traffic for suspicious patterns
- Implementation: Snort IDS with custom rules
- Coverage: All network traffic to/from database server
- Testing: Signature testing (2024-10-01), Penetration test validation (2024-09-20)
- Effectiveness: 2 (Medium)
- Evidence: IDS logs, alert samples
- Gaps: Some alerts missed during high-traffic periods

Control 6: Quarterly Access Reviews
- Type: Detective (Likelihood Reducing)
- Description: Formal review of all database access rights
- Implementation: Manual review by IT and data owner
- Coverage: All accounts reviewed
- Testing: Review documentation (Last: 2024-10-15)
- Effectiveness: 2 (Medium)
- Evidence: Access review sign-off sheets
- Gaps: Reviews sometimes delayed, limited automated detection of anomalies

Control 7: Annual Security Awareness Training
- Type: Preventive (Likelihood Reducing)
- Description: Training on password security, phishing, social engineering
- Implementation: Online learning platform
- Coverage: 87% completion rate (target: 100%)
- Testing: Training records review (2024-11-01)
- Effectiveness: 1 (Low)
- Evidence: Training completion reports
- Gaps: 13% non-completion, content not database-specific

Control Testing Summary:
Last Comprehensive Testing: 2024-11-15
Testing Method: Configuration review, penetration testing, log analysis
Tester: Mike Chen, IT Security Manager
Overall Control Environment Rating: Medium (multiple controls with gaps)

RESIDUAL RISK ASSESSMENT (WITH CONTROLS)
Residual Likelihood: 2 (Unlikely)
Likelihood Reduction Justification:
- MFA (High effectiveness): Reduces from 4 to 3 (prevents most credential theft)
- Account Lockout (High effectiveness): Reduces from 3 to 2 (prevents brute force)
- Password Policy (Medium): Maintains at 2 (some improvement)
- Access Reviews (Medium): Maintains at 2 (catches anomalies)
- Combined effect: Reduces from 4 (Likely) to 2 (Unlikely)

Residual Impact: 4 (Major)
Impact Reduction Justification:
- Access Logging (Medium): Reduces from 5 to 4 (faster detection = less data stolen)
- IDS (Medium): Maintains at 4 (limits data exfiltration)
- Combined effect: Reduces from 5 (Catastrophic) to 4 (Major)
- Financial impact reduced to $5-10M due to faster detection and containment

Residual Risk Score: 8 (2 × 4)
Residual Risk Rating: LOW

Risk Reduction: 20 - 8 = 12 points (60% reduction)

RISK TREATMENT
Risk Owner: Sarah Johnson, VP Customer Operations
Risk Owner Contact: [email protected]
Risk Owner Approval: Approved on 2024-11-18

Treatment Option: MODIFY (Apply Additional Controls)
Treatment Rationale:
Residual risk of 8 (Low) is at upper bound of acceptable risk appetite
(target: ≤6). Additional controls justified by:
- High-value asset (100K customer records)
- Regulatory requirements (GDPR, PCI-DSS)
- Industry trend toward stronger authentication
- ROI: Additional controls cost $150K vs potential $5M+ loss

Treatment Plan Summary:
Phase 1 (Q1 2025): Strengthen authentication
- Implement passwordless authentication (FIDO2 tokens)
- Deploy adaptive authentication (risk-based MFA)
- Block common passwords using custom dictionary

Phase 2 (Q2 2025): Enhance monitoring
- Real-time database activity monitoring with automated alerts
- Deploy User and Entity Behavior Analytics (UEBA)
- Implement database encryption at rest

Phase 3 (Q3 2025): Process improvements
- Monthly access reviews (vs quarterly)
- Automated access certification workflow
- Database-specific security training module

Expected Outcome:
- Reduce residual likelihood from 2 to 1 (Rare)
- Reduce residual impact from 4 to 3 (Moderate)
- Target residual risk: 3 (Very Low)

Treatment Priority: HIGH
Priority Justification:
- Current residual risk (8) exceeds long-term target (6)
- Regulatory compliance requirements
- Industry best practices alignment
- Budget approved for FY2025

Treatment Owner: Mike Chen, IT Security Manager
Treatment Owner Contact: [email protected]

Treatment Status: IN PROGRESS (60% complete)
Status Details:
- Passwordless authentication: Pilot testing (20 users)
- Adaptive authentication: Vendor selection complete, procurement in progress
- Password blacklist: Implemented (completed 2024-11-30)
- Real-time monitoring: Requirements defined, RFP issued
- UEBA: Not started
- Encryption at rest: Not started
- Monthly reviews: Process designed, not yet implemented

Target Completion Date: 2025-06-30
Milestones:
- 2025-01-31: Passwordless auth pilot complete
- 2025-02-28: Adaptive auth deployed to production
- 2025-03-31: Real-time monitoring operational
- 2025-04-30: UEBA deployed
- 2025-05-31: Encryption at rest complete
- 2025-06-30: All treatment activities complete and verified

Budget:
- Passwordless authentication: $50K (licenses + hardware tokens)
- Adaptive authentication: $30K (annual subscription)
- Real-time monitoring: $40K (software + implementation)
- UEBA: $25K (annual subscription)
- Encryption: $15K (implementation services)
- Training development: $10K
- Total: $170K (approved in FY2025 security budget)

Actual Completion Date: [To be completed]

RISK ACCEPTANCE
Risk Acceptance Authority: John Smith, CIO
Acceptance Date: 2024-11-20
Acceptance Conditions:
- Current residual risk (8 - Low) accepted for maximum 6 months
- Treatment plan must be completed by 2025-06-30
- Monthly progress reporting to executive leadership
- Immediate escalation if residual risk increases

Acceptance Documentation:
Signed Risk Acceptance Form on file (Doc ID: RA-2024-045)

MONITORING AND REPORTING
Next Review Date: 2025-02-15
Review Frequency: Quarterly (due to ongoing treatment activities)
Review Trigger Events:
- Treatment milestone completion
- New vulnerability or threat discovered
- Control failure
- Regulatory change
- Security incident involving database access

Key Risk Indicators (KRIs):
1. Failed login attempts
   - Current: 150/month
   - Target: <100/month
   - Threshold: >250/month (triggers review)
   - Monitoring: SIEM dashboard, weekly reports

2. Password reset requests
   - Current: 45/month
   - Target: <50/month
   - Threshold: >100/month (triggers review)
   - Monitoring: Help desk ticketing system

3. Privileged database access changes
   - Current: 8/month
   - Target: <10/month
   - Threshold: >20/month (triggers review)
   - Monitoring: Access management system

4. Security incidents related to database access
   - Current: 0 (past 6 months)
   - Target: 0
   - Threshold: Any incident (triggers immediate review)
   - Monitoring: Incident management system

5. MFA adoption rate
   - Current: 98%
   - Target: >98%
   - Threshold: <95% (triggers review)
   - Monitoring: Identity management system

6. Access review completion rate
   - Current: 100% (Q4 2024)
   - Target: 100%
   - Threshold: <100% (triggers review)
   - Monitoring: GRC system

KRI Dashboard: Updated weekly, reviewed by CISO monthly

RELATED ITEMS
Related Risks:
- RISK-2024-046: Weak authentication on application servers
  (Common cause: inadequate password policies)
- RISK-2024-052: Insufficient access logging on network devices
  (Common vulnerability: limited visibility)
- RISK-2024-067: Third-party database access by vendor
  (Same asset affected)

Related Incidents:
- INC-2024-089: Brute force attack detected on admin account (2024-08-12)
  Status: Blocked by account lockout policy, no breach
  Action: Prompted MFA implementation

- INC-2024-134: Phishing attempt targeting DBA credentials (2024-10-03)
  Status: Blocked by MFA, user reported suspicious email
  Action: Enhanced email filtering, additional training

- INC-2024-201: Unauthorized database access by former employee (2024-11-05)
  Status: Access detected within 2 hours, account disabled, no data stolen
  Action: Improved offboarding process, prompted quarterly to monthly reviews

NOTES AND CHANGE HISTORY
2024-07-15 (Initial Assessment - Mike Chen):
Risk identified during annual risk assessment. Initial assessment based on:
- Industry threat intelligence from FS-ISAC showing 40% increase in database attacks
- Gap analysis findings: weak password policy, no MFA
- Business impact analysis for customer database

Initial inherent risk: 20 (Extreme)
Initial residual risk: 16 (High) - Only basic controls in place

2024-08-15 (Control Implementation - Mike Chen):
Implemented MFA on all external access after INC-2024-089 brute force incident.
Updated residual likelihood from 4 to 3, residual risk from 16 to 15 (High).

2024-09-01 (Policy Update - Mike Chen):
Updated password policy to require 12 characters (from 8) and complexity.
Updated residual likelihood from 3 to 2.5, residual risk from 15 to 12 (Medium).

2024-10-15 (Control Testing - Sarah Patel, Internal Audit):
Conducted quarterly access review. Identified and removed 15 inactive accounts.
Control effectiveness confirmed. No change to risk scores.

2024-11-01 (Quarterly Review - Mike Chen):
Comprehensive control testing and penetration test results incorporated.
Updated control effectiveness ratings based on test results.
Residual risk reduced from 12 to 8 (Low) due to accumulated control improvements.

2024-11-18 (Treatment Planning - Risk Committee):
Risk Committee approved treatment plan and budget.
Target: Reduce residual risk to 3 (Very Low) by Q2 2025.

2024-11-20 (Risk Acceptance - John Smith, CIO):
CIO accepted current residual risk (8) for 6-month period conditional on
treatment plan completion. Requires monthly progress reporting.

2024-11-30 (Treatment Progress - Mike Chen):
Completed password blacklist implementation (blocks 1000 most common passwords).
Estimated small additional reduction in likelihood.

2024-12-01 (Status Update - Mike Chen):
Treatment plan 60% complete. Passwordless auth in pilot testing.
Adaptive auth procurement in progress. Real-time monitoring RFP issued.
On track for Q2 2025 completion target.

AUDIT TRAIL
Created By: Mike Chen, IT Security Manager ([email protected])
Created Date: 2024-07-15
Last Modified By: Mike Chen, IT Security Manager
Last Modified Date: 2024-12-01
Last Reviewed By: Sarah Johnson, VP Customer Operations
Last Review Date: 2024-11-18
Last Approved By: John Smith, CIO
Last Approval Date: 2024-11-20

Next Scheduled Review: 2025-02-15
Next Scheduled Audit: 2025-03-01 (Internal Audit - Quarterly Sample)

Risk Register Management Best Practices

1. Keep It Current

Stale Risk Register = Useless Risk Register

Update Triggers:

  • New risks identified
  • Control changes (added, removed, modified)
  • Security incidents occur
  • Threat landscape changes
  • Organizational changes (new systems, processes, personnel)
  • Regulatory updates
  • Scheduled reviews (quarterly minimum)

Red Flags:

  • Risks not updated in >6 months
  • No risks in "In Progress" status (indicates no active risk management)
  • All risks rated "Low" (unrealistic)
  • Treatment dates consistently missed without explanation

Solution:

  • Assign risk register curator (often CISO or GRC Manager)
  • Implement automated reminders for review dates
  • Include risk register updates in change management process
  • Review register health in monthly security meetings

2. Ensure Risk Ownership

Every Risk Must Have an Owner

Risk Owner Responsibilities:

  • Approve risk assessment and ratings
  • Make treatment decisions (accept, modify, avoid, transfer)
  • Allocate resources for treatment
  • Monitor risk levels and KRIs
  • Escalate changes in risk
  • Participate in periodic reviews

Ownership Criteria:

  • Must have budget authority
  • Must own the affected asset or business process
  • Must have decision-making authority
  • Cannot delegate accountability (can delegate tasks)

Common Mistakes:

  • Assigning all risks to CISO (CISO facilitates, doesn't own business risks)
  • Assigning to junior staff without authority
  • Assigning to committees without clear accountability
  • Leaving ownership field blank

Best Practice:

Risk: Unauthorized database access
Asset: Customer Database
Risk Owner: Sarah Johnson, VP Customer Operations
   (Owns the customer data and order processing business function)
Treatment Owner: Mike Chen, IT Security Manager
   (Implements technical controls)

3. Link to Asset Inventory

Risk Management Starts with Asset Management

Integration Benefits:

  • Ensures all critical assets have risk assessments
  • Provides asset context (classification, owner, dependencies)
  • Enables asset-based risk aggregation
  • Supports decommissioning decisions (asset value vs risk cost)

Implementation:

  • Use consistent asset IDs across asset inventory and risk register
  • Include asset classification (C-I-A ratings) in risk description
  • Cross-reference business processes
  • Identify asset dependencies and cascading risks

Example:

Asset ID: ASSET-DB-001
Asset Name: Customer Database
Classification: Confidential (High), Integrity (High), Availability (High)
Business Process: Customer Order Processing
Dependencies: Payment Gateway (ASSET-APP-005), Web Application (ASSET-APP-003)

Risks:
- RISK-2024-045: Unauthorized access (Residual: 8 - Low)
- RISK-2024-067: Third-party vendor breach (Residual: 9 - Low)
- RISK-2024-089: Database corruption (Residual: 6 - Low)

Aggregate Asset Risk: 23 (across all risks)
Risk Treatment Investment: $250K (FY2025)
Asset Value: $50M (annual revenue dependency)
Risk/Value Ratio: 0.5% (well within acceptable range)

4. Use Consistent Criteria

Consistency Enables Comparison and Prioritization

Document and Communicate:

  • Likelihood definitions (with specific frequency ranges)
  • Impact definitions (with financial thresholds)
  • Control effectiveness criteria
  • Risk rating methodology
  • Treatment decision criteria

Calibration Process:

  • Initial assessor reviews (2-3 assessors independently rate same risk)
  • Group calibration sessions (quarterly)
  • Sample re-assessment by different assessors
  • Benchmark against industry peers
  • Adjust criteria based on lessons learned

Example Calibration Exercise:

Risk Scenario: Phishing attack leading to ransomware

Assessor 1: Likelihood = 4, Impact = 5, Risk = 20
Assessor 2: Likelihood = 5, Impact = 4, Risk = 20
Assessor 3: Likelihood = 4, Impact = 4, Risk = 16

Discussion:
- Likelihood: Consensus = 4 (1-3 times per year based on industry data)
- Impact: Consensus = 5 (ransomware would halt operations >1 week, cost >$1M)
- Final Rating: 20 (Extreme)

Lesson: Assessor 3 underestimated impact. Provided additional guidance on
ransomware impact assessment (downtime cost calculation).

5. Report Regularly

Risk Register Data Must Drive Decisions

Standard Reports:

Executive Dashboard (Monthly):

  • Total number of risks by rating (Extreme/High/Medium/Low)
  • Risk trends (increasing/decreasing/stable)
  • Top 10 risks by residual score
  • Treatment progress (planned/in progress/complete)
  • Overdue treatment plans
  • New risks identified
  • Risk appetite compliance

Board Report (Quarterly):

  • Top 5 strategic risks
  • Risk heat map (inherent vs residual)
  • Risk treatment investments and outcomes
  • Significant risk changes
  • Compliance status
  • Cyber insurance implications

Operational Report (Weekly):

  • KRI status and alerts
  • Risks requiring immediate attention
  • Treatment milestones due this week
  • Control testing results
  • Incident impacts on risk levels

Audit Report (As Needed):

  • Complete risk register
  • Control effectiveness evidence
  • Treatment plan documentation
  • Risk ownership approvals
  • Review and testing documentation

Visualization Examples:

  • Risk heat map (likelihood × impact matrix)
  • Risk trend lines (risk scores over time)
  • Treatment progress Gantt chart
  • Risk distribution by category pie chart
  • KRI dashboard with traffic lights

Common Risk Register Mistakes

Mistake 1: Treating Risk Register as Compliance Checkbox

Wrong Approach: Create risk register only for audit, never update it

Right Approach: Use risk register as living tool for daily risk management

How to Fix:

  • Integrate into operational processes
  • Reference in security meetings
  • Use for budget justification
  • Link to incident management
  • Include in change management decisions

Mistake 2: Too Much Detail (Analysis Paralysis)

Wrong Approach: 50-page risk descriptions with exhaustive analysis

Right Approach: Concise, actionable information that supports decisions

Balance:

  • Risk description: 2-3 sentences
  • Supporting detail: Link to separate documentation
  • Focus on "what matters" not "what's measurable"

Mistake 3: Too Little Detail (Vague Risks)

Wrong Approach: "Security risk to IT systems"

Right Approach: Specific risk scenario with clear threat, vulnerability, impact

Example Transformation:

Before: "Security risk to IT systems"

After: "External attackers could exploit unpatched critical vulnerabilities
in internet-facing web servers, leading to complete server compromise,
customer data breach affecting 50,000 records, and estimated $2M in
incident response and regulatory penalties."

Mistake 4: Confusing Risks with Controls

Wrong Approach: "Risk: Lack of MFA"

Right Approach: "Risk: Unauthorized access to systems. Control gap: No MFA"

Distinction:

  • Risk: The potential event and its impact
  • Control: The mitigation measure
  • Vulnerability: The weakness

Mistake 5: No Control Effectiveness Testing

Wrong Approach: Assume controls work as designed

Right Approach: Test, validate, and document control effectiveness

Testing Methods:

  • Configuration reviews
  • Log analysis
  • Penetration testing
  • User awareness surveys
  • Incident response drills
  • Third-party audits

Mistake 6: Ignoring Residual Risk

Wrong Approach: Only tracking inherent risk

Right Approach: Track both inherent and residual to show control effectiveness

Why It Matters:

  • Inherent risk shows what you're protecting against
  • Residual risk shows if you're doing enough
  • Gap between them shows ROI of security investments

Mistake 7: Unrealistic Risk Ratings

Wrong Approach: All risks rated "High" (drives alert fatigue) or all "Low" (unrealistic)

Right Approach: Realistic distribution based on objective criteria

Realistic Distribution (typical organization):

  • 5-10% Extreme/High
  • 20-30% Medium
  • 60-70% Low/Very Low

Mistake 8: No Treatment Follow-Through

Wrong Approach: Plan treatment but never implement or track

Right Approach: Assign ownership, track progress, report regularly

Accountability Mechanisms:

  • Treatment owner KPIs include completion rate
  • Monthly progress reporting to executive leadership
  • Escalation process for overdue treatments
  • Link treatment completion to performance reviews

Risk Register Tools and Templates

Spreadsheet Template (Excel/Google Sheets)

Advantages:

  • Simple, universally accessible
  • Customizable
  • No cost
  • Familiar to all users

Disadvantages:

  • Version control challenges
  • Limited workflow automation
  • Manual reporting
  • No built-in access controls

Best For: Small organizations (<100 employees), initial implementation

Download Template: [Link to Excel template with all fields, formulas, and conditional formatting]

Dedicated GRC Platforms

Popular Solutions:

  • ServiceNow GRC
  • RSA Archer
  • LogicGate Risk Cloud
  • OneTrust GRC
  • MetricStream
  • NAVEX Global

Advantages:

  • Automated workflows
  • Built-in reporting and dashboards
  • Access controls and audit trails
  • Integration with other security tools
  • Scalable for enterprise

Disadvantages:

  • Significant cost ($10K-$500K+)
  • Implementation complexity
  • Training requirements
  • Vendor lock-in

Best For: Large organizations (>500 employees), mature risk programs

Open-Source Solutions

Options:

  • SimpleRisk
  • Eramba
  • GRCfy

Advantages:

  • No licensing costs
  • Community support
  • Customizable
  • No vendor lock-in

Disadvantages:

  • Requires technical skills to deploy
  • Limited support
  • May lack features of commercial solutions
  • Self-hosting and maintenance required

Best For: Medium organizations (100-500 employees) with IT resources


Risk Register Integration Points

1. Incident Management

Integration:

  • When incident occurs, check if related risk exists in register
  • Update risk assessment based on incident learnings
  • Create new risk if previously unidentified
  • Document incident in "Related Incidents" field
  • Reassess control effectiveness if control failed

Example:

Incident: INC-2024-089 - Brute force attack on admin account
Outcome: Attack blocked by account lockout control

Risk Register Update:
- RISK-2024-045: Validated control effectiveness (account lockout = High)
- RISK-2024-045: Increased inherent likelihood from 3 to 4 based on actual attack
- RISK-2024-045: Residual risk unchanged (control worked as designed)
- Action: Accelerated MFA implementation (treatment plan updated)

2. Change Management

Integration:

  • Before approving change, check impact on relevant risks
  • If change affects risk controls, update risk assessment
  • New systems/processes trigger new risk identification
  • Decommissioned systems remove associated risks

Example:

Change Request: CR-2024-567 - Migrate database to cloud (AWS RDS)

Risk Impact Assessment:
- RISK-2024-045: Residual risk may increase (new attack surface)
- Required: Re-assess risk after migration
- Required: Validate cloud security controls
- New Risks: Create risks for cloud-specific threats (misconfiguration,
  shared responsibility model gaps)

Approval Condition: Complete risk re-assessment within 30 days of migration

3. Vendor Management

Integration:

  • Vendor risk assessments feed into risk register
  • Third-party risks tracked separately
  • Vendor control effectiveness documented
  • Contract renewals trigger risk review

Example:

Vendor: CloudHost Inc. (Cloud Infrastructure Provider)

Risk Register Entry:
RISK-2024-067: Third-party data breach at CloudHost

Asset: Customer Database (hosted on CloudHost)
Threat: Security breach at vendor
Vulnerability: Limited visibility into vendor security practices

Controls:
- Vendor SOC 2 Type II certification (validated annually)
- Contractual security requirements and SLAs
- Data encryption in transit and at rest
- Annual vendor audit

Treatment: Risk transfer (cyber insurance includes third-party vendor incidents)

Next Vendor Review: 2025-03-01 (contract renewal)

4. Compliance Management

Integration:

  • Compliance requirements drive risk identification
  • Risk register demonstrates compliance with ISO 27001 Clause 6.1
  • Audit findings trigger risk reassessment
  • Risk treatment addresses compliance gaps

ISO 27001 Mapping:

Clause 6.1.2 - Information Security Risk Assessment
Evidence: Risk Register showing all identified risks with inherent assessments

Clause 6.1.3 - Information Security Risk Treatment
Evidence: Risk Register showing treatment decisions, plans, and ownership

Clause 8.2 - Information Security Risk Assessment
Evidence: Risk register review dates showing regular reassessment

Clause 8.3 - Information Security Risk Treatment
Evidence: Risk register treatment status showing implementation progress

5. Asset Management

Integration:

  • Asset inventory feeds risk identification
  • Asset classification drives impact assessment
  • Asset decommissioning removes associated risks
  • New assets trigger risk assessment

Example:

New Asset: ASSET-APP-012 (Customer Portal v2.0)

Risk Identification Trigger:
1. Review common risks for web applications
2. Assess application-specific risks
3. Create risk register entries
4. Assign risk owner (Product Owner)
5. Conduct initial risk assessment
6. Approve treatment plans before production deployment

Result:
- 8 new risks identified
- 3 rated High (require treatment before go-live)
- 5 rated Medium/Low (monitor)
- Total treatment budget: $75K
- Go-live approval conditional on High risk treatment completion

Risk Register Reporting and Dashboards

Executive Dashboard

Key Metrics (single-page view):

RISK OVERVIEW (as of 2024-12-08)
Total Risks: 127
├─ Extreme: 2 (▼ from 4 last month)
├─ High: 12 (▲ from 10 last month)
├─ Medium: 38 (─ unchanged)
├─ Low: 62 (─ unchanged)
└─ Very Low: 13 (▲ from 11 last month)

TREATMENT STATUS
Total Treatment Plans: 52
├─ Not Started: 5
├─ In Progress: 28 (54% complete on average)
├─ On Hold: 2 (both due to budget constraints)
├─ Completed: 15 (this quarter)
└─ Verified: 2

OVERDUE TREATMENTS: 3 (require immediate attention)
- RISK-2024-023: Patch management gaps (30 days overdue)
- RISK-2024-041: Vendor security assessment (15 days overdue)
- RISK-2024-078: Backup testing (7 days overdue)

TOP 5 RISKS (by residual score)
1. RISK-2024-012: Ransomware (15 - High) - Treatment 70% complete
2. RISK-2024-034: Insider threat (12 - Medium) - Treatment planned
3. RISK-2024-045: Unauthorized DB access (8 - Low) - Monitoring
4. RISK-2024-089: DDoS attack (8 - Low) - Monitoring
5. RISK-2024-102: Supply chain (8 - Low) - Treatment 40% complete

RISK TRENDS (past 12 months)
▼ Average residual risk score decreased from 11.2 to 8.7 (22% reduction)
▼ Extreme/High risks reduced from 18 to 14 (22% reduction)
▲ Treatment plan completion rate increased from 65% to 78%
▼ Average time to treatment completion decreased from 180 to 120 days

KEY RISK INDICATORS (KRIs)
├─ Security Incidents: 12 (▲ from 8, threshold: 10) - ALERT
├─ Failed Login Attempts: 1,250 (within normal range)
├─ Unpatched Systems: 23 (▼ from 45, threshold: 50)
├─ Overdue Access Reviews: 0 (target: 0)
└─ Training Completion: 94% (▲ from 87%, target: 100%)

BUDGET UTILIZATION
FY2025 Security Budget: $2.5M
└─ Risk Treatment: $850K (34%)
   ├─ Spent: $425K (50% of allocation)
   ├─ Committed: $275K (32%)
   └─ Available: $150K (18%)

COMPLIANCE STATUS
ISO 27001: ✓ Compliant (certification audit: 2024-09-15, no findings)
Next Audit: 2025-09-15 (annual surveillance)
Risk Management Process: Fully documented and operational

Risk Heat Map

Visual representation showing risk distribution:

RESIDUAL RISK HEAT MAP

                          IMPACT
                1     2     3     4     5
           5  [ 2]  [ 1]  [ 3]  [ 4]  [ 1]  (11 risks)
       L   4  [ 5]  [ 3]  [ 7]  [ 2]  [ 0]  (17 risks)
       I   3  [ 8]  [12]  [15]  [ 3]  [ 0]  (38 risks)
       K   2  [15]  [24]  [18]  [ 5]  [ 0]  (62 risks)
       E   1  [ 8]  [ 3]  [ 2]  [ 0]  [ 0]  (13 risks)
       H
       O          (38)  (43)  (45) (14)  ( 1)
       O
       D

Legend:
[Red 20-25]: Extreme - Immediate action
[Orange 15-19]: High - Senior management attention
[Yellow 10-14]: Medium - Management attention
[Green 5-9]: Low - Monitor
[Blue 1-4]: Very Low - Accept

Current Distribution:
- Extreme/High Risk Zone (Red/Orange): 14 risks (11%)
- Medium Risk Zone (Yellow): 38 risks (30%)
- Low Risk Zone (Green/Blue): 75 risks (59%)

Target Distribution:
- Extreme/High: <10% (currently 11%, close to target)
- Medium: 20-30% (currently 30%, at upper target)
- Low/Very Low: >60% (currently 59%, slightly below target)

Action Required: Focus on reducing 5-7 Medium risks to Low within next quarter

Risk Trend Analysis

Track risk evolution over time:

RISK SCORE TRENDS (Past 12 Months)

Month      | Extreme | High | Medium | Low  | Avg Score
-----------|---------|------|--------|------|----------
2024-01    |    6    |  14  |   42   |  65  |   11.2
2024-02    |    5    |  14  |   41   |  67  |   10.8
2024-03    |    4    |  13  |   40   |  70  |   10.3
2024-04    |    4    |  12  |   39   |  72  |    9.9
2024-05    |    4    |  11  |   38   |  74  |    9.5
2024-06    |    3    |  11  |   38   |  75  |    9.2
2024-07    |    3    |  10  |   39   |  75  |    9.0
2024-08    |    3    |  10  |   39   |  75  |    8.9
2024-09    |    3    |  11  |   38   |  75  |    8.9
2024-10    |    2    |  11  |   38   |  76  |    8.8
2024-11    |    2    |  12  |   38   |  75  |    8.7
2024-12    |    2    |  12  |   38   |  75  |    8.7

Trend Analysis:
✓ Significant improvement: Average risk score reduced 22% (11.2 → 8.7)
✓ Extreme risks reduced from 6 to 2 (67% reduction)
✓ High risks relatively stable (14 → 12, minor reduction)
✓ Medium risks stable (42 → 38, minor reduction)
✓ Low risks increased (65 → 75, reflects successful risk treatment)

Key Drivers of Improvement:
1. MFA implementation across organization (Q1-Q2)
2. Patch management automation (Q2-Q3)
3. Security awareness training program (Q1-Q4)
4. Cloud security posture management (Q2-Q3)
5. Enhanced logging and monitoring (Q3-Q4)

Concerns:
⚠ High risks increased slightly from 10 to 12 (Nov-Dec)
  Cause: 3 new High risks identified (ransomware, supply chain, DDoS)
  Action: Treatment plans approved, implementation starting Q1 2025

Next Steps: Implementing Your Risk Register

Week 1: Setup

  1. Choose your platform (spreadsheet, GRC tool, open-source)
  2. Customize template with your organization's:
    • Likelihood and impact definitions
    • Risk rating criteria
    • Control effectiveness criteria
    • Treatment decision criteria
  3. Define governance:
    • Who maintains the register (curator)?
    • Who can add/edit risks?
    • Approval workflow
    • Review schedule

Week 2-4: Initial Population

  1. Identify initial risks (target: 20-50 risks for first iteration):
    • Review asset inventory (start with critical assets)
    • Review prior assessments or audits
    • Interview stakeholders
    • Review industry threat intelligence
    • Analyze past incidents
  2. Conduct risk assessments for each risk
  3. Document existing controls
  4. Calculate residual risks
  5. Assign risk owners and get approvals

Month 2: Treatment Planning

  1. Develop treatment plans for unacceptable risks
  2. Prioritize treatments based on risk scores and resources
  3. Assign treatment owners
  4. Define timelines and budgets
  5. Get treatment plan approvals

Month 3: Operationalize

  1. Create reporting dashboards
  2. Set up review schedule (monthly/quarterly)
  3. Integrate with other processes (incident management, change management)
  4. Train risk owners and stakeholders
  5. Conduct first management review

Ongoing: Maintain and Improve

  1. Regular updates (at least quarterly, more for high risks)
  2. Treatment progress tracking (monthly)
  3. Control testing (ongoing)
  4. KRI monitoring (weekly/monthly)
  5. Annual process improvement (calibration, criteria updates)

Key Takeaways

  1. The Risk Register is Your ISMS Foundation: Everything else builds on comprehensive risk identification and assessment

  2. Completeness and Currency Matter Most: Better to have 50 well-maintained risks than 500 stale entries

  3. Risk Ownership is Non-Negotiable: Every risk must have a clearly accountable business owner

  4. Link Everything: Integrate risk register with assets, incidents, changes, and compliance

  5. Report to Drive Action: Regular reporting keeps risk management visible and prioritized

  6. Simple is Better Than Perfect: Start with basics, evolve over time

  7. Test Control Effectiveness: Don't assume controls work—validate with evidence

  8. Track Trends, Not Just Snapshots: Risk management is a continuous journey


Next Lesson: In Lesson 3.7, you'll learn the four risk treatment strategies (Modify, Retain, Avoid, Share) in detail, including when to use each approach, decision frameworks, and cost-benefit analysis techniques to optimize your risk treatment investments.

Complete this lesson

Earn +100 XP and progress to the next lesson