SOC 2 for an AI company, minimally

What it is, stated plainly

SOC 2 is a report written by an independent accounting firm about a service organisation's controls. You define a system boundary, you write a description of that system, you state the controls you operate, and the auditor tests whether those controls were suitably designed and, in one variant, whether they operated over a period of time. The output is a report your buyers read. There is no certificate, no registry, no logo that means anything, and no list of required controls delivered to you at the start.

That last point is the one that surprises engineers, and it cuts both ways. There is no checklist to grind through, which means you cannot be told exactly what to build. But it also means you write the controls, and a control you wrote to describe what your team already does is far easier to evidence than one copied from a template describing a company three times your size.

The criteria are organised into categories — security, availability, processing integrity, confidentiality and privacy. Security is common to every engagement. The others are optional, and each one you add is more description to write and more evidence to produce, every year, forever. Most companies asked for SOC 2 by an enterprise buyer are being asked for the security category and nothing else, and adding more because it sounds thorough is the most common self-inflicted cost in this whole exercise.

Type I and Type II, and which one your buyer means

Type I is an opinion on whether your controls are suitably designed as at a point in time. Type II is an opinion on whether they operated effectively over a period. Type II is what enterprise buyers mean when they say SOC 2, and a Type I will occasionally satisfy a buyer who is trying to help you, usually with a commitment that a Type II follows.

The mechanical consequence is that a Type II requires an observation window during which your controls have to actually be running and generating evidence. Windows are negotiated with your auditor and vary; the important planning fact is that the window is elapsed time you cannot compress by working harder. If a deal is waiting, the sequence that usually works is to get controls running, take a Type I to unblock the deal if the buyer will accept it, and let the window run for the Type II that follows.

The other planning fact is that the report has a period, and the period ages. Buyers routinely want a report covering a period that ended recently, which means this is an annual cycle rather than a project. Design for that from the start: a control that requires heroics to evidence once will be quietly abandoned by month eight.

Scope is the whole game

Nearly all of the cost and all of the misery come from scope, and scope is the part most within your control. Four levers matter.

The system. Scope the production service your buyers use, not your company. One product, one production environment. Your marketing site, your internal analytics, and the side project someone deployed last year do not need to be inside the boundary, and each one that is drags its access reviews, its change management and its evidence into scope with it.

The categories. Security only, unless a buyer has specifically asked for another in writing. Confidentiality is the one most often added on instinct; ask the buyer whether they need it before you volunteer it.

The infrastructure. Fewer accounts, fewer clouds, fewer bespoke servers. If you have one production cloud account with everything defined as code, the evidence practically produces itself. If you have three accounts, a legacy box somebody maintains by hand, and two former contractors with credentials, that is not a compliance problem, it is a cleanup you were going to have to do anyway.

The people. The number of humans with production access is a direct multiplier on evidence volume, because access reviews and onboarding and offboarding records scale with headcount in scope. Reduce standing access before you start, not because of the audit but because it is the single highest-value security change most small teams can make.

Where the engineering time actually goes

Most of a SOC 2 is administrative — policies, a risk assessment, vendor records, background checks, acknowledgements. That work is real and it is not engineering. The parts that do land on your engineers are a shorter list than people fear, and they are the parts worth doing anyway.

A note on the middle rows. Whatever timeframe you write into your own vulnerability policy is the timeframe you will be tested against. Writing an aggressive one to look serious is how companies generate their own exceptions. Write the interval you will hold on a bad month.

The second questionnaire, which is the AI-specific part

Here is the thing nobody warns you about. You will do all of this, receive the report, send it proudly to your buyer's security team, and then get a second document with questions the report does not address at all. For an AI company that second document is usually the harder one.

The questions cluster in five places, and none of them is answered by an opinion on your control environment.

Your model provider is a subprocessor. Buyers want it named, along with what data reaches it, what retention applies, whether their content can be used to improve anyone's models, and whether that is a default or a setting you enabled. Have the answer written down with the date you last verified it, because “we believe it is off” is a bad sentence to say to a security reviewer.

Prompt and completion logging. If you log requests for debugging, you are storing customer content, possibly in a third-party tool, possibly for longer than your stated retention. This is the most common uncomfortable discovery in an AI company's first audit. It is fixable, but fix it before the observation window rather than during it.

