"03 Enterprise Risk Management"

Enterprise Risk Management, commonly referred to as ERM, is the structured process organizations use to identify, analyze, evaluate, treat, monitor, and communicate risks that could affect business objectives.

For a GRC professional, risk management is one of the most important disciplines to understand.

Organizations cannot remove every risk.

Instead, they must determine:

Which risks matter most.
Which risks require immediate action.
Which risks can be accepted.
Which risks should be transferred.
Which risks should be avoided.
Which controls are necessary.
Who owns each risk.
How risk changes over time.

The objective is not to create a risk register filled with hundreds of entries.

The objective is to enable better business decisions.

Learning Objectives

By the end of this lesson, you will be able to:

Explain Enterprise Risk Management.
Understand the enterprise risk lifecycle.
Identify assets, threats, vulnerabilities, and impacts.
Explain inherent and residual risk.
Understand likelihood and impact assessments.
Calculate and interpret risk ratings.
Understand qualitative and quantitative risk analysis.
Build and maintain a risk register.
Identify risk owners and control owners.
Explain common risk treatment strategies.
Understand risk appetite and risk tolerance.
Understand risk escalation and reporting.
Recognize cybersecurity risk as enterprise business risk.
Understand continuous risk monitoring.

1. What Is Enterprise Risk Management?

Enterprise Risk Management is an organization-wide approach for managing uncertainty that could affect business objectives.

Risk may originate from many areas.

Examples include:

Cybersecurity.
Financial operations.
Technology.
Supply chain.
Third parties.
Legal requirements.
Regulations.
Privacy.
Cloud services.
Human resources.
Business operations.
Geopolitical events.
Artificial intelligence.

ERM brings these risks into a structured governance model.

Business Objectives
        │
        ▼
Identify Risks
        │
        ▼
Assess Risks
        │
        ▼
Prioritize Risks
        │
        ▼
Treat Risks
        │
        ▼
Monitor Risks
        │
        ▼
Report Risks
        │
        └──────────────► Continuous Review

2. What Is Risk?

Risk is the possibility that an uncertain event could affect an organizational objective.

In cybersecurity, one common simplified model is:

Risk = Likelihood × Impact

Another conceptual model may consider:

Threat
   +
Vulnerability
   +
Asset
   +
Potential Impact
   =
Risk

For example:

Asset:
Customer database

Threat:
Cyber attacker

Vulnerability:
Publicly exposed database

Potential Event:
Unauthorized access

Impact:
Customer data breach

Risk:
Sensitive customer information could be compromised.

3. Risk Is About Business Objectives

Risk should always be connected to something the organization values.

Examples include:

Revenue.
Customer trust.
Regulatory compliance.
Service availability.
Employee safety.
Intellectual property.
Business reputation.
Operational continuity.

A vulnerability by itself is not the complete business risk.

For example:

Technical Observation:
Critical vulnerability exists on server.

A stronger risk statement would be:

Exploitation of the critical vulnerability could allow unauthorized access to the customer platform, potentially resulting in customer data exposure, service disruption, financial loss, and regulatory impact.

This is the difference between a technical finding and a business risk.

4. Asset, Threat, Vulnerability, and Impact

Risk assessments often begin by understanding four important concepts.

Asset

Something valuable to the organization.

Examples:

Customer information.
Payment data.
Cloud infrastructure.
Employee records.
Applications.
Intellectual property.
Reputation.

Threat

Something capable of causing harm.

Examples:

Cyber attackers.
Malware.
Insider threats.
Natural disasters.
Human error.
Supply-chain compromise.

Vulnerability

A weakness that could be exploited.

Examples:

Weak passwords.
Missing patches.
Public cloud storage.
Excessive privileges.
Unsecured APIs.

Impact

The consequence if the risk occurs.

Examples:

Data breach.
Financial loss.
Regulatory penalties.
System outage.
Reputation damage.

5. Building a Risk Scenario

A useful risk scenario connects these concepts.

Threat
   │
   ▼
Exploits
   │
   ▼
Vulnerability
   │
   ▼
Affects
   │
   ▼
Asset
   │
   ▼
