SOC 2 Type II

Overview#

SOC 2 — System and Organisation Controls 2 — is the AICPA's attestation framework for service organisations: SaaS vendors, cloud providers, payroll processors, managed-service vendors, anyone who holds or processes customer data on behalf of another business. Where SOC 1 covers controls relevant to a customer's financial reporting (the original ISAE 3402 / SAS 70 use case), SOC 2 covers controls relevant to a customer's security, availability, integrity, confidentiality and privacy posture. It is the report a SaaS vendor's prospects ask for when they are deciding whether to trust the vendor with their data.

SOC 2 is performed under AICPA professional standards — primarily SSAE 18 (Statement on Standards for Attestation Engagements No. 18) and the related AT-C section 105 (concepts common to all attestation engagements). The auditor must be a licensed Certified Public Accountant (CPA) firm; the report is signed by a CPA partner; and the AICPA's peer-review process backstops the firm's quality. This is the substantive difference between a SOC 2 report and a self-attested 'we follow industry best practice' marketing statement — SOC 2 carries the weight of a regulated profession.

The framework was rebuilt in 2017 around the Trust Services Criteria (TSC). Before 2017, SOC 2 used the Trust Services Principles, which were broader and harder to audit consistently. The 2017 TSC are mapped to the COSO Internal Control - Integrated Framework, so they slot into an enterprise's existing internal-control posture. The criteria were lightly updated in 2022 (the '2022 Points of Focus' revision) to reflect cloud-first operating models and supply-chain risk; the substantive structure remained.

Type II is the version enterprise buyers actually want. A Type I report opines on whether the controls were suitably designed as of a single point in time — useful evidence that a vendor has thought about security, but no evidence that the controls actually operate. A Type II report opines additionally on whether those controls operated effectively across a continuous observation window — typically six months for a first Type II, twelve months thereafter, with sampled evidence drawn from across the window. That is what buyers buy: not a promise that you have controls, but evidence that the controls run.

Yobitel UK Sovereign and the broader Yobitel platform hold SOC 2 Type II as part of the customer-facing compliance posture — Security, Availability and Confidentiality TSCs, 12-month observation window, mid-tier UKAS-recognised audit firm, AWS and underlying datacentre providers treated as carved-out sub-service organisations — so customers building on Yobitel inherit the sub-service-organisation evidence as a baseline rather than starting their own SOC 2 chain from scratch.

This entry treats SOC 2 Type II as a working reference for an engineering and compliance team standing one up. The Reference section enumerates the five TSC categories and the Common Criteria (CC1-CC9) sub-criteria. The Evidence section lays out the control evidence regulators and auditors expect for each common criterion. The Audit & Accountability section describes the observation window, the auditor relationship and the report structure. The Mapping section cross-references SOC 2 to ISO 27001 Annex A, NIST CSF 2.0, NCSC Cloud Security Principles and HIPAA. The Cost section is honest about what a defensible SOC 2 Type II costs in USD, and the closing section makes plain how Yobitel UK Sovereign discharges SOC 2 obligations as part of its managed compliance posture. This entry helps you assemble defensible SOC 2 Type II evidence for your customers, auditors, or supervisory authorities — and explains where Yobitel's own posture inherits, so a user-entity audit can reuse the platform-side complementary sub-service-organisation controls without re-testing them.

Scope — who needs SOC 2 Type II#

