Lab 03 — Risk Assessment

Risk assessment is one of the most important skills in enterprise cybersecurity.

Security teams regularly discover:

Vulnerabilities

Misconfigurations

Weak Controls

Excessive Access

Missing Monitoring

But identifying a weakness is only the beginning.

The real question is:

How much risk does this weakness create for the business?

This lab teaches you how to move from:

Technical Finding
      ↓
Business Impact
      ↓
Risk Decision

Mission Information

Mission: Perform an enterprise cybersecurity risk assessment.

Difficulty: Intermediate

Estimated Time: 60–90 minutes

Primary Skills:

Asset identification
Threat identification
Vulnerability analysis
Control assessment
Likelihood estimation
Impact analysis
Inherent risk
Residual risk
Risk treatment
Risk ownership
Risk register creation
Executive risk reporting

Lab Scenario

You are working as part of an enterprise cybersecurity team.

A recent security review identified several concerns:

Privileged Accounts Without MFA

Publicly Accessible Cloud Resources

Unsupported Servers

Weak Backup Protection

Missing Security Monitoring

Third-Party Access

Leadership does not want a simple list of technical findings.

They want to know:

Which issues matter most?

What could happen?

How likely is it?

What is the business impact?

Which risks should be addressed first?

Who owns each risk?

Your task is to perform a structured cybersecurity risk assessment.

Lab Objective

By the end of this lab, you should be able to:

Define risk assessment scope
Identify critical assets
Identify threat scenarios
Identify vulnerabilities
Review existing controls
Estimate likelihood
Estimate business impact
Calculate qualitative risk
Distinguish inherent and residual risk
Select appropriate risk treatments
Assign risk ownership
Create a risk register
Prioritize remediation
Communicate risk to management
Produce an enterprise risk assessment report

Risk Assessment Lifecycle

Use the following workflow:

01 Define Scope
      ↓
02 Identify Assets
      ↓
03 Identify Threats
      ↓
04 Identify Vulnerabilities
      ↓
05 Review Existing Controls
      ↓
06 Estimate Likelihood
      ↓
07 Estimate Impact
      ↓
08 Determine Risk
      ↓
09 Evaluate Residual Risk
      ↓
10 Select Risk Treatment
      ↓
11 Assign Risk Owner
      ↓
12 Prioritize
      ↓
13 Document Risk Register
      ↓
14 Report to Management

Phase 1 — Define Assessment Scope

Before assessing risk, determine what is being assessed.

Possible scopes include:

One application
One cloud environment
One department
One business process
One technology platform
The entire organization

Example Scope

Assessment:
Customer Payment Platform

Environment:
Production

Assets:
Application
Database
Cloud Infrastructure
Identity Platform
Backups

Business Function:
Online Customer Transactions

Student Task

Create your own assessment scope.

Document:

Business Service

Environment

Systems

Applications

Data

Users

Third Parties

Geographic Scope

Why Scope Matters

Without defined scope:

Risk Assessment
      ↓
Unclear Boundaries
      ↓
Missing Assets
      ↓
Incomplete Risk Picture

Phase 2 — Identify Critical Assets

Risk exists because something valuable can be harmed.

An asset may be:

Information

Application

Infrastructure

Identity

Business Process

Service

Reputation

People

Asset Categories

Information Assets

Examples:

Customer information
Employee information
Financial records
Intellectual property
Credentials

Technology Assets

Examples:

Servers
Databases
Cloud platforms
Network devices
Applications

Business Assets

Examples:

Payment processing
Customer service
Manufacturing
Online sales

Asset Identification Questions

Ask:

What does the business depend on?

What information is most sensitive?

Which systems are essential?

What would cause major disruption if unavailable?

What would create major damage if compromised?

Asset Inventory Example

Asset	Type	Owner	Criticality
Customer Database	Data	Data Owner	Critical
Payment Application	Application	Product Team	Critical
Identity Platform	Infrastructure	IAM Team	Critical
Marketing Site	Application	Marketing	Medium
Development Repository	Software	Engineering	High

Asset Criticality

A simple scale:

Low
Medium
High
Critical

Student Task

Identify at least 10 assets.

For each document:

Asset Name

Asset Type

Owner

Business Function

Criticality

Data Sensitivity

Phase 3 — Identify Threats

A threat is something capable of causing harm.

Threats may include:

External Attackers

Insiders

Malware

Ransomware

Credential Theft

Human Error

Third Parties

Service Outages

Natural Events

Threat vs Vulnerability

