Understanding Shared Responsibility Models with Third-Party Providers

Key Takeaways

• You can outsource the work, but not the accountability. Using cloud or SaaS providers doesn't transfer your compliance obligations.
• Responsibility shifts by service type. EC2 requires you to patch the OS; Lambda doesn't. RDS manages database patching; self-managed PostgreSQL on EC2 doesn't.
• SaaS providers handle infrastructure, but you own configuration. Slack, GitHub, and Salesforce ship secure products, but misconfigured access controls are on you.
• SOC 2 and ISO 27001 auditors expect documented shared responsibility. Your compliance program should explicitly map what each provider handles vs. what you control.

Every B2B SaaS company relies on third-party providers. AWS hosts your infrastructure. Slack handles your internal communication. GitHub stores your source code. Salesforce manages your customer data.

But here's where most companies get it wrong: they assume their providers handle security comprehensively. They don't. Cloud and SaaS providers operate on a shared responsibility model, and misunderstanding this model is one of the most common causes of security gaps and compliance failures.

What Is the Shared Responsibility Model?

The shared responsibility model defines which security tasks your provider handles and which tasks remain your responsibility. It's a contract, often implicit, that divides accountability.

The core principle: providers secure the infrastructure; customers secure what runs on that infrastructure.

But the line shifts dramatically depending on whether you're using IaaS, PaaS, or SaaS. And within each category, the line shifts again depending on which specific service you choose.

Cloud Providers (IaaS): AWS, GCP, Azure

Infrastructure-as-a-Service gives you the most control and the most responsibility. You're essentially renting servers, and everything that runs on those servers is your concern.

What Cloud Providers Handle

• Physical security: Data center access controls, environmental protections, hardware disposal
• Hypervisor and virtualization layer: The software that creates and manages VMs
• Network infrastructure: Backbone connectivity, DDoS protection at the edge
• Availability zones and regions: Geographic redundancy and failover capabilities

What You Handle

• Operating system patching: When AWS releases a new AMI with security patches, you need to apply it
• Access control: IAM policies, role assignments, MFA enforcement
• Encryption: Enabling encryption at rest and in transit, managing keys
• Application security: Your code, dependencies, and deployment configurations
• Data classification: Knowing what data you store and where it lives
• Network configuration: Security groups, NACLs, VPC design

The Nuance: Responsibility Shifts by Service Type

This is where most companies get tripped up. The shared responsibility split isn't static, it varies by service type. Here's how it works using AWS as an example (GCP and Azure follow the same patterns with their equivalent services):

Virtual Machines (AWS EC2, GCP Compute Engine, Azure VMs)

• Provider: Hardware, hypervisor, physical network
• You: OS patching, middleware, application code, firewall rules, identity management, encryption configuration

Managed Databases (AWS RDS, GCP Cloud SQL, Azure SQL Database)

• Provider: Hardware, OS patching, database engine patching, automated backups
• You: Database configuration, access control, encryption settings, query security, data classification

Serverless Functions (AWS Lambda, GCP Cloud Functions, Azure Functions)

• Provider: Hardware, OS, runtime patching, scaling, availability
• You: Application code, function permissions, environment variables, function configuration, VPC/network settings when applicable

Managed Kubernetes (AWS EKS, GCP GKE, Azure AKS)

• Provider: Control plane, etcd management, Kubernetes version patching
• You: Worker node patching, pod security, network policies, RBAC, container images, secrets management
• Note: Using managed node pools or serverless containers (Fargate, GKE Autopilot, AKS virtual nodes) shifts worker node responsibility back to the provider

The pattern across all cloud providers: the more managed the service, the less you're responsible for infrastructure, but the more critical your configuration becomes.

Common Cloud Responsibility Mistakes

These mistakes apply across AWS, GCP, and Azure:

Mistake 1: Assuming object storage is private by default

AWS S3, GCP Cloud Storage, and Azure Blob Storage buckets are private by default, but policies and ACLs can override this. Misconfigured storage buckets have caused some of the largest data breaches in history. You own access policy configuration, logging, and encryption settings. Enable account-level public access blocks as an additional safeguard, demonstrating defense-in-depth.

Mistake 2: Neglecting firewall rules because "we're in a private network"

VPCs (AWS/GCP) and VNets (Azure) provide network isolation, but security groups and firewall rules define what traffic is allowed. Overly permissive rules (0.0.0.0/0 on SSH) are your misconfiguration, not the cloud provider's.

Mistake 3: Assuming managed services handle encryption

