Runbook 03 — Risk Assessment

This runbook provides a repeatable process for converting technical security observations into structured enterprise risk decisions.

Use it when you need to answer:

What are we protecting?

What could happen?

Why could it happen?

How likely is it?

What would the impact be?

Which controls already reduce the risk?

What risk remains?

What should the organization do next?

The objective is to move from:

Security Finding
      ↓
Risk Scenario
      ↓
Business Impact
      ↓
Risk Decision
      ↓
Treatment
      ↓
Ownership

Runbook Purpose

Use this runbook to perform risk assessments across:

Applications
Cloud environments
Infrastructure
Business processes
Identity systems
Third parties
Data platforms
Enterprise services

The runbook is designed to support consistent, evidence-based risk decisions.

Runbook Scope

This runbook covers:

Scope and context
Asset identification
Business criticality
Threat scenarios
Vulnerabilities and exposures
Existing controls
Control effectiveness
Likelihood
Impact
Inherent risk
Residual risk
Risk appetite
Risk tolerance
Risk treatment
Risk ownership
Risk acceptance
Risk register
Remediation planning
Risk monitoring
Executive reporting

Runbook Inputs

Before starting, collect where available:

Asset Inventory

Architecture Diagrams

Data Classification

Vulnerability Findings

Security Assessment Reports

Incident History

Threat Intelligence

Existing Controls

Policies and Standards

Business Impact Analysis

Previous Risk Register

Third-Party Assessments

Runbook Outputs

At completion, produce:

Risk Assessment Report

Risk Register

Risk Treatment Plan

Control Gap Summary

Residual Risk Summary

Executive Risk Report

Risk Assessment Workflow

Use this sequence:

01 Confirm Scope
      ↓
02 Understand Business Context
      ↓
03 Identify Assets
      ↓
04 Determine Asset Criticality
      ↓
05 Identify Threat Scenarios
      ↓
06 Identify Vulnerabilities
      ↓
07 Review Existing Controls
      ↓
08 Assess Control Effectiveness
      ↓
09 Estimate Likelihood
      ↓
10 Estimate Impact
      ↓
11 Determine Inherent Risk
      ↓
12 Determine Residual Risk
      ↓
13 Compare With Risk Appetite
      ↓
14 Select Risk Treatment
      ↓
15 Assign Risk Owner
      ↓
16 Build Risk Register
      ↓
17 Create Treatment Plan
      ↓
18 Monitor Risk
      ↓
19 Report to Management

Step 01 — Confirm Assessment Scope

Define exactly what is being assessed.

Possible scopes include:

One Application

One Cloud Environment

One Business Process

One Department

One Third Party

One Enterprise Service

Entire Organization

Scope Template

Assessment Name:

Business Unit:

System / Service:

Environment:

Primary Owner:

Critical Data:

Dependencies:

Third Parties:

Excluded Areas:

Assessment Date:

Scope Questions

Ask:

What is included?

What is excluded?

Which environments are covered?

Which data is covered?

Which third parties are involved?

Who owns the service?

Assessment Limitation

If important areas cannot be assessed, document them.

Example:

Assessment Limitation:

The external payment provider's internal
security controls were not independently assessed.

Step 02 — Understand Business Context

Cybersecurity risk should be evaluated in business terms.

Document:

Business Objective

Service Criticality

Customer Dependency

Revenue Dependency

Regulatory Dependency

Availability Requirements

Data Sensitivity

Business Context Questions

Ask:

What happens if this service fails?

What happens if data is exposed?

What happens if data is modified?

How long can the business tolerate downtime?

Which customers are affected?

CIA Impact

Assess potential impact to:

Confidentiality

Integrity

Availability

Broader Business Impact

Also consider:

Financial

Operational

Legal

Regulatory

Reputational

Safety

Step 03 — Identify Assets

Risk exists because something valuable may be harmed.

Identify:

Data

Applications

Infrastructure

Identities

Business Processes

Services

People

Reputation

Asset Inventory Template

Asset	Type	Owner	Data Classification	Criticality
Customer Database	Data	Data Team	Restricted	Critical
Payment API	Application	App Team	Confidential	Critical
Cloud IAM	Identity	Cloud Team	Sensitive	Critical
Employee Portal	Application	IT	Internal	High

Asset Questions

