SOC 2 Cloud Compliance On AWS: Key Requirements & Templates (2026)

Most enterprise procurement teams now require a proof of security before they will sign a contract. A single data‑handling misstep can derail months of sales effort; the average cost of a breach climbed to $4.88 million in 2024. For companies delivering software as a service (SaaS) to regulated sectors, security isn’t only about protecting data—it is about staying in deals and meeting contractual obligations. SOC 2 Cloud Compliance On AWS has become the most common way to provide third‑party assurance that your controls are operating effectively. This article explains what SOC 2 is, how Amazon Web Services (AWS) fits into the picture, how to map the Trust Services Criteria (TSC) to AWS‑native controls, and what Konfirmity’s managed service has learned from supporting more than six thousand audits.

Why enterprise clients demand assurance

Enterprise and healthcare buyers must manage substantial risk. According to IBM’s 2024 report, the average data breach cost increased by 26.4 % since 2020 and reached $4.88 million. Healthcare breaches cost even more. In addition to the direct losses, breaches trigger regulatory fines, litigation, and reputational damage. Large customers therefore insist on rigorous security assessments and require their vendors to produce attestation reports. Procurement questionnaires ask about encryption, access management, incident response, and data deletion. Without clear answers backed by evidence, deals stall.

SOC 2 was created by the American Institute of Certified Public Accountants (AICPA) to provide assurance that a service organization’s controls meet the TSC: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Enterprise clients choose SOC 2 because it is broad enough to address multiple risks yet flexible enough to apply to modern cloud architectures. However, the framework is intentionally broad, leaving organizations to design their own controls and produce evidence. This is where cloud providers like AWS and specialized service partners like Konfirmity play complementary roles.

Understanding SOC 2

SOC 2 is part of the AICPA’s System and Organization Controls suite. It is an examination performed by independent auditors that evaluates whether a service organization’s systems are designed and operating effectively to meet chosen categories of the TSC. The Security category is mandatory; the other four categories—Availability, Processing Integrity, Confidentiality, and Privacy—are optional and selected based on the services offered and customer commitments. The flexibility of SOC 2 allows technology companies, data processors, and infrastructure providers to craft a control set suited to their environments.

Trust Services Criteria

Each TSC is broken down into control objectives and points of focus that guide what auditors look for. For example:

• Security: protecting systems from unauthorized access; includes governance, risk assessment, access controls, system operations, and change management.
  
  
• Availability: ensuring the system is available for operation and use as committed or agreed.
  
  
• Processing Integrity: ensuring systems process data completely and accurately. AWS notes that its own SOC 2 scope does not include processing integrity, so customers must address this area themselves.
  
  
• Confidentiality: protecting information designated as confidential through classification, encryption, and access restrictions.
  
  
• Privacy: handling personal information in accordance with stated objectives and relevant regulations.

Type I vs. Type II

A Type I report evaluates the design of controls at a point in time, while a Type II report evaluates both design and operating effectiveness over a review period (commonly six to twelve months). Enterprise clients generally want a Type II report because it demonstrates that controls operated consistently. Achieving Type II readiness often requires implementing controls, collecting evidence over months, and undergoing an observation window. Compass IT Compliance notes that the observation period for Type II audits typically spans 6–12 months and that the full timeline to complete a Type II report may run 12–18 months. Type I reports can be completed faster, typically in 4–7 months, but offer less assurance. Konfirmity’s experience matches these ranges: we see self‑managed SOC 2 journeys taking nine to twelve months, while our managed approach often delivers Type II readiness in four to five months with around 75 hours of client effort.

Why buyers care

SOC 2 addresses several critical concerns for enterprise clients:

1. Data protection: confirms that technical and procedural controls protect data and systems.
   
   
2. Risk management: provides evidence of a risk‑based approach, vendor oversight, and incident response planning.
   
   
3. Assurance for regulators: helps demonstrate compliance with privacy laws (e.g., GDPR, HIPAA) and sector‑specific standards.
   
   
4. Procurement efficiency: reduces the number of custom security questionnaires and accelerates deal cycles.

