SOC 2 Common Controls: Shared Responsibility in Service Organizations

The conference room went silent. The CTO of a promising SaaS startup had just asked their auditor a seemingly simple question: "If our cloud provider has SOC 2, doesn't that mean we're covered?"

The auditor's response was swift and sobering: "Not even close."

I've witnessed this exact scenario at least thirty times in my career. It's the moment when organizations realize that security compliance isn't something you can completely outsource—even when you're using fully managed services. This misunderstanding about shared responsibility has derailed more SOC 2 audits than any other single issue.

Let me share what I've learned about common controls, complementary controls, and why understanding the boundary between them can make or break your SOC 2 journey.

The Wake-Up Call That Changed Everything

Back in 2020, I was consulting with a healthcare technology company preparing for their first SOC 2 Type II audit. They were confident. They'd chosen reputable vendors—AWS for infrastructure, Auth0 for authentication, Datadog for monitoring. Each vendor had SOC 2 reports. They assumed they were golden.

Three months before their planned audit, we did a gap assessment. The results were shocking. They had:

• No evidence of reviewing vendor security controls

• No monitoring of their own application-level access controls

• No incident response procedures beyond "call AWS support"

• No data backup testing (they relied entirely on AWS snapshots)

• No change management process for application updates

"But our vendors are SOC 2 compliant!" the CTO protested.

That's when I had to explain the harsh reality: Your vendors' SOC 2 reports don't transfer to you. They describe what the vendor does. You still need to prove what YOU do.

"SOC 2 compliance isn't a relay race where you hand off responsibility. It's more like a relay race where everyone runs the entire track together—each in their own lane."

Understanding Common Controls: The Foundation

Let me break this down in a way that finally made sense to that healthcare tech company (and hopefully to you).

Common controls are security controls implemented by a service organization (like your cloud provider, SaaS vendor, or hosting company) that support not just their own security, but also the security of their customers. These controls are "common" because multiple customers benefit from them simultaneously.

Think of it like living in a high-rise apartment building. The building has:

• Lobby security guards (physical access control)

• Fire suppression systems (environmental protection)

• Backup generators (availability)

• Structural integrity (physical security)

These are common controls—the building provides them, and all tenants benefit. But here's the critical part: you're still responsible for locking your own apartment door, not leaving windows open, and not storing flammable materials on your balcony.

Common Controls in Action: Real-World Examples

Let me show you what this looks like in practice:

That table represents real scenarios from audits I've been involved in. The pattern is clear: vendors provide the tools, you provide the discipline.

The Shared Responsibility Model: Decoded

After years of explaining this concept, I've developed a framework that finally clicks for people. I call it the Three Layers of Responsibility:

Layer 1: Infrastructure (Mostly Common Controls)

This is where your vendors do the heavy lifting:

My Hard-Learned Lesson: In 2019, a client's application went down because they deployed everything in a single availability zone. AWS's infrastructure was 100% operational. But the client hadn't implemented basic architectural redundancy. Their auditor noted this as a control deficiency in availability criteria.

The client argued, "But we use AWS! They have 99.99% uptime!"

The auditor's response: "AWS offers the tools for high availability. You chose not to use them. That's on you."

Layer 2: Platform (Split Responsibility)

This is where things get tricky:

Real Story: I worked with a payment processor in 2021 who'd been using their cloud provider's logging service. Excellent choice. But when the auditor asked for evidence of security monitoring, they had none. They were collecting logs but never looking at them.

"We have logs!" they insisted.

"Having logs without reviewing them is like having a security camera that nobody watches," the auditor replied. "It's not a control—it's data storage."

They spent six months implementing proper log monitoring before they could pass their audit.

Layer 3: Application (Mostly Your Responsibility)

This is your domain, and where most organizations struggle:

"Your vendors can give you the world's best security tools. But if you don't configure them properly, monitor them actively, and respond to their alerts, you're just renting expensive decorations."

The Complementary Controls Nightmare

Let me tell you about the phrase that strikes fear into every service organization's heart: "complementary user entity controls."

In your vendor's SOC 2 report, buried somewhere in the description of controls, you'll find statements like:

"The effectiveness of this control is dependent upon complementary user entity controls being in place at customer organizations, including but not limited to..."

Translation: "We did our part. Now you need to do yours."

A Real SOC 2 Report Analysis

I recently reviewed a major cloud provider's SOC 2 report with a client. Here's what we found:

Total remediation time: Six months of work they thought they didn't need to do.

This is why reading your vendor's SOC 2 report isn't optional—it's critical. Every complementary control mentioned is something you'll need to demonstrate in YOUR audit.

The Common Controls Mapping Framework

After helping dozens of organizations navigate this complexity, I've developed a practical framework for mapping responsibilities. Here's how it works:

Step 1: Inventory Your Service Providers

Create a comprehensive list:

Pro Tip: I once found a client using 23 different SaaS tools, and they'd only reviewed SOC 2 reports for 4 of them. We discovered three vendors had NO security certifications. They had to replace those vendors before they could proceed with their audit.

Step 2: Extract Complementary Controls

Go through each vendor's SOC 2 report and document every complementary control. Here's a template I use:

Step 3: Map to SOC 2 Trust Services Criteria

This is where it all comes together. For each TSC, identify the control split:

The Pattern: The higher up the stack you go (from infrastructure to application), the more responsibility shifts to you.

Common Pitfalls I've Seen (And How to Avoid Them)

Pitfall #1: "Our Vendor is SOC 2, So We're Good"

The Scenario: A marketing automation company built their entire platform on Heroku. When asked about infrastructure controls, they simply referenced Heroku's SOC 2 report.

The Problem: They had no evidence of:

• Application-level security controls

• Secure coding practices

• Application monitoring

• Incident response procedures

The Fix: They needed to implement a complete application security program—something that took 8 months and delayed their own SOC 2 certification.

My Advice: Think of vendor SOC 2 reports as covering the foundation of your house. You still need to build the walls, roof, and interior.

Pitfall #2: Not Reading the Fine Print

The Scenario: A fintech startup assumed their database provider handled all backup responsibilities.

The Problem: The vendor's report clearly stated: "Customers are responsible for initiating backups, testing restore procedures, and maintaining backup retention policies."

The Result: During the audit, they couldn't provide evidence of backup testing. They'd never actually restored from a backup. Ever.

The Fix: They had to establish backup testing procedures and wait 6 months to accumulate evidence of consistent testing.

"Reading your vendor's SOC 2 report isn't homework—it's a blueprint for what you still need to build."

Pitfall #3: Ignoring Configuration Responsibilities

Here's a table of the most common configuration failures I encounter:

Real Story: In 2022, I worked with a healthcare app that had accidentally made an S3 bucket containing patient health information publicly accessible. Their infrastructure provider (AWS) had done nothing wrong—they'd configured S3 to allow the option of public access.

The company had chosen that setting. That was 100% their responsibility.

They discovered this during a pre-audit assessment. If it had been found during the actual audit, they would have failed immediately. We spent three weeks proving the data hadn't been accessed, implementing proper access controls, and documenting remediation steps.

Building Your Shared Responsibility Matrix

Here's the practical framework I use with every client. This is your homework:

The Master Responsibility Matrix

How to Use This Matrix

1. For each row, assign clear ownership: Don't leave anything in limbo. If it's shared, document who does what.

2. Define verification methods: How will you prove this control exists and operates effectively?

3. Set evidence collection frequency: Auditors need to see consistency over time. One screenshot from last year won't cut it.

4. Assign responsible parties: Every control needs an owner who'll be accountable during the audit.

The Complementary Controls Checklist

Based on analyzing hundreds of vendor SOC 2 reports, here are the complementary controls you'll almost certainly need to implement:

Universal Complementary Controls (Required for 99% of Organizations)

• [ ] User Access Management

  • Documented user provisioning/deprovisioning process

  • Quarterly access reviews with evidence

  • Principle of least privilege enforcement

  • Approval documentation for access requests

• [ ] MFA Enforcement

  • MFA enabled for all users

  • No exceptions without documented business justification

  • Regular compliance monitoring

  • Authentication logs retained per policy

• [ ] Configuration Management

  • Documented baseline configurations

  • Change control procedures

  • Configuration drift monitoring

  • Regular configuration reviews

• [ ] Log Management

  • Logs exported from vendor platforms

  • Retained per your retention policy (usually 1 year minimum)

  • Regularly reviewed for security events

  • Integrated into your SIEM or log analysis tool

• [ ] Backup Verification

  • Quarterly restore testing

  • Documented restore procedures

  • RTO/RPO defined and tested

  • Backup monitoring and alerting

