SOC 2 Evidence Collection: Documentation and Testing Requirements

Dana Okafor had built her career on the assumption that a well-run compliance program runs itself once the policies are written. That assumption died on a Tuesday in March, eleven days before fieldwork was scheduled to start for Fenwick Analytics' first SOC 2 Type II examination. Dana, Fenwick's newly hired Head of Compliance and a former Big Four audit senior, had inherited a 140-person marketing analytics SaaS company with a signed $2.4 million enterprise contract sitting in legal review — contingent, per the customer's security addendum, on a clean SOC 2 Type II report delivered within the quarter. The controls existed. The policies existed. What did not exist was a single, organized answer to the question every auditor asks first: "Can you show me?"

Fenwick's engineering team had access logs scattered across three tools. Change tickets lived in Jira, but half of them lacked the approval trail the control description promised. Onboarding and offboarding records existed in an HR system nobody in security had ever logged into. Dana's predecessor had treated evidence as an afterthought — something you'd grab in a panic once the auditor asked. By the time Dana counted the gaps, she had 47 open items on what would become a very long provided-by-client list, a seven-month observation period to evidence, and eleven days to get organized before the audit firm, Bramwell & Cho CPAs, walked through the door. This article is the playbook Dana built during those eleven days and refined over the following two audit cycles — the one I wish every compliance leader had before their first Type II, not after.

Who this is for: compliance managers, GRC analysts, engineering leads, and founders preparing for or currently inside a SOC 2 Type I or Type II examination who need a concrete, operational understanding of what evidence auditors actually require. What you'll walk away with: a working model of the PBC list, the five core evidence types and how to produce each one correctly, how populations and sampling actually work in a SOC 2 engagement, the real differences between Type I and Type II evidence obligations, how to use automation to turn evidence collection from a fire drill into a byproduct of normal operations, and a checklist for the most common gaps that turn smooth fieldwork into a six-week ordeal.

Why Evidence Is the Real Audit

Here's the thing most first-time SOC 2 candidates get backwards: the audit isn't really about your controls. It's about your ability to prove your controls operated the way you said they would. I've sat across the table from organizations with genuinely excellent security programs — strong access governance, real change control, a security team that knew what it was doing — who still ended up with exceptions on their report because nobody could produce a clean trail of audit evidence tying the control to a specific date, a specific person, and a specific outcome. A control that exists but can't be evidenced, from an auditor's perspective, might as well not exist. That's not cynicism; it's the entire epistemology of an attestation engagement. The CPA firm wasn't in your building watching your engineers approve changes in real time across a seven-month window, so their opinion rests entirely on what you can hand them afterward.

This reframes the whole preparation exercise. Instead of asking "do we have good controls," the more useful question during evidence prep is "if a stranger walked in today and asked me to prove this control operated on every occasion it was supposed to, over the last six months, could I do it in under ten minutes per control?" If the answer is no, you don't have a documentation problem — you have an audit-readiness problem, and it will surface as findings regardless of how mature your actual security posture is.

"I don't grade companies on how sophisticated their tooling is. I grade them on whether the evidence in front of me proves the control operated, for every instance in the population, without gaps. I've seen brilliant security teams get qualified opinions because their evidence trail had holes, and I've seen scrappy ten-person startups sail through because someone owned evidence collection like it was a product." — Marcus Webb, Partner, Bramwell & Cho CPAs

The PBC List — What It Is and How It Works

The PBC list — "provided by client," sometimes called a request list or evidence request tracker — is the master document the audit team uses to request every piece of documentation, configuration export, log, and artifact needed to complete the examination. It is typically delivered as a spreadsheet with one row per request, columns for the associated control or criterion, the specific evidence requested, the responsible owner, due date, and status. For a Type II engagement covering a six-to-twelve month period, a mature PBC list commonly runs 80 to 150 individual line items, though the number varies with scope, criteria selected, and the number of systems in play.

Auditors usually deliver a preliminary PBC list at or shortly after the engagement kickoff, based on the system description and control matrix you provided during scoping. That list is a starting point, not a final one — expect 10 to 25 additional or follow-up requests during fieldwork as the auditor's sample selections generate new questions or as initial evidence reveals gaps that need a secondary artifact to close.

Anatomy of a PBC List by Trust Services Category

