SOC 2 Compliance Guide: 2026 Requirements & AI Controls

SOC 2 is an attestation, working differently to an ISO-style certification. An independent CPA firm audits an organisation's controls and issues an opinion on whether they meet the relevant Trust Services Criteria. There's a report, and buyers read it closely, rather than a pass-or-fail certificate.

The AICPA developed the framework to give enterprise buyers a standardised way to evaluate a service organisation's security and operational practices. It's widely used in the United States and increasingly required in UK financial services procurement.

Organisations select the non-mandatory criteria based on what they do and what clients expect. That selection decision carries real weight: confidentiality now appears in 64.4% of reports, according to the 2024 SOC Benchmark Study, up from 34% the year before. If a business processes customer data using AI, leaving Privacy out of scope is getting harder to justify.

SOC 2 Type I vs Type II

The audit produces one of two report types, and the distinction matters to buyers. Type I verifies that controls are suitably designed at a specific point in time: a snapshot answering whether the right controls exist today. Type II tests whether those controls operated effectively over a defined period, usually six to twelve months, answering whether they actually worked, consistently, throughout that window.

Most enterprise buyers require Type II because it demonstrates sustained performance rather than design intent alone. A Type I report can serve as a stepping stone, but it won't satisfy the procurement bar most regulated or enterprise buyers set.

SOC 2 carries no legal force in the UK or US. The commercial case makes the point on its own: most enterprise procurement processes for SaaS, cloud and managed services now treat SOC 2 Type II as a baseline requirement, and arriving without it means getting screened out before the technical evaluation even starts.

The confidentiality shift described above is driven by buyer pressure. Procurement teams are asking sharper questions about how vendors handle sensitive data, and they're reading the reports line by line rather than checking a box that says one exists. Organisations that treat SOC 2 as a one-off audit rather than a continuous programme build up a compliance debt that becomes visible the moment a buyer asks for the most recent Type II report at renewal.

UK-specific context

UK organisations increasingly see SOC 2 requested alongside ISO 27001, both by US-headquartered buyers and by UK financial services firms managing their own third-party oversight obligations. The FCA's Critical Third Parties regime (PS24/16), in force since January 2025, requires designated critical third parties to provide direct assurance to regulators, and it sits alongside the FCA's existing outsourcing rules that expect every regulated firm to document oversight of its technology suppliers. SOC 2 Type II, alongside ISO 27001, is among the most commonly accepted evidence formats for meeting that documented-oversight expectation.

Entities regulated under the EU's Digital Operational Resilience Act (DORA) need to consider how a SOC 2 report maps to their ICT third-party risk register as well. A current Type II report reduces the assessment burden for clients who are themselves subject to DORA oversight, because it gives them a structured, independently tested account of a supplier's controls rather than a self-reported questionnaire.

A verified Type II report also removes a common objection in enterprise sales. Security questionnaires that would otherwise take weeks of manual back-and-forth can be answered by reference to the report, which has a measurable effect on time-to-close for organisations selling into regulated buyers.

The criteria are stable. Auditor expectations aren't. The Trust Services Criteria were published in 2017 and revised in 2022, and no new version has been issued since. The AICPA hasn't formally rewritten the criteria to name AI, and claims that it has should be treated with caution: what's genuinely changed is how auditors interpret and apply the existing criteria, particularly around AI, vendor risk and evidence standards.

AI is drawing scrutiny under existing criteria

Any organisation using an LLM, AI agent or third-party model API for customer-facing or data-processing work should expect an auditor to ask about it. The AICPA has issued non-authoritative guidance acknowledging AI's growing role in service organisations, and practitioner firms including Baker Tilly report auditors folding AI system risk into the risk assessment, access control and vendor management criteria that already exist (broadly CC3, CC6, CC7 and CC9), rather than waiting for a dedicated AI criterion. "We use a major AI provider" is no longer treated as a sufficient control narrative on its own.

Auditors are increasingly asking for named owners, change-control approvals, AI system inventories and vendor risk assessments for every model called via API. The burden sits with the organisation to show that its AI systems are governed, rather than assumed safe because they come from a recognised provider.

The evidence bar is higher

Static screenshots of cloud consoles are increasingly challenged as evidence for configuration controls. Auditors now look for continuous-monitoring exports or programmatic evidence, such as cloud configuration snapshots or SIEM log exports, with timestamps proving controls operated throughout the audit window rather than only on the day the evidence was pulled. Point-in-time evidence collection at year-end is no longer enough to support a credible Type II report; the observation window covers the full audit period, and the evidence needs to cover it too.

