01 Perform an Enterprise Risk Assessment

Welcome to Module 11 — Enterprise GRC Transformation Project.

You have completed the foundational work.

You understand:

Governance

Risk Management

Policies

Controls

Compliance

Auditing

Privacy

Third-Party Risk

Business Continuity

Compliance Frameworks

Now you will bring those concepts together into an enterprise transformation project.

Your first assignment is to perform an:

Enterprise
Risk Assessment

This is one of the most important activities performed by a GRC team.

An organization cannot intelligently decide:

Which Controls
Should We Implement?

Which Risks
Should We Fix?

Where Should
We Spend Money?

Which Projects
Should Be Prioritized?

Which Risks
Can We Accept?

until it understands:

What Could Go Wrong?

How Likely Is It?

What Would the
Business Impact Be?

What Controls
Already Exist?

How Much Risk
Remains?

Your goal is to turn:

Technology Problems

into:

Business Risk
Information

that leadership can use to make decisions.

Project Objective

You will conduct an enterprise risk assessment for a fictional organization and create:

Business Context
       ↓
Critical Services
       ↓
Assets & Dependencies
       ↓
Threat Scenarios
       ↓
Existing Controls
       ↓
Likelihood & Impact
       ↓
Inherent Risk
       ↓
Residual Risk
       ↓
Risk Treatment
       ↓
Executive Reporting

Mission Information

Project Type: Enterprise GRC Transformation
Difficulty: Intermediate to Advanced
Estimated Time: 3–5 Hours
Primary Role: GRC Analyst / Cyber Risk Analyst
Supporting Roles: Security / IT / Business / Legal / Privacy / Compliance / BCM
Environment: Spreadsheet, GRC platform, or documentation workspace
Deliverable: Enterprise Risk Assessment Pack

Learning Objectives

By completing this project, you will learn how to:

establish risk-assessment scope.
understand organizational context.
identify business objectives.
identify critical business services.
identify information and technology assets.
map business dependencies.
identify threats.
identify vulnerabilities.
develop enterprise risk scenarios.
distinguish risk from findings and vulnerabilities.
define inherent risk.
define residual risk.
assess likelihood.
assess impact.
evaluate existing controls.
evaluate control effectiveness.
calculate risk scores.
classify risk severity.
define risk appetite and tolerance.
prioritize enterprise risks.
identify risk owners.
select risk-treatment strategies.
create risk-treatment plans.
document accepted risks.
identify key risk indicators.
create enterprise risk registers.
develop risk heat maps.
prepare executive risk reporting.
present material cyber risk in business language.

Scenario

You have been hired as part of the GRC transformation team for:

CloudNova Technologies

CloudNova is a fictional enterprise SaaS provider.

The organization has grown rapidly over the past five years.

It now supports:

8,000+ Enterprise Customers

Multiple SaaS Products

Global Remote Workforce

Public Cloud Infrastructure

Customer Data

APIs

Third-Party Integrations

24x7 Production Services

CloudNova operates across:

India

United States

European Union

Its major technology platforms include:

AWS

Microsoft 365

GitHub

Kubernetes

Customer SaaS Platform

Identity Provider

CI/CD Platforms

SIEM

Endpoint Security

Third-Party SaaS

Management is planning to pursue:

ISO 27001

SOC 2

Enterprise Customer Assurance

Improved GRC Governance

However, the organization currently does not maintain a formal enterprise cyber-risk register.

The Chief Risk Officer asks:

"What Are Our
Top Cyber Risks?"

The security team responds with:

Critical Vulnerabilities

Phishing

Ransomware

Cloud Misconfiguration

Third-Party Risk

But management asks:

"What Does That
Mean for the Business?"

This is your assignment.

Your Mission

Create an enterprise risk assessment that identifies:

What We Are
Trying to Protect

What Could
Go Wrong

Why It
Could Happen

What Business
Impact Could Occur

Which Controls
Currently Exist

How Much
Risk Remains

What Management
Should Do About It

Required Deliverables

Create:

01 Risk Assessment Scope

02 Business Context Assessment

03 Critical Business Service Register

04 Asset & Dependency Register

05 Threat Catalogue

06 Risk Scenario Library

07 Control Assessment

