What is a SOC 2 report? A complete guide for tech teams

A SOC 2 (System and Organisation Controls 2) report is an independent audit evaluating how a service organisation secures customer data based on five Trust Services Criteria. For B2B tech companies, this attestation has become a strict procurement gatekeeper.

A missing or weak report can kill an enterprise deal before the first product demo. While the standard was developed by the American Institute of Certified Public Accountants (AICPA), its reach is genuinely global. It has become the de facto trust benchmark for service organisations processing, storing, or transmitting customer data. Rather than viewing this process as a painful compliance hurdle, successful scale-ups treat it as a commercial enabler and a structured opportunity to establish mature security practices.

What is a SOC 2 report and why does it matter?

A SOC 2 report is an independent audit that matters because it proves to enterprise customers that your service organisation securely manages and protects sensitive data.

Attestation vs. certification

Developed by the AICPA, SOC 2 provides a standard framework to assess how well an organisation manages risk and protects data.

A crucial distinction to understand early on is that SOC 2 is an attestation, not a certification. You do not receive a formal 'SOC 2 certificate' to frame on the wall. Instead, an independent, licensed Certified Public Accountant (CPA) firm reviews your systems and attests to the design and operating effectiveness of your internal controls. The output is a detailed report containing the auditor's formal opinion on whether you meet the applicable standard.

Building customer trust

The primary purpose of a SOC 2 report is to give customers, partners, and management confidence in how you govern and protect sensitive data.

When you sell software to an enterprise, their security and privacy teams must assess the risk of bringing your product into their environment. Handing them a comprehensive SOC 2 report achieves several commercial objectives at once: it satisfies complex vendor security questionnaires, drastically reduces the need for individual customer audits, and creates a competitive advantage against vendors who cannot demonstrate the same level of operational maturity.

Ultimately, it unblocks deals. When a prospect's procurement team asks how you manage vendor risk management or secure external access, a clean SOC 2 report provides an immediate, verified answer.

The five Trust Services Criteria (TSCs)

The five Trust Services Criteria (TSCs) are security, availability, processing integrity, confidentiality, and privacy, which form the framework an auditor uses to assess your system and controls.

Security (Common Criteria)

The Security TSC is non-negotiable. It forms the base of every SOC 2 audit, which is why it is often referred to as the Common Criteria.

To achieve this baseline, you must demonstrate that your system is protected against unauthorised access (both logical and physical). This covers a broad range of operational controls, including formal risk assessments, continuous security monitoring, access management, endpoint protection, and incident response procedures.

Additional criteria

Beyond Security, management must define the scope of the audit by selecting which of the remaining four criteria are relevant to the service provided. Not every organisation needs all five.

Availability

Assesses whether systems are accessible for operation and use as committed or agreed.

• Core objective: Ensure systems meet operational uptime SLAs.
• You need this if: You provide infrastructure, hosting, or critical communication tools where downtime halts client operations.

Processing Integrity

Assesses whether system processing is complete, valid, accurate, timely, and authorised.

• Core objective: Ensure data processing is accurate and complete.
• You need this if: Your platform performs financial calculations, payroll processing, or large-scale data analytics.

Confidentiality

Assesses whether information designated as confidential is protected according to policy or agreement.

• Core objective: Protect non-personal, sensitive business data.
• You need this if: You handle strategic corporate data under NDA, like an M&A virtual data room or proprietary code repository.

Privacy

Assesses whether personal information is collected, used, retained, disclosed, and disposed of in conformity with the organisation's privacy notices and principles. The Privacy TSC heavily aligns with core data protection principles found in the UK GDPR.

• Core objective: Protect personal information (PII).
• You need this if: Your platform processes personal data on behalf of clients, requiring strict access, consent, and retention controls.

SOC 2 Type I vs. Type II

You need a SOC 2 Type I report to prove your controls are designed correctly at a single point in time, whereas a Type II report is needed to prove those controls operate effectively over a 3- to 12-month period.

Type I: Point-in-time snapshot

A Type I report verifies that you have designed appropriately secure controls and implemented them by a specific date.

The auditor reviews your documentation and policies to confirm that the framework exists. This is often an excellent first step for fast-moving startups needing to unblock early enterprise conversations, as it proves a foundational commitment to security. However, it does not prove that your team actually follows the policies day-to-day, making it less valuable to mature, risk-averse enterprise customers.

Type II: Effectiveness over time

A Type II report is an audit of both the design and the operating effectiveness of your controls over a specified timeframe, typically spanning three to 12 months.

During a Type II audit, the auditor requests evidence to verify that your controls functioned reliably throughout the entire observation period. Because it demonstrates consistent, applied security behaviour rather than theoretical design, the Type II report is widely considered the gold standard that enterprise procurement teams demand.

