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.

Warning: Scope creep is the single most common cause of SOC 2 cost overrun. Lock the system description, the TSC categories and the sub-service-organisation treatment (carve-out vs inclusive) before the auditor's readiness assessment, not after. Changing scope mid-engagement typically adds 30-50% to the fee and pushes the report date by a quarter.

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.

Category	Mandatory?	What it covers	Typical engagement
Security (Common Criteria)	Yes	Protection of the system against unauthorised access, unauthorised disclosure of information, and damage to systems.	Always included — the baseline of every SOC 2 engagement.
Availability	Optional	The system is available for operation and use as committed.	Added by any SaaS where uptime is a contractual commitment.
Processing Integrity	Optional	System processing is complete, valid, accurate, timely, and authorised.	Added by payments, billing, transaction processing, ETL vendors.
Confidentiality	Optional	Information designated as confidential is protected as committed.	Added by vendors that hold material non-public information (financial data, IP, trade secrets).
Privacy	Optional	Personal information is collected, used, retained, disclosed and disposed of in conformity with the entity's privacy notice.	Added by US-resident SaaS handling personal data; pairs with HIPAA, state privacy laws, or GDPR for transatlantic operations.

Note: The Common Criteria align with the COSO Internal Control - Integrated Framework. CC1-CC5 mirror COSO's five components (Control Environment, Risk Assessment, Control Activities, Information & Communication, Monitoring). CC6-CC9 are the cloud-and-tech-specific extensions added by the AICPA. Treating the CC1-CC5 mapping as 'COSO that you already do' and CC6-CC9 as 'the new operational work' is a useful planning frame.

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.

Criterion	Operative obligation	Sampled evidence	System / tool
CC1 — Control Environment	Board oversight, code of conduct, organisational structure, named accountable executives.	Board minutes, signed code-of-conduct attestation, org chart with named CISO / DPO.	Board portal; HRIS; intranet.
CC2 — Communication	Internal and external communication of security objectives, roles and incidents.	Security policy distribution log, incident-comms templates, status-page archive.	Knowledge base; Statuspage / Atlassian; email-distribution audit.
CC3 — Risk Assessment	Annual entity-level risk assessment; threat modelling on material changes; fraud risk.	Risk register with owners and review dates; threat-model artefacts; fraud-risk minutes.	Vanta / Drata / Secureframe; in-house GRC; Confluence / Notion.
CC4 — Monitoring	Ongoing and separate evaluations of control operation; reporting of deficiencies.	Internal-audit reports, control test results, deficiency log, remediation closure trend.	Internal audit platform; GRC tool; ticketing system.
CC5 — Control Activities	Documented control activities deployed through policies and procedures.	Policy library with version control; control matrix mapping policies to criteria.	Policy management platform; documentation site under version control.
CC6 — Logical & Physical Access	Identity, MFA, RBAC, joiners/movers/leavers, encryption at rest and in transit, physical-access logs.	Access-provisioning tickets, quarterly access-review evidence, MFA-enforcement screenshots, encryption-config attestation, badge-system reports.	OIDC / SAML IdP (Okta, Azure AD); IAM logs; cert-manager; cloud KMS; physical-access system.
CC7 — System Operations	Vulnerability scanning, change detection, incident response, communication of security incidents.	Vulnerability scan cadence and trend, patch SLA reports, incident post-mortems, security-incident comms log.	Trivy / Grype / Snyk; Falco; PagerDuty / Opsgenie; post-mortem repository.
CC8 — Change Management	Authorised, tested, approved and documented changes to production systems.	Pull-request approval records, deployment logs, test evidence, emergency-change exception log.	GitHub / GitLab; CI/CD pipeline; deployment tracker (Argo CD, Spinnaker).
CC9 — Risk Mitigation	Vendor-risk assessment, business continuity planning, response to identified vulnerabilities.	Vendor due-diligence files, BCP / DR test reports, vulnerability-closure tracking.	Vendor-management platform; DR-test runbooks; vulnerability tracker.
A1 — Availability	Capacity planning, environmental protection, recovery from incidents.	SLO dashboards, capacity-planning artefacts, DR-test reports with RTO/RPO observed.	Prometheus / Grafana; cloud auto-scaling; DR runbooks.
C1 — Confidentiality	Identification, protection and disposal of confidential information.	Data-classification policy, encryption attestation, secure-disposal certificates.	DLP tooling; KMS; certified-disposal vendor records.
PI1 — Processing Integrity	Complete, accurate, timely, authorised processing.	Reconciliation reports, input/output validation evidence, exception-handling logs.	Application audit logs; reconciliation jobs; data-quality monitors.
P1-P8 — Privacy	Notice, choice, collection, use/retention/disposal, access, disclosure, quality, monitoring of personal information.	Privacy notice, consent records, retention-schedule evidence, subject-access-request log.	Privacy management platform; consent management; DSAR workflow.