08 Risk Scoring Matrix

09 Enterprise Risk Register

10 Risk Treatment Plan

11 Risk Ownership Matrix

12 Key Risk Indicator Register

13 Risk Heat Map

14 Executive Risk Dashboard

15 Executive Risk Assessment Summary

Part 1 — Understand Enterprise Risk

Enterprise cybersecurity risk exists when:

Threat
      ↓
Exploits
      ↓
Vulnerability
      ↓
Affects
      ↓
Asset / Business Service
      ↓
Creates
      ↓
Business Impact

A simplified model:

Risk
=
Likelihood
×
Impact

But professional enterprise risk assessment requires more than simply multiplying two numbers.

You must understand:

Business Context

Threat

Exposure

Control Environment

Dependencies

Business Impact

Part 2 — Risk Is Not a Vulnerability

A vulnerability:

Critical CVE
on Production Server

is not itself a complete enterprise-risk statement.

A stronger risk statement is:

A threat actor could exploit
an unpatched vulnerability
on an internet-facing
production server,
resulting in unauthorized
access to customer systems
and disruption of the
SaaS platform.

This communicates:

Threat

Weakness

Asset

Event

Impact

Part 3 — Risk Is Not a Finding

Finding:

MFA Missing
on 3 Admin Accounts

Risk:

Compromise of a privileged
administrator account
could enable unauthorized
access to production systems,
resulting in customer data
exposure or service disruption.

The finding is evidence of:

Control Weakness

The risk describes:

Potential Business
Consequence

Part 4 — Define Assessment Scope

Do not begin with:

Assess
Enterprise Risk

without defining what enterprise means.

Document:

Legal Entities

Business Units

Locations

Products

Applications

Infrastructure

Data

Third Parties

Assessment Period

Part 5 — Create Risk Assessment Scope

For this exercise:

Organization:
CloudNova Technologies

Scope:
Enterprise SaaS Operations

Regions:
India
United States
European Union

Technology:
AWS
Kubernetes
Microsoft 365
GitHub
Corporate Endpoints
Third-Party SaaS

Data:
Customer Data
Personal Data
Employee Data
Security Data

Part 6 — Define Exclusions

If something is excluded, document:

What?

Why?

Who Approved?

Risk Created?

Example:

Acquired Subsidiary

Excluded:
Temporary

Reason:
Separate integration project

Owner:
CIO

Review:
Next Quarter

Part 7 — Understand Business Context

Risk cannot be assessed correctly without understanding:

What the
Business Does

Document:

Products

Customers

Markets

Revenue Drivers

Critical Operations

Strategic Goals

Regulatory Environment

Part 8 — Business Objectives

CloudNova’s objectives include:

Maintain 24x7 SaaS Availability

Protect Customer Information

Meet Enterprise
Customer Requirements

Expand Into EU Markets

Achieve ISO 27001

Maintain Customer Trust

Avoid Major Cyber Incidents

Part 9 — Why Business Objectives Matter

A cyber event matters because it threatens:

Business Objectives

Example:

Ransomware
      ↓
SaaS Unavailable
      ↓
Customer Operations
Disrupted
      ↓
Contractual SLAs Missed
      ↓
Revenue / Reputation Impact

Part 10 — Identify Critical Business Services

Start from:

Business Services

not:

Servers

For CloudNova:

Customer SaaS Platform

Customer Authentication

API Services

Billing

Customer Support

Security Monitoring

Software Delivery

Part 11 — Create Critical Service Register

Create:

Service	Owner	Criticality	RTO	Data
SaaS Platform	Product	Critical	2 Hours	Customer
Authentication	IAM	Critical	1 Hour	Identity
API Gateway	Engineering	Critical	2 Hours	Customer
Billing	Finance	High	24 Hours	Financial
Support	Customer Ops	Medium	8 Hours	Customer

Values are illustrative.

Part 12 — Identify Service Dependencies

For:

Customer SaaS Platform

map:

AWS

Kubernetes

Database

Identity Provider

DNS

CI/CD

Monitoring

Third-Party APIs

Conceptually:

Customer Service
       ↓
Application
       ↓
Kubernetes
       ↓
AWS
       ↓
Network / Identity
       ↓
