Reading SOC 2 Reports: A Practical Guide

What is a SOC 2 Report?

SOC 2 (Service Organization Control 2) is an auditing standard developed by the American Institute of Certified Public Accountants (AICPA) for service organizations that store customer data in the cloud. It measures how well a company protects customer data based on five Trust Service Criteria.

                The Five Trust Service Criteria
                Security: Protection against unauthorized access (both physical and logical)
Availability: System accessibility for operation and use as committed or agreed upon
Processing Integrity: System processing is complete, valid, accurate, timely, and authorized
Confidentiality: Information designated as confidential is protected
Privacy: Personal information is collected, used, retained, disclosed, and disposed of properly

            

Important: Security is always required in a SOC 2 audit. The other four criteria are optional and selected based on the service organization's offerings.

SOC 2 vs. SOC 3: Access and Distribution

SOC 2 Reports are Restricted-Use Documents

Unlike SOC 3 reports (which are public summaries), SOC 2 reports are confidential and typically require:

A Non-Disclosure Agreement (NDA) before the vendor will share the report
The report cannot be shared publicly or redistributed without permission
Some vendors only share reports after a sales conversation or during procurement
The detailed testing results and exceptions are considered sensitive information

SOC 3 reports are general-use summary reports without detailed testing procedures or results. They're designed for public distribution but provide much less assurance value than SOC 2.

SOC 2 Types and Versions

Type I vs. Type II

SOC 2 Type I

Point-in-time assessment

Evaluates controls at a specific date
Tests if controls are properly designed
Does NOT test if controls work over time
Faster and less expensive to obtain
Less valuable for assurance

Limited value - only shows controls existed on one day

SOC 2 Type II

Period-of-time assessment

Evaluates controls over a period (typically 6-12 months)
Tests both design AND operating effectiveness
Shows controls work consistently over time
More rigorous and time-consuming
Significantly more valuable for assurance

Industry standard - what most organizations require

Report Versions and Framework Evolution

SOC 2 reports come in different versions based on Trust Services Criteria updates:

Pre-2017: Used older criteria categories (may see legacy reports)
2017 Trust Services Criteria: Current foundation with five Trust Service Criteria listed above
2022 Revised Points of Focus: Updated guidance within the 2017 framework

Most modern reports use the 2017 framework. If you encounter an older report, be aware the criteria structure differs.

2022 Revised Points of Focus

AICPA November 2022 Update

In November 2022, the AICPA released revised points of focus for the 2017 Trust Services Criteria. This was not a complete framework overhaul - the five Trust Service Criteria remain the foundation.

What changed:

Added new points of focus addressing evolving technologies (cloud, DevOps, AI/ML)
Updated guidance for emerging threats (ransomware, supply chain attacks)
Incorporated lessons from recent regulatory changes (GDPR, CCPA, etc.)
Refined criteria around third-party risk management
Enhanced focus on incident response and resilience

What this means for you:

Points of focus are guidance, not mandatory requirements
Auditors use them to evaluate whether controls adequately address risks
Reports issued after 2022 may reference the updated points of focus
The core five Trust Service Criteria remain unchanged

Integration with COSO Framework: The 2017 Trust Services Criteria integrated with the COSO Internal Control Framework. The five COSO components (control environment, risk assessment, control activities, information and communication, monitoring) align with how security and common criteria are organized in SOC 2 reports.

How to Read a SOC 2 Report

SOC 2 reports are typically 50-150+ pages long. Here's how to efficiently evaluate them:

Report Structure

