Chapter 8

Risk Assessment & Findings

Learn how to rate risks using structured methodologies, classify audit findings by severity, perform root cause analysis, and recognize the most common vulnerability patterns encountered during cybersecurity audits.

Risk Rating Methodologies

The Purpose of Risk Rating

Risk rating is the process of assigning a severity level to each audit finding based on the potential impact and likelihood of exploitation. Without a consistent risk rating methodology, findings are presented as an undifferentiated list that makes it impossible for management to prioritize remediation resources. A well-applied risk rating framework enables the organization to address the most dangerous vulnerabilities first, allocate budget effectively, and track risk reduction over time. Risk ratings also provide a common language between auditors, IT teams, and executive leadership.

Qualitative Risk Rating

Qualitative risk rating uses descriptive categories rather than numerical values. It is the most common approach in cybersecurity audits because it is intuitive, easy to communicate to non-technical stakeholders, and does not require precise quantitative data that may not be available. The most widely used qualitative approach combines likelihood and impact assessments in a risk matrix.

Low ImpactMedium ImpactHigh ImpactCritical Impact
High LikelihoodMediumHighCriticalCritical
Medium LikelihoodLowMediumHighCritical
Low LikelihoodLowLowMediumHigh

Quantitative and Semi-Quantitative Approaches

Quantitative risk assessment assigns numerical values to likelihood and impact, often expressed in financial terms such as Annualized Loss Expectancy (ALE). While more precise, quantitative methods require reliable data on threat frequency and loss magnitude that is often difficult to obtain for cybersecurity risks. Semi-quantitative approaches use numerical scales (such as 1 to 5 for likelihood and impact) that are multiplied to produce a risk score, combining the structure of quantitative methods with the practicality of qualitative assessment.

  • NIST SP 800-30: Provides a comprehensive risk assessment methodology with detailed guidance on threat identification, vulnerability analysis, likelihood determination, and impact analysis. Uses a five-level scale for both likelihood and impact.
  • CVSS (Common Vulnerability Scoring System): A standardized framework for rating the severity of technical vulnerabilities on a 0 to 10 scale. Widely used for vulnerability management but not designed for broader audit findings.
  • FAIR (Factor Analysis of Information Risk): A quantitative model that breaks risk into measurable components including threat event frequency, vulnerability, and loss magnitude. Provides financially quantified risk estimates.
  • ISO 27005: Provides guidelines for information security risk management aligned with ISO 27001, including risk identification, analysis, evaluation, and treatment options.
  • Custom Organizational Frameworks: Many organizations develop internal risk rating scales tailored to their risk appetite, industry, and regulatory requirements. Auditors should understand and apply the client's framework when one exists.
When an organization has its own risk rating framework, use it. Applying a different framework creates confusion and makes it difficult for the organization to integrate audit findings into their existing risk register. If the organization lacks a framework, recommend adopting one and use a standard methodology such as NIST SP 800-30 for the current engagement.

Likelihood, Impact & Finding Classification

Assessing Likelihood

Likelihood represents the probability that a vulnerability will be exploited by a threat actor within a defined timeframe. Assessing likelihood requires the auditor to consider the threat landscape, the attractiveness of the target, the skill level required to exploit the vulnerability, the existence of known exploits, and the effectiveness of existing compensating controls. Likelihood is not a precise mathematical probability — it is a professional judgment informed by available data and industry knowledge.

LevelDescriptionIndicators
HighExploitation is expected or has already occurred. The vulnerability is actively targeted.Known exploits exist in the wild; vulnerability is internet-facing; no compensating controls; threat actors actively targeting this type of vulnerability
MediumExploitation is possible and reasonably foreseeable given current threat conditions.Exploits are available but require some skill; vulnerability is on internal network; partial compensating controls exist; threat actors occasionally target this type of vulnerability
LowExploitation is theoretically possible but unlikely given current conditions.No known exploits; vulnerability requires physical access or insider knowledge; strong compensating controls exist; threat actors rarely target this type of vulnerability

Assessing Impact

Impact measures the potential consequences if a vulnerability is exploited. Impact assessment should consider multiple dimensions: the confidentiality, integrity, and availability of affected data and systems; the financial cost of a breach; regulatory penalties; reputational damage; and operational disruption. The type of data involved significantly influences impact — a vulnerability affecting a system that stores personally identifiable information (PII) or protected health information (PHI) has a higher impact than one affecting a system with only public data.

LevelDescriptionExamples
CriticalCatastrophic consequences affecting the entire organization, its customers, or regulatory standingBreach of millions of customer records; complete system outage lasting days; regulatory sanctions; existential financial loss
HighSignificant consequences affecting major business functions or a large number of individualsUnauthorized access to sensitive financial or health data; extended outage of a revenue-generating system; material regulatory findings
MediumModerate consequences that are containable and recoverable but require meaningful effortCompromise of internal employee data; partial system outage; breach requiring customer notification for a limited population
LowMinimal consequences with limited scope and easy recoveryAccess to non-sensitive internal data; brief system disruption; minor policy violations with no external impact

Finding Classification