• [ ] Vulnerability Management

  • Application-level vulnerability scanning

  • Patch management for your code and dependencies

  • Remediation within defined SLAs

  • Vulnerability tracking and reporting

Frequently Overlooked Complementary Controls

Let me share the ones that consistently catch organizations by surprise:

A Real SOC 2 Audit Story: Learning the Hard Way

Let me tell you about an audit that went sideways, and the lessons we learned.

In 2023, I was advising a Series B SaaS company through their first SOC 2 Type II audit. They were six months in, feeling confident. Then the auditor asked to see evidence of their database backup restore testing.

"We use MongoDB Atlas," the CTO said. "They handle backups."

The auditor pulled up MongoDB Atlas's SOC 2 report and read aloud: "MongoDB Atlas provides automated backup capabilities. Customers are responsible for initiating backups, testing restore procedures, and validating backup integrity."

The room went quiet.

They'd been running on MongoDB Atlas for two years. They had never once tested restoring from a backup. They weren't even sure how to initiate a backup—they'd assumed it was automatic.

We had to:

1. Document backup procedures (2 weeks)

2. Implement automated backup initiation (1 week)

3. Perform test restores and document results (ongoing)

4. Wait 3 months to accumulate quarterly evidence

5. Repeat the restore test to show consistency

Their Type II audit got delayed by 6 months. The cost? About $120,000 in delayed revenue from enterprise deals that required SOC 2.

The CTO told me afterward: "I thought reading vendor SOC 2 reports was the auditor's job. Turns out it's mine."

"The most expensive words in SOC 2 compliance are: 'I assumed our vendor handled that.'"

How to Actually Read a Vendor SOC 2 Report

Most people receive a vendor's SOC 2 report and either:

1. Don't read it at all

2. Skim the first few pages

3. File it away "for compliance"

None of these approaches work. Here's my systematic approach:

The 7-Section Review Method

Section 1: Report Type and Period (5 minutes)

• Type I or Type II? (You want Type II)

• How long was the audit period? (12 months is ideal)

• When was the report issued? (Should be recent)

Section 2: Trust Services Categories (10 minutes)

• Which categories are included? (Security is mandatory, others are optional)

• Why does this matter to you?

Section 3: Management's Assertion (15 minutes)

• What is the vendor claiming about their controls?

• Are there any scope exclusions?

• What's explicitly NOT covered?

Section 4: System Description (30 minutes)

• What infrastructure do they use?

• What are their dependencies?

• How does data flow through their system?

Section 5: Control Objectives and Tests (60 minutes) This is where you find complementary controls. Look for phrases like:

• "Customers are responsible for..."

• "Requires complementary user entity controls..."

• "Customers must implement..."

• "Customer configuration of..."

Create a list of every complementary control mentioned.

Section 6: Testing Results (30 minutes)

• Were there any exceptions or deviations?

• How did the vendor address them?

• Are any exceptions relevant to your use case?

Section 7: Complementary User Entity Controls (45 minutes) This section explicitly lists what YOU need to do. Copy every single item. These will become part of YOUR control documentation.

Total Time Investment: About 3 hours per vendor report. Cost of Not Doing It: Potentially 6-12 month audit delays and six-figure revenue impacts.

Building Your Common Controls Documentation

Here's the documentation structure that's passed audits for my clients:

Document 1: Vendor Risk Assessment

Document 2: Complementary Controls Matrix

For each vendor with a SOC 2 report, document:

Vendor: AWS
Service: EC2, S3, RDS
SOC 2 Report Date: October 2024
Report Review Date: November 15, 2024
Reviewer: [Security Team Lead]

Document 3: Shared Responsibility Model

Create a visual that maps the split:

The Questions Your Auditor Will Ask

Let me save you some pain. Here are the exact questions auditors ask about common controls, based on my experience:

Round 1: Vendor Management Questions

1. "Do you maintain a list of all service providers who process or store sensitive data?"

2. "Have you reviewed the SOC 2 reports for all critical vendors within the past 12 months?"

3. "How do you identify complementary controls required by your vendors?"

4. "Can you show evidence of implementing these complementary controls?"

What They're Really Asking: Do you actually know who your vendors are and what they require of you?

Round 2: Implementation Questions

5. "Your cloud provider offers MFA. Show me evidence that you've enabled and enforced it."

6. "Your database provider offers encryption. Show me your encryption configuration and key management procedures."

