Maintain AWS compliance by knowing which controls AWS covers and which are yours, collecting AWS's own audit reports as evidence, and continuously checking your accounts against the rules you committed to. Passing an audit once shows a moment in time. Drift between audits is where findings come from.
Who is responsible for what?
AWS describes a shared responsibility model: AWS is responsible for security "of" the cloud, meaning the hardware, software, networking and facilities that run its services, and the customer is responsible for security "in" the cloud.
AWS sorts controls into three kinds. Inherited controls are those a customer fully inherits, such as physical and environmental controls. Shared controls apply to both layers in separate contexts. Its examples: for patch management, AWS patches the infrastructure but customers patch their guest operating systems and applications. For configuration management, AWS maintains its infrastructure devices while customers configure their own guest systems, databases and applications. For awareness and training, AWS trains its employees and customers train theirs. Customer specific controls belong solely to the customer, depending on the application deployed, and AWS's example is zone security that may require routing data within specific security environments.
Responsibility also shifts with the service. NIST's cloud guidance makes the same point: the responsibilities of the organization and the provider vary with the service model, and consumers must understand how responsibilities are divided.
Where does the evidence come from?
AWS Artifact provides on demand downloads of AWS security and compliance documents, such as reports on compliance with ISO standards and PCI standards, and System and Organization Controls reports. It also provides certifications from accreditation bodies. You can submit these documents to auditors or regulators to show the security and compliance of the AWS infrastructure and services you use.
This covers the AWS layer. It does not cover your configuration, your code, your people or your processes. Auditors will ask you for those.
NIST adds a caution worth remembering: assurances from a provider, or from a review entity paid by the provider, should be verified through independent assessment where possible.
How do you detect drift?
AWS Config offers conformance packs, which AWS describes as a collection of Config rules and remediation actions that can be deployed as a single entity in an account and Region or across an organization in AWS Organizations. You author them in a YAML template listing managed or custom rules and remediation actions, and AWS provides sample templates to start from and to evaluate your environment.
The practical value is a standing definition of "compliant" that is checked all the time, with history. A pack is only as good as its mapping to the framework you are held to, so map each rule to a named control in your framework and keep that map in version control.
A constructed example
A company passes a SOC style audit in March. In June, an engineer creates a storage bucket with public read to share a file with a partner and forgets it. A conformance rule for public buckets flags it, because the team deployed packs across the organization. The ticket goes to the bucket's tagged owner, who removes access and sets an expiring link process. Without the continuous check, the exposure would have been found by a manual review in the next audit cycle, if then.
How to check or apply this
- Write down your obligations: the framework, scope and the accounts and Regions in scope.
- Mark each control as inherited, shared or yours, using AWS's model, and name an owner for each shared and customer control.
- Pull the relevant AWS audit reports from Artifact on a calendar, check each report's date and scope, and file them with your evidence.
- Deploy conformance packs across your accounts and map each rule to a control.
- Route findings to named owners with due dates, and track time to fix.
- Review exceptions monthly. An exception needs an owner, a reason and an end date.
- Treat new accounts and services as events: enroll them in the packs when created.
- Rehearse an audit by pulling evidence for three controls end to end.
Quick check
Does using AWS make me compliant?
No. AWS covers its infrastructure layer. Your configuration, code, access management and processes remain your responsibility and need your own evidence.
What does a conformance pack do?
It deploys a set of AWS Config rules and remediation actions as one unit, in one account and Region or across an organization, so you can check a standing set of rules continuously.
Sources
- AWS Shared Responsibility Model
- AWS Artifact User Guide, What is AWS Artifact?
- AWS Config Developer Guide, Conformance Packs
- NIST SP 800-144, Guidelines on Security and Privacy in Public Cloud Computing
Last reviewed: 18 October 2026.
