How to Conduct a Security Risk Assessment

Risk assessments without a defined scope are impossible to complete, they expand indefinitely as new systems are discovered. Define scope before starting and enforce it. Scope can be defined by system category (all externally facing systems), by data type (all systems that process regulated customer data), by organizational unit (all corporate IT systems excluding OT), or by compliance requirement (HIPAA-covered components).

Asset inventory is the prerequisite for every subsequent step. You cannot assess risk to assets you do not know you have. Most organizations discover 15 to 30% more assets than they expected during the inventory phase of a thorough assessment. Use network scanning, cloud asset discovery APIs, and active directory enumeration in combination, no single source will provide a complete picture.

For each asset in scope, collect: the business owner (the person accountable for the system's availability and data integrity), the data classification of data the system processes or stores, the network exposure (internet-facing, internal only, isolated), the existing security controls applied to it, and its criticality to business operations. Asset criticality classification, typically a tiered system where Tier 1 assets are those whose failure or compromise would cause material business impact, is the most important input to risk prioritization.

Threat identification asks: for each asset in scope, what threat scenarios could materialize that would cause harm? NIST SP 800-30 provides a comprehensive threat source taxonomy: adversarial (external threat actors, internal threats, trusted third parties), accidental (human error, equipment failure), structural (hardware aging, software bugs), and environmental (natural disasters, utility failures).

For information security risk assessments focused on cyber threats, structure threat scenarios as threat-source, threat-event, and vulnerability triplets. Example: 'Financially motivated external threat actor (source) exploiting an unpatched remote code execution vulnerability (event) via CVE-2026-XXXX in the externally facing application (vulnerability).'

Likelihood scoring is where qualitative risk assessments diverge most from each other. The most common failure mode is assessors using different internal calibration for 'high likelihood', one assessor's High is another's Medium. Before scoring, anchor your likelihood scale to specific probability ranges: Very High = >70% probability of occurrence within 12 months, High = 40-70%, Medium = 10-40%, Low = 1-10%, Very Low = <1%. Using explicit probability ranges produces more consistent results across assessors and between assessment cycles.

For organizations with the analytical maturity to support quantitative risk assessment, the FAIR (Factor Analysis of Information Risk) model provides a structured approach to calculating loss exposure in monetary terms using frequency and magnitude distributions. FAIR is more resource-intensive than qualitative assessment but produces risk outputs that integrate directly into financial decision-making frameworks.

Impact scoring measures the potential harm from a threat scenario materializing. Impact dimensions to evaluate: confidentiality impact (what is the regulatory, competitive, and reputational impact of data exposure?), integrity impact (what is the operational impact of data or system integrity compromise?), and availability impact (what is the business and financial impact of system unavailability, and for how long?).

Avoid the trap of scoring impact purely on the technical dimension. The impact of a database breach is not 'database compromised', it is the specific downstream business consequences: regulatory fine exposure, breach notification cost, customer churn, operational disruption, and litigation risk. Translating technical impact into business impact terms is the step most technical risk assessments skip and the step most important for communicating risk to leadership.

Risk score calculation combines likelihood and impact. The traditional risk matrix (5x5 grid of likelihood versus impact) is widely used and organizationally familiar but produces results that cannot be compared to financial metrics. For organizations that need to prioritize security investments against competing business priorities, risk scores expressed as annualized loss expectancy (ALE = annual rate of occurrence x single loss expectancy) in dollar terms allow direct comparison to investment cost.

Every identified risk requires a treatment decision: accept (acknowledge the risk and document why the cost of mitigation exceeds the risk reduction benefit), mitigate (implement controls to reduce likelihood or impact), transfer (shift financial exposure through cyber insurance or contractual risk transfer), or avoid (eliminate the risk by discontinuing the at-risk activity or system).

Risk treatment decisions should be made by business owners, not security teams. Security teams provide the risk analysis; business owners with budget authority make the treatment decision with full information about the tradeoffs. Risk acceptance decisions above a defined threshold (typically anything rated High or Critical) should require documented sign-off from a named business executive.

Presenting findings to leadership requires translation from technical risk language to business risk language. A finding of 'Externally facing application is running an end-of-life framework with a known critical RCE vulnerability' means nothing to a CFO. 'An unpatched vulnerability in our customer portal creates a material probability of a breach that would expose customer PII, trigger state breach notification requirements, and carry an estimated $2.3 million in response cost and regulatory exposure' is a business risk that a CFO can make a budget decision about.

Limit board and executive presentations to the top five to ten risks by severity. A risk register with 200 items is operationally useful for the security team; it is paralyzing for executive decision-making. Present the risks that most urgently require executive attention and resource allocation, with clear treatment options and associated cost estimates.