Key differences

SOC 2 Type I

• Audit focus: Design of controls.
• Timeframe: A specific point in time (one date).
• Level of assurance: Foundational.
• Customer perception: Good for early-stage trust.
• Typical use case: Startups needing immediate proof of a security baseline.

SOC 2 Type II

• Audit focus: Design and operating effectiveness.
• Timeframe: A specific review period (3 to 12 months).
• Level of assurance: Comprehensive.
• Customer perception: Mandatory for enterprise procurement.
• Typical use case: Scale-ups and mature platforms proving reliable, ongoing compliance.

How to prepare for a SOC 2 audit

To prepare for a SOC 2 audit, you must complete a structured process of scoping your systems, remediating gaps, continuously generating evidence, and undergoing auditor fieldwork.

Across the privacy and security teams in the TrustWorks community, we consistently see that attempting to rush this process without a clear project plan results in engineer burnout and scope creep.

Phase 1: Scoping and readiness

The goal of phase one is to clearly define the system boundaries, select your applicable TSCs, and identify the gap between your current reality and the AICPA criteria.

Key activities include mapping exactly which products, databases, and infrastructure components are in scope. You will conduct a formal readiness assessment (either internally or with an external consultant) to highlight missing policies or technical vulnerabilities. This is also the time to interview and select your CPA audit firm.

Phase 2: Remediation

Phase two focuses on closing every gap identified during the readiness assessment before the formal audit period begins.

This requires hands-on work from engineering, security, and privacy teams. Typical activities include:

• Drafting missing information security policies.
• Implementing new technical controls, like endpoint detection, vulnerability scanning, and robust encryption.
• Formalising onboarding and offboarding procedures.
• Conducting mandatory security awareness training for all staff.

Phase 3: Observation period

The goal here is to operate your remediated controls consistently to generate evidence of their effectiveness over time.

This phase runs in parallel with normal business operations. It is an evidence-generation phase, without external assessors actively 'auditing' your systems. Every time a developer merges code, an employee is provisioned access, or a vendor is reviewed, a digital paper trail must be securely stored.

Phase 4: Fieldwork and report generation

In the final phase, the auditor collects evidence, conducts interviews, and writes the final report.

Your team will respond to extensive auditor evidence requests and participate in walkthroughs to explain how specific controls operate. Once fieldwork concludes, the auditor provides a draft report for management review. The final report will include one of four audit opinions regarding your controls:

• Unqualified: A clean bill of health. Controls are designed and operating effectively.
• Qualified: Controls are mostly effective, but specific deviations or failures were noted.
• Adverse: Controls are broadly ineffective or poorly designed.
• Disclaimer: The auditor could not obtain enough evidence to form an opinion.

SOC 2 audit costs

A SOC 2 audit actually costs between £35,000 and £100,000+, depending on your organisation's size, infrastructure complexity, and reliance on external consultants.

Cost factors

No two audits cost exactly the same. The primary variables include your company size, the complexity of your infrastructure, and the number of TSCs included in your scope.

Who you hire matters immensely. Engaging a Big 4 accounting firm will cost significantly more than a specialised boutique CPA firm. Additionally, if your current security posture is low, you will spend more capital on remediation tools and consulting before the audit even begins.

Breakdown of expenses

For a mid-sized SaaS company tackling a SOC 2 Type II for the first time, a realistic budget breaks down into several categories:

• Auditor Fees (£20,000 - £60,000+): The direct cost paid to the CPA firm to perform the fieldwork and issue the report.
• Readiness Assessment and Consulting (£8,000 - £25,000): Often optional but highly recommended. External experts review your gaps before the auditor sees them.
• Compliance Automation Software (£5,000 - £20,000 annually): Platforms that integrate with your tech stack to continuously monitor controls and collect evidence.
• New Security Tooling (Variable): Implementing mandatory controls often requires buying new tools, such as mobile device management (MDM), background check services, or vulnerability scanners.
• Internal Time and Resources: This is the hidden cost. Security, engineering, and privacy teams will spend hundreds of hours writing policies, reviewing access logs, and answering auditor questions.

SOC 2 vs. other security frameworks

SOC 2 differs from other security frameworks by focusing specifically on technical and operational controls for service organisations, evaluated against the AICPA's Trust Services Criteria.

SOC 1 vs. SOC 2 vs. SOC 3

All three reports fall under the AICPA's System and Organisation Controls framework, but they are not interchangeable.

SOC 1

• Primary audience: Client financial auditors and controllers.
• Subject matter: Controls relevant to a client's internal control over financial reporting (ICFR).
• Report content and distribution: Highly detailed, restricted use (under NDA).

