SOC 2 audit: who performs it, how long it takes and what happens

Your US prospect's security team has asked for a SOC 2 report, and procurement will not sign until it arrives. You have never been through a SOC 2 audit, and three questions land at once: who can do it, how long it will take, and what happens once it starts.

This guide answers them for founders, COOs and security leads at UK B2B tech firms with 25 to 100 staff, many of whom already hold ISO 27001. It covers who can perform the audit and how a UK firm engages one, each stage from kickoff to report, first-audit timelines, how often the audit recurs, how to answer an exception, and which ISO 27001 evidence carries over.

What is a SOC 2 audit?

A SOC 2 audit is an attestation examination performed by an independent, licensed CPA firm under AICPA attestation standards. It ends in a report, not a certificate. We recommend planning for a first Type 1 report about three to six months after kickoff, and a first Type 2 report about six to twelve months after kickoff.

For what SOC 2 covers and the five trust services categories, start with our SOC 2 hub. This guide picks up where that one stops: the audit itself.

The AICPA is precise about the label. In a Journal of Accountancy podcast on SOC engagements, its vice president for assurance and advisory innovation calls SOC 2 "an examination-level attestation engagement signed off on by a licensed CPA". Buyers say "audit", and so does this guide.

The CPA firm examines your system description and your controls, then gives an opinion on them. The report that results holds that opinion, your management's assertion, the description and, for a Type 2, the tests and their results. Reading the finished report is a separate skill with its own guide.

Who performs a SOC 2 audit, and how do you choose a SOC 2 auditor?

Only a licensed CPA firm can perform a SOC 2 audit and sign the report. A UK firm can engage a US CPA firm directly, or a UK practice that arranges for a licensed firm to sign. Either way, confirm who will sign. Where your customer accepts an alternative, ISAE 3402 is the international standard for service organisation reports.

The licensing rule is a legal one, not a convention. The same AICPA podcast explains that these engagements "are required under state law to be performed by licensed CPAs", under the Uniform Accountancy Act definition of attest. The AICPA's SOC logo guidelines for service organisations also refer to reports "from a licensed CPA or a non-U.S. equivalent".

For a UK firm, that leaves two practical routes:

• A US CPA firm, engaged directly. The examination runs under the same AICPA standards wherever your team sits, and fieldwork can be planned around the time difference.
• A UK accountancy practice. Ask which licensed entity will sign the SOC 2 report, under which licence, and whose peer review covers the work. Get the answer in writing before you sign the engagement letter.

There is also a UK-native alternative. ICAEW's guide to assurance standards describes ISAE 3402 as the standard "for practitioners engaged to give an assurance report on internal controls at service organisations". ICAEW's AAF 01/20 adds guidance for service auditors reporting on the services a service organisation performs. Some US customers ask for SOC 2 by name, so check what they will accept before you choose.

To choose between firms, the AICPA's Journal of Accountancy article on "fast and easy" SOC reports suggests clients:

1. Vet the firm's size, capacity and client references.
2. Check its qualifications, experience and peer review results.
3. Ask about the scope of the examination, the sampling it will use and how it stays independent.
4. Ask whether the offer is unrealistically fast, easy or cheap.

Speed is the one thing you should not shop for in an auditor.

The AICPA is acting on the same concern. Its peer review guidance on SOC 2 risks tells reviewers to look at "the reasonableness of SOC 2 engagement timelines" when they inspect a firm's SOC 2 work. Fees follow scope and hours, and our SOC 2 audit cost guide covers what drives them.

What is the SOC 2 audit process, step by step?

The SOC 2 audit process runs in five stages: planning and engagement, scoping from your system description, fieldwork and testing, management's written assertion and representations, and the report. Your team owns the description and the assertion. The CPA firm owns the testing and the opinion. Each stage needs a named owner and evidence ready on request.

The AICPA's Journal of Accountancy guide to SOC 2 engagements sets out what management owns: defining the scope, choosing Type 1 or Type 2 "depending on the needs of users", setting the period for a Type 2, giving a written assertion and giving written representations to the auditor. The table shows where each of those lands.

Two of those stages start before the auditor arrives. The gaps should already be closed, which is the job of a readiness assessment, and the system description should already be written, which is its own piece of work. The audit only tests what exists.

Fieldwork is where most of the calendar goes. Expect requests in three forms:

• Populations. Full lists, such as every joiner, leaver or production change in the period.
• Samples. Records for the items the auditor picks from those lists.
• Walkthroughs. A control owner showing how a control runs, from trigger to record.

The 2011 guide also says the auditor should agree with management that use of the report "will be restricted" to identified users. That restriction is why customers receive the report under NDA.

