SOC 2 project plan

A SOC 2 project plan is the operating document that turns a SOC 2 goal into assigned work: scope decisions, tasks, owners, dependencies, target dates, evidence, blockers, readiness findings, and audit-support actions.

SOC 2 itself is an AICPA attestation examination of a service organization’s system description and controls relevant to applicable Trust Services Criteria, a service auditor performs the examination. A project plan does not replace that examination, but it gives your team a way to manage the work before and during it. AICPA & CIMA describe SOC 2 reporting as focused on controls relevant to Security, Availability, Processing Integrity, Confidentiality, or Privacy.

What Is a SOC 2 Project Plan?

A SOC 2 project plan is not just a checklist or audit calendar. Not just that. It connects the examination scope to executable work across security, engineering, IT, HR, vendor management, legal/compliance, and leadership.

At minimum, the plan should identify:

• The system, product, service, or process in scope
• Applicable Trust Services Criteria
• Whether the project is preparing for Type I or Type II
• Workstreams and accountable owners
• Dependencies between teams and tasks
• Evidence needed for each control area
• Target dates and status
• Blockers and escalation paths
• Readiness milestones before formal audit work

The useful version is maintained throughout the project. If readiness findings, evidence requests, and remediation tasks live outside the plan, the project lead loses visibility into whether the team is actually audit-ready.

Decide the Scope Before You Build the Plan

Scope determines the rest of the plan. Before assigning tasks, confirm what the examination is intended to cover: the system being examined, relevant service commitments and system requirements, and the Trust Services Criteria in scope. Or more precisely, confirm the system boundaries, since AICPA guidance notes that those boundaries can vary with the services and categories included in the examination. The AICPA Trust Services Criteria cover Security, Availability, Processing Integrity, Confidentiality, and Privacy; the applicable criteria depend on the categories included in scope.

Resolve these inputs early:

• Which product, platform, service, or business process is in scope
• Which systems, environments, vendors, and teams support it
• Which Trust Services Criteria categories are included
• Whether the organization is starting from scratch or improving an existing control environment
• Whether the target is Type I or Type II
• When to involve the service auditor or engagement team for scope and evidence expectations

The Type I or Type II decision changes sequencing. A Type I examination is generally as of a point in time. A Type II examination covers a specified period and evaluates operating effectiveness in addition to control design, according to AICPA guidance on SOC 2 reporting. That means a Type II plan needs recurring control operation and evidence collection built into the schedule, not treated as a final-week packaging task.

SOC 2 Project Plan Phases From Kickoff to Audit

Use phases to sequence the work, but manage the work at the task level.

1. Kickoff and project governance

Confirm the executive sponsor, project lead, core stakeholders, status cadence, decision rights, and escalation path. The tracker should start with governance tasks: who approves scope, who resolves priority conflicts, and where blockers are reported.

2. Scope and criteria confirmation

Document the in-scope system, service boundaries, supporting teams, Trust Services Criteria categories, and Type I or Type II path. The output of this phase becomes the dependency for readiness assessment, control mapping, evidence requests, and auditor coordination.

3. Gap or readiness assessment

Use an internal readiness review to compare current practices against expected control activities for the agreed scope. Treat the output as project work, not a separate report that sits outside the plan. Findings should become tracked tasks with owners, target dates, evidence requirements, and blockers.

4. Remediation and control implementation

Assign each finding to an owner. Some tasks may be policy updates; others may require process changes, access review cadence, vendor review documentation, incident response evidence, or change management evidence. Dependencies matter here: HR training records may depend on HRIS exports, while access review evidence may depend on identity system ownership.

5. Evidence collection and validation

Collect evidence by workstream and control area. Depending on scope and control design, evidence may include access reviews, change records, vendor risk registers, incident response plans or test records, monitoring/logging retention evidence, security awareness training records, policy approvals, and risk assessment records. Validate evidence before audit support: is it current, complete, tied to the scoped system, and owned by someone who can answer follow-up questions?

6. Readiness review and audit preparation

Review unresolved gaps, missing evidence, and open blockers. For Type II, include whether recurring control activities have operated during the relevant period and whether evidence has been retained. The readiness decision is not a guarantee of audit results; it is a management decision about whether open issues are understood well enough to proceed.

7. Formal audit support

Once formal audit work begins, the plan should track auditor requests, response owners, due dates, evidence submitted, follow-up questions, and unresolved exceptions. Keep the service auditor’s requests visible in the same operating rhythm as the rest of the project.

Sample SOC 2 Project Plan Tracker

