SOC 2 Sample Selection: Audit Testing Methodology

Maria Chen had built the access review process at DataFlux Analytics herself, eighteen months earlier, and she was proud of it. Every quarter, IT pulled a list of active accounts in the core data platform, her team's manager reviewed it line by line, and she filed the signed sign-off in a shared drive. When her Type II audit kicked off in March, she handed the auditor four PDFs — one per quarter — and expected a quick "looks good."

Instead, the auditor, a senior manager named Devon Okafor from Marchetti & Cole CPAs, asked a question that stopped her cold: "Can you show me the complete list of every user account that existed at the moment each of these reviews happened — not just the list your team says it reviewed, but the system-generated export, timestamped, independently pulled?" Her Type II audit was already underway, and Maria didn't have it. Her quarterly review process worked from a spreadsheet someone had manually updated, and two departed contractors had lingered in the "reviewed" list for months because the export predated their offboarding by three weeks. DataFlux was mid-negotiation on a $2.4 million enterprise contract that was contractually gated on a clean SOC 2 Type II report. A sampling problem — not a control failure, a population problem — put the deal, and the report, at risk.

This is the part of a SOC 2 audit that catches even well-prepared teams off guard. You can have a genuinely well-designed, well-operated control and still fail testing because the population you handed the auditor wasn't complete, or because the sample the auditor picked landed on the one week your process broke. Sample selection isn't a formality bolted onto the end of the audit — it is the audit. Understanding how auditors build populations, size samples, and extrapolate deviations is the difference between a clean report and a qualified one.

Who this is for and what you'll walk away with

This is written for compliance leads, engineering managers, and control owners heading into (or already inside) a SOC 2 Type II examination who want to stop treating "the auditor will pick a sample" as a black box. You'll walk away understanding what a complete population actually looks like for the control types you own, how sample sizes scale with control frequency from daily automated jobs down to once-a-year disaster recovery tests, the real difference between judgmental and statistical sampling, and what happens mathematically and reputationally when a sample turns up a deviation. The goal is simple: never again be the person handing the auditor an incomplete population three days before the report is due. If sampling terminology throughout this piece is new to you, keep PentesterWorld's SOC 2 Glossary open in a second tab.

Why sample selection is the fulcrum of the whole audit

Every SOC 2 Type II examination rests on a basic constraint: the auditor cannot look at every single instance of every control operating across a 3-to-12-month audit period. A daily access-provisioning control might have 900 instances in a year. A change management pipeline might have thousands of deployments. Reviewing all of them isn't feasible for the auditor, and it isn't affordable for the client — audit fees would multiply several times over. So auditors rely on audit sampling: examining a representative subset of a control's operation and using the result to draw a conclusion about the whole audit period.

That's a powerful shortcut, and it's also a source of real audit risk. If the sample isn't representative — because the population it was drawn from was incomplete, or because the sample size was too small to catch a real problem, or because the selection method itself was biased — the auditor's conclusion can be wrong in either direction. They might pass a control that actually failed regularly, or they might flag a deviation that was a one-off fluke and unfairly tank an otherwise sound control. This guide walks through how professional sampling methodology tries to avoid both failure modes, and — more usefully for you — what it means for how you prepare. If you're still deciding which examination type your organization needs, our comparison of Type I vs. Type II audit approaches is worth reading first — everything in this guide applies specifically to operating-effectiveness testing, which is what makes Type II examinations fundamentally sampling-driven in a way Type I engagements are not.

Sample selection sits downstream of two things: the walkthrough procedures your auditor performs early in the engagement to understand how a control is supposed to work, and the control testing procedures they later run against your evidence collection discipline. Get those two things right and sampling becomes routine. Get them wrong and sampling becomes the mechanism by which small process gaps turn into report-threatening findings.

"People think the sample is where the audit gets hard. It's not. The sample is the easy part — it's arithmetic. The population is where audits get hard, because that's where I have to trust that what you handed me is actually everything, and clients hand me 'everything except the parts that were awkward' more often than they'd like to admit." — Devon Okafor, Senior Manager, Marchetti & Cole CPAs

Populations: the universe the sample is drawn from

A population (audit) is the complete set of items from which a sample is drawn — every instance of a control operating during the audit period. If the control is "quarterly access reviews," the population is every quarterly review that should have occurred: four instances for a 12-month period, three for a nine-month period. If the control is "code changes go through peer review before deployment," the population is every single deployment to production during the window, which could run into the thousands for an active engineering org.