Managed databases across all providers support encryption at rest, but you often need to enable it explicitly. Many managed services require explicit encryption configuration. Default settings are often not the secure settings.

SaaS Providers: Different Model, Different Risks

SaaS flips the responsibility model almost entirely. The provider handles infrastructure, application code, patching, and availability. You have far less control, but you're still accountable for how you use the service.

What SaaS Providers Handle

• Application security: Code vulnerabilities, secure development practices
• Infrastructure: Servers, databases, networking, scaling
• Patching: OS, runtime, and application updates
• Availability: Uptime, disaster recovery, backups
• Compliance certifications: Their SOC 2, ISO 27001, and other audits

What You Handle

• Access management: Who has accounts, role assignments, MFA enforcement
• Configuration: Security settings, permissions, feature toggles
• Data classification: Understanding what data you're putting into the service
• User permissions: Who can see what, sharing settings, external access
• Integration security: API keys, webhooks, connected applications
• Offboarding: Removing access when employees leave

Real SaaS Examples

Slack

• Slack's responsibility: Message encryption, infrastructure security, uptime
• Your responsibility: Workspace access controls, guest management, DLP policies, retention settings, app integrations, channel visibility rules

GitHub

• GitHub's responsibility: Platform security, code storage, authentication infrastructure
• Your responsibility: Repository visibility (public vs. private), branch protection rules, required reviewers, secret scanning configuration, Actions permissions, team access controls

Salesforce

• Salesforce's responsibility: Application security, data center security, platform availability
• Your responsibility: Field-level security, sharing rules, profile permissions, login IP restrictions, session settings, connected app management

The SaaS Accountability Gap

Here's the trap: because SaaS providers handle so much, companies assume security is "taken care of." But SaaS misconfigurations cause breaches constantly.

A GitHub repository with disabled branch protection lets anyone push to main. A Salesforce sharing rule exposing customer data to the wrong roles. A Slack workspace where anyone can invite external guests.

Your provider ships a secure product. How you configure it is on you.

PaaS / Managed Services: The Middle Ground

Platform-as-a-Service sits between IaaS and SaaS. You deploy applications; the platform handles infrastructure.

Examples and Their Responsibility Splits

Heroku

• Heroku: Server management, OS patching, scaling, deployment infrastructure
• You: Application code, environment variables, add-on configuration, access control, data handling

Vercel

• Vercel: Edge network, build infrastructure, scaling, CDN
• You: Application code, environment secrets, team access, domain configuration

Supabase

• Supabase: PostgreSQL management, authentication infrastructure, real-time infrastructure
• You: Row-level security policies, API key management, auth configuration, database schema security

The pattern with PaaS: less infrastructure to manage, but security shifts to application configuration and access controls.

How Shared Responsibility Maps to SOC 2

SOC 2 audits evaluate your controls across Trust Services Criteria. When you use third-party providers, auditors want to see that you understand and have documented the shared responsibility split.

Relevant SOC 2 Criteria

CC6.1 (Logical Access Controls)
Your access controls extend to how you manage access to cloud and SaaS services. IAM policies, role assignments, and MFA enforcement are your controls, even when the underlying system is AWS or Salesforce.

CC6.6 (System Boundary Protection)
Network segmentation and access controls at system boundaries are shared responsibilities. Cloud providers give you VPCs and security groups; you configure and manage them. SaaS providers protect their network perimeter; you control access from your environment.

CC7.2 (Monitor System Components for Anomalies)
Monitoring and logging are shared responsibilities. Cloud providers offer audit logging (AWS CloudTrail, GCP Cloud Audit Logs, Azure Monitor); you need to enable it and actually review the logs. SaaS providers like Slack provide audit logs; you need to monitor them for suspicious activity.

CC8.1 (Changes to Infrastructure, Data, and Software)
If you deploy to managed services, your deployment security is still your responsibility. CI/CD permissions, environment variable handling, and infrastructure-as-code security are your controls.

CC9.2 (Risk Management for Vendors)
This is the explicit vendor management criterion. You need to evaluate providers, review their SOC 2 reports, and document how their controls complement yours.

What Auditors Expect

1. Vendor inventory: A list of all cloud and SaaS providers with data classification
2. Responsibility mapping: Documentation of what each provider handles vs. what you control
3. Evidence of provider due diligence: Reviewed SOC 2 reports, security questionnaires, BAAs where applicable
4. Complementary controls: Evidence that you've implemented controls on your side of the responsibility split

How Shared Responsibility Maps to ISO 27001

ISO 27001 Annex A includes explicit controls for supplier relationships. The 2022 revision strengthened these requirements.

