AWS Grades AWS. Azure Grades Azure. The Order Is Yours to Write.

Somebody decides the order

The native tooling is switched on across all three providers, and more than one of them reaches past its own platform. Microsoft Defender for Cloud takes AWS and Google Cloud accounts through connectors and grades them alongside Azure in one recommendation set and one secure score spanning all three. Google Security Command Center connects AWS, gathering configuration and resource data for misconfiguration discovery, posture assessment and attack path analysis across the connected estate. Prisma Cloud and Wiz span all three by design. Aggregation is a product capability, and a mature one.

One scheduling fact belongs in any plan that leans on the Google path: the service tier carrying its multicloud capability is documented as deprecated with a shutdown date of May 21, 2027, after which organizations move to the Premium tier, which Google documents as Google Cloud only. Where multicloud coverage lands after that date is a question for current Google documentation, asked before a roadmap depends on the answer.

What the aggregate hands you is a combined list. The sequence your platform team works on Monday turns on facts the estate does not record about itself: which account carries the settlement run, what a change window costs there, who can approve a change there without a second team in the room. Those come from people.

So the order gets made somewhere else, in a room, on a Thursday, and the version that survives comes down to ordinary pressures:

• Whichever cloud produced the last incident holds the top of the list for a quarter.
• The provider whose engineer is most present in the meeting gets sequenced first.
• Two findings carrying the same label are treated as equal because the labels match, before anyone checks whether the two scales behind them were built against the same test.
• An account that was never onboarded is absent from every view, and quiet reads as fine.

One view of three clouds is a product capability. The order the platform team works on Monday is a decision with a name against it.

A rank needs one method, and the method is a decision

Each provider's posture tooling grades the estate that provider operates, and several products in this category grade all three at once. The ranking method that sits on top, the business inputs behind it, and the name against each judgment get built inside your organization.

Ranking two things means holding both at once and applying a single test, and the test is a choice. Which control families carry more weight here. How a compensating control is credited. What an accepted risk scores. Any product that aggregates ships a default for these, because it has to serve every customer at once, which is what makes it a product. Adopting that default, tuning it, or writing your own is a decision your organization makes and signs.

The method also has to cover what lives between the clouds. A workload in one provider holding a federated identity into another, a data path that starts in one provider's storage and lands in another provider's analytics service: both ends have to be in view before the pair can be graded, and the rule for grading the pair is yours to set.

That leaves the estate layer a short and demanding job:

• One severity method, applied to every finding in the estate, settled before any console is opened.
• An anchor that survives the move between providers, so the same idea carries the same name wherever it turns up.
• A trace from every ranked item back down to the console and the setting it came from, leaving each provider's tooling the authority on its own estate.

The inputs a rank depends on live in your organization

Suppose the severity method is settled and every finding across the three providers sits on one scale. The list is still not in the order your platform team should work it, because half the ordering question is a business question, and those answers are held by people.

A publicly reachable object in a sandbox account and the same finding in the account that runs billing are one finding and two problems. Which project arrived through an acquisition and still runs on a trust relationship nobody has reviewed decides the order too, and that history is carried by the engineers who lived it.

The facts that settle a cross-cloud order are gathered by asking:

• Which accounts, subscriptions and projects hold regulated or customer data, at a granularity you would defend to an auditor.
• Which parts of the estate the business cannot take offline midweek, and what a change window costs there.
• Who is on call for each one, by name, and whether that person can make the change without a second team's approval.

The input that decides a cross-cloud rank is an organizational fact: which of these accounts the business cannot take offline on a Tuesday.

Anchoring the order on public ground

The method needs to stand on ground held outside the estate, which is what public frameworks are good for. CWS scores multi-cloud posture against three of them. The cross-estate ranking argument, the domain anchored ordering method and the coverage checks below are CWS design. Read them as an argument to test against your own estate.

Anchor every finding on a Cloud Controls Matrix domain, because a domain means the same thing on all three providers. Carry the platform specific CIS Benchmark recommendation underneath as the evidence, one benchmark per platform, prescriptive down to the individual setting. Report upward in NIST Cybersecurity Framework functions, the vocabulary the risk committee already reads.

The domain layer is what makes the ranking usable. Once every finding is anchored on a domain, the output is an order of domains, and identity and access weak in two clouds and solid in the third is a resourcing statement your platform leads can act on this month.

Freeze these before the first console is opened, or the next measurement will not compare:

• The framework versions, stamped on the report. The Cybersecurity Framework added a govern function at 2.0, and benchmarks revise on their own schedule.
• How a domain score is built from the findings underneath it, in enough detail that an engineer who was not in the room reproduces the number.
• Where a published mapping between frameworks was used, and where the mapping was a judgment somebody made and signed.
• How an inherited control is scored, so a control the provider operates says so on the page.

What pulls a hand assembled view out of shape

Where this gets built by hand it lands in a workbook, or a page in the risk register. What pulls it out of shape is mechanical.

The exports come from three different days, so the aggregate compares three different weeks and carries the movement between Tuesdays inside it. The person who reconciled the severity labels did it by judgment and kept the judgment in their head. Next quarter somebody else reconciles it differently and the score moves for reasons that have nothing to do with the estate.

The one that costs most is coverage. A part of the estate never onboarded produces an empty result, and an empty result sits in an aggregate looking like health.

Before an aggregate goes in front of anyone senior, check the boring things:

• Every account, subscription and project enumerated from your own billing hierarchy, then reconciled against what the assessment read.
• Regions and services never enabled, listed on the page as unmeasured.
• The read permission granted for the assessment, checked at its real scope, because a role that reads most of the estate still produces a report that looks whole.
• The export dates, all of them, on the same page as the score.

Every clean domain earns the same question: was this measured, or was it absent.

Running the estate view with the team that implements the platforms

CWS assesses AWS, Azure and Google Cloud posture against CIS Benchmarks, the Cloud Controls Matrix and the NIST Cybersecurity Framework, and the same practice implements Prisma Cloud and Wiz. The estate view runs on the evidence the estate already produces, whatever is generating it.

What implementation experience changes is the column beside the finding. An item that closes with a policy change on Monday, an item that closes with a documented exception carrying an owner and a date, and an item that needs a quarter and a budget line all read identically in a severity column and behave nothing alike in a plan.

It also changes where the skepticism goes. A clean result in a part of the estate that was added last month is a claim about onboarding before it is a claim about configuration, and it gets verified before it gets reported.

Whether your own team builds this layer or you bring someone in, agree these before anyone starts:

• Read only access per cloud, written down as the role name.
• The evidence sources accepted per provider, and how a disagreement between two of them is settled.
• What you receive at the end: the ranked estate view, the domain scores underneath it, and a remediation order with an owner against every line.