A client sends you a security questionnaire, and somewhere in it sits a line asking for your most recent SOC 2 Type 2 report. You do not have one. You call an auditor, and the first thing they ask is when you want the observation window to start.
That question is the engagement. A Type 2 examination covers a period, and the auditor tests whether your controls operated across the whole of it. You cannot produce evidence in month eleven that you failed to collect in month two. Teams who treat SOC 2 as a date in the calendar find that out at the readiness assessment, which is an expensive place to find it out.
The report is an opinion, and there is no certificate
A SOC 2 examination is an attestation engagement performed under AICPA standards by a licensed CPA firm or a non-US equivalent. The standards call that firm the service auditor, and they call the engagement an examination rather than an audit. You receive a report: the service auditor's opinion, your own written description of your system, and a table of the controls tested with the results of the tests.
No badge arrives, and nobody certifies you. The phrase "SOC 2 certified" turns up on a lot of vendor sites and describes nothing that exists. You can say that you hold a SOC 2 Type 2 report covering a stated period, with an unmodified opinion if that is what you got. Unmodified is the attestation word for a clean opinion, where an auditor of financial statements would say unqualified.
For an engineer the consequence is direct. The deliverable is a report about your own description of your own system, so you control both the quality of that description and the difficulty of the examination.
The AICPA gives you criteria and lets you write the controls
The Trust Services Criteria describe what has to be true. They do not name a password length, a key rotation interval, or a scanning tool. The change management criteria ask you to authorize, test, approve and implement changes to infrastructure and software through a documented process. You decide what that process looks like at your company, write it down, and then live by what you wrote.
That cuts both ways. You get to describe controls you already run, which costs far less than adopting a control set someone else designed. You are also held to your own description for the whole window, so a description written to impress costs you every month it is in force. Write down what you do. If what you do is thin, fix the practice first and describe it second.
One shared criteria set, and four categories you opt into
Five categories exist: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Beneath all five sits one shared set called the common criteria, and every examination applies it. Security needs nothing beyond that shared set, which is why security sits in almost every SOC 2 and the AICPA describes an examination that leaves it out as uncommon. Each of the other four layers its own control activity criteria on top of the common ones.
Each category you add brings more controls, more evidence, and more auditor hours. Availability commits you to your own uptime targets and to proving you monitored them. Processing Integrity suits a payments or data-transformation product, and it adds real work to a product that stores customer data without transforming it. Add a category when a customer contract asks for one.
Your branch protection is already a control
The change management criteria describe most of what your repository settings enforce today. Review required from somebody other than the author, status checks required, no direct pushes to main. Write that down as the control, and your evidence is the pull request history that GitHub keeps for you.
Administrator bypass is what breaks it. If your organization lets admins merge without review, and two people used that power during the window, your report carries an exception against the control you described. Turn bypass off before the window opens. If you need a break-glass path, put the break-glass procedure into the control description and log every use of it, because the auditor will ask for that log and a spoken explanation will not close the point.
Make the access review something you can run in one command
You will be tempted to handle the quarterly access review the week before the auditor arrives: screenshots of a cloud portal, and a spreadsheet somebody assembled from memory of who left in March. The evidence comes out thin, and its timestamps show that one person made all of it in an afternoon.
Write the review as a script instead. Every human with production access, joined against the current employee roster, with a date and a named reviewer on the output. When producing it costs one command, you run it four times a year. When it costs a day, you run it once, and the auditor reads that off the file dates.
Retention is the control
A twelve-month window needs evidence that survives twelve months. Logs that roll off after thirty days say nothing about month one. The same goes for CI history, alert records, and the ticket system where your change approvals live.
Set retention to cover the window plus the weeks it takes to write the report, and set it before the window opens. Retention does not work backwards.
Your subprocessors are in scope, including the model provider
Vendors that hold your customer data fall inside the criteria, so each one needs a file: their current SOC 2 or an equivalent, the date you reviewed it, and what you concluded. Cloud hosting, error tracking, email delivery, analytics.
If your product sends customer text to a model API, that provider belongs on the list with the others, and the questions worth answering in the file are where the prompts go and how long the provider keeps them.
A Type 1 is a real answer to a different question
A Type 1 covers the same subject matter as a Type 2: whether your description of the system is presented fairly, and whether the controls in that description were suitably designed. It omits any opinion on whether those controls operated, and it speaks as of a single date, so you can pass one with controls switched on that morning. For a company that has never been examined it is a reasonable first step, and some customers accept it while they wait for the Type 2.
A Type 2 adds the opinion on operating effectiveness throughout a period, along with the detail of what the service auditor tested and what they found. Enterprise buyers ask for this one. The AICPA sets no minimum length for the window. It does require the service auditor to gather sufficient appropriate evidence, which rules out a window too short for your quarterly controls to have run inside it. Three to twelve months is the practical range, and a twelve-month window is what puts the report on an annual renewal cycle.
Read that against your sales pipeline. A customer who needs a Type 2 in nine months needs your window open now.
Cheap to build in, expensive to reconstruct
Worth wiring in before the window opens:
- Branch protection with administrator bypass disabled, so your change evidence is the pull request history
- Single sign-on in front of every production tool, so offboarding a person is one revocation rather than nine
- Log, CI, and ticket retention set past the end of the window
- Infrastructure changes through reviewed code, so the change evidence is a commit rather than a memory of a portal click
Painful to produce after the fact:
- Who held production access last March
- Whether an alert fired and who acknowledged it, once retention has rolled past it
- That a control operated in month two, when the tool that would have recorded it arrived in month ten
The version to send the people who sign the contract
The engineering work is one half of a SOC 2. The other half is a conversation with a client, a founder, or a board who want to know what the report proves and what it leaves open. I recorded a short explainer for that conversation, aimed at people who do not work in engineering:
What Is SOC 2 — and Why Might Your Company Need It?. Send it to the people who ask why the audit is on the roadmap.
What the report is worth
A SOC 2 report records that you described a set of controls, and that an independent examiner tested those controls across a stated period and wrote down what they found. Its value to a customer sits in how specific your description was and in the fact that somebody outside your company checked it. It is not a statement that your product is secure, and a buyer who reads it as one has misread it.
So the engineering half is worth starting long before the sales conversation that triggers it. The controls that survive an examination are the ones already running on the day the window opens.