Independent Auditor's Report (2-3 pages)
- The auditor's opinion on the controls
- Scope of the examination
- Type of opinion (unqualified, qualified, adverse, or disclaimer)
Management's Assertion (1-2 pages)
- Company's statement about their controls
- System description overview
System Description - Section 3 (10-30 pages)
This section contains nine standard subsections describing the system and its boundaries:
- Overview of Services Provided: What the organization does
- Principal Service Commitments and System Requirements: What the organization promises to deliver
- Components of the System: Infrastructure, software, people, procedures, and data
- System Incidents: Security incidents during the audit period
- Control Activities: Overview of control environment
- Complementary User Entity Controls (CUECs): Controls YOU must implement
- Complementary Subservice Organization Controls (CSOCs): Controls of third-party providers
- Specific Trust Services Criteria Not Applicable: Which criteria were excluded and why
- Significant Changes During the Period: Major changes (Type II only)
Section 4: Control Objectives and Controls (bulk of report)
- Detailed listing of controls
- Mapped to Trust Service Criteria
- Tests Performed and Results (Type II only)
- EXCEPTIONS (if any) - CRITICAL TO REVIEW
Section 5: Other Information Provided by Management (Optional)
- Management's additional context and responses to exceptions
- Remediation steps for control failures identified in Section 4
- Valuable for understanding management's response to issues
- Important: This section is unaudited by the service auditor - it's management's perspective, not verified by the auditor

The Most Important Parts to Review

1. Auditor's Opinion (Page 1-2)

Look for an "unqualified opinion" - this means the auditor found no material issues with the design or operating effectiveness of controls. A qualified opinion indicates material weaknesses or scope limitations that prevented the auditor from providing full assurance. An adverse opinion or disclaimer is a major red flag.

Important distinction: Many reports have minor exceptions in Section 4 but still receive an unqualified opinion. A qualified opinion specifically means the auditor identified material issues significant enough to affect their overall conclusion.

2. Exceptions and Qualifications

Read EVERY exception carefully. Exceptions indicate controls that failed testing. Evaluate:

Severity of the exception
Whether it affects your use case
Management's remediation plan

3. Report Date and Period

For Type II, check:

The audit period (should be at least 6 months, preferably 12)
How recent the report is (older than 12 months is a concern)
Whether there are gaps between successive reports

4. Scope and Boundaries

Understand exactly what IS and IS NOT covered:

Which systems and services are included
Geographic locations covered
Which Trust Service Criteria are included
Subservice organizations (and whether they were carved out)

5. Complementary User Entity Controls (CUECs)

These are controls YOU must implement for the service provider's controls to be effective. Don't skip this section - these are YOUR responsibilities.

Understanding Exceptions: Real-World Examples

Exceptions are arguably the most important part of a SOC 2 Type II report. An exception occurs when a control fails testing during the audit period. Understanding how to read and evaluate exceptions is critical.

What Exceptions Look Like

In the report, you'll typically see:

Control Objective: What the control was supposed to achieve
Control Description: The specific control that was tested
Test Performed: How the auditor tested the control
Exception Noted: What failed
Management Response: Company's explanation and remediation plan

Real-World Exception Examples

Example 1: Access Review Exception (Low-Medium Severity)

Control: User access reviews are performed quarterly to ensure appropriate access levels.

Exception: During Q2 2024, the quarterly access review was completed 17 days late due to key personnel being on leave.

Management Response: The company has implemented a backup reviewer process and calendar reminders to ensure timely completion. The delayed review did not identify any inappropriate access.

How to Evaluate:

Low severity - process control failure, not a technical control failure
One-time occurrence with reasonable explanation
Management response shows corrective action
No evidence of actual security impact

Example 2: Password Policy Exception (Medium Severity)

Control: System passwords require complexity requirements including minimum 12 characters, special characters, and 90-day expiration.

Exception: Testing of 45 user accounts revealed that 3 service accounts (6.7%) had passwords that did not meet the 90-day rotation requirement, with passwords aged 120-145 days.

Management Response: The three service accounts have been updated with new passwords. Service account password rotation has been added to the monthly security review checklist. The company is evaluating automated password rotation solutions for service accounts.

How to Evaluate:

Medium severity - technical control gap affecting multiple accounts
Small percentage but shows systematic issue with service account management
Management response addresses immediate issue and systemic fix
Consider: Are these service accounts used for systems relevant to your use case?

Example 3: Backup Verification Exception (High Severity)

Control: Database backups are performed daily and restore testing is conducted monthly to verify backup integrity.

Exception: Restore testing was not performed for 4 consecutive months (January - April 2024) for the production customer database. When testing resumed in May, the restore process failed due to a configuration error that had existed since January.

