SOC 2 · Readiness

SOC 2 Type II: A 90-Day
Readiness Roadmap
for Indian SaaS Startups

Rajith Sudhakaran, CISM · SOC 2 Lead Implementor 14 min read March 2026

A pattern I see repeatedly: an Indian SaaS startup lands a mid-market US or European enterprise client, and the procurement team asks for a SOC 2 Type II report. The startup has no compliance programme, three months before the deal closes, and is now trying to understand what SOC 2 actually is while simultaneously fielding a security questionnaire.

This guide is for that situation. It's a practical 90-day roadmap to get from zero to a credible, audit-ready SOC 2 Type II programme — structured around how auditors actually assess compliance, not how certification vendors sell it.

First: Type I vs Type II — The Difference Matters

A SOC 2 Type I report assesses whether your controls are suitably designed as of a point in time. A SOC 2 Type II report assesses whether those controls operated effectively over an observation period — minimum 6 months, typically 12.

Most enterprise clients asking for "SOC 2" want Type II. Type I is useful as a stepping stone but will not satisfy a serious procurement team on its own. The 90-day roadmap below prepares you for Type II — specifically, for the controls to be operating correctly by the time your observation period begins, so the Type II assessment reflects a mature programme rather than a rushed one.

The Five Trust Service Criteria — What They Actually Mean

SOC 2 is built around five Trust Service Criteria (TSC). Most engagements include Security (CC) as mandatory; the others are included based on what's relevant to your service commitments to customers.

For most Indian SaaS startups in their first SOC 2 engagement, I recommend starting with Security + Confidentiality. Adding Availability is worth it if you have uptime commitments in your contracts. Adding Privacy should be considered alongside your DPDP Act programme — the overlap is substantial.

The 90-Day Roadmap

Phase 1 Foundation & Scoping Weeks 1–2
  • Define your system description — Document what your service does, the infrastructure it runs on (AWS, Azure, GCP), and the boundaries of what's in scope. This is the foundation of your SOC 2 report and must be accurate.
  • Select your TSC — Decide which criteria to include. Get legal input on your customer contracts — what have you committed to regarding security, availability, and confidentiality?
  • Select your auditor (CPA firm) — Only licensed CPA firms can issue SOC 2 reports. In India, you'll typically engage a US-registered CPA firm or an international firm with Indian operations. Get this process started early — lead times are 4–8 weeks for initial engagement.
  • Conduct a readiness gap assessment — Map your current controls against the TSC requirements. Identify what exists, what's partially in place, and what's missing entirely. This assessment drives everything else.
  • Assign ownership — Each control needs a named owner responsible for operation and evidence collection. Don't leave this to "the engineering team" generically.
Phase 2 Policy & Control Implementation Weeks 3–6
  • Develop required policies — Information Security Policy, Access Control Policy, Change Management Policy, Incident Response Plan, Business Continuity Plan, Vendor Management Policy. These must be approved, versioned, and communicated — not just written.
  • Implement access controls — Role-based access control, MFA on all production systems, privileged access review process, onboarding/offboarding procedures. These generate the most evidence requests in a Type II audit.
  • Establish change management — A documented process for reviewing, approving, testing, and deploying changes to production. Even a lightweight Jira-based process is sufficient — but it must be followed consistently.
  • Configure monitoring and alerting — Security monitoring, availability monitoring, intrusion detection. The evidence of monitoring running consistently is critical for Type II.
  • Vendor risk management — For your critical subservice providers (AWS, Stripe, etc.), obtain and review their SOC 2 reports. Document what controls you're relying on them for (the complementary user entity controls model).
  • Risk assessment — Conduct and document a formal risk assessment identifying threats, likelihood, impact, and treatment decisions. This sits at the top of the CC9 control cluster.
Phase 3 Evidence Collection Infrastructure Weeks 7–9
  • Build your evidence repository — A structured folder system (or GRC tool) where control evidence is stored as it's generated. Organise by TSC control reference. Do not collect evidence retrospectively — auditors can tell.
  • Automate where possible — Access review reports from your identity provider, deployment logs from CI/CD, monitoring alert logs from your SIEM. Automated evidence is more reliable and less work than manual collection.
  • Run your first access review — Formally review all user access rights, document the review, and record any changes made. This must happen at least quarterly — start the clock now.
  • Test your incident response process — Run a tabletop exercise simulating a security incident. Document the exercise, findings, and any improvements made. This is evidence of operating effectiveness for CC7 controls.
  • Employee security training — All staff must complete security awareness training. Use any LMS that generates completion records. The content matters less than the consistency and documentation.
Phase 4 Readiness Review & Observation Period Start Weeks 10–12
  • Internal readiness review — Walk through each TSC control with your evidence. Identify any gaps in evidence coverage or controls not yet operating. Fix before the observation period begins.
  • Penetration test — Most SOC 2 engagements expect evidence of a penetration test or vulnerability assessment. Commission this now — remediation of findings takes time and you need closure evidence before the audit fieldwork begins.
  • Engage your CPA auditor — Your auditor will conduct a pre-assessment to confirm readiness. Brief them on your control environment, provide access to your evidence repository structure, and agree on the observation period start date.
  • Formal observation period begins — From this date, your controls must operate as documented, consistently, for the full observation period (minimum 6 months for Type II). This is the moment the clock starts.
The Most Common Mistake

Organisations that fail their first Type II engagement almost always have the same problem: they built the controls, but evidence collection was inconsistent during the observation period. A quarterly access review that was completed in Month 1 but skipped in Month 4 is a finding. A change management process that was followed for 90% of deployments is a finding. Consistency of operation is what Type II assesses — not the existence of the control.

Timeline Realistic Expectations

Day 1 to first Type II report: typically 9–12 months from a standing start. The 90-day roadmap above gets you to observation period start — the observation period itself is a minimum 6 months, typically 12 for a mature first report. Many Indian SaaS companies pursue Type I first (achievable in 4–5 months from a standing start) to satisfy immediate procurement requirements, then transition to Type II in the following cycle.

Responding to a SOC 2 request from a client?

We help Indian SaaS companies build SOC 2 programmes that satisfy enterprise procurement teams — with a clear path from the first client request to a signed Type II report.

Schedule a Free Scoping Call →
← Back to all articles Schedule a Free Consultation →