"04 Risk Assessment Methodology"

A risk assessment methodology provides a consistent and repeatable process for identifying, analyzing, evaluating, and documenting risks across an organization.

Enterprise Risk Management establishes the overall risk program.

Risk assessment is the practical activity used to determine:

• What could go wrong.

• Why it could happen.

• Which business assets could be affected.

• What controls already exist.

• How serious the risk is.

• Whether additional treatment is required.

• Who should own the risk.

• How the results should be communicated.

For a GRC professional, performing risk assessments is one of the most important practical skills you will develop.

A well-designed assessment converts technical observations, business concerns, vulnerabilities, audit findings, and threat information into structured and actionable business risk decisions.

Learning Objectives

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

• Explain the purpose of an enterprise risk assessment.

• Define risk assessment scope and objectives.

• Identify relevant stakeholders.

• Identify critical business processes, assets, and dependencies.

• Develop meaningful risk scenarios.

• Identify threats and vulnerabilities.

• Assess existing controls.

• Determine inherent risk.

• Evaluate control effectiveness.

• Calculate residual risk.

• Recommend appropriate risk treatment.

• Assign risk and remediation ownership.

• Document risks within a risk register.

• Prepare risk assessment reports.

• Facilitate stakeholder interviews and risk workshops.

• Perform risk assessments using a consistent methodology.

1. What Is a Risk Assessment?

A risk assessment is a structured process used to determine the likelihood and potential impact of events that could affect organizational objectives.

At a high level:

Understand the Business
        │
        ▼
Identify Assets
        │
        ▼
Identify Threats
        │
        ▼
Identify Vulnerabilities
        │
        ▼
Identify Existing Controls
        │
        ▼
Assess Likelihood & Impact
        │
        ▼
Determine Risk
        │
        ▼
Recommend Treatment

The assessment helps leadership decide which risks require attention.

2. Why Organizations Perform Risk Assessments

Organizations perform risk assessments for many reasons.

These may include:

• Enterprise risk management.

• New technology implementations.

• Cloud migrations.

• Regulatory requirements.

• Security certifications.

• Vendor onboarding.

• Application launches.

• Mergers and acquisitions.

• Major architecture changes.

• Audit preparation.

• Compliance programs.

• Cybersecurity improvement initiatives.

Risk assessment enables informed decisions before problems occur.

3. Risk Assessment Is Not Vulnerability Scanning

A vulnerability scan identifies technical weaknesses.

A risk assessment evaluates what those weaknesses mean to the business.

For example:

Vulnerability Scan Finding:

Critical vulnerability
CVSS 9.8

This alone does not explain enterprise risk.

A risk assessment would evaluate:

System:
Internet-facing payment application

Data:
Customer payment information

Threat:
External attacker

Vulnerability:
Critical remote code execution vulnerability

Existing Controls:
WAF
EDR
Network segmentation

Potential Impact:
Payment outage
Data breach
Regulatory exposure
Revenue loss

The technical finding becomes a business risk.

4. Risk Assessment Methodology

A typical methodology may contain the following stages:

1. Plan Assessment
        ↓
2. Define Scope
        ↓
3. Identify Stakeholders
        ↓
4. Understand Business Context
        ↓
5. Identify Assets
        ↓
6. Identify Threats
        ↓
7. Identify Vulnerabilities
        ↓
8. Identify Existing Controls
        ↓
9. Determine Inherent Risk
        ↓
10. Evaluate Control Effectiveness
        ↓
11. Determine Residual Risk
        ↓
12. Recommend Treatment
        ↓
13. Assign Ownership
        ↓
14. Document Findings
        ↓
15. Report Results
        ↓
16. Monitor Remediation

This process should be repeatable across assessments.

5. Step 1 — Plan the Assessment

Before starting, define why the assessment is being performed.

Questions may include:

• What triggered the assessment?

• What decision must be supported?

• What framework or methodology applies?

• Who requested the assessment?

