SOC 2 implementation plan: phases, owners and deliverables, from scoping to the Type 2 examination period

How a SOC 2 project is structured

A SOC 2 implementation plan exists to reach the start of an examination period with controls that are designed, operating and producing dated records, then to keep them running for the whole period the service auditor tests. Policies are the small part; changing how access, change, incidents, vendors and people are handled, and proving it, is the large part.

The plan runs in seven phases. Some overlap, and evidence collection never ends. Each phase closes with a gate where the sponsor confirms the next can begin; projects that drift past the gates tend to discover at fieldwork that a control was never switched on.

How long each stage takes is covered in the SOC 2 timeline guide, and what phase two examines in the SOC 2 gap analysis guide. This guide covers who does what, in what order, and what each phase hands on.

The seven phases, with owners and deliverables

An illustrative plan for a service organisation with a capable technical team, one cloud environment and Security plus one further category. The weeks are a planning shape, not a promise.

Phases three and four overlap on purpose: once a control is designed, its owner starts producing its record, because early records expose the problems, such as a review nobody booked or a leaver whose access lasted a week too long.

Decision points between phases

• End of phase 1: categories, system boundary and report type are fixed. Changing them later reopens the gap analysis. The SOC 2 scope guide covers how to set the boundary.
• End of phase 2: the remediation plan, engineering budget and support route are approved.
• End of phase 5: the sponsor decides whether the controls are stable enough to start the examination period, or whether a short further run is needed.
• Before fieldwork: management reviews and approves the system description and signs its assertion.

The roles a SOC 2 project needs

The criteria for the control environment, communication, risk assessment and monitoring reach into management, HR and procurement, so the plan names people outside engineering from the first week.

In small organisations one person may hold several roles, provided nobody reviews a control they operate. The SOC 2 governance guide explains how oversight and control ownership are recorded; the SOC 2 vendor management guide covers the vendor owner's work in depth.

Where the service auditor comes into the plan

The service auditor is the licensed CPA firm that examines your controls and issues the report, independently of whoever designed them; Sterling prepares you but never performs the examination or issues the report.

The right moment to engage the firm is after phase one, once you know the categories, the system and whether you need a Type 1, a Type 2 or both, and before the readiness assessment. You can then agree the period's start and length, the firm's expectations for the description and evidence, and fieldwork dates. Selecting the firm itself, and the questions to put to it, is the subject of the guide on choosing a SOC 2 service auditor.

Fieldwork after the period is covered in the guide to the SOC 2 examination.

Design™ and Drive™: two ways to staff the same plan

The phases, gates and deliverables do not change with the level of support you choose. What changes is who carries the work between the gates. Design™ and Drive™ are alternatives; you choose one for the engagement according to the capacity of your team, not one after the other.

• Design™ (guided): your compliance lead and control owners do the implementation work, using Sterling's control library, policy templates, workshops and review. Sterling checks each deliverable against the criteria before the gate.
• Drive™ (managed): Sterling's consultants take on the agreed consulting and documentation work: drafting policies and the system description, building the control matrix, running the evidence calendar and chasing owners for records. Your people still operate the controls, and management still approves the description and signs its assertion.

What stalls SOC 2 projects

• Tool-first purchasing. A platform chosen before scope and controls are settled imposes a generic control set, and teams spend weeks configuring integrations for controls they do not operate. Design the controls first, then choose automation.
• Evidence collected only at the end. A Type 2 samples events across the period; records reconstructed in the final month are incomplete and easy to recognise. Start the evidence calendar the week each control goes live.
• One person carrying the programme. When the security lead also runs infrastructure, the project pauses whenever production needs attention. Name control owners across teams and give the compliance lead protected time.
• Starting the period before the controls are stable. Every failure during the period can become an exception in the report. The readiness assessment exists to decide when to start, not to confirm a date already promised to a client.
• Treating the Type 1 as the finish line. Without a Type 2 plan, controls lapse after the first report. See SOC 2 common mistakes.

SOC 2 implementation plan: questions buyers ask