Understand the AWS shared responsibility model and build a SOC 2-ready cloud environment without assuming AWS covers everything
Moving your application to AWS can reduce a large part of the infrastructure security burden, but it does not make your company SOC 2 compliant by default. This guide explains what AWS handles, what remains your responsibility, and how startup teams can build a practical SOC 2 compliance plan around their AWS environment.
Table of Contents
- Topic Introduction
- Why SOC 2 Compliance in the Cloud Matters
- How to Approach SOC 2 on AWS
- When to Start SOC 2 Planning
- Top 7 Areas of SOC 2 Ownership on AWS
- Conclusion
SOC 2 is about demonstrating that relevant controls are designed and operating effectively around areas such as security, availability, processing integrity, confidentiality, and privacy.
AWS provides a strong foundation for these controls and maintains its own independent SOC reports. However, AWS and your company have different responsibilities. AWS protects the infrastructure of the cloud, while you remain responsible for how you configure, operate, and secure the resources you use.
Understanding this boundary early helps you avoid a common mistake: assuming an AWS compliance report covers your application, employees, configurations, access policies, and operational processes.
Why SOC 2 Compliance in the Cloud Matters
- Customer requirements: Enterprise customers may ask for SOC 2 evidence before approving a vendor, especially when your product handles sensitive business information.
- Clear ownership: AWS manages parts of the underlying infrastructure, but your team still owns many application, identity, data, and operational controls.
- Audit preparation: Knowing which controls you own makes evidence collection and auditor discussions much easier.
- Reduced security gaps: Misconfigured IAM, excessive permissions, weak logging, and poor change management can remain your responsibility even when the underlying AWS infrastructure is secure.
- Better engineering discipline: SOC 2 requirements can help establish repeatable practices for access management, deployment, monitoring, incident response, and vendor management.
How to Approach SOC 2 on AWS
The AWS shared responsibility model divides security into two broad areas. AWS is responsible for security “of” the cloud, while customers are responsible for security “in” the cloud. The exact customer responsibilities vary according to the AWS services being used.
| Area | AWS Handles | Your Team Owns |
|---|---|---|
| Physical infrastructure | Data centers, physical facilities, hardware | Selecting appropriate AWS services and configurations |
| Core infrastructure | AWS infrastructure, networking, virtualization, and managed service foundations | Your cloud architecture and resource configuration |
| Identity | Security capabilities provided by AWS IAM and related services | Users, roles, permissions, MFA, access reviews |
| Data | Infrastructure supporting AWS storage and database services | Data classification, encryption configuration, retention, access |
| Application security | Security of AWS-managed infrastructure | Application code, dependencies, vulnerabilities, secrets |
| Monitoring | AWS security and monitoring capabilities | Enabling logs, reviewing events, alerts, and responding to incidents |
| Change management | AWS changes to its infrastructure | Your deployments, code changes, infrastructure changes, approvals |
| Compliance evidence | AWS compliance reports and documentation | Your policies, procedures, control evidence, and audit activities |
AWS also publishes which services are included within specific compliance programs. Using an AWS service that is listed in scope does not automatically make your own workload compliant.
When to Start SOC 2 Planning
| Stage | What to Do | Recommended Focus |
|---|---|---|
| Before building | Define security requirements | Data, users, environments, access |
| Early development | Establish baseline controls | IAM, logging, encryption, backups |
| Before enterprise sales | Perform a gap assessment | Policies, evidence, access reviews |
| Audit preparation | Formalize control ownership | Documentation, testing, evidence |
| During audit period | Operate controls consistently | Reviews, approvals, monitoring |
| After audit | Maintain controls continuously | Access changes, incidents, evidence |
Starting after your first enterprise customer asks for SOC 2 can create unnecessary pressure. Building basic controls while the product and AWS environment are still evolving is usually easier than retrofitting them later.
Top 7 Areas of SOC 2 Ownership on AWS
1. Identity and Access Management
AWS provides IAM and related identity capabilities, but your organization decides who should have access and what they can do.
- User access: Define who can access production systems and business applications.
- Least privilege: Give users and workloads only the permissions they require.
- MFA enforcement: Require multi-factor authentication for appropriate accounts.
- Role management: Use controlled roles instead of broad administrator access.
- Access reviews: Periodically review employees, contractors, and service accounts.
- Offboarding: Remove or modify access promptly when people leave or change roles.
2. Data Protection and Encryption
AWS provides encryption features across many services, but your team must decide how those features are configured and used.
- Data classification: Identify sensitive, confidential, and public information.
- Encryption at rest: Configure encryption for relevant storage and databases.
- Encryption in transit: Use TLS for data moving between systems.
- Key management: Control access to encryption keys and related services.
- Data retention: Define how long different categories of information are retained.
- Data deletion: Establish processes for securely removing unnecessary data.
3. Logging and Monitoring
AWS provides services that can generate security and operational telemetry. Your responsibility is to configure the right sources and use the information effectively.
- Centralized logging: Collect relevant logs in controlled locations.
- Audit trails: Enable appropriate API and administrative activity logging.
- Alerting: Create alerts for important security and operational events.
- Log protection: Restrict who can modify or delete audit records.
- Log retention: Define retention periods based on business and compliance needs.
- Review process: Establish who investigates alerts and how findings are documented.
4. Application and Vulnerability Management
AWS secures its underlying infrastructure, but your application code remains your responsibility.
- Dependency scanning: Identify vulnerable libraries and packages.
- Code review: Require appropriate review before production changes.
- Security testing: Test applications for relevant security weaknesses.
- Secret management: Avoid storing credentials directly in source code.
- Patch management: Track and address operating system and dependency risks.
- Production controls: Restrict direct changes to production environments.
5. Change Management
SOC 2 is not only about preventing unauthorized access. Your organization also needs a controlled way to make changes.
- Approval workflow: Define who can approve production changes.
- Version control: Keep application and infrastructure changes in controlled repositories.
- Deployment records: Maintain evidence of what changed and when.
- Separation of duties: Avoid concentrating development and production privileges unnecessarily.
- Rollback plans: Maintain practical procedures for reversing failed changes.
- Emergency changes: Document and review changes made during incidents.
6. Incident Response and Business Continuity
AWS provides infrastructure designed for resilience, but your organization still needs its own response and recovery procedures.
- Incident plan: Define how security incidents are identified and escalated.
- Ownership matrix: Assign clear responsibilities during incidents.
- Communication process: Establish internal and customer communication procedures.
- Backup strategy: Configure backups based on application recovery requirements.
- Recovery testing: Test whether backups and recovery procedures actually work.
- Post-incident review: Document findings and track corrective actions.
7. Policies, Evidence, and Vendor Management
Technical controls are only part of SOC 2. Your organization also needs documented processes and evidence showing that controls operate consistently.
- Security policies: Document rules for access, security, data, and operations.
- Control owners: Assign a responsible person for each important control.
- Evidence collection: Store records that demonstrate controls were performed.
- Vendor reviews: Assess relevant third-party providers and services.
- Employee training: Provide appropriate security and compliance training.
- Control testing: Regularly verify that controls work as intended.
Conclusion
SOC 2 compliance in the cloud is a shared responsibility, but the responsibilities are not equal or interchangeable. AWS provides the secure infrastructure foundation and compliance evidence for its services, while your team owns the configuration, application, identity, data, monitoring, processes, and evidence around your workload.
If your startup is preparing for SOC 2, Signiance Technologies can help assess your AWS environment, identify control gaps, and build the cloud and DevOps controls needed for a more audit-ready environment.