SOC 2 Shared Responsibility Model: Key Requirements & Templates (2026)

Most enterprise buyers demand proof of security controls before they sign a contract. They read audit reports, send detailed questionnaires, and ask to see policies and logging evidence. Teams that rely on promises of strong security without evidence find deals stalled. Those that adopt a SOC 2 Shared Responsibility Model – a clear boundary between what the cloud provider secures and what your team controls – build solid systems, generate continuous evidence, and move procurement forward. This article gives a practitioner’s view on SOC 2, explains why shared responsibilities matter, and provides templates and tips for staying audit‑ready.

What Is SOC 2? The Basics

SOC 2 is an audit standard created by the American Institute of Certified Public Accountants (AICPA). Unlike a certificate, a SOC 2 report is an attestation that a service provider has controls in place to meet selected Trust Services Criteria: security, availability, processing integrity, confidentiality, and privacy. Security is always mandatory; the other four criteria are scoped based on customer commitments.

The security criterion establishes the foundation for any SOC 2 examination. It maps to nine common criteria covering control environment, information and communication, risk assessment, monitoring, control activities, logical and physical access, system operations, change management, and risk mitigation. An auditor assesses whether policies exist, controls operate over a specified observation period, and evidence supports each control point.

Availability focuses on uptime and the ability to provide services when needed. Processing integrity ensures that systems process data in a complete, valid, accurate, and timely way. Confidentiality addresses the protection of sensitive customer or business information from unauthorized disclosure. Privacy covers the collection, use, retention, disclosure, and disposal of personal information.

In practice, SOC 2 has become a de facto requirement for SaaS companies selling to enterprise and regulated industries. Buyers use SOC 2 reports to judge whether vendors can handle their data responsibly. The standard’s alignment with the COSO internal control framework — with components such as control environment, risk assessment, control activities, information and communication, and monitoring — reassures internal and external stakeholders that controls follow an accepted risk management framework. As CTOs and CISOs know, passing a SOC 2 Type II audit demands months of evidence and continuous monitoring, but the resulting attestation helps shorten sales cycles and builds trust.

What Is a Shared Responsibility Model?

Public cloud providers changed how companies build and deliver software. They host computer, storage, and networking resources that customers can rent on demand. To protect these multi‑tenant environments, cloud providers developed a shared responsibility model. The concept divides security tasks between the provider (“security of the cloud”) and the customer (“security in the cloud”). Understanding this split is essential for SOC 2 compliance because it clarifies which controls can be inherited from the provider and which ones your team must implement.

A good example comes from AWS. According to cloud experts, AWS is accountable for securing the physical infrastructure that supports its services. That includes data centres, hardware, networking equipment, and the virtualization layer. AWS invests heavily in physical access controls, biometric authentication, redundant power and environmental protections, and hypervisor isolation technologies like the Nitro System. These efforts form the security of the cloud.

Customers, on the other hand, are responsible for securing what they build within the provider’s infrastructure. They must encrypt data, manage access, configure networks, patch operating systems, set firewall rules, monitor logs, and respond to incidents. This set of tasks constitutes security in the cloud. Cloud providers supply tools and guidance, but customers must apply them correctly. For example, AWS offers Key Management Service (KMS) and CloudHSM for encryption, identity solutions through AWS Identity Center and multi‑factor authentication, and logging via CloudTrail, CloudWatch, GuardDuty, and Security Hub. Yet customers must configure and operate these tools to meet their own control objectives.

The shared responsibility model isn’t unique to AWS. Microsoft Azure, Google Cloud, DigitalOcean, and other providers publish similar matrices. Each splits responsibilities based on the service type (IaaS, PaaS, SaaS) and expects customers to secure workloads and data.

Why Shared Responsibility Matters for SOC 2

Many companies mistakenly think that choosing a SOC 2‑compliant cloud provider makes them SOC 2‑compliant. It doesn’t. Secureframe explains that using a provider like AWS does not automatically make your organization SOC 2 compliant. The provider’s SOC 2 report demonstrates that they have strong controls for the infrastructure and services they manage. However, your organization is still responsible for securing applications and data, managing user access, implementing encryption and logging, defining policies, and responding to incidents.

