SOC 2 When an AI Wrote Your Code

A prospect just told you the contract is contingent on SOC 2. You have a product that works, three engineers, and a repository where most of the code was generated by an assistant. The compliance vendors all promise you can be audit-ready in weeks.

Here is the part they gloss over. SOC 2 does not audit your code. It audits whether you consistently do the things you say you do — and AI-assisted development, as practiced by most small teams, systematically produces a company that cannot demonstrate it does anything consistently.

That is the actual problem, and it is fixable. It just is not fixable by buying software.

What SOC 2 tests, and why AI code trips it

A SOC 2 report is an auditor's opinion on your controls against the Trust Services Criteria — Security always, plus Availability, Confidentiality, Processing Integrity, or Privacy if you include them. Type 1 says the controls exist on a date. Type 2 says they operated over a window, usually three to twelve months, and it is the one enterprise buyers actually want.

The word doing the work is "operated." The auditor asks for evidence. Not a policy document — evidence that the policy happened, repeatedly, for every instance in the period.

That is where AI-built products fail, because the fast-shipping workflow that got you here has no evidence trail. Nobody reviewed the change. Nobody approved the deploy. Nobody removed the contractor's access. It all worked; none of it was recorded.

Read that table as good news in one respect: only two rows are about code. The rest are about process, and process can be established in weeks if you actually change how you work.

The five gaps that cost the most to close

1. Change management is the big one. If code reaches production without a reviewed, approved, traceable change record, you cannot pass. This is the control most affected by AI-assisted workflows, because the whole appeal of prompting your way to a feature is skipping the ceremony. You do not need heavyweight process — a branch, a pull request, a second pair of eyes, and a CI check that must pass. But it needs to be every change, from the first day of the observation window, because the auditor samples across the period.

2. Access reviews. Enumerate every system holding production data or credentials: cloud, database, model providers, error tracking, email, payment processor, source control. For each, document who has access, at what level, and why. Then remove everyone who does not need it. Then do it again quarterly, with a written record. Shared accounts have to go — an auditor cannot attribute an action to a person if four people know the password.

3. Secrets in the repository. This is where AI-built codebases fail loudly. A key committed to git and later "removed" is still in the history and still live until rotated. Run a full history scan, rotate everything, and move to a managed secret store, then add a pre-commit and CI check so it cannot recur. The specifics are in secret scanning an AI codebase, and closing this gap also removes a standard due diligence finding.

4. Vulnerability management with a paper trail. You need scanning that runs on a schedule, a documented severity-to-timeline policy ("critical in 7 days, high in 30"), and evidence that you met it. Dependency scanning plus a tracked remediation queue is enough for most first audits. Start from a real baseline rather than a scanner dump — an AI code audit gives you the initial list, and the dependency side is covered in auditing AI-chosen dependencies.

5. Logging that survives a question. The auditor wants to know that authentication events, privileged actions, and configuration changes are recorded, retained, and looked at by someone. Console output that vanishes when the container restarts is not logging. A hosted log platform with 90-day-plus retention and one alert rule that goes to a human clears most of the bar.

What it actually costs and how long it takes

For an early-stage AI startup, first-year SOC 2 spend typically lands somewhere between $40,000 and $120,000 once everything is counted: the auditor's fee, a compliance automation platform, a penetration test, security tooling, and the engineering time to build controls that did not exist. The engineering time is the line people underestimate and the one that dominates when the codebase was AI-generated.

The timeline is driven by the observation window, not by your effort. Realistic sequence for a team starting from nothing:

• Weeks 1–4: readiness assessment, fix the blocking technical gaps, pick tooling, write policies you will actually follow.
• Weeks 5–8: operate the new process. Every change through review, access reviewed, scanning running, logs retained.
• Month 3 onward: the Type 2 observation window runs. Nothing to do but keep operating and collecting evidence.
• After the window: fieldwork and report, typically four to eight weeks.

Six to nine months from standing start to a Type 2 report is a normal outcome. Anyone promising materially faster is either selling you a Type 1 or planning a very thin scope.

Scope is your main lever

Two decisions control most of the cost. First, which criteria you include — Security alone is the common starting point, and each additional category adds controls, evidence, and audit hours. Add Confidentiality or Availability only if a customer contract names them.

Second, what is in the system boundary. Your production application and the infrastructure it runs on, yes. Your marketing site, internal experiments, and the prototype nobody uses, no. Draw the boundary tightly and document it, because everything inside it is subject to every control.

If your buyers are pushing for SOC 2 mainly to get through procurement, check whether a well-prepared security package closes the deal first. Many mid-market buyers accept a thorough response to their questionnaire plus a recent pen test — the approach in answering enterprise security questionnaires — and that buys you the months you need to do SOC 2 properly rather than in a panic.

Do the engineering before the paperwork

The failure pattern is predictable: buy the compliance platform first, watch it generate 100 policy documents and a dashboard full of red, then discover that half the red items require real engineering work in a codebase nobody fully understands.

Run it the other way. Get an honest technical baseline, fix the exposures that make you fail regardless of framework — secrets, access control, tenant isolation, logging — and then start the observation window with controls that already work. The platform is genuinely useful for evidence collection and vendor tracking. It is not useful as a plan.

There is a compounding benefit, too. Almost everything on the list also serves technical due diligence and any privacy obligations you carry. You build the controls once and answer three sets of questions with them.

Frequently asked questions

Can a product built with AI coding tools pass SOC 2? Yes. The audit examines controls and evidence, not who or what wrote the code. What fails is the absence of process around the code — unreviewed deploys, shared credentials, secrets in the repository, no logging. Fix those and the origin of the code never comes up.

How much does SOC 2 cost for a small startup? Budget roughly $40,000 to $120,000 for the first year across auditor fees, compliance tooling, a penetration test, and engineering time. Renewals are cheaper because the controls already exist. The variable that moves the number most is how much remediation work the codebase needs before the observation window can start.

Type 1 or Type 2 first? If a deal is blocked right now, a Type 1 can unblock it while your Type 2 window runs, and some buyers accept it as an interim step. If nothing is urgent, go straight to Type 2 — it is what enterprise procurement expects, and doing Type 1 first adds cost without shortening the observation period.

---

If SOC 2 is now a sales requirement and your product was built fast with AI tooling, the gap is engineering work, not paperwork. SprintX runs the readiness pass — audit, remediation, change process, logging — so your observation window starts on controls that actually operate. Tell us your audit timeline and we will scope the work.