SOC 2

• Primary audience: Client security, privacy, and vendor risk teams.
• Subject matter: Controls relevant to the five Trust Services Criteria (TSCs).
• Report content and distribution: Highly detailed, restricted use (under NDA).

SOC 3

• Primary audience: General public, marketing prospects.
• Subject matter: Controls relevant to the TSCs (summary level).
• Report content and distribution: High-level summary, unrestricted public distribution.

SOC 2 vs. ISO 27001

Deciding between SOC 2 and ISO 27001 is a common dilemma, as the core difference lies in their fundamental approach to compliance. Ultimately, as scale-ups expand globally, many find they need to achieve and maintain both frameworks.

SOC 2

• Assessment type: Detailed attestation report.
• Core focus: Specific technical controls measured against predefined AICPA criteria.
• Regional preference: Heavily preferred in North America.
• Audience value: Directly demonstrates granular data protections to enterprise buyers.

ISO 27001

• Assessment type: Formal certification.
• Core focus: Establishing an Information Security Management System (ISMS) to continuously manage risk.
• Regional preference: Strong global recognition, particularly across Europe and Asia.
• Audience value: Highlights the overarching governance programme and security commitments.

Maintaining and leveraging your report

Maintaining and leveraging your SOC 2 report involves turning the audit into a continuous, year-round operational commitment and proactively using the attestation as a sales tool to unblock enterprise deals.

Continuous compliance

SOC 2 requires an annual operational commitment. Because a Type II report covers a specific window in time, you must begin the next observation period immediately after the previous one ends.

To prevent the next audit from becoming another heavy lift, privacy and security teams must implement continuous control monitoring. Automating evidence collection, scheduling quarterly logical access reviews, and integrating governance tasks into standard engineering sprints ensures you remain compliant year-round without panic.

Using SOC 2 in sales

A clean SOC 2 report should be a proactive sales tool. Train your sales and revenue teams on how to speak confidently about your security posture.

Offer the detailed report proactively under a Non-Disclosure Agreement (NDA) when enterprise prospects ask to review your architecture. For public marketing, consider creating a SOC 3 report or leveraging your compliance milestones when building a trust centre.

Frequently asked questions

The most frequently asked questions about SOC 2 reports cover auditor qualifications, pass and fail conditions, report validity, GDPR overlap, and audit scoping.

Who is qualified to perform a SOC 2 audit?

The professionals qualified to perform a SOC 2 audit are independent, licensed Certified Public Accountants (CPAs) or accounting firms approved by the AICPA. Under AICPA standards, these are the only entities that can legally perform the audit and issue the final attestation report. While security consultants can help your team prepare, they cannot issue the actual report.

Can you 'fail' a SOC 2 audit?

You cannot technically 'fail' a SOC 2 audit, because the auditor issues an opinion rather than a pass or fail grade. If your controls operate effectively, you receive an 'unqualified' opinion. If severe control failures or significant gaps exist, the auditor issues a 'qualified' or 'adverse' opinion, which procurement teams generally view as a failure.

How long is a SOC 2 report valid for?

A SOC 2 report is valid for exactly 12 months from the date of issuance. Because the risk landscape and internal IT systems change rapidly, enterprise clients will rarely accept a report older than a year. Consequently, maintaining compliance requires treating SOC 2 as an annual, repeating operational commitment.

Is SOC 2 mandatory under GDPR?

SOC 2 is not mandatory under GDPR, as it is a voluntary, market-driven standard established by a US body rather than a strict legal requirement. However, including the Privacy Trust Services Criteria (TSC) in your SOC 2 audit provides excellent documented evidence of the technical and organisational measures required to support comprehensive GDPR compliance.

Do I need to audit my entire company for SOC 2?

You do not need to audit your entire company for SOC 2, because the audit evaluates a specific system or service rather than the complete corporate entity. Accurately defining the system boundaries during the scoping phase ensures the auditor only evaluates the infrastructure, data, and personnel directly relevant to the product you sell.

Conclusion

Achieving SOC 2 compliance is a critical trust-building exercise that goes beyond a checkbox on a procurement form. The journey requires accurately scoping your system boundaries against the relevant Trust Services Criteria, implementing robust controls, and committing to continuous monitoring to satisfy the rigorous demands of a Type II audit.

Understanding and navigating this process is now a core competency for any B2B tech company aiming to scale. Building these operational habits early establishes a reliable foundation for a mature security and privacy programme.

If your team is managing compliance tasks in isolated spreadsheets, TrustWorks can help. Our platform is built to centralise data mapping, automate RoPA workflows, and seamlessly integrate privacy operations into your wider governance strategy, so you can face your next audit cycle with confidence.