Security tooling is not the same thing as compliance

Most teams discover this gap a few weeks before an auditor’s first evidence request. Threat detection is enabled. Cloud posture management is green. Audit logs are flowing. And the auditor still asks: show me the ticket where this was remediated, who approved the exception, and proof this control held for the last twelve months — not just today.

That gap exists because a tool reports the current state of a resource. Compliance requires a process: detection, ownership, remediation, validation, and a durable record proving the process happened, repeatedly, over time. That’s true whether the resource sits in AWS, Azure, or GCP — the provider changes the console, not the requirement. Two things make this genuinely hard beyond the sheer number of controls:

SOC 2, PCI DSS v4.0, ISO 27001 & NIST CSF — how they relate

These four frameworks overlap heavily at the control level but differ in what they actually certify. Understanding the difference prevents a common mistake: treating any one of them as a substitute for the others. In practice, most of the technical controls in this guide (encryption, network segmentation, logging, access control, vulnerability management) satisfy requirements across all four simultaneously — the difference is in the evidence package and audit process each one demands, not the underlying engineering.

The compliance lifecycle

Ten stages, one loop. Every closed finding and every audit cycle should feed back into better preventive controls — this is not a line, it’s a wheel.

Landing zone governance

Every major provider expresses the same idea with different nouns: a hierarchical structure that isolates workloads, applies baseline guardrails automatically, and gives auditors a clean scoping boundary. A single-account, single-subscription, or single-project environment makes blast radius and audit scope nearly impossible to reason about. Regardless of provider, a dedicated security tooling boundary centralizes posture management and detection findings, and a separate log archive boundary holds immutable audit log data with no engineer write access — a compromised Dev credential shouldn’t be able to reach or erase Production’s audit trail.

Identity and access management

Identity is the control area auditors scrutinize hardest, because nearly every other control depends on it — and it’s also the area with the most consistent vocabulary across providers, since PCI DSS Requirement 7–8, SOC 2 CC6, and ISO 27001 Annex A.9 all describe the same underlying expectations.

Preventive policy defines the ceiling, not the grant

SCPs, Azure Policy (deny effect), and GCP Organization Policy constraints all do the same job: they set the maximum available permissions at the org/folder level — never granting permissions, only constraining them, even for account or subscription administrators. Example shown in AWS SCP syntax; the same intent is expressed as an Azure Policy deny-effect definition or a GCP Organization Policy constraint.

// AWS SCP example — deny disabling audit logging, applied org-wide
{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyAuditLogDisable",
    "Effect": "Deny",
    "Action": ["cloudtrail:StopLogging", "cloudtrail:DeleteTrail"],
    "Resource": "*"
  }]
}

Network security and compliance

A compliant network architecture separates workloads by trust boundary — this pattern is identical on every provider, only the resource names change. Public subnets hold only internet-facing load balancers; private subnets hold application compute; a dedicated data tier has no route to the internet at all. Databases should never be publicly accessible — access routes exclusively through application-tier firewall rules.

CSPM, configuration monitoring & threat detection

Every major provider now ships a native three-layer detection stack: a configuration recorder that continuously tracks resource state, a CSPM/findings aggregator that evaluates state against named standards and produces a posture score, and a threat detection service that correlates logs and behavior against threat intelligence. The layers map cleanly across providers even though the product names differ. Each CSPM platform evaluates against a set of named standards that typically include CIS benchmarks, the provider’s own best-practice baseline, and — critically for fintech — PCI DSS-mapped control sets, with NIST-aligned baselines also commonly available. The standards catalog on every provider evolves continuously as new services launch and older controls get retired or superseded, so periodically re-checking which controls are actually enabled is itself a compliance task, regardless of provider. A posture score of 100% means all enabled controls are passing — not that the environment is perfectly secure, on any provider. Threat detection is a genuinely different layer from CSPM: intelligence-driven detection correlating audit logs, network flow logs, DNS, and runtime behavior against threat intelligence, rather than static configuration checks.

Containers, serverless & databases

For containers (ECS/EKS, Azure Kubernetes Service/Container Apps, GKE/Cloud Run): non-root containers, readonlyRootFilesystem: true, minimal base images, mandatory image scanning, no privileged containers, and secrets injected via a managed secrets service — never baked into images. Read-only root filesystem is a good example of why small controls matter across every platform: it stops a compromised container from writing persistence mechanisms to its own filesystem, and it’s commonly missed on sidecar containers even after the main app container is remediated. For serverless functions (Lambda, Azure Functions, Cloud Functions/Cloud Run): least-privilege execution identity per function, no secrets in environment variables, current supported runtimes, and enabled code/dependency scanning. For managed databases (RDS/Aurora, Azure SQL/Cosmos DB, Cloud SQL/AlloyDB/Spanner): encryption at rest via the provider’s key-management service, TLS in transit, private-subnet-only deployment, no public endpoint, high-availability replication, and credentials in a managed secrets service with automated rotation.

CI/CD compliance & compliance as code

Shifting compliance left means catching violations before deployment, not after. Compliance as Code converts requirements into version-controlled, automated checks: Terraform (or Bicep/CloudFormation/Pulumi) modules that only produce compliant resources, provider-native config rules, preventive org policy, and policy-as-code tools like OPA, Checkov, and tfsec — all of which scan Terraform and native IaC regardless of which cloud it targets, so one policy-as-code pipeline can enforce the same rules across AWS, Azure, and GCP resources simultaneously. A Checkov check that fails the pipeline is preventive; a native config rule that flags the same issue post-deployment is detective — mature multi-cloud programs run both, using the same toolchain across providers rather than three separate ones.

Findings, exceptions & audit evidence

Evidence falls into two categories, and conflating them is a common audit failure: implementation evidence proves a control exists right now; operating-effectiveness evidence proves it held continuously over the audit period. Auditors — particularly for SOC 2 Type II — care far more about the second.

Real-world case study: triaging a batch of High findings

A fintech running a landing zone with Dev/QA/UAT/Production boundaries, a mix of containers, managed databases, object storage, and serverless functions — on one provider or split across more than one — receives six High-severity CSPM findings in one sweep. The pattern below applies whether the underlying platform is AWS, Azure, or GCP.

The pattern is identical across all six, and across every provider: understand → contain if actively exploitable → fix root cause via IaC → validate in the tool that raised it → capture the artifact trail.

Automated remediation

Automated remediation should almost always pair with a human approval step in Production — full auto-remediation without review can itself become an availability risk. The event-driven pattern is identical across providers: a finding triggers an event, an event bus routes it to a function, the function remediates, and the CSPM platform re-evaluates.

End-to-end reference architecture

This pattern applies whether the workload sits on one provider or is deliberately spread across more than one — the security layer at the bottom is where posture, config, and detection findings converge into a single view regardless of source.

Operating model & RACI

R = Responsible · A = Accountable · C = Consulted · I = Informed

Compliance maturity model

Implementation roadmap

Security & compliance checklist

A working subset — group each item by control implemented, monitored, evidence available, and owner assigned.