SOC 2, ISO 27001, and PCI DSS programmes built from the controls up — not the evidence out. The difference is whether your certificate can answer a question the auditor never thought to ask.
An auditor tests whether your controls are documented, whether your evidence folder covers the sample period, and whether what you told them matches what they can verify. That is a specific, bounded test — and most companies learn to pass it.
A customer's security team tests something different. They test whether your controls actually work, whether the environment matches what the certificate claims, and whether the person answering their questions understands what they own. A SOC 2 report that passed last October does not answer the question they are asking in April.
The difference between a compliance programme that satisfies auditors and one that survives real scrutiny is not the certificate — it is whether the controls are real before the auditor arrives.
Scope definition is the first decision in any compliance programme — and the most consequential decision nobody explains to the client. A scope that excludes the production database, the cloud infrastructure, or the third-party integrations can produce a clean Type II report. It can also produce a clean Type II report for a system that stores no sensitive data and processes no real transactions. When a customer asks which systems are in scope, the conversation stops.
SOC 2 Type I tests whether controls are designed correctly at a point in time. Type II tests whether they operated consistently for six to twelve months. Most companies design controls for the Type I. Quarterly access reviews are scheduled. Change management tickets are raised. Then the quarter ends and the cadence slips — reviews happen when someone remembers, tickets get raised retrospectively. Auditors sample evidence across the entire period, not just the month before the audit. Eleven months of drift is not recoverable in the twelfth.
The report was clean. The sales team cited it. The customer's security team read the exceptions section — the part most people skip — and found three qualified opinions on controls that related directly to their data. They asked two follow-up questions. Nobody at the company could answer them, because the compliance programme had been managed by an external consultant and nobody internally had read the report.
A compliance readiness engagement is not a documentation project with an audit at the end. It is a security programme that produces a certificate as a by-product — because the controls are real before the auditor arrives.
A structured gap analysis against the selected framework — not a checklist, but a control-by-control review of what is implemented, what is partially in place, and what is missing entirely. The output is a remediation roadmap ranked by audit impact, not by technical complexity.
Designing controls that are auditable by construction — not retrofitted to fit the evidence requirement after the fact. The most common compliance failure is not missing controls. It is controls that exist but cannot be evidenced the way an auditor will sample them.
Preparing for the audit as if you know what the auditor will test — because after enough audits, you do. Pre-audit readiness reviews, evidence pack organisation, and being present when the auditor asks questions that can be answered two ways, one of which creates a finding.
A SOC 2 Type II period is twelve months long. ISO 27001 surveillance audits happen annually. The most expensive compliance mistake is treating certification as an event rather than a programme — and discovering in month eleven that the controls have drifted.
Most compliance programmes are run backwards — documentation first, controls second, security never. This one starts with the controls and builds the evidence around what is actually in place.
The most consequential decisions in any compliance programme are made before the work starts — which framework, which systems are in scope, and what the certificate will and will not claim. Getting scope wrong at this stage is expensive to undo and invisible until a customer asks the right question. This phase establishes what the programme will cover and what it will not — and why.
Week 1–2A control-by-control assessment of the current environment against the selected framework. Every control is evaluated not just for existence but for auditability — whether the evidence will survive the sampling methodology the auditor will use. The output is a gap register ranked by what will fail an audit first, not by what is easiest to fix.
Weeks 2–4Implementing the controls that are missing and redesigning the ones that exist but cannot be evidenced in the way the auditor will test them. Policies are drafted, technical controls are configured with your engineering team, and the evidence collection process is built to accumulate automatically through the audit period — not assembled at 11pm the night before fieldwork begins.
Weeks 4–12 (varies by gap count)An internal audit conducted before the external auditor arrives — testing the same controls, sampling the same evidence, and asking the same questions. This is where findings are surfaced and resolved while there is still time to resolve them. A finding discovered in a readiness review costs a week to fix. The same finding discovered by an auditor costs a qualified opinion on the report.
2–3 weeks before auditPresent during audit fieldwork for questions that need a security owner to answer — not a coordinator who escalates. After certification, the programme is structured to maintain compliance through the next audit period: quarterly control reviews, change management for systems entering scope, and annual refresh for framework updates. The certificate is the start of the programme, not the end of the project.
Ongoing post-certificationMost companies start a compliance programme because a customer asked for it, an investor expected it, or a deal stalled on it. The companies that get the most value from the programme are the ones that treat it as a security investment — not a sales prerequisite.
An enterprise customer has made SOC 2 a condition of the contract. The deadline is real. The fastest path to certification is not starting with policies — it is starting with scope, identifying the controls that will take the most time to implement, and working backwards from the audit date. The programme is designed around the timeline, not the other way around.
Type I proved the controls are designed. Type II will prove they operated consistently for twelve months. The clock started when the Type I was issued — which means the operating evidence period is already running, and the controls that were configured for the Type I assessment need to have been operating correctly every day since. A readiness review now is cheaper than a qualified opinion later.
The compliance project started internally. Policies were written. A consultant was engaged. Six months in, nothing has been audited, controls are partially implemented, and the team is not clear what "ready" actually looks like. This is the most common state for a first-time compliance programme. An experienced review at this point stops the drift — and tells the team what "ready" actually looks like.
SOC 2 is sufficient for US customers. The first UK or European enterprise deal will ask for ISO 27001. The first payments integration will trigger PCI DSS. Each framework has its own scope logic, control set, and evidence requirements. The decisions made for SOC 2 do not automatically transfer — and the controls that overlap need to be mapped before you build them twice.
The deliverables of a compliance readiness engagement are not documents. They are the operating infrastructure that makes the certificate credible — now and at the next audit.
Not every report needs to be qualification-free — but the qualifications should be on controls you chose to accept, not controls you didn't know were being tested. A readiness review before the audit is what separates a surprise finding from a planned exception.
Enterprise customers with mature security programmes do not rely on the SOC 2 report alone. They ask follow-up questions, request specific evidence, and occasionally conduct their own technical review. The controls in your environment are designed to answer those questions — not to answer the auditor's questions and hope nobody else looks.
The programme that produced the certificate is the same programme that maintains it. Quarterly control reviews, change management for new systems, and evidence accumulation through the audit period — so the next audit is a confirmation of a running programme, not a reconstruction of one that drifted.
Control owners are named individuals in your team. Evidence collection processes are documented and, where possible, automated. The compliance programme is owned internally — not dependent on an external consultant to answer questions the next time a customer or auditor asks them.
When a customer asks to review your SOC 2 report, the person presenting it has read it. When they ask what a control covers, someone can answer without calling the auditor. When the next audit arrives, the evidence already exists. The certificate is credible because the programme behind it is real.