Vendor and subservice scrutiny has increased

Auditors push back on reports that leave out subservice providers. Vendor management testing increasingly includes AI vendor governance as part of the review, so organisations relying on third-party infrastructure, SaaS tooling or model APIs need to document those relationships, assess the risk and produce evidence of ongoing oversight rather than a static supplier list.

None of this changes what SOC 2 formally requires. It changes what a credible answer looks like, and organisations building controls to survive scrutiny, rather than the minimum needed to pass a lighter-touch audit, are the ones that will move through renewal without a scramble.

To achieve SOC 2, an organisation implements and maintains controls across whichever Trust Services Criteria it has scoped. The AICPA specifies the required outcome and leaves the implementation approach to the organisation, and that flexibility is deliberate. It's also where organisations trip up, building controls that satisfy the letter of the criteria while failing to produce the evidence an auditor actually needs.

Core security controls

Every SOC 2 engagement requires controls addressing the Security criterion. Common controls include:

1. Role-based access control (RBAC) with documented provisioning and de-provisioning processes.
2. Data encryption in transit and at rest.
3. Continuous monitoring and logging of system events.
4. Incident response and recovery plans with tested procedures.
5. Risk assessments covering systems, vendors and, in 2026, AI tools.
6. Documented security policies with evidence of staff training and acknowledgement.

Controls that exist on paper but can't be evidenced fail to hold up in a Type II audit. Automated controls need continuous monitoring logs rather than a screenshot taken the week before the audit; manual controls need attestations from named owners, supported by targeted testing at defined intervals; vendor controls need documented assessments that go beyond a supplier list. That distinction, between a documented control and an evidenced one, is exactly what the next section covers.

Scoping decisions

Scope affects the cost, complexity and commercial value of a SOC 2 report. A narrower scope is easier to achieve but may not satisfy buyers who want assurance across the full service delivery environment. Key considerations include which systems process, store or transmit customer data, which subservice organisations would affect commitments if they failed, whether AI systems processing customer data should be scoped in explicitly (auditors increasingly scope them in regardless), and whether Confidentiality and Privacy are warranted given the service and buyer base.

Evidence quality is where most SOC 2 Type II programmes fall short. The question practitioners ask most often has shifted from "what controls do I need?" to "what evidence will actually satisfy my auditor?", and the answer has moved with it.

Static screenshots, access control lists exported on a single day and policy documents with no version history are increasingly challenged. Auditors running Type II engagements need to see that controls operated throughout the observation window, well beyond the day someone gathered the evidence. The accepted standard in 2026 is continuous-monitoring exports: cloud configuration snapshots showing configuration states across the audit period, timestamped queries, and SIEM log exports covering the full window rather than a sample.

Automated and manual controls need different evidence. Automated controls should produce continuous monitoring logs: an access control that's configured correctly but never tested during the observation period fails to qualify as a functioning automated control in an auditor's view. Manual controls need attestations from named owners, backed by targeted tests at defined intervals; a quarterly access review needs a documented completion record showing the review actually happened.

SureCloud's Continuous Controls Monitoring automates evidence collection throughout the observation window, producing audit-ready outputs that cover the full audit period rather than a point-in-time snapshot, and cuts audit preparation time by 75%. Gracie AI Agents with Personas and Skills handle the evidence chasing behind that automation, collecting, timestamping and linking evidence to named control owners without someone working through the list by hand, which cuts manual evidence collection by 50 to 65%. The package an auditor receives reflects how controls actually operated, not how they looked on export day.

A licensed CPA firm conducts the audit, evaluating controls against the scoped Trust Services Criteria and issuing a report based on its findings. Auditors apply professional judgement throughout, so the quality of the evidence supplied shapes the quality of the report.

1. Define the scope: Identify the systems, teams and Trust Services Criteria relevant to the engagement. Narrowing scope reduces cost and complexity, but don't exclude systems that buyers will expect to see covered.
2. Run a readiness assessment: Identify control gaps before the formal audit begins, ideally against a pre-mapped control framework rather than a blank page.
3. Remediate gaps: Implement or update controls, policies and documentation. Remediation takes longer than most teams expect, especially for vendor risk and AI governance controls.
4. Open the observation window: For a Type II report, controls need to operate effectively throughout the observation period, usually six to twelve months, and the window can't be shortened after the fact.
5. Gather audit evidence: Continuous monitoring logs, policy documents, access reviews and vendor assessment records, covering the full observation window.
6. Complete the independent audit: The CPA auditor tests the evidence, requests anything missing and issues the final report.
7. Maintain compliance: Controls need to keep operating between audits, since gaps here surface immediately in the next review.