Every SOC 2 examination includes the Common Criteria — the Security category, mandatory in every report — and then layers in whichever additional Trust Services Criteria apply to your commitments: Availability, Processing Integrity, Confidentiality, and Privacy. Each category generates its own cluster of PBC items. Understanding the shape of the request list before it arrives lets you pre-stage the evidence rather than scrambling category by category.

The Five Core Evidence Types

Nearly every request on a PBC list resolves to one of five underlying evidence types. Learning to recognize which type a request is asking for — before you start hunting — saves enormous time, because each type has its own capture discipline.

"The single biggest evidence mistake I see is companies treating a screenshot as sufficient proof of anything ongoing. A screenshot tells me what your MFA settings looked like the day you took it. It tells me nothing about whether MFA was enforced on day 40 of a 200-day audit period. That's a population problem, not a screenshot problem." — Sofia Marchetti, Senior GRC Analyst, Northfell Advisory

Screenshots — Best Practices and Pitfalls

Screenshots remain the most misunderstood evidence type in SOC 2 fieldwork. Auditors accept them readily for point-in-time facts — what a configuration setting looked like on the day of testing, what a dashboard displayed during a walkthrough — but they are the weakest possible evidence for anything that needs to be demonstrated as consistently true across an entire observation period. A screenshot of your firewall rule set taken in November does not tell an auditor anything about what your firewall rules looked like in June.

The practical discipline: every screenshot submitted as evidence should include, visibly in the frame, the system URL or hostname, the logged-in account or user context, and a timestamp — either the system clock shown on screen or a file-level capture timestamp you can independently verify. Screenshots taken specifically for the audit (rather than pulled from a system of record showing historical state) should be clearly labeled with the date and purpose in the filename, not just embedded in a folder with forty identically named "Screenshot 2026.png" files. I've watched fieldwork stall for two full days because an auditor couldn't determine which of six nearly identical access-list screenshots corresponded to which quarter's review.

Configuration Evidence and System Exports

Wherever a native export exists, auditors strongly prefer it over a manually curated screenshot, because an export reflects the system's full, unedited state rather than a cropped or selectively captured view. Configuration evidence typically covers things like identity provider policies (session timeout, MFA enforcement, conditional access rules), cloud provider security group and IAM policy exports, database encryption settings, and endpoint management baseline configurations.

The discipline here is retrieval repeatability. If your evidence owner leaves the company mid-audit-period and nobody else knows how to pull the same export in the same format, you've created a single point of failure that will bite you during a follow-up request. Document the exact steps — which console, which menu, which filter — for every recurring configuration pull, and store that retrieval procedure alongside the evidence itself. This is also where organizations running both an information security management system and a SOC 2 program get real leverage: teams pursuing running ISO 27001 and SOC 2 together often build a single evidence retrieval procedure that satisfies both an ISO 27001 internal audit and a SOC 2 fieldwork request, because the underlying configuration state is identical — only the framework language differs.

Tickets, Approvals, and Workflow Evidence

Ticket-based evidence is where the most SOC 2 control deficiency findings originate, because it depends on humans following a documented process consistently, and humans are the least consistent part of any control. A change management ticket needs to show the change requested, who requested it, who reviewed or approved it, and — critically — that the approval happened before the change was deployed, not backfilled afterward. An access-provisioning ticket needs a request, a named approver distinct from the requester (this is where segregation of duties shows up in fieldwork), and a timestamp showing the grant matches the approval.

The recurring failure pattern I see: organizations have a ticketing system, and they assume the existence of tickets proves the process worked. But an auditor sampling twenty-five tickets from a population of four hundred deployments will find the ones missing an approver field, the ones where the "approval" comment came three days after the deploy timestamp, and the ones where the requester and approver are the same person. Every one of those becomes a documented exception. The fix isn't more tickets — it's a ticket template that makes the required fields mandatory, so the evidence is structurally correct at creation time rather than something you have to clean up retroactively before the auditor samples it.

Logs as Evidence

Logs are the backbone of evidence for anything continuous: authentication events, privileged access usage, SIEM-correlated security alerts, system uptime, and job/batch completion. Unlike screenshots or tickets, logs can genuinely cover the entire observation period without a gap — which is exactly why auditors lean on them heavily for Type II testing, and exactly why log retention and integrity matter so much to a SOC 2 program. If your log retention policy purges data at 90 days but your audit period is 200 days, you have a structural evidence gap before fieldwork even begins.

