This program ranks vulnerabilities by what they threaten, not just how severe they look on paper. It runs every finding through reachability, susceptibility, and damage, then weighs the result against the business consequence of the system it lives on, so security, development, and IT can fix what actually needs fixing first.

Start from the consequence map, not the CVE feed. CVSS describes a flaw in isolation, but it says nothing about whether the system carrying that flaw is the one that ends the business if it fails. Before any scanner runs, each system in the inventory receives a consequence tier set by security and business owners together, based on the consequence map. For example, a payment system or a customer data store sits in the "existential" tier, whereas an internal reporting tool sits lower. This tier travels with the asset through every stage that follows, and it changes how fast a finding needs to move regardless of what its CVSS score says on its own.

There are three checks that need to happen before a ticket opens. The first check tests reachability. It traces network paths, public endpoints, and authentication barriers to establish who can reach the vulnerable component, and it also traces what that component can reach once compromised, since a worker node sealed off from public traffic can still become a pivot point toward something consequential. A flaw sitting behind strict isolation earns lower urgency only when both directions check out clean.

The second check tests susceptibility. Static and dynamic analysis confirm that the running service actually loads the vulnerable dependency and executes the flawed code path under its real configuration. A vulnerable library sitting unused in a dependency tree carries none of the urgency of one the application calls on every request.

The third thing to check is damage. This stage looks at data classification, runtime privileges, blast radius, and how long the affected system takes to restore if it gets compromised and needs rebuilding. A system with a tested one hour recovery carries different weight than one nobody has restored from backup in years, and that difference informs the response timeline as much as the vulnerability itself does.

A finding that clears all three checks against a KEV listing (Known Exploited Vulnerabilities) or a high exploit prediction score becomes a ticket. Everything else drops into scheduled maintenance or a ticket with lower priority, scaled to its consequence tier rather than treated as a single backlog.

Speaking of tickets, they are built to be actioned, not just logged. Actioned and to be used and education for people helping security become stronger. Each ticket explains the attack path in plain language, the access level required, and what an attacker actually gains. It describes the exact file, package, or configuration flag responsible, and it gives the engineer a specific fix rather than a generic advisory. Infrastructure level fixes route to the team that owns the infrastructure instead of landing in an application repo where nobody can act on them.

Remediation gets verified the same way the finding got found. The pipeline rescans the fix once it reaches staging, and the ticket closes only when the scan confirms the vulnerable path is gone.

There is an important component in a good vulnerability management program that usually gets messy. Ownership, and it's split three ways.

Security owns the consequence tiers, the scoring logic behind the three checks, and the exception process. Development owns the fix itself and the remediation timeline for the services it runs. IT owns infrastructure level remediation and operating systems patching, the kind that lives outside any single application repo and gets missed when automation assumes every fix belongs to a codebase.

Exceptions require a documented reason, a compensating control where one exists, and an expiration date. An exception with no expiration functions as a vulnerability with a permanent excuse, and the program treats it that way. An exception for vulnerabilities that apply to existential or high-recoverable systems must be reviewed and approved by a senior security leader, i.e. a CISO or VP of Security, and owned by the most senior executive on the department where the issue was found. Security does not own risk.

The final component is what gets measured. Time to remediate gets tracked by consequence tier rather than blended into one average, since a fast response on low tier findings can hide a slow one on existential systems. The share of findings closed through manual override is just as relevant, because a high rate there usually means the scoring logic is missing something people keep correcting by hand rather than trusting. Open and expired exceptions get their own count too, as an exception nobody revisited after it expired carries the same exposure as having no exception process at all.

Remember, this program works only if the tiers stay current and the exceptions get revisited on schedule. Treat it as a living structure that follows the business as it changes, not a one time setup that runs on its own from here.