In short, SOC 2 sets the expectation for how service providers protect data. For teams building on AWS, achieving SOC 2 Cloud Compliance On AWS means adapting these principles to a cloud‑native environment while still satisfying the rigor that auditors and enterprise buyers expect.

When a vendor can produce a clean SOC 2 Type II report, procurement teams often waive lengthy due‑diligence steps. Conversely, the absence of such assurance becomes a disqualifier.

AWS and SOC 2: understanding the partnership

When pursuing SOC 2 Cloud Compliance On AWS, teams must understand both what AWS covers and where their own responsibilities begin.

AWS compliance offerings

AWS publishes its own SOC 2 reports (Type II) covering the infrastructure and services it operates. These reports address the Security, Availability, and Confidentiality criteria and are available under non‑disclosure agreement through the AWS Artifact portal. AWS also offers a SOC 3 report—an attestation intended for general use and made public—to confirm that AWS has passed a SOC 2 examination. However, AWS’s scope does not include processing integrity, and the reports apply only to AWS’s managed services, not to customer workloads.

The shared responsibility model

The AWS shared responsibility model clarifies who is accountable for which controls. AWS states that “security and compliance is a shared responsibility between AWS and the customer”. AWS secures the physical facilities, network infrastructure, and virtualization layer, while customers are responsible for securing workloads within their accounts, including identity management, encryption, logging, and network configurations. The model can be summarised as follows:

• AWS responsibilities: physical security of data centers, hardware maintenance, hypervisor isolation, and compliance of managed services.
  
  
• Customer responsibilities: configuring IAM roles, encrypting data using services such as AWS KMS (customer‑managed encryption), setting up logging via CloudTrail and Config, managing backup schedules, and enforcing policies and reviews.

Complementary User Entity Controls (CUECs) appear in AWS’s SOC 2 report to remind customers that certain controls must be implemented for the AWS controls to be effective. Examples include managing IAM permissions, encrypting and backing up data, reviewing logs, and securing user devices. Understanding these boundaries is critical; many organizations mistakenly assume that AWS’s compliance automatically makes their applications compliant.

AWS’s new SOC 2 compliance guide

In July 2025, AWS published the AICPA SOC 2 Compliance Guide on AWS, a 73‑page whitepaper that demystifies SOC 2 for cloud customers. Centraleyes summarized the guide, noting that it “demystifies the process of achieving SOC 2 compliance … and provides practical advice on mapping the Trust Services Criteria to specific AWS services, such as IAM for access control, CloudTrail for auditing, and Macie for data classification”. The guide emphasises the shared responsibility model: AWS secures the underlying infrastructure, but customers must configure and manage their resources appropriately. With regulatory pressure increasing and clients demanding transparency, this guide provides a timely roadmap for organizations scaling in the cloud.

Mapping SOC 2 Trust Services Criteria to AWS controls

Implementing SOC 2 Cloud Compliance On AWS requires translating abstract principles into concrete actions. SOC 2 does not prescribe specific controls, but auditors expect you to design processes and technical measures that achieve the TSC objectives. Below, we translate the common SOC 2 control areas (CC1 through CC9 and the category‑specific criteria) into actionable tasks within AWS. For each area, we summarise what auditors look for and how Konfirmity implements controls using AWS services.

Control environment, governance, and risk (CC1–CC3)

Auditors begin by evaluating the control environment—the policies, procedures, and cultural factors that underpin security. They review board‑approved security policies, risk assessment methodologies, assignment of responsibilities, and governance structures. Risk assessments should cover threats specific to cloud environments, including misconfigurations, data exfiltration, and dependency on third‑party services. AWS advises customers to understand which TSC AWS helps address and which remain their responsibility.

Important actions include:

• Document a risk management policy that identifies threats, evaluates their impact, and assigns mitigation plans. Include vendor and sub‑processor risk reviews.
  
  
• Assign accountability by designating owners for security, privacy, availability, and incident response. Ensure the board or executive leadership reviews security performance regularly.
  
  
• Maintain an inventory of third‑party services (e.g., SaaS tools, payment gateways) and include them in risk assessments. Procurement should require SOC 2 or equivalent attestations from critical vendors.
  
  
• Harmonize control objectives across frameworks. Konfirmity often maps SOC 2 controls to ISO 27001, NIST SP 800‑53, or HIPAA safeguards to meet overlapping requirements without duplicating effort.

Access controls and identity management (CC6)

Logical and physical access are central to the Security criterion. AWS customers must configure access to their resources through AWS Identity and Access Management (IAM) and related services. Best practices include:

• Least‑privilege access: The Veza NIST compliance guide recommends restricting access to critical systems and data based on the principle of least privilege. Ensure that each IAM role grants only the permissions required for its tasks. Regularly review and adjust permissions to remove excess rights.
  
  
• Role‑based access and separation of duties: Create roles for administrators, developers, auditors, and service accounts. Avoid using root accounts for daily operations.
  
  
• Multi‑factor authentication (MFA): Enable MFA for all human users. For non‑human identities, use AWS roles and temporary security credentials. NIST guidance emphasises strong identification and authentication mechanisms.
  
  
• Encryption and key management: Use AWS KMS to manage cryptographic keys. Encrypt data at rest on Amazon EBS volumes, S3 buckets, RDS databases, and other storage. Encrypt data in transit via TLS.
  
  
• Data classification and confidentiality: Classify data based on sensitivity (e.g., public, internal, confidential, regulated). Apply appropriate encryption and access restrictions.

Konfirmity’s team performs quarterly access reviews, checks for unused IAM roles, and automates revocation of stale credentials. Our managed program includes continuous monitoring of CloudTrail logs to detect suspicious access patterns and automated alerting through Security Hub.

System operations, monitoring, and logging (CC4, CC7)

Auditors expect evidence that you monitor your environment, detect anomalous activity, and respond promptly. In AWS, this includes:

• Audit logging: Enable AWS CloudTrail to capture API calls, console logins, and changes to resources. Configure AWS Config to record configuration changes and evaluate them against rules. Retain logs for the period required by your audit (often at least twelve months).
  
  
• Continuous monitoring: Use services like AWS Security Hub, GuardDuty, and CloudWatch to aggregate findings, generate alerts, and trigger automated remediation workflows. Konfirmity integrates these tools to maintain a centralized view of security posture.
  
  
• Incident response: Maintain an incident response plan that defines escalation paths, communications, and documentation requirements. Regularly test the plan through tabletop simulations. Veza’s NIST guide emphasises the importance of a documented incident response plan.
  
  
• Data retention and audit trails: Define how long logs, configuration snapshots, and incident records are retained. Ensure that retention policies correspond with contractual and regulatory requirements.

Change management and risk mitigation (CC8, CC9)

Auditors look for evidence that changes to systems follow a documented process and that risks are reassessed periodically. Important practices include:

• Documented change requests and approvals: Use change tickets (e.g., in Jira) to record what is changing, why, who approved it, and when it was implemented. For infrastructure as code, use version control systems (e.g., Git) and pull‑request reviews.
  
  
• Environment segregation: Maintain separate development, staging, and production environments. Use different AWS accounts or resource tagging to enforce segregation.
  
  
• Rollback and backup strategies: Ensure that every deployment has a tested rollback plan. Use AWS Backup or snapshot policies to create restore points before major changes.
  
  
• Risk reassessment and vendor evaluations: Periodically review risk assessments and update them when there are significant changes (e.g., new services, acquisitions, expansions). Extend risk reviews to sub‑vendors.

Category‑specific criteria: Availability, Processing Integrity, Confidentiality, and Privacy