Management Response: The backup configuration issue has been corrected and verified through successful restore testing. The company has implemented automated restore testing with alerting and escalation procedures. A root cause analysis identified insufficient coverage in the backup monitoring dashboard.

How to Evaluate:

High severity - affects availability and disaster recovery capability
Four-month gap shows process breakdown, not one-time error
Failed restore when testing resumed indicates actual control failure
Critical for services where data availability is essential
Ask: What was the remediation timeline? Has automated testing been verified?

Example 4: Vulnerability Management Exception (Critical Severity)

Control: Critical and high-severity vulnerabilities are remediated within 30 days of discovery.

Exception: Review of vulnerability scan results identified 12 high-severity vulnerabilities in internet-facing systems that remained unpatched for 45-90 days beyond the 30-day SLA. The delays were attributed to change management backlog and resource constraints.

Management Response: All identified vulnerabilities have been remediated. The company has hired two additional security engineers and implemented a prioritized patching workflow with executive escalation for SLA breaches.

How to Evaluate:

Critical severity - high-risk vulnerabilities in internet-facing systems
Systematic failure affecting multiple systems over extended period
Resource constraints as root cause raises questions about ongoing capability
Significant security risk that could lead to breaches
Required actions: Request evidence of remediation, current vulnerability metrics, and staffing verification

Management Responses and Remediation

When evaluating management responses to exceptions, look for:

Immediate Remediation

Clear statement that the specific issue has been fixed
Timeframe for when remediation was completed
Evidence or verification of the fix

Root Cause Analysis

Understanding of why the failure occurred
Acknowledgment of systematic vs. one-time issues
Honest assessment without excessive excuses

Systemic Improvements

Process changes to prevent recurrence
Automation, monitoring, or technical controls added
Resource additions if capacity was the issue

Red Flags in Management Responses

Vague responses without specific remediation details
Blaming external factors without internal accountability
No mention of preventive measures for similar issues
Remediation timeline extends beyond the audit report date
Multiple similar exceptions across different controls
Responses that minimize or downplay the severity

Important Context About Management Responses

Management responses in SOC 2 reports are unaudited, but they are reviewed by the auditor for materially misleading statements. This means:

The auditor doesn't verify that promised remediations have been implemented
The auditor will flag responses that are factually incorrect or misleading
Future improvements and plans are aspirational, not verified facts
You should request evidence of remediation independently

Bridge/Gap Letters

What is a Bridge Letter?

A bridge letter (also called a gap letter) is a document from vendor management that covers the period between their last SOC 2 audit end date and your current evaluation date.

Example scenario:

Vendor's SOC 2 report covers: January 1 - December 31, 2024
Your evaluation date: June 15, 2025
Gap period: January 1 - June 15, 2025 (5.5 months)

What a bridge letter should include:

Confirmation that controls remain in place and operating effectively
Any material changes to the control environment
Status of exception remediations from the previous report
Any security incidents or breaches during the gap period
Changes in scope (new products, locations, acquisitions)
Status of next SOC 2 audit (in progress, planned, etc.)

Important limitations:

Bridge letters are unaudited management assertions
They don't carry the same assurance value as an audited report
Useful for short gaps (3-6 months), less acceptable for longer periods
Not a substitute for an up-to-date SOC 2 report

If a vendor's most recent SOC 2 report is more than 15-18 months old, even with a bridge letter, consider whether the assurance is sufficient for your risk tolerance.

Common Misunderstandings and Pitfalls

1. "SOC 2 Certified" or "SOC 2 Compliant"

These terms are technically incorrect and misleading.

SOC 2 is a report, not a certification. Organizations receive a SOC 2 report, not a certification. Correct language: "SOC 2 Type II attested" or "has a SOC 2 Type II report."

2. Assuming Type I Provides Meaningful Assurance

Type I only shows controls existed on one specific day.

Type II demonstrates controls operate effectively over time. Always prefer Type II reports for vendor assessment.

3. Not Reading the Exceptions

Assuming a clean opinion means no issues.

Even with an unqualified opinion, there may be exceptions. These represent control failures and must be evaluated for impact on your use case.