• What is the expected output?

• What is the required completion date?

Example:

Assessment:

Cloud Customer Portal Risk Assessment

Purpose:

Evaluate cybersecurity and compliance risks before production deployment.

Requested By:

Application Steering Committee

Assessment Owner:

Cybersecurity GRC Team

6. Step 2 — Define the Scope

Scope determines what the assessment will cover.

Poor scope can make an assessment either too broad or incomplete.

Scope may include:

• Applications.

• Infrastructure.

• Cloud accounts.

• Business processes.

• Data.

• Locations.

• Vendors.

• Departments.

• Regulations.

• Technology platforms.

Example:

In Scope:

Customer web application
AWS production account
Customer database
Authentication service
Payment integration

Out of Scope:

Internal HR systems
Development sandbox
Corporate laptops

Clearly defining scope prevents confusion later.

7. Scope Questions

Useful scoping questions include:

• Which business service is being assessed?

• Which applications support the service?

• Which cloud environments are involved?

• What information is processed?

• Which vendors are involved?

• Which locations are involved?

• Which regulations apply?

• What timeframe does the assessment cover?

The scope should be formally documented.

8. Step 3 — Identify Stakeholders

Risk assessments require information from multiple teams.

Common stakeholders include:

• Business owners.

• Application owners.

• System owners.

• Security teams.

• Cloud teams.

• Network teams.

• GRC.

• Legal.

• Privacy.

• Compliance.

• Procurement.

• Internal Audit.

• Vendor management.

Each stakeholder provides different information.

9. Stakeholder Example

For a payment application:

Stakeholder	Information Provided
Business Owner	Business impact
Application Team	Application architecture
Cloud Team	Cloud controls
Security Team	Security findings
GRC	Risk methodology
Compliance	PCI DSS requirements
Privacy	Customer data requirements
Vendor Team	Third-party dependencies

Risk assessment is therefore collaborative.

10. Step 4 — Understand Business Context

Before identifying technical risks, understand the business process.

Questions should include:

• What does the business service do?

• Who uses it?

• What happens if it becomes unavailable?

• Does it generate revenue?

• Does it process sensitive information?

• Are customers dependent on it?

• Are regulatory obligations involved?

Without business context, impact ratings become unreliable.

11. Example Business Context

Business Service:

Online Payment Platform

Purpose:

Processes customer transactions.

Users:

Approximately 200,000 customers.

Availability Requirement:

24×7.

Data:

Customer identity information
Payment information
Transaction records

Regulation:

PCI DSS
Data protection requirements

This information becomes the foundation of the assessment.

12. Step 5 — Identify Critical Assets

An asset is anything valuable to the organization.

Examples include:

Information Assets

• Customer records.

• Payment information.

• Intellectual property.

• Employee data.

Technology Assets

• Servers.

• Databases.

• Applications.

• Cloud services.

• Network devices.

Business Assets

• Revenue-generating processes.

• Brand reputation.

• Customer relationships.

Human Assets

• Employees.

• Administrators.

• Specialized personnel.

13. Asset Inventory Example

Asset ID	Asset	Owner	Criticality
A-001	Payment Application	Digital Services	Critical
A-002	Customer Database	Data Team	Critical
A-003	IAM Platform	IAM Team	High
A-004	Web Application Firewall	Security	High
A-005	Logging Platform	SOC	High

Asset ownership is important because risks ultimately affect assets.

14. Asset Criticality

Organizations may classify assets according to business importance.

Example:

Critical

Failure could significantly impact enterprise operations.

High

Failure could significantly impact an important business function.

Medium

Failure would create limited operational disruption.

Low

Failure would have minimal enterprise impact.

Critical assets typically require stronger controls.

15. Information Classification

Data classification also influences risk.

Typical classifications include:

Public
   ↓
Internal
   ↓
Confidential
   ↓
Restricted

The more sensitive the information, the greater the potential impact of unauthorized disclosure.

16. Identify Asset Dependencies

