The Sales Deal Made SOC 2 Urgent. It Didn't Make the Controls Real.

A security questionnaire lands in the inbox of a sixty-person SaaS company on an ordinary afternoon. An enterprise prospect's procurement team wants a SOC 2 report before the deal can clear legal review. The deal is worth more than the company's entire pipeline for the quarter, and someone now has a matter of weeks to produce a document that, as far as most of the executive team understands it, mostly needs to exist.

The task usually lands on whoever is least busy that week, or whoever has something adjacent to "compliance" in their job title without ever having run an audit — an operations manager, a general counsel who has never looked at an IAM policy, occasionally a founder handling it personally between customer calls. That person's job, as the company understands it, is to produce a stack of policies: an access control policy, a change management policy, an incident response policy, a vendor management policy. Templates exist. A compliance automation platform's onboarding wizard will generate most of them by name alone.

What the policies describe and what the systems actually do are, at that point, two separate documents that happen to share a filing folder. The access control policy says access is reviewed quarterly. No one has ever reviewed access. The change management policy says every production change requires a peer-reviewed pull request and a documented rollback plan. Half the engineering team pushes directly to the main branch on a Friday afternoon when no one is watching. The incident response policy names an incident commander and a communication tree that has never been exercised, because nothing resembling a real incident has ever been run against it on purpose.

This is not a failure mode invented for this article. It is the default trajectory of a SOC 2 program that starts as a sales response rather than an engineering decision, and it produces a specific, predictable outcome: a report that a licensed auditor is willing to sign, describing controls that do not reliably operate the way the report says they do. The report satisfies the immediate need — the deal advances, the security questionnaire gets a checkmark — and it creates two lasting problems. The system is not meaningfully more secure than it was the week before the audit; the paperwork changed, the risk didn't. And next year's audit will be exactly as expensive and exactly as disruptive as this one, because nothing about how the organization actually operates changed enough to make renewal any cheaper.

There is a different way to run this, and it does not require walking away from the sales urgency that triggers most SOC 2 programs in the first place. It requires recognizing that the five Trust Services Criteria the American Institute of Certified Public Accountants built SOC 2 around are not, underneath the audit language, a documentation framework. They describe a set of engineering practices — access control, change management, monitoring, incident response, vendor oversight, encryption — that a competent engineering organization has reason to run regardless of whether an auditor ever asks about them. Companies that build those practices as real engineering work, owned by the people who operate the systems, tend to clear their audits with fewer exceptions, spend less on remediation, and find that renewal gets easier with each cycle rather than staying flat. Companies that treat SOC 2 as paperwork assigned to whoever has time get a report once, at real cost, and then largely start over twelve months later.

What a SOC 2 Report Actually Certifies, and What It Doesn't

SOC 2 stands for System and Organization Controls 2, one of a family of attestation frameworks developed and governed by the AICPA for evaluating a service organization's internal controls.¹ The AICPA describes the broader SOC suite as a set of service offerings that licensed CPA firms may provide in connection with system-level controls at a service organization, and SOC 2 specifically evaluates those controls against one or more of five Trust Services Criteria: Security, Availability, Processing Integrity, Confidentiality, and Privacy.¹ The criteria and their detailed points of focus are published by the AICPA in the Trust Services Criteria framework, most recently revised in 2022.²

Two details about that description matter more than they usually get credit for, because both are routinely misstated in vendor marketing and misunderstood inside the companies pursuing the report.

SOC 2 is an attestation, not a certification. A licensed CPA firm examines an organization's controls and issues an opinion about whether those controls meet the relevant Trust Services Criteria. There is no pass/fail badge issued by a central authority the way there is for some certifications; there is a report, written in a specific format, containing the auditor's opinion, a description of the system, and — for a Type II report — the results of testing each control over an observation period. Organizations commonly say they are "SOC 2 certified" as informal shorthand, but the more accurate framing, and the one that matters when a prospect's security team is reading the actual document, is that the organization has undergone an examination and received a report with an opinion attached to it. That opinion can be unqualified (clean), qualified (with noted exceptions), or, in rarer cases, adverse or disclaimed. A report with exceptions is still a report; it is just one that says something specific went wrong during testing, which is exactly the kind of detail a sophisticated enterprise buyer's security team will read closely.

Security is the only mandatory criterion. The other four — Availability, Processing Integrity, Confidentiality, and Privacy — are elected based on what the organization actually does and what its customers reasonably need assurance about. Security is sometimes referred to as the "Common Criteria" because a substantial share of its content overlaps with, and forms the foundation for, the other four categories.³ A company can scope a SOC 2 examination to Security alone, and many do for a first report; a company running infrastructure with real uptime commitments will usually add Availability, and a company processing financial transactions has a strong argument for adding Processing Integrity. Choosing criteria is itself an engineering-relevant decision, not a paperwork one, because each additional criterion adds a distinct set of controls the organization has to actually operate, not just describe.

Type I and Type II: A Point-in-Time Opinion Versus a Sustained One

The distinction between SOC 2 Type I and Type II is the first thing most engineering leaders ask about, and it is also the distinction most consistently oversimplified in marketing copy. A Type I report evaluates whether an organization's controls are suitably designed as of a specific date — a snapshot.⁴ A Type II report evaluates both the design of those controls and whether they operated effectively over a defined period of time, commonly referred to as the observation period.⁴ Vendor and auditor guidance consistently describes that observation period as organization-selected and typically ranging from about three months to a year, with shorter windows more common for a first report and twelve-month windows becoming standard for mature, recurring engagements.^{4 5} This range is consistently reported across auditor and compliance-platform guidance rather than fixed by a single AICPA-published number, so treat "three to twelve months" as the commonly described range rather than a rigid rule — the actual window is a decision the organization makes with its auditor, informed by how much runway it has and how much evidence it can realistically produce.

The practical consequence of this distinction is larger than most first-time SOC 2 programs plan for. A Type I report can be produced relatively quickly once controls are documented and demonstrably in place on a given day — it answers "do these controls exist and make sense," not "have they actually been running." A Type II report cannot be rushed the same way, because by definition it requires controls to have been operating, and generating evidence of that operation, for the entire observation window. An organization that starts building its access review process the week before the audit begins cannot produce six months of quarterly access review evidence no matter how good its intentions are. This is the single most common reason Type II engagements run long or surface exceptions: the organization treated the audit start date as the moment to begin operating the controls, rather than the moment those controls needed to already have a track record.

Table 1 — SOC 2 Type I vs. Type II: what each report actually tests

The table above reflects publicly described audit mechanics from AICPA guidance and auditor/compliance-platform documentation, not proprietary QAtronic data.^{1 2 4 5}

Chart — SOC 2 audit duration by phase, as commonly described in auditor and compliance-platform guidance

This chart reflects real, sourced ranges reported by SOC 2 auditors and compliance-automation vendors describing typical engagement timelines, not a single fixed schedule set by the AICPA. Actual duration varies by organization readiness, auditor availability, and the observation period the organization selects.

Pre-audit prep        ▓▓▓▓▓▓▓▓▓▓▓▓             (1–3 months)
Type I fieldwork+report        ▓▓▓▓▓▓▓          (~5wk–2mo)
Type II observation                  ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓  (3–12 months)
Report delivery                                                                    ▓▓▓▓  (2–6 weeks)

What this shows: the observation period, not the fieldwork itself, is the dominant variable in how long a Type II engagement actually takes — and it is also the phase least compressible by working harder closer to the deadline, since it requires evidence to accumulate across real elapsed time. An organization deciding between a shorter and longer observation period is really deciding how much sustained evidence it wants behind its first report, not how much paperwork it wants to produce.

This is also where the ownership question from the opening of this article becomes concrete rather than abstract. A Type I report can be faked, in the narrow sense that a motivated non-engineering owner can assemble policy documents and point at a system configuration on a single day and get through it. A Type II report cannot be faked the same way, because it requires the underlying practice to have actually been running, continuously, for months, which is a property of how an engineering organization operates day to day — not a property of how well someone can write a policy document under deadline pressure.

The Five Trust Services Criteria as Engineering Requirements

Read as an audit checklist, the five Trust Services Criteria sound like compliance language. Read as a description of what a service organization's systems and processes should actually do, they map cleanly onto categories most engineering leaders already recognize, whether or not they have ever thought about them as "SOC 2 controls."

Table 2 — Trust Services Criteria mapped to concrete engineering controls

This table is built for this article as a synthesis of the AICPA's published Trust Services Criteria categories and the control types commonly associated with each in official and vendor guidance; it is not a reproduction of the AICPA's detailed points-of-focus document, which spells out a much longer and more granular list under each category.^{1 2}

Security: The Criterion That Does Most of the Work

Because Security is mandatory and its content overlaps heavily with the other four, most of the genuinely hard engineering work in a SOC 2 program happens here. Four sub-areas consistently generate the most audit findings and the most engineering effort, and each deserves separate treatment later in this article: access control and least privilege, change management, logging and monitoring, and incident response. A fifth — vendor and subprocessor management — sits partly under Security and partly under whichever other criteria the organization has elected, because a vendor with access to confidential or personal data implicates Confidentiality and Privacy as much as Security.

The reason Security absorbs most of the effort is not that auditors are arbitrarily strict about it. It is that Security controls are the ones most directly falsifiable by an auditor sampling real system behavior rather than reading a policy. An auditor testing access control for a Type II report does not just read the access control policy; they pull a sample of user accounts, check whether access matches documented roles, check whether departed employees' access was revoked within the timeframe the organization's own policy commits to, and check whether that pattern held consistently across the observation period. A policy that says access is reviewed quarterly, backed by zero actual review tickets, fails this test immediately and specifically — which is precisely the gap described in this article's opening.

Availability, Processing Integrity, Confidentiality, and Privacy: The Criteria You Choose

Unlike Security, these four criteria are elected based on the organization's actual business, and the decision of which to include is worth making deliberately rather than by default template selection.

Availability matters most for organizations whose customers depend on uptime commitments — infrastructure providers, API platforms, anything with a published or contractual SLA. Including it means the audit will test whether the organization's failover, backup, and incident response practices around availability actually function, not just whether they're described somewhere.

Processing Integrity matters most for organizations where the correctness of a calculation, transaction, or data transformation has direct financial or operational consequences for customers — billing systems, payment processing, financial reporting tools, marketplaces calculating payouts. It is frequently the most underestimated criterion because it requires demonstrating data accuracy and completeness controls that many engineering teams have never formally tested as a distinct category, even if the underlying logic has been in production and working correctly for years.

Confidentiality and Privacy overlap in practice but are analytically distinct: Confidentiality is about protecting information the organization has committed to keep confidential (which can include business data with no personal component at all, like a customer's proprietary source code or financial models), while Privacy is specifically about personal information and how it is collected, used, retained, and disposed of. A company handling sensitive B2B data but minimal personal information might scope in Confidentiality without Privacy; a consumer-facing product handling significant personal data has a much stronger case for including Privacy, particularly if enterprise customers or regulatory exposure make that assurance commercially relevant.

The decision of which criteria to include should be made jointly by whoever is closest to the sales requirement (to understand what enterprise buyers are actually asking about) and whoever is closest to the systems (to understand what can realistically be demonstrated with real evidence within the chosen observation period). A criterion elected because a template defaulted to it, without anyone checking whether the organization can actually produce evidence for it, becomes an unforced audit risk.

Who Ends Up Owning SOC 2, and Why That Decision Determines Whether It's Real

The single variable that predicts more about a SOC 2 program's outcome than any technical detail is who owns it. Not who signs the final report authorization, but who is accountable, week to week, for making sure the underlying controls actually operate the way the eventual report will describe them.

Three ownership patterns show up repeatedly in growth-stage companies pursuing their first SOC 2 report.

Pattern one: a non-engineering owner writes policies and hopes the systems match. This is the pattern described in this article's opening — an operations, legal, or general-management owner who has never operated the systems being described, working from templates, producing documents that describe an idealized version of the organization's practices rather than a verified one. This pattern is not a failure of the individual doing the work; it is a structural mismatch between what the role requires (verified, testable operational fact) and what the person assigned to it has the authority or technical access to actually verify.

Pattern two: engineering treats it as someone else's project and shows up only when blocked. Slightly better, but still fragile. Engineering leadership delegates a compliance point of contact, provides screenshots and access when asked, and otherwise continues operating exactly as before. Controls get implemented as one-off, audit-driven tasks rather than as changes to how the team actually works, which means they tend to lapse the moment audit pressure lifts — the access review happens once, right before the assessment, and never again until the next renewal cycle creates the same pressure.

Pattern three: an engineering or security leader owns the program and treats the Trust Services Criteria as a set of operational requirements the team should be meeting anyway. In this pattern, access reviews become a recurring calendar item owned by whoever runs identity and access management, not a one-time audit prep task. Change management requirements get enforced through branch protection rules and required reviewers, not a policy PDF. Incident response gets tested through an actual tabletop exercise, not just written down. The controls exist because the team decided they were good practice, and the audit becomes a matter of demonstrating something that was already true, rather than constructing something new under deadline pressure.

Hypothetical example 1 — two ownership models, one deadline. This is a hypothetical, illustrative scenario built for this article, not a real QAtronic client or a documented case. Two SaaS companies of similar size — roughly ninety employees, similar infrastructure complexity — both receive the same enterprise prospect's requirement for a SOC 2 Type II report within a comparable timeframe.

At the first company, the CEO assigns the project to the head of people operations, reasoning that compliance is "an HR-adjacent function" and that engineering is too busy with the product roadmap to take on additional work. The operations lead purchases a compliance automation platform, works through its policy templates, and asks engineering for access to systems to take configuration screenshots. Engineering treats each request as an interruption. Policies get written describing quarterly access reviews and mandatory code review on all production changes — practices the operations lead assumes are already happening because they sound like standard practice, without confirming this against the actual repository settings or IAM console. Six weeks before the audit's evidence collection deadline, the compliance platform's automated evidence checks start flagging failures: no access review tickets exist for the prior two quarters; roughly a third of production deployments in the sampled window have no associated pull request at all, because a subset of the team pushes hotfixes directly to a production branch during incidents. The operations lead escalates to engineering leadership for the first time with six weeks of runway left in a period that was supposed to already have months of evidence behind it.

At the second company, the VP of Engineering takes personal ownership of the program from the outset, reasoning that the underlying controls are engineering's responsibility regardless of who technically manages the audit relationship. Before selecting Trust Services Criteria or evidence tooling, the VP runs a two-week internal assessment against the control areas in Table 2 above, using engineers who already work in the relevant systems (identity and access management, CI/CD, observability) rather than treating it as a separate compliance project. The assessment finds real gaps — no formal offboarding checklist for access revocation, inconsistent enforcement of required pull request reviews across repositories — and the VP treats closing those gaps as engineering work with normal sprint planning and ownership, not as a parallel compliance track. By the time the observation period begins, the controls are already operating as day-to-day practice, and the audit period simply accumulates evidence of something already true.

The consequence: The first company's audit surfaces multiple exceptions related to access review and change management, requires a remediation period, and delays the report the sales deal was waiting on by several weeks past the original enterprise deadline. The second company's audit proceeds with minor findings that get remediated within the observation period itself, because the underlying practice was already close to compliant before the audit began. The decision point this scenario illustrates: whether SOC 2 ownership sits with someone who can write policy but cannot verify system behavior, or with someone who can change system behavior directly. The better approach: assign SOC 2 program ownership to an engineering or security leader with direct authority over the systems being evaluated, even when a compliance, legal, or operations function manages auditor logistics, vendor relationships, and documentation formatting alongside them.

Access Control and Least Privilege: The Control That Breaks Every First Audit

Of every control area covered in this article, access control produces the most audit findings in first-time engagements, and the reason is structural rather than accidental. Access control is the control category most directly testable through sampling — an auditor does not have to trust a description; they can pull a list of user accounts with production access, cross-reference it against current employment and role records, and check whether the access matches what the role actually requires. Any mismatch is an objective, falsifiable finding, not a matter of interpretation.

The most common gap is not initial provisioning — most organizations grant access reasonably deliberately when someone joins or a system first goes into production. The gap is deprovisioning and drift: access granted for a specific, temporary reason that never gets revoked once the reason ends; a contractor's credentials that outlive the contract; an engineer who moves from a backend role with database access to a frontend role that no longer needs it, but whose old permissions were never removed because nothing forced a review. None of these individually look like a security incident. Collectively, they are exactly what "least privilege" as a stated principle is supposed to prevent, and exactly what an auditor's access sample is designed to catch.

Building a control that actually closes this gap requires two distinct mechanisms working together, and conflating them is a common design mistake. The first is an event-triggered process: when someone changes roles or leaves the organization, access changes should be triggered automatically or through a defined, owned workflow — not left to whoever happens to remember. The second is a periodic, independent review: because event-triggered processes have gaps (a role change that doesn't go through the formal process, a permission granted informally outside the standard provisioning flow), a recurring review that samples current access against current role, on a defined cadence, catches what the event-triggered process misses. A program that has only the first mechanism will accumulate drift from anything that bypasses the formal workflow. A program that has only the second mechanism will carry stale access for the full length of the review interval before catching it. Both are needed, and both need to produce a retained record — a ticket, a signed-off spreadsheet snapshot, an audit log entry — because the record, not the practice alone, is what a Type II examination actually tests.

Hypothetical example 2 — the access grant that outlived its reason. This is a hypothetical, illustrative scenario, not a documented incident or a real QAtronic client. A mid-sized SaaS company's data engineering lead needs temporary elevated access to the production database to debug a data pipeline issue during an incident. The access is granted quickly, appropriately, through the on-call escalation process, and the incident is resolved within a day. No process exists to automatically expire incident-granted access once the incident closes, and no one owns a follow-up task to revoke it. The engineer moves to a different team eight months later, working on a product area with no legitimate need for production database access at all. The old grant is never touched during the transition, because the offboarding checklist for a role change (as opposed to full termination) does not include an access audit step.

During Type II testing, the auditor's access sample includes this account. The finding is specific: an individual with confirmed elevated database access whose current role has no documented justification for it, and no review record showing this was ever caught. This becomes a control exception in the report — not because the original grant was wrong, but because nothing in the organization's actual process caught and corrected the drift once the original justification expired. The decision point: whether access grants tied to a specific, time-bound reason (an incident, a project, a temporary assignment) have any mechanism forcing review or automatic expiration, or whether they default to permanent until someone happens to notice. The better approach: time-bound or incident-triggered access grants should default to automatic expiration or a mandatory follow-up review within a defined window — commonly 30 to 90 days depending on the sensitivity of the system — rather than persisting indefinitely on the assumption that someone will eventually remember to revisit them.

Change Management and Code Review as an Audit Trail, Not Just a Development Practice

Most engineering organizations already have something resembling change management: pull requests, code review, a CI pipeline, a deployment process. What SOC 2 asks for is not fundamentally different practice — it is the same practice, applied consistently enough, and recorded durably enough, to produce evidence rather than just habit.

The gap that shows up most often is not the absence of a code review culture. It is inconsistency at the edges: a hotfix pushed directly to production during an incident, bypassing the normal review flow because speed mattered more than process in that moment; a script run manually against production data outside the deployment pipeline entirely; an infrastructure change made directly in a cloud console rather than through infrastructure-as-code with its own review step. Each of these is individually defensible as an engineering decision made under real operational pressure. Collectively, sampled by an auditor across an observation period, they show up as a percentage of changes with no associated review record — and there is no threshold at which "we do this most of the time" satisfies a control that is supposed to apply consistently.

The engineering-correct response to this is not to eliminate legitimate emergency change paths — a rigid process that makes incident response slower in the name of compliance produces worse outcomes on both the Availability and Security criteria than a flexible one. The correct response is to make the emergency path itself auditable: a documented, narrower "break-glass" process for emergency changes that still requires a retroactive review and a record of why the normal path was bypassed, rather than an undocumented informal exception that different engineers interpret differently. A change management control that has a legitimate emergency exception, consistently followed and consistently logged, is stronger — both for the audit and for actual operational safety — than one that pretends emergencies never happen and gets quietly violated whenever they do.

Table 3 — Change management maturity: what auditors typically sample versus what most teams have

This table is a synthesis built for this article based on common patterns in engineering change management practice and SOC 2 audit sampling behavior, not a reproduction of any specific auditor's testing methodology.

Logging, Monitoring, and the Alert Nobody Reads

Logging and monitoring sit at the intersection of Security and Availability, and they are unusual among SOC 2 control areas because most engineering organizations already have the underlying technical capability — centralized logging, some form of alerting, dashboards for key system metrics — well before anyone frames it as a compliance requirement. The gap is rarely technical capability. It is whether that capability is connected to a defined human response process, and whether that connection can be demonstrated with evidence rather than asserted.

An auditor testing this control area is typically looking for three things working together: that security-relevant events are actually logged (authentication events, access changes, administrative actions, error rates on critical systems); that alerts exist for the events that matter, routed to a destination someone actually monitors; and that there is a record of what happened when an alert fired — that someone looked at it, made a determination, and, if needed, acted on it. A logging pipeline that captures everything but alerts on nothing satisfies the first requirement and fails the other two. An alerting system that fires constantly, to a channel everyone has muted because the signal-to-noise ratio is unbearable, technically satisfies "alerts exist" while failing the practical intent of the control entirely — and a good auditor asking follow-up questions about alert response will surface this quickly.

The most efficient way to close this gap in an organization that already runs modern observability tooling is not to buy a separate compliance-specific monitoring product. It is to make sure the monitoring infrastructure already in place for operational reasons — the same dashboards and alerting an SRE or on-call engineer already relies on — has explicit coverage for the security-relevant events the Trust Services Criteria care about, and that the response to those alerts is logged somewhere durable rather than living only in a Slack thread that eventually scrolls out of anyone's memory. A ticketing system entry, a runbook execution record, or a structured incident log entry all work; what matters is that the record persists past the moment the alert was addressed and can be produced later as evidence that the response actually happened.

Incident Response: The Policy Document Versus the Actual Event

Every organization pursuing a SOC 2 report has an incident response policy by the time the audit happens, because it is one of the easiest documents to produce from a template. Very few organizations pursuing their first SOC 2 report have ever actually tested that policy against a realistic scenario before an auditor asks about it — and the gap between a policy that exists on paper and a process that has been exercised is exactly where the most consequential failures in this control area happen, because it is the one area where the cost of discovering the gap during a real incident, rather than during a drill, is highest.

Hypothetical example 3 — the incident response plan that had never been tested. This is a hypothetical, illustrative scenario, not a documented incident or a real QAtronic client. A growth-stage fintech company's incident response policy, written as part of its SOC 2 preparation, names a specific incident commander role, a defined severity classification scheme, and a communication process requiring customer notification within a stated timeframe for incidents meeting a defined severity threshold. The policy is well-written, reviewed by legal, and signed off by leadership. It has never been run against a simulated incident.

Three months into the audit's observation period, a genuine incident occurs: a misconfigured access control change, unrelated to the SOC 2 preparation itself, briefly exposes a subset of customer account data to users who should not have had access to it. The team responds quickly on the technical side — the misconfiguration is identified and reverted within roughly an hour. But the incident response process itself does not run the way the policy describes. The person named as incident commander in the policy document left the company two months earlier, and no one updated the document. The severity classification scheme, never having been applied to a real event, turns out to be ambiguous about a scenario like this one — reasonable people on the response call disagree in real time about whether it meets the threshold that triggers customer notification. The eventual notification goes out, but roughly a day later than the policy's own stated commitment, because the ambiguity cost real time to resolve under pressure.

The consequence: The incident itself is resolved without material customer harm, but it becomes a Security-criterion finding in the Type II report — not because the underlying technical response was inadequate, but because the auditor's testing of the incident response control specifically checks whether the organization's actual response, during the observation period, matched its documented process, and this one did not, on two independently verifiable points (an outdated role assignment and a missed notification commitment). The decision point: whether an incident response policy is treated as complete once it is written and approved, or whether it is treated as complete only once it has been exercised against something realistic enough to surface the gaps a tabletop exercise is specifically designed to find. The better approach: run at least one structured incident response tabletop exercise — a realistic, deliberately imperfect scenario walked through by the actual people named in the plan — before the observation period begins, and repeat it periodically rather than treating the original policy document as permanently accurate. A tabletop exercise is inexpensive relative to what it catches: outdated role assignments, ambiguous severity thresholds, communication commitments that sound reasonable on paper but are difficult to meet in practice, are all far cheaper to discover in a scheduled two-hour exercise than during a real incident with a compliance deadline attached to it.

Vendor and Subprocessor Management: Scope Doesn't End at Your Own Infrastructure

A service organization's SOC 2 scope does not stop at the boundary of infrastructure it directly controls. Nearly every modern SaaS company relies on subprocessors — cloud infrastructure providers, payment processors, customer support platforms, analytics tools, and, increasingly, third-party AI models and AI-powered features — that touch customer data in some form, and the Trust Services Criteria expect the organization to have a defined process for evaluating and monitoring those relationships, not simply trusting that a vendor's own marketing claims about security are sufficient.

This control area has become materially more complicated over the past several years for a specific reason worth naming directly: the rapid adoption of third-party large language model APIs and AI-powered features has created a new, fast-growing category of subprocessor relationship that many vendor management processes built before 2023 were never designed to evaluate. A support team integrating an AI-powered chatbot, a product team adding an AI writing assistant, or an engineering team calling a third-party model API to generate summaries of customer data are all creating new data flows to new subprocessors — often through vendor sign-up flows that move faster than any formal procurement review, sometimes through an individual employee's own account rather than a company-level agreement. A vendor management process that only reviews vendors procured through a formal purchasing workflow will systematically miss this category, precisely because it is the category most likely to be adopted informally, by a team eager to ship a feature, without anyone treating it as a vendor decision at all.

A practical vendor and subprocessor management process, built to satisfy this control area without becoming an unworkable bottleneck, generally includes:

• An inventory of every third party that stores, processes, or has access to customer data — including AI model providers, not just traditional infrastructure and SaaS vendors — maintained as a living document rather than assembled once for the audit.
• A risk-tiering approach, since not every vendor warrants the same depth of review; a payment processor handling financial data warrants deeper scrutiny than an internal project management tool with no customer data access.
• A due diligence step at onboarding, appropriately scaled by tier — reviewing a vendor's own SOC 2 report or equivalent certification where one exists, and asking specific, scoped security questions where it doesn't.
• A mechanism to catch informally-adopted tools, since the highest-risk gap in this area is not the vendors that went through a formal process, but the ones that didn't — commonly addressed through a combination of a lightweight self-service intake form for any new tool touching customer data and periodic reconciliation against actual data flows, network egress patterns, or SSO application usage.
• Contractual terms flowing down relevant confidentiality and data protection obligations, particularly for any vendor with access to data covered under the organization's elected Confidentiality or Privacy criteria.

None of this requires a heavyweight enterprise vendor risk management platform for a growth-stage company. It requires a defined owner, a maintained list, and a consistent, appropriately-scaled review step applied before a new tool starts touching customer data — not after an auditor asks whether the AI feature shipped last quarter went through any review at all.

Hypothetical example 4 — the AI feature that shipped through nobody's review. This is a hypothetical, illustrative scenario, not a documented incident or a real QAtronic client. A customer support team at a mid-market SaaS company adopts a third-party AI writing assistant to help agents draft faster responses to support tickets, which frequently contain account details, billing history, and occasionally screenshots pasted directly into the ticket body. The tool is free to start, requires only an individual sign-up, and is adopted informally within the support team over the course of a few weeks — no procurement request, no security review, because from the support team's perspective it is a productivity tool, not a new subprocessor relationship.

By the time the company's SOC 2 program begins its vendor inventory exercise, the tool has been in active use for several months, processing a meaningful volume of customer support content, including data that falls under the company's elected Confidentiality criterion. No due diligence was performed on the vendor's own data handling practices, no contractual data protection terms were reviewed, and no one had evaluated whether the tool's default configuration retained submitted content for model training purposes — a setting that varies significantly across AI vendors and is not something a support agent signing up for a productivity tool would typically think to check.

The consequence: The vendor inventory exercise surfaces the tool as an unreviewed subprocessor with access to confidential customer data, and the company has to make a rushed decision mid-program: attempt retroactive due diligence and contractual remediation with the vendor under time pressure, or discontinue the tool and disrupt a workflow the support team has come to rely on, either of which is more disruptive than a review would have been before adoption. The decision point: whether a lightweight, fast, self-service intake step exists for any team wanting to adopt a new tool that will touch customer data — including AI tools adopted for reasons that feel more like personal productivity than formal procurement — or whether the only review mechanism is the periodic vendor inventory audit that catches these tools long after they're already embedded in daily workflow. The better approach: a short, low-friction intake form — answerable in minutes, not a multi-week procurement cycle — that any employee completes before connecting a new tool to customer data, paired with periodic reconciliation against actual SSO application usage and network activity to catch anything that bypassed even that lightweight step.

Encryption and Data Protection: Where "We Use a Major Cloud Provider" Stops Being a Complete Answer

Encryption is one of the more mechanically straightforward control areas covered by SOC 2, and it is also one of the areas where a partially-correct answer is most likely to be mistaken for a complete one. "We use a major cloud provider, and they encrypt everything by default" is true as far as it goes — default encryption at rest for managed storage and database services is now standard practice across major cloud providers — but it answers only part of what the Confidentiality and Security criteria actually ask.

The parts most commonly missed are encryption in transit for internal service-to-service communication (not just the customer-facing edge, which teams reliably get right, but internal traffic between services, which is more often assumed rather than verified), key management practices for any encryption keys the organization manages itself rather than delegating entirely to the cloud provider's managed key service, and encryption coverage for secondary data stores that accumulate outside the primary production database — data warehouses, analytics pipelines, backup exports, log aggregation systems, and staging or QA environments seeded with production-like data. A production database that is correctly encrypted at rest, feeding an analytics warehouse or a set of CSV exports used for internal reporting that are not held to the same standard, is a genuine and common gap — and one that an auditor's data flow mapping exercise is specifically designed to surface, because the control is meant to apply to where confidential data actually lives, not just where it originates.

The practical takeaway for an engineering team preparing for this control area is to treat "where does this data live, in every form it takes as it moves through our systems" as the actual question, rather than confirming encryption once at the primary data store and assuming the answer generalizes to every downstream copy.

The Engineering Readiness Sequence

The control-by-control detail above is more useful once it is organized into an actual sequence — the order in which an engineering-led SOC 2 program should approach the work, rather than a checklist to complete in whatever order feels convenient.

1. Decide ownership before anything else. Name a specific engineering or security leader as the program owner, with direct authority over the systems being evaluated, before selecting Trust Services Criteria, before choosing a compliance automation vendor, before contacting an auditor. Everything downstream works better when this decision happens first rather than as a mid-program correction.
2. Elect Trust Services Criteria deliberately, based on what customers actually need assurance about and what the organization can realistically demonstrate, not by accepting a template default. Involve whoever owns the enterprise sales relationship driving the requirement, since they know what specific assurances prospects are actually asking about.
3. Run an honest internal gap assessment against the control areas covered above — access control, change management, logging and monitoring, incident response, vendor management, encryption — using people who actually operate the relevant systems, not an outside party working from documentation alone. Treat this as an engineering exercise with normal task tracking, not a separate compliance project.
4. Close structural gaps before starting the clock on any observation period. If access reviews, change management enforcement, or incident response processes don't yet exist as actual operating habits, build them first. A Type II observation period that begins before the underlying practice exists will simply document that gap for its full duration.
5. Choose Type I or Type II, and choose the observation period length, based on real organizational readiness — not on whatever the compliance automation vendor's default suggests. A shorter observation period is a reasonable choice for a first report if it gets a credible report in front of an enterprise buyer sooner; a longer period is a reasonable choice if the organization wants stronger assurance behind the first report and has the operational maturity to sustain it.
6. Select an auditor and confirm scope, criteria, and evidence expectations before the observation period starts, so the evidence being generated throughout the window is actually the evidence the auditor will ask for, rather than discovering a mismatch after the window closes.
7. Run the observation period as normal operations, not as a special compliance mode. Access reviews, change management enforcement, monitoring response, and incident handling should look the same during the observation period as they will look the month after the report is issued — because if they don't, the report is describing a temporary state rather than the organization's actual practice.
8. Run at least one incident response tabletop exercise before or early in the observation period, specifically to surface the gaps described in the incident response section above while there is still time to correct them.
9. Conduct a mid-period internal review, roughly at the midpoint of the observation window, checking whether evidence is actually accumulating the way it needs to — not waiting until the window closes to discover a gap that can no longer be retroactively fixed.
10. Treat the report as a milestone in an ongoing program, not a terminal deliverable. The work that produced a clean report is the same work that needs to continue afterward for the next renewal to be easier rather than equally hard.

Build Versus Retrofit: What the Two Paths Actually Cost

The clearest way to make the ownership argument concrete is to compare, directionally, what an engineering-native program costs against what a retrofit program costs — not as measured industry data, since no reliable, uniformly comparable published benchmark exists across company sizes and audit scopes, but as an illustrative, hypothetical framing built to make the underlying mechanism visible.

Illustrative chart — relative effort by month, engineering-native versus retrofit SOC 2 program (hypothetical, illustrative figures, not measured industry data)

The figures below are a hypothetical scenario constructed for this article to make a qualitative point about how effort is distributed over time under each approach. They are not based on a specific audited engagement, a vendor benchmark, or aggregated client data, and should not be cited as a measured average.

Engineering-native:  2  2  3  3  2  2   (flat, low, sustained)
Retrofit:            0  1  6  8  2  7   (spikes under deadline pressure, repeats every cycle)
                    -6mo -3mo -1mo obs  after  next-cycle

The shape of this comparison, not the specific numbers, is the actual argument: an engineering-native program distributes a moderate, steady level of effort across time because the controls are already normal operating practice, while a retrofit program concentrates effort into deadline-driven spikes — and, critically, tends to repeat that spike at every renewal, because the underlying practice reverts once the immediate audit pressure lifts. The total effort over a two-year horizon is not obviously lower for the retrofit path even though it looks cheaper in any single quarter that isn't an audit quarter — it is simply deferred and repeated, with the deferred version carrying the added cost of deadline pressure, higher risk of audit exceptions, and genuine security gaps sitting unaddressed in the gaps between audit cycles.

Where Compliance Automation Tools Fit, and Where They Don't

Compliance automation platforms — Vanta, Drata, and Secureframe are among the more commonly used in this category — have made real parts of SOC 2 preparation faster, and it is worth being specific about what they actually do rather than treating "compliance automation" as an undifferentiated category.

Vanta describes its platform as automating evidence collection and centralizing documentation, connecting to an organization's existing systems through integrations to continuously monitor control status rather than requiring manual screenshot collection before every audit.⁵ Drata's own documentation similarly focuses on continuous control monitoring and evidence collection rather than describing itself as a substitute for the underlying security or engineering work.⁴ Secureframe describes its offering across several product lines addressing compliance management, along with security and trust-related capabilities, positioning itself as helping organizations both achieve and maintain compliance rather than as a document-generation tool alone.³

What these platforms are consistently and legitimately good at: continuously checking configuration state against expected control settings (is MFA actually enforced, is a given cloud storage bucket actually private, are the code repositories that should require reviews actually configured to require them), centralizing evidence so it does not have to be manually reassembled before every audit, and giving an auditor a single place to review current control status rather than requesting documents individually. This genuinely reduces the manual burden of evidence collection and can meaningfully shorten the mechanical parts of audit preparation.

What these platforms cannot do, regardless of how sophisticated their integrations are: they cannot create the underlying practice. A platform can detect that MFA is not enforced on a given system and flag it as a failing check. It cannot decide, on the organization's behalf, to actually enforce it, review the operational impact of doing so, or handle the exceptions that come up when a legacy system doesn't support the same authentication method as everything else. A platform can flag that a pull request lacks a required reviewer. It cannot make engineers actually review code thoughtfully rather than approving on autopilot to clear a blocking check. Compliance automation tooling is, at its most useful, a fast and reliable way to verify that real engineering practice is happening — and, at its most misused, a way to make bad paperwork faster to produce, generating a dashboard full of green checkmarks that describe configuration state accurately while the organizational habits behind that configuration remain exactly as fragile as they were before the tool was purchased.

The practical implication for a program built on engineering ownership: adopt compliance automation tooling to reduce the manual burden of evidence collection and continuous monitoring, but treat it as an instrument that measures whether the engineering work is happening, not as a substitute for deciding to do the engineering work in the first place.

Type II Renewal: Why Year Two Is Either Easy or a Nightmare

The first SOC 2 report an organization produces is, almost by definition, the hardest one — it requires building controls and evidence collection habits from close to nothing. What that first report does not settle is whether the second one, and the one after that, get easier or stay exactly as hard.

The determining factor is whether the controls built for the first audit were built as sustained operating practice or as an audit-specific exercise that quietly lapsed once the report was issued. An access review process built to run quarterly, owned by a specific person with a calendar reminder and a defined output record, continues running in month fourteen exactly as it did in month two — which means the second observation period simply accumulates evidence from practice that never stopped. An access review that happened twice, specifically because the auditor was going to ask about it, and then stopped the week after the report was delivered, means the next audit cycle starts from close to the same position as the first one did: building the practice under deadline pressure, all over again.

This is where the ownership argument closes its loop. A program owned by engineering leadership, integrated into how the team actually operates, tends to survive the gap between audits because it was never really a special "audit mode" in the first place — it was just how the team worked, and the audit periodically checks in on that. A program owned by whoever was available during the crunch tends to be exactly that: a crunch, repeated annually, with the same person (or, given normal attrition, a different person starting from scratch) rebuilding evidence collection under the same time pressure every single cycle. The second pattern is not just more expensive in aggregate engineering hours. It is also the pattern most likely to produce a Type II report with exceptions, because evidence built retroactively under deadline pressure is exactly the evidence most likely to have gaps a careful auditor's sampling will find.

Startups, Scale-Ups, and Enterprises: Where the Burden Actually Falls

The control areas covered above apply across company sizes, but the practical difficulty of building them well shifts with organizational maturity in ways worth naming directly, since a readiness sequence appropriate for one stage can be badly miscalibrated for another.

Early-stage companies with small, tightly-knit engineering teams often have an underappreciated structural advantage: fewer systems, fewer people with access, and less accumulated technical debt to reconcile. A ten-person engineering team can plausibly know, without a formal review process, exactly who has access to what — informal knowledge that a much larger organization cannot rely on. The risk at this stage is not usually technical complexity; it is the temptation to skip building durable, recorded evidence of practice because the team is small enough that everyone already "just knows" how things work. Auditors sample records, not institutional memory, and a small team's genuine, well-run practices still need to be captured in a form that survives someone forgetting to mention it or leaving the company.

Growth-stage companies — roughly the population this article is written for — face the hardest version of this problem, because they are past the size where informal knowledge is a reasonable substitute for process, but often have not yet built the formal systems (identity governance tooling, structured change management, dedicated security ownership) that make the required practice easy to sustain. This is also the stage where the enterprise-sales trigger for SOC 2 most commonly arrives, which is precisely why the ownership pattern described earlier in this article matters most here: a growth-stage company has enough complexity for a paperwork-only approach to fail, and not yet enough dedicated compliance or security headcount for the work to happen by default without someone deliberately owning it.

Enterprises and larger, more complex organizations typically have dedicated security and compliance functions, but face a different version of the same underlying risk: control areas can become genuinely owned by a compliance function that has authority to write policy but not to directly enforce technical configuration across many teams and systems, recreating the ownership mismatch described earlier at a larger and more fragmented scale. At this stage, the critical design question shifts from "does anyone own this" to "does the compliance function have a real enforcement mechanism across every team and system in scope, or does it depend on voluntary cooperation from engineering teams it has no direct authority over."

The practical implication is that the readiness sequence described earlier in this article should be calibrated to organizational stage: an early-stage company's priority is converting genuine informal practice into recorded, auditable evidence; a growth-stage company's priority is building the formal ownership and enforcement mechanisms this article has focused on throughout; and an enterprise's priority is making sure a centralized compliance function has actual technical enforcement authority, not just policy-writing authority, across every team whose systems fall inside the audit boundary.

Questions Engineering and Product Leaders Should Ask Before Starting a SOC 2 Program

• Who, specifically, has been named as the accountable owner of this program — and does that person have direct authority over the systems the audit will evaluate, or only the ability to ask engineering for updates?
• Which Trust Services Criteria are we electing, and did that decision come from understanding what our actual enterprise prospects need assurance about, or from a template default?
• If an auditor pulled a random sample of ten user accounts with production access today, would every one of them match a documented, current business justification?
• If an auditor pulled a random sample of ten production changes from the last quarter, would every one have an associated peer review record — and if some legitimately wouldn't, is there a defined, logged exception process, or just an informal habit of skipping review under pressure?
• Has our incident response plan ever been tested against a realistic scenario, with the actual people named in it, or does it exist only as an approved document?
• Do we have a current inventory of every third-party vendor and AI tool with access to customer data, including the ones adopted informally by individual teams rather than through a formal procurement process?
• If the observation period started today, is there already evidence accumulating that the controls above are operating — or would the "start" of the observation period also be the start of actually building the practice?
• What happens to these controls the week after the report is delivered — do they continue exactly as before, or does someone quietly stop doing the work once the immediate pressure lifts?

Frequently Asked Questions

Do we need SOC 2 Type II, or is Type I enough for our first report? It depends on what your specific prospects and customers are asking for. Some enterprise buyers accept a Type I report as an interim step, particularly from earlier-stage vendors, while others treat Type II as the baseline expectation because it demonstrates sustained operation rather than a single-day snapshot.^{4 5} A reasonable approach for many first-time programs is to pursue a Type I report while simultaneously building the operational habits that will let a subsequent Type II observation period start from genuine readiness rather than a standing start.

How long does a SOC 2 audit actually take? Auditor and compliance-platform guidance commonly describes pre-audit preparation taking roughly one to three months, the Type II observation period itself commonly ranging from about three to twelve months depending on the organization's choice, and report preparation and delivery adding several more weeks after the observation period closes.^{4 5} These are commonly reported ranges from auditor and compliance-platform documentation rather than a single fixed timeline set by the AICPA, and the actual duration for a specific organization depends heavily on how much of the underlying control work already exists before the process starts.

Can a small startup with a lean engineering team realistically pursue SOC 2? Yes, and the core argument of this article applies with particular force to smaller teams: a lean organization that builds access control, change management, and monitoring as normal practice from early on has comparatively less retrofit work to do than a larger organization with more accumulated technical debt and more systems to bring into scope. Company size affects the volume of evidence an audit will sample, not whether the underlying discipline is achievable.

Does achieving SOC 2 mean our systems are actually secure? A SOC 2 report is evidence that specific, defined controls were in place and, for a Type II report, operating consistently over a defined period — evaluated by an independent CPA firm against the AICPA's Trust Services Criteria.¹ It is meaningful evidence, but it is scoped to the criteria elected and the systems included in the audit boundary; it is not a general guarantee against every possible security failure, and organizations that treat a clean report as proof that no further security work is needed misunderstand what the report actually attests to.

Who at our company should actually talk to the auditor? The people who operate the systems being tested, not exclusively a single compliance point of contact relaying information secondhand. Auditors ask specific, technical follow-up questions, and an intermediary without direct system knowledge either has to go back and forth repeatedly to get accurate answers or, worse, provides an approximate answer that turns out not to match what the system actually does — which is a fast way to turn a routine question into a documented exception.

How do we choose which Trust Services Criteria to include beyond the mandatory Security criterion? Start from what your actual enterprise prospects and existing customers are asking about in security questionnaires and contract negotiations, not from what a compliance platform's default template suggests. If uptime commitments are commercially material, include Availability. If you process financial transactions or other data where correctness has direct financial consequences for customers, consider Processing Integrity. If you handle data your customers or contracts specifically designate as confidential, or meaningful personal information, Confidentiality and Privacy become relevant. Each additional criterion should be a deliberate scoping decision with a clear business reason behind it, not a default.

Does a compliance automation platform replace the need for engineering involvement? No. These platforms are effective at continuously verifying configuration state and centralizing evidence, which meaningfully reduces manual audit-preparation work.^{3 4 5} They do not create the underlying engineering practice — enforcing access control, conducting genuine code review, running incident response exercises — which remains work only the engineering organization itself can actually do.

Where QAtronic Fits

Building the practices behind a SOC 2 report — access control that actually gets reviewed, change management that actually gets enforced, incident response that has actually been tested, monitoring that actually reaches a human — is fundamentally a quality and engineering-process problem before it is a compliance problem. QAtronic works with engineering teams on exactly that layer: designing and testing the access review workflows, change management gates, monitoring and alerting coverage, and incident response exercises that a SOC 2 program depends on, so that the controls an auditor eventually samples are the same controls the team was already relying on to run the system well.

The Question Worth Bringing Back to Your Team

A SOC 2 report answers one question definitively: did an independent auditor examine a specific set of controls, over a specific period, and find that they were suitably designed and, for a Type II report, operating as described. It does not answer a second, more important question, which is entirely within an organization's own control: will those same practices still be running, unprompted, the month after the report is delivered.

The distinction between an engineering-owned SOC 2 program and a paperwork-owned one is not really about who holds the pen when the policies get written. It is about whether the organization decided that access control, change management, monitoring, incident response, vendor oversight, and encryption are things a competent engineering team does because the system demands it — with the audit as a periodic, external confirmation of practice that already exists — or whether those same things are treated as a once-a-year performance staged specifically for an auditor's benefit. The first version produces a report and a system that are describing the same reality. The second produces a report, and a system that has to be reintroduced to that report every single year.

The question worth taking back to an engineering organization considering this work is not "how do we pass the audit." It is: if we stopped thinking about SOC 2 entirely for the next twelve months, which of these controls would still be running exactly as well as they are today — and which ones would quietly stop the week nobody was checking?