Whether you’re handling sensitive client data or delivering critical digital services, demonstrating robust security, availability, and privacy practices is essential. For organisations running workloads on Amazon Web Services (AWS), SOC 2 compliance is a key tool in that trust arsenal.
SOC 2 in AWS is not a plug-and-play exercise. It’s a tailored, risk-driven approach to securing your cloud workloads. But with the right mix of AWS tools, internal policies, and ongoing governance, your organisation can meet the trust demands of clients, regulators, and business partners, without compromising on speed or scalability.
But while AWS might host your infrastructure, when it comes to SOC 2, much of the burden still lies with you.
What is SOC 2, and why does it matter?
SOC 2 (System and Organization Controls 2), governed by the American Institute of Certified Public Accountants (AICPA), is a voluntary compliance framework focused on five Trust Services Criteria (TSC): Security, Availability, Processing Integrity, Confidentiality, and Privacy. It’s especially relevant for service organisations storing customer data in the cloud.
SOC 2 reports come in two types:
- Type 1: Are the controls well-designed?
- Type 2: Are the controls both well-designed and operating effectively over time?
This framework isn’t prescriptive. It doesn’t provide a checklist—it asks you to interpret broad principles and prove that your controls work. That’s where AWS enters the story.
The shared responsibility model: Who owns what?
AWS describes cloud security as a “shared responsibility.”
- AWS secures the cloud: physical infrastructure, hypervisors, and data centre access.
- You secure what’s in the cloud: access management, workload configuration, data encryption, and incident response.
This shared model is the foundation for implementing SOC 2 in AWS environments. AWS provides security features, but customers must design, implement, and monitor their own controls, especially those tied to identity, data protection, and governance.
Translating SOC 2 into AWS reality
The core of the SOC 2 framework is the Common Criteria (CC1–CC9), which apply across all audits. Additional criteria (Availability, Processing Integrity, Confidentiality, Privacy) depend on your service commitments.
Control environment (CC1)
SOC 2 starts with tone from the top. It requires clearly defined responsibilities, ethical culture, and accountability mechanisms.
- AWS supports: IAM, IAM Identity Center, CloudTrail for auditing user activity.
- Your job: Assign access roles, monitor access logs, and enforce organisational policies using tools like AWS Config and SCPs (Service Control Policies).
Communication & information (CC2)
You must generate and share information to operate and control systems effectively.
- AWS supports: CloudTrail, AWS Config, CloudWatch metrics and alarms, Amazon SNS for alerts.
- You must: Establish internal incident communication plans, ensure clear job responsibilities, and monitor cloud activity centrally (e.g., via SIEM).
Risk assessment (CC3)
Organisations must assess internal and external risks, including fraud.
- AWS supports: Security Hub, Amazon Inspector, IAM Access Analyzer, GuardDuty.
- You handle: Defining risk scenarios, subscribing to threat intelligence feeds, and performing business impact assessments.
Monitoring activities (CC4)
Continuous monitoring is critical for detecting control failures or vulnerabilities.
- AWS supports: Inspector for vulnerability scanning, AWS Config for configuration drift detection, Security Hub for central issue tracking.
- You lead: Governance over monitoring practices, defining remediation processes, and running pen tests or red teaming where needed.
Control activities (CC5)
This covers the actual policies and procedures that mitigate risk.
- AWS supports: IAM role enforcement, automated compliance checks via AWS Config rules, and access reviews through Access Analyzer.
- Your role: Define and document how policies are enforced. Use AWS-native automation to bridge policy and practice.
Logical & physical access (CC6)
Controlling who gets access to what—physically and virtually—is foundational.
- AWS supports: IAM for logical access, KMS for encryption, Secrets Manager for credentials, VPC security groups for network isolation.
- AWS owns: Physical access controls (covered in AWS’s own SOC 2 Type 2 report).
- You must: Manage access credentials, define least privilege policies, enforce MFA, and protect external user devices.
System operations (CC7)
SOC 2 demands resilient operations, with monitoring and rapid incident response.
- AWS supports: GuardDuty for anomaly detection, Systems Manager Incident Manager, CloudWatch, and SNS for alerting.
- You own: Defining incident response runbooks, reviewing security events, and conducting readiness tests.
Change management (CC8)
You must manage infrastructure and software changes securely.
- AWS supports: Change Manager (in Systems Manager), CodePipeline, CloudFormation for infrastructure-as-code.
- You handle: Defining workflows, approvals, rollback plans, and documentation for all changes.
Risk mitigation (CC9)
SOC 2 expects you to prepare for disruption and manage third-party risks.
- AWS supports: Multi-AZ and Multi-Region deployments, AWS Backup, Elastic Disaster Recovery, Artifact for attestation reports.
- You should: Conduct business impact assessments, vendor reviews, and regularly test recovery plans.
Category-specific criteria: Going deeper
When your SOC 2 scope includes additional categories, here’s how AWS maps:
Processing integrity
- Ensure your systems produce valid, accurate outputs.
- Use: CloudTrail for logs, CloudWatch for monitoring, IAM for secure outputs.
Availability
- Design for uptime and disaster recovery.
- Use: Auto Scaling, Elastic Disaster Recovery, cross-region replication, backup policies.
Confidentiality
- Protect sensitive and proprietary data.
- Use: Amazon Macie for data discovery, KMS for encryption, S3 lifecycle rules for secure disposal.
Privacy
- Manage PII in compliance with data protection laws (e.g. GDPR).
- Use: IAM for access controls, Macie for PII detection, Shield/WAF for protection, and CloudTrail for auditability.
Evidence collection and audit readiness
SOC 2 isn’t just about having controls, it’s about proving they work.
- AWS provides: Logs, config snapshots, IAM reports, attestation reports.
- You must: Prepare audit trails, document policies, and collect screenshots or change logs to support audit testing.
Use tools like AWS Artifact, Config, and Security Hub to gather continuous assurance evidence, reducing the pain of point-in-time audit scrambles.
Key takeaways
- AWS provides a secure foundation, but SOC 2 compliance depends on how you configure, govern, and monitor your workloads.
- The Shared Responsibility Model is your map—understand what’s on you.
- Leverage native tools like IAM, Config, CloudTrail, Inspector, and GuardDuty to enforce and evidence controls.
- Implement strong internal governance to back up AWS technical controls.
- Treat audit readiness as a continuous discipline, not a once-a-year scramble.