Ask:

Who owns the asset?

What does the business use it for?

What data does it process?

What depends on it?

What depends on its availability?

Step 04 — Determine Asset Criticality

Use an organization-defined scale.

Example:

Low

Medium

High

Critical

Criticality Factors

Consider:

Revenue

Customer Impact

Data Sensitivity

Operational Dependency

Regulatory Impact

Recovery Complexity

Example

Asset:
Customer Payment Platform

Criticality:
Critical

Reason:
Directly supports revenue and
processes sensitive customer information.

Step 05 — Identify Threat Scenarios

Avoid listing vague threats.

Weak:

Hacker

Better:

An external attacker compromises a privileged
administrator account and gains unauthorized
access to production cloud resources.

Threat Sources

Consider:

Cybercriminals
Insiders
Nation-state actors
Contractors
Third parties
Human error
Technology failure
Environmental events

Threat Events

Examples:

Credential Theft

Ransomware

Privilege Escalation

Data Exposure

Unauthorized Modification

Service Outage

Supply-Chain Compromise

Accidental Deletion

Threat Scenario Template

Threat Actor / Event:

Target Asset:

Attack or Failure Method:

Potential Consequence:

Example

Threat Actor:
External attacker

Target:
Privileged cloud account

Method:
Credential theft

Consequence:
Unauthorized administrative access
to production resources

Step 06 — Identify Vulnerabilities and Exposures

A vulnerability is a weakness that can contribute to a threat scenario.

Examples:

Missing MFA

Excessive Privilege

Unpatched Software

Public Exposure

Weak Segmentation

Poor Offboarding

Missing Monitoring

Weak Backup Protection

Vulnerability Categories

Review:

Technical

Configuration

Process

People

Governance

Third Party

Vulnerability vs Threat

Remember:

Threat:
Credential Theft

Vulnerability:
Administrator Does Not Use MFA

Exposure

Exposure describes conditions that may increase likelihood.

Example:

Internet-Facing Administrative Interface

may increase the opportunity for attack.

Step 07 — Review Existing Controls

Identify controls already reducing the risk.

Control types may include:

Preventive

Detective

Corrective

Recovery

Preventive

Examples:

MFA

Firewall

Least Privilege

Encryption

Detective

Examples:

SIEM

Audit Logs

IDS

Security Alerts

Corrective

Examples:

Patching

Account Removal

Configuration Remediation

Recovery

Examples:

Backups

Failover

Disaster Recovery

Control Inventory Template

Risk Scenario	Existing Control	Type	Owner
Admin compromise	MFA	Preventive	IAM
Malware	EDR	Preventive/Detective	SOC
Data loss	Backup	Recovery	Infrastructure
Public exposure	Firewall	Preventive	Network

Step 08 — Assess Control Effectiveness

Do not assume a control is effective simply because it exists.

Review:

Design Effectiveness

Implementation Status

Operating Effectiveness

Design Effectiveness

Ask:

Would this control reduce the identified risk
if implemented correctly?

Operating Effectiveness

Ask:

Is the control actually working as intended?

Example

Control:

MFA Policy

Design:

Strong

Implementation:

Administrators excluded

Operating effectiveness:

Weak

Control Rating

Use:

Strong

Moderate

Weak

Not Implemented

Evidence Sources

Look for:

Configuration

Logs

Tickets

Screenshots

Reports

Access Reviews

Test Results

Step 09 — Estimate Likelihood

Likelihood represents the probability or plausibility that a risk scenario may occur.

Use an organization-defined scale.

Example:

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:

Administrator Without MFA
      +
Internet-Accessible Authentication
      +
High Phishing Exposure

Likelihood:

4 — Likely

Likelihood Evidence

Prefer:

Publicly reachable

Weak authentication

Known attacker technique

Repeated prior attempts

instead of:

Analyst feels likelihood is high.

Step 10 — Estimate Impact

Impact measures potential business consequences.

Use an organization-defined scale.

Example:

1 — Insignificant

2 — Minor

3 — Moderate

4 — Major

5 — Severe

Impact Categories

Consider:

Confidentiality

Integrity

Availability

Financial

Operational

Legal

Regulatory

Reputation

Safety

Example

Scenario:

Customer Database Compromise

Potential impact:

Sensitive data exposure