Causes
   │
   ▼
Business Impact

Example:

Threat:
Phishing attacker

Vulnerability:
No MFA

Asset:
Employee account

Event:
Account compromise

Impact:
Unauthorized access to corporate systems

6. Risk Statement Structure

A useful risk statement often follows:

There is a risk that [event] may occur because of [cause or weakness], resulting in [business impact].

Example:

There is a risk that privileged accounts could be compromised because multi-factor authentication is not enforced, resulting in unauthorized administrative access, data exposure, or service disruption.

Good risk statements should be:

Specific.
Understandable.
Business focused.
Actionable.

7. Enterprise Risk Categories

Organizations may classify risks into categories.

Common categories include:

Strategic Risk

Risks affecting long-term business objectives.

Examples:

Failed market expansion.
Poor technology strategy.
Major competitor disruption.

Operational Risk

Risks affecting day-to-day operations.

Examples:

Service outages.
Process failures.
Human error.

Financial Risk

Examples:

Fraud.
Revenue loss.
Currency exposure.
Credit risk.

Compliance Risk

Examples:

Regulatory violations.
Audit failures.
Contract violations.

Cybersecurity Risk

Examples:

Ransomware.
Data breaches.
Identity compromise.
Cloud misconfiguration.

Third-Party Risk

Examples:

Vendor breach.
Supply-chain compromise.
Service provider outage.

8. The Enterprise Risk Lifecycle

A mature ERM process usually follows a lifecycle.

Establish Context
       │
       ▼
Identify Risk
       │
       ▼
Analyze Risk
       │
       ▼
Evaluate Risk
       │
       ▼
Treat Risk
       │
       ▼
Monitor Risk
       │
       ▼
Communicate & Report

Each stage supports better decision-making.

9. Establishing Context

Before assessing risk, understand the environment.

Questions may include:

What business process is being assessed?
What systems support it?
What data is processed?
What regulations apply?
What customers depend on the service?
What is the organization’s risk appetite?
Which stakeholders are involved?

Without context, risk ratings may be misleading.

10. Risk Identification

Risk identification determines what could go wrong.

Common techniques include:

Interviews.
Workshops.
Vulnerability assessments.
Threat intelligence.
Audit findings.
Incident reviews.
Security testing.
Compliance assessments.
Architecture reviews.
Vendor assessments.

The goal is to identify meaningful risk scenarios.

11. Risk Sources

Risk can emerge from many sources.

Examples:

People
   ↓
Human error
Insider threats
Weak awareness

Process
   ↓
Poor approvals
Missing procedures
Weak change management

Technology
   ↓
Vulnerabilities
Misconfigurations
Legacy systems

Third Parties
   ↓
Vendor compromise
Supply-chain risk

External Environment
   ↓
Cybercrime
Regulation
Natural disasters

12. Risk Analysis

After identifying a risk, organizations assess its severity.

Two primary factors are typically used:

Likelihood
Impact

Risk Rating = Likelihood × Impact

The organization may use qualitative or quantitative methods.

13. Likelihood

Likelihood represents the probability that the risk event will occur.

A simple scale might be:

Score	Rating	Description
1	Rare	Highly unlikely
2	Unlikely	Could occur
3	Possible	May occur
4	Likely	Expected to occur
5	Almost Certain	Highly expected

The exact definitions should be documented.

14. Impact

Impact measures the potential consequences.

A common model is:

Score	Rating	Description
1	Insignificant	Minimal effect
2	Minor	Limited impact
3	Moderate	Noticeable impact
4	Major	Significant business effect
5	Severe	Critical enterprise impact

Impact should consider multiple dimensions.

15. Impact Categories

An organization may evaluate:

Financial impact.
Operational impact.
Regulatory impact.
Legal impact.
Customer impact.
Reputation impact.
Safety impact.

For example:

Risk:
Customer database compromise

Financial Impact:
High

Regulatory Impact:
Critical

Operational Impact:
Medium

Reputational Impact:
High

The overall impact may therefore be rated critical.

16. Risk Matrix

A 5 × 5 risk matrix is commonly used.

