The Console Says Critical. Critical to What Is Your Sentence to Write.

What a severity rating is computed from

Open the queue and the ordering looks settled. Critical at the top, high underneath, a long tail below. The rating is honest about its inputs, and every one of them is a property of the finding itself.

The scoring standards treat that as half the job and say so. CVSS publishes a base metric group describing the vulnerability as it stands, and a separate environmental group covering the confidentiality, integrity and availability requirements only the consuming organization can set. The base score is the assessor's work. The environmental adjustment belongs to whoever owns the asset, and the specification is explicit about it.

Products in this category read further than the finding. Wiz and Prisma Cloud, both of which CWS implements, weigh effective exposure, data sensitivity and privilege into the severity they present, and that weighting is real work done well. It runs on what the estate has recorded about itself: tags, resource names, account structure, and whatever inventory is connected to it. Which workload the resource belongs to, and what the business would notice if it stopped, reach that machinery as accurately as somebody wrote them down and no more.

So the queue arrives ordered by something precise about the finding and dependent, for everything past that, on a record your organization maintains. What the rating itself has to work with:

• The class of the misconfiguration and the control that is off
• The configuration state of the resource as the provider's API reports it
• Declared exposure such as a public endpoint, an open port or a permissive policy
• Published vulnerability metrics where a CVE applies

Critical to what is a question about your business, and the answer to it lives with the people who run it.

Where the record runs thin

Take a storage bucket with public read enabled. Whether it matters turns on what the workload behind it does, and the estate's own record of that is a tag applied by whoever ran the pipeline that day. Where the tag is right, a context aware tool weighs it correctly. Where it says sandbox and the bucket has been fronting production for a year, the weighting is right about the input and wrong about the world.

Reachability generates the most argument, and it is where the better tooling earns its money. Effective exposure analysis follows the actual route: the listener in front of the resource, the authentication layer, the peering added for a migration and left in place. What stays outside it is intent. Whether that peering was meant to survive the migration is held by the two engineers who agreed it, and it decides whether the finding is a cleanup or an incident waiting.

Then there is timing. A batch account sits idle for most of the month and carries the close for a few days of it. A finding against it means one thing in the first week and something else in the last, and it scores identically in both, because the calendar that account serves is held by the finance team.

The questions worth putting to a finding before it takes a place in the order:

• Which workload owns this resource, named the way the business names it
• What data that workload touches, at whatever classification you already use
• Whether the path to it is reachable once routing, upstream controls and authentication are accounted for
• What breaks if the resource is unavailable, and who notices first

Where the business context lives

The instinct is to go looking for the system that holds this, and two candidates come up. Tags are readable by everything, which is what makes them attractive, and they were applied at creation against a convention that has been revised twice since. A configuration management database is the second, and where its cloud records were imported once as an account list, that is what they still are. Both are readable. Whether either is current is the question.

The mapping from an account, subscription or project to a business owner takes longer than any other input, and it gets corrected after the first pass. It gets assembled by asking. An application owner knows what runs in their subscription. A data steward knows which stores are in scope for a regulator. A platform engineer knows which account was stood up for a trial and never closed. Those conversations produce the ranking layer.

The shortcut worth taking is to reuse a list your organization already maintains for another reason, one where being wrong has a consequence. A tier invented for a security report has nothing keeping it honest. A tier that pages somebody at three in the morning gets corrected the first time it is wrong. Lists that hold up:

• Disaster recovery tiering, which ranks systems by what the business can survive losing
• The applications with a named on call rotation, which is criticality somebody funded
• Audit scope, which names the systems whose failure carries a reporting obligation

The application owner can tell you in ten seconds what runs in their subscription. The tag can tell you in a millisecond, and it was last correct in March.

Building the ranking layer

The layer is a small amount of arithmetic on top of a large amount of agreement. The arithmetic: a criticality tier for the workload, a data classification, a reachability judgment, and the finding's own rating, combined by a rule you write down. Getting four people to agree on the tiers is where the time goes.

This is the environmental adjustment CVSS describes, done deliberately and written down. Posture findings carrying a vendor's own severity work the same way: the description comes from whoever measured it, the weight comes from whoever owns the estate. The inputs listed below, the demotion rule and the review cadence are CWS recommendations. CVSS gives you an environmental metric group. Filling it in is the work described here.

Two rules keep the layer defensible. It has to be able to demote, or you have built an escalation machine and the queue only grows. And it has to be versioned, because a queue that reordered itself for reasons nobody logged is harder to defend than the rating you started from.

Write these down before anyone re-sorts a queue:

• The criticality tiers, and which existing list they come from
• The data classification, coarse enough that a person can apply it in a minute
• The rule combining them with the finding's rating, in enough detail that someone else reproduces your order
• The owner of each judgment, by name
• What happens when a workload changes tier, and who tells you
• The version of the rule, stamped on the queue it produced

Keeping it current, which is where it fails

Context decays on its own schedule. A team reorganizes and the owner named against a set of accounts left in March. An application changes tier and the tier list never hears about it. A trial account graduates into production over a weekend, keeping the tag that says it is a sandbox.

Account creation is the cheap moment to capture this. Requiring an owner, a tier and a data classification before the account exists costs three form fields. Reconstructing the same three facts later costs calendar time from people who have to be tracked down, and it produces a weaker answer, because some of the people who knew have moved on.

The other half is a review with a date on it. No standards body publishes a cadence for this, so treat quarterly for the tiering and annually for the classification as a considered starting point. The interval matters less than whether a name sits against it. Signs the layer has gone stale:

• An owner field naming a team that no longer exists
• Accounts created since the last review with no tier against them
• A sandbox tag on something carrying production traffic
• A queue order no engineer can explain without opening a spreadsheet

What the reordered queue changes

The visible output is a different order. Two findings both rated critical: one against an account holding synthetic data for a training environment, one against the account that fronts customer sign in. They leave the console with the same severity and leave your process with weeks between their due dates. Both ratings are exactly what the console produced.

The quieter output is a sentence you can say in front of a board or an auditor. Asked why the third item is being worked ahead of the first, you have an answer with a rule and a name behind it. That answer survives a change of tooling, a change of provider, and the departure of the engineer who knew which account mattered.

Ownership, criticality and classification are inputs CWS collects during tool agnostic posture assessment across AWS, Azure and Google Cloud, scored against CIS Benchmarks, the Cloud Controls Matrix and the NIST Cybersecurity Framework, because a rating only becomes a ranking once they are in hand. The interviews that produce those inputs are already happening there, which is the practical reason an assessment is where they get collected. What gets built on top stays with you afterwards, because the judgments inside it are yours.

The rating underneath is left exactly as it is. It describes the finding, and it goes on doing that through every tool change you make. What gets added on top is the half of the sentence your organization writes.

The rating describes the finding. What the finding threatens is a sentence your organization writes and signs.