Do not confuse them.

Threat:

Credential Theft

Vulnerability:

Privileged Account Without MFA

Risk scenario:

Attacker Steals Password
      ↓
Privileged Account Compromised
      ↓
Critical Systems Accessed

Threat Categories

Cyber Threats

Phishing
Malware
Ransomware
Exploitation
Credential attacks

Insider Threats

Malicious insider
Negligent employee
Privileged misuse

Operational Threats

Configuration error
Accidental deletion
Hardware failure

Third-Party Threats

Vendor compromise
Cloud outage
Supply-chain compromise

Threat Scenario

A useful risk assessment evaluates scenarios rather than isolated words.

Weak:

Threat:
Hacker

Better:

Threat Scenario:

An external attacker compromises a privileged
cloud administrator account and modifies
production resources.

Student Task

Create at least 8 threat scenarios.

For each scenario document:

Threat Actor / Event

Target Asset

Attack or Failure Method

Potential Consequence

Phase 4 — Identify Vulnerabilities

A vulnerability is a weakness that a threat may exploit.

Examples include:

Missing MFA

Excessive Permissions

Unpatched Software

Public Exposure

Weak Network Segmentation

Missing Backups

Unsupported Systems

Weak Logging

Vulnerability Sources

Weaknesses may exist in:

Technology
Architecture
Configuration
Processes
People
Governance

Technical Vulnerabilities

Examples:

Unpatched Server

Weak TLS Configuration

Exposed Management Port

Process Vulnerabilities

Examples:

No Access Review

Poor Offboarding

Missing Change Approval

Governance Vulnerabilities

Examples:

No Policy

No Risk Owner

No Security Standard

Student Task

Map vulnerabilities to assets.

Asset	Vulnerability
Cloud Admin Account	MFA missing
Customer Database	Excessive access
Production Server	Unsupported OS
Backup Platform	Same admin credentials as production

Phase 5 — Review Existing Controls

Before rating risk, determine which controls already reduce it.

Controls may be:

Preventive

Detective

Corrective

Deterrent

Compensating

Recovery

Preventive Controls

Attempt to stop an event.

Examples:

MFA

Firewall

Least Privilege

Encryption

Detective Controls

Identify activity.

Examples:

SIEM

Audit Logs

IDS

Security Alerts

Corrective Controls

Help correct identified problems.

Examples:

Patching

Account Removal

Configuration Remediation

Recovery Controls

Support restoration.

Examples:

Backups

Disaster Recovery

Failover

Control Assessment Questions

Ask:

Does the control exist?

Is it implemented everywhere?

Is it operating?

Is it effective?

Can it be bypassed?

Control Example

Risk scenario:

Credential Theft
      ↓
Cloud Administrator Compromise

Existing controls:

Password
MFA
Conditional Access
Logging

The existence of multiple controls may reduce likelihood or impact.

Student Task

For each threat scenario identify existing controls.

Scenario	Existing Controls	Control Effectiveness
Admin compromise	MFA + logging	Strong
Database exposure	Firewall only	Weak
Ransomware	Endpoint security + backup	Moderate

Phase 6 — Estimate Likelihood

Likelihood evaluates how probable a risk scenario is.

A simple qualitative scale:

1 — Rare

2 — Unlikely

3 — Possible

4 — Likely

5 — Almost Certain

Likelihood Factors

Consider:

Exposure
Threat activity
Ease of exploitation
Existing controls
Attack complexity
Historical incidents

Example

Scenario:

Publicly Exposed Administrative Interface
        +
Weak Authentication

Likelihood may be:

4 — Likely

because the service is publicly accessible and poorly protected.

Another Example

Scenario:

Highly Segmented Internal System
        +
Strong MFA
        +
Limited Users

Likelihood may be lower.

Likelihood Should Be Evidence-Based

Avoid:

I Feel Like This Is High

Prefer:

Publicly exposed
Known attack method
Weak authentication
Active threat activity

therefore:

Likelihood = High

Student Task

Assign likelihood to each risk scenario.

Document your reasoning.

Phase 7 — Estimate Impact

Impact measures the consequence if the event occurs.

Impact may include:

Financial

Operational

Legal

Regulatory

Customer

Reputational

Safety

Impact Scale

Use:

1 — Insignificant

2 — Minor

3 — Moderate

4 — Major

5 — Severe

Impact Questions

Ask:

Would customers be affected?

Would operations stop?

Would sensitive data be exposed?

Could regulatory obligations apply?

