SOC 2 Type II without slowing down a weekly release cadence

A Series C SaaS company came to us with four enterprise deals worth $2.8M in combined ARR held at security review, all requesting SOC 2 Type II. They had attempted it once already through a compliance automation platform, and the attempt had stalled.

The diagnosis was not complicated. The platform's generic controls did not describe how the team actually worked, so engineers were being asked to do compliance in addition to engineering. Within six weeks they had stopped engaging, which is the rational response.

Leadership's constraint was explicit: any control that slowed the release cadence would be rejected regardless of its compliance value. They shipped to production more than forty times a week and had no intention of stopping.

They got a clean Type II report in sixteen weeks with no change to release cadence. Here is what made that possible.

Do not add a change-approval process#

The instinct with SOC 2's change management criteria is to introduce a change advisory board, or at minimum a ticket that someone approves before deployment. This is where most engineering-organisation SOC 2 programmes die.

It is also unnecessary. What the criteria require is that changes are authorised, tested and approved by someone other than the author before reaching production. A well-configured pull request workflow already does all three.

The control we implemented was, in substance, the workflow they already had:

# Branch protection on the production branch
required_pull_request_reviews:
  required_approving_review_count: 1
  dismiss_stale_reviews: true
  require_code_owner_reviews: true
required_status_checks:
  strict: true
  contexts:
    - ci/tests
    - ci/lint
    - ci/security-scan
enforce_admins: true
allow_force_pushes: false

Four things made this auditable rather than merely good practice:

1. enforce_admins: true — without this, an administrator can merge unreviewed, and the auditor will find the exception. This was the only configuration change required.
2. The configuration itself is evidence. Exported via API on a schedule, it demonstrates the control was operating throughout the observation period, not just on the day someone screenshotted it.
3. Merge history is the population. The auditor samples from merged pull requests, and each carries its reviewer, its checks and its timestamps.
4. Exceptions are visible. Any merge that bypassed the rules appears in the audit log, so you can explain the three legitimate emergency deploys rather than being surprised by them.

Instrument evidence, do not collect it#

By the start of the observation period, 78% of the required evidence was produced without human involvement. That number is the difference between a routine audit and six weeks of senior engineering time.

What we connected, and what each source covered:

The remaining 22% is genuinely manual and always will be: board minutes, management review records, vendor assessments, policy approvals, the annual risk assessment. Those are quarterly or annual artefacts, so their cost is bounded.

The failure pattern to avoid: automating evidence collection into a folder nobody maps to criteria. Collection without mapping produces a large pile of artefacts and an auditor who still has to ask for things. Map first, then automate.

Pick your criteria honestly#

Security — the common criteria — is mandatory. Availability, Confidentiality, Processing Integrity and Privacy are optional, and every one you add expands scope, cost and the surface on which you can be found deficient.

Our advice is consistent: include only what a customer commitment or contract actually requires.

• Availability is the most commonly justified addition, for infrastructure-dependent services with uptime commitments.
• Confidentiality is often already covered adequately by Security for most SaaS products; add it when you make specific confidentiality commitments.
• Processing Integrity matters for payments, calculations and data transformation products. Rarely otherwise.
• Privacy is a substantial expansion and, for organisations with an ISO programme, usually better served by ISO 27701.

The company above scoped Security and Availability. Their prospects' risk teams accepted that without comment.

Type I or straight to Type II#

If a named deal is blocked right now, Type I produces a report in weeks and signals intent. If you have three to six months of runway, go straight to Type II — the report is far more valuable and you avoid paying for two audits.

We recommended Type I only once in the last two years, for a client with a contract signature contingent on a report inside five weeks.

The observation period is a real constraint, though. A three-month window is the usual starting point. That window has to be a period in which your controls actually operated, which means the readiness work has to finish before the window opens, not during it.

Running both ISO 27001 and SOC 2#

The same client needed ISO 27001 for two European prospects. Run sequentially, that is close to double the work. Run together off one cross-mapped control library, the second framework cost roughly 46% of the first.

The overlap is substantial — typically 70–80% of controls — but it is not automatic. It requires the control library to be built with both frameworks' requirements in view from the start, and it requires an evidence repository indexed by control rather than by framework.

Retrofitting the mapping after achieving one certification recovers most of the benefit but not all of it, because the first framework's documentation will have been written to that framework's structure.

What the report is actually for#

Worth remembering that the report exists to shorten a buyer's due diligence. That means the useful outputs of a SOC 2 programme extend past the report itself:

• A trust centre with the report request flow, sub-processor list and current certifications.
• An answer library covering the questions that recur across CAIQ, SIG Lite and bespoke enterprise questionnaires.
• A named owner who can join a customer security call and answer without escalating.

The client above cut nine days from their enterprise sales cycle. About half of that came from the report and about half from the three items above — which cost a fraction as much.

The gap between reports, and the bridge letter#

A Type II report covers a defined observation period and then stops. If your period ended in September and a prospect asks in February, there are five months the report says nothing about — and a competent risk team will notice.

The instrument for that gap is a bridge letter: a management assertion covering the interval since the report period, confirming no material changes to the control environment and disclosing any that occurred. Your auditor does not issue it; you do, on your letterhead.

Two things make bridge letters credible rather than perfunctory. Keep operating the controls and be able to show it, so the assertion is a statement of fact rather than optimism. And disclose the material changes honestly — a new sub-processor, a significant architecture change, a security incident. A bridge letter claiming nothing changed in five months at a growing company invites scepticism about everything else in the pack.

Plan the second report before the first arrives#

The first Type II is a project. The second is an operating rhythm, and the transition between them is where programmes decay.

The failure pattern is consistent. The team pushes hard for the report, ships it to the blocked deals, and disbands. Evidence automation degrades because nobody owns the broken connector. Nine months later someone realises the next observation period started two months ago and the control environment was not being evidenced.

Three commitments prevent it:

Name an owner with named time. Not "the security team" — a person with an allocation, even if it is two days a month. Compliance without an owner is compliance in decline.

Treat a broken evidence connector as a production incident. If the connector to your identity provider stops exporting, you have lost evidence for that window and it cannot be recovered retrospectively. That deserves the same alerting as a failed deploy.

Choose consecutive periods. Back-to-back observation windows mean continuous coverage with no gap to bridge, which removes the awkward conversation entirely. It also means the second audit is substantially cheaper, because the controls never stopped operating.

The client in this article moved to consecutive twelve-month periods after their first Type II. Their second examination consumed 11 hours of engineering time against 38 for the first — and the difference was almost entirely that nothing had to be reconstructed.

Our Compliance & Certification practice runs these programmes, and our SOC 2 Evidence Requirements Checklist lists every artefact an auditor will request with the system that can produce it automatically.