Populations differ fundamentally from most of what compliance teams are used to producing. A policy document is static — you write it once and it's done until the next review cycle. A population is a live extraction from a system of record, generated fresh, and it has to be provably complete: no gaps, no manual pruning, no "I removed the ones that weren't relevant." The auditor's first move on any sampled control isn't to pick the sample — it's to test whether the population itself is trustworthy.

Notice the pattern across every row: the completeness risk is almost never "the control didn't work." It's "the extract that represents the control's history has a hole in it." That's exactly what happened to Maria at DataFlux — her control (the review itself) may well have been fine, but her population (the account list at each review date) wasn't demonstrably complete.

Population completeness: the make-or-break step

Auditors are trained to test population completeness before they trust anything derived from it, because a sample drawn from an incomplete population proves nothing about the whole. Common completeness procedures include tracing the population total back to an independent source (like reconciling a user list against total headcount from payroll), footing and cross-footing totals across systems, and asking pointed questions about how the export was generated and by whom.

"The question I ask every client the same way, every time: 'If I pulled this list myself, independently, from your system right now, would it match what you just gave me?' Half the time the answer is a confident yes. The other half, someone in the room goes quiet, and that's when we find the gap." — Lena Sorenson, Partner, Halbrook Sorenson Assurance LLP

Population completeness failures are almost always a preparation problem, not a control problem, which is exactly why they're so frustrating for clients — you can lose a clean audit outcome to a bad export script rather than a bad process. The fix isn't complicated, but it does require discipline: populations should come from a system-generated, timestamped, unedited export whenever possible, never a manually curated list someone assembled from memory or a rolling tracker that gets "cleaned up" before the auditor sees it.

Judgmental vs. statistical sampling: two different logics

Auditors choose between two broad sampling philosophies, and understanding the difference clarifies a lot of confusion clients have about "why did they pick that one instance."

Judgmental (non-statistical) sampling relies on the auditor's professional judgment to select items — often deliberately targeting higher-risk transactions, unusual items, period-end activity, or a spread across different systems or locations. It doesn't rely on probability theory to project a mathematically precise error rate across the population; instead, the auditor uses experience and risk assessment to decide the sample is representative enough to support a conclusion.

Statistical sampling uses a defined, probability-based method — such as a random number generator — to give every item in the population a known, calculable chance of selection. This allows the auditor to mathematically extrapolate a deviation rate found in the sample across the entire population with a stated confidence level.

Most SOC 2 engagements you'll encounter lean judgmental, layered with elements of randomization, because populations are typically homogeneous enough (a quarterly review is a quarterly review) that a strict statistical model adds cost without adding much assurance. But larger service organizations, or engagements testing very high-volume automated controls, sometimes see a more formal statistical approach, particularly for populations in the hundreds or thousands.

"I get asked constantly why I picked a particular week out of the fifty-two available. Half the time it's genuinely random. The other half, I picked the week right after a system migration, because that's where things break. Both are valid — they're just different tools." — Devon Okafor, Senior Manager, Marchetti & Cole CPAs

How auditors determine control frequency

Before an auditor can size a sample, they have to classify how often the control operates during the audit period, because frequency drives everything downstream. This sounds obvious, but frequency classification isn't always a clean fit — a control that's "supposed to" run monthly but actually ran eleven times in an eleven-month period isn't the same population as a truly monthly control across twelve months, and a control that runs continuously (like automated encryption enforcement) needs a different lens entirely from one that runs on a calendar cadence.

Classification errors here cascade. If your team calls a control "quarterly" but it actually only ran twice because two review cycles were skipped, the auditor isn't testing a sample of four — they're staring at a population of two, and now they have to ask why the other two didn't happen at all, which is a design or operating-effectiveness question entirely separate from sampling. The length of your organization's observation period matters here too: a nine-month window turns a "quarterly" control into a population of three, not four, and auditors adjust sample-size expectations accordingly.

Sample size guidance by control frequency

This is the table almost every client wants first, and for good reason — it's the closest thing to a rulebook in what is otherwise a judgment-driven discipline. Most CPA firms doing SOC 2 work use some variation of the following heuristic, adapted to their own methodology and the specific risk profile of the engagement. Treat these as illustrative, commonly used starting points, not a universal standard — every firm calibrates its own numbers, and risk assessment can push a sample size up or down from the baseline.