Assets rarely operate independently.

For example:

Customer Portal
       │
       ├── IAM Platform
       │
       ├── API Gateway
       │
       ├── Database
       │
       ├── Cloud Infrastructure
       │
       └── Payment Provider

Failure of one dependency may affect the entire business service.

Dependency analysis helps identify hidden risk.

17. Step 6 — Identify Threats

A threat is something capable of causing harm.

Threats may be intentional or accidental.

External Threats

Examples:

• Cybercriminals.

• Nation-state attackers.

• Hacktivists.

• Competitors.

Internal Threats

Examples:

• Malicious insiders.

• Negligent employees.

• Privileged users.

Environmental Threats

Examples:

• Flood.

• Fire.

• Power outage.

• Natural disasters.

Technology Threats

Examples:

• Hardware failure.

• Cloud outages.

• Software defects.

18. Threat Sources

A useful threat model may include:

External Attacker

Insider

Third Party

Malware

Human Error

Technology Failure

Environmental Event

Not every risk requires a malicious attacker.

19. Threat Intelligence

Threat intelligence can improve risk assessments.

Information may include:

• Active ransomware groups.

• Industry attack trends.

• Exploited vulnerabilities.

• Phishing campaigns.

• Cloud attacks.

• Supply-chain attacks.

Threat intelligence helps determine whether a threat is realistic.

20. Step 7 — Identify Vulnerabilities

A vulnerability is a weakness that may allow a threat to cause harm.

Examples include:

• Weak passwords.

• Missing patches.

• Excessive privileges.

• Insecure configurations.

• Poor network segmentation.

• Missing encryption.

• Weak security monitoring.

• Inadequate procedures.

• Untrained employees.

Vulnerabilities may be technical or procedural.

21. Sources of Vulnerability Information

Useful evidence may include:

• Vulnerability scans.

• Penetration tests.

• Audit findings.

• Cloud security assessments.

• Configuration reviews.

• Security incident reports.

• Policy reviews.

• Access reviews.

• Architecture assessments.

Risk assessments should be evidence driven wherever possible.

22. Step 8 — Develop Risk Scenarios

A strong risk assessment does not simply list vulnerabilities.

Instead, vulnerabilities should be translated into realistic risk scenarios.

A useful structure is:

Threat
   +
Vulnerability
   +
Asset
   +
Event
   +
Business Impact

Example:

Threat:

External attacker

Vulnerability:

Privileged accounts do not enforce MFA

Asset:

Cloud production environment

Event:

Privileged account compromised

Impact:

Unauthorized production access
Customer information exposure
Service disruption

23. Writing Strong Risk Statements

A practical format is:

There is a risk that [threat/event] may exploit [vulnerability], resulting in [business impact].

Example:

There is a risk that an external attacker could compromise privileged cloud accounts because MFA is not consistently enforced, resulting in unauthorized access to production resources, customer information exposure, and service disruption.

This statement clearly communicates:

• What could happen.

• Why.

• What the consequence could be.

24. Weak vs Strong Risk Statements

Weak:

MFA is missing.

Better:

Privileged accounts could be compromised because MFA is not enforced.

Strong:

An external attacker could compromise privileged cloud accounts because MFA is not enforced, potentially resulting in unauthorized production access, customer data exposure, and disruption of critical business services.

GRC professionals should learn to write risks at the business level.

25. Step 9 — Identify Existing Controls

Before scoring risk, identify controls already protecting the environment.

Examples include:

• MFA.

• Firewalls.

• Encryption.

• Endpoint security.

• Backups.

• Security monitoring.

• Access reviews.

• Policies.

• Training.

• Segmentation.

Existing controls influence residual risk.

26. Control Categories

Controls may be:

Preventive

Attempt to stop an incident.

Examples:

• MFA.

• Firewall.

• Access restrictions.

Detective

Identify an incident.

Examples:

• SIEM.

• IDS.

• Audit logging.

Corrective

