In the previous post we used a Data Flow Diagram to visualize how data moves through an environment and where threats might interact with it. That visualization is a starting point. The next step is quantifying what those interactions actually mean — and that’s where risk comes in.
Risk is often treated as something vague: a feeling, a concern, a checkbox on a compliance form. But it has a structure. Understanding that structure is what allows you to prioritize, allocate resources appropriately, and make security decisions that can be explained and defended.
The Risk Formula
A threat with no vulnerability to exploit presents no risk. A vulnerability with no threat actor to exploit it presents no risk. And a threat exploiting a vulnerability that has no meaningful impact presents no risk worth acting on. All three factors have to be present and significant for something to warrant serious attention.
More precisely: a risk is anything that has significant exposure to threats or weaknesses that would get in the way of organizational objectives. That framing matters because it ties risk directly to what the organization is trying to accomplish, not just to abstract security concerns.
Threats
- Natural — floods, fires, earthquakes, power outages
- Technical — software failures, hardware faults, network outages
- Physical — theft, vandalism, unauthorized access to facilities
- People — malicious insiders, external attackers, negligent users
Vulnerabilities
- Systems — unpatched software, misconfigured services, weak authentication
- Procedures — missing or inconsistent processes that create gaps
- Processes — workflows that bypass security controls or create blind spots
- People — insufficient training, social engineering susceptibility, access sprawl
Impact
- Confidentiality — unauthorized disclosure of sensitive data
- Integrity — corruption or unauthorized modification of data
- Availability — disruption to systems or services
- Non-repudiation — loss of audit trail or attribution capability
- Non-compliance — regulatory violations and associated penalties
- Legal — liability exposure from breaches or contractual failures
- Privacy — harm to individuals whose data is compromised
The impact column is particularly important because it connects risk directly to consequences the organization and its stakeholders actually care about. A technical vulnerability that could only affect availability of a non-critical system is a different conversation than one that could expose patient records and trigger HIPAA penalties. The formula is the same — the variables are different.
Responding to Risk
Once a risk is identified and assessed, the organization has to decide what to do about it. There are four responses, and the important thing to understand is that they’re not mutually exclusive. In practice, organizations use all four and accept whatever residual risk remains after applying them.
Avoid
Eliminate the activity or condition that creates the risk entirely. If a business process creates unacceptable exposure, stop doing it. Not always possible, but when it is, it’s the most effective response.
Transfer
Shift the financial or operational consequence of the risk to a third party. Cyber insurance is the most common example. The risk still exists — you’ve just changed who bears the cost if it materializes.
Mitigate
Reduce the likelihood or impact of the risk through controls. This is where most security work lives — patching vulnerabilities, implementing MFA, segmenting networks. Mitigation reduces risk but rarely eliminates it.
Accept
Acknowledge the risk and decide not to act on it, typically because the cost of mitigation exceeds the expected impact. Acceptance should be a documented, conscious decision — not a default.
After applying any combination of responses, some risk remains. That’s residual risk, and it’s inevitable. The goal isn’t zero risk — it’s risk at a level the organization has consciously decided is acceptable given its tolerance and the cost of further reduction. That decision should be made by the governance committee, not the security team alone.
Risk in Practice
Risk assessment isn’t a one-time exercise. Threats evolve, vulnerabilities are discovered, and the impact of a given event changes as the organization changes. A risk that was acceptable last year may not be acceptable today if the organization has taken on new regulatory obligations, expanded into new markets, or changed how it stores and processes data.
The governance structure covered in the previous post is what makes ongoing risk management possible. Without a committee that owns risk tolerance and reviews it regularly, risk decisions get made informally, inconsistently, and often by people who don’t have the full organizational picture. With it, risk is managed as a continuous organizational function rather than a periodic audit exercise.
Conscious, documented risk acceptance is a legitimate and often appropriate response. The problem is undocumented acceptance, where risk is ignored rather than evaluated and accepted with full awareness of the consequences.
With risk understood and response strategies in place, the next question is what mechanisms you deploy to actually address it. That’s the domain of controls — and we’ll cover those in the next post.