The intuitive shape here — sample size grows with population size, but far slower than proportionally — is standard audit sampling theory at work. A population of a million transactions doesn't need a sample of a hundred thousand to draw a reasonably confident conclusion; it needs a sample large enough to have a good statistical shot at catching a deviation rate above the auditor's tolerable threshold. That's why annual controls get a test of one rather than "zero, because it's such a small population" — one instance is still the entire population, and the entire population must be examined.

How your team runs its upstream risk assessment process feeds directly into this table — a control the auditor assesses as higher-risk based on your own risk register gets a larger sample almost automatically, which is one more reason a thoughtful, current risk assessment pays dividends well beyond its own control objective.

Test of one: why annual controls get different treatment

Annual controls — the yearly penetration test, the annual risk assessment refresh, the once-a-year disaster recovery failover exercise, the annual policy re-approval by leadership — pose a unique sampling problem: there's only one instance in a typical 12-month audit period. The auditor can't "sample" two out of one. So the standard approach is a test of one: the auditor examines the single instance thoroughly, since testing it is equivalent to testing 100% of the population.

This has an important implication that catches teams off guard: because there is zero margin, that one instance has to be flawless in its documentation. There's no "well, three out of four passed" cushion. If the annual DR test's evidence is thin, or the annual risk assessment happened but nobody can produce the sign-off, that single instance either passes or the entire control fails for the period — there's no partial credit in a population of one.

"Annual controls are the ones that quietly sink reports every year, and it's never because the work didn't happen — it's because nobody wrote down that it happened in a way I can independently verify eleven months later." — Lena Sorenson, Partner, Halbrook Sorenson Assurance LLP

Attribute sampling mechanics

Most SOC 2 control testing uses attribute sampling — a method built around a binary question for each sampled item: did the control operate as designed, yes or no? Each item either exhibits the defined "attribute" of proper operation, or it's flagged as a deviation. This is different from variables sampling (common in financial statement audits, estimating a dollar amount), which rarely applies to SOC 2 operating-effectiveness testing.

Setting up an attribute sampling plan involves defining the attribute of interest precisely — for example, "the access review was completed within 5 business days of the quarter-end and signed off by the designated manager" — and setting a tolerable deviation rate, the maximum rate of deviation the auditor will accept while still concluding the control operated effectively. If deviations found in the sample exceed what's consistent with that tolerable rate, the auditor generally cannot conclude the control is effective without further work.

Statistical sampling methods in practice

When an engagement does lean statistical, or when an auditor wants a defensible, unbiased selection method even within a judgmental framework, a handful of standard techniques recur across SOC 2 work.

Stratified selection deserves particular attention for SOC 2 work because service organizations rarely have one homogeneous population — a multinational company's user access population spans multiple identity systems, business units, and risk tiers, and a naive random sample might miss an entire high-risk stratum entirely by chance. A well-designed sample stratifies first (say, by system criticality or geography) and then samples within each stratum, ensuring coverage across the whole population rather than a lucky or unlucky cluster.

Building the complete population: the evidence request process

The population isn't something the auditor discovers passively — it's something you, as the control owner, are asked to produce, usually via a formal request that lands on what practitioners call the PBC list ("provided by client"). How you respond to a population request shapes the rest of the sampling process, and getting it right the first time avoids a frustrating cycle of follow-up questions that eats into your timeline.

The strongest population responses share a consistent shape: a system-generated export (not a manually maintained tracker), a clear description of the query or filter logic used to generate it, a timestamp showing exactly when it was pulled, and — critically — no pre-filtering to remove items you'd rather the auditor not see. Auditors are specifically trained to probe for filtering, because it's the single most common way populations quietly become incomplete.

"The clients who give me headaches aren't the ones with messy processes — messy is fixable, we document it and move on. The clients who give me headaches are the ones who hand me a suspiciously clean list, and when I ask how it was generated, the answer changes twice." — Devon Okafor, Senior Manager, Marchetti & Cole CPAs

Common population completeness pitfalls

A handful of failure patterns show up again and again across service organizations of every size, and nearly all of them are avoidable with a small amount of forethought baked into how systems export data.

Sample selection in action: a worked example

