Preparing for a SOC 2 audit: a step-by-step plan and the first-year mistakes

You do not prepare for a SOC 2 audit by writing documents for the auditor. You prepare by making sure that on the first day of the observation period every control is operating, every control has an owner and evidence is being recorded from that day onwards. Anything that still has to be implemented after that date shows up in a Type II report as a period in which the control did not operate.

This article describes the steps in the order in which they save the most time, and for each step the mistake we encounter most often in first SOC 2 engagements. If the framework itself is new to you, start with what a SOC 2 report is and who asks for it.

Step 1: choose a scope as small as your customers allow

Scope consists of two decisions: which Trust Services Criteria the report covers and which systems are in it. Of the five categories, only Security is mandatory. Add Availability if your contracts promise availability, because that is the assurance customers are looking for. Confidentiality, Processing Integrity and Privacy belong in the report only if your service directly depends on them. The criteria per category are covered in the article on the Trust Services Criteria.

The mistake we see most often here: choosing three or four categories because it looks more complete, or because a sales colleague promised it to a prospect. Every additional category means additional criteria, additional controls and additional evidence, throughout the entire observation period. Expanding in year two is easy. Scaling back in year one is something you have to explain to customers.

The system boundary is the second decision and the more expensive one. Which product, which environments and which supporting systems (deployment pipeline, secrets management, logging platform, support tooling) belong to the service the report is about? For SaaS providers, the article on SOC 2 for SaaS companies works through those questions. Record the outcome in a first version of the system description, because that determines what the auditor will and will not test.

Step 2: establish a baseline before the clock starts

A Type II report tests the operating effectiveness of controls over a period. A Type I only tests design and implementation at a point in time. The difference and its consequences for planning are covered in Type I versus Type II. For preparation the conclusion is simple: do not start the observation period until you can demonstrate that the controls are operating.

The way to establish that is a baseline, as a readiness assessment or as a Type I report. Both force the organization to have every control in place before the period starts. Skip that step and you discover the gaps when the auditor finds them, and then they are in the report.

The variant of this mistake that costs the most: starting the observation period too early because a customer wants to hear a date. A period that begins while half the controls are still being implemented is guaranteed to produce exceptions for the first months. A later start date with a clean report is worth more to that customer than an early start date with a list of findings.

Step 3: describe controls as they actually work

Make an inventory of the controls you already have. Many organizations have more in place than they think: multi-factor authentication, code reviews, monitoring, backups, an incident procedure. For each control, record what it does, who performs it, how often, and what evidence demonstrates that it operated. That inventory is the control matrix, the document the auditor starts from.

The mistake here is copying controls from a template or a compliance tool. Useful as a starting point, risky as an end point. The auditor tests what is on paper. A control that promises monthly access reviews while reality is quarterly produces an exception, even if quarterly is perfectly defensible for your risk. And employees do not recognize themselves in processes imported from outside, so compliance erodes as soon as attention fades.

So describe controls as they really work, or make them work as described. Either is fine, but they have to match. A smaller set of controls that is demonstrably followed is worth more than an impressive list that does not reflect practice.

Step 4: close the gaps that need a track record first

Compare the control matrix with the criteria you selected. Gaps we keep seeing in first audits: no approved information security policy, no periodic access reviews, undocumented change management, no incident response plan, no formal risk assessment and no vendor review.

Not every gap weighs the same for planning. A missing policy document can be written and approved in a week. A periodic control that does not exist yet has to run a few times before there is any operation to test. So tackle the gaps that need a run-up first: access reviews, risk assessment, vendor review and the change process. The documentation work can run in parallel, but it does not determine the start date.

Step 5: build evidence into the process

This is the step on which the first year breaks down. A Type II audit requires evidence across the entire observation period: tickets, reviews, minutes, logging, change documentation. Organizations that start collecting when the audit is announced discover that evidence from eight months ago can no longer be reconstructed. An access review that was not documented did not take place as far as the auditor is concerned.

So record who did what and when for every periodic control, and collect continuously instead of retroactively. What the auditor expects of evidence (dated, attributable to a person, system-generated rather than recreated) is covered in evidence in IT audits.

Two points deserve separate attention. The first is completeness of the population. The auditor samples from all changes, all new hires or all incidents in the period, and first wants to establish that the list is complete. A handful of approved pull requests is not evidence for the change process; the full deployment list is, including manual and emergency changes. The second is retention. Logs kept for thirty days while the period lasts six months are a gap that cannot be closed afterwards. Check retention periods before the period starts.

Step 6: sort out vendors before the auditor asks

Almost every service organization relies on third parties: a cloud platform, a data center, a payroll processor, an identity provider. For each vendor that plays a role in the controls within your scope, you choose how it appears in the report, through the carve-out or the inclusive method. Carve-out is the usual choice for hyperscalers, but it does not close the subject. You have to demonstrate that you monitor that vendor: report requested, read, assessed, and the assessment documented.

Organizations that map their vendors only during the audit sometimes discover they never requested a report. That is immediately a finding on the monitoring controls. So take the inventory at the start of the engagement, and read the complementary user entity controls in the vendor reports: the measures the vendor places with you, which therefore belong in your control matrix. How to set up vendor review structurally is covered in third-party risk management.

Step 7: assign ownership beyond one person

In many organizations the SOC 2 effort is carried by one driven colleague, often the CTO or a security officer. As long as that person is around, things run. But controls touch the whole organization: HR provides onboarding and offboarding evidence, engineering runs the change process, management performs the risk assessment. If ownership is not explicitly assigned, execution stalls with every holiday or departure.

Assign an owner to each control, make execution part of regular work and report periodically to management on status. Also designate a single point of contact for the auditor, who coordinates evidence requests and schedules interviews. Make sure control owners know what a walkthrough is and what questions to expect.

During the audit: exceptions and the management response

Almost every first Type II report contains exceptions. That is normal. What we advise against is the reflex to negotiate every finding during the audit or to repair evidence after the fact. Auditors notice, and it damages the credibility of the whole report. An exception with a clear management response (root cause, remediation, timeline) reads better to a customer than a report that looks suspiciously clean.

Treat findings as input for the next year. The same exception should not recur in the second report; that is what report users and their accountants look for. How the cycle continues after the first report is covered in the annual SOC 2 audit cycle.

What preparation delivers

A well-prepared first engagement has four characteristics: a scope that matches what customers ask for, controls that reflect practice, evidence recorded from day one, and ownership that does not rest with one person. Then SOC 2 is a manageable annual cycle instead of a yearly feat of strength.

Secure Audit performs readiness assessments and SOC 2 audits. Our approach and the factors that drive cost are on the SOC 2 audit page.