Third Parties

Part 13 — Why Dependencies Matter

Your application may be secure.

But if:

Identity Provider
Fails

customers may still be unable to access the service.

Therefore risk assessment must include:

Dependency Risk

Part 14 — Build Asset Inventory

Identify:

Applications

Servers

Cloud Accounts

Databases

Endpoints

Network Infrastructure

APIs

Source Code

Security Tools

Third Parties

Part 15 — Asset Record

Create:

Asset ID

Asset Name

Type

Owner

Business Service

Data Classification

Criticality

Location

Technology

Dependencies

Part 16 — Asset Criticality

Use:

Critical

High

Medium

Low

based on:

Business Impact

Data Sensitivity

Availability

Financial Impact

Regulatory Impact

Part 17 — Information Assets

Do not forget data.

Examples:

Customer Data

Authentication Data

Source Code

Employee PII

Financial Data

Security Logs

Backup Data

Part 18 — Identify Threats

Create a threat catalogue.

For CloudNova consider:

Ransomware

Phishing

Credential Theft

Cloud Account Compromise

Insider Threat

Application Attack

API Abuse

Supply Chain Attack

DDoS

Third-Party Breach

Data Exfiltration

Configuration Error

Software Vulnerability

Service Outage

Part 19 — Threat Sources

Threat sources may include:

Cybercriminal

Nation-State Actor

Malicious Insider

Careless Employee

Third-Party Actor

Automated Attack

Technology Failure

Natural Event

Part 20 — Threat Events

Example:

Threat Source:
Cybercriminal

Threat Event:
Credential Phishing

Target:
Administrator

Potential Outcome:
Cloud Account Compromise

Part 21 — Identify Vulnerabilities

Weaknesses may include:

Missing MFA

Unpatched Systems

Excessive Privileges

Weak Network Segmentation

Public Cloud Resources

Weak Vendor Controls

Unsupported Software

Weak Backup Testing

Missing Logging

Insecure APIs

Part 22 — Control Weakness vs Vulnerability

Technical vulnerability:

Unpatched
Software

Control weakness:

Patch Process
Fails to Meet SLA

Both can contribute to risk.

Part 23 — Build Risk Scenarios

Use a structured statement:

A [Threat Source]
could [Threat Event]
because of [Weakness],
affecting [Asset / Service],
resulting in [Business Impact].

Part 24 — Risk Scenario 01

A cybercriminal could
compromise a privileged
administrator account
because MFA is not
consistently enforced,
resulting in unauthorized
access to production
cloud resources and
customer data.

Part 25 — Risk Scenario 02

A threat actor could
exploit an unpatched
internet-facing vulnerability
and gain unauthorized
access to the SaaS
environment, resulting
in service disruption
and customer data exposure.

Part 26 — Risk Scenario 03

Ransomware could
compromise corporate
and production systems,
resulting in prolonged
service disruption and
loss of operational capability.

Part 27 — Risk Scenario 04

A critical SaaS vendor
could experience a
cybersecurity incident,
resulting in exposure
of customer information
or disruption of
CloudNova services.

Part 28 — Risk Scenario 05

A cloud configuration
error could expose
sensitive customer data
to unauthorized access,
resulting in privacy,
contractual, and
reputational impact.

Part 29 — Risk Scenario 06

A software supply-chain
compromise could introduce
malicious code into the
production environment,
resulting in unauthorized
access or customer impact.

Part 30 — Risk Scenario 07

Failure of the primary
cloud region could
interrupt critical
customer services,
resulting in SLA breaches
and customer disruption.

Part 31 — Risk Scenario 08

An employee could
fall victim to phishing,
resulting in credential
compromise and unauthorized
access to corporate systems.

Part 32 — Risk Scenario 09

An attacker could
abuse exposed APIs,
resulting in unauthorized
access, data extraction,
or service disruption.

Part 33 — Risk Scenario 10

Failure to restore
production systems
following a cyber incident
could extend business
disruption beyond
acceptable recovery
objectives.

Part 34 — Build Risk Scenario Library

Create:

Risk ID	Scenario	Service	Threat	Weakness
R-001	Privileged compromise	SaaS	Cybercriminal	MFA Gap
R-002	Vulnerability exploitation	SaaS	Threat Actor	Patch Gap
R-003	Ransomware	Enterprise	Cybercriminal	Multiple
R-004	Vendor breach	SaaS	Third Party	Vendor Risk
R-005	Cloud data exposure	SaaS	Misconfiguration	Cloud Config

Part 35 — Identify Existing Controls

For each risk identify:

Preventive Controls

Detective Controls

Corrective Controls

Part 36 — Example — Privileged Account Risk

Existing controls:

MFA

PAM

Least Privilege

Conditional Access

Access Reviews

SIEM Monitoring

Part 37 — Example — Ransomware Risk

Controls:

Email Security

EDR

Vulnerability Management

Network Segmentation

Backups

Incident Response

Security Awareness

Part 38 — Assess Control Effectiveness

Do not assume:

Control Exists
=
Control Effective

Rate controls:

Effective

Partially Effective

Ineffective

Not Implemented

Part 39 — Control Effectiveness Questions

Ask:

Is It Designed Correctly?

Is It Implemented?

Does It Cover
the Correct Scope?

Does It Operate
Consistently?

Is Evidence Available?

Part 40 — Inherent Risk

Inherent Risk is risk before considering the effectiveness of existing controls.

Conceptually:

Threat
      +
Exposure
      +
Impact
      ↓
Inherent Risk

Part 41 — Residual Risk

Residual Risk is the risk remaining after considering controls.

Inherent Risk
      ↓
Controls
      ↓
Residual Risk

Part 42 — Important Principle

Controls rarely reduce risk to:

Zero

There is usually:

Residual Risk

Part 43 — Define Likelihood

Use a five-level scale.

1 — Rare

Highly Unlikely

2 — Unlikely

Possible but
Not Expected

3 — Possible

Could Occur

4 — Likely

Expected to
Occur

5 — Almost Certain

Expected Frequently

Part 44 — Likelihood Factors

Consider:

Threat Activity

Attack Surface

Exposure

Historical Incidents

Control Strength

Exploitability

Industry Trends

Part 45 — Define Impact

Use:

1 — Insignificant

2 — Minor

3 — Moderate

4 — Major

5 — Severe

Part 46 — Impact Dimensions

Evaluate:

Financial

Operational

Regulatory

Customer

Reputation

Confidentiality

Integrity

Availability

Safety

where applicable.

Part 47 — Financial Impact

Example criteria:

1
Minimal Cost

3
Material Business Loss

5
Severe Financial Impact

Exact thresholds should be defined by the organization.

Part 48 — Operational Impact

Consider:

Service Downtime

Business Disruption

Customer Impact

Recovery Effort

Part 49 — Regulatory Impact

Consider:

Notification

Investigation

Fines

Contractual Breach

Certification Impact

Part 50 — Customer Impact

Consider:

Number of Customers

Critical Customers

Data Exposure

Service Availability

SLA Failure

Part 51 — Reputation

Ask:

Would This
Damage Customer
or Market Trust?

Part 52 — Calculate Risk Score

Use:

Likelihood
×
Impact
=
Risk Score

Part 53 — Risk Rating Matrix

Use:

Score	Risk
1–4	Low
5–9	Moderate
10–14	High
15–25	Critical

This is an illustrative methodology.

Part 54 — Example

Risk:

Privileged Cloud
Account Compromise

Likelihood:

Impact:

Score:

Result:

Critical

Part 55 — Inherent Risk Example

Before controls:

Likelihood:
4

Impact:
5

Inherent Risk:
20 — Critical

Part 56 — Evaluate Controls

Controls:

MFA
Partially Effective

PAM
Effective

Monitoring
Effective

Part 57 — Residual Risk

After considering controls:

Likelihood:
3

Impact:
5

Residual Risk:
15 — Critical

Why did impact remain 5?

Because if compromise occurs:

Business Impact
Could Still
Be Severe

Controls primarily reduced likelihood.

Part 58 — Avoid Mathematical Precision Theater

Do not assume:

Risk Score 14

is scientifically different from:

Risk Score 15

The scoring model supports:

Consistent
Decision Making

not perfect prediction.

Part 59 — Apply Professional Judgment