Reduce impact or support recovery.

Examples:

• Backups.

• Incident response.

• Account reset.

27. Administrative, Technical, and Physical Controls

Another classification is:

Administrative

Policies
Procedures
Training

Technical

MFA
Encryption
Firewalls

Physical

Badge systems
CCTV
Security guards

Assessments may consider controls from all three areas.

28. Step 10 — Determine Inherent Risk

Inherent risk is the risk before existing controls are considered.

For example:

Scenario:

Privileged cloud account compromise

Likelihood:
4

Impact:
5

Inherent Risk:
20 — Critical

This represents natural exposure.

29. Assessing Likelihood

Likelihood asks:

How probable is this risk event?

Factors may include:

• Threat capability.

• Threat motivation.

• Attack frequency.

• Exposure.

• Ease of exploitation.

• Previous incidents.

• Industry trends.

Example scale:

Score	Likelihood	Description
1	Rare	Highly unlikely
2	Unlikely	Could occur
3	Possible	Reasonable possibility
4	Likely	Expected
5	Almost Certain	Highly expected

30. Assessing Impact

Impact asks:

What would happen to the organization if the event occurred?

Consider:

• Financial loss.

• Operational disruption.

• Legal impact.

• Regulatory penalties.

• Customer harm.

• Reputation.

• Safety.

Example:

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

31. Impact Should Be Business Based

Avoid scoring impact based only on technical severity.

For example:

System:
Development test server

Vulnerability:
Critical CVSS score

Sensitive Data:
None

Internet Exposure:
None

Business Dependency:
Low

The technical severity may be high.

The enterprise impact may still be lower.

Risk assessment requires business context.

32. Risk Calculation

A simple methodology may use:

Risk = Likelihood × Impact

Example:

Likelihood:
4

Impact:
5

Risk:
20

An organization might classify this as:

Critical

33. Risk Rating Scale

Example:

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

The organization’s official methodology should define its own thresholds.

34. Step 11 — Evaluate Control Effectiveness

Existing controls should be assessed before residual risk is determined.

A control may be:

Effective

Partially Effective

Ineffective

Not Implemented

Assessment should examine:

• Design.

• Implementation.

• Coverage.

• Consistency.

• Monitoring.

• Evidence.

35. Control Design Effectiveness

Ask:

Is this control appropriately designed to address the risk?

Example:

Risk:

Privileged Account Compromise

Control:

Annual Security Awareness Training

Training may help generally, but it is not a sufficient primary control for privileged authentication.

MFA and PAM would be more directly relevant.

36. Control Operating Effectiveness

A control may be well designed but poorly implemented.

Example:

Control Requirement:

MFA for all administrators

Observed Implementation:

MFA enabled for 80% of administrator accounts

Assessment:

Partially Effective

This affects residual risk.

37. Evidence of Control Effectiveness

Possible evidence includes:

• Screenshots.

• System reports.

• IAM exports.

• Firewall rules.

• SIEM logs.

• Vulnerability scan results.

• Policy documents.

• Access review records.

• Training reports.

• Backup reports.

Evidence should demonstrate that the control actually operates.

38. Step 12 — Determine Residual Risk

Residual risk is the risk after existing controls are considered.

Example:

Inherent Risk:
Critical

Controls:

MFA
Conditional Access
SIEM Monitoring

Control Effectiveness:
Partially Effective

Residual Risk:
High

Residual risk is what management must decide whether to treat or accept.

39. Residual Risk Decision

Once residual risk is determined, compare it with organizational risk appetite.

Residual Risk
      │
      ▼
Compare With Risk Appetite
      │
      ├── Within Appetite → Accept / Monitor
      │
      └── Above Appetite → Treat / Escalate

This connects assessment activity with governance.

40. Step 13 — Recommend Risk Treatment

Risk treatment generally follows four options:

Mitigate

Avoid

Transfer

Accept

The recommendation should be proportionate to the risk.

41. Mitigation Example