Once likelihood and impact are assessed, the finding is classified using the risk matrix. However, classification also involves determining the finding category and its relationship to compliance requirements. Findings are typically categorized as control deficiencies, significant deficiencies, or material weaknesses. The classification determines how the finding is reported, who it is escalated to, and the expected remediation timeline.

  • Critical: Requires immediate remediation. Represents an imminent threat to the organization or a material compliance violation. Should be escalated to executive leadership and the board. Expected remediation: immediate to 30 days.
  • High: Requires prompt remediation. Represents a significant security risk or compliance gap. Should be reported to senior management. Expected remediation: 30 to 60 days.
  • Medium: Requires planned remediation. Represents a moderate risk that should be addressed within normal operating cycles. Reported to management. Expected remediation: 60 to 90 days.
  • Low: Represents an improvement opportunity or minor observation. Can be addressed during the next review cycle or as resources allow. Expected remediation: 90 to 180 days.
  • Informational: An observation or best-practice recommendation that does not represent a control deficiency. No remediation requirement, but improvement is encouraged.
Be cautious about allowing management to negotiate finding ratings downward. While management input on likelihood and impact is valuable (they understand their environment better than the auditor), the final rating must reflect the auditor's professional judgment. If management disagrees with a rating, document their rationale but maintain the rating you believe the evidence supports.

Root Cause Analysis & Common Vulnerability Patterns

Why Root Cause Analysis Matters

Root cause analysis (RCA) identifies the underlying reason a control failure occurred, not just the symptoms. Without RCA, remediation efforts address the surface-level problem but leave the root cause intact, leading to recurring findings in subsequent audits. For example, if orphaned accounts are found during an audit, the surface-level fix is to disable those specific accounts. But the root cause might be a disconnected HR-to-IT offboarding workflow — and without fixing that workflow, new orphaned accounts will appear continuously. Effective RCA transforms audit findings from one-time fixes into lasting process improvements.

Root Cause Categories

CategoryDescriptionExample
Process GapA required process does not exist or is incompleteNo formal process for revoking access when employees transfer between departments
Process FailureA process exists but is not followed consistentlyChange management policy requires approvals, but 70% of changes bypass the process
Resource ConstraintInsufficient personnel, budget, or tools to implement or maintain controlsOne security analyst responsible for monitoring 5,000 endpoints cannot review all alerts
Knowledge GapPersonnel lack the training or awareness to execute controls properlySystem administrators do not understand CIS benchmark hardening requirements
Technology LimitationCurrent tools or systems do not support the required controlLegacy application does not support multi-factor authentication
Governance FailureLack of oversight, accountability, or management commitmentNo one is assigned responsibility for reviewing access logs; no metrics are reported to leadership

Common Vulnerability Patterns

Experienced auditors recognize recurring vulnerability patterns that appear across organizations regardless of industry or size. Recognizing these patterns accelerates the audit process and helps auditors know where to focus their testing. The following patterns represent the most frequently encountered findings in cybersecurity audits.

  • Excessive Privileges and Access Creep: Users accumulate access over time as they change roles without old access being revoked. Service accounts are granted broad permissions that are never reviewed. Shared accounts make accountability impossible.
  • Patch Management Gaps: Critical patches are not applied within policy-defined timelines. Patch coverage excludes certain system categories like network devices, firmware, or third-party applications. No process exists for emergency patching of zero-day vulnerabilities.
  • Insufficient Logging and Monitoring: Logs are generated but never reviewed. No centralized log management or SIEM. Log retention periods are too short for regulatory requirements or forensic needs. Security events generate alerts that no one investigates.
  • Weak Change Management: Changes are made to production environments without documentation or approval. Emergency changes bypass the process and are never retrospectively reviewed. No separation of duties between change requestors and implementers.
  • Incomplete Backup and Recovery: Backups exist but are never tested through restoration exercises. Backup scope does not cover all critical systems. Recovery time objectives are defined but unvalidated. Backup media is not encrypted or stored offsite.
  • Third-Party Risk Gaps: Vendors with access to sensitive data have not undergone security assessments. No contractual security requirements or right-to-audit clauses. Vendor access is not monitored or reviewed periodically.
When you identify a finding, always ask 'why' at least three times to dig past the symptom to the root cause. Finding: orphaned accounts exist. Why? Because IT was not notified of the termination. Why? Because there is no automated integration between the HR system and Active Directory. Why? Because the project to build the integration was deprioritized due to budget constraints. The root cause is a resource prioritization decision, not a technical oversight.
Track recurring findings from prior audit reports. If the same finding appears in consecutive audits, it indicates that either the remediation was ineffective or the root cause was not addressed. Recurring findings should be escalated in severity because they demonstrate a pattern of management inaction.

Chapter quiz

Risk Assessment & Findings Quiz

7 questions · passing score 70%

Practice scenario

Classifying and Prioritizing Audit Findings

You are finalizing the findings for a cybersecurity audit of Meridian Financial Group, a mid-size investment advisory firm managing $5 billion in client assets. Meridian is regulated by the SEC and must comply with the SEC's cybersecurity disclosure rules and Regulation S-P for safeguarding customer information. You have completed your testing and identified multiple findings. Now you need to classify each finding by severity, perform root cause analysis, and prepare them for the audit report. You are working with the CISO, Robert Kim, who will present the findings to the board of directors.