While the Security controls cover core governance and operations, category‑specific criteria require additional measures:

• Availability: Define uptime objectives (e.g., 99.9 %). Architect for redundancy across multiple Availability Zones and Regions. Use AWS Auto Scaling, Amazon RDS Multi‑AZ, and Amazon S3 cross‑region replication. Implement disaster‑recovery plans that include recovery time objectives (RTO) and recovery point objectives (RPO), and test them regularly.
  
  
• Processing Integrity: Ensure that applications process data accurately and completely. Implement input validation, error handling, and integrity checks. Because AWS’s SOC 2 scope excludes processing integrity, customers must implement application layer controls and maintain evidence of test results.
  
  
• Confidentiality and Privacy: Encrypt data at rest and in transit, classify personal data, and implement data minimisation. Maintain privacy policies that meet regulations such as GDPR and CCPA. Ensure that personal information is processed only for stated purposes and that data subjects can invoke their rights. Regularly purge data that no longer serves business or legal purposes.

Audit preparation and evidence gathering

Proper SOC 2 Cloud Compliance On AWS hinges on the quality of evidence. Auditors evaluate not only whether controls exist but whether they operated continuously throughout the review period. 

Once controls are designed and implemented, organizations must collect evidence. Auditors need documentation showing that controls existed (design) and operated consistently (operating effectiveness). Evidence sources include:

• Logs and configuration snapshots from CloudTrail, Config, and Security Hub showing changes, access attempts, and remediation actions.
  
  
• Policies and procedures: board‑approved security policies, risk assessments, access management procedures, incident response plans, and disaster‑recovery runbooks.
  
  
• Screenshots or reports from AWS services demonstrating configurations (e.g., KMS key policies, S3 bucket encryption settings).
  
  
• Change tickets and approvals: records of change management processes and segregation of duties.
  
  
• Third‑party attestations: SOC 2 reports from critical vendors and business associate agreements (BAAs) for HIPAA‑covered entities.

AWS’s whitepaper highlights the value of tools such as AWS Audit Manager, which offers a pre‑built SOC 2 framework and can automatically collect evidence from services like Config and Security Hub. However, many controls require manual evidence—for example, documenting risk assessments, training records, and vendor agreements. Konfirmity combines automated evidence collection with guided documentation to ensure completeness.

Timelines and observation periods

Audit readiness is not instantaneous. The preparation phase for a first‑time Type II audit typically runs two to four months, followed by an observation window of six to twelve months. During the observation period, auditors will expect to see consistent execution of controls—access reviews completed on schedule, backup logs matching policies, and incident response drills recorded. After the observation window, the auditor performs fieldwork and issues the report, which may take six to ten weeks. Planning for these timelines is critical; organizations that start too late often rush implementations and risk findings.

Konfirmity’s managed service compresses the timeline by providing ready‑made control libraries, automated evidence collection, and expert oversight. Our teams handle control implementation inside your AWS stack, perform continuous monitoring, and prepare evidence packages. Clients typically spend around 75 hours over the engagement, compared with 550–600 hours when self‑managed.

Challenges and common pitfalls on AWS

1. Complexity of AWS environments: AWS offers hundreds of services and thousands of configuration options. As companies scale across regions and accounts, keeping track of resources becomes difficult. Without centralized visibility, misconfigurations accumulate.
   
   
2. Misunderstanding shared responsibility: Some teams assume that because AWS has a SOC 2 report, their application is already compliant. In reality, AWS’s report covers the underlying infrastructure and does not extend to customer workloads.
   
   
3. Documentation fatigue: Organizations often underestimate the volume of documentation required—policies, risk assessments, training records, vendor agreements, and evidence of control execution. Manual processes become a bottleneck.
   
   
4. Scaling controls: As new accounts, microservices, and data stores are added, existing controls may not automatically extend. Maintaining least‑privilege across dozens of accounts, rotating keys, and ensuring consistent logging is labor intensive.
   
   
5. Continuous maintenance: SOC 2 is not a one‑time certification. Controls must operate year‑round. Regular policy reviews, quarterly access reviews, annual risk assessments, and continuous monitoring are required to avoid findings in renewal audits.