Picture a mid-sized SaaS company with a quarterly user access review control in scope for a nine-month audit period. The population is three review instances — Q1, Q2, and Q3. Given the frequency-based guidance above, the auditor is likely to test all three rather than sample from them, since the population itself is already at or near the sample-size threshold for a quarterly control. Contrast that with a daily automated log-monitoring review with roughly 190 business-day instances in the same nine-month window — there, the auditor pulls a genuine sample, perhaps 20 dates selected using a random number generator, and tests each one for evidence the review occurred and was actioned.

This flow illustrates why the population step gates everything downstream — if step C fails, the whole process resets, often under time pressure as report deadlines approach. It's also why experienced compliance leads front-load population preparation months before fieldwork, rather than scrambling to assemble it the week an evidence request lands.

When a sample finds a deviation: extrapolation and its consequences

This is the part of sampling that has the most real-world weight for clients, because a single deviation in a small sample can look — and sometimes is — disproportionately serious. When an auditor finds a deviation, professional standards require them to consider what that deviation implies about the population as a whole, not just treat it as an isolated anomaly. A deviation found in 1 of 25 sampled items produces a sample deviation rate of 4%; the auditor then has to assess whether that rate, projected across the full population, is still consistent with the control operating effectively, or whether it crosses into control deficiency territory.

The auditor's response to a deviation typically follows a structured line of inquiry: is this an isolated, explainable event (a one-time system outage that delayed a review by a day, with clear documentation), or does it suggest the control doesn't operate consistently? Isolated, well-documented anomalies are sometimes distinguishable from systemic failures — but the burden of proof sits with the client to demonstrate the deviation truly is isolated, often through additional testing of a larger or supplementary sample. This is where the process connects directly to exception management: how you respond to and document a discovered deviation shapes whether it stays a footnote or becomes a qualified opinion. A well-organized management response to the finding — root cause, scope of impact, remediation timeline — is often what separates a one-line noted exception from language that follows you into next year's report.

"A deviation rate doesn't automatically mean a qualified report — but it does mean I have to do more work, and more work usually means more questions, and more questions in the final weeks of an engagement is exactly what nobody wants." — Devon Okafor, Senior Manager, Marchetti & Cole CPAs

Roll-forward and bridge period considerations

Not every deviation surfaces neatly within the primary sample-testing window. Many Type II engagements include a roll-forward or bridge letter period — the gap between the end of the tested audit period and the report issuance date, or between one report period and the next. Auditors typically perform lighter-touch procedures over this window rather than full sampling, but a deviation discovered during roll-forward inquiry can still affect the overall conclusion or trigger management representations about the intervening period. Keeping population extraction discipline consistent year-round — not just during the formal fieldwork window — makes roll-forward inquiries far less eventful.

Preparing for auditor sample requests: PBC readiness

The single highest-leverage thing a compliance team can do to make sampling painless is treat population readiness as a year-round discipline rather than an audit-season scramble. That means every in-scope control has a documented, repeatable extraction method, owned by a named person, tested before the auditor ever asks for it. Really, this is just an extension of a solid readiness assessment practice — verifying population completeness before the auditor asks, not scrambling to reconstruct it after.

"We stopped scrambling every audit cycle the year we made every control owner responsible for a one-page extraction runbook. It sounds bureaucratic until you realize it turns a three-day population fire drill into a fifteen-minute export." — Raj Patel, Compliance Automation Lead, Crestline Cloud

If you want a quick gut-check on where your organization stands before committing to a Type II engagement, PentesterWorld's "Are You SOC 2 Ready?" quiz covers population and evidence readiness alongside the broader control environment.

Automated and continuous controls: a different sampling lens

Automated, system-enforced controls — think encryption enforcement, automated vulnerability scanning, or continuous configuration monitoring — don't fit the traditional frequency table cleanly, because they don't "occur" on a calendar cadence; they're either always on or they run continuously in the background. Auditors typically address these through a hybrid approach: testing the design and configuration of the automated control directly (confirming the rule or policy is correctly configured), combined with testing the general IT controls that govern changes to that automation (so the auditor can rely on the control operating consistently without manually reviewing every instance).

Reliance on an automated control's consistency depends heavily on the strength of the IT general controls around it — change management over the system that enforces the automation, and access control over who can modify its configuration. If those surrounding controls are weak, the auditor can't simply trust that "automated" means "always correct," and testing scope expands accordingly.

