A UK SaaS company does not need to move its business to the United States to produce a SOC 2 report. It needs a defined service, controls that operate in that service, and an independent examination by an eligible CPA firm. The reason the request feels unfamiliar is commercial: SOC 2 is a US-origin assurance product, while UK and European buyers more often recognise ISO 27001, Cyber Essentials or a customer-specific security review.
Start with the buyer’s wording. Ask whether they require Type I or Type II, which Trust Services Criteria they expect, how recent the report must be, and whether they accept a bridge letter while the next examination is underway. “SOC 2 required” is not a sufficiently detailed project brief.
Why a UK company ends up needing a US-style attestation
US enterprise procurement teams often use a SOC 2 report as a standardised substitute for reviewing every supplier from scratch. Their security questionnaire, contract playbook and cyber-insurance process may all refer to the AICPA Trust Services Criteria. A report gives their security team an auditor’s opinion on a defined system and period, which is easier to compare than a collection of policies.
This is usually a customer requirement, not a statutory obligation. A US prospect can ask a UK vendor for SOC 2 because the vendor will host customer data, connect to internal systems, or support a business process that the customer must defend to its own auditors. The request might appear late because the commercial sponsor and technical buyer are different people. Treat it as a sales-risk event: clarify the acceptance criteria, deadline and interim evidence before spending on an unnecessarily broad programme.
SOC 2 does not replace UK GDPR, the Data Protection Act 2018, or your contractual security duties. Privacy is one optional Trust Services Criterion, and even a SOC 2 Privacy report does not make a controller-processor arrangement compliant by itself. Maintain your data-processing agreements, international-transfer analysis and rights procedures separately. The main SOC 2 guide explains how the report fits beside other frameworks.
Practical steps for a UK SaaS SOC 2 programme
- Translate the customer request. Get the exact procurement policy, required report date, acceptable observation period, criteria, report-sharing method and remediation expectations. Ask if a Type I can unblock onboarding while Type II evidence accumulates.
- Define the system boundary. Identify the production application, cloud accounts, repositories, CI/CD pipeline, support tools, offices, personnel and subprocessors that can affect customer data. Keep development experiments outside scope only when they genuinely cannot affect the service.
- Record the data story. Document where customer data is collected, stored, backed up, accessed and deleted; which regions and subprocessors are involved; and which data is encrypted in transit and at rest. This supports both the system description and the customer’s GDPR questions.
- Assess current controls. Check MFA and privileged access, joiner-mover-leaver records, quarterly access reviews, vulnerability remediation, change approvals, backup restoration, incident response, supplier due diligence and security training. Evidence of an informal process is useful, but it must be repeatable.
- Choose criteria and report type. Security is required. Add Availability when uptime and resilience are contractual promises; add Confidentiality when the customer entrusts sensitive information; add Privacy or Processing Integrity only where the service and buyer require them.
- Run readiness before fieldwork. Close design gaps, assign owners, establish evidence collection and perform a mock request cycle. Starting a Type II window before controls are stable creates months of weak evidence and avoidable exceptions.
- Operate and communicate. During the observation period, keep a calendar for recurring controls, log exceptions, and tell the customer promptly when the promised report date changes. A dated plan is more credible than an unsupported claim that the audit is “nearly done.”
Using a UK/EU auditor versus a US auditor
The important question is not the auditor’s postcode. A SOC 2 report must be issued by an independent CPA firm authorised to perform SOC engagements under the AICPA framework. Many international firms have UK or EU teams that conduct SOC 2 work for European service organisations; some US firms work with UK clients remotely. Ask for examples of reports for companies with a similar scope, clarity on independence, the exact criteria covered, and who will perform testing.
Confirm the firm’s report format before signing. The customer may ask for a SOC 2 Type II report under the current AICPA description criteria, a particular service auditor’s report, or an additional ISAE 3000 opinion for European stakeholders. An ISO certification body cannot issue your SOC 2 report merely because it audits ISO 27001. Conversely, an AICPA CPA firm’s SOC 2 engagement does not certify your ISMS.
Use a readiness consultant separately from the auditor where independence rules or your customer’s procurement policy require it. The consultant can organise controls, prepare evidence and help manage requests; the independent auditor decides what testing is sufficient and writes the opinion. Never ask the readiness team to promise a clean opinion.
Invoices, currency and time zones
Budget for two distinct suppliers: readiness support and the audit firm. Audit quotes may be in US dollars, pounds or euros and may exclude travel, penetration testing, platform subscriptions, bridge letters or an additional criterion. Ask whether the quote is fixed for the defined scope, what happens if the system boundary changes, and whether report updates or a subsequent examination are priced separately.
Currency conversion can obscure a real project cost. Keep the commercial proposal, purchase order and payment schedule explicit about currency, VAT, withholding tax and bank fees. A UK company paying a US supplier may need to check its own tax and finance treatment; that is an accounting question, not a SOC 2 control. Do not let an attractive headline audit fee hide six months of internal engineering and operations time.
Time zones matter during fieldwork. Agree a primary contact, evidence-request deadline, standing call time and escalation path. A UK team can usually support US working hours with one weekly overlap, but a distributed team should nominate an owner who can answer an auditor’s question without waiting for three regions to wake up. Store evidence in a controlled workspace with clear file names and retention rules rather than passing sensitive exports through ad hoc email.
Type I or Type II for the first customer?
Type I examines whether controls are suitably designed and implemented at a point in time. It can be a rational first report when a customer needs independent assurance within a quarter, accepts it in writing, and your programme is newly formalised. Type II examines operating effectiveness across a defined observation window, commonly three to twelve months. It is normally what a mature enterprise buyer means by “current SOC 2.”
| Question | Practical answer |
|---|---|
| Customer deadline under 90 days? | Ask whether Type I or an audit-in-progress letter is accepted; do not promise Type II without its observation period. |
| Customer says “Type II only”? | Confirm required window and report age, then plan readiness before the window starts. |
| Existing ISO 27001? | Reuse risk, access, change and supplier evidence, but map it to SOC 2 requests rather than assuming transfer. |
| Several US prospects? | Choose a scope and criteria that answer the common requirement, not a bespoke report for every prospect. |
Read SOC 2 Type I vs Type II for startups before deciding. If the customer date is tight, the realistic audit timeline helps sales and engineering work from the same assumptions.
What evidence will a UK SaaS auditor request?
Expect evidence that controls happened, not just that a policy says they should happen. Examples include user and administrator exports, access-review sign-offs, ticket links for code and infrastructure changes, vulnerability scan results, incident and exercise records, backup tests, vendor assessments, security training completion and board or management review notes. Evidence should identify the period, owner, system and result, with exceptions explained rather than deleted.
Design the evidence workflow before the audit. A compliance platform can collect some cloud and identity evidence, but it cannot decide whether a change was properly approved or whether a supplier’s risk is acceptable. Keep source records in systems engineers already use, add a control owner and review cadence, and export a legible pack. The SOC 2 evidence checklist is organised by Trust Services Criteria and can be used in a kickoff workshop.
UK SaaS SOC 2 FAQs
Does a UK company need a US entity?
No. The report concerns a service organisation and a defined system, not its country of incorporation. You do need an eligible independent CPA firm and a report that matches the customer’s requirement.
Can ISO 27001 satisfy the customer?
Sometimes a customer will accept it, but only if its procurement policy says so. ISO 27001 certification and SOC 2 attestation are different deliverables. Ask for written acceptance rather than assuming equivalence.
Can the report cover EU-hosted data?
Yes. Hosting region and transfer arrangements should be accurately described. SOC 2 does not remove UK GDPR obligations, so maintain your data-processing and international-transfer documentation.
How long should we plan?
Type I often takes six to twelve weeks after readiness for a small, controlled scope. Type II adds a three-to-twelve-month observation period. Auditor availability and evidence maturity can extend either route.
Need to answer a US customer's SOC 2 request?
Bring the customer email, deadline and current evidence. We will map the scope, report type and next steps in a 45-minute working session.
Book a 45-minute working session →