Tip: Use a continuous control monitoring (CCM) platform — Vanta, Drata, Secureframe, Sprinto, Tugboat Logic — to capture evidence automatically across the observation window rather than scrambling at audit time. CCM platforms reduce audit-prep effort by 40-60% and turn evidence into a continuous stream rather than an annual fire-drill. Budget $15,000-$75,000/year for the tool depending on scope.

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.

Report section	Author	Contains	Why it matters
Section I — Independent Service Auditor's Report	Auditor	The auditor's formal opinion; scope statement; basis for opinion.	This is what user entities read first. An unqualified opinion is the trust signal.
Section II — Management's Assertion	Service organisation	Management's signed statement that the description is fairly presented and the controls met the TSC.	The legal hook for the engagement; required by AT-C 105.
Section III — Description of the System	Service organisation	System boundaries, infrastructure, software, people, processes, data, sub-service organisations, complementary user-entity controls.	User entities read this to understand whether the product they use is in scope.
Section IV — Trust Services Criteria, Controls, Tests and Results	Service organisation + auditor	Each TSC criterion, the controls in place, the tests performed, the results, and any exceptions.	The detailed evidence. A user entity's security team reads this to understand specifically what was tested.
Section V — Other Information (optional)	Service organisation	Additional information not covered by the auditor's opinion.	Used for forward-looking statements, ongoing initiatives, planned improvements. Read with caution — it is unaudited.

Warning: Avoid 'bridge letter' over-reliance. Between the end of one observation window and the issue date of the next report, vendors issue a bridge letter (gap letter) attesting that no material changes have occurred. A bridge letter is a stop-gap, not a substitute for a current Type II report. User entities that ask for a SOC 2 Type II will accept a bridge letter for up to three months; beyond that, they will press for the new report.

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.

