Three Clouds, Three Severity Scales, One Board Asking for One Number

Three scales and one sentence

The request sounds small: one answer on how the cloud estate is doing this quarter. The estate runs on AWS because the platform team started there, Azure because the identity stack lives there, and Google Cloud because an acquisition brought it in. Each console is accurate about what it grades.

The trouble starts at severity. Three consoles grade on three scales because each was designed for the platform it grades. A publicly reachable storage object in one and an over-permissive role in another both come back labeled high, and the two highs were built against different tests. Somebody reconciles them by hand, in a workbook carrying one engineer's initials, and if that engineer leaves, next quarter starts from a blank sheet.

One sentence above all three is the deliverable, and it is written by whoever is accountable for the estate. Three things have to be settled before that sentence exists:

• Each provider grades severity against its own service catalog and its own view of a sensible configuration on its own platform. That is the right thing for a provider to do, and it leaves you deciding how the three scales relate to each other.
• The vocabulary drifts as well. The key that never rotates, the network path that should not exist, the identity that can grant itself more than it was given: three names for one idea, and a fourth on your risk register.
• Then there is weighting. Any engine that aggregates the three ships a default, because it is built to serve every customer at once. What counts as adequate for a business your size is a judgment you make and sign.

The board asked for a sentence. What arrives is three exports and a covering note.

The rubric is the deliverable, the tool is an evidence source

Decide the scoring method before anyone opens a console. Every tool in the estate then feeds it as an evidence source, and the score stays with the method whichever tools happen to sit underneath it.

You can test whether you have one. Take any number in the report and walk it down: to the rule that produced it, to the evidence that fed the rule, to the person who signed the judgment where the rule ran out. A figure that survives that walk is yours to defend a year from now, whatever is generating the evidence by then.

An assessment written from outside the consoles earns its place for a structural reason. Any engine that scores an estate ships one method, because it has to serve every customer at once, which is what makes it a product. A method built for your estate weighs what is true only of your estate: the two accounts that carry regulated data, the controls you inherit from a provider, the exception your auditor already accepted. Choosing between the shipped method and your own, and defending the choice, is the work.

Anyone can staple a summary page to the front of a findings export. The finished article is a scored posture, and it carries:

• The rubric that produced it, in enough detail that an engineer who was not in the room could reproduce the number
• A named owner for every judgment call
• Every finding traced down to the evidence source and the setting it came from
• What the assessment could not see, and why

The score lives in the rubric. The tools underneath it are evidence sources, and the rubric is what you defend.

Folding CIS, CCM and NIST CSF into one carryable score

Three public frameworks do three different jobs here, and the method needs all three.

What follows is CWS design. The three layer reconciliation, the scoping basis and the sequencing argument are ours, and no standards body publishes this arrangement. Let each layer do the part it is good at. Anchor every finding on a Cloud Controls Matrix domain, because the domain survives the move between clouds. Carry the platform specific CIS Benchmark recommendation underneath it as the evidence. Roll the domains up to a Cybersecurity Framework function for the executive view. An auditor can then walk any summary number back down to the setting.

Where published mappings between the frameworks exist, use those. Where the case falls outside them, you are making a judgment, so write it into the report where the reader can see it.

Each framework earns its layer:

• CIS Benchmarks come one per platform, one for AWS, one for Azure, one for Google Cloud, prescriptive down to the individual setting, each with its own numbering and profile levels. That precision is what makes them good evidence and what ties each one to its own platform.
• The Cloud Controls Matrix, from the Cloud Security Alliance, is organized by control domain, applies across clouds, and is explicit about which side of the shared responsibility line a control falls on. Its domains hold steady while the platforms underneath them change.
• The NIST Cybersecurity Framework is what you report in. Functions and categories, a current profile measured against a target profile, and tiers describing how repeatable the practice is. The 2.0 revision added a governance function, one reason to stamp the version on anything you plan to compare.

One method with specialists feeding it

There is a version of this that produces three reports in one binder. Three specialists, one per cloud, each writing in their own idiom, reconciliation left to the final week. The same problem then lands on page nine and page twenty two under two names, and the reader is left to work out that they are one thing.

It works better when one person owns the method and the specialists feed evidence into it. The scoring conversation then happens once, at the start, with you in the room: what adequate looks like for a business your size, which controls you inherit from the provider, and where a documented exception is the right answer and should score as one.

Scoping deserves more care than it gets. Account count is what gets asked for, because it is easy to ask and easy to answer. The effort tracks distinct control planes, the identity model, and how much of the estate arrived through acquisition.

Whether your team does the work or you bring someone in, insist these are written down first:

• The frameworks and their versions, so this score can be compared to the next one
• Read only access per cloud, written down as the role name
• The evidence sources accepted, and how a conflict between two of them is resolved
• The sampling basis behind anything that came out of an interview
• What you receive: the scored posture, a remediation plan sequenced by cost of closure, and the rubric itself
• Whether a re-score is included, and on what cadence

What implementing the platforms changes about assessing with them

CWS runs this assessment tool agnostically across AWS, Azure and Google Cloud, scored against CIS Benchmarks, the Cloud Controls Matrix and the NIST Cybersecurity Framework, with the same practice that implements Prisma Cloud and Wiz. Any competent assessor reading the same estate reaches roughly the same finding list, because a configuration is either set or it is not. The difference an implementer makes is in what they can tell you about each line afterward.

The first difference is what a finding costs to close, and closure cost sits outside the finding itself. Order the list that way and the platform team can start on Monday, which the severity column will never let them do.

The second is where a clean result deserves suspicion. An estate section onboarded last month has not been assessed yet, and in an aggregate view it is indistinguishable from a section with nothing wrong in it. Three checks before a clean domain gets reported as clean:

• An account that was never onboarded
• A region never enabled
• A permission granted at a scope that reads most of the estate but not all of it

The re-score: making the number move

The first score describes one day. The board wants to know whether the last six months of effort and spend bought anything, and only a second measurement answers that. So build the assessment to be repeatable from day one.

Repeatable means the method is frozen and every change to it is written down. A revised benchmark, a new service in scope: those go in a log the reader can see, with the effect on the score stated separately from the estate's own movement. Otherwise improvement and method drift look the same.

The other half is ownership, and that half is yours. Every finding that survives the first report should leave it with a name, a target date, and the decision taken, including a decision to accept the risk. The second assessment then measures how many of those decisions held.

A re-score is a comparison only if these hold steady between the two:

• The rubric version
• The evidence sources, and how a conflict between them is resolved
• The sampling basis
• The treatment of inherited controls

A re-score run against a list with no owners returns the same list with a newer timestamp. All the board learns is how long it has been sitting there.