5 AWS Compliance Concepts

AWS compliance programs

AWS compliance programs provide assurance about AWS-operated services and infrastructure. They do not, by themselves, establish that a customer's applications, data, or business processes comply with a law or standard. Customers need to understand the program, determine which responsibilities remain theirs, and gather evidence for both AWS-managed and customer-managed controls.

AWS groups compliance information into three broad categories:

• Certifications and attestations are independent assessments that result in certifications, audit reports, or attestations. Examples include ISO certifications and SOC reports.

• Laws, regulations, and privacy programs concern requirements that may apply to a customer's business or data. AWS may offer services, contractual terms, and other features to support customers, but customers remain responsible for determining and meeting applicable obligations.

• Alignments and frameworks provide mappings, guidance, or features related to published frameworks. An alignment does not necessarily mean AWS or a customer has been certified against that framework.

The services, Regions, and environments covered can vary by program. Verify that the AWS offering and scope match the intended use rather than relying on a program name alone.

Shared responsibility and control inheritance

The Shared responsibility model divides security between security of the cloud and security in the cloud. AWS operates and protects the underlying infrastructure, including facilities, hardware, networking, and the virtualization layer. Customers secure their workloads and configure the services they use; the details of this division vary by service.

For example, an EC2 customer manages the guest operating system and installed software. An abstracted service such as S3 reduces the customer's infrastructure-management burden, but the customer remains responsible for data, access permissions, and appropriate configuration.

The same division applies to compliance controls:

• Inherited controls: AWS operates the control, such as physical and environmental safeguards. A customer may rely on AWS evidence for the AWS portion, subject to the applicable program and scope.

• Shared controls: AWS and the customer each implement a related control in their own environment. AWS patches its infrastructure, for example, while the customer patches the guest operating systems and applications it manages.

• Customer-specific controls: The customer implements controls specific to its workload or organization, such as deciding who may access customer data, training employees, or enforcing application-level approval procedures.

For an application running on EC2 with records stored in S3, AWS infrastructure assurance can support evidence about the cloud infrastructure. The organization still needs to secure the EC2 operating system, set IAM and S3 permissions, decide how data is protected, and document its own operating procedures. A compliant AWS service does not make an insecure customer configuration compliant.

Evidence tools and governance

AWS Artifact provides on-demand access to AWS security and compliance documents, including reports and certifications. Customers can use relevant documents as evidence about AWS controls or as reference material when evaluating their own cloud architecture. Artifact also provides access to certain AWS agreements. Customers must obtain or produce evidence about their own organization and workloads.

AWS Audit Manager helps organize assessments and collect evidence from sources such as AWS Config, AWS Security Hub CSPM, and AWS CloudTrail. Evidence may include configuration snapshots, compliance-check results, and records of user activity.

Some evidence must be supplied manually, such as a written policy or proof that staff completed training. Automated evidence may demonstrate only part of a control's requirements, so collecting it does not necessarily establish that the entire control is satisfied.

Building a compliance evidence process

A practical governance process connects requirements to control owners, implementation, and evidence:

1. Identify applicable requirements and define the systems, accounts, services, and Regions in scope.

2. Break the requirements into controls and assign an owner for each control.

3. Record whether each control is inherited, shared, or customer-specific. Document assumptions and required customer actions.

4. Collect AWS evidence where applicable, then add customer evidence such as policies, approvals, procedures, and operational records.

5. Review findings, resolve gaps, and periodically confirm that scope, control implementation, and evidence remain current.

Use least-privilege IAM policies and appropriate role separation to govern who can change resources, manage assessments, and access evidence. This helps make control ownership and review responsibilities explicit.

Assessing evidence and limitations

For each requirement, identify the control objective, which party implements each part, which AWS services and resources are in scope, what evidence supports the control, and who reviews whether that evidence is sufficient. Check AWS program documentation for the exact service and scope, then assess the actual configuration and organizational processes against the requirement.

Treat evidence tools as aids, not compliance verdicts. AWS Audit Manager can collect and organize relevant evidence, but it does not assess whether an organization is compliant, may not collect every item an audit requires, and is not a substitute for legal counsel or compliance expertise. A passing automated check is evidence about the check it performed, not proof that every related legal or business requirement is satisfied.

AWS compliance programs provide assurance about defined AWS services and controls. Customers still need to verify scope, fulfill their own responsibilities, check evidence completeness, and determine which requirements apply.