The Same Control Passes in One Cloud and Fails in Another. Both Are Right.

One requirement, three benchmarks, three correct answers

The requirement was written once, in a policy document, in a single line: data at rest is encrypted. Three platform teams implemented it with the primitives their platform gives them, which is what a competent platform team does. Then assessment season arrives and that one line produces a pass in one place and a finding in another.

Each benchmark did exactly the job it was built for. A benchmark is written against its own platform's service model, its defaults, and what the community maintaining it considers a defensible configuration there. Where the platform encrypts by default, the benchmark's job is to catch the deviation. Where the platform expects the setting to be asserted, its job is to confirm it. One requirement, two evaluation strategies, two verdicts, both correct inside the model that produced them.

That sentence is worth holding onto, because the reflex in the room is to rank the three providers. Each benchmark grades against its own platform's model, which is what makes it usable inside that platform, and the drift sits in the space between the models. The sentence that says what you meant sits above all three, and only you can write it.

The same requirement diverges in at least three ways before anyone has misconfigured anything:

• The control boundary. One platform treats the key, the storage service and the access policy as separate settings. Another folds them together. The requirement covers the same ground either way and lands on a different number of checks.
• The default. A strong platform default moves the interesting evidence from the configuration to the exception, and the benchmark follows the evidence.
• The unit of evaluation. Accounts, subscriptions and projects are different containers with different nesting rules, so a finding scoped to one carries a different weight in each cloud.

Three honest answers are three descriptions. A position is one sentence, and writing it is yours.

Where the drift concentrates

The cross-cloud control mapping CWS uses was built by hand, on the same tool agnostic AWS, Azure and Google Cloud work scored against CIS Benchmarks, the Cloud Controls Matrix and the NIST Cybersecurity Framework. It gets edited for the estate in front of it, because the service mix changes. Where the drift concentrates follows from how benchmarks are written, which means it can be predicted before any export arrives.

It concentrates in the ordinary capabilities, the ones every framework has an entry for and every platform has built the most machinery around. Administrative access logging is the clearest case. Every provider gives you a durable record of who did what to the control plane, and the service names, the retention defaults, the granularity and the line between control plane and data access all sit differently. Each benchmark grades what its own platform emits, and it grades it accurately.

So the reconciliation happens one requirement at a time. You decide what evidence proves intent on each platform, and you write that decision down before the results arrive. Do it afterwards and the decision gets shaped by whichever export was hardest to argue with.

The four shapes it takes:

• Capabilities one platform delivers as a single toggle and another assembles from several components.
• Capabilities where a strong default sends one platform's benchmark looking for something entirely different.
• Capabilities that live in a different layer per platform: identity in one, network in another, resource policy in a third.
• Coverage boundaries. An account nobody onboarded, a region nobody enabled, an organizational unit outside the read role: all of it comes back quiet.

The estate does not have three postures. It has one posture described three times, each description precise about the platform it was written for.

What each framework carries, and what it will not carry for you

Three public frameworks sit behind this work. Each is doing a different job, and naming the job keeps the demands placed on each one inside what it was built to answer.

Published mappings between them exist and are worth using wherever they cover your case. Coverage runs out, because a mapping is written at the level of the control and this problem surfaces at the level of the implementation. Past that line you are exercising judgment, so put the judgment in the report where the reader can argue with it.

• CIS Benchmarks are published per platform, prescriptive down to individual settings, each with its own numbering and its own profile levels. That precision is what makes them good evidence and what ties each one to the platform it was written for. A recommendation from one cloud's benchmark has no address in another.
• The Cloud Controls Matrix, from the Cloud Security Alliance, is organized by control domain, applies across providers, and is explicit about which side of the shared responsibility boundary a control sits on. Its domains keep their shape while the platforms underneath them change, which makes them the natural anchor for a cross-cloud requirement.
• The NIST Cybersecurity Framework is the reporting layer: functions and categories, a current profile measured against a target profile, and tiers describing how repeatable the practice is. It is written in terms of outcomes, which leaves the question of whether one setting on one service is right to the benchmark.

The control intent layer, and what it has to do

Above the three benchmarks sits a written statement of control intent, one per requirement, in plain language, owned by you. The control intent layer, what it has to contain, and how divergence between providers gets treated are CWS design. No standards body publishes this layer, and no framework supplies it for you.

Each intent statement says what the control has to achieve in words that name no service. Underneath it sit the evidence expressions, one per platform, each naming what an assessor will inspect there to decide the intent is met. The benchmark recommendation is cited as the evidence. The verdict belongs to the intent statement, which reads the same in all three clouds.

The layer earns its place on exactly the cases that produced the disagreement. When one platform meets the intent through a default and another through explicit configuration, both roll up as met, with the difference recorded as an implementation note. When a platform cannot reach the intent with the services in use, that becomes a documented exception with an owner and a date, weighted the same wherever it appears.

The whole layer has to be written before the first export lands, and it has to contain:

• The intent, stated once, with no service name in it.
• One evidence expression per platform, naming what will be inspected.
• The rule for a partial pass, settled in advance, so nobody negotiates it in the final week.
• The disposition when a platform cannot reach the intent: exception, compensating control, or accepted risk, each with a person's name against it.
• A version stamp, so the next assessment can be compared to this one.

A control intent written after the exports arrive describes whatever the exports happened to say.

The one answer you owe

Whoever asked, an audit committee, a regulator, a customer's security questionnaire, wants one line and is entitled to one. The line to give them carries the divergence inside it, because the divergence is the part that describes what the estate does.

It reads something like this. The requirement is met across the estate. Two providers meet it through platform defaults and one through explicit configuration. One business unit's older workloads sit under a documented exception with a close date and an owner. That is a single answer, it is longer than a percentage, and it survives the follow-up question.

The part that gets skipped is ownership of the mapping itself. Once the intent layer exists it has a version and a maintainer, and it should outlive the assessment that produced it. A new provider, a new service, a revised benchmark: each is an edit to a document you already hold.

Whether your own team builds this or you bring someone in, insist on:

• The intent statements delivered as their own artifact, separate from the findings.
• Framework versions named, including the benchmark version used for each platform.
• Every equivalence judgment attributed to a person.
• The parts of the estate the assessment could not reach, written down with the same care as the findings.
• A re-run on the same intent layer, so the second number means something standing next to the first.