Would financial losses occur?

Could reputation be damaged?

Example

Scenario:

Customer Database Compromised

Potential impact:

Sensitive Data Exposure
Customer Harm
Legal Consequences
Reputation Damage

Impact:

5 — Severe

Business Impact Matters

A vulnerability in:

Unused Test Server

does not necessarily carry the same impact as one in:

Critical Payment Platform

even if the technical weakness is similar.

Student Task

Assign impact scores to your scenarios.

Explain each rating.

Phase 8 — Determine Risk

A simple qualitative model is:

Likelihood × Impact = Risk Score

Example:

Likelihood = 4
Impact = 5

Risk Score = 20

Example Risk Matrix

Score	Risk
1–4	Low
5–9	Medium
10–16	High
17–25	Critical

Your organization may use a different model.

The exact numbers matter less than consistency.

Risk Matrix

Impact
  5 | M  H  H  C  C
  4 | M  M  H  H  C
  3 | L  M  M  H  H
  2 | L  L  M  M  H
  1 | L  L  L  M  M
     ----------------
      1  2  3  4  5
         Likelihood

Legend:

L = Low
M = Medium
H = High
C = Critical

Student Task

Calculate risk for every scenario.

Example:

Risk	Likelihood	Impact	Score	Rating
Admin compromise	4	5	20	Critical
Test system outage	2	2	4	Low
Customer data leak	3	5	15	High

Phase 9 — Understand Inherent Risk

Inherent risk is the risk before considering controls.

Example:

Internet-Facing Payment Application
        +
Credential Attack

Without controls:

Likelihood = 5
Impact = 5

Inherent Risk = Critical

Phase 10 — Determine Residual Risk

Residual risk is the risk remaining after controls.

Inherent Risk
      ↓
Security Controls
      ↓
Residual Risk

Example:

Existing controls:

MFA
WAF
Monitoring
Least Privilege

After considering controls:

Likelihood = 2
Impact = 5

Residual Risk = Medium / High

depending on the organization’s risk model.

Important Principle

Controls often reduce likelihood more than impact.

For example:

MFA

may reduce the likelihood of account compromise.

But if compromise still occurs, the impact could remain severe.

Student Task

For each risk, document:

Inherent Risk

Existing Controls

Control Effectiveness

Residual Risk

Risk Table

Scenario	Inherent Risk	Controls	Residual Risk
Admin compromise	Critical	MFA + PAM	Medium
Database exposure	Critical	Weak firewall	High
Data loss	High	Tested backups	Low

Phase 11 — Select Risk Treatment

Once risk is understood, determine what should happen.

Common treatments are:

Mitigate

Avoid

Transfer

Accept

Mitigate

Implement controls to reduce risk.

Example:

Risk:
Privileged Account Compromise

Treatment:
Require MFA
Reduce Privilege
Enable Monitoring

Avoid

Stop the activity creating the risk.

Example:

Risk:
Unsupported Public Application

Treatment:
Retire Application

Transfer

Shift some financial or operational consequences to another party.

Examples may include:

Insurance
Contractual arrangements

Transfer does not eliminate cybersecurity responsibility.

Accept

The appropriate owner acknowledges and accepts residual risk.

Acceptance should be:

Informed
Documented
Authorized
Reviewed

Risk Treatment Decision

Use:

Risk
 ↓
Business Context
 ↓
Available Controls
 ↓
Cost / Benefit
 ↓
Treatment

Student Task

Select a treatment for every risk.

Phase 12 — Assign Risk Ownership

Every significant risk should have an accountable owner.

Risk owner:

Person or Role
Responsible for Ensuring
the Risk Is Appropriately Managed

Security Team vs Risk Owner

Security may:

Identify
Analyze
Recommend
Monitor

But should not automatically:

Own Every Enterprise Risk

Example

Risk:

Payment Application Availability

Possible owner:

Business Service Owner

not necessarily:

SOC Analyst

Student Task

Assign a realistic owner to every risk.

Examples:

Risk	Owner
Payment service outage	Business Service Owner
Excessive cloud privilege	Cloud Platform Owner
Customer data exposure	Data/Business Owner
Third-party dependency	Vendor/Service Owner

Phase 13 — Create the Risk Register

A risk register provides a structured view of enterprise risk.

Risk Register Template

ID	Risk Scenario	Asset	Likelihood	Impact	Risk	Owner	Treatment
R-001	Admin compromise	Cloud Platform	4	5	Critical	Cloud Owner	Mitigate
R-002	Database exposure	Customer DB	3	5	High	Data Owner	Mitigate
R-003	Vendor outage	SaaS Service	3	4	High	Service Owner	Mitigate