4. Ignoring Report Age

Accepting reports that are 18-24+ months old.

SOC 2 reports should be current (within 12 months). Older reports may not reflect current controls, especially in fast-growing tech companies.

5. Not Verifying Scope Matches Your Use Case

Assuming the entire company is covered.

Carefully verify that the specific product, service, or data center you're using is within the audit scope.

6. Overlooking Complementary User Entity Controls (CUECs)

Thinking the vendor's SOC 2 covers everything.

CUECs are controls YOU must implement. The vendor's controls may fail if you don't implement your part.

7. Confusing SOC 2 with Other Reports

Don't confuse SOC 2 with:

SOC 1: Focuses on financial reporting controls, not security
SOC 3: A general-use summary report without detailed testing results
ISO 27001: An international security standard (certification, not a report)
PCI DSS: Payment card industry specific compliance

8. Treating SOC 2 as a Security Guarantee

Believing SOC 2 means the vendor is "secure."

SOC 2 shows the vendor has controls in place and they operated effectively during the audit period. It's not a guarantee against breaches or vulnerabilities. Use it as one input in your security assessment.

9. Not Considering the Auditor Quality

Assuming all SOC 2 audits are equivalent.

Audit quality varies significantly based on the auditing firm's expertise and rigor. A SOC 2 from a reputable, specialized firm is more valuable than one from a small, inexperienced firm.

10. Missing Gaps in Coverage

Not checking for gaps between audit periods.

If a company has multiple SOC 2 reports over time, check for gaps. A 3-month gap between reports could indicate a period where controls weren't tested or issues were being remediated.

Evaluating the Auditing Firm

Not all SOC 2 audits are created equal. The quality of the audit depends heavily on the auditing firm.

How to Verify the Auditing Firm

1. Check CPA Licensing

SOC 2 reports must be issued by a licensed CPA firm. Verify their license:

Find the state: Look for the firm's state of registration on the report (usually on the auditor's opinion letter)
Search the state board: Go to that state's Board of Accountancy website and search for the firm name
Quick links: California | New York | Texas | All State Boards (NASBA)
Confirm the license is active and in good standing

2. Verify Peer Review Status

CPA firms performing SOC 2 audits must undergo peer review every 3 years. Check their status:

Go to: AICPA Peer Review Public File
Search: Enter the firm name and state
What to look for:
- Pass: The firm's system of quality control is designed appropriately and operating effectively
- Pass with Deficiency(ies): Generally adequate but with specific issues identified
- Fail: Significant deficiencies - consider this a red flag
Confirm the most recent review is within the last 3 years
Check that the peer review scope includes "System Reviews" (required for SOC engagements)

3. Check AICPA Membership (Optional)

AICPA membership is not required but indicates professional commitment:

The AICPA does not maintain a public member directory
However, the Peer Review Public File shows if firms are members of AICPA practice sections (PCPS, GAQC, EBPAQC)
You can also ask the firm directly for proof of AICPA membership

4. Review IT Security Certifications

SOC 2 is an IT security audit - auditors should have IT/security credentials beyond just CPA licensure:

CISA (Certified Information Systems Auditor): Premier certification for IT audit - Verify CISA
CISSP (Certified Information Systems Security Professional): Deep security expertise - Verify CISSP
CRISC (Certified in Risk and Information Systems Control): IT risk management focus - Verify CRISC
Audit teams should include members with relevant technical certifications

5. Evaluate Experience and Specialization

Firms specializing in SOC 2 audits typically provide more thorough audits
Look for experience in your industry (SaaS, fintech, healthcare, etc.)
Check if they understand the technology stack in scope
Review their website for published thought leadership or case studies

Red Flags

Auditor is not a CPA firm
No information about the auditing firm in the report
Very short audit period (less than 6 months for Type II)
Generic or vague control descriptions
Lack of detail in testing procedures
Unknown or unverifiable auditing firm

Understanding Scoping

Scoping determines what is and isn't covered by the SOC 2 report. This is critical to understand.

Common Scoping Considerations

In-Scope vs. Out-of-Scope Systems

The report should clearly define:

In-scope: Systems, applications, and infrastructure covered by the audit
Out-of-scope: Systems explicitly excluded

A company might have SOC 2 for Product A but not Product B. Verify your specific service is in scope.

Subservice Organizations

Many companies rely on third-party services (cloud providers, data centers, etc.). These can be handled two ways:

Carve-out method: Subservice organization is excluded from scope. You must separately verify the subservice organization's controls.
Inclusive method: Subservice organization's controls are included in the audit and testing.

The carve-out method is more common. Always check which method is used.

Geographic and Temporal Scope

Which data centers or locations are covered?
If the company operates globally, are all regions included?
What was the time period for Type II reports?

Trust Service Criteria Selection

Organizations choose which criteria to include. Common combinations:

Security only: Minimum viable SOC 2
Security + Availability: Common for SaaS products
Security + Availability + Confidentiality: For data-sensitive services
All five criteria: Most comprehensive (but rare)

Understanding Other Frameworks in Vendor Reports

When reviewing vendor security, you'll encounter multiple frameworks. Understanding what they actually tell you helps you assess whether a vendor's compliance portfolio meets your needs.

What Different Frameworks Tell You as a Reviewer

SOC 1

Financial Controls Report

What it tells you: Controls affecting YOUR financial statements (e.g., payroll processors)
What it doesn't tell you: Nothing about security, data protection, or IT controls
Common confusion: Vendors may cite "SOC 1" when you ask for "SOC 2" - they are completely different
When it matters: If the vendor processes financial transactions that flow into your financial reporting

Red flag: If a vendor offers SOC 1 when you asked for security assurance, they either don't understand compliance or are being evasive.

ISO 27001

International Security Standard (Certification)

What it tells you: An ISMS exists and was certified at a point in time
What you don't see: Specific control test results, exceptions, or detailed evidence
Key limitation: You get a certificate, not a detailed attestation report
When to accept it: International vendors where ISO 27001 is the norm, but you lose transparency compared to SOC 2

ISO 27001 confirms a security program exists but doesn't show you whether controls actually work. Some organizations accept it internationally, but it's not equivalent to SOC 2 for vendor risk assessment.

PCI DSS

Payment Card Industry Data Security Standard

What it tells you: Payment card data is protected per card brand requirements
Scope limitation: Only covers cardholder data environment (CDE), not broader security
When it matters: If you're transmitting card data to this vendor
What it doesn't replace: General security controls outside the CDE

PCI DSS compliance is narrow and specific. Don't accept it as a substitute for SOC 2 unless your only concern is payment processing.

HIPAA

Health Insurance Portability and Accountability Act

What it tells you: The vendor claims compliance with healthcare privacy and security rules
Key problem: There's no official "HIPAA certification" - you're relying on their self-assessment
What to ask for: Request a SOC 2 with HIPAA mapping, or an independent HITRUST certification
When it matters: If you're a covered entity or business associate sharing PHI

HIPAA "compliance" without third-party attestation is just a vendor's claim. Always request independent verification for healthcare data.

FedRAMP

Federal Risk and Authorization Management Program

What it tells you: The service is authorized for federal government use at a specific impact level
Key limitation: Authorization packages aren't publicly available for vendor due diligence
What you know: Rigorous NIST 800-53 controls were assessed, but you can't see the details
Practical value: Strong signal of security maturity, but not a substitute for SOC 2 report review

FedRAMP authorization is excellent but you can't review the assessment details. Most FedRAMP vendors also maintain SOC 2 for non-government customers.

NIST CSF / NIST 800-53

National Institute of Standards and Technology Frameworks

What it tells you: The vendor uses NIST frameworks to structure their security program
Key limitation: These are frameworks, not certifications - there's no official NIST attestation
What to ask for: Independent verification (like SOC 2 with NIST CSF mapping)
Positive signal: Shows security maturity if they're following government-grade frameworks

NIST framework alignment is good, but it's self-reported. Request third-party attestation to verify controls are actually implemented.

GDPR / CCPA

Privacy Regulations

