Every system in your inventory has an "Attackability"(TM) score, whether anyone has measured it or not. Start from that premise and the whole vulnerability management program looks different. Reachability, susceptibility, and damage were never separate concerns bolted together for convenience. They are the same question asked from three angles: how likely is someone to reach this thing, how easily can they break it once they do, and how much can it take before it stops functioning the way the business needs it to.

The Attackability Index takes those three checks and adds a fourth, recovery, then rolls all four into a single, entirely unscientific number from zero to a hundred. Except the number is always a hundred, because everything is attackable, and that is the entire point of naming it this way. These four numbers that make the Attackability Index do not exist in a spreadsheet anywhere, and that is deliberate. The index is a thinking tool, not a metric to report to a board, and its purpose is forcing a security team to hold all four questions in their head at once instead of fixating on the one that happens to be easiest to measure that quarter.

Let's define then Attackability:

"Attackability: the condition of every system, regardless of its reachability, susceptibility, or damage profile, being attacked, exploited, or bypassed eventually. It assumes compromise as the baseline rather than the exception, which means recovery is the one input that decides how much that compromise actually costs."

Most vulnerability management programs stop at the first two. They chase reachability and susceptibility hard, sometimes damage too, and treat recovery as an afterthought that lives in a disaster recovery (DR) document nobody has opened since it was written, unless you had a breach and then you discovered that the DR plan didn't really work out. A high "Attackability score" (always 100) on a system with fast, tested recovery is a very different problem than the same score on a system where nobody remembers the last time a restore actually worked. The score, treated this way, forces the issue into the open instead of letting resilience and recovery hide behind a single severity label.

The four inputs behind this score are not 100% precise, but they are far more accurate than calculating likelihood, an estimate at best, or relaying on vulnerability counts, which shift and grow week to week. Resilience and recovery are both partly guesswork until something actually tests them, and recovery time only becomes real once someone has timed a restore with a stopwatch, which is exactly the exercise this whole series keeps pointing back to. The score itself stays an internal running joke, always a hundred, because it was never the deliverable. The habit of asking all four questions about every consequential system, on a standing cadence rather than once during an audit, is the actual work. The trademark sign is there to make the concept memorable enough that a team actually keeps asking.

Everything is attackable, given enough time and motivation, so the real differentiator between organizations is not whether an attacker gets in, but rather how fast a system gets found, how little it gives up once compromised, and how quickly it comes back to a state the business can trust. Vulnerability management should be the thing that shrinks the exposure and the impact side of the equation. Survivability engineering continues the work by making sure recovery is never the number nobody bothered to measure.

Remember: "what is your attackability score from 0-100?" "Yes".