Risk:

Cloud administrator accounts could be compromised.

Recommended actions:

1. Enforce MFA.

2. Implement privileged access management.

3. Remove standing administrator access.

4. Configure conditional access.

5. Monitor privileged activities.

Treatment should address the root cause.

42. Avoidance Example

Risk:

Unsupported application creates unacceptable security exposure.

Treatment:

Decommission the application.

The underlying risky activity is removed.

43. Transfer Example

Risk:

Financial consequences of cyber incidents.

Possible treatment:

Cyber insurance.

However, responsibility cannot always be fully transferred.

44. Acceptance Example

Risk:

Legacy system cannot immediately support MFA.

Possible decision:

Accept temporarily
+
Implement compensating controls
+
Establish remediation deadline

Acceptance should be formally approved.

45. Step 14 — Assign Ownership

Every risk should have a clear owner.

Example:

Risk:

Payment platform service outage

Risk Owner:

Head of Digital Payments

The risk owner should have authority to make decisions about the affected business area.

46. Risk Owner vs Remediation Owner

These may be different people.

Example:

Risk Owner:

Director of Digital Payments

Remediation Owner:

Cloud Platform Manager

The risk owner remains accountable for managing the risk.

The remediation owner performs the corrective work.

47. Assigning Treatment Actions

Each action should include:

Action

Owner

Target Date

Status

Evidence

Example:

Action	Owner	Target	Status
Enable MFA	IAM Team	15 Sep	In Progress
Reduce privileges	Cloud Team	30 Sep	Open
Deploy PAM	Security	31 Oct	Planned

This enables accountability.

48. Step 15 — Document the Risk

Risks should normally be documented within a risk register.

Typical fields include:

Risk ID

Risk Title

Risk Description

Business Process

Asset

Threat

Vulnerability

Likelihood

Impact

Inherent Risk

Existing Controls

Control Effectiveness

Residual Risk

Treatment

Risk Owner

Action Owner

Target Date

Status

49. Example Risk Register Entry

Risk ID:

R-024

Risk Title:

Privileged Cloud Account Compromise

Risk Description:

An external attacker could compromise privileged AWS accounts because MFA and privileged access controls are inconsistently implemented, potentially resulting in unauthorized production access, customer data exposure, and disruption of critical services.

Business Service:

Customer Platform

Likelihood:

4 — Likely

Impact:

5 — Severe

Inherent Risk:

20 — Critical

Existing Controls:

CloudTrail
IAM policies
Security monitoring

Control Effectiveness:

Partially Effective

Residual Risk:

High

Treatment:

Enforce MFA
Implement PAM
Remove standing administrator access

Risk Owner:

Director of Cloud Platforms

Target:

31 October 2026

50. Step 16 — Prepare the Risk Assessment Report

The final assessment should summarize results for relevant stakeholders.

A typical report may contain:

1. Executive Summary

2. Assessment Objective

3. Scope

4. Methodology

5. Systems / Processes Assessed

6. Key Risk Findings

7. Risk Ratings

8. Existing Controls

9. Recommended Treatments

10. Risk Owners

11. Remediation Actions

12. Conclusion

Technical detail can be included in supporting sections where required.

51. Executive Summary

Leadership should not have to read dozens of pages to understand the major concerns.

Example:

The assessment identified eight risks across the customer payment platform. Two were rated Critical, three High, two Medium, and one Low. The primary concerns relate to privileged access management and insufficient disaster recovery capability. Immediate remediation is recommended for the two Critical risks.

This provides decision-ready information.

52. Risk Summary Table

An executive summary may include:

ID	Risk	Rating	Owner	Status
R-001	Privileged account compromise	Critical	Cloud Director	Open
R-002	Backup recovery failure	Critical	IT Director	Open
R-003	Vendor compromise	High	Procurement	Treatment
R-004	Weak logging	High	SOC	Treatment

This helps prioritize attention.

53. Risk Heat Map