Risk scoring should consider:

Business Context

Threat Intelligence

Control Strength

Dependencies

Management Judgment

Part 60 — Risk Appetite

Risk appetite describes:

Amount and Type
of Risk the
Organization Is
Willing to Accept

Part 61 — Example Appetite

CloudNova has
very low appetite
for unauthorized
customer data
disclosure.

Part 62 — Risk Tolerance

Tolerance defines acceptable variation.

Example:

Critical Customer
Services:

Maximum Acceptable
Unplanned Downtime:
2 Hours

Part 63 — Compare Residual Risk to Appetite

Residual Risk
      ↓
Risk Appetite
      ↓
Within Appetite?
      / \
    Yes  No

Part 64 — If Risk Is Above Appetite

Management should consider:

Reduce

Avoid

Transfer

Accept with
Executive Approval

Part 65 — Risk Treatment Options

Use four common strategies:

Mitigate

Avoid

Transfer

Accept

Part 66 — Mitigate

Implement additional controls.

Example:

Risk:
Cloud Account Compromise

Treatment:
Enforce MFA

Deploy PAM

Improve Monitoring

Part 67 — Avoid

Stop the risky activity.

Example:

Unsupported
Legacy Application
      ↓
Retire System

Part 68 — Transfer

Transfer part of the financial or operational impact.

Examples:

Cyber Insurance

Contractual Risk Transfer

Risk is not completely eliminated.

Part 69 — Accept

Management knowingly accepts:

Residual Risk

because:

Cost of Further
Treatment
>
Expected Benefit

or for another documented reason.

Part 70 — Risk Acceptance Requirements

Document:

Risk

Residual Exposure

Business Justification

Owner

Approver

Expiration

Review Date

Part 71 — Create Risk Treatment Plan

Example:

Risk	Treatment	Action	Owner	Due Date
R-001	Mitigate	Enforce MFA	IAM	TBD
R-002	Mitigate	Patch Critical Assets	IT	TBD
R-003	Mitigate	Improve Recovery	BCM	TBD
R-004	Mitigate	Vendor Monitoring	TPRM	TBD

Part 72 — Define Risk Owner

Every risk requires:

Accountable
Risk Owner

A risk owner should have authority to:

Understand Risk

Fund Treatment

Accept Residual Risk

Escalate Decisions

Part 73 — Risk Owner Is Not Always Security

Example:

Payment Service
Availability Risk

may be owned by:

Head of Payments

not:

CISO

Part 74 — Risk Ownership Matrix

Example:

Risk	Risk Owner
SaaS Availability	CTO
Customer Data Exposure	CISO
Vendor Failure	COO
Privacy Breach	Privacy Officer
Payment Risk	Product Owner

Part 75 — Build Enterprise Risk Register

Your master register should contain:

Risk ID

Risk Title

Risk Scenario

Business Service

Asset

Threat

Vulnerability

Existing Controls

Inherent Likelihood

Inherent Impact

Inherent Risk

Control Effectiveness

Residual Likelihood

Residual Impact

Residual Risk

Risk Appetite

Treatment

Risk Owner

Action Owner

Target Date

Status

Part 76 — Example Risk Register Entry

Risk ID:
R-001

Title:
Privileged Cloud
Account Compromise

Scenario:
A threat actor could
compromise a privileged
cloud administrator
account and gain
unauthorized access
to production systems.

Business Service:
Customer SaaS

Threat:
Credential Theft

Weakness:
Incomplete MFA Coverage

Existing Controls:
MFA
PAM
SIEM
Access Review

Inherent Risk:
20 — Critical

Residual Risk:
15 — Critical

Treatment:
Mitigate

Risk Owner:
CISO

Part 77 — Identify Top Risks

For the project, assess at least:

R-001
Privileged Account Compromise

R-002
Ransomware

R-003
Critical Vulnerability Exploitation

R-004
Cloud Data Exposure

R-005
Third-Party Compromise

R-006
Software Supply-Chain Attack

R-007
Critical Cloud Outage

R-008
Phishing / Credential Theft

R-009
API Attack

R-010
Recovery Failure

Part 78 — Add Privacy Risk

Risk:

Unauthorized Processing
or Disclosure of
Personal Data