Case study: DataFlux Analytics turns a population gap into a process win

Returning to Maria Chen's story from the opening: once Devon flagged the incomplete population problem, DataFlux had roughly five weeks before the report deadline tied to the $2.4 million contract. Rather than trying to reconstruct historical account lists retroactively — which auditors are rightly skeptical of — Maria's team worked with IT to pull a true system-generated export for each of the four quarterly review dates directly from the identity provider's audit log, timestamped precisely to each review date. Two of the four exports revealed exactly the gap the auditor suspected: departed contractor accounts that had been reviewed and flagged for removal, but where the removal ticket lagged the review by three to four weeks.

Rather than a clean pass, the finding became a documented, isolated exception with clear root-cause analysis and remediation evidence — the review process itself worked, but the offboarding-to-review handoff had a timing gap. Devon's team performed root cause analysis alongside DataFlux, confirmed the gap was consistent across only the two instances (not systemic across the full year), and DataFlux implemented an automated termination-to-review trigger going forward, documented in a corrective action plan. The report shipped on time with a noted, remediated exception rather than a qualified opinion, and the contract closed. Maria's team now runs a quarterly self-check — a lightweight control self-assessment — pulling their own population export a week before each quarter-end specifically to catch this class of gap before an auditor ever sees it.

Case study: NimbusPay's quarterly access review sample failure

NimbusPay, a payments infrastructure company, had a cleaner population story than DataFlux but a messier sample result. Their auditor selected two of four quarterly access reviews for testing (consistent with the frequency guidance table above) and found a deviation in one: a manager had approved the review, but three accounts flagged for removal during that review remained active 45 days later, well past NimbusPay's own documented SLA of 10 business days.

Because the deviation touched segregation of duties-sensitive accounts (engineers with production database access), the auditor's team expanded testing to the other two quarters rather than treating it as isolated, per standard practice when a deviation surfaces in one part of a small population. The expanded sample turned up a similar timing gap in a second quarter — enough for the auditor to conclude the removal-SLA portion of the control was not operating effectively for the period, resulting in a qualified opinion covering that specific control, while the rest of the report remained clean. NimbusPay's leadership, initially frustrated, ultimately used the qualified finding constructively: they automated access removal to trigger directly off the review sign-off rather than relying on a manual follow-up ticket, and the next year's report showed zero deviations on the same control.

"A qualified opinion on one control out of forty isn't the end of the world it feels like in the room. Prospects who actually read the report understand a remediated, isolated exception. What they don't forgive is silence — a report that reads suspiciously perfect raises more questions with sophisticated buyers than an honest, remediated finding." — Priya Raman, GRC Lead, NimbusPay

Case study: Vertex Health Systems and the annual DR test-of-one

Vertex Health Systems, a healthtech service organization, learned the test-of-one lesson the hard way. Their annual disaster recovery failover exercise had genuinely occurred — engineers spent a full Saturday failing over to the secondary region and validating recovery — but the only evidence was a Slack thread and a handful of screenshots taken informally during the exercise, with no consolidated report tying observed recovery time back to their documented recovery time objective.

Because the annual DR test is a population of exactly one, there was no averaging effect to soften a thin evidence trail — the auditor either had sufficient evidence that the test met its objective, or the control failed for the year. After a tense two weeks of reconstructing timeline evidence from Slack timestamps, monitoring system logs, and engineer recollections cross-referenced against system logs, Vertex's auditor concluded the test had, in substance, met its objective, but noted the documentation gap as an observation and recommended formal DR test reporting going forward. The following year, Vertex Health Systems built a one-page DR test report template — scope, start/end time, objective, observed recovery time, deviations, sign-off — completed within 24 hours of every exercise, eliminating the reconstruction scramble entirely.

"The annual controls are the ones I tell every client to over-document, not under-document, precisely because there's no second chance in the population that year. You get one shot to write it down right." — Tom Baptiste, VP Engineering, Vertex Health Systems

Multi-location and multi-system stratification

Organizations operating across multiple regions, business units, or technical stacks face a sampling wrinkle worth planning for explicitly: a single flat population can obscure meaningful differences in how a control operates in different parts of the environment. A random sample drawn from a combined population might, purely by chance, never touch the European data center's access reviews or the newly acquired subsidiary's change management process — exactly the areas most likely to have gaps.

