Preparing for a SOC 2 Audit: Readiness, Evidence and the Common Gaps
Reading a SOC 2 report is one skill; producing one is another. This is the producer's side — what an organization actually does to get through an audit, and where the work concentrates. If you need the consumer's perspective, the report types and how to read one are under SOC 1, SOC 2 and SOC 3.
Scoping first
Two decisions shape everything else, and both are frequently made badly under sales pressure.
Which systems are in scope. Narrow scope means less work and a report customers may find inadequate. Broad scope means a stronger report and substantially more effort. Scope the service customers actually buy, and be able to describe the boundary clearly — auditors ask, and a vague boundary produces findings.
The boundary depends on an accurate inventory, which is why organizations discover during scoping that they do not have one. That work is upstream of the audit, not part of it, and it is the same dependency described under CMDB.
Which trust services criteria. Security is mandatory. Adding Availability, Confidentiality, Processing Integrity or Privacy each brings its own controls and evidence. Add what customers ask for, not everything, and expect to add more later.
Type I first, or straight to Type II
A Type I attests that controls are suitably designed at a point in time. It can be produced quickly and it gives a sales team something to show while the observation period for a Type II runs.
A Type II covers operating effectiveness over a period — typically six to twelve months for a first report — and it is what informed customers actually want. The pragmatic sequence for a first audit is Type I to unblock deals, then Type II covering the following period. Organizations with time go straight to Type II and skip the cost of two engagements.
The readiness assessment
A gap analysis against the criteria before the observation period starts. It is optional and skipping it is usually a mistake, because a gap discovered during the audit period means the control did not operate for part of it, and that becomes an exception in the report.
The output is a list of controls to implement, policies to write, and processes to start running — and critically, to start evidencing. A control implemented on day one of the observation period produces twelve months of evidence; the same control implemented in month nine produces three, and the report says so.
Evidence is the actual work
This is what surprises people. The audit does not test your controls directly — it samples evidence that they operated throughout the period.
Which means every recurring control needs a durable artefact with a date. Access reviews need the completed review with reviewer and outcome, not an assertion that they happen. Change approvals need the approval record for each sampled change. Vulnerability remediation needs the finding, the fix, and the dates. Onboarding and offboarding need the ticket showing access granted and revoked, with timing.
Evidence gathered retrospectively at the end of the period is the most common cause of pain, and sometimes of failure — you cannot produce an access review for last March in December. Automate collection from the systems that already record it, and treat "how will this be evidenced" as part of designing any control.
The gaps that actually cause exceptions
Consistently the same few, across organizations of every size.
Offboarding timeliness. Access not revoked promptly on departure, with the ticket timestamps proving it. Easy to fix and easy to sample, which is why auditors sample it.
Access reviews not performed or not evidenced. The review happened in a meeting and nobody recorded the outcome.
Change management bypassed. Emergency changes made without retrospective approval, or a deployment pipeline that permits unreviewed pushes to production.
Vulnerability remediation outside stated timelines. Your policy says critical findings are fixed in thirty days; the evidence shows ninety. Auditors test against the policy you wrote, so an unrealistic policy is worse than a modest one you meet.
Vendor management. No inventory of subservice organizations, no review of their reports, no assessment records — the programme described under supply chain security.
Incident response not exercised. A plan exists and no evidence of testing, which the criteria expect.
After the report
SOC 2 is annual and continuous. The observation periods are meant to be contiguous, so a gap between reports is visible and customers ask about it.
The organizations that find this sustainable are the ones that automated evidence collection and stopped treating the audit as a project. Those that treat it as an annual scramble pay the same cost every year and accumulate exceptions, which is a governance failure rather than a compliance one — the accountability framing under COBIT.
Exam angles
Know Type I as design at a point in time and Type II as operating effectiveness over a period, with the observation period typically six to twelve months. Recognize scoping and criteria selection as the first decisions, readiness assessment as identifying gaps before the period begins, and evidence produced contemporaneously as the core requirement. Name offboarding timeliness, access reviews, change management and vendor assessment as the recurring exception areas.
Comments
Post a Comment