Potential impact:

Customer Harm

Regulatory Exposure

Contract Breach

Reputation

Part 79 — Add Insider Risk

Risk:

Privileged Employee
Misuses Authorized
Access

Controls:

Least Privilege

Segregation of Duties

Logging

Access Reviews

DLP

Part 80 — Add Concentration Risk

Example:

Critical SaaS

Backup

Analytics

Identity

Production

all depend on:

Single Cloud
Provider

This creates:

Technology
Concentration Risk

Part 81 — Add Legacy Technology Risk

Risk:

Unsupported Software
Could Be Exploited
Because Security Updates
Are No Longer Available

Part 82 — Add Compliance Risk

Risk:

Failure to maintain
required security controls
could result in failed
customer audits or
certification delays.

Part 83 — Prioritize Risks

Sort by:

Residual Risk

Business Criticality

Risk Appetite

Regulatory Impact

Customer Impact

Threat Activity

Part 84 — Do Not Prioritize Only by Score

Example:

Risk A:
Score 16

Risk B:
Score 15

Risk B may involve:

Regulated Customer Data

and require faster treatment.

Part 85 — Develop Key Risk Indicators

Key Risk Indicator

or:

KRI

helps monitor whether exposure is increasing.

Part 86 — KRI — Privileged Access

Privileged Accounts
Without MFA

Threshold:

Target:
0

Part 87 — KRI — Vulnerability

Critical Vulnerabilities
Past SLA

Part 88 — KRI — Logging

Critical Assets
Not Sending Logs

Part 89 — KRI — Vendor Risk

Critical Vendors
Without Current
Security Assessment

Part 90 — KRI — Resilience

Critical Services
Without Successful
Recovery Test

Part 91 — KRI Register

Create:

KRI	Risk	Frequency	Owner
Admins Without MFA	R-001	Daily	IAM
Critical Vulns Overdue	R-003	Daily	Security
Missing Log Sources	R-009	Daily	SOC
Untested Critical Services	R-010	Monthly	BCM

Part 92 — Define KRI Thresholds

Use:

Green

Amber

Red

Example:

Critical Vulns
Past SLA

0–2
Green

3–5
Amber

>5
Red

Thresholds should be approved by the organization.

Part 93 — Risk Heat Map

Create a:

5 × 5
Risk Matrix

Example:

Impact ↓ / Likelihood →	1	2	3	4	5
5 Severe	5	10	15	20	25
4 Major	4	8	12	16	20
3 Moderate	3	6	9	12	15
2 Minor	2	4	6	8	10
1 Insignificant	1	2	3	4	5

Part 94 — Plot Risks

Example:

R-001
Likelihood 3
Impact 5
Score 15

R-003
Likelihood 4
Impact 4
Score 16

R-007
Likelihood 2
Impact 5
Score 10

Part 95 — Inherent vs Residual Heat Map

Create two views:

Before Controls

and:

After Controls

This helps demonstrate:

Control Effectiveness

Part 96 — Executive Risk Dashboard

Example:

ENTERPRISE CYBER RISK

Critical Risks               3

High Risks                   5

Moderate Risks               7

Low Risks                    4

Risks Above Appetite         4

Overdue Risk Treatments      3

Accepted Risks               2

Illustrative values only.

Part 97 — Top Risk Dashboard

Show:

Top Risk

Residual Rating

Trend

Risk Owner

Treatment Status

Decision Required

Part 98 — Risk Trend

Use:

Increasing

Stable

Decreasing

Example:

Ransomware Risk
Trend:
Increasing

because:

Threat Activity Increased

Critical Vulnerabilities
Remain Open

Part 99 — Executive Risk Narrative

Do not report only:

R-003
Score 16

Explain:

Critical internet-facing
vulnerabilities remain
outside remediation SLA.

Two affected systems
support customer production
services.

Residual risk remains
above approved appetite.

Immediate remediation
is recommended.

Part 100 — Executive Questions

Your assessment should answer:

What Are Our
Top Cyber Risks?

Which Risks
Are Above Appetite?

What Business Services
Could Be Disrupted?

Which Controls
Are Weak?

What Risk
Is Increasing?

What Requires
Investment?