The deeper detail on how logging and alerting infrastructure should be built to support both security operations and audit evidence is covered in SIEM and log management — but from an evidence-collection standpoint, the key requirements are retention that spans the full audit period, exports that are filterable to the exact date range and system requested, and a demonstrable chain showing the exported log matches what the live system actually recorded (auditors occasionally cross-check log exports against independent system data, like ticket timestamps, to confirm nothing was altered).

Policies and Procedures as Design Evidence

Policies prove design intent — what a control is supposed to do — which makes them essential for Type I report evidence and foundational for Type II, even though Type II ultimately needs operational proof on top of the policy. Every policy submitted as evidence should carry version history, an approval date, an owner, and ideally evidence that employees acknowledged it (a signed attestation or LMS completion record). A policy with no version control is a red flag to any auditor, because it raises the question of whether the policy in front of them is actually the one that was in effect during the audit period.

Understanding Populations

A population (audit) is the complete set of items from which the auditor will draw a sample — every access grant issued during the period, every production deployment, every terminated employee, every vulnerability scan run. Getting the population right is arguably more consequential than any individual piece of evidence, because if your population is incomplete or miscounted, every sample drawn from it is compromised, and the auditor will typically require you to reconstruct the full population before testing can proceed.

The most common population failure is an incomplete extraction — pulling "all terminations from HR" when some terminations were processed manually outside the HR system, or pulling "all production changes from Jira" when a subset of hotfixes were deployed directly without a ticket. Auditors are trained to probe for this by asking a second, independent source to corroborate the population count (e.g., comparing the HR termination count against the IT offboarding ticket count) — and a mismatch there is one of the fastest ways to trigger a scope expansion mid-fieldwork.

Sampling Methodology