What it tells you: The vendor claims compliance with privacy regulations
Key limitation: No official certification process - compliance is self-assessed
What to verify: Data processing agreements (DPAs), data subject rights procedures, breach notification processes
How SOC 2 helps: SOC 2 Privacy criteria can provide evidence, but doesn't guarantee legal compliance

Privacy regulation "compliance" is often self-declared. Review their privacy policies and data processing agreements, and consider SOC 2 Privacy criteria as supporting evidence.

Can Multiple Frameworks Replace Each Other?

Short answer: Partially, but be cautious

Different frameworks have overlapping controls but different focuses:

ISO 27001 + SOC 2: ISO 27001 is a certification that confirms an ISMS exists, while SOC 2 is a detailed report showing specific controls and test results. Some international customers accept ISO 27001, but you lose visibility into actual control effectiveness. They serve different purposes.
FedRAMP → SOC 2: FedRAMP is a government authorization for specific cloud services based on NIST 800-53 controls, while SOC 2 uses Trust Services Criteria. Both are service-specific assessments, but FedRAMP authorization packages aren't accessible for typical vendor due diligence. Organizations often maintain both to serve different customer types.
PCI DSS ≠ SOC 2: PCI is narrowly focused on payment security. It doesn't cover broader organizational security controls.
HIPAA ≠ SOC 2: Different focus areas. Healthcare organizations often need both.

Best practice: Understand what controls you need assured and verify the framework covers those specific areas, regardless of the framework name.

SOC 2+ Reports: What They Mean for Reviewers

What is SOC 2+?

SOC 2+ (or "SOC 2 Plus") reports map SOC 2 controls to additional compliance frameworks in a single report. This can be valuable for reviewers but requires careful examination.

Common SOC 2+ Mappings You'll Encounter:

SOC 2 + HIPAA: Shows which SOC 2 controls address HIPAA Security Rule requirements
SOC 2 + HITRUST: Healthcare-focused, more comprehensive than HIPAA alone
SOC 2 + NIST CSF: Maps to NIST Cybersecurity Framework categories
SOC 2 + GDPR: Shows privacy and security control alignment with GDPR
SOC 2 + PCI DSS: Maps controls to payment card security requirements

What to Verify as a Reviewer:

Check the mapping: Does the report clearly show which SOC 2 controls address your required framework?
Verify coverage: Are all the framework requirements you need actually mapped?
Look for gaps: The mapping might not cover 100% of the secondary framework
Assess exceptions: Do exceptions in SOC 2 controls impact the mapped framework requirements?

Critical for reviewers: A SOC 2+ report is convenient but verify the mapping actually covers YOUR specific compliance requirements. Don't assume complete coverage of the secondary framework.

Understanding Cloud Infrastructure in Vendor Reports

When a Vendor Says "We're on AWS" or Cites AWS's SOC 2

This does NOT replace their own SOC 2

This is one of the most common vendor responses when asked for SOC 2. It's a red flag.

What Cloud Provider SOC 2 Reports Actually Cover

When reviewing vendor security, understand what the cloud provider's SOC 2 tells you (and what it doesn't):

What AWS/Azure/GCP SOC 2 Covers

(Infrastructure layer only)

Physical data center security
Network infrastructure
Hypervisor and virtualization layer
Core platform services
Hardware and facility controls

What the Vendor Must Still Control

(Requires their own SOC 2)

Application code and configuration
Data encryption and key management
Access controls and identity management
Backup and disaster recovery procedures
Security monitoring and incident response
Secure development practices

What "Subservice Organization" Means in a SOC 2 Report

If a vendor has their own SOC 2, you might see cloud providers mentioned as "carved-out subservice organizations." This means:

Positive sign: The vendor acknowledges cloud infrastructure is out of their direct control
What it tells you: The vendor's auditor reviewed the cloud provider's SOC 2 report
Your responsibility: You may still want to review the cloud provider's SOC 2 yourself for infrastructure assurance
What it doesn't mean: The cloud provider's report doesn't reduce the vendor's responsibility for application-layer controls

Red Flags When Reviewing Vendor Responses