Customer harm

Regulatory impact

Reputation damage

Impact:

5 — Severe

Step 11 — Determine Inherent Risk

Inherent risk represents the risk before existing controls are considered.

A simple conceptual approach:

Likelihood
    ×
Impact
    ↓
Risk Rating

Organizations may use different methodologies.

Example Risk Matrix

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

Example

Likelihood = 5

Impact = 5

Inherent Risk = Critical

Important

Do not treat mathematical scores as universally objective.

They provide structured consistency, not absolute certainty.

Step 12 — Determine Residual Risk

Residual risk is what remains after considering existing controls.

Inherent Risk
      ↓
Existing Controls
      ↓
Control Effectiveness
      ↓
Residual Risk

Example

Scenario:

Privileged Account Compromise

Inherent risk:

Critical

Controls:

MFA

Conditional Access

PAM

Monitoring

Residual risk:

Medium

if controls are appropriately designed and operating.

Control Impact

A control may reduce:

Likelihood

Impact

or Both

Example:

MFA

primarily reduces likelihood.

Backup

may reduce impact associated with data loss or service disruption.

Step 13 — Compare Risk With Risk Appetite

Risk appetite describes the amount or type of risk the organization is willing to pursue or retain.

Risk Appetite

Example:

Low appetite for unauthorized
access to customer data.

Risk Tolerance

Tolerance provides more specific boundaries.

Example:

No Critical residual risks
may remain open without executive approval.

Decision Flow

Residual Risk
      ↓
Compare With Appetite / Tolerance
      ↓
Acceptable?
   ↙       ↘
 Yes       No
 ↓          ↓
Monitor   Treat

Step 14 — Select Risk Treatment

Common options are:

Mitigate

Avoid

Transfer

Accept

Mitigate

Implement controls to reduce likelihood or impact.

Example:

Enable MFA

Reduce Privilege

Add Monitoring

Avoid

Stop the activity creating the risk.

Example:

Retire unsupported system.

Transfer

Shift part of the financial or operational consequence.

Examples:

Insurance

Contractual Allocation

Transfer does not remove accountability for security.

Accept

Authorized leadership knowingly accepts residual risk.

Treatment Decision Template

Risk ID:

Current Residual Risk:

Treatment:

Reason:

Required Action:

Owner:

Target Date:

Step 15 — Assign Risk Ownership

Cybersecurity teams often identify and analyze risk.

They do not automatically own every business risk.

Risk Owner

The risk owner is accountable for deciding how the risk should be treated.

Possible owners:

Business Service Owner

Application Owner

Data Owner

Technology Owner

Executive Sponsor

Control Owner

Control ownership is different.

Example:

Risk Owner:
Business Application Owner

Control Owner:
IAM Team

Good Ownership Model

Security:
Advises and facilitates

Control Owner:
Operates controls

Risk Owner:
Accepts or drives treatment

Red Flag

Risk Owner:
Security Team

for every business risk

This may indicate unclear accountability.

Step 16 — Build the Risk Register

Use a standard structure.

Risk Register Template

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

Recommended Fields

Include:

Risk ID

Asset / Process

Risk Statement

Threat

Vulnerability

Existing Controls

Control Effectiveness

Likelihood

Impact

Inherent Risk

Residual Risk

Treatment

Risk Owner

Control Owner

Target Date

Status

Review Date

Risk Statement Format

Use:

Because of [condition or vulnerability],
[threat event] could occur,
resulting in [business impact].

Example

Because privileged cloud accounts are not
consistently protected by MFA,
credential theft could lead to unauthorized
administrative access, resulting in production
compromise and service disruption.

Step 17 — Create the Risk Treatment Plan

Translate risk decisions into actions.

Use:

Immediate

Short Term

Medium Term

Strategic

Immediate

Examples:

Disable exposed credentials

Remove public sensitive storage

Enforce administrator MFA

Short Term

Examples:

Patch critical systems

Reduce excessive privilege

Enable missing logging

Medium Term

Examples:

Implement PAM

Improve segmentation

Automate access review

Strategic

Examples:

Zero Trust

Cloud governance

Security architecture modernization

Identity governance

Treatment Tracker

Risk	Action	Owner	Priority	Status
Admin compromise	Enforce MFA	IAM	Critical	Open
Public DB	Remove public access	Cloud	Critical	In Progress
Ransomware	Isolate backups	Infrastructure	High	Planned

