AWS SOC 2 Controls: What to Configure and Document

Running on AWS does not make you SOC 2 compliant. AWS holds its own SOC 2 report for the infrastructure it operates. Your auditor will still test the controls you run on top of it: who can log in, what gets logged, how data is encrypted, how incidents are handled and how changes reach production. This guide separates what AWS covers from what you own. It maps the controls to AWS services and shows how to collect evidence without a scramble at audit time.

TL;DR

• AWS's SOC 2 report covers AWS's own environment. Your report covers your system, so your AWS configuration and your written procedures are in scope.
• Start with a baseline of Security Hub, AWS Config, CloudTrail, GuardDuty, IAM Access Analyzer and Macie across every account.
• AWS Audit Manager's prebuilt SOC 2 framework automates 15 controls and leaves 46 manual, so plan for documents as well as settings.
• SOC 2 is an attestation, not a certification. A Type 2 opinion depends on controls operating consistently over a period, not on a snapshot.

Table of Contents

• What AWS covers and what you still own
• How the Trust Services Criteria translate to AWS
• The baseline AWS security services to turn on
• Using AWS Audit Manager for SOC 2 evidence
• Type 1 or Type 2 on AWS
• Cutting audit fatigue with common controls
• Our perspective: where AWS SOC 2 projects go wrong
• Getting audit-ready: a 90-day sequence
• How CISOSafe helps
• FAQ
• Sources

What AWS covers and what you still own

AWS describes its SOC reports as independent third-party examinations that show how AWS achieves key compliance controls. Its SOC 2 examination measures controls against the AICPA Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality and Privacy. AWS reporting periods run 12 months, ending March 31 or September 30.

You can download those reports from AWS Artifact and hand them to your auditor. They answer the question "Is the data center secure?" They do not answer "Does this company grant production access only to the right people?"

The split follows the AWS shared responsibility model:

Auditors call the AWS report a "carve-out" or complementary subservice organization evidence. You cite it for the infrastructure layer and test everything above it yourself.

How the Trust Services Criteria translate to AWS

The AICPA SOC 2 guide on AWS organizes the criteria into the Common Criteria (CC1 through CC9) plus category-specific criteria for Availability, Processing Integrity, Confidentiality and Privacy. It maps each criterion to AWS services. Security, through the Common Criteria, is the only mandatory category. The others are added based on what you promise customers.

A practical working map looks like this. These are typical pairings, not a substitute for your auditor's view of your system.

Notice how many rows lean on documents. The technical rows are the easy part to automate. The governance rows are where first-time audits stall.

The baseline AWS security services to turn on

AWS's Security Reference Architecture describes a baseline of security services across all accounts in a multi-account environment. For SOC 2 purposes, six matter most:

1. AWS CloudTrail. Logs management events across the organization. It is your primary evidence for CC6 and CC7: who did what, and when. Send logs to a separate, locked-down account.
2. AWS Config. Evaluates resource configuration continuously and keeps history. This is what lets you show that encryption, public access blocks and security group rules held throughout the audit window, not only on the day you checked.
3. AWS Security Hub. Centralizes findings. Its control reference lists the available controls, and it supports the CIS AWS Foundations Benchmark, a common starting standard for account hardening.
4. Amazon GuardDuty. Threat detection that feeds your monitoring and incident response evidence.
5. IAM Access Analyzer. Flags resources shared outside your account or organization, and supports access review work.
6. Amazon Macie. Finds sensitive data in S3, which helps with Confidentiality and Privacy scoping.

The same AWS guidance stresses defense in depth. Turning a feature on is not enough. Layer the controls: IAM for authentication, Config for monitoring, CloudTrail for logging. A gap in one is then caught by another.

Access controls auditors test first

CC6 produces more findings than any other area. Before the audit window opens, confirm these:

• MFA is enforced for every human user, with no long-lived access keys on the root account.
• Access is granted through roles or an identity provider, not shared credentials.
• Permissions follow least privilege and are reviewed on a schedule you can prove. Our user access review checklist shows what a defensible review record contains.
• Offboarding removes access within a defined time, and you can show tickets for sampled leavers.
• Data is encrypted at rest and in transit, with key policies restricted to named roles.

Auditors sample. If they pick five terminated employees, you need five clean records, not four.

Using AWS Audit Manager for SOC 2 evidence

AWS Audit Manager provides a prebuilt SOC 2 framework with 15 automated controls and 46 manual controls across 20 control sets. It maps your AWS resource configurations to AICPA requirements and collects evidence continuously. The feature overview explains how prebuilt frameworks link IT controls to data sources, which cuts the effort of interpreting technical detail.

The 46 manual controls matter as much as the 15 automated ones. Audit Manager cannot verify that your incident response plan exists, that it was tested or that access reviews were completed. You upload that evidence yourself. The teams that pass cleanly treat the tool as one portal for both kinds of evidence, so the auditor receives one organized package.

A practical rhythm:

1. Create the SOC 2 assessment in Audit Manager and scope it to the accounts that hold production systems and customer data.
2. Assign each manual control to a named owner, not a team.
3. Set a monthly calendar reminder to upload evidence while it is fresh.
4. Review the automated evidence for failures weekly and fix findings before they become exceptions.

For an example of how evidence is organized by item, see this checklist of SOC 2 evidence items for a CRM platform. The system differs from yours, but the habit of tying each control to a specific artifact applies anywhere.

Type 1 or Type 2 on AWS

