Preparing for a SOC 2 Examination

SOC 2 preparation goes wrong most often for one specific reason: organizations often approach it with the assumptions of a financial audit, when the framework is actually an attestation engagement, and that mismatch shapes almost every mistake covered in this piece. A licensed CPA firm examines a service organization's controls under AICPA standards (SSAE No. 18, AT-C Sections 105 and 205) and issues a report with four parts: an audit summary stating scope and opinion, management's own assertion about its systems, a detailed system description, and the results of control testing. Any organization handling sensitive client data eventually runs into a client or partner asking for one, whether it's a SaaS provider, a cloud platform, a managed service provider, a healthcare IT vendor, or a financial processor. Outside parties value the report because it offers independent proof that stated controls actually function, distinct from a set of policies that sound good in a sales deck. SOC 1 addresses something different entirely: controls tied to a user entity's financial reporting, think payroll processors or revenue recognition platforms, and conflating the two frameworks is the single fastest way to burn an entire preparation cycle on the wrong exam.

Choosing the right scope before any preparation begins

The AICPA's five Trust Services Criteria, set in 2017, give the exam its shape. Security, sometimes labeled CC1 through CC9, is the only one that's mandatory, and it covers governance, risk, logical access, change management, operations, and monitoring. The other four, Availability, Processing Integrity, Confidentiality, and Privacy, are optional additions layered on based on what the business actually does.

Most organizations get this decision backwards, and it's worth stating plainly: adding criteria because the framework technically allows it is the wrong instinct, full stop. The only defensible reason to add a criterion is that a client is already asking for it in a security questionnaire or contract redline. An uptime-sensitive SaaS company usually adds Availability. An organization handling PII, or one operating under GDPR, usually adds Privacy. Every criterion added expands the testing population and the documentation burden, so the discipline here is restraint: include only what's defensible and meaningful, not everything the framework technically permits.

There's also SOC 2+, which folds additional frameworks, HIPAA, NIST CSF, GDPR, into a single report. It's a reasonable option for organizations selling into regulated industries where clients want a specific overlay named explicitly.

Underneath all of it sits the system boundary question: which products, infrastructure, and processes actually fall inside the exam. A narrow, tightly defined boundary is far easier to control and to audit than a sprawling one that tries to capture the entire company, and the temptation to scope broadly, to look thorough, deserves to be resisted outright rather than indulged as a middle path. Scoping in a system the organization can't yet control consistently is the mistake that does the most damage, because it fails testing on something that never needed to be in scope in the first place. Leaving it out and expanding the boundary in a later period costs far less than that failure does.

Type I versus Type II: which report to pursue first

A Type I report is a snapshot. The auditor evaluates whether controls are designed appropriately as of one specific date, with no requirement to prove they operated that way over time. A Type II report goes further: it examines both design and operating effectiveness across a defined period, a minimum of six months under AICPA standards.

Type I only makes sense in two situations, and organizations that reach for it outside those two are usually just avoiding a harder problem. It fits an organization pursuing SOC 2 for the first time with genuinely mature controls but no documented history, or a case where a prospect needs some credential quickly and will accept a Type I as a bridge. The limitation shows up fast after that: enterprise procurement teams and regulated-industry buyers increasingly want Type II, because it proves controls ran consistently rather than simply existing on paper the day the auditor showed up. Treating Type I as the destination rather than the bridge is where most of this goes wrong.

That has a real planning consequence. An organization aiming for Type II should expect the observation period alone to run at least six months, on top of preparation time before that period even opens. For a first engagement, the realistic timeline from decision to issued report often runs well past a year. Most organizations end up doing Type I first, largely out of necessity, to surface gaps under actual audit conditions, then move straight into the Type II observation window once those gaps are closed.

The readiness assessment and what it actually surfaces

A readiness assessment is a preliminary, informal examination, often run by the same firm that will eventually perform the audit, or by an outside advisor, that checks current control design against the chosen Trust Services Criteria before the formal clock starts. The output is a findings letter: specific gaps, missing documentation, spots where operating effectiveness is likely to fail once real testing begins.

