← All guides

Gantt Chart for SOC 2 Compliance and Audit Projects

Plan a SOC 2 Type II compliance program from readiness assessment to report issuance with a Gantt chart covering controls, evidence, audit fieldwork, and renewal.

Gantt Chart for SOC 2 Compliance and Audit Projects

SOC 2 (Service Organization Control 2) is the de facto security compliance standard for B2B SaaS companies selling to enterprise customers. Most enterprise procurement teams now require a SOC 2 Type II report as a condition of vendor approval, placing it on the critical path for deals above $50,000 in annual contract value. Companies that do not have SOC 2 lose deals not because their security is poor — but because they cannot prove it.

The problem SOC 2 creates for engineering and operations teams is not technical. It is a project management problem: SOC 2 compliance requires implementing dozens of controls across access management, change management, incident response, vendor management, and risk assessment; collecting evidence that those controls operated continuously during a defined observation period; and passing an independent audit conducted by a certified public accounting firm. Done well, it is 12 to 18 months of disciplined work. Done poorly, it is the same 12 to 18 months plus a failed audit and a remediation cycle.

The Gantt chart for SOC 2 makes the work visible, assigns ownership to each control domain, schedules the observation period correctly, and creates the accountability structure that keeps an inherently bureaucratic project moving.

SOC 2 Fundamentals Before Building the Plan

Trust Services Criteria and scope selection: SOC 2 is based on the AICPA Trust Services Criteria (TSC). The Security category is required — it covers logical and physical access controls, system operations, change management, and risk mitigation. The additional categories — Availability, Processing Integrity, Confidentiality, and Privacy — are optional and selected based on the services the company provides and what customers care about. A payments processing company adds Processing Integrity. A healthcare SaaS company adds Confidentiality and Privacy. Over-scoping adds audit cost and evidence burden without adding proportional customer trust.

Type I vs. Type II: The single most important SOC 2 decision is which type to pursue and why:

  • SOC 2 Type I: A point-in-time report. The auditor evaluates whether the controls are designed appropriately to meet the Trust Services Criteria as of the report date. It demonstrates that controls exist and are well-designed, but not that they have operated consistently over time. Most enterprise security reviewers recognize that Type I is a milestone toward Type II, not a substitute.
  • SOC 2 Type II: A report covering a defined observation period — typically 6 to 12 months. The auditor tests whether controls operated effectively throughout the observation period by sampling evidence. Enterprise procurement teams almost always require Type II. A Type II with a 6-month observation period is achievable in 12 to 14 months from a standing start; a 12-month observation period requires 18 to 20 months.

Some companies pursue Type I first (Months 1 to 8) and then continue directly into the Type II observation period (Months 9 to 20). This approach provides a commercial milestone (Type I report to give to prospects) while the Type II observation period accumulates.

Phase 1: Readiness Assessment (Months 1–2)

The readiness assessment is the foundation of the entire compliance project. Its output — a gap analysis against the Trust Services Criteria — determines the remediation scope, timeline, and resource requirements. Starting control implementation without a gap assessment produces an incomplete control set that fails the audit.

Scope definition: Define which systems, business units, and services are in scope for the SOC 2. Scope has a direct relationship to audit cost and evidence burden. A company whose entire product runs on AWS in a single region has a simpler scope than a company with multi-cloud infrastructure, on-premises components, and acquired legacy systems. The scope statement must be specific: "The SOC 2 covers the [product name] cloud service, including the application, API, data pipeline, and supporting infrastructure hosted in AWS us-east-1 and us-west-2, and the corporate IT environment supporting service delivery."

Gap analysis against Trust Services Criteria: Evaluate current practices against each control requirement in the Security category (and any additional categories in scope). For each requirement, the assessment produces one of three findings: control exists and is operating effectively (no gap), control exists but lacks documentation or evidence collection (documentation gap), control does not exist (implementation gap). Implementation gaps require the most remediation effort and must be prioritized.

Risk assessment: Conduct a formal risk assessment — a required SOC 2 control, not merely good practice. The risk assessment identifies threats to the systems in scope, assesses likelihood and impact, and links mitigating controls to each identified risk. The risk assessment must be documented formally, reviewed, and updated on a defined cadence (annually at minimum).

Remediation priority and resource planning: Rank remediation items by the combination of audit failure risk (controls without any implementation will produce major nonconformities that prevent report issuance) and implementation effort. Controls that are critical to the audit and easy to implement get done first. Controls that are complex to implement and lower audit risk get scheduled later in the observation period.

Phase 2: Policy and Documentation Development (Months 2–5)

SOC 2 requires documented policies, procedures, and control descriptions that auditors review as primary evidence that controls are designed appropriately.