Likelihood ↓ / Impact →	1	2	3	4	5
5	5	10	15	20	25
4	4	8	12	16	20
3	3	6	9	12	15
2	2	4	6	8	10
1	1	2	3	4	5

Example:

Likelihood = 4
Impact = 5

Risk Score = 4 × 5
Risk Score = 20

This may be categorized as Critical depending on organizational thresholds.

17. Example Risk Classification

An organization may define:

1–4
Low

5–9
Medium

10–16
High

17–25
Critical

These thresholds are organization-specific.

Risk methodology should always be documented.

18. Qualitative Risk Analysis

Qualitative analysis uses descriptive ratings.

Examples:

Low.
Medium.
High.
Critical.

It is commonly used because it is:

Easy to understand.
Fast to perform.
Suitable for workshops.
Useful for executive reporting.

However, it may be subjective.

19. Quantitative Risk Analysis

Quantitative risk analysis attempts to express risk financially.

Concepts may include:

Asset Value.
Exposure Factor.
Single Loss Expectancy.
Annual Rate of Occurrence.
Annual Loss Expectancy.

20. Asset Value

Asset Value represents the financial value associated with an asset.

Example:

Customer Platform Value:
₹50,000,000

The value may include:

Replacement cost.
Revenue.
Regulatory exposure.
Recovery costs.
Business dependency.

21. Exposure Factor

Exposure Factor represents the percentage of asset value potentially lost during a risk event.

Example:

Asset Value:
₹50,000,000

Exposure Factor:
20%

22. Single Loss Expectancy

Single Loss Expectancy estimates the loss from one event.

Formula:

SLE = Asset Value × Exposure Factor

Example:

Asset Value = ₹50,000,000
Exposure Factor = 20%

SLE = ₹10,000,000

23. Annual Rate of Occurrence

Annual Rate of Occurrence estimates how often an event may happen per year.

Examples:

Once per year
ARO = 1

Once every two years
ARO = 0.5

Twice per year
ARO = 2

24. Annual Loss Expectancy

Annual Loss Expectancy estimates expected yearly loss.

Formula:

ALE = SLE × ARO

Example:

SLE = ₹10,000,000
ARO = 0.5

ALE = ₹5,000,000

This can help justify security investments.

25. Quantitative Decision Example

Suppose:

Expected Annual Loss:
₹5,000,000

Security Control Cost:
₹1,000,000 per year

If the control significantly reduces the risk, it may be financially justified.

However, security decisions should also consider:

Legal obligations.
Safety.
Reputation.
Customer trust.
Regulatory requirements.

Not every decision can be reduced purely to financial value.

26. Inherent Risk

Inherent risk is the level of risk before controls are considered.

Example:

Public Cloud Application
        +
Sensitive Customer Data
        +
Internet Exposure
        =
High Inherent Risk

Inherent risk helps organizations understand the natural exposure of an activity.

27. Controls

Controls are safeguards that reduce risk.

Examples include:

MFA.
Encryption.
Firewalls.
Security monitoring.
Access reviews.
Backups.
Policies.
Employee training.

Controls may reduce either:

Likelihood.
Impact.
Or both.

28. Residual Risk

Residual risk is the risk remaining after controls are applied.

Inherent Risk
      │
      ▼
Apply Controls
      │
      ▼
Residual Risk

Example:

Inherent Risk:
Critical

Controls:
MFA
Conditional Access
Privileged Access Management
SIEM Monitoring

Residual Risk:
Medium

The risk owner then decides whether the residual risk is acceptable.

29. Control Effectiveness

Controls must be evaluated for effectiveness.

A control may be:

Effective.
Partially effective.
Ineffective.
Not implemented.

Example:

Required Control:
MFA

Implementation:
90% of privileged accounts protected

Assessment:
Partially Effective

Residual risk should reflect actual control effectiveness.

30. Risk Treatment

Organizations generally have four major options for treating risk.

Risk
 │
 ├── Mitigate
 ├── Avoid
 ├── Transfer
 └── Accept

31. Risk Mitigation

Risk mitigation means implementing controls to reduce risk.

Example:

Risk:
Administrator account compromise