Relevant ISO 27001 Controls

A.5.19 (Information Security in Supplier Relationships)
You must identify and document security requirements for suppliers who access, process, store, or provide infrastructure for your information assets.

A.5.20 (Addressing Security Within Supplier Agreements)
Contracts with suppliers should include security requirements, right-to-audit clauses, incident notification requirements, and termination provisions.

A.5.21 (Managing Information Security in the ICT Supply Chain)
This specifically addresses cloud providers and managed services. You need controls throughout the supply chain, not just with direct vendors.

A.5.22 (Monitoring, Review, and Change Management of Supplier Services)
Ongoing monitoring of supplier security, including reviewing their certifications, tracking security incidents, and managing changes to their services.

A.5.23 (Information Security for Use of Cloud Services)
Added in ISO 27001:2022, this requires specific controls for cloud service acquisition, use, management, and exit.

What ISO 27001 Auditors Expect

1. Supplier security policy: Formal policy addressing cloud and SaaS provider management
2. Risk assessment including suppliers: Your risk register should include risks from third-party dependencies
3. Contractual protections: Security requirements in contracts, DPAs, BAAs
4. Ongoing monitoring: Evidence of regular review of supplier security status

Practical Guidance: Documenting Shared Responsibility

Abstract understanding isn't enough. You need to operationalize shared responsibility in your compliance program.

Step 1: Create a Provider Inventory

List every cloud and SaaS provider, categorized by:

• Provider name and service type (IaaS, PaaS, SaaS)
• Data processed (customer data, employee data, system data, none)
• Business criticality (critical, important, low)
• Responsible team internally

Step 2: Map Responsibilities for Critical Providers

For each critical provider, create a responsibility matrix:

Step 3: Document Your Controls

For each area where you have responsibility, document:

• The specific control you've implemented
• Who owns it internally
• How it's monitored
• Evidence for auditors

Step 4: Review Provider SOC 2 Reports

When you receive a provider's SOC 2 report, look for:

• Scope: Which services are covered?
• Exceptions: Any qualified opinions or control failures?
• Complementary User Entity Controls (CUECs): What are you expected to do on your side?

CUECs are critical. They're the provider explicitly telling you what's your responsibility. Auditors will ask if you've implemented them. Maintain a CUEC tracking spreadsheet for each critical provider, documenting whether you've implemented each required control and the evidence that supports it.

Step 5: Update Annually

Cloud and SaaS providers change their services, add features, and update their security models. Review your responsibility mappings at least annually, or when you adopt new services. This annual review should also assess exit capabilities and data portability for critical providers, aligning with ISO 27001 A.5.23's cloud exit planning requirements.

What Goes Wrong: Real Examples

Example 1: The Capital One Breach

In 2019, Capital One suffered a breach affecting over 100 million customers. The attack chain: a server-side request forgery (SSRF) vulnerability in a misconfigured web application firewall allowed an attacker to query the EC2 instance metadata service and retrieve IAM credentials. Those credentials had overly broad permissions to S3 buckets containing customer data. AWS provided secure building blocks (IMDS, IAM roles, WAF capabilities). Capital One's configuration, the firewall rules, the overly permissive IAM role permissions, and not enforcing IMDSv2, created the vulnerability. Shared responsibility in action: AWS provides secure infrastructure; the customer's configuration determines the outcome.

Example 2: Exposed Elasticsearch Clusters

Hundreds of Elasticsearch databases have been exposed because companies deployed managed Elasticsearch without configuring authentication. The managed service provides the database; access control configuration is the customer's responsibility.

Example 3: GitHub Repository Leaks

Countless companies have leaked source code, credentials, and customer data through misconfigured GitHub repository visibility. GitHub provides fine-grained access controls. Using them is your responsibility.

The Bottom Line

Shared responsibility is not about absolving yourself of accountability. It's about understanding exactly where your obligations lie.

When you use any cloud provider, you inherit their physical security, but you own your identity and access policies. When you use Salesforce, you inherit their application security, but you own your sharing rules. When you use any third-party service, you inherit some protections and retain some obligations.

For SOC 2 and ISO 27001, this isn't abstract. Auditors expect you to have documented the split, implemented controls on your side, and monitored your providers' security posture.

The companies that handle this well don't assume their providers have everything covered. They know exactly what they own and act accordingly.

Bastion helps startups and SMBs achieve SOC 2 and ISO 27001 compliance, including documenting shared responsibility with your cloud and SaaS providers. Get started with Bastion →