Which Risk
Needs Acceptance?

Who Owns
Each Risk?

What Decision
Is Required?

Risk Assessment Interview Questions

Ask business leaders:

Which Services
Are Most Critical?

What Would
Happen if They
Were Unavailable?

How Long Could
You Operate
Without Them?

Which Customer
Commitments Matter?

Which Data
Is Most Sensitive?

Which Third Parties
Are Critical?

What Risks
Concern You Most?

Ask technology teams:

Which Systems
Support Critical Services?

Where Are
Single Points
of Failure?

Which Technologies
Are Legacy?

Which Vulnerabilities
Are Hard to Fix?

Which Controls
Are Weak?

Which Dependencies
Are External?

Ask security teams:

Which Threats
Are Increasing?

Which Controls
Frequently Fail?

Where Are
Visibility Gaps?

Which Incidents
Have Occurred?

Which Attack Paths
Concern You Most?

Common Mistake — Start With Vulnerability Scanner

An enterprise risk assessment is not:

Vulnerability Report
      ↓
Risk Register

Start with:

Business
      ↓
Critical Services
      ↓
Risk Scenarios

Common Mistake — Generic Risk Statements

Weak:

Ransomware Risk

Better:

Ransomware could
compromise production
and corporate systems,
resulting in prolonged
customer-service disruption
and inability to meet
contractual obligations.

Common Mistake — Risk Without Business Impact

Avoid:

SQL Injection
Risk

Explain:

What Happens
to the Business?

Common Mistake — Every Risk Owned by CISO

Business risk belongs to:

Business
and
Enterprise Leadership

Security supports risk management.

Common Mistake — Treat Risk Score as Science

The score supports:

Prioritization

It does not predict the future with mathematical certainty.

Common Mistake — Ignore Existing Controls

Always assess:

Control Environment

otherwise you cannot determine:

Residual Risk

Common Mistake — Assume Control Exists Therefore Effective

Validate:

Design

Implementation

Operation

Evidence

Common Mistake — No Risk Appetite

Without appetite, teams cannot determine:

Which Risks
Require Treatment?

Common Mistake — Risk Acceptance Forever

Accepted risks should include:

Review Date

Expiration

Changed Conditions

Common Mistake — Risk Register Never Updated

Risk management should be:

Continuous

not:

Annual Spreadsheet
Exercise

Continuous Risk Monitoring

Future-state model:

Threat Intelligence

Vulnerability Data

IAM

SIEM

Cloud

Vendor Risk

Business Changes
        ↓
Risk Indicators
        ↓
Risk Register
        ↓
Risk Dashboard

Risk Trigger Events

Reassess risk when:

Major Incident

New Product

New Country

New Regulation

New Critical Vendor

Cloud Migration

Acquisition

Major Vulnerability

Architecture Change

Enterprise Risk Register Template

Use:

Risk ID:

Risk Title:

Risk Category:

Business Service:

Asset:

Risk Scenario:

Threat:

Vulnerability / Weakness:

Existing Controls:

Control Effectiveness:

Inherent Likelihood:

Inherent Impact:

Inherent Risk:

Residual Likelihood:

Residual Impact:

Residual Risk:

Risk Appetite:

Within Appetite:

Risk Owner:

Treatment:

Treatment Actions:

Action Owner:

Target Date:

KRI:

Risk Trend:

Status:

Last Review:

Next Review:

Risk Treatment Template

Risk ID:

Current Residual Risk:

Treatment Strategy:

Treatment Objective:

Actions:

Control Improvements:

Action Owner:

Budget Required:

Dependencies:

Target Date:

Expected Residual Risk:

Success Criteria:

Risk Acceptance Template

Risk ID:

Risk Description:

Residual Risk:

Reason for Acceptance:

Business Justification:

Existing Controls:

Compensating Controls:

Risk Owner:

Approver:

Acceptance Date:

Expiration Date:

Review Date:

Executive Risk Summary Template

Assessment Objective:

Assessment Scope:

Critical Services:

Number of Risks:

Critical Risks:

High Risks:

Risks Above Appetite:

Top Risk Themes:

Weakest Control Areas:

Top Treatment Priorities:

Investment Requirements:

Accepted Risks:

