Compliance · AWS · Controls

AWS compliance controls mapping: services to SOC 2, PCI & ISO

Sahil Dubey

CISA · AWS Solutions Architect Professional · 27 Jul 2026

Engineers think in services; auditors think in controls. Here's how the core AWS building blocks map to SOC 2, PCI DSS and ISO 27001 - and the evidence each one produces.

Why this mapping matters

Engineers think in AWS services; auditors think in controls. The gap between those two languages is where audits stall. This is how the core AWS building blocks map to SOC 2, PCI DSS and ISO 27001 — and, just as important, the evidence each one has to produce.

The mapping

AWS component	Satisfies (SOC 2 / PCI / ISO)	Evidence an auditor asks for
IAM + Identity Center + IRSA	CC6.1–6.3 / PCI 7,8 / A.9	Access-review export, MFA policy, no long-lived keys
VPC + private subnets + SG/NACL	CC6.6 / PCI 1 / A.13	Network diagram, SG rules, no 0.0.0.0/0 to sensitive ports
KMS + Secrets Manager	CC6.7 / PCI 3,4 / A.10	Key policies, rotation config, encryption-at-rest proof
CloudTrail + Config + GuardDuty	CC7.2–7.3 / PCI 10 / A.12	Log retention, tamper-evidence, alert routing
CodePipeline + Checkov/OPA gate	CC8.1 / PCI 6 / A.14	Pipeline definition, failed-build evidence, change tickets
RDS + automated backups	A1.2 / PCI 10 / A.12	Backup schedule, tested restore, RTO/RPO doc

The failure modes

• Long-lived access keys in CI instead of IRSA or OIDC.
• A public RDS endpoint or open SSH to 0.0.0.0/0.
• Hardcoded secrets and unmanaged encryption keys.
• Logging switched off in one region, so the trail has holes.
• Manual production changes with no pipeline gate or ticket.

From mapping to evidence

The point of the mapping isn't the table — it's that each row produces evidence automatically when the control is real. IAM Identity Center emits access reviews; the pipeline emits change records; Config emits drift. Wire those outputs into an evidence store and the audit stops being a scramble.

My take

One well-built AWS control set serves SOC 2, PCI DSS and ISO 27001 at once, because the frameworks overlap far more than they differ. Build the controls to satisfy the strictest requirement, map them to each framework, and you defend three audits with one platform.

Want your services mapped to your framework?

I'll map your AWS architecture to your target controls and show you exactly what evidence each piece must produce.

DevOps & Compliance →Book a free call

The abstract case for mapping is easy to accept and hard to act on, so here is a single control traced all the way through.

The control: no standing administrative access to production; privileged access is granted just-in-time, time-boxed, and every assumption of the role is logged.

The AWS implementation: IAM Identity Center with permission sets carrying a session duration limit; no IAM users with attached admin policies; production in its own account so the boundary is an account boundary rather than a policy condition; CloudTrail organisation trail writing to a log archive account that the production role cannot write to or delete from.

What each framework wants from it: SOC 2 reads it against the common criteria on logical access — it will want your provisioning and deprovisioning records and a completed access review. ISO 27001 maps it to the Annex A access control and privileged access requirements, and additionally wants it reflected in your access control policy and risk treatment. PCI DSS is the most prescriptive — least privilege, unique IDs, MFA for administrative access, and log retention with defined review. HIPAA frames it as the access control and audit controls requirements under the Security Rule, and wants it tied to your risk analysis.

What you produce once: the permission set configuration, the CloudTrail archive, an access review export with dates and reviewer, and a joiner-mover-leaver record. Four frameworks, one implementation, one evidence bundle, four references. That ratio is the entire argument for mapping before building.

The failure mode this avoids is well known: evidence assembled by hand in the weeks before an audit, which is expensive, error-prone and produces artefacts nobody trusts.

AWS Config is the workhorse. Rules evaluate resources continuously and record compliance state over time, which matters because auditors ask about a period rather than a moment. Conformance packs give you pre-built rule sets aligned to common frameworks — useful as a starting point, though they need tuning to your architecture rather than adopting wholesale.

Security Hub aggregates findings across accounts and scores them against standards, giving you one place to see posture and, more usefully, a trend line. A control that was passing in March and failing in July is exactly what a Type 2 observation window is designed to surface.

CloudTrail is the record of who did what. The detail that determines whether it is credible evidence is where it is written: a log archive in a separate account, with the production role holding no write or delete permission. Logs an administrator could alter are not evidence of administrator behaviour.

AWS Audit Manager collects evidence against framework-specific assessments and is genuinely useful for reducing manual work, with the caveat that it collects what you configure it to collect — it is not a compliance oracle.

Underneath all of it, Terraform or equivalent keeps the configuration from drifting between assessments. The most common way an organisation fails a re-assessment is not a missing control but a control that quietly stopped applying eleven months ago.

This is the point most mapping exercises understate. Separating environments into distinct AWS accounts is not organisational tidiness — it satisfies control objectives across every framework simultaneously, and it does so more convincingly than any IAM policy.

Segmentation, blast-radius containment, separation of duties and the integrity of the audit trail all become structural rather than configuration-dependent. An auditor can verify an account boundary in seconds; verifying that a sprawling set of IAM conditions genuinely prevents cross-environment access takes considerably longer and inspires less confidence.

It also makes scope arguments straightforward. If cardholder data or protected health information lives in a dedicated account with controlled connectivity, the case for what is in and out of scope is a diagram rather than an argument. That reduces both audit effort and the surface you are obliged to evidence.

The cost is real — more accounts to manage, cross-account access to design, and centralised logging and billing to build. Organisations or Control Tower absorb most of it, and the compliance return is disproportionate to the effort.

Two honest caveats, because control mapping is oversold.

First, a mapping is not an assessment. Demonstrating that an AWS service can satisfy a requirement says nothing about whether your configuration does. Every mapping table published — mine included — describes potential, and the gap between potential and reality is exactly what an assessor exists to examine.

Second, frameworks are not fully commutative. Where SOC 2 lets you define the control and then tests whether you ran it, PCI DSS specifies the control and tests conformance to the specification. A control satisfying SOC 2 may be too loosely defined for PCI. Map the overlap, then handle the prescriptive requirements on their own terms rather than assuming coverage.

Related reading: SOC 2 vs ISO 27001 on sequencing, and secure cloud landing zone for the multi-account build this depends on.