Practical templates and checklists

Konfirmity provides companies with practical tools to accelerate SOC 2 Cloud Compliance On AWS. These templates are based on lessons learned from thousands of audits and can be adapted to your environment.

SOC 2 readiness assessment checklist

• Scope definition: list the in‑scope systems, data flows, and third‑party services. Identify which TSC apply.
  
  
• Gap analysis: compare existing policies, controls, and evidence against the SOC 2 TSC and determine gaps.
  
  
• Control mapping: map each TSC requirement to AWS services and to existing controls (e.g., CC7.1 to CloudTrail and Config; CC6.2 to IAM roles and MFA).
  
  
• Remediation plan: define tasks to implement missing controls, with owners and deadlines.

AWS configuration checklist

• Identity and access: ensure all IAM users and roles have MFA; avoid long‑lived access keys; implement service control policies if using AWS Organizations.
  
  
• Logging: enable CloudTrail in all accounts; configure logs to be written to centralized, immutable storage; enable AWS Config rules for resource compliance.
  
  
• Encryption and key management: ensure KMS keys are customer‑managed for sensitive data; enable S3 default encryption; encrypt EBS and RDS.
  
  
• Backup and recovery: configure AWS Backup or snapshots; define retention schedules; test restoration procedures.
  
  
• Monitoring: enable GuardDuty, Security Hub, and CloudWatch alarms; integrate alerts with ticketing and incident response workflows.

Documentation templates

• Security policy: a broad policy approved by leadership outlining commitments to security, availability, confidentiality, and privacy.
  
  
• Access management policy: defines roles, access request processes, review cadence, and separation of duties.
  
  
• Change management policy: describes approval workflows, environment segregation, version control requirements, and emergency procedures.
  
  
• Disaster recovery and backup plan: outlines objectives, backup schedules, restoration procedures, and testing frequency.
  
  
• Vendor risk management policy: specifies how third‑party vendors are evaluated, monitored, and re‑assessed; includes requirements for SOC 2 reports or BAAs.
  
  
• Data classification and retention policy: defines categories of data, retention periods, and disposal methods.

Evidence‑collection tracker

Create a spreadsheet or use a tool to track evidence sources, including the control, description of evidence, location (e.g., log bucket path), date collected, and responsible party. This tracker should include automated evidence (logs, snapshots) and manual evidence (meeting minutes, training records). Konfirmity’s platform integrates this tracker into our managed workflow.

Audit‑readiness timeline

1. Preparation (0–2 months): scope definition, gap analysis, remediation plan, and initial policy drafting.
   
   
2. Implementation (2–4 months): deploy technical controls, finalize policies, conduct training, and set up monitoring.
   
   
3. Observation (3–12 months): operate controls consistently, perform quarterly reviews, and collect evidence.
   
   
4. Fieldwork (1–2 months): engage an independent CPA firm, provide evidence, respond to auditor inquiries.
   
   
5. Report issuance (0.5–1 month): auditor issues the SOC 2 report.

Strategic benefits for enterprise sellers

Investing in SOC 2 Cloud Compliance On AWS yields significant returns for companies targeting enterprise clients:

1. Trust and market access: A clean SOC 2 Type II report signals to buyers that your organization takes security seriously. It accelerates procurement, reduces the number of security questionnaires, and opens doors to regulated industries.
   
   
2. Regulatory fit: SOC 2 controls overlap with ISO 27001, HIPAA, GDPR, and NIST guidelines. By designing controls once and reusing evidence across frameworks, organizations reduce duplicated effort.
   
   
3. Operational resilience: Implementing least‑privilege, encryption, logging, and change management reduces the likelihood of incidents. Early detection and containment lower breach costs and demonstrate due diligence to regulators and insurers.
   
   
4. Reduced liability: Strong controls and vendor oversight reduce the risk of third‑party breaches. Customers expect vendors to manage sub‑processors; failing to do so invites legal exposure.
   
   
5. Scalable growth: A structured security program supports rapid onboarding of new customers, regions, and services. Controls scale across accounts, and continuous monitoring allows teams to grow without losing visibility.

