§ WHAT WE FIX

SOC 2 Readiness and Compliance

A certification is blocking a deal, and the audit is the smaller half of the problem. We build the controls, the evidence pipeline, and the engineering habits that keep them true after the report is signed.

Who
Founder holds the engineering leadership seat; the delivery team executes underneath it.
Request a call What this covers

What you're seeing

A signed enterprise contract is waiting on a Type II report.
Usually means Revenue is now gated on an observation period that has not started. The date the customer expects is usually earlier than the earliest date physically available, and someone has to say so.
Security questionnaires are being answered by an engineer with other work.
Usually means Answers are coming from memory rather than from evidence, which is slow and produces follow-up questions. The loop consumes more engineering time over a year than building the control environment would have.
You passed a first audit and nobody knows how the evidence gets collected next year.
Usually means The first report was a project rather than a practice. The scramble repeats annually, gets more expensive each time, and eventually a control fails because nobody was operating it between audits.
Access reviews happen when someone remembers.
Usually means There is no owner and no schedule, so the control exists on paper. This is the single most common finding, and it is also one of the cheapest to automate away permanently.
The change management description does not match how code actually reaches production.
Usually means The policy was written for the auditor and the pipeline was built for the engineers. An auditor who samples deployments will find the gap, and the finding is worse than not having claimed the control.
Vendor assessments are a folder of PDFs in an inbox.
Usually means Subprocessors are not being tracked, and neither is what data each one holds. It surfaces late — usually when a customer asks for the list and it has to be reconstructed.

The audit is the smaller half

Most of the work is not the audit.

It is access reviews nobody owns. A change management story that does not match how code actually reaches production. Vendor assessments filed in an inbox. Onboarding and offboarding that happen reliably for laptops and unreliably for the six SaaS tools someone was granted in their first week.

The report at the end is a statement about all of that, and it is only as durable as the practices underneath it. That is why the framing here is readiness rather than certification: what gets built is a control environment, and the report is the byproduct that closes the deal.

Where it usually starts

A deal stalls. Procurement sends a questionnaire, an engineer spends the best part of two weeks answering it from memory, and the answers arrive with enough gaps to generate a second round.

That loop is the symptom, and it is worth pricing. Two or three of those a quarter is a meaningful fraction of a senior engineer’s year, spent producing answers that are not reusable because they were never evidenced. The fix is a control environment that answers the questionnaire from evidence — which is the same environment an auditor will test.

The second common entry point is a Type II date already committed to a customer. That one has a harder constraint, because an observation period is elapsed time that no amount of readiness work shortens.

Evidence first, policy second

The usual order is to write the policies and then work out how to prove they are followed. We invert it.

A control that is described but not evidenced is a finding. A control evidenced by hand becomes a control nobody operates between audits, which is a worse finding the following year. So collection is built first — access reviews that run on a schedule and record themselves, change history that comes out of the pipeline, vendor records that live somewhere with an owner — and the write-up then describes something that is already running.

This has a second benefit during fieldwork. An auditor samples: they pick three deployments from eight months ago and ask to see the review, the approval and the ticket. Organisations that built the pipeline first can produce those in minutes. Organisations that documented first spend fieldwork reconstructing.

Built for the second audit

Passing once is a project. Passing every year without a scramble is a property of how the system is built.

The difference shows up in what happens between audits. In the durable version, evidence accumulates as a side effect of ordinary engineering, and the annual effort is an auditor reading what is already there. In the fragile version, the control environment is reassembled each year by whoever is available, at increasing cost, until a control fails a test because nobody operated it in the intervening eleven months.

Most of the controls that overlap with reliability work — change management, access review, incident response — should be built once and serve both purposes. That overlap is the cheapest part of a compliance programme, and it is why this often runs alongside Platform Engineering rather than separately.

Two other engagements touch this. If you do not yet know how large the gap is, the Engineering Audit includes a compliance readiness pass and gives you a scoped answer in five days. And if the certification question arrived because of a transaction rather than a customer, Technical Due Diligence is the version written for the other side of the table.

What this covers

Each of these is a capability with its own page, its own order of work and its own outputs.

Capability What it means
Security Audit An assessment of where the system is exposed, ranked by what an attacker would actually reach. Findings written so they can be fixed rather than filed.
Code Security Review A manual review of the code that handles trust decisions, with automated scanning wired into the pipeline behind it so the same class of defect does not return.
ISO 27001 Readiness The management system European procurement asks for. Scope, risk assessment, the Statement of Applicability, and the operating evidence a certification body will want to see running.
Compliance Automation Evidence that accumulates as a side effect of normal work. Access reviews, change records and configuration checks collected continuously, so the next audit is a report rather than a project.
Vendor Risk Management Both directions of the same problem: assessing the vendors you depend on, and answering the questionnaires your own enterprise buyers send. One evidence base serves both.