Step 18 — Review Risk Acceptance

Risk acceptance should be formal.

Document:

Risk

Residual Rating

Reason

Compensating Controls

Risk Owner

Approver

Expiration / Review Date

Example

Risk:
Legacy application cannot support modern authentication.

Residual Risk:
High

Reason:
Replacement project is scheduled.

Compensating Controls:
Restricted network access,
enhanced monitoring,
limited authorized users.

Review Date:
90 Days

Poor Acceptance

Avoid:

Team decided not to fix it.

Better

Residual risk was reviewed,
documented,
accepted by the authorized owner,
and assigned a future review date.

Step 19 — Monitor Risk

Risk is dynamic.

Reassess when:

New vulnerabilities appear
Architecture changes
Incidents occur
Threat activity changes
Vendors change
Business criticality changes
Controls fail

Risk Monitoring Workflow

Risk Identified
      ↓
Treatment
      ↓
Monitoring
      ↓
Trigger / Change
      ↓
Reassessment

Risk Monitoring Indicators

Potential KRIs include:

Number of Critical Residual Risks

Expired Risk Acceptances

Overdue Remediation

Privileged Accounts Without MFA

Critical Unsupported Systems

Untested Backups

Step 20 — Use Risk Review Cadence

Risk should be reviewed periodically based on importance.

Example:

Critical:
Frequent Review

High:
Regular Review

Medium:
Periodic Review

Low:
Scheduled Review

The exact cadence should follow organizational requirements.

Step 21 — Validate Risk Closure

A risk should not be closed only because a ticket was marked complete.

Verify:

Remediation Implemented
      ↓
Control Tested
      ↓
Residual Risk Reassessed
      ↓
Evidence Recorded
      ↓
Risk Closed

Closure Questions

Ask:

Was the required control implemented?

Is it operating?

Did the risk actually decrease?

Is evidence available?

Step 22 — Handle Compensating Controls

When the preferred control cannot be implemented, consider compensating controls.

Example:

Preferred:

MFA

Not supported by legacy platform.

Potential compensating controls:

Restricted Network

Dedicated Admin Workstation

Enhanced Logging

Limited User Population

Residual risk must still be evaluated.

Step 23 — Assess Common Enterprise Risk Scenarios

Use the following examples for practice.

Scenario 1 — Privileged Account Without MFA

Asset:
Production cloud environment

Threat:
Credential theft

Vulnerability:
Missing MFA

Impact:
Administrative compromise

Treatment:
Mitigate

Potential controls:

MFA

PAM

Least Privilege

Authentication Monitoring

Scenario 2 — Public Sensitive Storage

Asset:
Customer data

Threat:
Unauthorized external access

Vulnerability:
Public exposure

Impact:
Data breach

Potential treatment:

Remove public access

Implement private access

Review IAM

Enable monitoring

Scenario 3 — Unsupported Internet-Facing Server

Asset:
Production application

Threat:
Remote exploitation

Vulnerability:
Unsupported OS

Impact:
System compromise

Potential treatment:

Upgrade

Replace

Isolate

Apply compensating controls

Scenario 4 — Ransomware

Asset:
Production infrastructure

Threat:
Ransomware

Vulnerability:
Weak segmentation
and backup privilege separation

Impact:
Business disruption

Controls:

Endpoint Security

Segmentation

Protected Backup

Recovery Testing

Scenario 5 — Third-Party SaaS Failure

Asset:
Critical business process

Threat:
Vendor outage or breach

Vulnerability:
Dependency on external service

Impact:
Operational disruption
or data exposure

Potential treatment:

Vendor controls

Contractual requirements

Backup process

Continuity planning

Step 24 — Prioritize Risk

Prioritize based on more than a score.

Consider:

Residual Risk

Asset Criticality

Exposure

Exploitability

Threat Activity

Control Weakness

Business Urgency

Example

Risk A:

Critical scanner finding
on isolated development system

Risk B:

High finding
on public production payment system
with active exploitation

Risk B may require earlier action.

Step 25 — Report Risk to Management

Management reporting should emphasize:

Business Impact

Decision Required

Trend

Ownership

Treatment Status

Avoid

CVSS 9.8

