How to Prepare for a SOC 2 Audit: The 9 Steps in Order

The request arrives as one line in a security questionnaire with a contract date attached to it. Somebody needs your SOC 2 report by the end of the quarter. The instinct is to find a checklist, work through it, and book the audit, and that instinct is why so many first reports come back carrying exceptions.

Preparation for a SOC 2 examination is not a set of controls to install. It is a sequence, and the order matters more than the contents, because an auditor tests what was running across a period rather than what is running on the day they arrive. A control switched on in week six of a twelve week observation window produces evidence for six weeks and a finding for the other six, and no amount of effort afterward changes that.

How to Prepare for a SOC 2 Audit

Nine steps, in order. Steps one through seven happen before anyone is examining anything. Step eight is where money starts moving. Step nine is the part that lasts months and looks, from the inside, like ordinary work.

Two things sit underneath that sequence and explain most of what goes wrong. The first is that a SOC 2 report is an opinion rather than a certificate, so there is no pass mark to clear and no examiner to satisfy on the day. The second is that steps one through seven compress and step nine does not, which is why the answer to how long each phase runs is mostly a question about how early you started.

Is There an Official SOC 2 Compliance Checklist?

No, and this is the most useful fact on the query. Linford & Company, a CPA firm that performs SOC examinations, states it plainly: the AICPA has not issued a SOC 2 compliance checklist setting out which controls an organization needs, and so every checklist published on the internet is a suggestion for meeting the criteria rather than the criteria themselves.

That has a practical consequence for how you read any list, this one included. Use it to find the questions you have not answered, then have the conversation with the firm that will examine you about which controls answer them in your environment. Companies that skip that conversation build controls for a generic company and then discover in fieldwork that the auditor wanted something else.

How to Scope Your SOC 2 Audit

Scope is the first irreversible decision, because everything inside it produces evidence for as long as the report covers, and every year after that.

Three questions settle it. Which report type, which categories, and which system.

Report type. A Type 1 is a real report and a reasonable first move when a deal is waiting, and a sophisticated buyer reads it as a promise that a Type 2 is coming. Going straight to a Type 2 saves you paying for two engagements, and it costs you the months the period takes.

Categories. Security is mandatory and is most of the work. The other four are added when your commitments call for them.

System. Name the product, the environments, the locations and the entities. Then name the providers you depend on, because your description has to say whether their controls are carved out of the examination or included in it. Carving out is normal and it tells your reader that the assurance chain continues somewhere else. Deciding it late is what forces a description rewrite in the middle of fieldwork.

How to Run a SOC 2 Risk Assessment

The criteria ask for a risk assessment that exists, was performed by people who understand the business, and visibly fed the controls you then built. A generic register bought from a template fails on the third condition, because an auditor asks what changed as a result.

Work from the service commitments you make to customers, not from a catalog of threats. For each commitment, ask what could stop you meeting it, how likely that is, and what it would cost if it happened.

The output you want from this step is a short ranked list, each line carrying a named owner, a decision and a date. That list becomes the input to the gap assessment, and the two together become the story your description tells about why your controls look the way they do.

How to Run a SOC 2 Gap Assessment

A gap assessment compares what you operate against the criteria in scope. A readiness assessment is the same exercise run as a rehearsal for the examination, usually by a firm that performs examinations, and it ends with a written list of weaknesses.

Who performs it matters more than the label. Linford & Company is direct about the limit: a readiness assessment produces a management letter listing identified weaknesses and recommendations to implement before the testing period, and the auditor performing the examination cannot fix those issues itself, because it cannot audit its own work. The same firm notes that while the examination has to be performed by a licensed CPA firm, there is no requirement that the readiness work is.

So you have three workable arrangements. Your future auditor performs readiness and hands you a letter you act on yourself. A separate readiness firm does the diagnosis and the remediation, and the CPA firm arrives cold. Or you do it internally, which works when somebody on staff has been through an examination before and does not work when nobody has.

Whichever you choose, insist that the output is a written list mapped criterion by criterion, with an owner and a date on every line. A verbal debrief is not something you can schedule work from.

How to Close the Gaps Before the Observation Period Starts

This is the step that decides how the report reads, and the whole trick is finishing it before the period opens rather than during it.

Remediation has three parts for every gap, and skipping any one of them leaves you with a control that cannot be tested. Write the rule down. Make the rule actually happen. Make it leave a record that somebody who was not there can inspect months later.