"We're hosted on AWS, so we're SOC 2 compliant" - This is incorrect and shows lack of understanding
"You can review AWS's SOC 2 instead of ours" - Not acceptable; demand their own report
"We're working on SOC 2" - This means they don't have it yet; assess the risk of proceeding without it
Only providing a SOC 3 summary - This provides minimal assurance; request the full SOC 2 Type II report

Questions to Ask Vendors Beyond "Do You Have SOC 2?"

Having a SOC 2 report is just the starting point. Here are critical questions to ask vendors during your security evaluation:

About the SOC 2 Report Itself

Is it Type I or Type II? (Always request Type II)
What is the audit period covered? (Minimum 6 months, preferably 12)
When was the report issued? How current is it?
Which Trust Service Criteria are included? (Security only, or Security + others?)
Were there any exceptions in the report? If so, what were they and have they been remediated?
Can you provide evidence of exception remediation?
Who was the auditing firm? Can you provide information about their qualifications?

About Scope and Coverage

Is the specific product/service we're purchasing covered in the SOC 2 scope?
Which data centers and geographic regions are in scope?
Are there any services we'll use that are out of scope?
Which subservice organizations are carved out? Do you have their SOC 2 reports?
Has there been any change in scope since the last report?
If you have multiple products, can you confirm which ones are covered?

About Complementary User Entity Controls (CUECs)

What are the Complementary User Entity Controls we need to implement?
Can you provide detailed guidance on implementing CUECs?
Do you offer tools or features to help us meet CUEC requirements?
What happens if we don't implement the CUECs? Which controls are affected?

About Ongoing Security Practices

When is your next SOC 2 audit scheduled? Will there be any gaps in coverage?
Can you provide a bridge letter covering the period since your last audit?
How often do you perform penetration testing? Can you share recent results (redacted)?
Do you have a vulnerability disclosure/bug bounty program?
What is your vulnerability remediation SLA for critical/high vulnerabilities?
Have you experienced any security incidents or breaches? How were they handled?
Do you have cyber insurance? What's the coverage amount?
Can you describe your incident response process and communication plan?

About Data Protection

How is our data encrypted in transit and at rest?
Who manages encryption keys? Do you support customer-managed keys?
Where is our data stored geographically? Can we control data residency?
What is your data backup and recovery process?
What is your Recovery Time Objective (RTO) and Recovery Point Objective (RPO)?
How often do you test disaster recovery procedures?
What happens to our data if we terminate the service? What is your data deletion process?

About Access Controls

Do you support multi-factor authentication (MFA)? Is it required for all users?
Do you support single sign-on (SSO) and SAML integration?
Can we control user permissions and implement role-based access control (RBAC)?
Do you support just-in-time (JIT) access for privileged operations?
How do you manage access for your employees to customer data?
Do you log all access to customer data? Can we access these logs?

About Compliance and Legal

Are you compliant with GDPR/CCPA or other relevant privacy regulations?
Do you have a Data Processing Agreement (DPA) we can review?
What other compliance certifications do you maintain? (ISO 27001, PCI DSS, HIPAA, etc.)
Do you undergo regular third-party security assessments beyond SOC 2?
Can you support our compliance requirements (e.g., financial services, healthcare)?

Best Practice: Security Questionnaire

Use a standardized security questionnaire (like the SIG Lite or CAIQ) in addition to SOC 2 review. This ensures comprehensive coverage of security topics that may not be fully addressed in the SOC 2 report.

Common questionnaires:

SIG (Standardized Information Gathering): Comprehensive vendor security questionnaire by Shared Assessments
CAIQ (Consensus Assessments Initiative Questionnaire): Cloud Security Alliance's cloud-focused questionnaire
VSAQ (Vendor Security Assessment Questionnaire): Google's open-source security questionnaire

Evaluating Vendor SOC 2 Timeline Claims

When a vendor says "We're working on SOC 2," understanding realistic timelines helps you assess whether to wait or look elsewhere.

What "Working on SOC 2" Actually Means

"We're doing a readiness assessment"

What this means: They're identifying control gaps, haven't started implementing controls yet

Realistic timeline to Type II report: 15-24 months

Red flag: If they've been "doing readiness" for 6+ months, they may be stalling

