Survivability Engineering, Part 1: Risk Assessment

Cyber risk quantification today chases an illusion of precision. Spreadsheets promise clarity with rounded loss numbers and simulated curves, but they rarely survive contact with reality. The problem isn't how we measure risk, since even sound math built on weak data or subjective assumptions still produces a tidy sense of control that costs millions and rarely shapes a real decision.

A better path replaces abstract probability with concrete, evidence-based survival scenarios. Instead of saying the annualized loss is $3.2M, describe how a system could fail, why, and how long it would stay down. That shift turns risk from financial fiction into an engineering discipline focused on real-world resilience for every dollar spent.

Assessing Risk

Forget spreadsheets for a moment. The goal is to understand how a real thing, a system, a product, a workflow, fails under pressure.

Start with something concrete. A system. A product. A workflow. Not "enterprise risk". One real thing.

Start by asking why the system exists. What business function does it support, and who depends on it? If it goes down, something stops, and someone feels it first, whether that's a revenue team missing a transaction, an operations team stalled mid-process, or legal facing exposure. If no one can give you a clear answer, that gap is itself useful information. The system either has low impact, or the people running it don't fully understand it.

From there, think through how an attacker would realistically reach it. Skip the theoretical zero-days and focus on real entry paths: who can log in, what connects to it, whether it's reachable from the internet or only internally, whether a compromised laptop or stolen token could get there. Build a mental attack graph and trace the shortest believable path from an attacker existing to an attacker having control.

Then assume compromise happens. Rather than asking how likely that is, assume someone already has access and ask what they could do. Can they read sensitive data, change transactions, create admin accounts, push code, shut the system down, or pivot further in? Translate that into business terms. If it happens, what breaks and for how long? Are customers locked out, are orders halted, could this trigger a contract breach or a regulatory filing? Push past vague phrases like high impact and state something concrete, even uncomfortable, like "we could not process transactions for three days." That specificity gives leadership and the board what they actually want to know.

Next, look at survivability. How fast would the team notice a real incident, based on current monitoring, not theoretical monitoring? How fast could they contain it by isolating systems, disabling accounts, or cutting connections? How fast could they restore cleanly? This is where most security theater falls apart. Backups may exist but go untested. Logging may be enabled but unreviewed. Access controls may be defined on paper while "temporary" exceptions quietly became permanent. The question isn't whether controls exist, but whether they hold up under real stress.

At this point, you should be able to state plainly: "if this system is compromised in a realistic way, the worst credible damage is X, the likely disruption is Y, and the biggest weakness is Z". That sentence is the risk assessment.

Only then decide what to do. Ask what single change would most reduce the damage or the downtime, what would limit blast radius or shorten recovery, rather than what would improve a maturity score or satisfy a framework. Often the answer is unglamorous; for example tightening privileged access, segmenting a critical dependency, testing restores, or clarifying incident ownership. Make the change, then reassess.

If a dollar figure becomes necessary later, take the downtime identified and multiply it by a rough cost per day, then compare that to the cost of the fix. That gives a financial view worth discussing. Starting there first, before understanding how the system fails and how long it stays broken, only adds false precision.

Risk assessment, done well, is simple.

1. Understand how this thing gets compromised.
2. Understand what really breaks when it does.
3. Understand how long you stay broken.
4. Improve that.

Then repeat.

You can download the simplified step list (PDF)

Go to Part 2.