Navigating AWS Compliance: A Practical Guide for Security, Audit, and Risk Teams
PCI-DSS, FFIEC, SOC 2, GLBA, FSI expectations, and ISO 27001 — mapped to the AWS Shared Responsibility Model, extended into AI workloads and cloud computing generally, with the native AWS tools that make each framework auditable, not just achievable.
Security, audit, and risk teams don’t fail AWS compliance because the controls aren’t available. They fail because nobody has mapped which controls belong to AWS, which belong to the customer, and which AWS service actually generates the evidence an auditor will ask for.
Every major framework — PCI-DSS, FFIEC, SOC 2, GLBA, and ISO 27001 — sits on top of the same foundation: the AWS Shared Responsibility Model. Get that foundation wrong and every downstream control mapping, audit narrative, and evidence package inherits the mistake. Get it right, and AWS’s native tooling does most of the heavy lifting for you.
This guide is written for the people who have to defend the control environment in front of an auditor or examiner — not for the engineers configuring it. We’ll walk through the Shared Responsibility Model, map it to each framework’s expectations, show which AWS services generate the evidence you need, and give you a practical path to an audit-ready posture.
Frameworks & Domains Mapped to AWS Controls
Parties in the Shared Responsibility Model
AWS Services in Scope for Compliance Programs
Source of Truth: AWS Artifact
- The AWS Shared Responsibility Model, for Auditors
- Framework-by-Framework: What AWS Covers and What You Own
- FSI-Specific Expectations on AWS
- The AWS Toolkit for Continuous Compliance Evidence
- Extending the Model to AI Workloads and Cloud Computing Generally
- Building an Audit-Ready Program: A Practical Sequence
- Where Teams Get This Wrong
The AWS Shared Responsibility Model, for Auditors
AWS is responsible for the security of the cloud. The customer is responsible for security in the cloud. That single sentence is the correct starting point for every framework mapping in this guide — and it’s also the sentence most often misquoted in an audit narrative, usually in the direction of assuming AWS covers more than it does.
Physical data center security, hardware, the host operating system, virtualization layer, and the global network infrastructure. This is where AWS’s own certifications — SOC 1/2/3, ISO 27001, PCI DSS Level 1 Service Provider — apply.
Guest OS patching, identity and access management, network and firewall configuration, data encryption (at rest and in transit), and application-layer security. This is where the overwhelming majority of audit findings originate.
AWS’s self-service portal for on-demand access to AWS’s own audit reports (SOC reports, PCI attestations, ISO certificates) and for accepting agreements like the AWS Business Associate Addendum. This is the first place an auditor should be pointed.
Responsibility also shifts with the service model you choose. Infrastructure services like EC2 leave more “in the cloud” for the customer to own — patching, network ACLs, host hardening. Abstracted services like S3, RDS, and Lambda shift more toward AWS, since AWS manages the underlying platform. Container and serverless services sit in between. Every control mapping in this guide should be re-checked against the specific services in scope, not treated as a blanket statement about “AWS compliance.”
When an auditor asks “how do you know AWS is meeting its side of the model,” the answer is never “we trust AWS.” The answer is: AWS Artifact reports, reviewed on a defined cadence, with sign-off tracked in your GRC tool. Trust, but evidence it.
Framework-by-Framework: What AWS Covers and What You Own
Each framework asks a slightly different question, but they all draw the same line at the Shared Responsibility boundary. Here’s how the five most common frameworks map onto that line, and what a customer-side program needs to demonstrate for each.
PCI-DSS
AWS holds PCI DSS Level 1 Service Provider status and publishes its Attestation of Compliance (AoC) and Responsibility Matrix through AWS Artifact. That covers the underlying infrastructure hosting cardholder data. The customer remains fully responsible for scoping the cardholder data environment (CDE), network segmentation, encryption key management, access control to in-scope resources, and — critically — for engaging their own Qualified Security Assessor (QSA) to validate the customer-side controls. AWS’s certification does not transfer to your merchant compliance.
FFIEC
The FFIEC doesn’t certify AWS directly; instead, financial institution examiners expect the institution to perform vendor due diligence on AWS as a critical third party, referencing AWS’s SOC 2 and ISO 27001 reports as part of that diligence. Note that the FFIEC retired its Cybersecurity Assessment Tool (CAT) on August 31, 2025 — institutions still using CAT as their self-assessment framework should transition to NIST CSF 2.0 or the Cyber Risk Institute (CRI) Profile, the two frameworks the FFIEC pointed to as replacements. Either way, the customer owns mapping AWS controls into whichever framework is adopted, business continuity and resilience planning for workloads running on AWS, and ongoing vendor management documentation — not a one-time review at contract signing.
SOC 2
If your organization is pursuing its own SOC 2 report, AWS’s SOC 2 Type II report (available via Artifact) becomes a sub-service organization reference in your own auditor’s report — typically handled through the “carve-out” or “inclusive” method. Your Trust Services Criteria (security, availability, confidentiality, etc.) still need customer-side evidence: access reviews, change management, monitoring, and incident response performed by your team, on your AWS account.
GLBA
The Gramm-Leach-Bliley Act’s Safeguards Rule requires a written information security program covering access controls, encryption, and vendor oversight for nonpublic personal information (NPI). AWS provides the encryption and access-control primitives (KMS, IAM, S3 Block Public Access), but the customer must configure and evidence them specifically around where NPI lives, and document AWS as a service provider under the Safeguards Rule’s vendor management requirements.
ISO 27001
AWS’s own ISO 27001, 27017 (cloud-specific), and 27018 (PII) certifications cover the infrastructure layer and are available through Artifact. A customer pursuing their own ISO 27001 certification treats AWS as an external party in their Statement of Applicability (SoA) and still needs a full customer-side ISMS: risk assessments, an asset inventory covering cloud resources, and Annex A controls implemented in the customer’s account — AWS’s certificate covers Annex A controls at the infrastructure layer only.
| Framework | What AWS’s Certification Covers | What the Customer Must Still Own |
|---|---|---|
| PCI-DSS | Infrastructure hosting the CDE (Level 1 Service Provider AoC) | CDE scoping, segmentation, key management, own QSA assessment |
| FFIEC | No direct FFIEC certification — SOC 2/ISO reports support diligence | Vendor risk assessment, NIST CSF 2.0 / CRI Profile mapping, resilience & BCP planning |
| SOC 2 | Infrastructure-layer Trust Services Criteria (via sub-service reliance) | Application & account-layer controls, access reviews, monitoring |
| GLBA | Encryption and access-control primitives available in-platform | Written Safeguards Rule program, NPI-specific control evidence |
| ISO 27001 | Infrastructure-layer Annex A controls (plus 27017/27018) | Customer ISMS, SoA, risk register, account-layer Annex A controls |
FSI (Financial Services Industry) Expectations
FSI isn’t a single certifiable standard — it’s the umbrella of regulatory expectation that financial institutions operate under, blending FFIEC, GLBA, SEC/FINRA guidance, and increasingly state-level requirements like NYDFS 23 NYCRR 500. What ties them together on AWS is a consistent examiner expectation: demonstrated operational resilience, data residency and sovereignty control, and a documented third-party risk management program specific to AWS as a critical vendor.
AWS supports this through AWS Compliance Center for Financial Services reference architectures, regional partitions for data residency (including dedicated regions in some jurisdictions), and resilience features like Multi-AZ and Multi-Region failover. None of this satisfies FSI expectations automatically — the customer still needs a documented resilience testing cadence, a data residency control mapped to actual bucket/database locations, and board-level reporting that ties AWS architecture decisions back to the institution’s risk appetite.
FSI examiners tend to probe concentration risk — what happens if AWS itself has a regional outage. Pair your AWS architecture diagrams with a written business impact analysis showing recovery time and recovery point objectives per critical system. This single artifact answers most FSI resilience questions in one shot.
The AWS Toolkit for Continuous Compliance Evidence
Manually screenshotting console settings for every audit cycle doesn’t scale, and it produces evidence that’s stale the moment it’s captured. AWS’s native tooling is built to generate continuous, timestamped evidence instead — which is what examiners and auditors increasingly expect.
AWS Artifact — On-demand access to AWS’s own audit reports, certifications, and agreements. Your starting point for every framework’s “AWS-side” evidence.
AWS Audit Manager — Automates evidence collection against prebuilt frameworks including PCI DSS, SOC 2, and ISO 27001, mapping AWS Config and CloudTrail data directly to control requirements.
AWS Config — Continuously records resource configurations and evaluates them against managed or custom rules, producing a historical compliance timeline auditors can query directly.
AWS Security Hub — Aggregates findings across services and maps them to standards like CIS AWS Foundations, PCI DSS, and NIST — a single pane of glass for control status.
AWS CloudTrail — Immutable API activity logging. The backbone of “who did what, when” evidence for every framework’s access and change-management controls.
IAM Access Analyzer & IAM Credential Reports — Evidence for access-review and least-privilege controls, directly satisfying PCI-DSS, SOC 2, and ISO 27001 access-governance requirements.
AWS KMS & GuardDuty — Encryption key management and continuous threat detection, generating evidence for GLBA Safeguards Rule and ISO 27001 Annex A cryptography and monitoring controls.
Set up AWS Audit Manager’s prebuilt framework for your primary standard first, then customize. It automatically wires up the underlying Config rules and CloudTrail queries, saving weeks versus building custom evidence pipelines from scratch.
Security Hub and Config only evaluate what they’re turned on to evaluate, and only in the regions and accounts where they’re enabled. In a multi-account AWS Organization, confirm coverage through AWS Organizations-level aggregation — a control that “passes” in one account but was never deployed in three others is a finding waiting to happen.
Extending the Model to AI Workloads and Cloud Computing Generally
The same Shared Responsibility logic applies to AWS’s AI services — it just adds a layer. With Amazon Bedrock and SageMaker, AWS secures the underlying infrastructure and, for Bedrock, the foundation models themselves. The customer still owns data governance for anything sent to a model, access control over who can invoke it, logging of prompts and completions for audit purposes, and — for regulated data — confirming the model provider’s data usage terms (Bedrock does not use customer inputs to train underlying models, but this needs to be verified per model provider and documented).
Model access governance via IAM, prompt/output logging via CloudTrail and Bedrock’s model invocation logs, and guardrails (Bedrock Guardrails) for data leakage and content filtering — all of which need to map into your existing SOC 2 or ISO 27001 control set rather than living as a separate program.
Beyond any single framework, a cloud governance baseline — landing zone controls, tagging and cost/asset inventory, encryption-by-default policies, and a documented cloud risk register — is what lets every framework mapping above stay accurate as the environment grows.
AWS Audit Manager includes a prebuilt assessment for AI/ML workloads that pulls evidence from SageMaker and Bedrock configuration, giving audit teams a starting evidence set rather than a blank page when AI enters a compliance scope for the first time.
Frameworks like SOC 2 and ISO 27001 don’t yet have AI-specific criteria in most versions, so AI workloads get evaluated against existing controls — access management, change management, data classification. Don’t wait for a dedicated “AI framework” before bringing AI systems into scope; map them into what you already have today.
Building an Audit-Ready Program: A Practical Sequence
For teams starting from a blank slate — or cleaning up a program that grew organically — this sequence gets you to a defensible, evidence-backed posture without boiling the ocean.
-
Pull Your AWS Artifact Baseline
Download the current SOC 2, PCI AoC, and ISO 27001 certificate for AWS, plus the Responsibility Matrix relevant to your services. This becomes the “AWS-side” appendix in every framework binder you build.
-
Scope Your In-Scope Accounts and Services
Identify exactly which AWS accounts, regions, and services hold regulated data — cardholder data, NPI, customer PII. Scope creep here is the single biggest driver of audit fatigue; a tight, documented scope keeps evidence collection manageable.
-
Turn On Config, CloudTrail, and Security Hub Org-Wide
Enable these at the AWS Organizations level, not per-account, so there are no silent gaps. Route findings into a central logging/security account, not scattered across workload accounts.
-
Stand Up Audit Manager Against Your Primary Framework
Deploy the prebuilt assessment for PCI DSS, SOC 2, or ISO 27001, then extend to the others — most control evidence overlaps heavily across frameworks, so the second and third frameworks are far cheaper than the first.
-
Assign Control Owners and a Review Cadence
Every control needs a named human owner and a review frequency — quarterly for access reviews, continuous for configuration drift. Tie this into your GRC platform so evidence gaps surface before the auditor finds them.
Where Teams Get This Wrong
“AWS is SOC 2 certified” does not mean your application is SOC 2 compliant. Auditors distinguish sharply between infrastructure-layer and customer-layer controls — conflating them is the fastest way to draw a qualified opinion or a finding.
Avoid
A screenshot from six months ago proves a control existed then, not now. Continuous evidence from Config and Audit Manager is what modern examiners increasingly expect, especially under FFIEC and PCI-DSS.
Watch
Running separate PCI, SOC 2, and ISO 27001 projects in parallel duplicates evidence-gathering effort. Map controls once to a common control framework and evidence each downstream standard from that single source.
Improve
Individual teams spinning up AWS accounts outside AWS Organizations governance creates blind spots no framework mapping can cover. Enforce account creation through a governed landing zone (e.g., AWS Control Tower).
Don’t Skip
Confidence Comes From the Mapping, Not the Platform
AWS gives security, audit, and risk teams a genuinely strong foundation — but confidence comes from knowing exactly where AWS’s responsibility ends and yours begins, framework by framework, and having the evidence pipeline to prove it continuously rather than reconstructing it under deadline pressure.
Start with the Shared Responsibility Model as your organizing principle, pull your AWS Artifact baseline, and let Audit Manager and Config do the evidence-gathering your team used to do by hand. The frameworks stop feeling like five separate projects once the underlying control mapping is unified.