Once the population is confirmed, auditors apply audit sampling — testing a defined subset rather than every item, because testing every item in a population of thousands of access events would be neither practical nor necessary to reach a defensible conclusion. Sample sizes generally scale with the frequency of the control and the size of the population, following conventions common across attestation engagements (these aren't SOC 2-specific rules, but firm methodologies converge around similar ranges).

The reason low-frequency controls (annual, quarterly) get tested at or near 100% is straightforward: with only one or four instances in the whole population, there's no meaningful statistical basis for sampling below that. High-frequency, high-volume controls get a proportionally smaller sample because the auditor is using the sample to estimate the deviation rate across the full population — and if even one sampled item fails, that typically triggers an expanded sample to determine whether the failure was isolated or systemic.

"When a client asks me why I need forty samples of something that happens four hundred times, I tell them: I'm not trying to annoy you, I'm trying to have statistical confidence that the four hundred I didn't look at would have looked the same as the forty I did. Give me a clean population and organized evidence, and the sampling conversation is short." — Marcus Webb, Partner, Bramwell & Cho CPAs

Type I vs Type II Evidence Differences

The distinction between a Type I report and a Type II report is fundamentally an evidence distinction, not just a report-length difference. Type I asks: was the control suitably designed as of a specific date? Type II asks: did the control operate effectively across the entire audit period? That difference cascades into completely different evidence expectations, and organizations that treat Type II prep like "Type I evidence plus more months" consistently underestimate the lift. For a deeper comparison of when each type makes sense strategically, see Type I vs Type II: choosing the right audit type.

Building Evidence for Point-in-Time (Type I) Engagements

Type I evidence prep is fundamentally a documentation exercise: does every control described in your management assertion have a corresponding policy, a corresponding configuration state, and — ideally — a live walkthrough where the auditor watches you execute the control once, in real time, to confirm the design matches reality. A walkthrough might mean showing the auditor, live, how a new-hire access request moves from creation to manager approval to provisioning in your identity system. It's the closest thing SOC 2 has to a demonstration rather than a document review.

Because Type I doesn't require proving consistency over months, teams sometimes treat it as the "easy" report. It isn't easy so much as it's front-loaded differently — the risk in Type I prep is submitting evidence that looks complete on the surface (a policy exists, a screenshot exists) but doesn't actually match what the system does in practice, which the walkthrough will expose immediately. I've seen more Type I findings originate from a mismatch between the written policy and the live walkthrough than from any missing document.

Building Evidence for the Observation Period (Type II)

Type II evidence has to be built continuously across the observation period, not assembled retroactively in the final month. This is the single most consequential planning decision in a Type II engagement: evidence collection needs to start on day one of the period, because you cannot manufacture a compliant historical population after the fact. If your access reviews were supposed to happen quarterly and you skipped the second-quarter review, there is no evidence artifact that can retroactively prove a review that never occurred — that's simply a control deficiency that will surface as an exception.

Practically, this means every recurring control needs an evidence checkpoint scheduled at the same cadence as the control itself: the quarterly access review generates its sign-off the same week it happens, the monthly vulnerability triage meeting generates minutes and a remediation tracker update the same week, every production change generates its approval trail at deploy time, not reconstructed from memory during audit prep. Organizations that build this cadence into their operating rhythm — rather than treating it as a compliance-season scramble — consistently walk into fieldwork with dramatically fewer findings, a pattern explored further in operating effectiveness: demonstrating consistent control performance.

Evidence Timing — Aligning Collection to the Audit Period

One of the more subtle timing traps: evidence collected outside the defined audit period generally cannot be used to demonstrate operating effectiveness within it. If your period runs January 1 through September 30 and you conduct a rigorous access review on October 5th, that review — however well done — doesn't cover a gap that existed during Q3. This catches organizations that start their compliance program mid-year and try to backfill; auditors will not accept post-period evidence as a substitute for in-period evidence, though a well-run readiness assessment months before the period starts is exactly the mechanism to prevent this, a topic covered fully in readiness assessment: pre-audit preparation checklist.

The PBC List Lifecycle — From Kickoff to Fieldwork Close

The flow below maps how a PBC list actually moves through an engagement, from the initial request through to closure. Understanding this flow lets an evidence owner anticipate the next request rather than reacting to it.

Organizing Evidence — Folder Structures and Naming Conventions

Disorganized evidence doesn't just slow the auditor down — it actively invites deeper scrutiny, because an auditor who can't quickly locate corroborating context for one item starts asking more questions about everything else. A consistent folder structure and naming convention, applied from day one of the audit period rather than assembled retroactively, is one of the highest-leverage investments a compliance team can make.

Evidence Repositories and Compliance Automation Platforms

The manual model — spreadsheets, shared drives, and email threads — buckles once a company crosses roughly 50–75 employees or adds a second framework to its compliance scope. This is where dedicated evidence repositories and GRC/compliance automation platforms earn their keep: they connect directly to identity providers, cloud infrastructure, ticketing systems, and HR platforms via API, and pull evidence on a schedule automatically rather than requiring a human to log in and export it manually each time.

"We went from a person spending most of a week each month manually screenshotting configurations to an automated platform pulling the same evidence nightly. The auditor didn't get less rigorous — if anything, our evidence got more consistent, because a script doesn't forget to take the screenshot in a busy week." — Priya Nandakumar, Compliance Automation Lead, Solvane Cloud Hosting

Continuous Evidence Collection vs Point-in-Time Gathering

Continuous monitoring reframes evidence collection from an event you do before an audit into a background process that runs constantly, with audit prep becoming a matter of exporting what's already been captured rather than generating it from scratch. This shift matters most for Type II engagements, where the entire premise is operating effectiveness across time — continuous collection is a structurally better fit than periodic manual gathering.

Mapping Evidence to Controls — The Control Matrix

The control matrix — sometimes delivered as a RACI-style document — is the single artifact that ties every control statement to its owner, its evidence source, and its testing approach, and it should exist well before fieldwork starts, not get reverse-engineered during it. A strong matrix lets any evidence owner answer, without asking anyone else, exactly what artifact satisfies their control and where to pull it from. The auditor's actual testing procedures against this matrix — walkthroughs, inspection, observation, re-performance — are covered in depth in control testing: auditor procedures and expectations, which pairs directly with this evidence-prep discussion: this article is about assembling what the auditor needs; that one is about what the auditor does with it once you hand it over.

Common Evidence Gaps and How to Avoid Them

Across dozens of engagements, the same handful of gaps recur so predictably that I now check for them before an auditor ever asks. Catching these during a pre-fieldwork internal review consistently saves weeks of back-and-forth during actual fieldwork.

Evidence for Access Control Testing

Access control testing generates one of the largest evidence footprints in any SOC 2 examination, spanning provisioning, periodic review, and deprovisioning. For provisioning, auditors want a request, a distinct approver, and proof the granted access matches what was approved — no more, no less. For periodic access reviews, they want proof the review actually happened on schedule, who performed it, and evidence that any access flagged for removal was actually removed. For deprovisioning, they want the termination date from HR cross-referenced against the access revocation timestamp, checking specifically for delay.

Tobias Lindqvist, Fenwick's engineering manager, became an unlikely hero of Dana's evidence sprint by building a lightweight internal script that cross-referenced HR termination dates against IAM deprovisioning timestamps weekly, flagging anything over 24 hours automatically. That single automation closed what had been Fenwick's most persistent gap category. The broader operational discipline for this control area is covered in access controls: user management and privilege administration.

"The termination-to-deprovisioning gap is the one every auditor checks first, because it's the fastest way to spot whether a company's access process is real or theoretical. We automated the cross-check, and our average deprovisioning time went from four days to under six hours." — Tobias Lindqvist, Engineering Manager, Fenwick Analytics

Evidence for Change Management Testing

Change management evidence needs to demonstrate that changes to production systems followed a defined path: request, review, approval, testing where applicable, deployment, and — for emergency changes — a documented retroactive review. The population here is every production deployment during the period, and the sample will typically probe for approval timing (did approval precede deployment, not follow it), separation between requester and approver, and evidence of rollback capability for high-risk changes.

Organizations running CI/CD pipelines have a natural advantage: pipeline logs can serve as an authoritative, tamper-resistant population source and often supply timestamped approval gates automatically, reducing reliance on manually maintained ticket fields. The specific expectations auditors apply during change testing are detailed in change management: system and application updates.

Evidence for Incident Response and Monitoring Testing

Incident response evidence covers detection, escalation, containment, and resolution — with auditors typically sampling a handful of actual incidents (or, if none occurred, testing the tabletop exercise or simulated incident used to validate the process) plus reviewing the underlying monitoring and alerting infrastructure that would detect an incident in the first place. This is where logging infrastructure and incident response process evidence intersect directly, and it's a category where a genuinely quiet period (few or no real incidents) can actually complicate evidence gathering, since the auditor still needs proof the process works — hence the value of a documented tabletop test during the period. The process-level expectations are covered in incident response: security event management and reporting.

Evidence for Vendor/Subservice Organization Oversight

Every subservice organization — cloud infrastructure providers, payment processors, background check vendors, any third party your system depends on for the criteria in scope — generates its own evidence obligation: proof you assessed the vendor's risk before onboarding, proof you reviewed their own attestation reports (their SOC 2, if they have one) during the period, and clarity on whether your report handles them via the carve-out method or inclusive method. Where a control depends partly on the customer's own actions, that's where CUEC documentation comes in — the complementary user entity controls your customers must operate, which get documented (not tested) in your report and are worth reviewing against user entity controls: client responsibility documentation.

Roles and Responsibilities — Who Owns Evidence Collection

Evidence collection fails most often not because nobody could produce the artifact, but because nobody was clearly accountable for producing it before the deadline. A RACI-style assignment, published before the audit period even begins, removes the ambiguity that turns a routine PBC request into a three-day email chase.

Evidence Quality Checklist Before Fieldwork

Before Dana's team let Bramwell & Cho's field team log in, they ran every open PBC item through a short internal quality gate. It's the single highest-leverage step in this entire process, because it catches the gaps a human reviewer notices instantly but a busy control owner, focused only on their own item, easily misses.

Case Study: Fenwick Analytics' Eleven-Day Evidence Sprint

When Dana Okafor counted 47 open PBC items with eleven days until fieldwork, she didn't try to close them all herself. She assigned each item to its true functional owner using a RACI she built in one afternoon, set a hard 72-hour internal deadline for the first pass, and ran a daily 15-minute stand-up exclusively about evidence status — no other agenda items allowed. Engineering's Tobias Lindqvist built the termination-to-deprovisioning cross-check automation on day three. By day seven, Fenwick had closed 41 of the 47 items; the remaining six required a genuine policy update (their vendor review cadence had lapsed for two vendors), which they remediated and documented transparently rather than trying to paper over. Fieldwork opened on schedule. Bramwell & Cho's team logged two total exceptions in the draft report — both tied to the disclosed vendor review lapse, both accompanied by Fenwick's own remediation evidence, and both ultimately noted as isolated rather than systemic. The $2.4 million contract closed six weeks later.

"I didn't need more headcount. I needed one spreadsheet everyone could see and a deadline nobody could ignore. The technical work was maybe 30% of the problem — the other 70% was just organizational clarity about who owned what." — Dana Okafor, Head of Compliance, Fenwick Analytics

Case Study: Ridgeline Payments' Late-Stage Evidence Recovery

Ridgeline Payments, a payments infrastructure company preparing for its third annual Type II renewal, discovered during its internal readiness assessment — run 90 days before period close — that a platform migration mid-year had silently broken an automated evidence feed for privileged access logging, leaving a two-month gap in the population. CISO Chris Delacroix's team spent three weeks reconstructing the gap period using compensating evidence: cloud provider native audit logs (independently retained regardless of the broken internal feed), corroborated against change tickets for the migration itself, and a documented root-cause writeup explaining the gap and the fix. Because the reconstruction was thorough and independently corroborated, the auditor accepted it as sufficient, closing what could have been a qualifying gap. Ridgeline's fieldwork, originally projected at five weeks, closed in three and a half — the compensating evidence package meant fewer follow-up requests, not more.

"The instinct when you find a gap is to panic and hide it. The right instinct is to document exactly what broke, when, and what you did about it. Auditors have seen every kind of gap — what they haven't always seen is a company that caught it themselves and fixed it before being asked." — Chris Delacroix, CISO, Ridgeline Payments

Case Study: Solvane Cloud Hosting's Automation ROI

Solvane Cloud Hosting, a hosting provider running SOC 2 alongside a growing ISO 27001 program, was spending roughly 220 staff-hours per quarter on manual evidence gathering — largely screenshots and manually compiled spreadsheets — heading into its second Type II cycle. Priya Nandakumar's team implemented a compliance automation platform with direct API connectors into their identity provider, cloud infrastructure, and ticketing systems, reducing quarterly evidence-gathering effort to roughly 40 staff-hours, almost entirely spent on exception review rather than raw collection. The company avoided an estimated $85,000 in contractor spend it had budgeted for audit season support the prior year, and — notably — its auditor reported fewer sampling follow-ups, because the automated evidence had more consistent formatting and complete date coverage than the manually assembled equivalent had the year before.

Auditor Requests During Fieldwork — PBC List Revisions

Even a well-prepared PBC list generates follow-up requests once fieldwork actually begins, because sample selection and initial evidence review routinely surface questions nobody anticipated during scoping. Budgeting time and attention for this second wave is as important as the initial preparation.

Cost and Time Investment of Evidence Collection

Evidence collection is rarely budgeted as its own line item, which is precisely why it becomes a crunch. Sizing the effort honestly, by company stage, helps set realistic internal expectations before the audit period even opens.

Evidence Discipline as a Business Opportunity

It's tempting to treat evidence collection purely as audit overhead — a cost center you tolerate because customers demand the report. I'd push back on that framing. Every organization I've watched build genuine evidence discipline — automated population capture, clean control ownership, evidence that's a byproduct of how the team already works rather than a special audit-season activity — ended up with better operational visibility as a side effect. Dana Okafor's team at Fenwick didn't just pass their audit; they built a termination-to-deprovisioning monitor that now catches real security gaps in real time, independent of any auditor asking for it. Evidence infrastructure, done well, is security infrastructure. The organizations that internalize this stop dreading their next Type II renewal, because the evidence was never really something they had to go find — it was already there, generated as a natural consequence of running the business the way they said they did. That's the actual finish line: not passing one audit, but reaching a state where passing the next one is no longer a special project.

If your evidence collection process still looks like Dana's did on day one — scattered, undocumented, owned by no one in particular — PentesterWorld can help you build the operational muscle before your next audit cycle starts, not during a panic eleven days out.

Ready to get organized before your next SOC 2 cycle? Start with our SOC 2 Control Matrix / RACI Template to assign clear evidence ownership, run our SOC 2 Readiness Checklist to surface gaps before an auditor does, and use our SOC 2 Policy Pack to make sure your design evidence has the version control and approval trail auditors expect. If you're just beginning to map out what evidence each control will require, our SOC 2 Gap Analysis Tool will show you exactly where to focus first.