Executive Decisions Required:

Next Review:

Project Validation Checklist

Scope

legal entities identified.
business units identified.
geographies identified.
products identified.
technology scope identified.
data scope identified.
exclusions documented.

Business Context

business objectives understood.
critical services identified.
service owners assigned.
RTO/RPO considered.
critical dependencies mapped.

Assets

critical applications identified.
cloud resources considered.
information assets identified.
third-party dependencies identified.
asset owners assigned.

Threats

external threats considered.
insider threats considered.
technology failure considered.
third-party risk considered.
supply chain considered.

Risk Scenarios

scenarios are business-focused.
threat identified.
weakness identified.
affected service identified.
impact identified.

Controls

existing controls identified.
control effectiveness assessed.
control gaps identified.
preventive controls considered.
detective controls considered.
corrective controls considered.

Risk Scoring

likelihood methodology established.
impact methodology established.
inherent risk assessed.
residual risk assessed.
professional judgment applied.
appetite considered.

Treatment

treatment strategy defined.
risk owners identified.
action owners identified.
target dates established.
accepted risks approved.

Monitoring

KRIs identified.
thresholds established.
review frequency defined.
trigger events identified.
risk trends tracked.

Reporting

heat map created.
top risks identified.
risks above appetite highlighted.
treatment status reported.
executive decisions identified.

Expected Project Folder

01 Enterprise Risk Assessment
│
├── 01 Risk Assessment Scope
│
├── 02 Business Context Assessment
│
├── 03 Critical Business Services
│
├── 04 Asset & Dependency Register
│
├── 05 Threat Catalogue
│
├── 06 Risk Scenario Library
│
├── 07 Control Assessment
│
├── 08 Risk Scoring Matrix
│
├── 09 Enterprise Risk Register
│
├── 10 Risk Treatment Plan
│
├── 11 Risk Ownership Matrix
│
├── 12 KRI Register
│
├── 13 Risk Heat Map
│
├── 14 Executive Risk Dashboard
│
└── 15 Executive Risk Summary

Success Criteria

You successfully complete this project when you can take:

Business Objective
      ↓
Critical Service
      ↓
Technology Dependency
      ↓
Threat Scenario
      ↓
Existing Controls
      ↓
Inherent Risk
      ↓
Residual Risk
      ↓
Risk Appetite
      ↓
Treatment
      ↓
Executive Decision

and clearly explain:

What Could
Go Wrong?

Why Could
It Happen?

What Business
Would Be Affected?

How Severe
Could It Be?

What Controls
Already Exist?

How Effective
Are They?

How Much Risk
Remains?

Who Owns
the Risk?

What Should
Management Do?

Career Connection

This project reflects work performed by:

GRC Analysts

Cyber Risk Analysts

Enterprise Risk Analysts

Security Risk Consultants

Risk Managers

Security Governance Leads

GRC Managers

Security Architects

The difference between a beginner and a professional risk analyst is often the ability to move from:

"Critical Vulnerability
on Server"

to:

"This weakness creates
a credible attack path
to a customer-facing
service that could
cause material operational
and contractual impact."

That is how technical security becomes:

Enterprise Risk
Management

What’s Next?

➡️ Next: 02 — Build an ISMS

You now understand:

Business Context
        ↓
Critical Services
        ↓
Assets & Dependencies
        ↓
Threats
        ↓
Risk Scenarios
        ↓
Controls
        ↓
Residual Risk
        ↓
Risk Treatment

The next step is to build the management system that governs those risks continuously.

You will create an:

Information Security
Management System

or:

ISMS

You will move from:

Individual Risk
Assessment

to:

Enterprise Security
Governance System

You will design:

ISMS Scope
      ↓
Context
      ↓
Leadership
      ↓
Risk Management
      ↓
Security Objectives
      ↓
Policies
      ↓
Controls
      ↓
Roles & Responsibilities
      ↓
Evidence
      ↓
Performance Measurement
      ↓
Internal Audit
      ↓
Management Review
      ↓
Continual Improvement

The objective is to understand how an organization turns security from:

Individual Projects

into:

A Managed,
Repeatable,
Measurable,
and Continually
Improving Program

➡️ Next: 02 — Build an ISMS