SOC 2 readiness for cloud-native startups: the engineering checklist

TL;DR

• Once an enterprise buyer’s security team asks for a SOC 2 report, “we’ll have it by Q3” rarely keeps a deal alive — it becomes the last gate before signature.
• Most engineering teams already meet 60-70% of the technical controls. The gap is almost always evidence and procedural controls — policies, access reviews, incident runbooks — that exist in nobody’s head but were never written down or tested.
• A focused gap assessment (scope → technical review → procedural review → remediation roadmap) turns “we think we’re compliant” into a prioritized list with effort estimates, usually in three to five weeks.
• The real readiness test isn’t “would we pass” — it’s “could we hand an auditor the evidence for every in-scope control today, without a scramble.”

The problem: the deal is real, the audit programme isn’t

The trigger is almost always the same: an enterprise prospect’s security or procurement team sends a vendor questionnaire, and somewhere in it is a line that stops the deal — “Please provide your current SOC 2 Type II report.” Sales forwards it to engineering with a deadline attached to a contract value, and engineering’s honest answer is “we’re basically compliant, we just haven’t gone through a formal audit.”

That gap — between “basically compliant” and “auditor-verified” — is where deals stall for months. The team usually does have good practices: encryption at rest and in transit, role-based IAM, a CI/CD pipeline with code review gates. What it doesn’t have is the other half of SOC 2 — written policies, documented access-review cadences, an incident-response runbook that’s actually been used, evidence that controls have operated consistently over a period of time (Type II, not just a point-in-time snapshot).

Without a structured assessment, teams either over-scope (trying to satisfy every Trust Services Criteria “to be safe,” tripling the evidence workload) or under-scope (assuming a compliance-automation tool’s green dashboard means they’re ready, when it’s covering maybe half of what an auditor will actually test). Both waste months the deal doesn’t have.

The framework: scope, assess, document, prioritize

Step 1: Framework scoping — decide what “SOC 2” actually means for you

SOC 2 isn’t one fixed checklist — it’s an audit against the Trust Services Criteria you choose to be evaluated on. Security (the “Common Criteria,” CC1-CC9) is mandatory for every SOC 2 report. Availability, Confidentiality, Processing Integrity, and Privacy are optional add-ons, and each one adds real evidence-collection work — uptime SLOs and incident history for Availability, data classification and NDAs for Confidentiality, and so on.

The first working session should answer one question: which criteria does your customer actually need to see? A B2B analytics platform handling customer data usually needs Security + Confidentiality. A platform making uptime guarantees in its contracts needs Availability too. Adding criteria nobody asked for doesn’t make the report more impressive — it just multiplies the evidence you have to produce and maintain, forever, since SOC 2 Type II is a recurring annual audit.

The other scoping decision is Type I vs. Type II. Type I assesses whether controls are designed correctly at a point in time — it’s faster (and is often what an enterprise buyer will accept as a bridge while Type II evidence accumulates). Type II assesses whether those controls operated effectively over an observation window, typically 3-12 months. Most startups under deal pressure start with Type I, then roll into a Type II observation period immediately afterward.

Step 2: Technical controls assessment — read-only review against control IDs

This is the part engineering teams expect, and usually the part they’re most prepared for. A technical reviewer maps your actual cloud configuration to specific control IDs — not a generic checklist, but the literal CC6-CC9 control language:

• Access control (CC6) — IAM least-privilege, MFA enforcement (including for break-glass and root/admin accounts — the most commonly missed item), role separation between engineering and production access.
• System operations (CC7) — logging and monitoring coverage, alerting on security-relevant events, vulnerability scanning cadence.
• Change management (CC8) — does your CI/CD pipeline enforce code review and approval before production deploys, and can you produce a history of that enforcement?
• Risk mitigation (CC9) — backup and recovery testing, vendor risk assessment for your subprocessors.

Most of this review can be automated against live cloud accounts — that’s what compliance-automation platforms do well. Where it falls short is judgment: a flagged “MFA not enforced” finding might be a real gap, or it might be a service account that’s correctly excluded by policy. Automated scans flag both identically; an experienced reviewer separates them, because that distinction is the difference between a one-line policy exception and a week of IAM rework.

Step 3: Procedural and organizational controls — the half engineers forget

This is where most gap assessments find the real work, because it’s the half that doesn’t show up in a cloud console scan:

• Access reviews — do you have a documented quarterly (or more frequent) review of who has access to what, with sign-off, and can you produce evidence of the last two cycles?
• Incident response — is there a written runbook, and has it been tested (a tabletop exercise counts) in the audit period?
• Onboarding/offboarding — is access provisioning and de-provisioning tied to HR events, and is there evidence it happens within a defined SLA?
• Vendor management — do you track which subprocessors touch customer data, and have you reviewed their compliance posture?
• Security awareness training — has everyone with system access completed training, with records?

None of these are technically hard. All of them require someone to have written the policy, run the process, and kept the evidence — and in a 15-person engineering team moving fast, that’s exactly the kind of work that gets skipped under deadline pressure, then becomes the long pole when an auditor asks for it.

Step 4: Gap register and remediation roadmap — prioritized by audit risk, not just severity

Every control that doesn’t pass gets logged with three things: the specific requirement, the current state, and the closure path. The critical step is prioritization — and “prioritized by audit risk” is different from “prioritized by severity.”

A missing access-review policy might be “low severity” from a security standpoint (nothing is actively exploitable), but it’s an automatic finding in every SOC 2 audit and takes an afternoon to fix. A missing centralized logging pipeline might be “medium severity” but takes three weeks of engineering work and blocks multiple other controls (you can’t evidence monitoring without it). The roadmap separates these into a 30/60/90-day plan: the afternoon fixes go first (cheap wins that shrink the gap list fast), the structural work gets scheduled with a realistic timeline, and the audit kickoff date gets set after the structural work, not before.

Real-world example

Our client, an investment portfolio management platform, had been “doing SOC 2” for eight months using a compliance-automation tool. The dashboard showed 41 failing controls, with no indication of which ones mattered or how long each would take — to the team, it looked like eight months of work remained, and the enterprise deal that triggered the whole effort had a six-week runway left.

A focused gap assessment reclassified those 41 findings: roughly 60% were controls that were already effectively met — the infrastructure was correct, but there was no documentation or evidence trail (fixable in days, mostly writing down what the team already does). About 25% were procedural gaps — no written access-review policy, no tested incident-response runbook — each closeable in one to two weeks with provided templates adapted to their stack. The remaining 15% were genuine technical gaps: MFA wasn’t enforced on two admin accounts, and there was no centralized log retention meeting the audit’s evidence window.

With that roadmap, the team closed the technical gaps in the first two weeks, ran the procedural work in parallel, and entered a Type I audit six weeks after the assessment — inside the deal’s runway. The Type II observation period started immediately after, so the following year’s renewal conversation came with a Type II report already in hand instead of starting the same scramble again.

Trade-offs and what we’d avoid

• Don’t assume a green compliance-automation dashboard means you’re ready. These tools are genuinely useful for continuous monitoring of technical controls, but they don’t write your access-review policy, run your incident tabletop, or judge whether a flagged finding is a real gap or a documented exception. Treat them as one input, not the readiness assessment itself.
• Don’t scope every Trust Services Criteria “to be safe.” Security is mandatory; everything else is a recurring evidence-collection commitment you’ll carry every year. Scope to what your customers actually require.
• Don’t book the audit before the structural gaps are closed. A gap assessment 8-12 weeks ahead of audit kickoff gives engineering time to fix things like centralized logging or MFA enforcement that take real sprint capacity — not just paperwork.
• Don’t let policies describe a process that isn’t actually followed. Auditors test whether documented procedures match reality — if the access-review policy says “quarterly,” they will ask for evidence of the last two quarters specifically. A policy that doesn’t match practice is worse than no policy, because it’s now a documented control failure.

If you’re running AI or LLM workloads, factor in the newer questions auditors are starting to ask: training-data provenance, model-artefact access controls, and prompt/inference logging and retention. The audit-logging story for inference traffic intersects with general observability practice — see our post on LLM observability with Langfuse for the minimum viable setup that also gives you the evidence trail.

What to do next

1. Run the “evidence today” test on five controls. Pick five — MFA enforcement, last access review, incident runbook, vendor list, backup test — and ask: could you produce evidence for each, right now, without anyone scrambling? Wherever the answer is no, that’s your gap list starting point.
2. Decide your Trust Services Criteria scope before you talk to an auditor. Security is non-negotiable; everything else should map to a specific customer requirement, not a “just in case.”
3. Talk to us about a Compliance Audit. Our Compliance Audit engagement runs the full process above — framework scoping, technical and procedural controls review, evidence packet, and a 30/60/90-day remediation roadmap — typically in three to five weeks. Clients who run this before a formal audit typically cut their audit cycle by 40-60%, because the back-and-forth evidence requests that normally stretch an audit over months get resolved before the auditor arrives.

If a deal is sitting on a SOC 2 requirement and you don’t yet have a programme, book a 30-minute call — we’ll tell you honestly how big the gap is before you commit to anything.

Not sure SOC 2 is even the right framework for your buyers? See SOC 2 vs ISO 27001 — the decision usually comes down to who’s asking, not which framework is “better.”