Risk assessment reports often include a heat map.

Conceptually:

Impact
  ▲
5 │                R1 R2
4 │          R3 R4
3 │      R5
2 │   R6
1 │
  └────────────────────────►
    1   2   3   4   5

        Likelihood

Heat maps show the concentration of enterprise risk.

54. Risk Assessment Interviews

Interviews are an important information-gathering technique.

A GRC professional should ask open-ended questions.

Examples:

• What does this system support?

• What happens if the system becomes unavailable?

• What sensitive data does it process?

• Who has administrative access?

• How is access reviewed?

• What security incidents have occurred?

• Which third parties are involved?

• What controls are currently implemented?

• What concerns keep you awake at night?

The objective is to understand the environment, not to interrogate the stakeholder.

55. Interview Preparation

Before an interview:

• Review available documentation.

• Understand the business process.

• Identify known findings.

• Prepare questions.

• Know the assessment scope.

• Identify required evidence.

Good preparation makes interviews much more productive.

56. Risk Assessment Workshop

For larger assessments, organizations may conduct workshops.

Participants might include:

Business Owner
Security
GRC
Cloud
Application Team
Legal
Compliance
Privacy

A workshop can identify and score several risks collaboratively.

57. Example Workshop Flow

Introduce Scope
      │
      ▼
Review Business Service
      │
      ▼
Identify Assets
      │
      ▼
Identify Threat Scenarios
      │
      ▼
Discuss Existing Controls
      │
      ▼
Score Likelihood
      │
      ▼
Score Impact
      │
      ▼
Agree Risk Rating
      │
      ▼
Assign Owner & Actions

Collaborative scoring can improve stakeholder ownership.

58. Avoiding Group Bias

Risk workshops can become influenced by personalities.

Possible problems include:

• Senior leaders dominating ratings.

• Security teams rating everything Critical.

• Business teams minimizing risk.

• Recent incidents creating exaggerated ratings.

GRC facilitators should use documented scoring criteria.

59. Documenting Assumptions

Assessments sometimes require assumptions.

Example:

Assumption:

Production database contains approximately 500,000 customer records.

Evidence:

Application owner interview.

Validation Required:

Database team confirmation.

Assumptions should be recorded rather than silently treated as facts.

60. Documenting Evidence

A well-supported assessment may reference:

Evidence ID:
EV-014

Evidence:
IAM privileged account report

Source:
IAM Team

Date Reviewed:
25 August 2026

Supports:
Risk R-024

This helps with auditability.

61. Handling Missing Evidence

Sometimes stakeholders cannot provide evidence.

Do not automatically assume a control is effective.

Example:

Control Claimed:

Quarterly privileged access review

Evidence Requested:

Latest review report

Evidence Available:

None

Assessment conclusion may be:

Control effectiveness cannot be confirmed.

This is more defensible than making assumptions.

62. Risk Assessment Approaches

Organizations may use different approaches.

Asset-Based Assessment

Starts with critical assets.

Asset
   ↓
Threat
   ↓
Vulnerability
   ↓
Risk

Threat-Based Assessment

Starts with major threat scenarios.

Ransomware
   ↓
Affected Assets
   ↓
Weaknesses
   ↓
Business Impact

Process-Based Assessment

Starts with business processes.

Payment Processing
   ↓
Dependencies
   ↓
Failure Scenarios
   ↓
Risk

Control-Based Assessment

Starts with expected controls.

Required Control
   ↓
Existing Implementation
   ↓
Control Gap
   ↓
Risk

Organizations may combine approaches.

63. Project Risk Assessments

Risk assessments can be integrated into project lifecycles.

Example:

Project Idea
     │
     ▼
Architecture Design
     │
     ▼
Security Risk Assessment
     │
     ▼
Security Requirements
     │
     ▼
Implementation
     │
     ▼
Pre-Go-Live Review

This helps identify problems before production.

64. Cloud Risk Assessment

Cloud assessments may examine:

• IAM.