What usually turns up? Controls that exist in practice but were never written down top the list, and this matters because auditors cannot test something that leaves no evidence trail. Access management gaps show up constantly: excessive permissions left over from old projects, no formal process for provisioning or de-provisioning accounts, service accounts holding broad rights nobody remembers granting. Vendor management is another recurring soft spot: third parties with access to in-scope systems but no security review on file and no contract language covering it. Incident response tools might be sitting there unused, with no documented procedure and no evidence anyone reviews logs on a schedule. Change management often reveals a segregation of duties problem too: developers deploying and approving their own code, which the AICPA's 2022 revised points of focus call out by name.

Alongside the formal findings letter, this phase usually involves tabletop exercises, internal questionnaires to inventory what controls genuinely exist versus what people assume exists, and alignment meetings across security, engineering, legal, and leadership. A readiness assessment is the mechanism that turns a vague compliance goal into an actual remediation workplan with names and dates attached to it. Skip it, and the formal examination becomes the readiness assessment, at a much higher cost, with a final report that documents the gaps instead of the fix. Organizations that skip this step aren't saving time; they're just moving the discovery of the same gaps to a more expensive, more consequential moment.

What the 2022 AICPA updates changed about control expectations

The AICPA published a revised SOC 2 Audit Guide in October 2022, updating the points of focus tied to each Trust Services Criterion to account for newer technology and threats. Four expectations are now explicit in a way they weren't before, and organizations still building toward pre-2022 standards are preparing for an exam that no longer exists.

Organizations are expected to keep accurate, current network and data flow diagrams along with a full hardware inventory, maintained as a living document rather than a one-time diagram drawn for the first audit. Offboarding got specific too: immediate revocation of access and retrieval of assets for terminated remote employees and partners is now a named point of focus, which matters given how much work happens outside a physical office. Segregation of duties in change management is spelled out plainly: no one approves or tests their own code, a rule that organizations without a formal change board can easily run afoul of. Patch management now needs to be a documented, end-to-end process, identification, testing, approval, verification, rather than updates applied whenever someone gets around to it.

Why does this matter for someone preparing right now? Auditors are testing against these updated points of focus today, not the version that existed before October 2022. A control environment built to older expectations, even one that felt thorough at the time, will likely generate findings in a current examination. The 2022 revisions also tightened what the system description in the final report has to cover, which turns thorough documentation from a nice-to-have into an actual requirement of the report itself.

Building and documenting the control environment

Here's the constraint that shapes everything in this section: an auditor can only test what leaves evidence. A control that runs informally, in someone's head or in a Slack thread nobody archived, fails testing even if it worked perfectly in practice. That single fact explains most of what follows.

Access control needs a formal provisioning and de-provisioning workflow with documented sign-off, periodic access reviews (quarterly is common, and the results have to be retained, not just performed), multi-factor authentication enforced across in-scope systems, and privileged access tracked and monitored separately from standard user access. Risk assessment needs to happen at least annually, documented and tied specifically to the in-scope system, feeding into a risk register that names likelihood, impact, and an owner responsible for mitigation.

Change management needs a documented control process requiring approval before anything hits production, with segregation of duties actually enforced: the developer who wrote the change cannot be the person who approves its release. Vendor management needs an inventory of every third party with access to in-scope systems, an annual security review or SOC report check for the material ones, and contracts that actually contain the relevant security and confidentiality language. Monitoring and incident response need active log review with evidence it happened, a documented incident response plan tested at least once a year, and an incident log that's actually reviewed rather than just accumulated.

Format matters as much as content here. Policies need formal approval, version control, and accessibility; an informal wiki page edited by whoever remembered to update it doesn't count as policy. The evidence discipline is unforgiving on the math: if a control runs monthly, the auditor expects twelve data points across a twelve-month period, no exceptions and no partial credit. Auditors sample from that population, and any gap in it becomes a finding, full stop. Running in parallel with all of this is the system description itself, the narrative covering infrastructure, data flows, personnel, and boundaries, a required deliverable the auditor will test for accuracy against what's actually happening on the ground.

Closing gaps between the readiness assessment and the examination period

