How to Audit a Cloud-Native Company

This is written for auditors. If you came up doing financial or IT general controls audits, the discipline transfers, but the evidence changes shape completely. GRC, Governance, Risk, and Compliance, has always been about proving that controls operate. In a cloud-native company, the controls and the proof both live inside the cloud provider, and that one fact changes how you scope, sample, and test.

The good news is that the control objectives in SOC 2 and ISO/IEC 27001 have not moved. Access control, change management, monitoring, and encryption all still apply. What you have to relearn is where the evidence comes from and what a good sample looks like when the infrastructure is rebuilt every deploy.

What changes when the company has no servers

A cloud-native company does not own racks, switches, or a server room you can walk. Production might be a few hundred containers that exist for ninety seconds and then disappear. The traditional audit instincts that worked against physical infrastructure quietly stop working here.

• Infrastructure is ephemeral: Servers are created and destroyed automatically. A screenshot of a host is evidence about something that no longer exists. You test the template and the pipeline that produce the hosts, not the hosts.
• Everything is configuration: A firewall is a security group definition. A network is a virtual private cloud config. The control is the setting, so your evidence is the setting as the provider reports it, pulled from the API.
• Everything is an API call: Provisioning, access changes, and deployments all happen through APIs that log themselves. CloudTrail, Azure Activity Log, and GCP Cloud Audit Logs give you a record of who did what, which is stronger evidence than a manual change ticket.
• Identity is the perimeter: There is no building badge to check. Access is governed by IAM policies, roles, and federation. Reading an IAM policy is now a core audit skill, not a specialist one.

How to scope a cloud audit

Scoping is where a cloud audit either starts clean or starts wrong. You are no longer drawing a boundary around buildings and asset inventories. You are drawing it around cloud accounts and the services running inside them.

• Enumerate the cloud accounts, subscriptions, or projects in scope. A single company often runs many AWS accounts, Azure subscriptions, or GCP projects. Get the full org structure first.
• List the managed services in use, not just the compute. Managed databases, object storage, queues, and serverless functions each carry their own controls.
• Identify the regions in play. Data residency and replication requirements often turn on which regions are active.
• Map the shared responsibility boundary for each service, because it determines which controls you test versus which you inherit from the provider.
• Confirm which framework and trust criteria apply. SOC 2 trust services criteria and ISO/IEC 27001 Annex A controls scope differently even over the same environment.

A clean scope reads like a list of accounts, services, and regions with a responsibility owner next to each one. If your scope still looks like a list of physical assets, you scoped a data center that does not exist.

How to sample evidence from cloud provider APIs

Here is the single most important shift in a cloud audit. Stop accepting screenshots as your population. A screenshot shows you what the client chose to show you. The provider API shows you everything.

The pattern is the same across AWS, Azure, and GCP. Query the API or console for the complete population of a resource, then sample from that complete list:

• Pull the full population first: List every IAM user, every storage bucket, every security group, or every database instance through the provider API. That list, not a screenshot, is your population.
• Sample from the complete list: Once you hold the full population, your sample selection is defensible and reproducible. You can re-run the same query and get the same answer, which is the point of independent evidence.
• Use read-only access where you can: Many cloud audits run with a read-only role in the client tenant so you pull evidence yourself. AWS Config, Azure Resource Graph, and GCP asset inventory let you query resource state directly.
• Capture the query, not just the result: Document the API call or console path you used. The reproducibility of the query is part of what makes the evidence reliable.

When the underlying environment is defined in code, you can also read the infrastructure-as-code directly. Reviewing a Terraform module or CloudFormation template tells you what the environment is supposed to be, and the API tells you what it actually is. The gap between the two is often your finding. For the deep version of that technique, read Auditing Infrastructure as Code.

Testing automated and continuous controls

Point-in-time testing assumes a control was either operating or not on the day you looked. Cloud controls are not like that. An AWS Config rule, an Azure Policy assignment, or a GCP Organization Policy runs continuously and evaluates every resource as it changes. The control is the rule, and the evidence is its execution history.