7. "Your vendors retain logs for 90 days. Show me how you retain logs for your required retention period."

8. "Your infrastructure provider offers backup capabilities. Show me evidence of backup testing."

What They're Really Asking: Did you actually do the work, or just pay for the tools?

Round 3: Consistency Questions

9. "You showed me evidence from November. Now show me evidence from February, May, and August."

10. "This process document says quarterly reviews. Show me four quarters of reviews."

11. "Your access review found three issues. Show me evidence of remediation."

What They're Really Asking: Is this real, or did you fake it for the audit?

My 90-Day Common Controls Implementation Plan

Based on successfully guiding organizations through this process, here's a realistic timeline:

Days 1-30: Discovery and Documentation

Week 1-2: Vendor Inventory

• List all service providers

• Obtain current SOC 2 reports

• Identify vendors without SOC 2 reports

• Assess alternatives for non-compliant vendors

Week 3-4: Report Analysis

• Read each vendor's SOC 2 report

• Extract all complementary controls

• Create a master list of your responsibilities

• Identify gaps in current implementation

Days 31-60: Implementation

Week 5-6: Quick Wins

• Enable MFA where it's not enforced

• Configure encryption where it's not enabled

• Set up log forwarding to your SIEM

• Document existing processes that aren't written down

Week 7-8: Procedural Controls

• Create access review procedures

• Establish backup testing schedule

• Implement change management process

• Document incident response procedures

Days 61-90: Evidence Collection and Testing

Week 9-10: Evidence Collection

• Generate first round of evidence

• Test that evidence collection processes work

• Identify gaps in evidence quality

• Refine collection procedures

Week 11-12: Validation

• Perform mock audit of common controls

• Have internal team review evidence

• Address any deficiencies found

• Begin accumulating ongoing evidence

Timeline Reality Check: This is the minimum. Many organizations need 6-12 months to fully implement all complementary controls, especially if they've never done it before.

The Bottom Line: Shared Responsibility in Practice

After fifteen years and dozens of SOC 2 audits, here's what I know for certain:

Common controls from vendors are powerful—but they're only half the equation.

Your vendors can provide world-class infrastructure security. They can offer sophisticated encryption, comprehensive logging, and robust backup systems. But they can't:

• Decide who in your organization should have access to what

• Determine how you classify and handle sensitive data

• Configure your applications to use security features properly

• Monitor your logs and respond to security events

• Test your disaster recovery procedures

• Manage your vendor relationships

That's all on you.

"Vendors provide the security building blocks. You provide the architecture, the construction, and the ongoing maintenance. Both are equally critical."

Your Action Plan: Starting Today

If you're preparing for SOC 2, here's what to do right now:

This Week:

1. List every vendor that processes or stores sensitive data

2. Request current SOC 2 reports from all critical vendors

3. Schedule time to read each report thoroughly

4. Identify vendors without SOC 2 (start replacement planning)

This Month:

1. Extract all complementary controls from vendor reports

2. Create your master responsibility matrix

3. Conduct gap assessment against current state

4. Prioritize implementation based on audit timeline

This Quarter:

1. Implement critical complementary controls

2. Document all processes and procedures

3. Begin evidence collection

4. Perform internal assessment

This Year:

1. Maintain consistent evidence collection

2. Conduct regular access reviews

3. Test disaster recovery procedures

4. Prepare for your SOC 2 audit with confidence

A Final Story: Getting It Right

I want to end on a positive note. Last year, I worked with a fintech startup that took shared responsibility seriously from day one.

Before choosing any vendor, they:

• Requested SOC 2 reports

• Analyzed complementary control requirements

• Assessed their ability to meet those requirements

• Factored that effort into vendor selection decisions

They built a shared responsibility matrix before writing their first line of production code. They documented which team owned each control. They established evidence collection procedures early.

When audit time came, they breezed through. The auditor later told me: "Most companies treat vendor SOC 2 reports as proof they don't need to do anything. This company treated them as instruction manuals for what they needed to do. That's the difference between passing and failing."

Their Type II audit took 8 weeks instead of the typical 6 months. They achieved certification on the first try. And they built a security program that actually protects their business, not just checks compliance boxes.

That's the power of understanding shared responsibility.

Your vendors are partners in security, not replacements for it. Their SOC 2 reports are blueprints for your own security program, not substitutes for it.

Build accordingly.