Working with your SOC 2 auditor

Choose a licensed CPA firm that audits companies like yours, and agree the scope, categories and period before the period starts. Then prepare what only you can write: the system description, your management’s assertion, and the controls your customers must run themselves. The auditor tests your controls; independence rules stop them from designing them.

The requirement in plain English

A SOC 2 examination is your management’s claim about your system, tested by an independent CPA firm. Several parts of the report are therefore yours, not the auditor’s.

Who can be your auditor

Only a licensed CPA firm can perform the examination and sign the report. The firm must be independent of you: it can tell you where the gaps are, but it cannot build or operate your controls. In 2026 the AICPA warned publicly about quick-turn SOC engagements and about providers who are unlicensed or not enrolled in peer review, so check both before you sign.

What you write

• The system description: usually section 3 of the report, written to the AICPA’s 2018 SOC 2 description criteria. It covers your services, your commitments to customers, the parts of the system (infrastructure, software, people, procedures and data), its boundaries, and any significant incidents or changes in the period.
• Management’s assertion: a signed statement that the description is fair and that the controls were suitably designed and, for Type II, operated effectively.
• Complementary user entity controls: the controls your customers must run for the criteria to be met, such as managing their own users’ access to your product. They also form part of how you tell customers about their responsibilities under SOC 2 CC2.3.

Suppliers inside your system

A cloud provider or other supplier that runs part of your system is a subservice organisation. Under the carve-out method its controls stay out of your report, which lists the controls you rely on it for, and you monitor it through its own SOC 2 report, as SOC 2 CC9.2 expects. Under the inclusive method its controls are tested in your report, which needs its cooperation. Carve-out is the usual choice with the large cloud providers.

The timeline

Engagement letter, scoping, an optional readiness assessment, the observation period for Type II, fieldwork after the period ends, a draft report, your responses to any exceptions, and the final report.

This is guidance to help you understand the requirement, not legal advice.

What good looks like

A 20-person fintech in Edinburgh asks three firms for proposals. It checks each firm’s licence and peer review, asks for an anonymised sample report and the names of the people who will do the work, and picks the firm with the most software clients, not the fastest promise.

At the scoping meeting the chief technology officer agrees the system boundary, Security plus Availability, a carve-out of the cloud provider and the period dates. The firm sends its request list (the list of documents and populations it will need) at the start, and the operations lead tracks it to the end, with one named owner per item.

The draft system description is written by the people who run the system, then checked against the description criteria and the actual controls. During fieldwork a 30-minute weekly call clears questions before they pile up. Each exception gets a management response within a week of the draft.

Evidence an auditor expects

Before and at the start of fieldwork, the auditor usually asks for these. The system description and management’s assertion are required parts of every SOC 2 report; the rest is evidence that is usual.

• System description: matches what actually runs, including boundaries and changes in the period.
• Management’s assertion: signed by someone with authority over the system.
• Complementary user entity controls: listed, and consistent with your customer contracts and documentation.
• Subservice organisation list: each supplier’s role, the method used, and its current SOC 2 report with your review.
• Organisation chart and policies: current and approved, matching the description.
• Risk assessment: dated within the period.
• Populations: complete lists for each event-driven control, with how they were produced.
• Previous report and bridge letter: for a renewal, so the auditor can follow up earlier exceptions.

Common mistakes

Choosing on speed and price

A report produced in days with little testing may not survive a customer’s security review, and the AICPA has flagged that risk. Choose a firm whose reports your customers already accept.

A system description written by marketing

Descriptions that promise more than the system does create exceptions the auditor must report. Describe what runs, not what the website says.

Forgetting the controls your customers own

If you omit complementary user entity controls, the report reads as though you cover things only your customers can do. List them, and tell customers in your documentation.

Carving out the cloud provider and then ignoring it

A carve-out moves the provider’s controls out of scope, not your duty to monitor it. Read its SOC 2 report every year, note the controls it expects of you, and keep the review.

Asking the auditor to write your controls

An auditor who designs your controls cannot then audit them. Get build help from someone else, and keep the auditor to findings and questions.

How Sted helps

Related guides and terms

• The SOC 2 hub: who can issue a report and how the pieces fit.
• SOC 2 report: the sections of the report your auditor will issue.
• SOC 2 Type I and Type II reports: agreeing the report type and period.
• Supplier due diligence: reviewing your subservice organisations’ own reports.
• SOC 2 evidence: preparing the populations on the request list.

Frequently asked questions