"We're implementing controls"

What this means: Building security infrastructure, policies, and processes

Realistic timeline to Type II report: 12-18 months

Questions to ask: Which controls are implemented? When does the observation period start?

"We've selected an auditor"

What this means: Formal engagement is starting, but observation period may not have begun

Realistic timeline to Type II report: 8-14 months (includes 6-12 month observation period)

Questions to ask: Who is the auditor? When does the observation period begin?

"We're in the observation period"

What this means: Controls are operating, collecting evidence for Type II

Realistic timeline to Type II report: 6-12 months (remaining observation period + audit execution)

Questions to ask: When did the observation period start? How many months are left? Will you get Type I in the meantime?

"We're in testing/fieldwork"

What this means: Auditor is actively testing controls

Realistic timeline to Type II report: 1-3 months

Good sign: They're close, but report may have exceptions if this is their first audit

"Our report is being finalized"

What this means: Final review and approval from the auditor

Realistic timeline to Type II report: 2-6 weeks

Questions to ask: Were there any exceptions noted? When will the final report be available?

Realistic Timeline Expectations

First-Time SOC 2 Type II Timeline

If vendor is well-prepared: 12-15 months minimum

Typical for most vendors: 15-18 months

Starting from scratch: 18-24 months

Critical: You CANNOT rush the observation period. Type II requires 6-12 months of controls operating effectively. Anyone claiming faster timelines is either getting Type I only or being unrealistic.

Red Flags in Vendor Timeline Claims

"We'll have SOC 2 in 3 months" - Impossible for Type II unless they're already in the final audit phase
"We're getting SOC 2 next quarter" (repeated quarterly) - Timeline keeps slipping, they may not be making progress
"We can expedite it for this deal" - You cannot rush the observation period; this shows misunderstanding
Vague timeline with no specifics - "Working on it" without details about which phase they're in
"We're SOC 2 ready" - Meaningless term; readiness doesn't equal having a report
No auditor selected after 6+ months - Suggests low commitment or budget issues

Questions to Ask Vendors "Working on SOC 2"

What specific phase of the SOC 2 process are you in?
Have you selected an auditor? Which firm?
When did (or will) your observation period start?
Are you pursuing Type I, Type II, or both?
What is your target completion date? Has this date changed?
Which Trust Service Criteria are you including?
Can you provide regular status updates on your progress?
What compensating controls do you have in place until you have SOC 2?

Deciding Whether to Wait or Proceed Without SOC 2

Consider waiting if:

Vendor is in the observation period or later (6-12 month wait)
They have a credible timeline with specific milestones
They offer Type I report in the interim
They provide strong compensating controls (ISO 27001, detailed security documentation, customer references)
The vendor is otherwise a strong fit and willing to provide transparency

Consider other vendors if:

Timeline is 18+ months out
They haven't selected an auditor or started implementation
This is a hard requirement from your organization or regulators
The vendor is vague about timeline or progress
You've seen multiple timeline slips
Other qualified vendors have current SOC 2 reports

Risk mitigation strategies while waiting:

Include SOC 2 completion milestone in contract with penalties
Request quarterly progress updates with evidence
Require additional security reviews (penetration testing, security questionnaires)
Implement enhanced monitoring and logging on your side
Include termination rights if SOC 2 isn't delivered by agreed date
Request right to review draft report when available

Quick Reference: Evaluating a SOC 2 Report

Essential Checks

Type II (not Type I)
Unqualified opinion from auditor
Report date within last 12 months
Audit period of at least 6 months (12 preferred)
Your specific service/product is in scope
Relevant Trust Service Criteria included (minimum: Security)
Review all exceptions thoroughly
Understand what's carved out (subservice organizations)
Read Complementary User Entity Controls
Verify auditing firm is a legitimate CPA firm

Remember

A SOC 2 report is a valuable assurance tool, but it's not a complete security assessment. Use it as part of a comprehensive vendor risk evaluation that also includes:

Security questionnaires
Penetration testing results
Incident response plans
Contractual security requirements
Regular security reviews

Resources

This guide was compiled from the most trusted resources in the industry. Here are the primary sources used: