2026-09-24 · ~20 min read · Decision records

The SOC 2 compliance decision record: why the trust service criteria scope you set determines your control evidence accumulation surface and your enterprise pipeline readiness gap

The Trust Service Criteria scope selection, the evidence automation model, and the Type I vs Type II timing decision are compliance decisions that are almost never made explicitly — they emerge from the first enterprise prospect who asks for SOC 2, the first quarter of evidence collection where gaps appear because no one owns the ongoing task, and the first procurement cycle where the six-month observation period makes the deal timeline impossible. Three failure patterns: the B2B SaaS that scoped all five Trust Service Criteria because the sales team wanted the broadest possible coverage, and found its three control owners spending 14 hours per week on evidence collection for 89 controls when Security-only would have required 51; the SaaS that chose manual evidence collection to avoid a $24k annual platform cost and arrived at its audit with four months of access review gaps and no consistent change management trail; and the developer tooling company that started Type II only when the first enterprise deal required it and lost the deal because the minimum observation period made the timeline impossible.

A 29-person B2B SaaS company built procurement workflow automation for mid-market operations teams — purchase order routing, approval workflows, supplier onboarding, and a spend visibility dashboard. The company had grown to twenty-nine people over three years, with an engineering team of eleven across two product squads and a shared infrastructure function. At the beginning of year three, the first three enterprise prospects — a 400-person manufacturing company, a 600-person logistics services firm, and a 350-person professional services group — each requested SOC 2 Type II reports as part of their vendor security review process. The head of engineering and the CEO agreed that SOC 2 was now a prerequisite for closing enterprise deals and began planning the compliance program. The compliance planning was conducted over two weeks in a series of conversations with a fractional CISO the company had engaged for the program initiation. At the end of the two weeks, the company had decided to pursue SOC 2 Type II with a scope that included all five Trust Service Criteria: Security, Availability, Confidentiality, Processing Integrity, and Privacy.

The decision to include all five criteria was made for two reasons that seemed sound at the time. The sales team had been fielding security questionnaires from prospects that asked about data confidentiality and privacy practices, and the team anticipated that the three enterprise prospects already in the pipeline would ask about Availability (uptime guarantees) and Processing Integrity (transaction accuracy) in the security review. The fractional CISO had noted that adding all five criteria in the first audit meant the company would not need to expand scope in a future audit, avoiding the remediation work that scope expansion requires. The decision seemed to offer comprehensiveness at the cost of a slightly longer compliance program initiation. The cost of the decision became visible during the first month of the observation period.

The company assigned three engineers as control owners alongside their normal product delivery work — the infrastructure lead, a senior backend engineer, and the head of engineering part-time. The Security criterion required 51 controls across six control categories: CC1 (control environment), CC2 (communication and information), CC3 (risk assessment), CC4 (monitoring), CC5 (control activities), and CC6 (logical and physical access). Adding Availability added 9 controls covering uptime monitoring, incident response, backup and recovery, and redundancy. Adding Confidentiality added 8 controls covering data classification, retention, and disposal. Adding Processing Integrity added 7 controls covering input validation, processing completeness, and output accuracy. Adding Privacy added 14 controls covering data subject rights, consent management, data minimization, and cross-border transfer documentation. The total was 89 controls with ongoing evidence requirements.

In the first quarter of the observation period, the three control owners reported spending an average of 14 hours per week across the three of them on compliance-related work — a total of approximately 14 person-hours per week being redirected from product engineering. The Infrastructure lead was running user access reviews monthly for eight different systems, maintaining the vendor risk assessment register for thirty-two vendors (the Privacy criterion required assessments for any vendor with access to personal data, including analytics, email, support, and monitoring tools that the Security-only scope would not have covered as vendor risk items), and conducting quarterly backup restoration tests. The senior backend engineer had taken on the Processing Integrity controls, which required documenting input validation logic and output accuracy monitoring across the product's transaction workflows — work that had no prior documentation. The head of engineering was spending three to four hours per week reviewing and signing off on change management records. At the end of the quarter, the fractional CISO ran the evidence status against the 89 controls and found that 34 controls had full evidence, 41 had partial evidence with gaps, and 14 had no evidence for the quarter. The 41 partial and 14 missing represented a control remediation backlog that would require significant work before the audit engagement could open.

A retrospective at the four-month mark identified the root cause: the decision to scope all five Trust Service Criteria had been made based on a forward-looking sales justification rather than a specific named-customer requirement for each criterion. Neither of the three enterprise prospects had specified Availability, Confidentiality, Processing Integrity, or Privacy in their security questionnaires — they had asked for SOC 2, which most enterprise procurement teams use as shorthand for the Security criterion. The two additional weeks of planning that produced the five-criteria scope had not included a review of the actual security questionnaires from the three pipeline prospects, which would have revealed that Security-only was the requirement. The five-criteria scope had doubled the evidence accumulation burden and directed 38 controls' worth of engineering capacity away from closing the three deals that had triggered the compliance program in the first place.

A 36-person SaaS company built HR workflow tools for mid-size employers — employee onboarding automation, benefits enrollment management, and a compliance calendar for HR administrators. The company had grown to thirty-six people over four years, with an engineering team of fifteen across three squads. At the beginning of the fourth year, the company decided to pursue SOC 2 Type II with a Security-only scope, targeting a twelve-month observation period that would produce a report in time for the following year's enterprise sales cycle. The compliance planning included a decision about tooling: whether to use a compliance automation platform (Vanta was the primary option evaluated, at $22,000 to $24,000 per year for the company's size) or to collect evidence manually. The company chose manual collection. The reasoning: the company's infrastructure was primarily on AWS with a GitHub repository and Okta for identity management. The infrastructure lead believed the evidence for most controls could be pulled directly from these systems using the AWS CLI, the GitHub API, and Okta's user export. A compliance platform that cost more than $2,000 per month seemed expensive relative to what appeared to be a manageable manual collection task. Two engineers were designated as control owners alongside their product work, with a calendar that mapped each control to a collection frequency and a responsible owner.

The twelve-month observation period was scheduled to close in December. In October, the company engaged an auditor for the Type II examination. The auditor's pre-engagement evidence request covered the full observation period — twelve months of evidence for each control. The infrastructure lead pulled the evidence package together over three weeks. When the package was complete, the auditor's evidence review identified the gaps.

User access reviews: the control required monthly access reviews for all systems with access to production data. The calendar event for the monthly access review had been set as a recurring event shared between the two control owners. In April, both control owners were in the middle of a product launch sprint and the access review was not conducted. In July, the infrastructure lead was on leave for two weeks spanning the review date and the task was not delegated. In September, the review was conducted but the output — a spreadsheet confirming that all user access was appropriate and that departed employees had been removed — was saved to a local folder rather than the compliance evidence folder, and was not present when the auditor requested the October access review documentation. The access review evidence trail had gaps in April, July, and September — three months of the twelve-month observation period.

Change management approval records: the control required that all production changes go through a documented approval process — a pull request review, a deployment approval record, or a linked ticket. The company's engineering culture had strong pull request discipline for feature changes. Hotfixes and infrastructure configuration changes were a different story. Over the twelve-month observation period, the infrastructure lead had made 47 direct production configuration changes — updating environment variables, adjusting autoscaling parameters, rotating credentials, modifying S3 bucket policies — using the AWS console and CLI without corresponding pull requests or linked tickets. These changes were visible in AWS CloudTrail but had no associated approval records. The auditor identified 23 of the 47 as in-scope change management control failures because they affected production systems that handled customer data.

Vendor risk assessments: the control required annual assessments of vendors with access to production systems or customer data. The company used forty-one third-party vendors. The infrastructure lead had conducted vendor assessments for the seven highest-risk vendors — AWS, GitHub, Okta, Stripe, SendGrid, Intercom, and Datadog — at the program start. The remaining thirty-four vendors had not been assessed. The auditor flagged eighteen of the thirty-four as in-scope based on their access to production systems or their processing of customer personal data. The company had to conduct and document eighteen vendor assessments in the four weeks before the audit engagement could proceed, which required reaching out to vendors for their own security documentation, reviewing it, and producing risk assessment records dated within the observation period. Seven of the eighteen vendors did not respond within the four-week window.