Mitigation:
Enable MFA
Deploy PAM
Monitor privileged sessions

This is one of the most common approaches.

32. Risk Avoidance

Risk avoidance means stopping the risky activity.

Example:

Risk:
Sensitive information stored in unsupported application

Decision:
Decommission the application.

The risk is avoided by removing the activity creating the exposure.

33. Risk Transfer

Risk transfer shifts part of the financial or operational consequence to another party.

Examples:

Cyber insurance.
Outsourced services.
Contractual liability.
Managed security services.

Risk transfer does not necessarily eliminate the organization’s responsibility.

34. Risk Acceptance

Risk acceptance means knowingly retaining the risk.

This may occur because:

Impact is low.
Cost of treatment is excessive.
Risk is within appetite.
Remediation requires time.
Business benefit outweighs exposure.

Risk acceptance should be formally documented.

35. Risk Acceptance Example

Risk:
Legacy application does not support MFA

Current Risk:
High

Compensating Controls:
Restricted network access
Strong passwords
Enhanced monitoring

Owner:
Business Application Director

Decision:
Accept risk temporarily

Expiration:
Six months

Temporary risk acceptance should be reviewed before expiry.

36. Risk Appetite

Risk appetite defines the overall amount and type of risk the organization is willing to accept.

Example:

Customer Data
→ Very Low Risk Appetite

Service Availability
→ Low Risk Appetite

Research Environment
→ Moderate Risk Appetite

Innovation Projects
→ Higher Risk Appetite

Risk appetite helps guide priorities.

37. Risk Tolerance

Risk tolerance defines acceptable boundaries around specific risks.

Example:

Business Objective:
Maintain payment platform availability

Tolerance:
Maximum 30 minutes downtime

If downtime exceeds the threshold, escalation may be required.

38. Risk Capacity

Risk capacity is the maximum risk an organization could absorb before its ability to operate is threatened.

Conceptually:

Risk Capacity
     >
Risk Appetite
     >
Risk Tolerance

Organizations should normally operate well below their risk capacity.

39. Risk Owner

Every major risk should have an owner.

The risk owner is responsible for ensuring the risk is managed appropriately.

Risk owners commonly:

Review risk status.
Approve treatment plans.
Provide resources.
Accept residual risk.
Escalate issues where necessary.

The risk owner should have authority over the affected business area.

40. Control Owner

A control owner is responsible for implementing or operating a specific control.

Example:

Risk:
Privileged account compromise

Risk Owner:
Business Technology Director

Control:
MFA

Control Owner:
IAM Manager

Risk ownership and control ownership are not necessarily the same.

41. Risk Register

The risk register is one of the most important ERM artifacts.

It provides a centralized record of identified risks.

Typical fields include:

Risk ID.
Risk description.
Category.
Asset.
Threat.
Vulnerability.
Likelihood.
Impact.
Inherent risk.
Existing controls.
Residual risk.
Risk owner.
Treatment.
Target date.
Status.

42. Example Risk Register

ID	Risk	Likelihood	Impact	Rating	Owner
R-001	Customer database breach	4	5	Critical	CISO
R-002	Payment platform outage	3	5	High	Application Owner
R-003	Vendor compromise	3	4	High	Procurement
R-004	Employee phishing	4	3	High	Security
R-005	Backup failure	2	5	High	IT Operations

This provides enterprise visibility.

43. Risk Register Lifecycle

Risk registers must be maintained continuously.

Risk Created
     │
     ▼
Risk Assessed
     │
     ▼
Owner Assigned
     │
     ▼
Treatment Planned
     │
     ▼
Actions Tracked
     │
     ▼
Residual Risk Reviewed
     │
     ▼
Risk Closed / Accepted

A risk register that is never updated provides little value.

44. Risk Status

Common risk statuses may include:

Open.
Under Assessment.
Treatment in Progress.
Accepted.
Escalated.
Monitoring.
Closed.

Organizations should define standard status values.

45. Risk Aging

Risk aging measures how long risks remain unresolved.

For example:

Critical Risk:
Open 120 days

Target Remediation:
30 days

This may indicate:

Lack of accountability.
Resource limitations.
Poor governance.
Unclear ownership.

Risk aging is useful for executive reporting.

46. Risk Remediation Plan

High risks should generally have documented remediation plans.

Example:

Risk:
Unpatched Internet-facing systems

Actions:

1. Identify affected systems.
2. Prioritize critical vulnerabilities.
3. Apply security patches.
4. Validate remediation.
5. Implement automated patching.
6. Confirm residual risk.

Each action should have:

Owner.
Due date.
Status.
Evidence.

47. Risk Escalation

Organizations should define escalation thresholds.

Example:

Low Risk
→ Team Manager

Medium Risk
→ Department Manager

High Risk
→ CISO / Risk Committee

Critical Risk
→ Executive Leadership

Escalation ensures significant risks receive appropriate attention.

48. Risk Reporting

Risk reports should support decisions.

Useful information may include:

Number of critical risks.
New risks identified.
Overdue remediation.
Risk trends.
Risks above appetite.
Top business risks.
Accepted risks.
Emerging risks.

Executives usually need summarized business-level reporting.

49. Top Risk Report

An executive report may look like:

Risk	Rating	Trend	Owner	Action
Ransomware	Critical	Increasing	CISO	Improve endpoint controls
Cloud IAM	High	Stable	CIO	Implement PAM
Vendor Risk	High	Increasing	Procurement	Reassess vendors
Data Privacy	High	Stable	Privacy Officer	Strengthen controls

The goal is to show what requires attention.

50. Risk Heat Map

Organizations often visualize risk using heat maps.

Conceptually:

Impact
  ▲
5 │            High      Critical
4 │        Medium     High
3 │     Medium     High
2 │ Low       Medium
1 │ Low       Low
  └──────────────────────►
    1   2   3   4   5

       Likelihood

Risk heat maps help leadership quickly understand concentration of risk.

51. Risk Trend

A risk should not be viewed only as a static rating.

Organizations should understand whether it is:

Increasing.
Stable.
Decreasing.

Example:

Cloud IAM Risk

Q1 → Critical
Q2 → High
Q3 → Medium

This may indicate that remediation is working.

52. Emerging Risk

Emerging risks are new or changing risks that may not yet be fully understood.

Examples include:

Generative AI.
Quantum computing.
New regulations.
Geopolitical instability.
New attack techniques.
Supply-chain concentration.
New cloud dependencies.

ERM should include mechanisms for identifying emerging risks.

53. Cybersecurity Risk and ERM

Cybersecurity should not operate as an isolated risk program.

Cyber risks should be integrated into enterprise risk management.

For example:

Cyber Risk:
Ransomware

Enterprise Consequences:
Operational outage
Revenue loss
Regulatory exposure
Customer impact
Reputation damage

This allows cybersecurity to be compared with other business risks.

54. Risk Aggregation

Individual technical findings may contribute to a larger enterprise risk.

Example:

Finding 1:
Weak passwords

Finding 2:
No MFA

Finding 3:
Excessive privileges

Finding 4:
Poor access monitoring
        │
        ▼
Aggregated Risk:
Enterprise identity compromise

GRC professionals should avoid filling executive risk registers with every individual vulnerability.

Risks should be aggregated at meaningful business levels.

55. Risk Dependencies

Risks may also be connected.

Example:

Cloud Provider Outage
        │
        ▼
Customer Platform Unavailable
        │
        ▼
Revenue Loss
        │
        ▼
Contractual SLA Breach
        │
        ▼
Customer Reputation Impact

Understanding dependencies helps organizations identify systemic risk.

56. Third-Party Risk

Third parties can create significant enterprise risk.

Questions may include:

What data does the vendor access?
Is the vendor business-critical?
What happens if the vendor fails?
Does the vendor maintain appropriate controls?
Where is customer data stored?
Does the vendor use subcontractors?

High-risk vendors should receive greater scrutiny.

57. Cloud Risk

Cloud environments create additional risk considerations.

Examples:

Public exposure.
Excessive IAM permissions.
Insecure storage.
Weak logging.
Data residency.
Shared responsibility misunderstandings.
Dependency on cloud provider availability.