Not every finding from the readiness assessment carries equal weight, and treating them all the same wastes time that's already scarce. Design gaps, a missing policy document, can often be closed in a matter of weeks. Operating effectiveness gaps take longer: a control might exist on paper but hasn't run consistently yet, and no amount of urgency retroactively creates a history that never happened.

This is where the timing math gets unforgiving. If a finding calls for a new control that needs six months of demonstrated operation before a Type II exam can test it, fixing that control the month before the observation period opens accomplishes nothing for that report cycle. The control simply won't have enough history behind it, regardless of how well it's designed.

A workable remediation plan assigns each gap to a named individual, not a team, sets a target date that accounts for when the observation period actually begins, and specifies what evidence will be collected and where it will live. Some remediation work is deceptively slow. Standing up an access review process takes an afternoon; collecting twelve months of completed, documented reviews takes twelve months, no shortcut exists for that one. Building a vendor inventory is quick; chasing down SOC reports or completed security questionnaires from every material vendor can eat months of follow-up emails. Security awareness training needs documented completion records for every employee, not a link fired off in an email and forgotten. Before the observation period opens, the internal check is straightforward to state and hard to actually satisfy: are all in-scope controls running, is evidence being captured systematically, and is the system description draft complete enough for management to comfortably assert over it.

Selecting a qualified CPA firm for the examination

Only a licensed CPA firm can issue a SOC 2 report under AICPA attestation standards. That's a legal boundary on who's allowed to sign the opinion, and it rules out a whole category of consulting shops that market SOC 2 "certification" they cannot actually deliver. Anyone selling a certificate rather than an attestation report is selling something SOC 2 doesn't have.

Past that baseline, the differences between firms matter more than most organizations expect going in. Industry familiarity counts for a lot: an auditor who's worked with healthcare IT, or financial services, or SaaS specifically will write a system description and design tests that reflect how the environment actually functions, instead of forcing it into a generic template built for a different kind of company. Partner involvement is worth asking about directly, since the gap between a partner-led engagement and one run mostly by junior staff can be significant; genuine partner attention should show up throughout the exam, not just at the signature line. Some firms offer both the readiness assessment and the formal examination, which creates useful continuity, since the same team that found the gaps understands why the remediation was built the way it was. And if HIPAA or NIST CSF overlay work seems likely down the road, it's worth confirming upfront whether the firm has actually examined against those frameworks before, rather than discovering the gap mid-engagement.

The engagement letter deserves a careful read before anything opens, since it locks in the examination period, the criteria in scope, the report type, and the delivery timeline, and changes mid-period are genuinely difficult to make. A firm running a high-quality engagement communicates along the way: interim status updates, early flags on emerging findings, a clear path for management to respond to exceptions before they become surprises in the final report. The firm's name attaches permanently to that report's conclusion, worth remembering when deciding whether the relationship feels like an advisory partnership or just a document intake process.

What happens during the examination and after the report is issued

During the observation period itself, the auditor requests evidence for every in-scope control, usually through a secure portal or a structured request list rather than an ad hoc email chain. Walkthroughs follow: the auditor interviews the people who actually own each control to see whether documented procedure matches daily practice. A mismatch here creates a finding even when the written policy itself is well constructed, because the auditor is testing behavior, not paperwork.

Sampling drives the Type II testing specifically. The auditor pulls samples of control execution spread across the period, and the larger the population of executions, the larger the sample pulled from it. Any gap in execution during the period surfaces in that sample; there's no averaging it away.

Management's job during fieldwork is fairly plain: respond to evidence requests without delay, keep controls running without a lapse just because the audit is underway, and flag any incident or control failure to the auditor directly instead of hoping it slips past unnoticed. That last point matters more than it sounds, since auditors are trained to notice exactly the kind of silence that suggests something was buried.

When exceptions do turn up, the auditor documents them plainly in the report, and management gets a chance to respond formally. A clear, factual response describing what remediation happened or is planned reads far better to a client reviewing the report than a defensive one that tries to explain the exception away. A report with a small number of exceptions and a credible, specific management response isn't automatically a failure, and organizations that treat it as one are missing the point of the exercise. If anything, it demonstrates that the organization's monitoring actually catches problems instead of missing them, which is the entire reason for running the exam in the first place.