Risk Assessment Basics

Why Severity Scores Alone Mislead

A critical vulnerability (CVSS 9.8) on an internal-only server with no exposed attack surface is a lower priority than a high vulnerability (CVSS 7.5) on an internet-facing web server that processes credit card data. If you prioritize by severity alone, you waste resources on the wrong problems.

Risk assessment fixes this by combining two dimensions:

Risk = Likelihood × Impact

• Likelihood (also called probability or frequency): How likely is it that this threat will exploit this vulnerability? A vulnerability on an internet-facing server has higher likelihood than one on an isolated internal network.

• Impact (also called consequence or severity): If the threat is exploited, how bad is the outcome? A breach of customer financial data has higher impact than a breach of a public marketing page.

The product of these two gives you a risk score that reflects actual exposure, not just theoretical severity.

Qualitative vs. Quantitative Assessment

Qualitative assessment uses descriptive scales — Low, Medium, High — for both likelihood and impact. This is the most common approach in practice because it is fast, requires no specialized expertise, and is sufficient for most decision-making.

Example qualitative matrix:

Quantitative assessment assigns numeric values — dollar amounts, percentages, or counts. This is more precise but requires data that is often unavailable or unreliable.

Example quantitative calculation:

• Asset value: $2,000,000 (customer database)
• Exposure factor: 40% (40% of the asset's value would be lost in a breach)
• Single Loss Expectancy (SLE): $2,000,000 × 0.40 = $800,000
• Annual Rate of Occurrence (ARO): 0.25 (once every 4 years)
• Annualized Loss Expectancy (ALE): $800,000 × 0.25 = $200,000

The ALE tells you the maximum you should spend on a control to reduce this risk. If a control costs $300,000 per year but the ALE is only $200,000, the control is not cost-effective.

In practice, most organizations use qualitative assessment for the initial triage and quantitative analysis for the most critical assets where the data justifies the effort.

Inherent Risk vs. Residual Risk

Inherent risk is the risk that exists before any controls are applied. It answers: "How exposed would we be if we did nothing?"

Residual risk is the risk that remains after controls are applied. It answers: "How exposed are we given the controls we have in place?"

Both matter:

• Inherent risk tells you the theoretical maximum exposure and helps you understand the importance of the asset.
• Residual risk tells you your actual current exposure and helps you decide whether additional controls are needed.

The gap between inherent and residual risk is the value of your controls. If inherent risk is Critical and residual risk is Medium, your controls have reduced risk by two levels. If inherent risk is Critical and residual risk is still Critical, your controls are ineffective.

The Risk Register

A risk register is the central artifact of risk assessment. It is a living document that tracks every identified risk, its characteristics, and its remediation status. A well-maintained risk register includes:

The risk register is not a compliance artifact — it is a decision-making tool. Its value comes from the conversations it forces: "Is this risk acceptable?" "What would it cost to reduce it?" "Who owns it?"

From Asset Inventory to Remediation Plan

A risk assessment follows a structured process. Skipping steps produces incomplete results that leave critical risks unaddressed.

Step 1: Asset Inventory and Valuation

You cannot assess risk for assets you do not know exist. The first step is a complete inventory:

• Hardware: Servers, workstations, network devices, IoT devices
• Software: Applications, operating systems, libraries, APIs
• Data: Customer records, financial data, intellectual property, credentials
• People: Employees with specialized knowledge, executives, contractors
• Facilities: Data centers, offices, co-location spaces

Each asset is valued — not necessarily in dollars, but in terms of its importance to the organization. A database containing customer PII is more valuable than a test server with no real data.

Step 2: Threat Identification

For each asset, identify the threats that could affect it. Use threat intelligence, historical incident data, and frameworks like STRIDE:

• Natural threats: Flood, fire, earthquake, pandemic
• Human threats: Attacker (external), insider (malicious), user (accidental)
• Technical threats: Hardware failure, software bug, capacity exhaustion

Step 3: Vulnerability Identification

For each threat, identify the vulnerabilities that could be exploited:

• Unpatched software
• Misconfigured firewalls
• Weak authentication
• Lack of encryption
• Insufficient logging

Tools like vulnerability scanners (Nessus, Qualys, OpenVAS) automate this for known vulnerabilities, but they miss business logic flaws, architectural weaknesses, and novel attack vectors.

Step 4: Risk Analysis

For each threat-vulnerability pair, assess likelihood and impact:

Likelihood factors:

• Is the asset exposed to the internet?
• Is there a known exploit available?
• How attractive is the asset to attackers?
• How easy is it to exploit?
• Has it been attacked before?

Impact factors:

• How many users or records are affected?
• Is the data sensitive (PII, financial, health)?
• What is the financial cost of downtime?
• What is the reputational damage?
• Are there regulatory consequences?

Step 5: Risk Evaluation and Prioritization

Compare each risk score against the organization's risk appetite — the level of risk the organization is willing to accept. Risks above the appetite threshold require treatment; risks below it may be accepted.

Step 6: Risk Treatment

For each risk above the appetite threshold, choose a treatment:

• Mitigate: Implement controls to reduce likelihood or impact (patch the vulnerability, add a firewall rule, implement MFA)
• Transfer: Shift the risk to a third party (cyber insurance, outsourcing)
• Avoid: Stop the activity that creates the risk (decommission the vulnerable system)
• Accept: Acknowledge the risk and take no action (document the decision and the rationale)

The choice depends on cost-benefit analysis. A $50,000 control that reduces a $200,000 annualized risk is cost-effective. A $500,000 control for the same risk is not.

Step 7: Monitoring and Review

Risk assessment is not a one-time activity. The threat landscape changes, new vulnerabilities are discovered, and the organization's assets evolve. Review the risk register:

• Continuously: Automated vulnerability scanning feeds new findings into the register
• Monthly: Review new and changed risks
• Quarterly: Full review of all open risks
• Annually: Comprehensive reassessment of the entire risk landscape

Common Pitfalls

• Assessing only technical risks: The biggest risks are often human (insider threat, social engineering) or process (lack of incident response planning).
• Ignoring low-likelihood/high-impact events: A once-in-a-decade flood that destroys your only data center is a real risk. The likelihood is low, but the impact is catastrophic.
• Treating the register as a compliance artifact: If the register does not drive decisions, it is waste. Every entry should have an owner and a treatment plan.
• Failing to update: A risk register that is six months old is worse than no register at all — it gives a false sense of security.