Common mistakes to avoid

Starting too late causes the most damage. A Type II audit needs a minimum six-month observation period, and once readiness assessment and remediation time gets added, most organisations need nine to twelve months from decision to report.

Treating compliance as a one-time task is the second most common error: controls that lapse between audits show up in the next report, so continuous compliance stays essential for organisations renewing Type II annually. Manual tracking in spreadsheets doesn't scale either; evidence goes missing, reviews get skipped, and control gaps build up quietly. Vendor risk deserves the same weight as internal controls, treated as a core part of the programme rather than an afterthought.

SOC 2 applies to any service organisation handling third-party data in the cloud, but the commercial and regulatory drivers differ by sector, and the criteria scoped in should reflect what buyers in that sector expect.

SaaS and cloud providers

Enterprise procurement teams now treat SOC 2 Type II as a baseline. Arriving at a vendor security review without a current report means exclusion from the shortlist entirely, ahead of any scoring. AI governance controls add a new requirement for SaaS providers using LLMs in their product: auditors now examine model risk controls, AI vendor assessments and shadow AI detection alongside the underlying infrastructure.

Financial services

UK financial services firms manage third-party risk obligations under the FCA and PRA's operational resilience framework, including the Critical Third Parties regime referenced above. SOC 2 Type II, alongside ISO 27001, is among the most commonly accepted evidence formats for satisfying that oversight. DORA-regulated entities operating in the EU need to consider how SOC 2 maps to their ICT third-party risk register too. SureCloud's Third-Party Risk Management supports organisations managing both SOC 2 vendor obligations and DORA third-party requirements from a single platform.

Professional services and managed service providers

Managed service providers increasingly appear as subservice organisations in their clients' SOC 2 reports, which creates a chain of assurance: an MSP's controls affect its clients' reports directly. An MSP with weak access controls or undocumented vendor relationships creates a material risk for every client whose report names it as a subservice provider, so MSPs need their own SOC 2 programme rather than familiarity with the framework they help clients achieve.

Healthcare and HealthTech

SOC 2 Privacy criteria align closely with UK GDPR obligations. For organisations processing health data, scoping in Privacy is close to standard practice given ICO enforcement trends, and organisations using AI to process health data face scrutiny under both the Privacy criterion and the AI-related questions auditors now raise under the existing risk, access and vendor criteria.

SOC 2 is a control programme that operates continuously, producing evidence an independent auditor can rely on year-round. Organisations that treat it as an operational discipline get there faster than those that treat it as a project.

1. Step 1: review the Trust Services Criteria and select scope
   Security is mandatory. For most organisations handling sensitive customer data in 2026, Confidentiality is a strong candidate, and Privacy belongs in scope if personal data is processed using AI.
2. Step 2: define the audit scope
   Identify the systems, teams and third parties inside the engagement boundary, including subservice organisations. Exclude nothing buyers will expect covered.
3. Step 3: map your controls
   Use a pre-built framework aligned to the criteria rather than starting from a blank sheet. SureCloud's Compliance Management includes a pre-mapped SOC 2 control set, and controls mapped once apply automatically across other standards including ISO 27001, NIST CSF 2.0 and GDPR.
4. Step 4: build evidence workflows
   Decide how evidence gets collected, stored and produced for each control. Automated controls need continuous monitoring outputs; manual controls need attestation records. Both need timestamps and named owners.
5. Step 5: choose a qualified auditor
   Work with a licensed CPA firm experienced in the industry. Auditor familiarity with AI governance and cloud infrastructure matters more each year, so ask prospective auditors directly how they're approaching AI system scoping.
6. Step 6: maintain compliance between audits
   A Type II report covers a set observation period, and controls need to keep operating after it's issued: continuous compliance is what keeps year two easier than year one.

For smaller organisations starting the journey, SureCloud Foundations provides a pre-built compliance toolkit covering ISO 27001 and SOC 2, with automated evidence collection and continuous controls monitoring built in.

Many UK organisations pursue both frameworks. They address overlapping security control domains but serve different purposes, and understanding the distinction prevents duplicated effort.

ISO 27001 carries European market credibility; SOC 2 satisfies US buyer requirements and, increasingly, UK financial services procurement. The control domains overlap enough that mapping them once and applying the result across both frameworks cuts duplication and audit burden meaningfully. SureCloud's SOC 2 framework page sets out how the platform maps to the Trust Services Criteria in detail, and evidence collected for ISO 27001 also populates the SOC 2 evidence library from the same control set.