SOC 2 area	ISO 27001:2022 Annex A	NIST CSF 2.0	NCSC Cloud Security Principles	HIPAA Security Rule
CC1 — Control Environment	Clauses 5, 6 (Leadership, Planning)	GV — Govern	Principle 4 (Governance framework)	§ 164.308(a)(1) Security Management
CC2 — Communication	A.5.10, A.5.14 (Acceptable use, Information transfer)	GV.CO — Communications	Principle 14 (Secure use of service)	§ 164.308(a)(5) Awareness & Training
CC3 — Risk Assessment	A.5.9, A.5.13, Clause 6.1.2 (Risk assessment)	ID.RA — Risk Assessment	Principle 4 (Governance framework)	§ 164.308(a)(1)(ii)(A) Risk Analysis
CC4 — Monitoring	A.5.35 (Independent review), Clause 9 (Performance evaluation)	DE — Detect	Principle 13 (Audit information)	§ 164.308(a)(8) Evaluation
CC5 — Control Activities	A.5.36 (Compliance with policies), Clause 8 (Operation)	PR.PO — Policies	Principle 14 (Secure use of service)	§ 164.316 Policies and Procedures
CC6 — Logical & Physical Access	A.5.15-A.5.18, A.8.2-A.8.5 (Access control), A.7.x (Physical)	PR.AC — Identity Mgmt & Access Control	Principles 9, 10 (User mgmt, Identity & auth)	§ 164.312(a)(1) Access Control
CC7 — System Operations	A.8.7, A.8.8, A.8.16 (Malware, vulnerabilities, monitoring)	DE.CM — Continuous Monitoring	Principle 5 (Operational security)	§ 164.308(a)(1)(ii)(D) Information System Activity Review
CC8 — Change Management	A.8.32 (Change management)	PR.IP-3 — Change control	Principle 5 (Operational security)	§ 164.308(a)(7) Contingency Plan
CC9 — Risk Mitigation / Vendor Mgmt	A.5.19-A.5.23 (Supplier relationships)	GV.SC — Cybersecurity Supply Chain	Principle 8 (Supply chain security)	§ 164.308(b) Business Associate Contracts
A1 — Availability	A.5.30, A.8.13, A.8.14 (Backup, ICT readiness)	RC.RP — Recovery Planning	Principle 2 (Asset protection & resilience)	§ 164.308(a)(7) Contingency Plan
C1 — Confidentiality	A.5.12, A.8.10, A.8.24 (Classification, deletion, cryptography)	PR.DS — Data Security	Principle 1 (Data in transit), Principle 2 (Asset protection)	§ 164.312(a)(2)(iv) Encryption
PI1 — Processing Integrity	A.8.29 (Security testing in development)	PR.DS-6 — Integrity checking	Principle 11 (External interface protection)	§ 164.312(c)(1) Integrity
P1-P8 — Privacy	A.5.34, A.8.11 (PII processing, Data masking); ISO 27018	GV.PO-3 — Privacy	Principle 8 (Supply chain), GDPR Article 32 (cross-ref)	Privacy Rule (separate from Security Rule)

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.

Warning: A qualified opinion ('controls operated effectively except for X') is recoverable but expensive in market terms — user entities will press on the exception and may delay procurement. An adverse opinion or disclaimer is a market-credibility event; recovery typically takes a full additional observation window to demonstrate remediated controls. Invest in readiness rather than relying on the auditor's discovery process.

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.

Cost line	Typical annual range (USD)	Notes
SOC 2 Type I — first year (mid-tier firm)	$19,000 - $37,500	Stepping-stone before Type II; covers Security TSC; 4-6 week engagement.
SOC 2 Type II — first year (mid-tier, 6-month window)	$44,000 - $112,000	Security + Availability + Confidentiality scope; readiness consulting may be bundled.
SOC 2 Type II — subsequent years (12-month window)	$37,500 - $94,000	Steady-state; CCM tooling reduces effort year-over-year.
SOC 2 Type II — Big-Four equivalent	$100,000 - $250,000	Required by some Fortune 100 buyers; brand premium dominates the price differential.
Readiness consulting (year 1)	$25,000 - $80,000	Optional but recommended for first-time engagements; bundles with auditor where firms offer it.
Adding Processing Integrity or Privacy TSC	$12,500 - $37,500 additional	Per category, per engagement; Privacy is the highest because of personal-data scope.
Continuous control monitoring platform (Vanta, Drata, Secureframe)	$15,000 - $75,000	Annual SaaS fee; scope-dependent; reduces audit-prep effort 40-60%.
Penetration testing (annual minimum)	$25,000 - $75,000	Not strictly required by SOC 2 but routinely expected by user entities; CC4/CC7 evidence.
Compliance + security engineering FTE (loaded)	$112,000 - $225,000 per FTE	Realistic floor: 0.5-1 FTE for steady-state Type II; 1-2 FTE in the readiness year.
Bridge letter (gap letter) between observation windows	$1,900 - $5,000	Auditor-issued attestation that no material changes have occurred; bridges up to ~3 months.

Tip: Budget tip — fold SOC 2 cost into the gross margin model rather than treating it as a fixed overhead. For a SaaS vendor doing $5M-$20M ARR, total annual SOC 2 cost (auditor + CCM + 1 FTE) typically sits at $250,000-$400,000, which is 1-2 percentage points of gross margin. That is the cost of being eligible to sell to US enterprise — without it, the addressable market shrinks by 60-80%.

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.