How long does a SOC 2 audit take for a first Type 1 and Type 2?

There is no fixed duration for a SOC 2 audit. As GRCMANA planning guidance, allow about three to six months from kickoff to a first Type 1 report, and six to twelve months to a first Type 2. The difference is the observation period, which a Type 2 must complete before the auditor can test it and report.

The ranges below are GRCMANA planning guidance, not AICPA rules. Your CPA firm, your evidence and your customer's deadline will move them.

AICPA guidance sets no fixed length for a Type 2 period. The 2011 guide says there is "no generally accepted minimum useful period", and that the period must be long enough for an opinion and for the needs of report users. Choosing the report type and timing the window have their own guide: SOC 2 Type 1 vs Type 2.

Three things stretch a SOC 2 audit more than any other:

• Slow evidence. Each request that waits a week moves the report date by a week.
• A description that changes mid-fieldwork. The auditor has to re-plan the tests.
• Unavailable control owners. Walkthroughs need the people who run the controls, not a stand-in.

How often do you need a SOC 2 audit?

Plan for a SOC 2 audit every year. Customers expect a current report, and the AICPA says the examination should be repeated annually because systems change. After the first Type 2, we recommend back-to-back 12-month periods, with a bridge letter covering the months between one period's end and the next report.

The AICPA put it plainly in the same podcast: "it's also important that the services be done annually as things can change over time." A SOC 2 audit is a cycle, not a project.

In practice, the rhythm looks like this:

1. Year one. A first Type 2 period of about three months, then testing and the first report.
2. Year two onwards. A 12-month period that starts the day after the last one ended, so there is no gap.
3. Between reports. A bridge letter for customers who review you after a period has ended but before the next report arrives.

Bridge letters are a recognised part of reviewing a SOC 2 report. The AICPA's SOC 2 report walkthrough course covers them alongside exceptions. We recommend timing your period end so the report lands before your largest customers' annual reviews.

A gap between report periods is a question your customer will ask in writing.

What is a SOC 2 audit exception, and how do you respond to one?

A SOC 2 audit exception is a test result showing that a control did not operate as described for part of the sample or period. Exceptions appear in a Type 2 report's test results, often with a response from management. An exception is not a failed audit, but every customer reviewer will read it and judge your response.

Exceptions come from ordinary lapses, not dramatic failures. Typical examples include:

• a quarterly access review that ran late or left no record;
• a leaver whose access was removed days after their last day;
• a production change deployed without the recorded approval your procedure requires;
• a security training record missing for a new joiner.

An exception is also not the same as a qualified opinion. Whether the auditor modifies the opinion depends on how much the problems matter, and the opinion types are explained in our guide to reading the report.

We recommend handling an exception in five steps:

1. Confirm the facts during fieldwork. Ask the auditor for the sample item and the test, and agree what happened before the draft report.
2. Find the cause. A late review usually has a cause, such as an owner who left or a reminder that nobody receives.
3. Fix it and date the fix. Change the process, then produce a record that shows the fixed control running.
4. Write the response. State what happened, why, what changed and from what date, in three or four plain sentences.
5. Check it next period. The same control will be tested again, and a repeat reads very differently from a first.

An exception with a specific fix reads as control; a vague response reads as luck.

What ISO 27001 evidence can you reuse in a SOC 2 audit?

Most ISO 27001 evidence carries into a SOC 2 audit: risk assessments, policies, asset and supplier registers, access reviews, incident records, internal audit reports and management review minutes. What changes is the test. A SOC 2 Type 2 auditor samples records across the whole period, so evidence must exist for every occurrence, not only the latest.

If you run an ISO 27001 management system, the table shows how the same records serve a SOC 2 auditor.

Your team's audit experience transfers too. If you have been through the ISO 27001 certification process, you already know how to answer an auditor's request with a record. The difference is the period: a Stage 2 auditor samples to confirm the system runs, while a SOC 2 Type 2 auditor tests that it ran throughout.

What are the common mistakes in a SOC 2 audit?

The common mistakes in a SOC 2 audit are booking the auditor before readiness, choosing a firm on speed or price, letting the system description drift from reality, writing vague responses to exceptions and leaving a gap before the next period. Each one costs time with the customer, and some cost a whole report period.

• Booking fieldwork before the gaps are closed. The audit then finds what a readiness check would have found, and the findings go in the report.
• Choosing on turnaround. A firm that promises a report in days is offering the very thing the AICPA's peer reviewers now examine.
• A description written for the auditor, not the service. If the description and the operation differ, the tests will find it.
• Vague exception responses. "Process improved" invites a follow-up question; a dated fix closes it.
• A gap between periods. Every month without coverage needs explaining, usually with a bridge letter.

Frequently asked questions