Cloud risks should be included within the enterprise risk register where significant.

58. Compliance Risk

Failure to meet regulatory requirements creates enterprise risk.

Potential consequences include:

Financial penalties.
Legal action.
Loss of certification.
Customer contract violations.
Reputation damage.

Compliance therefore represents one category of business risk.

59. Operational Risk

Not every security risk involves a cyber attacker.

Operational risks may include:

Configuration errors.
Failed backups.
Change failures.
Capacity issues.
Hardware failure.
Human mistakes.

ERM considers both malicious and non-malicious events.

60. Scenario Analysis

Scenario analysis helps organizations consider severe but plausible events.

Example scenario:

A ransomware attack encrypts critical production systems and backups.

Questions may include:

Which services would fail?
How long could operations continue?
What would recovery cost?
Which regulations would apply?
Could backups be restored?
What customer impact would occur?

Scenario analysis is especially valuable for high-impact risks.

61. Risk Workshops

Organizations often conduct risk workshops.

Participants may include:

Business owners.
Security.
GRC.
IT.
Legal.
Compliance.
Privacy.
Risk management.

A workshop may follow:

Define Business Process
        │
        ▼
Identify Critical Assets
        │
        ▼
Identify Risk Scenarios
        │
        ▼
Score Likelihood
        │
        ▼
Score Impact
        │
        ▼
Review Existing Controls
        │
        ▼
Determine Residual Risk

62. Risk Assessment Interviews

GRC professionals frequently perform interviews.

Useful questions include:

What is the business process?
Which systems are critical?
What sensitive information is involved?
What could cause the service to fail?
What controls currently exist?
Have previous incidents occurred?
What happens if the service is unavailable?
Who owns the risk?

Good risk assessment requires understanding the business.

63. Evidence Supporting Risk Assessments

Risk decisions should use reliable information.

Evidence may include:

Vulnerability scans.
Penetration tests.
Incident data.
Audit findings.
Architecture diagrams.
Security configurations.
Threat intelligence.
Business impact assessments.
Vendor reports.
Control testing results.

Evidence improves confidence in risk ratings.

64. Risk Assessment Bias

Risk scoring can become subjective.

Common biases include:

Rating every issue High.
Underestimating familiar risks.
Overestimating recent incidents.
Allowing business pressure to influence ratings.
Inconsistent scoring between teams.

Organizations should use documented criteria and review processes to reduce bias.

65. Common Risk Management Failures

Weak ERM programs often experience:

Risk registers containing outdated entries.
No assigned risk owners.
Every vulnerability becoming a risk.
Inconsistent scoring.
Risks without remediation dates.
Accepted risks without expiration dates.
No connection between cyber risk and business impact.
Risk reports that leadership cannot understand.
Duplicate risks across departments.
Lack of continuous monitoring.

ERM should be designed to drive decisions, not produce paperwork.

66. GRC Professional Responsibilities

As a GRC professional, you may:

Facilitate risk workshops.
Maintain risk registers.
Draft risk statements.
Calculate risk ratings.
Track treatment plans.
Follow up with risk owners.
Prepare risk dashboards.
Escalate overdue risks.
Review accepted risks.
Identify emerging risks.
Support enterprise risk committees.
Map technical findings to business impacts.

67. Example Enterprise Risk Assessment

Consider a cloud-hosted payment application.

Business Objective

Provide continuous payment processing.

Asset

Payment platform.

Threat

Cyber attacker.

Vulnerability

Excessive privileged permissions.

Risk Event

Compromise of privileged cloud account.

Potential Impact

Payment disruption.
Sensitive data exposure.
Regulatory impact.
Revenue loss.

Likelihood

4 — Likely.

Impact

5 — Severe.

Inherent Risk

4 × 5 = 20
Critical

Existing Controls

MFA.
Security logging.
IAM monitoring.

Control Effectiveness

Partially effective.

Residual Risk

High.

Treatment

Deploy privileged access management and reduce permissions.

Risk Owner

Head of Payment Technology.

68. Example Risk Entry

Risk ID:
R-017