That changes how you test operating effectiveness over a SOC 2 Type 2 period or an ISO/IEC 27001 surveillance window:

• Test the rule itself. Confirm the automated control is defined correctly, for example that the policy actually requires encryption or blocks public access.
• Test the execution history across the period. Pull the evaluation results over the full audit window to show the control ran and caught violations, instead of inspecting one instance on one day.
• Test the response. When the control flagged a non-compliant resource, what happened next? An auto-remediation that fired, or a ticket that closed, is your operating-effectiveness evidence.
• Watch for gaps in coverage. A continuous control that was disabled for three weeks in the middle of the period is a finding you would never see from a single screenshot.

The same logic applies to the deployment pipeline, where change management controls now live as automated gates. For how to test those, see Auditing CI/CD Pipelines.

The shared responsibility model

The shared responsibility model is the dividing line between what the cloud provider controls and what the customer controls. Getting it wrong in either direction produces a bad audit. Test a control the provider owns and you are wasting effort on something you cannot evaluate. Skip a control the customer owns because you assumed the provider handles it, and you have a gap.

A workable way to think about it for the major providers:

• Provider controls: Physical data center security, hardware, the hypervisor, and the underlying service infrastructure. You do not test these. You inherit them through the provider's own SOC 2 or ISO/IEC 27001 report.
• Customer controls: Identity and access configuration, data classification and encryption choices, network configuration, and how the customer uses the services. This is where almost all of your testing happens.
• Shared controls: Patching and configuration management shift depending on the service model. For a managed database the provider patches the engine, but the customer still owns access and encryption settings.

For the controls you inherit, the provider's assurance report is your evidence. Read it the way you would any subservice organization report, and pay attention to the complementary user entity controls it lists, because those are controls the provider is explicitly telling you the customer must operate.

Mapping it to SOC 2 and ISO/IEC 27001

Neither framework was rewritten for the cloud, and neither needed to be. The control objectives are technology-neutral. What changes is the evidence you bring to satisfy them.

For SOC 2, the trust services criteria around logical access, change management, and monitoring map cleanly onto IAM policies, pipeline gates, and provider audit logs. A Type 2 opinion depends on operating effectiveness over a period, which is exactly why the continuous-control testing above matters so much.

For ISO/IEC 27001, the Annex A controls for access control, cryptography, and operations security translate the same way. The Information Security Management System still has to show that risks were identified and treated. In a cloud-native company, the treatment is usually a configuration or an automated policy, so your evidence of treatment is the configuration as the provider reports it.

Common pitfalls

• Accepting screenshots as the population: A screenshot is a sample of one that the client selected. Pull the full population from the API and sample from that instead.
• Point-in-time testing on continuous controls: Looking once misses the three weeks a control was disabled. Test the execution history across the whole period.
• Misreading the responsibility boundary: Testing provider controls wastes time and assuming the provider covers a customer control creates a gap. Map the boundary per service before you test.
• Treating multiple accounts as one: A control enforced in the production account may be missing in a forgotten sandbox that still touches production data. Scope every account.
• Skipping complementary user entity controls: The provider report tells you which controls the customer must run. Ignoring that list leaves real gaps untested.

The cloud literacy this takes

You do not need to become a cloud engineer to audit a cloud-native company. You do need enough fluency to read an IAM policy, navigate the AWS, Azure, or GCP console, interpret an audit log, and understand what infrastructure-as-code is doing. Without that, you are dependent on whatever the client hands you, which is the opposite of independent evidence.

That is the exact literacy the CGE-AUD Auditor Specialty was built to teach: how to scope, sample, and test cloud controls the way this guide describes, so you walk into a cloud audit pulling your own evidence instead of waiting on screenshots. If you are weighing it against a traditional auditing credential, see CGE-AUD vs CISA.

Frequently Asked Questions