SOC 2 without slowing down

The auditor is on the calendar. Someone says we should freeze the roadmap until it is over. That is how a small product team loses a quarter to a folder of PDFs.

SOC 2 does not ask you to stop shipping. It asks you to say what you do, do that, and keep the proof. The freeze is a choice. It is usually the wrong one.

I am not writing an auditor's manual. I am writing what I would tell a founder who still has to ship on Thursday. Pick a small scope. Pick the trust criteria you actually need. Put the controls in the tools you already use. Let the evidence fall out of normal work. Do Type I first. Then Type II. Name who owns what.

Pick the scope before you pick the binder

Scope is the system the report covers. On a small team that is usually the product customers log into, the repo it ships from, and the cloud account it runs in. It is not the marketing site, the founder's laptop, and every side tool someone tried in March.

Write the boundary in one paragraph. Name what is inside. Name what is outside. An auditor can test a boundary you drew. They cannot test one you never wrote down. A wide boundary feels careful. It is how you end up documenting tools nobody owns.

If a customer security form lists systems you do not run, say so. Do not quietly add them to the report so the form looks shorter. The report and the product have to match.

Trust criteria you actually need

SOC 2 has five trust services criteria. You do not have to claim all five on the first report.

• Security. Almost every report includes this one. Who can get in. How a change lands. How you notice when something looks wrong.
• Availability. Add this if you already promise uptime. Leave it off if you do not.
• Confidentiality. Add this if you hold customer data you agreed to keep private.
• Processing integrity. Add this if the product's job is to change data, and a wrong result is the failure customers feel.
• Privacy. Add this only if you handle personal information beyond what the service needs to run. It is a heavier claim. Do not add it because a template listed it.

Security, plus the one or two criteria that match the promise you already make. That is the report. The rest can wait for a later period, when you have actually built them.

Put the controls in the tools you already use

A control is something you already do, written so a stranger can see it. It is not a new platform you buy in month two of the audit.

Access reviews. Once a month, export who is in the GitHub org, the cloud account, and the production database. A named person reads the list and removes anyone who should not be there. The export and the removal are the evidence. A spreadsheet someone rebuilds the week the auditor arrives is not.

Change review in pull requests. Main requires a reviewer who did not write the change. The pull request says what changed and how you know it still works. The reviewer writes a sentence. A thumbs-up with no words is a weak record. You were already opening pull requests. The thread is the evidence. You do not pause feature work to create it.

CI checks. The tests, the dependency check, and the build already run on the commit you ship. Keep that history. A green run on the commit that went out is the evidence. Turning CI off so you can "move faster during the audit" throws away the proof.

Logging. The app already logs sign-in failures, admin actions, and deploys. Point the auditor at that log. Do not write a new logging essay in a wiki and hope it matches production. If a control says you alert on failed admin logins, the alert has to exist. If it does not, build the alert or change the sentence.

Offboarding. The day someone leaves, remove GitHub, the cloud console, and the SaaS tools that can see customer data. The ticket, with the date and the removals, is the evidence. A quarterly note that says "we think we got everyone" is how a departed contractor still has a token in month four.

None of those stop a release. They are the release, plus a record you can open later.

Evidence is a side effect, not a scramble

The painful version is a shared drive that fills up in the last two weeks. Screenshots from memory. Policies nobody followed. A contractor writing what you wish you had done.

The workable version is boring. The pull request is the change record. The CI run is the test record. The access export is the access record. The offboarding ticket is the offboarding record. You keep them because the work happened, not because someone asked on a Friday.

If a control has no artifact a stranger can open, it is not a control yet. Fix the tool, or delete the sentence. Do not invent a quarterly project to paper over the gap.

When those controls need to live in the product itself, not only in the process around it, that build is compliance engineering. Encryption, access, logging, and retention in the system, so the next review has code behind the sentence. This post is the shape. That page is the work if you want a named engineer on it.

Type I first. Type II after you have a window.

Type I says the controls are designed and in place on a date. It is a snapshot. It is the right first report for a team that just made the process real.