Add More Fields

A mature register may include:

Risk ID

Risk Description

Asset

Threat

Vulnerability

Existing Controls

Likelihood

Impact

Inherent Risk

Residual Risk

Owner

Treatment

Target Date

Status

Risk Statement Format

Use:

Because of [vulnerability],
there is a possibility that [threat event]
could affect [asset],
resulting in [business impact].

Example

Because privileged cloud accounts lack MFA,
there is a possibility that stolen credentials
could allow unauthorized administrative access,
resulting in production compromise and service disruption.

This is far more useful than:

MFA Missing

Phase 14 — Prioritize Risks

Do not simply sort by scanner severity.

Use:

Risk Rating
      +
Asset Criticality
      +
Business Context
      +
Control Weakness
      +
Threat Activity

Example Priority

Risk	Rating	Action
Privileged account without MFA	Critical	Immediate
Public customer database	Critical	Immediate
Unsupported production server	High	Short Term
Missing access review	Medium	Medium Term
Outdated documentation	Low	Planned

Immediate Risks

Usually involve scenarios where:

High Likelihood
      +
Severe Impact

or where active compromise may already exist.

Phase 15 — Build a Risk Treatment Plan

Organize actions into:

Immediate

Short Term

Medium Term

Strategic

Immediate

Examples:

Disable exposed credentials
Remove public sensitive resources
Require administrator MFA

Short Term

Examples:

Patch critical systems
Reduce excessive access
Improve logging

Medium Term

Examples:

Implement PAM
Improve segmentation
Automate access reviews

Strategic

Examples:

Zero Trust program
Security architecture modernization
Enterprise risk governance

Risk Treatment Plan

Risk	Treatment	Action	Owner	Target
Admin compromise	Mitigate	MFA + PAM	IAM Owner	Immediate
Public DB	Mitigate	Private access	Cloud Owner	Immediate
Legacy server	Avoid/Mitigate	Replace	System Owner	90 Days

Phase 16 — Quantitative Risk Concepts

Most enterprise assessments use qualitative or semi-quantitative methods.

However, understand the basic quantitative concepts.

Single Loss Expectancy

SLE = Asset Value × Exposure Factor

Example:

Asset Value = $100,000

Exposure Factor = 50%

SLE = $50,000

Annual Rate of Occurrence

ARO estimates how frequently an event may occur in a year.

Example:

ARO = 0.5

means approximately once every two years.

Annual Loss Expectancy

ALE = SLE × ARO

Example:

SLE = $50,000

ARO = 0.5

ALE = $25,000

Why Quantitative Risk Helps

It may support decisions such as:

Control Cost
      ↓
Compared With
      ↓
Expected Loss Reduction

But precise-looking numbers should not create false confidence.

Phase 17 — Evaluate Control Effectiveness

Risk assessment is not complete without understanding whether controls work.

For each important control ask:

Is it designed appropriately?

Is it implemented?

Is it operating?

Is it effective?

Control Effectiveness Rating

Use:

Strong

Moderate

Weak

Not Implemented

Example

Control	Status	Effectiveness
Admin MFA	Partial	Weak
Endpoint Protection	Deployed	Strong
Backup	Enabled	Moderate
Access Review	Missing	None

Compensating Controls

Sometimes the preferred control cannot be implemented immediately.

A compensating control may reduce risk temporarily.

Example:

Preferred:

MFA on Legacy Administrative System

Not technically possible.

Possible temporary compensating controls:

Restricted Network Access
      +
Dedicated Admin Hosts
      +
Enhanced Monitoring

Residual risk should still be documented.

Phase 18 — Risk Acceptance

Not every risk will be remediated.

Reasons may include:

Cost
Business requirement
Technical limitation
Low risk
Planned retirement

Proper Risk Acceptance

Should contain:

Risk Description

Business Impact

Residual Risk

Reason for Acceptance

Compensating Controls

Approver

Review Date

Poor Risk Acceptance

Avoid:

Engineering Team Decided
Not to Fix It.

Better

Risk reviewed by the appropriate owner,
residual exposure understood,
acceptance documented,
and review scheduled.

Phase 19 — Risk Monitoring

Risk changes over time.

Example:

Low-Risk Internal System
      ↓
Business Decision
      ↓
System Becomes Internet-Facing
      ↓
Risk Changes

