A confirmed, reachable vulnerability still needs one more answer before it becomes a ticket with a real priority attached. What does exploitation actually cost, measured through the sensitivity of the data involved, the privilege level the affected system runs under, and how long that system takes to come back online if it needs rebuilding. This part exists to answer that question in seconds rather than through a fresh evaluation every time a finding shows up.

Build this at the same time the consequence map itself gets built, not after. Data classification comes from whoever already owns data governance inside the organization, recorded against each system during onboarding instead of negotiated later under pressure once an incident is already underway. Runtime privilege comes from the same identity and access data already pulled for the reachability work, since a system's permission scope is as much a part of its exposure as its network position. Recovery time comes from an actual restoration exercise, not an estimate written down once and never revisited, run against every existential and high recoverable system on a fixed schedule, quarterly at minimum for the systems the business cannot afford to lose, with the measured result replacing whatever assumption sat there before.

Once those three values live on the asset record, a new finding that has already cleared reachability and susceptibility inherits its damage score the moment it lands, with no meeting required to produce it. The only decision left for a person is whether the specific mechanics of that particular finding change what the tier already implies, and that decision belongs to a senior security reviewer for anything touching an existential system, with the business owner (a SVP or above) signing off on any exception, given a date to expire rather than left open with no end in sight.

The friction in this part looks different from the friction in the previous two. It usually comes from getting a data owner or a business unit leader to sit down and actually assign a classification or a recovery expectation to their own system, because that conversation tends to expose gaps nobody wants to admit out loud, let alone own. Framing this as part of the consequence map leadership already approved, rather than a new request from security, tends to move that conversation along far faster than asking cold. This step should already be behind you by this point. As Vulnerability Management Based on Security Brutalism and Survivability Engineering lays out, each system in the inventory needs a consequence tier set by security and business owners together before any scanner runs.

With this part built, every finding that survives reachability and susceptibility lands on a priority that reflects what the business stands to lose. That is the point where the program stops generating noise and starts producing a small, trustworthy list that security, development, and IT can actually work through together.

Now What?

Build these three parts in the order they appear here. The reachability record and the consequence tiers need to come first, since nothing that follows works without them in place. The pipeline checks for susceptibility come second, cutting volume down before any of it reaches a person. Damage comes last, and it falls into place with little added effort given that the values it draws on were already recorded during the consequence mapping work that had leadership's attention from the start.

Nothing here requires a mature security function existing before work can begin. It needs a clear choice of where the data lives, connecting the sources that already hold the truth about the environment, and running the same three checks on every finding without exception. What a team ends up with is a program where most findings get filtered and scored without a person touching them, leaving the limited attention security and engineering actually have for the small set of findings that survived every check and landed on a system the business really depends on.