Many software-as-a-services (SaaS) companies rely on Amazon Web Services (AWS) as the backbone of their infrastructure—and for good reason. AWS’s robust physical, network, and operational controls offer a strong foundation for building secure, scalable systems. But having AWS controls in place is not the same as demonstrating to your auditor that your controls meet the SOC 2 criteria. Control mapping is key to making that connection.
In this article, we’ll explore how AWS controls intersect with SOC 2, how to document inherited vs. customer-implemented controls, and how to streamline your compliance process while building stakeholder trust.
What Is SOC 2? Why It Matters
SOC 2 is a framework developed by the American Institute of Certified Public Accountants (AICPA) to assess data security to build and maintain trust with stakeholders. SOC 2 is based on five Trust Services Criteria (TSC):
SOC 2 is particularly important for Software-as-a-Service (SaaS) providers and other service organizations handling sensitive data. It provides assurance to current and potential stakeholders that your systems and data are secure and reliable.
AWS & the Shared Responsibility Model
Before diving into control mapping, it’s essential to understand the AWS Shared Responsibility Model, which outlines the division of security tasks between AWS and the customer:
- AWS is responsible for the security “of” the cloud — this includes physical infrastructure, networking, and managed services.
- You (the customer) are responsible for the security “in” the cloud — this includes data, configurations, IAM, and application-level controls.
Your SOC 2 audit focuses on your organization’s responsibilities. Some controls may be inherited from AWS, while others must be implemented and managed by you as the customer.
How AWS Supports Your SOC 2 Journey
AWS provides several resources and tools that help with SOC 2 compliance, including:
- AWS Artifact: Access to AWS’s own compliance reports, including their SOC 1, SOC 2, and ISO 27001 certifications.
- AWS Well-Architected Framework: Best practices for secure workloads.
- AWS Security Tools: For monitoring and compliance automation.
- AWS Control Tower: Multi-account setup with security guardrails.
These resources don’t make you SOC 2 compliant out of the box, but they provide the building blocks to implement and demonstrate your security controls.
Step-by-Step: Mapping AWS Controls to SOC 2
The following steps outline a practical approach for aligning AWS services and configurations with SOC 2 TSCs to support a successful audit.
1. Determine Applicable TSCs
Start by determining which TSCs apply to your organization. Security is mandatory, but others depend on your services and customer expectations. The full set of SOC 2 control criteria and points of focus can be downloaded from the AICPA website.
2. Perform a Gap Analysis
Compare your AWS setup with SOC 2 requirements and security best practices. Tools such as AWS Security Hub, AWS Trusted Advisor, and AWS Config can identify misconfigurations and areas for improvement.
Build a control matrix that includes:
- SOC 2 criteria
- Your internal controls
- Supporting AWS controls (service or feature)
- Evidence source (e.g., AWS logs, screenshots, policies)
3. Map AWS Services to SOC 2 Controls
The following are some examples of AWS services mapped to typical SOC 2 controls:
-
- CC4.1, CC7.1, & CC7.2 (Security Event Monitoring): Use AWS CloudTrail for activity audit logging, Amazon CloudWatch to configure alert thresholds for anomalous activity, Amazon Inspector to perform automated, continuous vulnerability scanning, and Amazon GuardDuty for threat detection. Set up automated alerting and response playbooks.
- Identity & Access Management (IAM)
-
- CC6.1 & CC6.2 (Logical Access): Use IAM roles, policies, and MFA to enforce least privilege access and secure identity management. Regularly perform access reviews and, if possible, implement automated provisioning/deprovisioning using IAM or SSO integrations.
- Data Encryption
- Infrastructure Security
-
- CC6.6 & CC7.1 (External Threats): Use Amazon Inspector for continuous scanning on EC2 instances and containers for vulnerabilities and demonstrate remediation efforts. Configure VPC rules to implicitly deny and only allow specific IP ranges (e.g., corporate IPs) or known services via specific ports to prevent unauthorized traffic.
- Backups & Recovery
-
- CC7.5, A1.2, & A1.3: Establish automated backups for all critical systems and perform regular restore tests. Define your RTO and RPO objectives and make sure they align with availability requirements.
- Risk Mitigation
-
- CC9.1 & CC9.2: Include a review of AWS’s Type II SOC 2 report as part of your vendor due diligence. Understanding AWS’s controls helps you identify which responsibilities are inherited and which ones you must implement and monitor yourself, and provides assurance that AWS has designed and operated effective controls.
Even though AWS provides powerful monitoring tools to assist in SOC 2 compliance, it is ultimately your responsibility as the customer to properly configure, monitor, and maintain these tools to meet your organization’s security and compliance obligations. Tools that are enabled but not used meaningfully or monitored are unlikely to pass as effective controls.
4. Document the Controls & Evidence
Auditors will request evidence showing that your AWS environment is configured securely and operates effectively. Documentation examples include:
- Monitoring reports with configured thresholds, alerting, and responses
- Screenshots of IAM policies and permissions
- Encryption settings
- Security group configurations and VPC rules
- Backup schedules, retention, and restore tests
- Third-party reviews, including AWS SOC 2 reports
Your documentation should clearly explain how you’re using AWS’s tooling and what you’re doing on your end to meet the TSC.
5. Integrate AWS Control Mapping Into Your Security Program
Instead of treating SOC 2 as a one-time project, organizations should include AWS control mapping into their ongoing security operations and governance framework. This not only prepares you for future audits but also improves your overall risk posture. Here’s how to make it part of your ongoing workflow:
- Operationalize Your Control Matrix: Instead of a static spreadsheet, integrate your control mappings into agile project management tools like Jira or Confluence for live tracking and ownership.
- Automated Alerts & Remediation: Use AWS Config and AWS Security Hub to trigger alerts when configurations drift from your compliant baseline.
- Periodic Reviews: Treat SOC 2 control mappings like security policies—schedule periodic reviews and updates as your architecture evolves.
- Training & Awareness: Make sure DevOps and engineering teams understand how their AWS usage affects compliance.
- Control Ownership: Assign specific team members or roles to each mapped control to ascertain accountability and readiness for audits.
By integrating AWS-based controls into your day-to-day processes, your organization stays audit-ready while enhancing cloud governance and security posture.
From Mapping to Momentum: Operationalizing SOC 2 in AWS
Mapping AWS controls to SOC 2 requirements is about aligning responsibilities and demonstrating control effectiveness. While AWS provides a secure foundation for the cloud infrastructure, it’s up to your organization to configure those services appropriately—and to show evidence that the controls are working as intended. By understanding the SOC 2 requirements, using AWS tools strategically, and maintaining well-organized documentation, you can streamline the audit process and reinforce trust with stakeholders.
Maintaining SOC 2 compliance is not a one-time event—it’s an ongoing journey. Leveraging AWS correctly is not just about passing the audit; it’s about operationalizing security and governance as part of a resilient, cloud-based infrastructure.
Want to learn more about how your AWS environment aligns with SOC 2 requirements? Feel free to contact us if you would like additional guidance specific to your environment, or for any of our external auditing services at Linford & Company.
Danielle has over 16 years of information systems auditing experience. Prior to starting at Linford & Company, Danielle worked at PricewaterhouseCoopers in their Systems and Process Assurance group followed by the Internal Audit Department of a financial services company and the IT Compliance group for a large healthcare organization. She has experience in IT general control reviews, SOC audits, HIPAA compliance, Sarbanes-Oxley section 404 attestation engagements, and Payment Card Industry Data Security Standards (PCI DSS) compliance. Danielle is a Certified Information Systems Auditor (CISA) and received her Bachelor of Science degree in Management Science & Information Systems from Penn State University.