Next step

Describe the situation and we'll tell you whether this is the right shape.

Request a call

How we decide

  • Built for the second audit, not the first

    Costs It is slower and more expensive than the minimum route to a first report.

    Passing once is a project; passing every year without a scramble is a property of how the system works. Evidence that accumulates as a side effect of normal engineering costs more to set up and almost nothing to maintain, and the second audit is the one that reveals whether the first was real.

  • The evidence pipeline is built before the controls are written up

    Costs It front-loads tooling work at the point when everyone wants to see policies.

    A control that is described but not evidenced is a finding, and a control evidenced by hand becomes a control nobody operates. Building collection first means the write-up describes something already running, which is also the only version that survives a sampled test during fieldwork.

  • We prepare, we never audit

    Costs It rules out the single-vendor convenience some clients ask for.

    The auditor has to be independent for the report to mean anything, and a provider offering both is either not independent or not doing one of the jobs. We run the readiness assessment, close the gaps and sit alongside you during fieldwork. Somebody else writes the opinion.

  • A compliance platform is recommended only where it earns the subscription

    Costs It occasionally means telling a client the tool they already bought is not doing much.

    Platforms automate evidence collection, which is genuinely most of the recurring cost. They do not create controls that do not exist, and a dashboard showing amber for things nobody has implemented is a project tracker with a licence fee. Where existing infrastructure already produces the evidence, the honest answer is to say so.

SOC 2, ISO 27001, and the frameworks around them

The overlap is larger than the differences, and the choice is usually made by which buyer is waiting rather than by the control sets.

Framework Who asks for it What it produces The time constraint
SOC 2 Type I North American buyers, as an interim answer An auditor's opinion on control design at a point in time Weeks after readiness — no observation period
SOC 2 Type II North American enterprise procurement, as the real requirement An opinion on controls operating over a period A three-to-twelve-month observation window that cannot be compressed
ISO 27001 European and international procurement A certificate against a management system, on a three-year cycle Stage 1 and Stage 2 audits, plus the ISMS running beforehand
A security questionnaire Any customer, at any time, with no warning Answers, and usually more questions Whatever the deal cycle allows, which is never enough

The row that costs deals is the second one. A Type II observation period is real elapsed time — no amount of readiness work shortens it — so the expensive mistake is starting the programme when the contract arrives rather than when the pipeline suggests it will.

Is this you?

  • A signed enterprise contract is waiting on a Type II report
  • Security questionnaires are being answered by an engineer who has other work
  • A first audit passed and nobody knows how the evidence gets collected next year

How we run it

Built for the second audit, not the first

Passing once is a project. Passing every year without a scramble is a property of how the system is built — access reviews that run themselves, evidence that accumulates as a side effect of normal work. We optimise for the second audit, which is the one that reveals whether the first was real.

Frequently Asked Questions

An attestation by an independent auditor that a service organisation's controls over security — and optionally availability, confidentiality, processing integrity and privacy — are designed appropriately and, in a Type II, operated effectively over a period. It is not a certificate you buy or a checklist you self-assess. It is a report someone else writes about what they observed in your organisation.
Type I says the controls were designed correctly on a given date. Type II says they operated correctly across a period, typically three to twelve months. Enterprise procurement almost always means Type II, and the observation period is real elapsed time — which is why the date a customer wants is frequently earlier than the earliest date available.
It depends on what exists already. A team with managed cloud infrastructure, code review and a ticketing system has most of the raw material and needs it evidenced. A team without those is building the practice as well as the paperwork. We scope after looking rather than before, and then the observation period is added on top.
SOC 2 is what North American buyers ask for; ISO 27001 is what European and international procurement asks for. The control sets overlap heavily, so doing one first makes the second substantially cheaper. Which comes first is decided by which deals are waiting, not by which framework is better.
A compliance platform automates evidence collection, which is most of the recurring cost, and for most teams at this stage it is worth its subscription. It does not create controls that do not exist. We implement one where it earns its place and say so plainly where the same job is already done by infrastructure you run.
An independent audit firm — it cannot be us, and a provider offering both preparation and the opinion should be treated carefully. We run the readiness assessment, close the gaps, build the evidence pipeline and sit alongside you during fieldwork. The opinion is written by someone with no interest in the outcome.
It drops during implementation and then recovers, and the size of the permanent cost depends on a choice made early. Controls implemented as process — approvals, forms, someone remembering — cost friction forever. The same controls implemented as tooling cost setup once. That is why the evidence pipeline is built before the auditor asks for it rather than after.
A penetration test answers whether the system can be broken into on a given day. This is about whether the organisation reliably does the things that keep it secure — access granted and removed on a schedule, changes reviewed, incidents handled, vendors assessed. Auditors will ask for a test as one input; it is a fraction of the control set.

Sources

Page reviewed