How to create a SOC 2 project plan (timeline, owners, and milestones)

SOC 2 fails when treated as a last-minute audit sprint. A SOC 2 project plan turns compliance into managed workstreams with dates, owners, and dependencies, especially critical for Type 2 observation periods.

Related: Who is responsible for SOC 2? · Collection

---

Key takeaways

• Plan backward from audit fieldwork and Type 2 period end date.
• Separate readiness (policies, controls) from observation (evidence over time).
• Assign an executive sponsor and a day-to-day program owner.
• Track gaps weekly; auditors punish surprises.

---

Project phases

1. Scoping: systems, TSC categories, subservice organizations
2. Gap assessment: current vs required controls
3. Remediation: implement tools, policies, processes
4. Observation (Type 2): operate and collect evidence
5. Audit: CPA fieldwork and report issuance
6. Post-audit: bridge letters, customer communication, continuous monitoring

---

Sample milestones

Milestone	Typical timing
TSC scope signed off	Week 1–2
Policies approved	Week 4–8
Control matrix complete	Week 6–10
Readiness review	Before observation start
Observation period ends	Per auditor (e.g., 6–12 mo.)
Report issued	4–8 weeks after fieldwork

See how long audits take.

---

Roles and ownership

Area	Typical owner
Program management	Compliance / GRC lead
Technical controls	Security + Engineering
HR controls	People Ops
Vendor risk	Security / Procurement
Executive accountability	CTO / CISO / CEO

---

A sample SOC 2 timeline

For a SaaS company of up to 50 people starting with the Security criteria only, a realistic plan looks like this:

Weeks	Phase	Key outputs
1 to 2	Scoping	Systems in scope, Trust Services Criteria chosen, auditor shortlisted
3 to 5	Gap assessment	Control matrix, list of gaps with owners
6 to 14	Remediation	Policies approved, MFA and logging in place, access reviews and vendor reviews running, training completed
15 to 16	Readiness check	Internal or auditor-led readiness review, evidence spot check
17	Type 1 audit (optional)	Report on control design at a point in time
17 to 29+	Type 2 observation	Controls operating, evidence collected for a period of usually 3 to 12 months
End of period + 4 to 8 weeks	Type 2 audit	Fieldwork and final report

Many first-time companies choose a Type 1 report to unblock sales quickly, then start a 3 to 6 month Type 2 observation period straight away.

Workstreams to track

Run the remediation phase as parallel workstreams, each with an owner and a weekly status:

• Policies and governance: information security policy, acceptable use, access control, incident response, change management, vendor management, risk assessment
• Identity and access: single sign-on, MFA, onboarding and offboarding, quarterly access reviews
• Infrastructure and operations: logging, monitoring, backups, vulnerability scanning, patching, encryption
• Software development: code review, change approval, separation of environments, dependency scanning
• People: background checks where lawful, security awareness training, signed policies
• Vendors: inventory, risk rating and review of critical vendors, collection of their SOC 2 reports
• Incident response and continuity: incident response plan, tabletop exercise, backup restore test

Common risks that delay SOC 2

Risk	How to prevent it
Scope grows during the project	Sign off scope in week 2 and log any change as a decision
Engineers are pulled back to product work	Agree protected time with leadership at kickoff
Policies written but not followed	Start operating each control as soon as its policy is approved
Late auditor booking	Engage the audit firm during scoping, not after remediation
Evidence gaps in the observation period	Check evidence monthly, not only at the end
Vendor reports missing	Request vendor SOC 2 reports early, as some take weeks to arrive

Running the weekly check-in

Keep a 30-minute weekly meeting with workstream owners. Review three things: gaps closed since last week, gaps at risk of missing their date, and decisions needed from leadership. Share a one-page status with the executive sponsor every two weeks. A simple, consistent rhythm keeps the plan on track better than any tool.

Choosing your Trust Services Criteria

Scoping decides the size of your project. SOC 2 has five Trust Services Criteria:

Criteria	Required?	When to include it
Security	Always	The common criteria every SOC 2 report covers
Availability	Optional	You promise uptime or recovery times in customer contracts
Confidentiality	Optional	You handle sensitive business data, such as customer financials or intellectual property
Processing integrity	Optional	Customers rely on your processing being complete and accurate, for example payments or calculations
Privacy	Optional	You collect and process personal information directly from individuals

Most first-time SaaS reports cover Security, often with Availability and Confidentiality. Add criteria only when customers ask for them, because each one adds controls and evidence.

What to put in your project plan

A spreadsheet or project tool works fine. Give every task these fields:

• Workstream and control reference, so each task maps to a control in your matrix
• Task description written as a clear outcome, for example "MFA enforced for all users in the identity provider"
• Owner (one named person) and due date
• Dependencies, such as "needs SSO rollout first"
• Status and evidence link, so a closed task points to the proof the auditor will see

Plan backward from your target report date. If sales needs a Type 2 report by the end of next year, work out the observation period and audit window first, then fit remediation in before it.

Budgeting the project

A SOC 2 budget has four parts: the audit fee charged by the CPA firm, a compliance platform or consultant, security tools you may need to add (for example MDM, logging or vulnerability scanning), and internal time from engineering and leadership. Internal time is the cost most often underestimated. Ask audit firms for a fixed quote that states the criteria, the period and what happens if fieldwork runs over.

SecureSlate

---

FAQ

How long does a SOC 2 project take?

Most small SaaS companies need 3 to 4 months to reach Type 1 readiness. A Type 2 report adds an observation period of usually 3 to 12 months plus 4 to 8 weeks for the audit.

Should we start with SOC 2 Type 1 or Type 2?

Type 1 is faster and helps close deals that need a report soon. Type 2 carries more weight with enterprise customers. Many companies do a Type 1 first and start the Type 2 period immediately after.

Who should manage the SOC 2 project?

A single program owner, often a compliance or security lead, with an executive sponsor such as the CTO or CEO and named owners for each control. See who is responsible for SOC 2.

What is the most common reason SOC 2 projects run late?

Lack of protected time. Engineers are pulled back to product work and remediation stalls. Agree with leadership at kickoff how many hours each week the key people will spend on SOC 2, and report progress against that commitment.

Can we run SOC 2 and ISO 27001 projects together?

Yes. Build one control set that maps to both, run one risk assessment, and line up the audit windows. The plan gets slightly larger, but far smaller than running two projects back to back.

Disclaimer (legal note)

Timelines vary by maturity and scope. Informational only.