Risk Identification and Risk Register

Risk is the potential for loss or harm resulting from a threat exploiting a vulnerability. In information security, risk is expressed as the combination of likelihood (how probable the event is) and impact (how severe the damage would be). Understanding risk allows organizations to make informed, cost-effective security decisions rather than trying to eliminate every possible threat.

Risk identification begins with three core elements. An asset is anything of value — servers, databases, intellectual property, or reputation. A threat is any potential event that could harm an asset, such as a ransomware attack or a disgruntled employee. A vulnerability is a weakness that a threat can exploit, such as an unpatched system or weak password policy. Risk exists where threats meet unprotected assets.

Systematic risk identification follows a structured process: first, asset inventory catalogs everything of value; next, threat modeling identifies who might attack and how; then vulnerability assessment finds weaknesses in systems and processes. Finally, analysts map threats to vulnerabilities to determine which assets face real exposure. This process is typically repeated annually or after major changes.

Assigning value to assets drives prioritization. Tangible assets (hardware, software licenses) have clear market values. Intangible assets (brand reputation, customer data) require judgment — regulators may assign a per-record value to PII. The replacement cost method asks what it would cost to recreate the asset; business impact asks what revenue loss results if the asset is unavailable for 1 hour, 1 day, or 1 week.

A risk register is a living document that captures all identified risks in a structured, searchable format. Each entry typically includes: risk description, affected assets, threat source, vulnerability exploited, likelihood rating, impact rating, risk score, current controls, and the assigned risk owner. Risk registers serve as the central reference for governance, audit, and remediation tracking activities.

The likelihood column rates how probable exploitation is (1=Rare to 5=Almost Certain). The impact column rates consequences in terms of financial loss, regulatory penalty, or operational downtime (1=Negligible to 5=Catastrophic). Multiplying these produces a risk score used for prioritization. The residual risk field records remaining risk after controls are applied, ensuring nothing is assumed to reach zero.

Every risk in the register must have a named risk owner — typically a business manager or system owner, not the security team. The risk owner is accountable for ensuring controls are implemented and residual risk stays within acceptable thresholds. The security team advises and monitors but cannot own all risks, as that creates single-point accountability that does not scale across an enterprise.

Several frameworks help structure threat identification. STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) categorizes threats against each system component. PASTA (Process for Attack Simulation and Threat Analysis) is a risk-centric methodology that maps attacker goals. DREAD scores threats by Damage, Reproducibility, Exploitability, Affected users, and Discoverability — though DREAD is less common in modern practice.

Risks cannot be identified without finding vulnerabilities first. Key sources include: vulnerability scanners (Nessus, OpenVAS) that test systems against known CVEs; penetration test reports that validate exploitability; configuration audits that compare settings to CIS benchmarks; and threat intelligence feeds that highlight actively exploited weaknesses. Internal audit reports and self-assessments also surface process-level vulnerabilities missed by technical scans.

Risk registers must account for both internal threats (employees, contractors, misconfigured systems) and external threats (hackers, nation-state actors, supply chain compromises). Internal threats often have higher impact because insiders already have access — a disgruntled employee can exfiltrate data without triggering perimeter controls. Insider threat programs that monitor behavioral anomalies address a risk category that technical controls alone cannot mitigate.

A risk register is not a one-time deliverable — it must be reviewed and updated whenever significant changes occur: new system deployments, organizational restructuring, newly disclosed CVEs, or post-incident findings. Most organizations tie formal risk register reviews to annual security reviews, change management processes, and compliance audits. Stale risk registers create false confidence and may lead to unresourced exposure during rapid infrastructure changes.

Test your understanding of CompTIA Security+ (SY0-701) concepts from this lesson.

In this lesson you learned: risk combines likelihood and impact to prioritize security decisions, risk registers document assets, threats, vulnerabilities, scores, owners, and residual risk, and threat modeling techniques like STRIDE help systematically identify what could go wrong. Next up we explore qualitative versus quantitative risk analysis methods.