Tenant separation in retrieval. If you run a vector or search index over customer content, expect to be asked how one customer's data cannot reach another's context. “We filter by tenant in the application” is a weaker answer than a separation the query layer enforces, and reviewers have learned to ask which one it is.

Human review of outputs. Whether anyone at your company reads model outputs containing customer content, under what circumstances, and whether the customer was told.

Model behaviour. Accuracy, hallucination, evaluation, bias, and what happens when the model is wrong. A SOC 2 report says nothing about any of this — it is an opinion about controls, not about output quality — and buyers increasingly know that, which is why the second questionnaire exists.

The practical move is to prepare a short, plain technical document covering these five things and send it alongside the report. It costs a day, it shortens the review by weeks, and it is the artefact that most distinguishes companies that close enterprise deals from ones that get stuck in review.

What it costs, in the only terms that are honest

We will not quote figures, because audit fees vary by firm, scope, region and year, and a stale number in an article is worse than none. What is stable is the shape: three lines, and the one people underestimate is not the one on the invoice.

The audit firm. Get three quotes. Ask each for the same scope in writing and compare what is included — a readiness assessment, the observation window they will accept, whether a bridge letter is included, and what a second year costs. The spread between firms on identical scope is wide enough to be worth an afternoon.

The compliance platform. Optional, and usually worth it for a small team. It collects evidence continuously, keeps policies in one place, and saves real time. Two cautions: do not let it define your architecture, and check what its monitoring agent installs on your team's laptops before you find out from your engineers.

Internal time. Almost always the largest line, and it is rarely modelled. It lands on one person who becomes the owner and on engineers in bursts. Name the owner explicitly. A SOC 2 with no single accountable person takes twice as long and produces a worse report.

The mistakes we see

• Scoping the company instead of the product, which multiplies evidence for no buyer benefit
• Adding criteria categories nobody asked for, permanently, to look thorough
• Writing aspirational policies and then being tested against them
• Starting the observation window before controls are actually running, guaranteeing exceptions
• Logging prompts and completions into a third-party tool with a retention nobody checked
• Letting a platform's template dictate architecture rather than describing what you do
• No named owner, so evidence collection happens in a panic before the window closes
• Treating the report as the finish line when the AI questionnaire is what actually gates the deal

Where you do not need us

Most of a SOC 2 does not need an engineering firm and we would rather say so. The policies, the risk assessment, the vendor records, the training and acknowledgements, the evidence collection — a capable operations-minded person plus a compliance platform plus a good auditor covers all of it. Many companies get through a first Type II with no outside engineering help at all, and that is a perfectly good outcome.

Choosing the auditor is also yours. Ask peers at companies one stage ahead of you, get three quotes, and pick on responsiveness and on whether they have audited companies whose architecture resembles yours.

Where an outside team is worth paying for is the narrow set of things that touch the product: separating tenants properly in a retrieval layer, rebuilding logging so it stops capturing customer content, making offboarding provable across systems that were never wired together, or writing the technical answers to the AI questionnaire in a way a security reviewer accepts. That is a handful of specific pieces of work, not a programme — and if someone proposes a programme, ask which of those pieces they mean.

A sequence that works

• Ask the buyer exactly what they need — type, categories, and how recent the period must be
• Draw the smallest honest boundary: one product, one production environment
• Clean up access first: single sign-on, multi-factor, groups, no shared accounts, no orphans
• Fix logging before the window, so customer content is not in scope by accident
• Write controls that describe what you actually do, then close the gaps that remain
• Name one accountable owner with time protected for it
• Get three auditor quotes on identical written scope
• Run a restore test and a tabletop, and write both up
• Start the observation window only once controls are running
• Prepare the AI questionnaire answers before the report lands, not after

Bottom line

SOC 2 is an attestation against a description you wrote, so nearly everything that matters is decided in scope and in writing controls you can actually hold for a year. Take security only, one product, one environment, the fewest people with standing access, and policies that describe your real behaviour rather than an aspirational version of it. Most of the work is administrative and does not need an engineering firm. The parts that do are identity, logging, tenant separation and provable offboarding, and those are worth doing whether or not anyone audits you. Then remember that the report is not what closes the deal on its own: for an AI company, the questions that decide the review are about your model provider, your prompt logs, your tenant boundaries and what happens when the model is wrong. Write those answers down early, keep them current, and send them with the report.

Frequently asked questions