Information security policy suite: The core policy documents required include: Information Security Policy (parent document), Acceptable Use Policy, Access Control Policy, Change Management Policy, Incident Response Policy, Business Continuity and Disaster Recovery Policy, Vendor Risk Management Policy, Data Classification Policy, and Encryption Policy. Each policy must define scope, responsibilities, requirements, and exceptions handling. Policies written as three-paragraph summaries that state "we care about security" are not evidence of control design — auditors look for specificity.

Procedures and work instructions: Policies describe what must be done; procedures describe how to do it. Access provisioning, change management, incident response, and access review procedures must be documented in enough detail that a new employee following the procedure would achieve a compliant outcome. Auditors may interview employees and ask them to walk through how they perform a process — if the procedure does not match what the employee actually does, it is a finding.

Control descriptions for the System Description: The SOC 2 report includes a System Description — a document written by management that describes the service, infrastructure, people, processes, and controls. The control descriptions in the System Description are what the auditor tests against. Writing accurate, specific control descriptions before the observation period begins ensures that the controls being tested are the controls that actually operate.

Statement of Applicability (for ISO 27001 dual-track programs): Companies pursuing ISO 27001 alongside SOC 2 produce a Statement of Applicability that maps controls to the ISO annex. The overlap between SOC 2 and ISO 27001 is substantial — approximately 70 to 80 percent of the control domains are shared — and companies pursuing both can structure the project to reduce duplicate evidence collection.

Phase 3: Control Implementation (Months 3–8)

Control implementation is the largest single phase — and the one where the most organizational resistance occurs. Security controls that change how engineers work, how access is managed, and how change is approved are not popular. Leadership sponsorship is a prerequisite for implementation success; security teams without executive backing have no enforcement authority.

Access control (identity and access management): Access control is typically the highest-risk control domain for first-time SOC 2 audits because it touches every person in the company and requires ongoing maintenance. Required implementations:

  • Single Sign-On (SSO) for all business-critical systems — Google Workspace, Okta, or Microsoft Azure AD as the identity provider
  • Multi-factor authentication (MFA) enforced for all users, not just optional for privileged users
  • Least privilege access — users have access only to what their role requires; no blanket admin access for convenience
  • Access provisioning and de-provisioning procedures — documented and followed, with evidence (ticket records, approval emails) generated at each event
  • Quarterly access reviews — all access to in-scope systems reviewed by the system owner and any excess access revoked, with evidence of the review and revocation documented

Vulnerability management: A documented vulnerability management program is required: vulnerability scanning of infrastructure and applications on a defined cadence (minimum quarterly external scan, weekly or continuous internal scan), a patching SLA (critical vulnerabilities remediated within X days of discovery), and a penetration test conducted by a qualified third party annually. The penetration test report and evidence of remediation of findings are standard audit evidence.

Incident response: The incident response plan must be written, tested via a tabletop exercise, and the tabletop exercise documented. Auditors look for evidence that the plan was exercised, not just that it exists. If a security incident occurred during the observation period, auditors will review how it was handled — whether the incident response process was followed, documented, and whether post-incident remediation was completed.

Change management: Change management controls prevent unauthorized changes to the production environment. Required elements: a change management ticket or request for all changes to in-scope systems, peer review or approval before production deployment, separation of development and production environments (developers cannot push directly to production without review), and a deployment record that links the change ticket to the production deployment. In SaaS companies with CI/CD pipelines, automated controls in the pipeline (required approvals before merge, automated security scans before deployment) are the preferred implementation.

Vendor risk management: Review and risk-rate all vendors that have access to customer data or to the in-scope infrastructure. High-risk vendors (cloud providers, security tools, payment processors) require collection of their SOC 2 reports or equivalent security documentation annually. The vendor inventory and risk ratings must be maintained and reviewed.

Employee security training and background checks: All employees in scope must complete security awareness training on hire and annually. The training completion records are audit evidence — not the training slides, but evidence that each employee completed the training. Background checks for all employees prior to access provisioning are a standard SOC 2 control.

Phase 4: Evidence Collection Infrastructure (Months 4–6)

Evidence collection is the operationally painful part of SOC 2 that most teams underestimate. The audit will sample evidence from throughout the observation period — if that evidence was not generated and stored during normal operations, it must be reconstructed or the control finding is a nonconformity.

GRC platform selection and implementation: Governance, Risk, and Compliance (GRC) platforms — Vanta, Drata, Secureframe, Tugboat Logic, and Thoropass are the leading options for B2B SaaS — automate evidence collection by integrating directly with cloud infrastructure (AWS, GCP, Azure), identity providers (Okta, Google), code repositories (GitHub, GitLab), ticketing systems (Jira, Linear), and HR systems (BambooHR, Workday). The platform monitors controls continuously, flags exceptions in real time, and stores evidence automatically. Manual evidence collection from spreadsheets and email chains is feasible for small companies but does not scale.