CVE-XXXX

Port 443 exposed

without context.

Translate Technical Risk

Technical:

Privileged accounts do not use MFA.

Executive:

Several privileged accounts rely on password-only
authentication, increasing the likelihood that stolen
credentials could provide administrative access
to critical production systems.

Executive Risk Summary

Risk	Residual Rating	Owner	Treatment	Status
Privileged compromise	Critical	Cloud Owner	Mitigate	Open
Customer data exposure	High	Data Owner	Mitigate	In Progress
SaaS outage	Medium	Service Owner	Accept/Mitigate	Monitoring

Step 26 — Produce the Final Risk Assessment Report

The report should contain:

01 Executive Summary

02 Assessment Scope

03 Business Context

04 Methodology

05 Critical Assets

06 Threat Scenarios

07 Vulnerabilities and Exposures

08 Existing Controls

09 Control Effectiveness

10 Likelihood and Impact

11 Inherent Risk

12 Residual Risk

13 Risk Register

14 Treatment Decisions

15 Remediation Roadmap

16 Risk Acceptance

17 Monitoring Plan

18 Assessment Limitations

Executive Summary Template

Assessment Objective:

Evaluate cybersecurity risks affecting
the assessed environment.

Overall Risk:

[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:

[Funding / acceptance / ownership / treatment]

Risk Assessment Quick Checklist

Scope and Context

Assets

Assets inventoried
Owners identified
Criticality assigned
Sensitive data identified

Threats

Threat actors considered
Threat events documented
Risk scenarios created
Third-party scenarios considered

Vulnerabilities

Technical weaknesses reviewed
Configuration weaknesses reviewed
Process weaknesses reviewed
Governance weaknesses reviewed

Controls

Preventive controls reviewed
Detective controls reviewed
Recovery controls reviewed
Control effectiveness assessed

Risk Analysis

Treatment

Monitoring

Review date defined
KRIs identified
Remediation tracked
Closure validated

Common Risk Assessment Mistakes

Mistake 1 — Calling a Vulnerability a Risk

Missing MFA

is a weakness.

The risk is what could happen because of that weakness.

Mistake 2 — Using Scanner Severity as Business Risk

Technical severity is only one factor.

Mistake 3 — Ignoring Existing Controls

Controls may substantially change residual risk.

Mistake 4 — Treating Risk Scores as Absolute Truth

Scoring models support consistency but still require judgment and evidence.

Mistake 5 — Ignoring Business Context

Risk exists in relation to business objectives and assets.

Mistake 6 — Letting Security Own Every Risk

Appropriate business or system owners should retain risk accountability.

Mistake 7 — Closing Risks Without Validation

Verify remediation effectiveness before closure.

Mistake 8 — Leaving Risk Acceptance Open Forever

Accepted risks should have review dates.

Risk Assessment Decision Framework

For every security issue ask:

What asset is affected?

What threat could occur?

What weakness enables it?

What controls already exist?

How effective are they?

How likely is the scenario?

What is the business impact?

What is the residual risk?

Who owns the decision?

What should happen next?

Runbook Completion Criteria

The risk assessment is complete when:

Professional Outcome

This runbook gives you a repeatable process for moving from:

Technical Observation
       ↓
Threat Scenario
       ↓
Business Impact
       ↓
Inherent Risk
       ↓
Controls
       ↓
Residual Risk
       ↓
Treatment
       ↓
Ownership

A professional risk assessment should not end with:

This is a critical vulnerability.

It should explain:

What could happen,

why it could happen,

how likely it is,

what impact it would create,

which controls already exist,

what risk remains,

who owns the decision,

and what should happen next.

That is the foundation of enterprise cybersecurity risk management.

What’s Next?

➡️ Runbook 04 — Enterprise Security Assessment

In the next runbook, you will combine multiple security domains into one structured enterprise assessment covering:

Governance
   ↓
Assets
   ↓
Identity
   ↓
Network
   ↓
Systems
   ↓
Applications
   ↓
Data
   ↓
Cloud
   ↓
Security Operations
   ↓
Resilience
   ↓
Risk
   ↓
Executive Reporting

The progression is:

Cloud Security Assessment
        ↓
IAM Security Review
        ↓
Risk Assessment
        ↓
Enterprise-Wide Security Assessment