Auditors expect to see evidence of both provider‑owned controls and customer‑owned controls. The provider’s SOC 2 Type II report covers physical security, environmental controls, hypervisor security, and service management. But your audit scope will include Complementary User Entity Controls (CUECs)—controls that your provider assumes you will implement. Secureframe notes that providers rely on customers to enforce strong password policies, review access rights, and configure offered security settings. If those CUECs are not implemented, the service provider’s controls may not function as intended.

Understanding the shared responsibility model helps you map SOC 2 controls correctly. It identifies which controls can be inherited from your provider, which are shared, and which are solely your team’s responsibility. Without this clarity, teams either duplicate controls unnecessarily or overlook critical gaps that auditors will flag.

Finally, the model underscores that compliance is continuous. Using a provider’s SOC 2 report supports your audit, but you must generate your own evidence—access reviews, logs, risk assessments, and incident response records—over the observation period.

Breaking Down Responsibilities

Provider (Cloud) Responsibilities

• Infrastructure security – Providers secure the hardware, facilities, and network under their control. In AWS’s case, this includes 24/7 surveillance, biometric access controls, uninterruptible power supplies, and waterless fire suppression systems. Providers also protect networking and hardware through custom silicon and advanced routing protocols.
• Physical data centres – Providers restrict physical access to data centres. They manage facility security, environmental controls, and supply chain integrity. Customers cannot visit or audit these facilities directly; instead, they rely on provider audit reports such as SOC 2, ISO 27001, and others.
• Networking and hardware – Providers design and maintain the network infrastructure. For example, AWS uses the Nitro System for hardware isolation and invests in DDoS protection through AWS Shield Advanced.
• Managed service compliance documentation – Providers publish compliance reports for customers to inherit. AWS’s SOC 2 Type II report, for instance, covers the period from April 1, 2024 to March 31, 2025. The report includes Complementary User Entity Controls that customers must address. Similar attestation documents exist for ISO 27001, HIPAA, PCI DSS, and other standards.

Customer Responsibilities

• Access controls and identity management – Customers must define and enforce who can access systems, what privileges they have, and when access should be revoked. That includes using strong authentication, role‑based access, and periodic access reviews.
• Data protection and encryption – Customers classify data based on sensitivity and apply appropriate encryption at rest and in transit. They control encryption keys using KMS or external hardware security modules.
• Logging, monitoring, and reporting – Customers need to enable logging for all critical systems and store logs securely. They should integrate logs into monitoring tools and create alerts for anomalies.
• Security policies and governance – A written information security policy sets expectations across the organization. Policies should cover acceptable use, incident reporting, access management, change management, and vendor risk. Governance includes assigning a security officer, establishing committees or working groups, and reporting to the board.
• Incident response planning – Customers must prepare for incidents by defining how to detect, respond, recover, and communicate. Evidence might include runbooks, contact lists, post‑incident reports, and exercises.
• Vendor management – Customers evaluate and monitor third‑party vendors that access sensitive data. They review vendor SOC 2 reports, security questionnaires, and contractual clauses such as Data Processing Addendums (DPAs) or Business Associate Agreements (BAAs) for HIPAA.

Shared Controls

Some responsibilities are shared between the provider and the customer. Patch management is a common example. AWS patches the infrastructure and hypervisor, while customers must patch their operating systems and applications. Similarly, providers maintain the physical network, but customers configure security groups and network access control lists. Logging is another shared area: providers log platform events, but customers must retain and review logs to meet evidence requirements. Recognizing shared controls ensures that both parties contribute to a control’s effectiveness.

Mapping Shared Responsibilities to SOC 2 Controls

SOC 2 audits evaluate controls within the trust services criteria. Mapping the shared responsibility model to these criteria clarifies who owns each control and what evidence is required.

Security Controls

