SOC 2 Type II in Five Months That Unblocked a $4M Enterprise Pipeline

The Company

Fernbrook Software is a 90-person B2B SaaS company whose platform helps mid-market logistics teams manage freight, warehousing and last-mile delivery. Its customers include shippers and third-party logistics providers, and its product sits squarely in the operational spine of those businesses: order flows, carrier rates, shipment status and the customer data attached to all of it. The company had found genuine product-market fit and was winning technical evaluations consistently — right up to the moment its deals reached procurement.

Enterprise procurement is where technical wins go to be audited. Fernbrook's target accounts were large enough that every vendor touching their operational data passed through a security review, and the review's gating question was almost always the same: provide your current SOC 2 Type II report. Fernbrook did not have one, and its improvised substitutes — a stale policy document, verbal assurances, screenshots assembled on request — were not moving deals forward. The company's growth story depended on converting a handful of named enterprise accounts, and every one of them was standing behind the same gate.

Where Things Stood

Three target accounts worth a combined $4M in first-year contract value required a current SOC 2 Type II report, and two deals had already been lost to competitors over security review failures. Security policies lived in a stale Google Doc last meaningfully revised during a previous funding round. Evidence collection meant screenshots and guesswork: when a prospect asked for proof of access reviews or logging coverage, engineers reconstructed whatever they could find, and the result varied depending on who answered the email. Security questionnaires — each one 200 to 400 questions, each one overlapping the last — were answered ad hoc by whichever engineers had context, consuming days at a time and producing inconsistent answers that occasionally contradicted each other.

The founders understood the gap but feared the standard remedy. The prevailing wisdom among their peer founders was that a SOC 2 effort meant a multi-year audit slog that would freeze the product roadmap, consume the engineering manager's calendar and still end in an expensive report. Meanwhile the pipeline kept calling: the three target accounts represented expansion the board had already modeled, and procurement at each one had made the report a hard requirement rather than a preference. Leadership gave the team five months to produce the report or walk away from the pipeline, a deadline that reframed the project from "someday compliance work" into a product launch with a ship date.

The Challenge

The challenge was to take a 90-person company with zero formal controls and produce an unqualified SOC 2 Type II report in five months — without freezing the roadmap the business was betting on. The constraint eliminated every slow path: no leisurely policy-writing phase, no annual-cycle evidence gathering, no discovery of the auditor's calendar after the controls were built. Everything with a long lead time had to start in week one, and everything with a quality bar — evidence, reviews, incident response — had to be real, because auditors test whether processes operate rather than whether documents exist.

The scale of the ask is easier to see in context. IBM Security's 2024 research puts the global average breach cost at $4.88 million, the highest figure the study has recorded, and finds that organizations making extensive use of security AI and automation save $2.22 million per breach on average; Verizon's Data Breach Investigations Report has repeatedly found stolen credentials among the most common initial access vectors worldwide. Enterprise buyers were not inventing their requirements — they were reflecting genuine breach economics, and Fernbrook needed controls that were defensible against that reality, not merely present in a document. The program had to produce operating evidence across five months, satisfy an independent auditor's sampling, and leave behind a compliance capability that would not collapse the moment the report was delivered.

Discovery and Diagnosis

Emerson Technology began with a two-week discovery that mapped Fernbrook's production environment, data flows and existing practices against the SOC 2 trust services criteria. The audit found a paradox common to strong engineering teams: many good practices already existed — encryption in transit, sensible cloud permissions, code review — but nothing was documented, owned, evidenced or consistent, and several controls the audit would sample had no process behind them at all. Access reviews had never been performed. Vendor risk files for subprocessors did not exist. Incident response was a channel in the team chat tool and goodwill.

The diagnosis produced the three decisions that shaped everything after it. First, scope: the audit boundary would be drawn tightly around the core production environment and the customer data it touched, rather than boiling the ocean, because a tight scope cuts cost, effort and the number of controls to operate. Second, sequencing: the auditor had to be selected in week one — auditor availability, not engineering, is the most common cause of missed deadlines — with the observation window locked before controls were built. Third, mechanism: evidence would be collected by systems, not people. Each control would be mapped to the system that generates its proof, wired through APIs into a compliance automation platform, and verified daily by automated checks instead of annually by screenshots. The five-month plan was then backwards-scheduled from the observation window's start date.

The Solution

The program paired a compliance automation platform with hardened cloud controls, so that Fernbrook's audit evidence was generated by the environment itself.

A tight scope and an early auditor

The audit boundary was defined around the product's core production environment, keeping the scope small enough to operate but large enough to be honest — the environment where customer data actually lives. An auditor was selected in week one: three firms interviewed, fees agreed, and the 90-day observation window locked on the calendar before any control work began, which converted the deadline from a hope into a schedule. The window was kept deliberately compact with clean evidence from day thirty, meaning the observation period measured controls that were already operating rather than controls still being built.