• Network exposure.

• Encryption.

• Logging.

• Data storage.

• Backup.

• Resilience.

• Cloud configurations.

• Security monitoring.

• Shared responsibility.

Example:

AWS Account
    │
    ├── IAM
    ├── VPC
    ├── S3
    ├── EC2
    ├── RDS
    └── CloudTrail

Each component may contribute to enterprise risk.

65. Third-Party Risk Assessment

Vendor assessments may consider:

• Data access.

• Criticality.

• Certifications.

• Security controls.

• Incident history.

• Privacy.

• Business continuity.

• Subcontractors.

• Geographic processing locations.

Higher-risk vendors require deeper assessment.

66. Compliance Risk Assessment

Compliance-driven assessments may identify gaps against:

• PCI DSS.

• ISO/IEC 27001.

• SOC 2.

• NIST.

• Privacy requirements.

• Contractual obligations.

However:

A compliance gap should still be translated into business risk.

Do not treat compliance as a checkbox alone.

67. Risk Assessment Frequency

Assessments may occur:

• Annually.

• Quarterly.

• Before major projects.

• After significant changes.

• After incidents.

• When regulations change.

• When new threats emerge.

High-risk environments may require more frequent review.

68. Trigger-Based Reassessment

Some events should automatically trigger reassessment.

Examples:

Major Architecture Change

New Vendor

Data Classification Change

Security Incident

Cloud Migration

New Regulation

Significant Vulnerability

Risk assessments should reflect the current environment.

69. Common Risk Assessment Mistakes

Common mistakes include:

• Starting without clear scope.

• Treating vulnerabilities as complete risk statements.

• Ignoring business impact.

• Scoring without defined criteria.

• Assuming controls work without evidence.

• Failing to identify risk owners.

• Making every risk High or Critical.

• Creating remediation actions without due dates.

• Never reviewing risks again.

• Focusing exclusively on compliance requirements.

A good methodology prevents many of these problems.

70. Quality Review

Before finalizing an assessment, perform a quality review.

Verify:

• Scope is clear.

• Risks are business focused.

• Likelihood is justified.

• Impact is justified.

• Controls are documented.

• Evidence is available.

• Residual risk is reasonable.

• Owners are assigned.

• Treatment plans are actionable.

• Dates are defined.

Peer review can improve consistency.

71. Practical Risk Assessment Scenario

Imagine a company launching a new cloud-hosted customer portal.

During assessment, you discover:

Customer Data:
Sensitive

Platform:
Cloud-hosted

Authentication:
Username and password

MFA:
Not enabled

Administrative Access:
Internet accessible

Logging:
Enabled

SIEM:
Integrated

You now need to develop the risk.

72. Step-by-Step Risk Development

Asset

Customer portal and customer information.

Threat

External attacker.

Vulnerability

MFA not enforced for privileged accounts.

Risk Event

Administrator account compromise.

Business Impact

• Unauthorized application access.

• Customer data exposure.

• Service disruption.

• Regulatory impact.

Likelihood

4 — Likely.

Impact

5 — Severe.

Inherent Risk

4 × 5 = 20

Critical

73. Existing Controls

Existing controls include:

• Password authentication.

• SIEM monitoring.

• Audit logging.

• Network filtering.

However, these do not sufficiently prevent credential compromise.

Control effectiveness:

Partially Effective

74. Residual Risk

After evaluating existing controls:

Residual Risk:

High

This remains above organizational tolerance.

75. Treatment Plan

Recommended treatment:

1. Enforce MFA for all privileged accounts.

2. Restrict administrative access.

3. Implement privileged access management.

4. Introduce just-in-time access.

5. Monitor privileged sessions.

6. Perform quarterly access reviews.

76. Ownership

Risk Owner:

Director of Digital Services

Control Owners:

IAM Team
Cloud Security Team

Target Remediation:

30 days

The risk can now be formally tracked.

77. Example Final Risk Statement