A Type 1 report tests whether controls are designed appropriately at a point in time. A Type 2 report tests whether they operated effectively across a period. Buyers in enterprise procurement increasingly ask for Type 2, but a Type 1 can unlock a deal sooner. Our guide on when SOC 2 Type 1 works versus Type 2 walks through that decision.

On AWS, the Type 2 requirement is where Config history and CloudTrail retention pay off. If you cannot show that a control held in month three of the window, the auditor cannot either.

The AICPA is explicit that SOC 2 is an examination and report on controls, not a certification you receive once. Treat compliance as ongoing. Our guide to continuous compliance monitoring covers how leadership can keep visibility between audits.

Cutting audit fatigue with common controls

Many companies face SOC 2 alongside PCI DSS, HIPAA or customer-specific questionnaires. Collecting separate evidence for each is wasteful. The AWS Audit Manager common controls library helps governance, risk and compliance teams map enterprise controls once for evidence collection. A single control, such as encryption at rest, can then support requirements in more than one framework.

The same logic applies outside the tool. Write one control statement, attach one body of evidence and map it to every framework that asks. Our compliance mapping guide shows how, and the SOC 2 control matrix guide lists the fields a matrix should carry.

Our perspective: where AWS SOC 2 projects go wrong

We work with regulated organizations, including law firms, energy operators and compliance-sensitive mid-market companies. The pattern in cloud-based SOC 2 work is consistent: the technical controls are rarely the obstacle. Teams that already use CloudTrail, Config and IAM sensibly can show most of CC6 and CC7 with modest cleanup.

The obstacles are elsewhere:

• No owner. Policies exist, but nobody is accountable for the quarterly review, so evidence has gaps.
• Scope drift. A new AWS account or a new vendor appears mid-window and is never added to the system description.
• Evidence at the end. Screenshots gathered in the final two weeks produce rework. Evidence gathered monthly does not.
• Treating AWS's report as your own. It supports your audit. It does not replace it.

Our view is that SOC 2 should be run as a security program with an audit at the end, not an audit project with a program bolted on. That is the reason we pair strategic vCISO leadership with a platform that handles intake, assessment and reporting. Leadership gets a clear view of risk, and the technical team is not buried in paperwork.

— vCISO

Getting audit-ready: a 90-day sequence

If you are starting from a typical AWS environment, this order avoids the most rework:

1. Days 1 to 15: scope. List the AWS accounts, services, data types and vendors in your system. Decide which Trust Services categories you will include.
2. Days 15 to 40: baseline. Enable the six services above in every account, centralize logs and remediate high-severity Security Hub findings.
3. Days 40 to 60: policies and ownership. Draft or update the information security, access control, change management, incident response and vendor management policies. Assign owners.
4. Days 60 to 75: gap assessment. Run Audit Manager against your scope and compare it with your manual control list. Close gaps or document compensating controls.
5. Days 75 to 90: readiness review. Test incident response with a tabletop exercise, complete a first access review and choose your auditor and report type.

The timeline varies with company size and existing maturity. Treat it as a planning frame rather than a promise. For a wider view of the process, read SOC 2 compliance explained for business leaders. Law firms handling client data can start with our SOC 2 guide for law firms.

How CISOSafe helps

CISOSafe is a Houston-based virtual CISO firm with an AI-powered platform for regulated industries. For SOC 2 on AWS we offer security risk assessments, policy and controls development, compliance program management and audit and certification readiness. Those cover the manual controls most teams underestimate, as well as the strategy and board-level reporting around them. See the full list of vCISO and compliance services, or start at cisosafe.com to discuss your environment.

FAQ

Does AWS's SOC 2 report make my company SOC 2 compliant?

No. The AWS report covers AWS's own control environment and is available through AWS Artifact. Your auditor examines your system, including how you configure and operate AWS services. You can cite the AWS report for the infrastructure layer.

Which AWS services produce the most SOC 2 evidence?

CloudTrail, AWS Config and IAM produce the bulk of technical evidence for access, change and monitoring criteria. Security Hub and GuardDuty add monitoring and detection evidence. Audit Manager can collect and organize it against the SOC 2 framework.

Can AWS Audit Manager automate all SOC 2 controls?

No. Its prebuilt SOC 2 framework includes 15 automated controls and 46 manual ones. Manual controls, such as incident response plans and access review records, need documents uploaded by your team.

Is SOC 2 a certification?

No. According to the AICPA, SOC 2 is an examination in which an independent CPA reports on your controls against the Trust Services Criteria. You receive a report with an opinion, not a certificate, and customers expect it to be renewed regularly.

Do I need all five Trust Services categories?

No. Security is required, and you add Availability, Processing Integrity, Confidentiality or Privacy based on your commitments to customers. Adding categories widens scope and cost, so include only those your customers rely on.

Sources

• AWS SOC Compliance FAQs
• AICPA SOC 2 Compliance Guide on AWS (AWS Security Blog)
• AWS Security Reference Architecture
• Control reference for Security Hub CSPM
• CIS AWS Foundations Benchmark in Security Hub CSPM
• SSAE-18 SOC 2 in AWS Audit Manager
• AWS Audit Manager features
• AWS Audit Manager common controls library
• AICPA SOC 2 for service organizations

Recommended

• SOC 2 Readiness: Control Matrix Fields Mapped to AICPA for U.S. Teams
• SOC 2 Compliance Explained for Business Leaders
• SOC 1 and SOC 2: Which Report Does Your Organization Need?
• Close U.S. Deals in 60 Days: When SOC 2 Type 1 Works vs Type 2