Risk Monitoring Triggers

Reassess when:

Architecture changes
New vulnerabilities emerge
Threat activity changes
New regulations apply
Major incidents occur
New vendors are introduced

Risk Lifecycle

Identify
 ↓
Assess
 ↓
Treat
 ↓
Monitor
 ↓
Review
 ↓
Close / Reassess

Phase 20 — Executive Risk Reporting

Executives usually need concise risk information.

Avoid:

CVSS 9.8
Port 443
CVE-XXXX
IAM Policy JSON

unless specifically relevant.

Translate into:

Risk
Business Impact
Trend
Recommended Action
Decision Required

Example

Technical:

Cloud administrator accounts have no MFA.

Executive:

Several privileged cloud accounts rely on password-only
authentication. Credential theft could provide unauthorized
administrative access to critical production systems.
Immediate remediation is recommended.

Executive Risk Dashboard

Example:

Risk	Rating	Trend	Owner	Status
Privileged compromise	Critical	↑	Cloud Owner	Open
Customer data exposure	High	→	Data Owner	Mitigating
Ransomware recovery	High	↓	Infrastructure	Improving

Trend Indicators

Use:

↑ Increasing Risk

→ Stable Risk

↓ Decreasing Risk

Practical Exercise 1 — Privileged Account Risk

Scenario:

Cloud Administrator
      ↓
Password Only
      ↓
Internet Accessible Identity Platform

Asset:

Production Cloud Environment

Threat:

Credential Theft

Vulnerability:

Missing MFA

Impact:

Potential Full Administrative Control

Student task:

Determine:

Likelihood

Impact

Inherent Risk

Recommended Controls

Residual Risk

Risk Owner

Practical Exercise 2 — Public Database

Scenario:

Customer Database
      ↓
Public Network Exposure
      ↓
Sensitive Information

Assess:

Asset
Threat
Vulnerability
Controls
Likelihood
Impact
Risk treatment

Practical Exercise 3 — Unsupported Server

Scenario:

Production Server
      ↓
Unsupported Operating System
      ↓
Security Updates Unavailable

Consider:

Could it be patched?

Could it be isolated?

Should it be replaced?

What business dependency prevents retirement?

Practical Exercise 4 — Ransomware Recovery Risk

Scenario:

Production Environment
       +
Backups
       ↓
Same Privileged Accounts

Attack path:

Administrator Compromised
      ↓
Production Encrypted
      ↓
Backups Deleted

Assess the resulting resilience risk.

Practical Exercise 5 — Third-Party Risk

Scenario:

External Vendor
      ↓
Remote Access
      ↓
Production Application

Review:

Authentication
Access scope
Monitoring
Contract
Offboarding
Incident notification

Practical Exercise 6 — Missing Monitoring

Scenario:

Critical Cloud Environment
      ↓
Audit Logs Enabled
      ↓
No Alerting

Ask:

Does logging alone sufficiently reduce risk?

Document the residual detection risk.

Enterprise Risk Finding Template

Use:

Risk ID:
[R-XXX]

Risk Title:
[Short description]

Asset:
[Business or technology asset]

Threat:
[Threat scenario]

Vulnerability:
[Weakness]

Existing Controls:
[Current controls]

Likelihood:
[1–5]

Impact:
[1–5]

Inherent Risk:
[Rating]

Residual Risk:
[Rating]

Treatment:
[Mitigate / Avoid / Transfer / Accept]

Risk Owner:
[Role]

Recommendation:
[Action]

Example Completed Risk

Risk ID:
R-001

Risk Title:
Privileged Cloud Account Compromise

Asset:
Production Cloud Environment

Threat:
Credential theft targeting cloud administrators

Vulnerability:
MFA is not enforced for all administrators

Existing Controls:
Password authentication and audit logging

Likelihood:
4 — Likely

Impact:
5 — Severe

Inherent Risk:
Critical

Treatment:
Mitigate

Recommendation:
Require approved MFA,
review privileged membership,
reduce standing privilege,
and monitor administrative activity.

Residual Risk:
Medium after full control implementation

Risk Owner:
Cloud Platform Owner

Risk Assessment Report Structure

Your final report should contain:

01 Executive Summary

02 Assessment Scope

03 Methodology

04 Critical Assets

05 Threat Scenarios

06 Vulnerabilities

07 Existing Controls

08 Risk Ratings

09 Risk Register

10 Treatment Recommendations

11 Residual Risk

12 Remediation Roadmap

13 Management Decisions Required

