Case Study: Zero to SOC 2 Type II for a Venture-Backed Startup

Humera is a venture-backed security company in the United States. In 2023 it had roughly fifteen people, a production platform serving millions of requests a day, and no compliance programme of any kind. Enterprise procurement teams kept asking for a SOC 2 report, and the honest answer was that one did not exist.

This is the case study we get asked about most, so it is worth being precise about what it is. This programme was built in house. Jacob Masse ran it as Head of Operations at Humera, not as an outside consultant delivering to a client. That distinction matters when you are reading it, because it means the account below is written from inside the company that had to live with the controls afterwards, rather than from the vendor seat.

Why Type II, and why that made it harder

The board wanted Type I. Type I is a point-in-time report: an auditor confirms your controls are suitably designed on one particular date. It is faster, it is cheaper, and for a company that needed something to show buyers, it was the obvious call.

The problem is that enterprise procurement had already learned to read the cover page. A Type I tells a buyer that controls existed on a Tuesday. A Type II tells them the controls actually operated across a window, usually three to twelve months, with the auditor sampling evidence from throughout that period. The buyers holding up the deals were asking for Type II specifically.

Going straight to Type II meant there was no way to compress the timeline. You cannot manufacture an observation period. If access reviews are supposed to happen quarterly, the auditor wants to see quarters of them. If every production change needs an approval trail, the trail has to exist for every change made during the window, including the ones made at 2am during an incident. The controls had to be real before the clock started, because everything after that was being recorded.

The starting position

The engineering team was strong and the instincts were mostly right. What was missing was the evidence that the instincts were being followed consistently. That gap is the normal state of a startup at this size and it is worth describing honestly, because most companies reading this will recognise themselves in it.

• Access was granted informally. People got what they needed to do their jobs, which is correct, but there was no record of who approved it, no periodic review, and no reliable offboarding trail.
• Change management existed in practice but not on paper. Engineers reviewed each other's work because they wanted to, not because a control required it, and nothing prevented a direct push when someone was in a hurry.
• Vendors had never been assessed. The company depended on a long list of third parties, and nobody had written down which ones touched customer data.
• Policies did not exist. Not out of date, not thin. Absent.
• Incident response was tribal knowledge. The team knew what to do. None of it was documented, and none of it had been tested.

Scoping: 76 controls, and the ones that were argued about

The scope landed at 76 controls across the Security, Availability and Confidentiality criteria. Getting there involved a fair amount of argument, and the arguments are the useful part.

Availability was the contested one. Adding it means the auditor tests your uptime commitments, your monitoring, your capacity planning and your business continuity arrangements. It is more work and more risk. It went in anyway, because the buyers holding up deals were evaluating an infrastructure product, and a security-only report would have prompted the follow-up question of why availability had been left out. A narrow scope that invites a question is worse than a wider scope that answers it.

Processing Integrity was left out, and that was the right call. It applies to systems that process transactions on a customer's behalf, and stretching it to fit would have added evidence obligations with no buyer asking for them. Scope is not a score. Every criterion you add is a set of controls somebody has to operate every week for the life of the report.

The change management flow, which is where Type II is usually lost

Change management is the control family that fails Type II most often, and the reason is structural. A Type I asks whether you have a change process. A Type II asks for every change made over several months and samples them. One undocumented production push in month two becomes an exception in the report.

The answer was a five-layer pull request approval flow, built so that the safe path was also the fast path. Nothing reached production without passing through it, and the trail it produced was the evidence itself rather than something reconstructed later:

• Branch protection preventing direct pushes to production branches, with no exceptions and no admin bypass.
• Mandatory peer review, with reviewers who could not approve their own work.
• Automated checks including tests, dependency scanning and static analysis, wired as required status checks rather than advisory ones.
• A separate approval gate for anything touching infrastructure, authentication or data handling.
• Deployment records tying each release back to the approved pull request, so the auditor could walk from a production change to its authorisation without asking anybody.

The part worth copying is not the five layers. It is that the trail was a by-product of how people already worked. Any control that requires somebody to remember to log something will produce an exception eventually, because the week it matters is the week everyone is busy.

The asset audit

Sixty-plus assets were inventoried: production systems, cloud accounts, code repositories, SaaS applications and every third party in scope. Each was mapped to the controls that applied to it and the evidence an auditor would ask for.

This is dull work and it is the single highest-leverage thing in the programme. Almost every unpleasant surprise in an audit traces back to something nobody remembered was in scope: a forgotten staging environment with production data, a contractor's account that outlived the contract, an integration set up for a trial two years earlier. The inventory turns the audit from a memory exercise into a lookup.

Policies, evidence, and tooling

Policies were written from the environment outward rather than adapted from a template. A template gives you a document that says quarterly access reviews will happen. It does not tell you who runs them, where the output lives, or what the auditor will accept as proof. Writing from the environment means the policy describes what the company genuinely does, which is the only version that survives sampling.

A compliance automation platform was deployed to collect evidence continuously. It was useful and it was also the smallest part of the work. The platform showed which controls were failing. It did not configure anything, write anything, or decide anything. Judging by the marketing in this category, that is worth stating plainly.

The outcome

Humera passed its SOC 2 Type II with zero exceptions across all 76 controls. The platform held 99.9% uptime through the observation window while serving millions of daily requests, which mattered because Availability was in scope and the auditor tested it.

The commercial effect was the point. The security questionnaire that had been stalling enterprise deals became a report attached to an email. Procurement conversations that had run for weeks closed in days, because the report answered in advance most of what the questionnaire was asking.

Zero exceptions is worth being unromantic about. It does not mean nothing was ever wrong. It means nothing was wrong in a way the auditor could evidence during the window, which is a product of designing controls people can actually follow under pressure. A control that depends on good behaviour on a bad day is a control that will produce an exception.

What we would do differently

Two things.

The policy set was written before the asset inventory was finished, which meant several policies had to be revised once the true scope was known. The inventory should come first. It is the cheapest work in the programme and it constrains everything downstream.

Vendor risk was left too late. It was treated as paperwork and it turned out to be the area with the most genuine unknowns, including third parties nobody could confidently say whether they touched customer data. Starting it in the first fortnight would have removed several weeks of anxiety later.

What this means if you are looking at your first Type II

The uncomfortable finding is that most of the work has nothing to do with security tooling. It is inventory, ownership, writing things down, and building processes people will still follow during an incident. The technical controls were the straightforward part.

If you are weighing Type I against Type II, ask your blocked buyers which one they actually need rather than deciding internally. If you are looking at compliance platforms, they are worth having and they will not do this work. And if you are scoping criteria, add the ones your buyers ask about and leave out the ones they do not, because every criterion is an ongoing operational commitment rather than a line on a certificate.

We run this programme for other companies now, on the SOC 2 in 75 Days track and through fractional CISO engagements, and we run the internal audit for companies whose readiness somebody else did. If you would rather see the numbers first, our free SOC 2 readiness assessment will tell you roughly where you stand, and the rest of our case studies cover what audits cost and why the quotes differ so much.

Book a call and we will tell you honestly how far you are from audit-ready, including if the answer is that you are not ready to start.