Identity and access management – Under the security criterion, auditors expect evidence that only authorized personnel can access systems. For cloud services, this means combining provider features (e.g., AWS Identity Center, Single Sign‑On) with your own policies. Customers should document account provisioning, access reviews, multi‑factor authentication, and least‑privilege enforcement.

Encryption and configuration baselines – The provider offers encryption mechanisms and baseline configurations. Customers must implement them correctly and document their use. For instance, enabling server‑side encryption for Amazon S3, using envelope encryption for sensitive keys, and applying hardened operating system images.

Firewalls and segmentation – Providers maintain network isolation at the hypervisor. Customers configure virtual networks, security groups, and firewall rules to restrict traffic. Evidence could include network diagrams, configuration snapshots, and change records.

Data Confidentiality & Protection

The confidentiality criterion focuses on protecting sensitive or proprietary data. Customers classify data, assign retention requirements, and apply encryption. Providers supply physical and logical safeguards but have no visibility into the data classification. Evidence might include data classification policies, encryption key management procedures, and results from encryption key rotation.

System Availability

Availability controls address uptime, capacity planning, and disaster recovery. Providers deliver redundancy and resilient infrastructure; AWS invests in multiple availability zones and global regions, offering high availability and failover capabilities. Customers must design architectures to use these features (e.g., multi‑AZ deployment) and monitor performance. Evidence includes disaster recovery plans, results of failover tests, and capacity monitoring dashboards.

Risk Management

The SOC 2 security criterion includes risk assessment and mitigation. The COSO framework emphasizes control environment, risk assessment, control activities, information and communication, and monitoring. Customers must run periodic risk assessments, identify threats, and decide on mitigation strategies. Providers contribute by supplying compliance reports and vulnerability notifications. Evidence might consist of risk registers, assessments, treatment plans, and documentation showing how provider reports inform internal risk decisions.

Practical SOC 2 Templates

Successful audits depend on well‑organized evidence and clear documentation. The following templates help structure responsibilities and prepare for assessments.

Responsibility Matrix Template

A Responsibility Matrix lists each control or activity against provider, customer, or shared ownership. Use a table to indicate who does what. For example:

This matrix clarifies responsibilities and helps auditors understand inherited controls and CUECs.

Policy Templates

Policy documents must be actionable and aligned with the SOC 2 criteria. Suggested policies include:

• Access Control Policy – Defines user roles, authentication methods, password requirements, account provisioning/de‑provisioning, and regular reviews.
  
  
• Incident Response Plan – Outlines detection, response, recovery, and post‑mortem steps. It lists contact roles, escalation paths, communication procedures, and evidence retention guidelines.
  
  
• Data Classification Policy – Categorizes data (e.g., public, internal, confidential), assigns handling requirements, and defines encryption protocols.

Each policy should assign a responsible owner, specify review frequency (e.g., annually), and reference the relevant trust services criteria.

Audit Readiness Checklist

Preparing for a SOC 2 audit requires gathering documents and ensuring controls are operating. A checklist might include:

• Scope definition (systems, locations, services).
  
  
• Updated organization chart and role descriptions.
  
  
• Risk assessment reports and treatment plans.
  
  
• Evidence of security training and awareness.
  
  
• Access control records (provisioning, de‑provisioning, reviews).
  
  
• Change management tickets and approvals.
  
  
• Incident response logs and post‑mortem reports.
  
  
• Vendor management files (questionnaires, SOC reports, contracts).
  
  
• Continuous monitoring outputs (vulnerability scans, patch reports, log summaries).
  
  
• Provider compliance reports (e.g., AWS SOC 2 Type II, ISO 27001 certificates).

The checklist ensures all required evidence is available before the audit begins.

Vendor Management Worksheet

Enterprise organizations rely on many vendors. A Vendor Management Worksheet helps track vendor compliance obligations and integration points. Include fields such as:

• Vendor name and contact.
  
  
• Services provided.
  
  
• Data classification (e.g., personal data, payment data, healthcare data).
  
  
• Frameworks in scope (SOC 2, ISO 27001, HIPAA, GDPR, PCI DSS).
  
  
• Contractual obligations (DPA, BAA, SLA).
  
  
• Audit evidence received (SOC 2 report, ISO certificate, penetration test).
  
  
• Security questionnaire status.
  
  
• Next review date.