Executive Summary Template

Assessment Objective:

Evaluate cybersecurity risks affecting
the assessed business environment.

Overall Risk Level:

[Low / Moderate / High / Critical]

Highest Risks:

1. [Risk]
2. [Risk]
3. [Risk]

Primary Business Impact:

[Summary]

Immediate Actions:

1. [Action]
2. [Action]
3. [Action]

Management Decisions Required:

[Risk acceptance / funding / ownership]

Risk Assessment Scorecard

Area	Risk
Identity	Critical
Network	High
Data	High
Vulnerability Management	Moderate
Monitoring	High
Resilience	High
Third-Party Risk	Moderate

Risk Professional Questions

During every assessment ask:

What are we protecting?

What could happen?

Why could it happen?

How likely is it?

What would the business impact be?

Which controls already exist?

How effective are they?

What risk remains?

Who owns the risk?

What should we do about it?

Common Risk Assessment Mistakes

Mistake 1 — Treating Vulnerability as Risk

Missing MFA

is a control weakness.

Risk is the potential business consequence resulting from that weakness.

Mistake 2 — Using Technical Severity Only

A technically severe vulnerability on an unimportant isolated asset may be lower priority than a moderate weakness affecting a critical business system.

Mistake 3 — Ignoring Existing Controls

Risk should account for control effectiveness.

Mistake 4 — Ignoring Business Impact

Cybersecurity risk must connect to business consequences.

Mistake 5 — Security Accepting Risk

Appropriate risk owners should make acceptance decisions.

Mistake 6 — Never Reviewing Risk Again

Risk is dynamic.

Risk Assessment Deliverables

By the end of this lab, you should produce:

Career Connection

This lab directly supports roles such as:

Cybersecurity Analyst

Security Consultant

GRC Analyst

Risk Analyst

Cloud Security Engineer

Security Architect

Security Manager

Security Program Manager

Risk assessment is particularly important as you move into senior cybersecurity positions.

The higher your responsibility becomes, the more frequently your work changes from:

Is this technically vulnerable?

to:

What risk does this create,
and what should the organization do about it?

Interview Questions After This Lab

You should now be able to answer:

What is cybersecurity risk?
What is an asset?
What is a threat?
What is a vulnerability?
How does a threat differ from a vulnerability?
What is a risk scenario?
What is likelihood?
What is impact?
What is inherent risk?
What is residual risk?
How do existing controls affect risk?
What are preventive controls?
What are detective controls?
What are corrective controls?
What are compensating controls?
What are the primary risk-treatment options?
What does risk mitigation mean?
What does risk avoidance mean?
What does risk transfer mean?
What does risk acceptance mean?
Who should own cybersecurity risk?
What is risk appetite?
What is risk tolerance?
What should a risk register contain?
How do you prioritize cybersecurity risks?
Why should technical severity not be used alone?
What makes a good risk statement?
What is control effectiveness?
What is SLE?
What is ARO?
What is ALE?
How do qualitative and quantitative risk analysis differ?
When should risk be reassessed?
How do you communicate technical risk to executives?
How would you assess privileged account risk?
How would you assess ransomware recovery risk?
How would you assess third-party risk?
What is a risk treatment plan?
Why is residual risk important?
How do you demonstrate that risk has been reduced?

Lab Completion Milestone

After completing this lab, you should be able to move through:

Asset
 ↓
Threat
 ↓
Vulnerability
 ↓
Controls
 ↓
Likelihood
 ↓
Impact
 ↓
Risk
 ↓
Treatment
 ↓
Residual Risk
 ↓
Ownership

The professional transition is:

Finding Security Problems

toward:

Understanding and Managing
Business Cybersecurity Risk

A mature security professional does not simply say:

This vulnerability is critical.

They explain:

What could happen,

how likely it is,

what the business impact could be,

what controls exist,

what risk remains,

and what should be done next.

That is the foundation of enterprise cybersecurity risk management.

What’s Next?

➡️ Lab 04 — Security Architecture

In the next lab, you will move from identifying and prioritizing enterprise risk into designing security controls that address those risks.

You will work through:

Business Requirements
        ↓
Assets and Data
        ↓
Threats and Risk
        ↓
Trust Boundaries
        ↓
Security Requirements
        ↓
Security Architecture
        ↓
Control Placement
        ↓
Validation

The progression is:

Risk Assessment
      ↓
Understand What Must Be Protected
      ↓
Determine Required Controls
      ↓
Design Secure Architecture