SOC 2 Type II: what engineering actually has to build

01Type I versus Type II, and what the period means

Type I assesses whether controls are suitably designed at a point in time. Type II assesses whether they operated effectively across an observation window, typically three to twelve months. Enterprise buyers increasingly ask for Type II specifically, because Type I can be achieved by writing policies the week before the audit.

The practical consequence is that the observation period starts when your controls start working, not when you decide to pursue certification. If access reviews are supposed to happen quarterly and you have not done one, the clock has not started.

02The controls that actually require engineering work

Most of the Trust Services Criteria are satisfied by policy and process. A smaller set requires real implementation, and these are the ones worth starting early because they take time to build and longer to accumulate evidence for.

03Change management is where most findings arise

Auditors sample deployments and ask for evidence that each was reviewed, tested and approved. Teams with strong engineering practice usually pass this easily, because a pull request with a required approval and a passing CI run is exactly the evidence needed.

The failures are the exceptions - the emergency hotfix pushed directly to main at 2am during an incident. That is a legitimate operational necessity, and SOC 2 accommodates it, but only if you have a documented emergency change process that was followed and retrospectively approved. Undocumented exceptions become findings.

• Branch protection requiring review, enforced rather than conventional.
• CI that must pass before merge, with retained results.
• A documented emergency change path, with retrospective approval.
• Deployment records linking each release to the approved change.
• Separation between who writes and who approves, where feasible.

04Access reviews and deprovisioning

Access control findings cluster around two things: people who retained access after changing role, and departed staff whose access lingered. Both are process failures rather than technical ones, and both are trivially detectable by an auditor comparing your HR records to your access lists.

The engineering contribution is making access reviewable. If access is granted through a dozen separate systems with no central view, quarterly review becomes an unpleasant manual exercise that gets skipped. Centralised identity with group-based access makes the review tractable and the evidence automatic.

• Single sign-on for every system in scope.
• Group-based access rather than individual grants.
• Deprovisioning triggered by the HR process, with a target window.
• Quarterly reviews that produce a dated, signed artefact.

05Sequencing a first Type II

A realistic first Type II runs nine to twelve months from standing start to report. The sequence below front-loads the controls that need the longest evidence trail, which is what determines the timeline.

Compliance automation platforms genuinely help with evidence collection and are worth the cost for a small team. They do not implement controls for you, and buying one before you have controls simply produces a dashboard showing what is missing.

• Months 1-3: implement access control, change management, monitoring, encryption.
• Month 3: define scope and select an auditor; agree the observation window.
• Months 4-9: operate controls and accumulate evidence; run access reviews on schedule.
• Month 6: readiness assessment to surface gaps while there is time to fix them.
• Months 10-12: fieldwork and report.