Maintaining this worksheet supports vendor risk management (CC9.2) and helps demonstrate that third‑party risks are assessed and mitigated.

Tips for Audit Readiness

Use provider SOC 2 reports strategically – Leverage your provider’s SOC 2 Type II report to inherit controls and support your evidence. For example, AWS’s report covers physical security, environmental protection, and service management. Provide these documents to your auditors so they can focus on your unique controls.

Implement continuous monitoring – Configure tools for vulnerability scanning, patch management, and log analysis. Automate alerts and integrate them into ticketing systems. Continuous monitoring provides ongoing evidence and reduces the risk of evidence gaps during the observation period.

Establish internal review cadences – Schedule regular control reviews: monthly access reviews, quarterly vulnerability management meetings, and annual policy reviews. Document these activities and store evidence centrally. Regular reviews prove to auditors that controls are operating as designed.

Plan observation periods – SOC 2 Type II audits cover a period of three to twelve months. Start collecting evidence early and ensure controls operate consistently throughout. If you make changes mid‑period, maintain change logs and test new controls.

Engage experts – Managed security providers like Konfirmity bring expertise from thousands of audits. They embed dedicated personnel who design controls, implement them in your stack, and handle evidence collection. Our team has supported over 6,000 audits and brings more than 25 years of combined technical experience. We often reduce internal effort from hundreds of hours to about 75 hours per year by managing policies, monitoring, and audits end to end. We implement controls once and operate them daily, so you stay audit‑ready without overburdening engineers.

Common Mistakes to Avoid

Assuming provider compliance covers everything – Providers secure the infrastructure, but you must secure your applications and data. Failing to implement CUECs can lead to audit findings.

Neglecting internal policy and documentation – Auditors need to see written policies, evidence of approval, and periodic reviews. Missing or outdated documents indicate weak governance.

Ignoring evidence retention – Collect logs, tickets, and reports and store them for the entire observation period. Evidence gaps cannot be filled retroactively.

Underestimating time and effort – SOC 2 Type II readiness often takes four to five months of preparation and another six months for the observation period. Self‑managed programs can stretch to nine to twelve months. Engage early and dedicate resources to avoid delaying enterprise deals.

Conclusion

Clear boundaries between provider and customer responsibilities are critical for security and compliance. The SOC 2 Shared Responsibility Model translates abstract cloud responsibilities into concrete controls and evidence. Teams that document responsibilities, implement appropriate controls, and collect continuous evidence build trust with enterprise buyers and pass audits more efficiently. Adopting a human‑led, managed security approach allows you to focus on product innovation while experts handle control design, monitoring, and audits. Security that works only on paper is a liability; build a program that survives incidents, audits, and due diligence.

FAQ: Key Questions Answered

1) What are the five principles of SOC 2?

SOC 2 uses the AICPA Trust Services Criteria: security, availability, processing integrity, confidentiality, and privacy. Security is mandatory; the other four apply depending on commitments and services.

2) What is a shared responsibility model?

A shared responsibility model divides security and compliance tasks between the cloud provider and the customer. The provider secures the infrastructure — data centres, hardware, networking, and hypervisor — while the customer secures their workloads, data, and configurations, including access controls, encryption, and monitoring.

3) What is the SOC 2 framework?

SOC 2 is an AICPA audit framework that evaluates a service provider’s controls against selected trust services criteria. It relies on the COSO internal control framework’s components — control environment, risk assessment, control activities, information and communication, and monitoring — and covers both design and operating effectiveness over an observation period.

4) What is the COSO framework for SOC 2?

The COSO Internal Control–Integrated Framework outlines five components: control environment, risk assessment, control activities, information and communication, and monitoring activities. SOC 2 adopts these components in the common criteria, and auditors evaluate whether an organization applies them to meet the trust services criteria. By following COSO, organizations establish a solid control environment, assess risks, implement controls, share information, and monitor performance — all essential for a successful SOC 2 program.