Type II says those controls operated over a period. Often three months the first time, longer after that. You cannot start Type II on Monday and pass it on Friday. The window is the work. Keep shipping through it. The evidence is the shipping.

A customer form that asks for Type II does not mean you skip Type I. Tell them the date Type I lands, and the date the Type II window starts. A clear Type I beats a Type II you cannot defend. Buyers who have been through this will see the difference.

If the question on the form is specifically what Copilot, Cursor, or Claude Code already merged, that is a narrower job: a SOC 2 AI code audit. It is a snapshot of assistant output, mapped to change management. It is not a substitute for the scope, the criteria, and the weekly evidence in this post.

Who owns what

On a small team the list is short. One name per row. If a cell says "the team," it is blank.

Question	What good looks like	Not good enough
What is in the report?	One paragraph. Product, repo, cloud account. What is out is named.	"Everything we use."
Which criteria?	Security, plus the promise you already make to customers.	All five, because the template had five rows.
Who reviews a change?	A named reviewer on the pull request, who writes a sentence.	The author approving their own merge.
Who can reach production?	A short list, exported and read once a month.	A shared password in Slack.
What happens the day someone leaves?	Access removed the same day. The ticket is saved.	A reminder for next quarter.
Who talks to the auditor?	One named owner who can say what is in and what is out.	A group chat.

Engineering owns the controls in the tools. One person owns the scope and the answers. On a small team that person is often the engineering lead, or the founder who still ships. They do not have to stop coding. They do have to be the name on the boundary.

The auditor owns the test. They do not own your process, and they should not be designing it for you in the last month. If you want help putting the controls into the product before that conversation, start with compliance engineering.

Same idea, other angles

This is the general-product version: a small team, a SOC 2 report, and a release train that keeps moving. The same week, the other four sites take the security question from their own seat.

• Mobile app launch security checklist, on Maxiom Apps.
• Vetting outside developers: security and access, on Maxiom Dev.
• HIPAA cloud hosting: what you actually need, on Maxiom Labs.
• Audit-ready inspection trails, on Hyperlogs.

FAQ: SOC 2 without slowing down

Do we have to stop shipping to get through SOC 2?

No. The report describes how you ship, and you keep the proof. A freeze makes the proof worse, because the controls stop matching the work. Keep the pull requests, the CI runs, and the access reviews going.

Which trust criteria should a small team pick?

Security, plus availability, confidentiality, processing integrity, or privacy only when you already promise that thing. Do not claim all five because a checklist had five boxes.

What is the difference between Type I and Type II?

Type I is a snapshot: the controls exist on a date. Type II is a window: those controls operated over months. Do Type I first. Start the Type II window after the process is real, and keep shipping through it.

Can GitHub, CI, and our logs count as evidence?

Yes, when they show the control you wrote down. A required reviewer, a saved green run, a monthly access export, an offboarding ticket, and a log you can open. A policy page that does not match those tools does not count.

Who should own the program on a small team?

One person owns the scope and the answers. Engineering owns the controls in the tools. The auditor owns the test. "The team" is not a name.

How is this different from a SOC 2 AI code audit?

This post is the program around the product you ship every week: scope, criteria, and evidence from normal work. A SOC 2 AI code audit is a point-in-time look at what assistants already merged. You may need both. They are not the same job.

What if the product can see health data?

Say so on day one. SOC 2 does not replace HIPAA. No production export to a laptop, and no paste of patient data into a tool that is not approved for it. Clinical systems and hosting for that data belong with Maxiom Labs.

When should we bring someone in?

When the controls are still sentences, and the product does not yet log, restrict, or record what the sentences claim. That is compliance engineering: a named engineer, a written scope, and evidence in the system. If you can already point at the pull request, the CI run, the access list, and the offboarding ticket, you can run the first period yourselves.

If you want that build, see compliance engineering or talk to an engineer. Thirty minutes is enough to tell whether we are the fit.

I write from the seat of a working engineering company, not a tool vendor. More at antoniochagoury.com.