Prioritize the controls that produce their own records without anyone remembering to save anything. Multi-factor authentication enforced in the identity provider leaves a configuration you can screenshot on any day. Change approvals recorded in the ticket system leave a trail for every deployment. Patching leaves a queue with dates on it, which matters more than it used to: the 2026 Verizon Data Breach Investigations Report found that exploiting software flaws, at 31 percent, has passed stolen credentials as the top breach entry point for the first time, so an auditor testing your remediation timelines is testing the thing attackers are currently using most.

Write policies last. A policy written before the practice describes a company that does not exist yet, and the gap between the two is the first thing an auditor finds.

What Evidence Does a SOC 2 Auditor Ask For?

Evidence is the part every first timer underestimates, largely because nobody publishes the request list. Schneider Downs, a CPA firm with a SOC practice, groups what it asks for into eight categories drawn from its own engagements.

Three of those rows are worth reading twice. The risk management row wants your vulnerability scans as artifacts with dates, not a statement that scanning happens. The incident response row wants a tabletop record, which means an incident response plan that has been exercised at least once rather than filed. The governance row wants completion records for security awareness training, which is the control that quietly rots first because completion rates drift and nobody notices until an auditor counts.

Set up one place for all of it before the period starts, name it consistently, and file evidence as it is produced. Reconstructing nine months of records in the two weeks before fieldwork is the single most common reason a first examination slips.

How to Write Your SOC 2 System Description

Here is the deliverable almost nobody expects. The description of the system, conventionally section 3 of the report, is written by management rather than by the auditor. The AICPA's description criteria are benchmarks developed by its Assurance Services Executive Committee, through the Trust Information Integrity Task Force's SOC 2 Working Group, to be used when preparing and evaluating that description.

The reasoning is set out in DC section 200: because service organization management is ultimately responsible for developing, implementing and operating the system, management is also responsible for developing and presenting the description of it. The service auditor then uses the same criteria to evaluate whether what you wrote is presented in accordance with them.

DC6 and DC7 are where first drafts fail. Complementary user entity controls are the things the report assumes your customers do, and writing them honestly means admitting which parts of the assurance you are not providing. Budget real writing time for all of this: a first description usually runs dozens of pages and takes several weeks of back and forth, and it has to be internally consistent with every control you listed.

How to Choose a SOC 2 Auditor

Only a licensed CPA firm can perform the examination and issue the report. Beyond that, the market is wide, the quotes vary enormously, and turnaround is the wrong thing to buy on.

Four questions separate firms in a first conversation. How many SOC 2 examinations does the firm perform each year, and in which industries. Who is actually on the engagement team, and are they CPAs or contractors. How does the firm decide sample sizes for a company your size. And what does the firm expect from you, in writing, before fieldwork opens.

Ask for a redacted sample report as well. You are about to hand a document to your largest customers, and reports differ in how much they explain. On price, the spread is wide enough that a quote is meaningless without the scope beside it, which is why what the examination costs turns almost entirely on the scoping decisions you made in step three.

How to Prepare for SOC 2 Fieldwork

Fieldwork is a few weeks of evidence requests, walkthroughs and follow-up samples. Your response time is the variable you control, and it is usually the one that decides whether the report lands on schedule.

What Happens If You Fail a SOC 2 Audit?

You cannot fail, because there is nothing to pass. The auditor forms an opinion, and an opinion can be unqualified, qualified, adverse or disclaimed. What most people mean by failing is an exception: a control the auditor tested where the evidence did not support that it operated as described.

An exception is printed in section 4 alongside the test performed and management's response. It is not fatal, and buyers read those responses. Two well explained exceptions with a credible remediation plan often reads better to a security team than a spotless report, because it shows the auditor actually tested something.

What genuinely damages a report is a qualified opinion, which says the auditor could not conclude that the controls operated effectively in some material respect. That is rare, it is almost always the result of controls that started late or evidence that does not exist, and it is exactly what steps five through seven are for.

How to Stay Ready for Your Next SOC 2 Audit

The second report is easier only if the first one changed how the company runs. Year two's period should start where year one's ended, because a gap between periods is printed on the report and vendor risk teams do notice.

Three things rot first, in roughly this order. Access reviews slip a quarter and then two. Offboarding misses a contractor nobody remembered was still provisioned. Training completion drops below whatever number you told the auditor. All three are cheap to keep alive with a calendar and an owner, and all three are expensive to explain once they are in section 4.