Home
Solutions
Multi-cloud governance

Multi-cloud governance

One standard and one record across every cloud you run.

Each cloud ships its own policy engine, its own console and its own idea of evidence. ACSE holds them to one set of controls, routes every fix through one approval flow, and keeps one record your auditor can read, whichever cloud the resource lives in.

Talk to us See how it works

One answer for the board

Posture against each framework across all your clouds, not a separate report per provider.

The same bar everywhere

A control means the same thing on AWS, Google Cloud and Azure, so no cloud becomes the weak spot.

Connected without new risk

Each cloud connects through a federated, read-only identity. No long-lived key exists to leak.

Coverage

What each framework covers on each cloud

The share of each framework’s tracked technical controls that ACSE checks evaluate, cloud by cloud.

Share of each framework’s tracked technical controls that ACSE checks evaluate, by cloud
Framework	AWS74 checks	Google Cloud21 checks	Azure13 checks
CIS Benchmarks	82%51 of 62 controls	47%18 of 38 controls	55%12 of 22 controls
PCI DSS 4.0.1	44%21 of 48 controls	31%15 of 48 controls	17%8 of 48 controls
NIST SP 800-53 Rev. 5	53%24 of 45 controls	33%15 of 45 controls	27%12 of 45 controls
FedRAMP Moderate	53%24 of 45 controls	33%15 of 45 controls	27%12 of 45 controls
CCCS Medium	53%24 of 45 controls	33%15 of 45 controls	27%12 of 45 controls
ISO/IEC 27001	13%12 of 93 controls	9%8 of 93 controls	8%7 of 93 controls
SOC 2	21%8 of 38 controls	18%7 of 38 controls	13%5 of 38 controls

Share of each framework’s tracked technical controls that at least one automated check evaluates. The rest are listed as manual controls, so nothing is silently left out. Kubernetes and AI infrastructure coverage is coming. Generated 2026-10-23 from the provider packs.

One control model

One control, every cloud

ACSE separates the framework requirement from the technical test. A requirement maps to provider-neutral controls, and each control is evaluated by checks written for each cloud’s storage, compute, network and identity services.

So a PCI DSS requirement reads the same in your report whether the bucket sits in AWS or Google Cloud, and a custom framework you build applies to all of them.

Framework text kept as published
Provider-neutral controls in between
Per-cloud checks underneath

Connect a cloud

Connected from the portal, read-only by design

A Tenant Admin connects AWS, Google Cloud or Azure from the portal. ACSE generates the setup, scoped to the accounts, projects or subscriptions you choose; your team runs it in your own cloud, then tests the connection.

ACSE never holds administrator or write rights in your cloud. Fixes still arrive as code.

Choose the cloud and the scopeIn Setup › Connect cloud, a Tenant Admin picks the provider and what to cover. ACSE lists every permission it will need and who in your team can grant them, before anything is created.
Run the generated setup in your cloudACSE generates a read-only setup bound to your tenant’s own runtime identity. Your team reviews and runs it. ACSE never runs it for you and never sees a key.
Test the connection and confirm with MFATest connection checks every permission and reports exactly what is missing. The Tenant Admin confirms with MFA, and the connection settings are recorded on your evidence chain.

Scope

One account, or every account in an AWS Organization or organizational unit.

What the setup creates

A read-only role, ACSEReadOnlyScanner, in each account in scope
A trust policy that lets only your own ACSE runtime assume it
A permissions boundary, so the role can never gain write access

Read-only by design. ACSE delivers fixes as pull requests to your code, so the connection never needs write access to your cloud.

Where ACSE runs

The estates you govern

AWS

Storage, compute, network and identity checks, with fixes as Terraform and runbooks.

Explore 02

Google Cloud

Connected through Workload Identity Federation, at project or organization scope.

Explore 03

Azure

Storage, compute, network and identity checks, connected through a federated identity.

Explore 04

Kubernetes

Fixes as patches to your manifests, Helm values or Kustomize overlays.

Explore

Questions

What people ask us

Do we get one score or one per cloud?

You see posture per framework across your whole estate, with the governed and raw scores always shown together.

Where does the evidence live for each cloud?

In retention-locked storage in your own cloud, with the same chain and seal rules everywhere: Object Lock on AWS, bucket lock on Google Cloud and immutable blob storage on Azure.

Does ACSE need write access to any cloud?

No. Every connection is read-only and federated. Changes reach your cloud through your own code and pipeline.

Can ACSE use the controls we already have in each cloud?

ACSE is designed to read your existing provider-native controls, such as organization policies, and assess whether they achieve the outcome a framework expects, so you don’t duplicate what already works.

Keep reading

ACSE

Talk to us

See ACSE on your cloud.

Tell us what you run and what your auditors ask for. We’ll show you the loop end to end: a real finding, a fix as code, an approval with MFA and the sealed record.

Talk to us Explore the platform