The pre-audit remediation sprint took six weeks rather than the original three-week estimate. The infrastructure lead spent four of those six weeks on compliance remediation rather than on the product work the sprint had been planned around. The total engineer-hours spent on remediation were approximately 240 — equivalent to six weeks of one full-time engineer. The compliance automation platform cost of $24,000 per year would have been recovered in the first year by avoiding approximately 120 of those 240 remediation hours at a loaded engineer cost of $200 to $250 per hour, producing a net positive return in the first audit cycle alone. The decision to avoid the platform cost had been made without an estimate of the remediation cost that manual collection failures would produce.

A 22-person developer tooling company built a static analysis platform for backend engineering teams — code quality gates, dependency vulnerability scanning, and a technical debt tracking dashboard. The company had grown to twenty-two people over two years, with an engineering team of ten. In year two, the company entered its first Series A enterprise sales cycle with a 1,200-person financial services technology company. The deal was $180,000 ARR. In the fifth week of the sales cycle, the prospect's vendor security team sent a security questionnaire that included the requirement: "Provide SOC 2 Type II report for the relevant observation period, or indicate your planned timeline for achieving SOC 2 Type II." The company did not have a SOC 2 report. The head of engineering, the CEO, and the fractional CFO held a planning session to evaluate options and their timelines.

The planning session identified four facts. First, a SOC 2 Type II audit requires a minimum observation period of six months — the period during which controls are in operation and for which evidence is collected. Most auditors require six to twelve months for a first engagement. Second, before the observation period can begin, controls must be implemented — the control implementation sprint typically takes three to six weeks. Third, after the observation period closes, the auditor conducts fieldwork and issues the report — this typically takes six to eight weeks. The minimum timeline from program start to report issuance is therefore approximately eight to ten months. Fourth, the prospect's procurement timeline — which the sales team confirmed — had a vendor security approval deadline of five months from the start of the sales cycle. The company was in week five of the cycle. Four and a half months remained. The minimum Type II timeline was eight to ten months.

The company could offer the prospect a SOC 2 Type I report instead. A Type I audit examines whether controls are in place at a single point in time, without an observation period requirement. A Type I could be completed in two to three months from program start: three weeks of control implementation, one week of auditor fieldwork, and three to four weeks for report preparation and issuance. The company could have a Type I report within the prospect's procurement window. The sales team asked the prospect's vendor security team whether a Type I would satisfy the requirement while the company pursued Type II. The prospect's vendor security team reviewed the question with their procurement leadership and returned an answer in five days: the company's security policy required Type II for vendors handling production financial data. Type I was acceptable only for vendors in a limited pilot or sandbox integration. The deal required Type II.

The company began the Type II program immediately. The observation period start was set for four weeks out, following the control implementation sprint. The six-month observation period would close eight months later. The auditor's fieldwork and report issuance would take six to eight weeks beyond that. The earliest possible Type II report issuance was ten months from program start — five months past the prospect's procurement deadline. The deal was lost in month six of the compliance program, before the observation period had closed. The financial services technology company had found an alternative vendor with an existing SOC 2 Type II report.

The engineering retrospective after the deal loss identified the decision that had created the constraint: the company had not started the SOC 2 program until the first enterprise deal required it. The company had been targeting enterprise deals since month six of year one — fifteen months before the deal that required SOC 2. A program started at month six of year one would have produced a Type II report at month sixteen, two months before the deal entered its procurement phase. The cost of starting the program fifteen months earlier would have been the compliance platform subscription and the control implementation engineering work — approximately $45,000 in platform costs and 200 engineer-hours at the company's loaded cost. The cost of losing the $180,000 ARR deal was larger than the cost of early program start by a factor of approximately four. The decision to defer the compliance program until it was required by a named customer had been made implicitly — it had never been discussed as a decision, only as a deferral that seemed reasonable when SOC 2 was a future concern rather than an active procurement requirement.