Building stratification into the sampling conversation early — ideally during scoping, well before fieldwork — lets you flag to your auditor where you know coverage should be deliberate rather than left to chance, which often works in your favor by demonstrating proactive risk awareness rather than looking like you're trying to steer the sample away from weak spots.

Tools and automation for sample and evidence management

Manually tracking which items were sampled, what evidence was requested, and what's been provided becomes unmanageable fast once an engagement has a dozen or more controls each generating their own population and sample. Most mature compliance programs now run this through a dedicated tracker or GRC platform rather than email threads and shared folders.

Continuous control monitoring platforms increasingly pre-stage population exports automatically throughout the year rather than generating them on demand at audit time — a meaningful shift that turns what used to be a stressful fieldwork scramble into a much lighter confirmation exercise. This connects directly to continuous monitoring practices more broadly, and specifically to a mature continuous monitoring program: the same automated evidence pipelines that support day-to-day security operations can, with modest additional structure, double as always-ready audit population sources. It also overlaps with the ongoing monitoring activities your organization already runs under CC4 — population readiness is, in many ways, just monitoring turned outward toward the auditor.

Working with your auditor on sample size and methodology

Sample size and methodology aren't entirely fixed by a rulebook — they're shaped by the auditor's risk assessment, and that assessment is informed by conversations you have with them well before fieldwork starts. Being proactive about flagging known weak spots, prior-period issues, or recent system changes doesn't invite more scrutiny than you'd otherwise get; it builds credibility and often results in a more efficient, better-scoped sample than if the auditor discovers the issue independently mid-testing.

It's also fair to ask your auditor to walk through their sampling approach for a given control before fieldwork — how they'll classify frequency, roughly what sample size they expect, and what evidence format they'll want for each sampled item. This isn't negotiating the auditor's methodology; it's making sure you're not caught flat-footed producing evidence in the wrong format under time pressure. Auditors doing recurring engagements, in particular, tend to be transparent about this because a well-prepared client makes their job faster too.

"The best clients I work with treat the sampling conversation as collaborative, not adversarial. They ask me how I'm going to test something before I ask them for it. That single habit cuts weeks off some engagements." — Lena Sorenson, Partner, Halbrook Sorenson Assurance LLP

Sample selection as a competitive advantage, not just an audit chore

It's tempting to treat everything in this guide as defensive — process to survive an audit without a black mark. That framing undersells what disciplined population and sample management actually buys an organization. Every dollar spent making your populations provably complete and your evidence contemporaneously retained is a dollar that also makes your internal operations more observable, your incident response faster, and your onboarding/offboarding processes tighter, because the same discipline that produces a clean sample response also closes the operational gaps that create real security risk. DataFlux's automated termination-to-review trigger didn't just satisfy an auditor — it closed a genuine window of exposure where departed contractors retained access. NimbusPay's automated removal-on-signoff didn't just fix a control deficiency — it removed a manual step that was a latent single point of failure.

Sales and customer trust teams increasingly know that a clean SOC 2 Type II report with no exceptions, or a well-explained and promptly remediated one, is a real deal accelerant — enterprise buyers' security reviewers read reports closely, and a report that shows population rigor and prompt remediation reads as organizational maturity, not just compliance box-checking. Treat your population and evidence infrastructure as a durable operational asset you're building once and reusing every audit cycle, not a scramble you re-run from scratch every year.

If your organization is also pursuing certification alongside its attestation, the good news is that the discipline transfers almost directly: the population-completeness habits described here map cleanly onto the evidence expectations of an ISO 27001 internal audit, and our guide to running ISO 27001 and SOC 2 together walks through how to build one evidence pipeline that serves both. If you're still weighing which framework to pursue first, ISO 27001 vs. SOC 2: which one do you need and the ISO 27001, SOC 2 & NIST CSF crosswalk are useful starting points.

If your team is heading into fieldwork and isn't confident your populations would survive the "could you independently regenerate this?" test, that's worth fixing now rather than in week three of the engagement. PentesterWorld's SOC 2 Control Matrix / RACI Template gives you a structured way to map every control to its population source and named owner before your auditor ever asks, the SOC 2 Readiness Checklist walks through the same completeness questions an auditor will, and the SOC 2 Gap Analysis Tool can help you benchmark where your evidence pipeline stands today against what a Type II examination expects.

What "good" looks like: a closing scorecard