Risk:
Privileged cloud accounts could be compromised because excessive permissions and inconsistent privileged access controls exist, potentially resulting in unauthorized access to payment infrastructure, customer data exposure, and service disruption.

Category:
Cybersecurity

Inherent Risk:
Critical

Existing Controls:
MFA
CloudTrail
SIEM Monitoring

Residual Risk:
High

Treatment:
Implement PAM
Reduce standing privileges
Introduce quarterly access reviews

Owner:
Head of Cloud Platform

Target Date:
30 November 2026

This is the type of structured information commonly managed by GRC teams.

69. Risk Monitoring

Risks should be monitored continuously.

Risk ratings may change because:

Controls are implemented.
Threats increase.
New vulnerabilities emerge.
Business processes change.
Regulations change.
Incidents occur.
Systems are retired.

A risk assessment is therefore a snapshot, not a permanent answer.

70. Key Risk Indicators

KRIs help monitor increasing exposure.

Examples include:

Number of critical vulnerabilities.
Percentage of unsupported systems.
Failed backup rate.
Number of privileged accounts.
Number of overdue access reviews.
Percentage of high-risk vendors.
Number of open critical audit findings.

KRIs can help identify when risk is moving beyond tolerance.

71. Continuous Risk Management

Modern organizations are increasingly moving from periodic assessments toward continuous risk management.

Traditional model:

Annual Risk Assessment
        ↓
Report
        ↓
Wait Until Next Year

Modern model:

Continuous Monitoring
        │
        ├── Vulnerability Data
        ├── Cloud Posture
        ├── IAM Data
        ├── Vendor Risk
        ├── Compliance Data
        └── Incidents
        │
        ▼
Dynamic Risk View

This provides more current information.

72. Enterprise Risk Management Mindset

When reviewing a potential issue, ask:

1. What business objective is affected?

2. What asset is involved?

3. What threat exists?

4. What vulnerability exists?

5. What event could occur?

6. What would the business impact be?

7. How likely is the event?

8. What controls already exist?

9. How effective are those controls?

10. What residual risk remains?

11. Who owns the risk?

12. What treatment is appropriate?

13. When should the risk be reviewed?

This structured approach is central to GRC work.

Key Takeaways

Enterprise Risk Management provides a structured approach to managing uncertainty across the organization.
Risk should always be connected to business objectives and business impact.
A risk scenario usually involves an asset, threat, vulnerability, event, and impact.
Likelihood and impact are commonly used to calculate risk ratings.
Qualitative analysis uses descriptive categories such as Low, Medium, and High.
Quantitative analysis attempts to estimate financial loss.
Inherent risk exists before controls.
Residual risk remains after controls.
Controls reduce likelihood, impact, or both.
Common risk treatments are mitigate, avoid, transfer, and accept.
Every significant risk should have an identified owner.
Risk registers provide centralized enterprise risk visibility.
Risk acceptance should be formally approved and periodically reviewed.
Cybersecurity risk should be integrated into wider enterprise risk management.
Risk management is an ongoing process rather than a one-time assessment.

Knowledge Check

Before continuing, make sure you can answer these questions:

What is Enterprise Risk Management?
What is the difference between a technical finding and a business risk?
What are the primary components of a risk scenario?
How are likelihood and impact used?
What is inherent risk?
What is residual risk?
What are the four major risk treatment strategies?
What is the difference between a risk owner and a control owner?
What information is normally maintained in a risk register?
What is risk appetite?
What is risk tolerance?
What is SLE?
What is ALE?
Why should cyber risks be integrated into ERM?
Why must risks be continuously monitored?

What’s Next?

➡️ Next: 04 — Risk Assessment Methodology

In the next lesson, you will move from the overall Enterprise Risk Management process into the practical methodology used to perform structured risk assessments.

You will learn how to define assessment scope, identify assets and dependencies, develop risk scenarios, interview stakeholders, evaluate threats and vulnerabilities, assess existing controls, score inherent and residual risk, document findings, assign ownership, and prepare formal risk assessment reports.

This will prepare you for one of the most important practical activities in the GRC career path: performing an enterprise risk assessment from start to finish.