Use this as an adaptable project-management model, not a universal control catalog. Validate tasks, evidence, and expectations with your auditor or engagement team.

Assign Owners, Dependencies, and Evidence

SOC 2 projects get messy when tasks have no accountable owner, evidence is requested late, dependencies are implicit, or readiness findings are tracked somewhere separate from remediation. The project lead’s job is to make ownership and evidence flow visible.

Use a compact RACI-style model for each in-scope workstream. The example below is illustrative; adapt it to your operating model.

For each row, the plan should answer four practical questions:

1. Who is accountable if the task stalls?
2. Who actually produces the evidence?
3. Who reviews it before it is sent to the auditor?
4. What dependency could block completion?

Use the Readiness Assessment as a Go/No-Go Milestone

A readiness review can be used internally to turn identified gaps into tracked remediation work before the formal examination. It is not an official guarantee that the audit will proceed without issues, though.

Prepare for the review by collecting:

• Confirmed scope and criteria decisions
• Current policies and procedures
• Existing evidence samples
• Control owner list
• System and vendor inventories relevant to scope
• Known gaps, exceptions, or undocumented processes

Triage findings into action categories:

• Missing control: A needed process or activity has not been designed.
• Weakly designed control: The process exists but is unclear, inconsistent, or not aligned to the scoped environment.
• Control exists but lacks evidence: The team performs the activity but does not retain proof.
• Evidence is incomplete or outdated: Evidence exists but may not cover the right system, period, population, or approval.
• Ownership is unclear: No one can explain, operate, or approve the control activity.

Convert each finding into a project task with an owner, priority, dependency, target date, required evidence, status, and blocker. Then use the readiness review as a management decision point.

Before proceeding to formal audit support, review:

• Unresolved high-impact gaps
• Missing or incomplete evidence
• Ownership gaps
• Type II operating evidence needs, if applicable
• Auditor availability and request process
• Stakeholder risk tolerance for known open issues

The decision should be documented as a readiness position, not treated as an audit outcome at this point.

How Type I vs Type II Changes the Plan

Type I and Type II affect planning because they test different things.

• Timeline: Type I planning can focus on readiness as of a point in time. Type II planning must account for a specified examination period.
• Evidence: Type I evidence supports control design at the relevant date. Type II evidence also needs to support operating effectiveness during the period.
• Control activities: For Type I, the plan emphasizes whether controls are designed and ready. For Type II, the plan must schedule recurring operation, evidence retention, and owner follow-through.
• Readiness decision: Type I readiness can focus more heavily on design completeness. Type II readiness should also consider whether recurring control activities have been operating and documented.
• Project risk: Type I risk often centers on missing or weak control design. Type II risk often includes inconsistent execution, missing recurring evidence, or unclear ownership during the period.

Keep the distinction practical: do not add Type II evidence collection at the end of the project. Build it into the operating cadence.

Where Automation Helps — and Where Project Management Still Matters

Tools can help centralize SOC 2 tasks, evidence, owner assignments, status, and follow-up. They can also make recurring evidence collection easier to manage when information comes from connected systems.

But tools don’t decide scope, choose Trust Services Criteria, design controls, prioritize remediation, resolve blockers, or determine whether management is ready to proceed. Those are still project-leadership and auditor-coordination responsibilities.

If you evaluate Ciphrix or another compliance workflow tool, assess it against the operating model in this article: can it keep owners, evidence, readiness findings, blockers, and audit requests in one workflow? Treat automation as support for disciplined execution, not as a replacement for control ownership or the service auditor’s examination.

SOC 2 Project Plan Checklist Before Audit

Use this final checkpoint before moving from preparation into formal audit support:

• Scope and in-scope system are confirmed
• Applicable Trust Services Criteria categories are documented
• Type I or Type II path is confirmed
• Executive sponsor and project lead are assigned
• Workstream owners and evidence providers are assigned
• Auditor timing and request process are understood
• Readiness review is completed
• Findings are converted into tracked remediation tasks
• Dependencies and blockers are visible
• Evidence owners are assigned
• Required evidence is collected, scheduled, or clearly marked as open
• Evidence has been reviewed for scope, completeness, and currency
• Type II recurring control operation and evidence tracking are built into the plan, if applicable
• Open risks are reviewed before formal audit work begins
• Auditor requests will be tracked with owner, due date, status, and follow-up

A strong SOC 2 project plan is not the longest checklist. It is the plan that shows what is in scope, who owns each workstream, what evidence is needed, what is blocked, and whether the team is ready to support the examination.