Structural properties set by the SOC 2 compliance decision

Three structural properties are determined when a company decides — or fails to explicitly decide — how to approach SOC 2 compliance: what the Trust Service Criteria scope selection determines about the control evidence accumulation surface as the compliance program runs through its observation period, what the evidence automation model determines about the compliance drift maintenance gap as months pass between the initial control implementation sprint and the audit engagement, and what the Type I vs Type II timing decision determines about the enterprise pipeline readiness surface as deals enter procurement cycles that require a completed report. None of these are labeled as decisions in the conversations that produce them. The scope selection emerges from a planning session where the sales team argues for comprehensiveness and the compliance advisor notes that scope expansion is harder than starting broad. The evidence automation decision emerges from a cost comparison where the platform subscription is a visible line item and the remediation cost of manual collection failures is not yet visible. The Type I vs Type II timing decision emerges from the assumption that SOC 2 can be started when it is needed — an assumption that does not account for the observation period requirement that makes reactive compliance program starts incompatible with enterprise procurement timelines.

Property 1: The TSC scope selection and the control evidence accumulation surface. The Trust Service Criteria scope selection is the foundational decision that determines the size of the compliance program — the number of controls the company must implement, operate, and evidence throughout the observation period. Security is the required criterion and forms the complete basis for the security posture most enterprise procurement teams are evaluating when they ask for SOC 2. The optional criteria — Availability, Confidentiality, Processing Integrity, and Privacy — each add control categories that require ongoing evidence collection, control owner time, and auditor examination. The evidence accumulation surface is the total recurring effort required to maintain a complete evidence trail across all in-scope controls throughout the observation period. The surface grows nonlinearly with each additional criterion because the additional criteria introduce new control categories that interact with the existing Security controls (Privacy requires documenting data handling practices in the Security controls that cover data access, not just in the Privacy-specific controls) and require evidence collection from systems that were not in scope for Security-only (Privacy requires vendor assessments for any vendor that processes personal data, which includes tools in the marketing, support, and analytics stack that are not covered by the Security criterion's vendor assessment controls). The scope selection should be made against specific named customer requirements, not against anticipated future requirements. The evidence accumulation burden of each optional criterion should be estimated before the scope is committed — a practical estimate is the number of additional controls the criterion adds multiplied by the average monthly evidence collection time for each control, which produces an engineering-hours-per-month estimate that can be compared to the capacity the company has available for compliance work alongside product engineering. Connect this property to the security ADR on threat model and compliance scope: the threat model decisions — what data the system handles, what its attack surface is, and what the impact of a security incident would be — determine which of the optional Trust Service Criteria are legitimately in scope based on what the system actually does; a company whose system processes personal data has a genuine compliance obligation around Privacy that is independent of whether any customer has yet asked for a Privacy criterion audit; a company whose system provides a critical workflow with defined uptime guarantees has a genuine obligation around Availability; the threat model provides the honest basis for scope selection that neither overstates the compliance posture nor defers criteria that the system's actual risks require.

Property 2: The evidence automation model and the compliance drift maintenance gap. The evidence automation model is the decision about whether compliance evidence is collected by a person following a calendar, or by a platform that integrates directly with the production environment and pulls evidence automatically. The compliance drift maintenance gap is the evidence deficit that accumulates between collection cycles when evidence collection is a human-owned task without a dedicated owner — the months of access review records that are missing because the collection event was skipped during a product sprint, the change management approval records that are absent because the deployment process did not enforce structured approval capture, the vendor assessment records that are incomplete because the vendor did not respond within the assessment window and no one followed up. The gap is structurally invisible during the observation period because the compliance dashboard, if manual, shows only what has been collected — it does not surface what should have been collected and was not. The gap becomes visible when the auditor requests the full observation period evidence and the control owner conducts the first comprehensive inventory of what exists. The decision between a compliance automation platform and manual collection is often framed as a cost decision: the platform subscription versus the engineer-hours the platform saves. The frame is incomplete because it excludes the remediation cost that manual collection failures produce — the engineer-hours spent conducting retroactive evidence collection in the weeks before the audit engagement, the auditor fees for extending the engagement timeline to accommodate remediation, and the reputational cost of a Type II report that covers a shorter observation period than planned because the evidence for the first months was not adequate for examination. The accurate frame for the cost decision includes the expected remediation cost under the manual collection model, which requires an honest estimate of how consistently the collection calendar will be maintained when it competes with product delivery work for the same engineers' time. Connect this property to the audit log decision record: the audit log infrastructure decisions — what events are logged, how logs are retained, and how they are made accessible — are the primary source of continuous evidence for the Security criterion's change management, incident detection, and access monitoring controls; an audit log infrastructure that produces timestamped, tamper-evident records of all production access and changes is the foundation of automated evidence collection, because the compliance platform's integrations can pull from the audit log directly; an audit log infrastructure with gaps, short retention, or limited coverage produces the same evidence gaps in automated collection that calendar failures produce in manual collection — the platform can only pull evidence that exists.

Property 3: The Type I vs Type II timing decision and the enterprise pipeline readiness surface. The Type I vs Type II timing decision is the decision about when to begin the SOC 2 Type II program relative to the company's enterprise sales pipeline. The Type II report is the report that enterprise procurement teams require — it tests whether controls operated effectively over time, not just whether they exist at a point in time, and the observation period requirement creates a structural minimum timeline from program start to report issuance that is eight to ten months for a first engagement. The enterprise pipeline readiness surface is the gap between the compliance program's current state and the state required by the first deal that needs a Type II report — a gap that grows nonlinearly from zero (no program, no pipeline) to insurmountable (deal in procurement, no program started, eight months required) when the compliance program start is deferred past the point where the timeline fits within the deal cycle. The most reliable trigger for starting the Type II program is the first named enterprise prospect in the sales pipeline — not the first deal that specifically asks for SOC 2, but the first deal whose size and company profile suggest that a vendor security review involving SOC 2 is likely. Enterprise companies with formal vendor management programs almost universally require SOC 2 Type II for vendors handling production data, whether or not the initial security questionnaire explicitly states the requirement. Starting the program when the first enterprise prospect enters the pipeline, rather than when the first prospect requires the report, closes the readiness gap before it becomes a deal constraint. Connect this property to the access control model decision record: the access control model decisions — how access is provisioned, how it is reviewed, and how access for departed personnel is revoked — are the central requirements of the Security criterion's CC6 controls, which cover logical access and are the controls most commonly examined in depth during a Type II audit; a company that has implemented a principled access control model before starting the SOC 2 program has a material head start on the control implementation sprint, because the access management controls are already operating as designed; a company that implements access controls during the compliance program's control implementation sprint must both build the access management infrastructure and operate it long enough to produce a full observation period evidence trail, which extends the program timeline. The WhyChose extractor finds the SOC 2 compliance decisions buried in your AI chat history — the planning session where the TSC scope was set based on sales team anticipation rather than named customer requirements, the tooling discussion where the compliance platform cost was compared to the platform subscription without an estimate of the manual collection failure remediation cost, and the enterprise sales cycle debrief where the Type II timing decision emerged as an implicit deferral that was never evaluated against the observation period timeline constraint.

The SOC 2 compliance ADR: five sections

Section 1: Trust Service Criteria scope selection and evidence burden estimate. Specify which Trust Service Criteria are in scope for the audit, with the customer requirement justification for each criterion beyond Security. For each criterion in scope, document: the named customer or regulatory requirement that justifies including the criterion (if Security-only is the choice, document that no named customer has specified an additional criterion, which makes the justification for scope expansion explicit if the scope changes later); the number of controls the criterion adds to the Security baseline; and an estimate of the monthly evidence collection time the criterion requires, calculated as the number of controls multiplied by the average collection time per control per month. The evidence burden estimate should be compared against the compliance engineering capacity the company has available — the person-hours per month that can be dedicated to evidence collection without conflicting with product engineering velocity. If the evidence burden estimate for the proposed scope exceeds the available capacity, the scope selection must either add capacity (dedicated compliance engineering, a compliance automation platform, or a fractional compliance engineer) or reduce scope to Security-only until additional capacity is available. Document the scope selection decision with the evidence burden calculation and the capacity assessment, so that future scope expansion decisions are made against the same framework rather than repeating the availability-versus-burden analysis from scratch. Connect this section to the security ADR on threat model and compliance scope: the threat model decisions establish which optional criteria are genuinely in scope based on what the system processes and what risks it presents; the scope selection ADR should cross-reference the threat model to confirm that the scope selection reflects actual system risk rather than sales team preference, and should document explicitly which optional criteria the threat model identifies as relevant but the company has deferred, with the condition that would trigger scope expansion.

Section 2: Evidence automation model selection and collection ownership structure. Specify whether evidence will be collected by a compliance automation platform or by a human following a collection calendar, with the ownership structure and failure mode analysis for the chosen model. For a compliance automation platform: specify which platform (Vanta, Drata, Secureframe, Sprinto, or other), which integrations will be enabled at program start, which controls the platform will automate evidence for, and which controls require manual evidence collection that the platform cannot automate (physical security controls, custom internal process evidence, in-person training completion records). For a manual collection model: specify the control owner for each control category, the collection frequency for each control's evidence, the escalation path when a collection event is missed (who is notified, what the remediation window is, and what constitutes a compliance control failure versus a remediable evidence gap), and the audit preparation timeline (how many weeks before the audit engagement opens the control owners begin the evidence package review, so that gaps discovered during preparation can be remediated within the observation period rather than after). The failure mode analysis for manual collection should enumerate the conditions under which collection events are most likely to be missed — product launch sprints, employee leave, engineering team turnover — and specify the mitigations for each (redundant ownership for each control, calendar reminders with escalation contacts, quarterly evidence completeness checks that surface gaps while remediation is still possible). Connect this section to the audit log decision record: the audit log infrastructure decisions determine which controls can be evidenced automatically from log data and which require separate evidence collection; a comprehensive audit log infrastructure reduces the manual evidence collection burden by making change management, access monitoring, and incident detection controls evidenceable from the same log data that the operations team already maintains for non-compliance purposes; documenting the specific log queries or exports that produce each control's evidence in the audit log ADR creates a reusable evidence collection specification that reduces preparation time in subsequent audit cycles.

Section 3: Type I vs Type II timeline planning and enterprise pipeline trigger. Specify the planned timeline for achieving SOC 2 Type II — the milestone that enterprise procurement requires — with the program start trigger based on the enterprise sales pipeline. The program start trigger should be specified as a pipeline signal rather than a deal event: the first named enterprise prospect in the sales pipeline (a company with more than 500 employees, formal vendor management, or an industry sector with known SOC 2 requirements such as financial services, healthcare, insurance, or government contracting) triggers program initiation, regardless of whether the prospect's security questionnaire has yet arrived. Document the minimum Type II timeline from program start: control implementation sprint (three to six weeks), observation period (six to twelve months for the first engagement — confirm the duration with the chosen auditor before committing), and auditor fieldwork and report issuance (six to eight weeks). The total minimum timeline should be compared against the typical enterprise procurement timeline for the company's deal size — if the minimum Type II timeline is longer than the typical procurement cycle, the program must start before the first enterprise prospect enters the pipeline, triggered by ICP (customer profile) rather than by a specific prospect. Connect this section to the CI/CD pipeline security decision record: the change management controls in the Security criterion require that all production changes go through a documented approval process; the CI/CD pipeline's approval enforcement — whether deployments require pull request reviews, whether there are protected branches, whether the pipeline generates a deployment record that can serve as change management evidence — is the primary determinant of whether the change management controls have adequate evidence from day one of the observation period or whether the change management evidence trail requires a parallel manual process to supplement the pipeline's existing records; a CI/CD pipeline that enforces structured change approval before the SOC 2 program starts reduces the change management control implementation sprint to documentation and verification rather than infrastructure change.

Section 4: Control owner structure and compliance capacity model. Specify the control ownership structure for the entire control set, with the capacity allocation for each owner and the conflict resolution model for when compliance work competes with product engineering velocity. The control owner structure should assign each control to a named owner (not a role — a person), with a named backup owner for each control who is responsible when the primary owner is unavailable. The capacity allocation should specify the compliance engineering capacity in person-hours per month that each control owner commits to the program for the observation period — a number that is agreed with the control owner and their manager before the program starts, so that the allocation is a constraint on sprint planning rather than a retroactive explanation for missed evidence collection. The conflict resolution model should specify what happens when compliance work exceeds the allocated capacity during a product sprint: whether the backup owner takes the overflow, whether the sprint scope is reduced to protect the compliance allocation, or whether the evidence gap is remediated in the following period (and what constitutes a remediable gap versus a control failure under the auditor's standards). Connect this section to the secrets management decision record: the secrets management infrastructure decisions — how credentials are stored, how access to secrets is controlled, and how credential rotation is managed — are the direct operational implementation of the Security criterion's CC6 controls covering encryption and key management; control owners responsible for CC6 evidence need access to the secrets management audit trail (who accessed which secrets, when, and what changes were made to access policies) as continuous evidence of secrets management control operation; secrets management infrastructure that does not produce an auditable access trail requires a compensating control (manual access review logs, periodic exports) that adds to the control owner's evidence collection burden.

Section 5: Audit vendor selection and observation period preparation protocol. Specify the auditing firm, the observation period start and end dates, the pre-engagement evidence preparation protocol, and the criteria for selecting the audit firm. The audit firm selection criteria should include: experience with companies at the company's stage (first-time SOC 2 engagements require an auditor who will provide pre-engagement guidance rather than assuming controls are already implemented), the observation period length requirement (some auditors require twelve months for a first engagement; others accept six months — confirm the requirement before the observation period starts), and the report format (some enterprise procurement teams require reports in specific formats; confirm that the auditor's report format meets the prospect's requirements before engaging). The observation period start date should be set only after the control implementation sprint is complete — not before, because evidence collected before controls are implemented does not satisfy the control operation requirement. The pre-engagement evidence preparation protocol should specify: how many weeks before the observation period close the control owners begin the evidence package assembly, how long the pre-engagement evidence review takes to identify and remediate gaps, and what the escalation path is if the gap remediation period extends past the engagement start date. A practical preparation protocol is six weeks: four weeks for evidence package assembly and gap identification, two weeks for gap remediation for gaps that can be addressed within the observation period, and escalation to the auditor for gaps that cannot be remediated before the engagement starts. Document the preparation protocol in the compliance calendar before the observation period begins, so that the preparation timeline is a planned constraint rather than a reactive sprint triggered by the auditor's evidence request. Connect this section to the access control model decision record: the access control model decisions determine the architecture of the CC6 controls, which are typically the deepest area of auditor examination in a Type II engagement; access control models that are implemented with automation (Okta or similar identity provider, access provisioning through the identity provider's lifecycle management, and quarterly access reviews triggered by the identity provider's reporting) produce a complete evidence trail automatically and reduce the CC6 pre-engagement preparation to verification rather than reconstruction; access control models that rely on manual provisioning and ad hoc access reviews require the control owner to reconstruct the access review trail from multiple systems during pre-engagement preparation, which is the most common source of evidence gaps in first-time Type II audits.

FAQ

How should a startup decide which SOC 2 Trust Service Criteria to include in its first audit scope?

Begin with Security only unless there is a documented requirement from a named customer or a regulatory obligation for an additional criterion. The Security criterion covers the common controls most enterprise procurement teams evaluate — access management, change management, risk assessment, incident response, logical and physical security — and it forms the complete basis for the security posture most B2B SaaS buyers are verifying when they ask for SOC 2. Adding Availability, Confidentiality, Processing Integrity, or Privacy adds new control categories, new evidence requirements, and new auditor procedures that increase the ongoing evidence accumulation burden for the entire observation period. Adding these criteria before they are required by a named customer consumes compliance engineering capacity that would otherwise go to strengthening the Security controls and closing the gaps that the audit will actually test. The trigger for adding an optional criterion is a named customer requirement — a security questionnaire, a procurement addendum, or a vendor management requirement from a specific deal — not a sales team anticipation of future requirements. When a named customer requires an additional criterion, add it at the start of the next audit cycle when the observation period begins fresh, not mid-observation period where the evidence collection for the new criterion begins from an already-partial window.

What does a compliance automation platform like Vanta or Drata actually do, and when is manual evidence collection adequate?

Compliance automation platforms integrate directly with the production environment — AWS, GCP, Azure, GitHub, Okta, Google Workspace, Slack, Jira, and dozens of other systems — and pull evidence automatically on the platform's collection schedule. For each integrated system, the platform pulls user access lists for periodic access review, configuration snapshots for policy compliance checks, deployment records for change management evidence, vulnerability scan results for monitoring controls, and security alert records for incident detection controls. The platform stores these with timestamps, maps them to the specific controls they satisfy, and presents a compliance dashboard showing which controls have current evidence and which have evidence gaps. Manual evidence collection is adequate when the engineering team has a dedicated person — not a shared responsibility — who owns the evidence collection calendar, who treats compliance evidence collection as a first-priority task competing with product work, and who has enough technical access to pull evidence items directly rather than requesting them from other team members. In practice, manual collection is adequate for teams with a Head of Security or a DevSecOps engineer who can own the compliance program. It becomes inadequate when compliance ownership is shared across engineers who also own product delivery — the evidence collection task loses to product priorities in every sprint, producing the evidence gaps that force remediation work in the weeks before the audit engagement begins.

When should a B2B SaaS start its SOC 2 program relative to its enterprise sales pipeline?

Start the Type II program at the point where the first enterprise deal is a realistic pipeline opportunity — when you have a named prospect in evaluation, when your ICP includes companies with formal vendor security programs, or when your deal size is entering the range where procurement involves a security review team. The minimum Type II timeline from program start is eight to ten months: approximately four weeks to implement controls and open the observation period, six months of observation period at minimum (most auditors require six to twelve months for a first engagement), and six to eight weeks for auditor fieldwork and report issuance. Companies that start the program at Series A or at the first enterprise sales hire are positioned to have a completed Type II report when the first significant enterprise deal reaches the security review stage. Companies that start the program when the first deal requires it face a structural choice: offer the deal the Type I report (which most enterprise procurement teams do not accept as a substitute for Type II) or ask the prospect to wait ten months. Both outcomes are worse than starting the program proactively. The economic argument for early program start: the marginal cost of starting the program twelve months earlier than required is approximately the annual cost of a compliance platform plus the engineer-hours for the initial control implementation sprint. The cost of losing one enterprise deal because the Type II report does not exist is typically larger than the cost of early program start.

What are the most common evidence gaps that cause remediation work in the weeks before a SOC 2 audit?

The five evidence gaps that appear most consistently in pre-audit remediation work are: (1) user access reviews — the control requires periodic review confirming that access is appropriate for current role and that departed employees have been removed; reviews skipped during product sprints create gaps the auditor checks by interval, not just by completion count; (2) change management approvals — production changes made directly without pull request review, deployment approval records, or linked tickets create control failures visible in the git history and deployment log; (3) vendor risk assessments — vendors with access to production systems or customer data require annual assessments; assessments not conducted or not documented create gaps that require retroactive assessment, which does not satisfy the control because the assessment timing is part of the evidence; (4) backup restoration tests — the control requires periodic tests confirming backups are restorable; tests planned but not executed, or executed but not documented, produce a control gap that requires a test with documentation before the audit window closes; (5) security training completion records — annual security awareness training must be tracked with completion records per employee; training conducted without tracked completion records, or with records in a system that does not export in auditor-expected formats, requires re-running the training with proper documentation before the audit.

Structural properties set by the SOC 2 compliance decision

The SOC 2 compliance ADR: five sections

FAQ

Further reading