SOC 2 binds the service organisation — the legal entity that operates the service being reported on. The actor that asks for the report is the user entity — the customer (or the customer's auditor) whose data lives in the service organisation's environment. The relationship is contractual and audit-driven: the user entity needs assurance that the service organisation is operating sound controls, and the SOC 2 Type II report is the artefact that provides it without the user entity having to send its own auditors on-site.

The classic SOC 2 use case is the B2B SaaS vendor selling into US enterprise. A US Fortune 500 buyer's vendor-risk-management process will not approve a new SaaS supplier without a current SOC 2 Type II report covering at least the Security TSC. The process is rote — the procurement team requests the report under NDA, the buyer's security team reads the auditor's opinion, the description of the system, the list of controls and the test results, and either approves the vendor or asks the vendor to remediate gaps before signing. A vendor without a SOC 2 Type II report cannot enter the conversation; a vendor with a clean report typically completes the security review in days rather than months.

Beyond US enterprise SaaS, the framework now reaches further. UK enterprise procurement increasingly asks for SOC 2 Type II as an alternative or complement to ISO 27001; the Crown Commercial Service G-Cloud framework accepts SOC 2 Type II as supporting evidence for NCSC Cloud Security Principles compliance, though it does not by itself satisfy a G-Cloud listing. EU enterprise buyers ask for SOC 2 Type II as part of a broader Article 32 evidence pack (alongside ISO 27001 + 27017 + 27018). And in healthcare, financial services, public sector and any sector with sub-processor scrutiny, SOC 2 has become the lingua franca for processor-to-controller assurance.

Scope also turns on which TSC categories the report covers. The Security category — the Common Criteria, CC1 through CC9 — is mandatory in every SOC 2 engagement. The four other categories are optional and selected based on what the service does. A SaaS vendor whose buyers care about uptime will add Availability. A vendor that processes payments or transactions where data correctness is critical will add Processing Integrity. A vendor that holds material non-public information will add Confidentiality. A vendor that processes personal data under a privacy notice (US-resident SaaS often pairs SOC 2 Privacy with HIPAA or state privacy laws) will add Privacy. Scoping in too many categories at once inflates audit cost without commensurate market value; most mature SaaS vendors run Security + Availability + Confidentiality as their default scope.

• Service organisation — the entity being audited; signs the management's assertion; pays the auditor.
• User entity — the customer of the service organisation; reads the report under NDA; uses it to discharge its own vendor-risk obligations.
• Sub-service organisation — a sub-processor used by the service organisation (e.g. AWS for hosting); either carved out of the report (with complementary sub-service controls listed) or inclusive (audited as part of the engagement).
• User auditor — the user entity's own auditor; may rely on the SOC 2 report to reduce the scope of their own work.
• Service auditor — the licensed CPA firm performing the SOC 2 engagement; bound by AICPA professional standards.
• Boundary case — multi-product SaaS vendors often scope the report to a named subset of products; the description of the system must make the boundary unambiguous so a user entity can tell whether the product it uses is in scope.

The framework — TSC categories and Common Criteria#

The Trust Services Criteria are organised into five categories. Each category has 'points of focus' — illustrative examples of how an organisation might satisfy the criterion — which were lightly updated in the 2022 revision. The Common Criteria (the Security category) cover nine sub-areas, CC1 through CC9, and are mandatory in every SOC 2 engagement. The other four categories layer additional criteria on top of the Common Criteria.

• CC1 — Control Environment — governance, integrity, ethical values, board oversight, organisational structure, commitment to competence.
• CC2 — Communication and Information — internal and external communication of objectives, responsibilities, control activities, deficiencies.
• CC3 — Risk Assessment — entity-level risk identification, fraud risk, change risk, control activities responsive to identified risks.
• CC4 — Monitoring Activities — ongoing and separate evaluations of control effectiveness; communication of deficiencies.
• CC5 — Control Activities — selection and development of control activities, including over technology, deployed through policies and procedures.
• CC6 — Logical and Physical Access Controls — identity, authentication, authorisation, access provisioning and de-provisioning, encryption, physical access.
• CC7 — System Operations — vulnerability management, change detection, incident response, security incident communication.
• CC8 — Change Management — authorising, designing, developing, configuring, documenting, testing, approving and implementing infrastructure, data, software and procedural changes.
• CC9 — Risk Mitigation — risk-mitigation activities, vendor and business-partner risk assessment, response to identified vulnerabilities.

Evidence patterns by Common Criterion#

SOC 2 Type II evidence is sampled — the auditor does not look at every change, every access review or every incident; they sample from the population across the observation window. The table below states the criterion, the operative obligation, the evidence the auditor will typically sample, and the system or tool most teams use to produce it. This is the evidence-pack a SOC 2 engagement programme manager builds in advance of fieldwork.

Customers running their own SOC 2 engagement and using Yobitel UK Sovereign as a carved-out sub-service organisation can reuse Yobitel-supplied evidence to close the platform-layer half of the pack: the Yobitel SOC 2 Type II report (under NDA via the customer security portal) covers CC1, CC4, CC5, CC6 and CC7 at the infrastructure layer; the customer-readable audit-stream config covers CC4 and CC7 evidence sampling; the published sub-processor register and complementary sub-service-organisation controls cover CC9; sovereignty pinning to UK regions covers the data-location representation under the description of the system. The customer's own engagement still owns the application-layer evidence (workload RBAC, in-application MFA, customer-side change management, customer-side incident response) but the infrastructure-layer evidence is shipped, not rebuilt.

Audit and accountability — the engagement, the window, the report#

A SOC 2 Type II engagement runs on a cycle. The four phases — scoping, readiness, observation window, fieldwork — are sequential, and the calendar matters. Most service organisations target an annual report on a fixed period (e.g. 1 January to 31 December, or 1 April to 31 March), so the auditor is engaged once a year for fieldwork that runs in the two-to-three months after the window closes. The report is typically issued three to four months after the window-end date.

Phase 1 — Scoping. Set the system boundary, the TSC categories, the treatment of sub-service organisations (carve-out or inclusive), and the observation window. The system description is the auditor's reference for what is in and out of scope and must be unambiguous. Carve-out treatment of sub-service organisations (e.g. 'AWS is carved out; the report does not opine on AWS's controls; user entities should review AWS's own SOC 2 report') is the default for SaaS vendors built on hyperscalers — going inclusive is rarely worth the cost.

Phase 2 — Readiness assessment. The auditor (or an external readiness consultant) walks through the planned controls and identifies gaps before formal fieldwork. The goal is to enter the observation window with controls operating as designed; gaps surfaced in readiness are remediated in the weeks before the window opens. A first-time SOC 2 organisation should expect readiness to take 6-12 weeks and to surface 20-50 deficiencies of varying severity.

Phase 3 — Observation window. Six months for a first Type II; twelve months thereafter. Controls operate continuously across the window. Evidence is captured continuously (the CCM tool earns its keep here). Internal audit or the control owners perform self-testing across the window so that the auditor's sampled tests are not the first time anyone has looked at the evidence.

Phase 4 — Fieldwork. The auditor samples evidence from across the window, tests operating effectiveness, identifies exceptions (deficiencies where a control did not operate as designed for at least one sampled instance), and writes the report. The service organisation responds to exceptions in writing. The auditor finalises the opinion — unqualified ('the controls operated effectively'), qualified ('the controls operated effectively except for ...'), adverse, or a disclaimer. Unqualified is the goal; qualified is acceptable for a first report with limited exceptions; adverse or disclaimer is a market-credibility failure.

Mapping to other frameworks#

SOC 2 overlaps substantially with the other security frameworks an enterprise buyer is likely to encounter. The mapping below is the working cross-reference most security architects use to avoid duplicating control work across frameworks. Most organisations that hold ISO 27001 with cloud overlays (27017 + 27018) can evidence two-thirds of the SOC 2 Common Criteria from existing artefacts; the gap is typically in CC7 (operational monitoring evidence) and CC9 (vendor management evidence at SOC 2's depth).

• ISO 27001 + 27017 + 27018 covers approximately 70% of SOC 2 Common Criteria evidence; the remaining 30% is typically CC7 monitoring evidence and CC9 vendor-management evidence at the depth SOC 2 expects.
• NIST CSF 2.0 covers approximately 80% of SOC 2 CC at the principle level; the gap is in COSO-aligned CC1-CC5 governance evidence that CSF treats more lightly.
• NCSC Cloud Security Principles cover approximately 60% of SOC 2 evidence; G-Cloud buyers accept SOC 2 Type II as supporting evidence rather than as a substitute for principles-mapped self-assessment.
• HIPAA Security Rule maps almost 1:1 to SOC 2 Security TSC for technical safeguards; a vendor with both can usually present a single combined evidence pack to a healthcare user entity.
• GDPR Article 32 cites SOC 2 Type II explicitly under Article 32(3) — adherence to an approved certification mechanism may demonstrate compliance — though SOC 2 alone does not satisfy GDPR; pair with ISO 27018 for personal-data processor evidence.

UK, EU and US considerations#

SOC 2 was created by a US standards body (the AICPA) for US service organisations, and the United States remains the dominant market for SOC 2 reports. But the framework is geography-neutral by design — there is no jurisdictional gating in SSAE 18 — and adoption in the UK and EU has accelerated sharply since the rise of US-headquartered SaaS demanding consistent assurance from European sub-processors.

In the United States, SOC 2 Type II is effectively the cost-of-entry for B2B SaaS. Enterprise buyers — Fortune 500, mid-market, and increasingly state and local government — will not approve a new SaaS vendor without a current report covering at least the Security TSC. The report is read by procurement, by the buyer's security team, and frequently by the buyer's own external auditor (who may rely on it under SOC 2 Type II's user-auditor reliance provisions to reduce the scope of their own work). In regulated sectors — healthcare under HIPAA, financial services under various state regimes, federal government under FedRAMP — SOC 2 supplements but does not displace sector-specific certifications.

In the United Kingdom, SOC 2 Type II is now routinely requested in enterprise procurement alongside or instead of ISO 27001. UK G-Cloud (Crown Commercial Service framework RM1557.x) does not require SOC 2 — the NCSC Cloud Security Principles are the operative security layer — but it accepts SOC 2 Type II as supporting evidence for several principles, particularly Principle 4 (governance), Principle 5 (operational security), Principle 8 (supply chain) and Principle 13 (audit information). UK enterprise buyers in financial services (FCA-regulated firms) and increasingly in the NHS supply chain treat SOC 2 Type II as a credible substitute for ISO 27001 where the vendor is US-domiciled. The UK Information Commissioner's Office cites SOC 2 Type II as one of the acceptable forms of demonstration evidence under UK GDPR Article 32(3).

In the European Union, SOC 2 Type II is established but not dominant — ISO 27001 + 27017 + 27018 carry more weight with EU enterprise buyers because they are ISO standards, recognised under the EU regulatory framework for accreditation, and explicitly cross-referenced by the upcoming EUCS scheme. EU buyers increasingly accept SOC 2 Type II as a credible processor-side artefact under GDPR Article 28 and Article 32, particularly for US-origin sub-processors, but treat it as complementary to ISO rather than as a substitute. The German BSI C5 (Cloud Computing Compliance Criteria Catalogue) is a closer analogue to SOC 2 in spirit — controls-based, cloud-specific, attestation-driven — and is becoming the German-market alternative to a SOC 2 report.

• US — SOC 2 Type II is the dominant trust signal for B2B SaaS; required by most enterprise procurement; user-auditor reliance reduces buyer's own audit scope.
• UK — accepted as G-Cloud supporting evidence; treated as ISO 27001 substitute by US-origin vendors selling into UK financial services and NHS supply chain.
• EU — accepted as Article 28/32 processor evidence; complementary to ISO 27001 + 27017 + 27018 rather than a substitute; BSI C5 is the German-market analogue.
• Cross-jurisdictional — the same evidence pack supports SOC 2 (US buyers) and ISO 27001 + 27017 + 27018 (UK + EU buyers); most mature SaaS vendors run both annually with overlapping audit windows.
• Sector overlays — pair SOC 2 with HIPAA for US healthcare, PCI DSS for payments, FedRAMP for US federal, NHS DSP Toolkit for UK NHS, ISO 13485 / 21 CFR Part 11 for life sciences.

Common implementation gaps#

SOC 2 readiness assessments — and SOC 2 fieldwork itself — surface the same handful of operational gaps with striking regularity. The list below is the failure-mode catalogue most readiness consultants apply on day one; each item is the kind of deficiency that produces an audit exception unless caught in advance. None is novel. All are tractable. Most cost meaningfully more to remediate during fieldwork than to close before the observation window opens.

The single most common cause of SOC 2 exceptions is evidence-capture failure rather than control-design failure: the control exists, the engineering team operates it daily, but no contemporaneous evidence was captured to prove operation across the window. Continuous control monitoring tools (Vanta, Drata, Secureframe, Sprinto) close this gap by automating evidence capture from source systems. The second most common cause is access-review cadence drift: quarterly access reviews scheduled in calendars get missed when teams are busy, and the auditor finds two quarters of evidence followed by a gap, followed by a hurried review just before fieldwork. Make the review a recurring system-generated workflow, not a calendar reminder.

• Control evidence not captured continuously — auditor finds the control exists but cannot evidence operation across the window; remediate with a CCM platform that captures evidence automatically from source systems.
• Access-review cadence drift — quarterly access reviews missed during busy periods; remediate by automating the review workflow in the CCM platform with named owners and SLA escalation.
• Vendor-management gap — vendors onboarded informally without due-diligence files; remediate with a vendor-onboarding gate in procurement that requires due-diligence completion before a SOW is signed.
• Change-management exception trail — emergency changes made outside the normal pull-request gate without documented post-hoc approval; remediate with an emergency-change runbook and a mandatory post-incident review.
• Joiners-movers-leavers latency — leavers' access not deprovisioned within the SLA window; remediate with HRIS-triggered automation that revokes access on termination date rather than relying on manual ticket closure.
• MFA enforcement gap on legacy paths — a legacy access pattern (API key, service account) that pre-dates the MFA policy; remediate by inventorying all auth paths and enforcing MFA at the IAM policy level for any privileged action.
• Sub-service-organisation carve-out under-described — the report carves out AWS but does not enumerate the complementary sub-service controls user entities must verify against AWS's own SOC 2; remediate by adding a complete CSOC table to the description of the system.
• Incident post-mortem gap — incidents handled but post-mortems not consistently produced; remediate with a mandatory post-mortem template and a 7-day SLA for completion, tracked in the incident-management tool.
• Backup-and-restore evidence missing — backups taken but restore not exercised across the window; remediate with a quarterly restore-drill calendar item that produces a recorded RTO/RPO observation per drill.
• Vulnerability-scan trend absent — scans run but no trend evidence of mean-time-to-remediation; remediate by exporting scan results to a tracking dashboard that the CCM platform can pull from.

Cost of compliance#

SOC 2 cost has three layers: the auditor's fee, the readiness and remediation effort, and the continuous control monitoring tooling. The table below states typical USD ranges for a mid-sized US SaaS vendor in 2026. Big-Four pricing (Deloitte, PwC, EY, KPMG) is roughly 2-3x mid-tier pricing for the same scope; the substantive difference is brand and depth of testing, not the audit opinion itself. Most start-ups and mid-market vendors use mid-tier specialist firms (A-LIGN, Schellman, Coalfire, Prescient Assurance, Sensiba San Mateo) and reserve Big-Four for buyers who specifically require it.

Where this fits in the Yobitel stack#

Yobitel UK Sovereign holds SOC 2 Type II as part of its managed compliance posture, alongside ISO 27001:2022, ISO 27017 (cloud-services controls), ISO 27018 (PII processor controls), Cyber Essentials Plus and a documented NCSC Cloud Security Principles self-assessment. The Type II observation window runs on a 12-month cycle aligned to the company financial year; the report covers Security, Availability and Confidentiality TSCs, with AWS and the underlying datacentre providers treated as carved-out sub-service organisations.

Yobibyte — the self-serve AI platform — inherits the Yobitel UK Sovereign SOC 2 posture for all workloads running on Yobitel-managed infrastructure. A Yobibyte customer that needs a SOC 2 report to discharge its own user-entity vendor-risk obligations requests the Yobitel UK Sovereign Type II under NDA via the customer security portal; the report is delivered electronically with the current bridge letter if the latest window has closed. Customers operating their own SOC 2 engagement and using Yobibyte as a sub-service organisation cite Yobitel UK Sovereign in their description of the system; the complementary sub-service organisation controls are published as a public document.

Omniscient Compute, the federated marketplace for compute capacity, treats SOC 2 Type II as a provider-eligibility filter rather than a default. Providers participating in Omniscient Compute declare their SOC 2 posture (current Type II report, Type I only, or none) against the workload classes they are willing to host; the marketplace surfaces only SOC-2-Type-II providers when a workspace is flagged as requiring it. A buyer building on Yobibyte can absorb the SOC 2 evidence chain without contracting separately with the underlying provider — the marketplace contract carries the obligation through.

InferenceBench, the Yobitel benchmarking and evaluation platform, contributes CC4 (monitoring) and CC7 (system operations) evidence by maintaining a continuous, automated regression suite against model and infrastructure baselines. Benchmark runs are emitted into the same audit stream as control-plane events, supporting the CC4 monitoring evidence the SOC 2 auditor samples across the observation window.

Where Yobitel UK Sovereign and the customer share responsibility for SOC 2 evidence — as in every multi-tenant cloud relationship — the complementary user-entity controls are documented in the published shared-responsibility matrix. The matrix names the controls the customer must operate on its own side (typically: workload-level RBAC, in-application MFA enforcement, application-layer encryption keys, customer-side incident response). Treating that matrix as the contract between Yobitel's SOC 2 posture and the customer's own SOC 2 posture is how the chain remains defensible end-to-end.