We do code reviews. I know we do code reviews. The question that started this whole thing was different: could I hand someone outside the company something that shows we do code reviews, every time, for a stated period, without going and asking anyone?
That gap between doing a thing and being able to demonstrate a thing is the entire SOC 2 experience so far. We're at the beginning. TechFabric is planning a SOC 2 Type II examination in 2027, the observation window isn't fixed yet, and we have not been audited. I'm writing this now rather than after the report lands, because the beginning is the part nobody publishes and the part I would have wanted to read.
What SOC 2 actually is, briefly
SOC 2 is an examination by an independent auditor of how a service organisation handles customer data, measured against the Trust Services Criteria. Security is the one everybody includes; it's the common baseline covering things like access control, risk management, incident response and change management. The other four, Availability, Confidentiality, Processing Integrity and Privacy, are chosen based on what you promise customers.
We're including Security, Availability and Confidentiality. We didn't limit it to Security only, and that was deliberate. If we're asking customers to run things with us and trust us with their data, availability and confidentiality are the two they ask about next anyway.
There's also the Type I versus Type II distinction, which matters more than it sounds. A Type I says the controls are designed properly as of a point in time. A Type II says they actually operated, consistently, across a window. We're going for Type II because the point-in-time version answers a question nobody is really asking. Anyone can look tidy on a Tuesday.
Why now
Not a questionnaire that stalled, and I want to be straight about that, because the standard version of this story is always a deal that nearly died. Ours is about where we're trying to go.
We're expanding on two fronts at the same time: our own product initiatives, and more work with larger enterprise customers. Both of those raise the same question from the other side of the table, and it isn't really "are you secure". It's "who has checked". At a certain size of customer, your own account of your controls stops being the thing that gets evaluated. Someone independent has to have tested them.
So this isn't a checkbox for us, although I understand why people read it that way. It's a readiness thing. If we want to operate at that scale, the controls have to exist and someone outside has to have looked at them.
From we do this to we can prove we do this
Here's the shift that surprised me most, and it's the one I'd warn anyone else about.
A lot of the practices SOC 2 asks about already exist in a company like ours. We review code. We use MFA. We remove access when someone leaves. We think about vendors. None of that was news. What the early readiness work keeps surfacing is that having a process, documenting it formally, executing it consistently, and being able to produce evidence of it are four different things, and most teams have the first one and assume they have the rest.
The translation looks roughly like this:
| Good practice | Control | Evidence |
|---|---|---|
| We review code | Reviews are required before merge | Pull request history |
| We use MFA | MFA enforced on in-scope systems | System configuration and logs |
| We remove access | Offboarding checklist with access revocation | Access records, tickets |
| We check our vendors | Vendor review process with criteria | Completed vendor reviews |
| We handle incidents | Defined response and escalation path | Incident records |
The left column is a conversation. The right column is a file someone can read a year from now without you in the room. Most of the work is the arrow between them.
And the honest version of the question isn't "do we do this". It's "on the third Thursday of April, when the person who normally does it was on leave, did it still happen, and where would I see that". That's what a Type II window actually tests.
I'm not going to publish our specific gaps. They're about our internal security and operational environment and they aren't anybody else's business. What I can say is that nothing we found changed my view of how the team works. It changed my view of how much of what the team does lives in people's heads.
Who is actually doing this
I assumed, before we started, that SOC 2 was an IT project with some paperwork attached. It isn't. It's an operations project that happens to be about security.
At TechFabric the work is owned primarily by Operations and HR, with responsibilities distributed across our different locations. HR surprises people until you think about it for ten seconds. Joiners and leavers, security training, who signed what, when someone's access should have been cut off, all of that sits in HR records, and they're exactly the records an auditor samples. Engineering owns the change and deployment side. Leadership owns risk and the decision about what's in scope. IT owns identity and devices.
The distributed-locations part is its own thing. When your team sits in more than one place, "we have a process" can quietly mean three slightly different processes, and the differences only become visible when someone asks for one consistent record across all of them. That's not a criticism of anyone. It's just what happens when a company grows faster than its documentation.
We set a design goal at the start, which was to build the controls into normal operational processes instead of standing up a separate compliance programme that runs alongside the real work. A control that only exists during audit season isn't a control, it's a performance. And a Type II window will find that out.
What we scoped first
We've been working with consultants from Vanta and Rippling to understand the requirements and structure the initial scope. We haven't finalised and I'm not going to pre-announce tooling or an auditor before those decisions are actually made.
The first three areas we're working through:
Access management. Who has access to what, whether it's still appropriate, and how that gets reviewed on a schedule rather than when someone remembers. This is first for a reason. Nearly every other criterion leans on it.
Equipment management. Devices, who holds them, how they're configured, what happens when one leaves the building or the company. Unglamorous, and the single easiest place to have a quiet gap between the asset list and reality.
Security policies and controls. The written layer. What we actually commit to, in words, approved, dated, and findable by someone who doesn't know who to ask.
Phased, on purpose. The failure mode I've watched other companies hit is trying to remediate every criterion in parallel, which produces a lot of half-finished policies and no evidence of anything. We'd rather have three areas that genuinely operate than eleven that look addressed in a spreadsheet.
We're somewhere between assess and remediate on that line. Nowhere near audit.
What I'd tell someone starting this
Four things, from about as early in the process as you can be.
Start with evidence, not policy. It's tempting to write the policies first because writing is tractable and you can finish it. But the question that decides whether a control is real is "where does the record of this land, automatically, without anyone deciding to save it". Work backwards from that and the policy writes itself. Work forwards from the policy and you'll discover in month nine that nothing was being captured.
Give every control a named owner, a person and not a team. "Operations" does not do access reviews. A specific person does, on a specific cadence, or it doesn't happen.
Assume it's company-wide from day one and bring HR in at the start. Half of the evidence an auditor wants is employment lifecycle records. If HR finds out about SOC 2 in month four, you will be reconstructing offboarding history from memory, which is exactly the thing the standard exists to prevent.
And decide Type I versus Type II before you build anything, because it changes what you build. Type II means the controls have to survive holidays, handovers and a quarter where everyone is busy. Design for that, not for the demo.
We'll write again when we have real findings from the gap assessment and a fixed observation window, including the parts that didn't go smoothly. If you're thinking about the governance side of this for data and AI systems specifically, we wrote about that separately in an AI governance framework is four answers you can query.