Controls that check themselves daily

Roughly 60 controls were mapped to the SOC 2 trust services criteria in the compliance platform, each with a named owner, a defined test and evidence collection wired directly into cloud APIs. Terraform-managed guardrails enforced the encryption, logging and access baselines in code, so controls passed automated checks daily rather than annually — a control that fails on Tuesday is a ticket, while a control that fails in an audit is an exception. Access reviews ran on a monthly cadence from the first month, building the historical evidence auditors require while catching orphaned accounts within weeks instead of years. The platform became the system of record, and its dashboards replaced the screenshots that had previously stood in for proof.

The human evidence: vendors, reviews, response

The controls no API can generate were built in parallel. Vendor risk files were backfilled for every subprocessor — SOC 2 reports, data-flow diagrams and termination terms collected for each third party in the stack — because auditors sample vendors early and missing files generate avoidable exceptions. A tabletop incident response exercise was run, written up and folded into an updated response plan, giving the auditor evidence the process actually works rather than a polished document that exists. Finally, a trust center was published for buyers: common security questions answered once, publicly, with the report available under NDA, so the sales team stopped consuming engineering time on overlapping questionnaires.

The First 90 Days

Week one closed the three long-lead decisions: scope, auditor and platform. Weeks two through six built the control framework — the 60-odd controls documented with owners and tests, the Terraform guardrails landing in the production repository, and the evidence integrations connected to the cloud provider, identity system and code repositories. By week six the automated checks were running daily, and the first failures surfaced exactly as intended: two logging gaps and a stale access grant, fixed within days, each fix generating its own evidence.

Weeks seven through ten covered the operational controls that require lived history: the first two monthly access review cycles completed and archived, vendor risk files assembled subprocessor by subprocessor, and the incident response tabletop run with the engineering team, producing an after-action summary and a revised plan the auditor would later sample. The trust center went live in week ten, and the sales team answered its first enterprise questionnaire from maintained answers in hours instead of days. Weeks eleven through thirteen were stabilization: evidence pipelines monitored for gaps, controls failing any daily check remediated at the source, and the observation window opened with clean evidence flowing from day thirty as planned. By day 90, Fernbrook was operating its compliance program as a routine system, and the remaining two months of the observation window were simply the system running.

The Results

Fernbrook received an unqualified SOC 2 Type II report with zero exceptions in month five, and the $4M in stalled enterprise contracts moved to signature within two quarters. Security questionnaires that consumed engineer days are now answered from a maintained trust center, cutting response time 70%, and two of the three target deals expanded mid-negotiation once the report cleared procurement. The platform now runs continuous compliance, so next year's audit is a review rather than a rebuild.

The durable change is that compliance became an engineering property rather than a sales emergency. Controls live in Terraform and pass daily checks, so the environment cannot quietly drift out of compliance between audits, and the monthly access reviews that once did not exist now generate the historical evidence every future audit will sample. Engineers stopped answering questionnaires ad hoc, recovering days of roadmap capacity each quarter. The founders' feared multi-year audit slog turned out to be a five-month build followed by a system that maintains itself — and the sales team now enters procurement conversations with the report attached instead of an apology.

What Your Business Should Do

The Fernbrook playbook works for any B2B SaaS facing its first enterprise audit, and its steps are mostly about sequence. Define the smallest defensible audit scope: draw the boundary around your core production environment and the data it touches, because a tight scope cuts cost, effort and the number of controls you must operate. Choose your auditor in week one — auditor availability, not engineering, is the most common cause of missed deadlines — so interview three firms early, agree fees, and lock the observation window before you build anything. Map controls to evidence sources first: for each control, identify the system that generates its proof and wire collection through APIs, because manual screenshots cannot survive a Type II observation window, let alone a daily automated check. Codify your baselines in infrastructure as code, enforcing encryption, logging and access rules through Terraform or equivalent tooling so controls pass automated checks daily instead of failing annual audits.

Run access reviews on a monthly cadence, because frequent lightweight reviews build the historical evidence auditors require and catch orphaned accounts within weeks rather than at annual cleanup time. Backfill vendor and subprocessor risk files — SOC 2 reports, data-flow diagrams and termination terms for every third party in your stack — since auditors sample vendors early and missing files generate avoidable exceptions that cost weeks. Exercise incident response before the window: run a tabletop, write the after-action summary and update the plan, because auditors want evidence the process works, not just a polished document that exists. Finally, publish a trust center for buyers — answer common security questions once, publicly, and link the report under NDA — because pre-built answers cut questionnaire turnaround from days to hours and shorten sales cycles. Sequence these eight steps against your own deadline with the action checklist in this practice book, and return to the reflection questions at every quarterly business review: how many enterprise deals stalled last year because you could not produce a current audit report, which of your controls would pass an automated daily check rather than a screenshot exercise, and what would a five-month audit freeze realistically cost your roadmap — is that cheaper than the pipeline you are losing?