An external attacker could compromise privileged customer portal accounts because multi-factor authentication and privileged access restrictions are insufficient, potentially resulting in unauthorized production access, customer data exposure, service disruption, and regulatory consequences.

This is clear, business focused, and actionable.

78. GRC Analyst Assessment Checklist

For every assessment, verify:

Scope defined?

Stakeholders identified?

Business process understood?

Assets identified?

Threats identified?

Vulnerabilities identified?

Risk scenarios written?

Existing controls reviewed?

Evidence collected?

Likelihood scored?

Impact scored?

Inherent risk calculated?

Control effectiveness evaluated?

Residual risk determined?

Treatment documented?

Risk owner assigned?

Target date defined?

Results reported?

79. Risk Assessment Deliverables

Typical deliverables may include:

• Risk Assessment Plan.

• Scope Document.

• Interview Notes.

• Asset Inventory.

• Risk Register.

• Control Assessment.

• Evidence Register.

• Risk Heat Map.

• Risk Treatment Plan.

• Executive Summary.

• Final Risk Assessment Report.

These artifacts provide traceability.

80. Risk Assessment Methodology Template

A reusable methodology may look like:

Assessment Name:

Business Owner:

Assessment Owner:

Purpose:

Scope:

Systems:

Data:

Regulatory Requirements:

Stakeholders:

Assets:

Threats:

Vulnerabilities:

Existing Controls:

Inherent Risk:

Control Effectiveness:

Residual Risk:

Treatment:

Risk Owner:

Action Owner:

Target Date:

Status:

Evidence:

Using a standard template improves consistency.

81. The GRC Professional Mindset

When performing an assessment, continuously ask:

What are we protecting?

Why is it important?

What could go wrong?

Who or what could cause it?

What weakness could enable it?

What would happen to the business?

How likely is it?

What protections already exist?

Can we prove those protections work?

What risk remains?

Is that risk acceptable?

What should be done?

Who owns the decision?

When will we review it again?

This mindset turns risk assessment from paperwork into effective enterprise decision support.

Key Takeaways

• Risk assessment is the practical process used to identify and evaluate enterprise risk.

• Every assessment should begin with clearly defined objectives and scope.

• Understanding business context is essential before assigning risk ratings.

• Assets, threats, vulnerabilities, controls, likelihood, and impact are core assessment components.

• Strong risk statements describe the event, cause, and business consequence.

• Technical vulnerabilities should be translated into business risks.

• Inherent risk represents exposure before controls.

• Control effectiveness must be evaluated using evidence.

• Residual risk represents exposure after controls.

• Risks above appetite require treatment or escalation.

• Every significant risk should have an owner.

• Treatment actions require owners and target dates.

• Risk assessments should produce clear, decision-ready reports.

• Assessments should be repeated when technology, threats, business conditions, or regulatory requirements change.

Knowledge Check

Before continuing, make sure you can answer these questions:

1. What is the purpose of a risk assessment?

2. Why should assessment scope be defined before work begins?

3. What is the difference between an asset, threat, and vulnerability?

4. How do you construct a strong risk statement?

5. Why is business context important?

6. What is inherent risk?

7. What is control effectiveness?

8. What evidence can be used to validate controls?

9. What is residual risk?

10. How should residual risk be compared with risk appetite?

11. What are the four major risk treatment options?

12. What is the difference between a risk owner and remediation owner?

13. What should a risk assessment report contain?

14. Why should assumptions be documented?

15. When should an existing risk assessment be reviewed again?

What’s Next?

➡️ Next: 05 — Policies, Standards & Procedures

In the next lesson, you will move from assessing enterprise risk into establishing the governance documentation used to control that risk.

You will learn how organizations design and manage policies, standards, procedures, guidelines, baselines, control requirements, policy exceptions, ownership, approvals, versioning, review cycles, and document governance.

You will also learn how to translate risk and regulatory requirements into practical security rules that technology and business teams can consistently implement across the enterprise.