Evidence map: Before the observation period begins, produce an evidence map: for each control, document what evidence will demonstrate operating effectiveness, where that evidence is stored, and who is responsible for ensuring it is generated. Controls without a defined evidence source cannot be tested.

Access review cadence setup: Quarterly access reviews are a recurring evidence generation task. Set up calendar reminders, assign owners, and define the process — who pulls the access list, who approves it, where the approval is documented. Access reviews that are performed but not documented are indistinguishable from access reviews that were not performed.

Phase 5: Type I Audit (Optional, Months 7–9)

If pursuing Type I as a milestone, the Type I audit occurs after controls are implemented but before the observation period ends.

Auditor selection and engagement: Select a CPA firm accredited by the AICPA to perform SOC 2 audits. SOC 2 audit market is bifurcated: large firms (Deloitte, PwC, KPMG, EY, BDO) for enterprise clients; specialized SOC 2 audit firms (A-LIGN, Prescient Assurance, Johanson Group, KirkpatrickPrice) that are faster, less expensive, and typically serve growth-stage SaaS. Request proposals from two to three firms, compare pricing, timeline, and process.

Stage 1 (Document review): The auditor reviews the System Description, policies, and control documentation to assess design adequacy. Stage 1 findings — controls that are inadequately designed or documented — must be addressed before Stage 2 proceeds.

Stage 2 (Testing for Type I): For Type I, the auditor tests control design by interviewing personnel, reviewing system configurations, and inspecting control documentation. Testing takes 2 to 5 business days for most mid-sized SaaS companies. The Type I report is issued 4 to 8 weeks after fieldwork.

Phase 6: Observation Period (Months 8–20 for Type II)

The observation period is not a passive waiting period. Controls must operate consistently and generate evidence continuously throughout.

Continuous monitoring: The GRC platform monitors controls and flags exceptions in real time. A failed control — access review not completed on schedule, vulnerability not remediated within SLA, new vendor added without a risk assessment — must be detected and remediated before it becomes an audit finding. The longer an exception persists undetected, the more evidence the auditor has of ineffective operation.

Exception handling and documentation: When a control exception occurs (and they will — a quarterly access review that was scheduled for the 15th but completed on the 22nd, a vulnerability that was remediated 5 days outside the SLA), document the exception, the root cause, and the remediation. Auditors expect some exceptions in a 12-month period; what they test is whether exceptions were detected and addressed, or whether they indicate a systemic control failure.

Mid-period internal audit: Conduct an internal audit at the midpoint of the observation period to identify control gaps before the external auditor does. The internal audit tests a sample of evidence, identifies exceptions, and produces a management report with corrective actions. This is the best investment in audit readiness available — it costs far less than a remediation cycle after an adverse audit finding.

Phase 7: Type II Audit Fieldwork (Months 20–22)

Fieldwork preparation: In the 4 to 6 weeks before fieldwork, prepare the evidence package — pull all evidence from the GRC platform, organize it by control, verify completeness, and address any gaps. The evidence package should be auditor-ready before fieldwork begins, not assembled during fieldwork.

Auditor evidence requests: During fieldwork, auditors request evidence samples — typically 25 items per sampled control for a 12-month observation period. The GRC platform should produce these samples automatically. Gaps in evidence (evidence that does not exist for sampled population items) must be explained; if they represent an exception, the exception response documentation must be present.

Findings response: Major nonconformities (controls that did not operate at all or that produced consistent exceptions throughout the period) must be remediated before the report can be issued. Minor nonconformities are included in the report with the company's management response. The audit firm will not issue an unqualified (clean) report while any major nonconformity is open.

Phase 8: Report Issuance and Ongoing Program (Month 23+)

SOC 2 report distribution: The SOC 2 Type II report is issued by the CPA firm and is typically a 40 to 80 page document. Establish a customer trust portal (Vanta, Secureframe, and similar platforms offer hosted trust portals) that allows prospects and customers to request the report under an NDA without requiring manual fulfillment by the sales or security team.

Annual renewal: SOC 2 is not a one-time certification — the report must be renewed annually. The observation period for the renewal begins immediately after the prior period ends, so the audit is essentially continuous. The controls, evidence collection, and GRC platform monitoring that were established for the first audit continue permanently.

Common first-audit failures: The three most common causes of SOC 2 audit delays and nonconformities are: quarterly access reviews not performed on schedule (a recurring evidence gap that accumulates throughout the observation period), penetration test findings not remediated within the committed SLA, and change management tickets not created for production deployments (a process adoption failure rather than a technical control failure). Addressing these three specifically during implementation and the first months of the observation period prevents the most common adverse findings.

SOC 2 compliance, done right, is not a compliance exercise — it is the implementation of the security controls, processes, and monitoring infrastructure that make a SaaS company operationally defensible and commercially competitive in the enterprise market.