Conclusion

SOC 2 is no longer optional for cloud vendors selling to enterprise and healthcare clients. The framework provides a structured way to demonstrate that your controls meet critical criteria for security, availability, processing integrity, confidentiality, and privacy. AWS offers a strong foundation, but the shared responsibility model makes it clear that customers must build and operate their own controls. The new AICPA SOC 2 Compliance Guide on AWS offers practical mappings from the abstract criteria to AWS services. Konfirmity goes further by implementing those controls inside your stack, monitoring them continuously, and preparing evidence for the auditor. From our experience across six thousand audits, durable security programs shorten sales cycles, reduce findings, and lower breach risks. 

SOC 2 Cloud Compliance On AWS is not optional; it is a prerequisite for trust. Consider compliance as an integral part of your architecture and operations. If you build a solid program and operate it daily, compliance follows.

Frequently asked questions

1. Does AWS’s SOC 2 report make my application compliant automatically? 

No. AWS’s SOC 2 Type II report covers the infrastructure and services AWS manages (e.g., data centers, network, hardware). Customers remain responsible for how they configure and use AWS services, including identity management, encryption, and logging. Therefore, your application still needs its own SOC 2 controls and evidence.

2. What is the difference between SOC 2 Type I and Type II? 

A Type I report evaluates whether controls are designed appropriately at a specific point in time. A Type II report assesses both design and operating effectiveness over an observation period (commonly six to twelve months). Enterprise buyers typically require Type II reports because they offer stronger assurance.

3. Which AWS services are most helpful for SOC 2 compliance? 

Important services include AWS IAM (identity and access control), AWS KMS (customer‑managed encryption), CloudTrail (audit logging), AWS Config (configuration monitoring), Security Hub (aggregated security findings), GuardDuty (threat detection), and AWS Audit Manager (evidence collection). These services help implement and document controls consistent with the TSC.

4. Do I need to assess sub‑vendors as part of SOC 2 compliance? 

Yes. Auditors expect you to perform vendor risk assessments and maintain evidence that critical vendors have appropriate security controls. This includes obtaining SOC 2 reports or equivalent assurances from sub‑processors and verifying that contractual commitments (e.g., BAAs) are in place.

5. How often must I renew SOC 2 compliance? 

SOC 2 reports typically cover a twelve‑month period. Organizations undergo annual audits to renew their attestation, though some choose shorter observation windows (e.g., three or six months) for initial reports. Renewal audits focus on whether controls operated consistently during the preceding period.

6. Does SOC 2 cover data privacy regulations such as GDPR or CCPA? 

SOC 2’s Privacy criterion addresses many data‑handling controls, but it is not a substitute for regulatory compliance. Organizations serving European or Californian residents must still comply with GDPR or CCPA requirements, which include specific provisions such as lawful basis for processing, consent, and data subject rights. Mapping controls across frameworks helps reduce duplication but does not replace legal obligations.

7. If I already follow ISO 27001 or NIST guidelines, will that help with SOC 2 compliance? 

Yes. Many controls overlap. For example, ISO 27001 requires an information security management system and risk assessments; NIST emphasises least‑privilege access and continuous monitoring. By mapping requirements across frameworks, you can reuse policies and evidence and streamline multiple certifications.

8. What documentation should I maintain to ensure audit readiness? 

Maintain board‑approved security policies, risk assessments, access management and change management procedures, incident response and disaster‑recovery plans, training records, vendor agreements, configuration evidence, logs, and meeting minutes. Keep an evidence tracker to record when and how evidence was collected and who is responsible.