A readiness assessment is the part of SOC 2 that determines whether your first audit is painful or boring. Get it right and your Type 2 observation window runs on rails. Get it wrong and you spend the window patching fundamentals while evidence accumulates with gaps your auditor will find later. Most Indian SaaS teams we work with try to compress readiness into two weeks and remediation into two months, then wonder why their Type 2 report is delayed.
This is the 90-day readiness playbook we run at RingSafe. It assumes you are starting from a typical Indian SaaS baseline: AWS or GCP, GitHub for source, Slack, Google Workspace or Microsoft 365, an engineering team of ten to sixty, and a security posture that ranges from “we have MFA on email” to “we have some tooling but nothing documented.” By day 90, you should have a written gap analysis, a prioritized remediation backlog with owners, a draft policy library, and enough evidence scaffolding to start the observation window.
Week 0: Scope and prerequisites
Before day 1, you need three things locked.
- Trust Services Criteria decision. Security is mandatory. Decide on Availability, Confidentiality, Privacy, Processing Integrity. For most B2B SaaS, Security plus Availability plus Confidentiality is the right scope.
- System description scope. The customer-facing product, which supporting systems, which environments (prod, staging, dev). Document carve-outs.
- Executive sponsor and day-to-day owner. The CTO is usually the executive sponsor. The day-to-day owner is a named person, often a security or platform engineer, with at least 50 percent of their time committed for 90 days.
Days 1 to 14: Discovery and inventory
The goal of the first two weeks is an honest picture of where you stand. No remediation yet; just documentation.
Asset inventory
Build a single spreadsheet or CMDB listing all AWS accounts, cloud projects, SaaS tools that touch customer data, endpoint device inventory, and data stores. Include: owner, data classification, environment, backup status, and encryption status. This becomes Annex 1 of your readiness report.
Identity and access inventory
Pull the user list from your identity provider. For each production system, document who has access, what role, whether MFA is enforced, when it was last used. This will expose ghost accounts and over-privileged engineers.
Subprocessor inventory
Every SaaS vendor that processes customer data, including analytics, email, logging, and AI APIs. Record: vendor, purpose, data categories shared, SOC 2 report on file, DPA signed, annual review date.
Control self-assessment
Walk the Trust Services Criteria common criteria (CC1 through CC9) and mark each point of focus as: implemented, partially implemented, or not implemented. Be honest. Exaggerating here produces remediation gaps that surface during fieldwork.
Days 15 to 30: Gap analysis and remediation plan
By day 30, you need a written gap analysis and a prioritized backlog.
Gap analysis document
For each partially or not-implemented control, capture: control objective, current state, target state, remediation action, estimated effort, owner, target date. This is not a project plan; it is a commitment register.
Tooling decisions
Make the platform decisions that will cost time to reverse. Pick a compliance automation platform if you are going to use one (Drata, Vanta, Sprinto, Scrut are commonly used by Indian SaaS clients). Pick a SIEM or logging platform. Pick a vulnerability scanner. Pick an endpoint management tool. Procure and start rollout. Do not defer tooling to month two; evidence starts accumulating the moment tools are live.
Policy roadmap
SOC 2 does not require a specific policy list, but auditors will expect to see roughly fifteen to twenty policies covering: information security, access control, acceptable use, data classification, change management, incident response, vendor management, business continuity, backup, risk management, HR security, physical security, cryptography, secure development, logging and monitoring. Draft an ownership matrix for each policy.
Days 31 to 60: Build and operationalize
This is the heavy-lifting month. Parallel workstreams.
Workstream A: Identity and access
- Enforce SSO for all production-relevant SaaS tools.
- Enforce MFA for all identities with any production access.
- Remove all long-lived AWS or GCP access keys for human users. Move to SSO-backed role assumption.
- Document and run a first access review. Preserve the evidence.
- Deploy or formalize the joiner-mover-leaver process. Offboarding must complete within 24 hours of termination notice.
Workstream B: Change management
- Enforce branch protection on main branches with required reviewers.
- Enforce CI passing before merge.
- Require production deploy approval via a tracked mechanism (pipeline approval, ChatOps, ticket).
- Document an emergency change procedure.
- Retain evidence of deploys: who deployed, when, what, who approved.
Workstream C: Logging, monitoring, alerting
- Centralize logs from production cloud accounts, application, identity provider, and SaaS admin events.
- Set retention to at least 12 months for security-relevant logs.
- Build alerts for privileged access use, failed MFA at scale, security group changes to sensitive resources, new IAM user creation.
- Document the on-call rotation and escalation path.
Workstream D: Vulnerability management
- Deploy dependency scanning on source repos.
- Deploy container image scanning in CI.
- Deploy SAST if not already in place.
- Write and publish remediation SLAs by severity (for example: critical 7 days, high 30 days, medium 90 days).
- Schedule an annual external VAPT with a reputable vendor and preserve the report.
Workstream E: Policy library and training
- Draft and publish the policy library. Avoid generic templates; tailor to your environment.
- Deploy annual security awareness training with tracking.
- Require all employees to sign the acceptable use and confidentiality agreements.
Days 61 to 90: Operate and evidence
The last month is when you stop building and start proving. Every control must be seen to operate at least once with evidence retained.
Dry-run evidence collection
For each in-scope control, retrieve a sample of the evidence an auditor would ask for. Store it in a structured evidence repository. If a control cannot produce evidence today, it will not produce evidence during the observation window; fix the gap.
Tabletop exercise
Run a simulated security incident with the on-call team. Document the timeline, decisions, and post-incident actions. This produces tangible evidence of an operating incident response program.
Access review
Run a formal access review of all production systems. Document approvers, reviewed items, and remediations. Preserve the artifacts.
Vendor review
For critical subprocessors, pull their latest SOC 2 report, note the review, and file. This is a control in itself.
Readiness report
The output of day 90 is a readiness report that states, for every control: control statement, implementation, evidence location, owner, last operated date. The report is what an external auditor or internal audit committee reads to decide whether you are ready for Type 1 or Type 2.
The 90-day checklist in one table
| Phase | Outcome |
|---|---|
| Week 0 | Scope locked, sponsor and owner named |
| Days 1 to 14 | Asset, identity, subprocessor inventories; control self-assessment |
| Days 15 to 30 | Gap analysis, tooling decisions, policy roadmap |
| Days 31 to 60 | Identity, change, logging, vulnerability, policy workstreams |
| Days 61 to 90 | Dry-run evidence, tabletop, access review, readiness report |
Where teams lose the 90 days
Three failure modes account for most slippage. First, the day-to-day owner is not allocated full bandwidth and the work competes with feature velocity; readiness quietly slides. Second, tooling is procured late and evidence does not accumulate; the team scrambles in month three. Third, policies are drafted from templates without tailoring, and when auditors read them later, the disconnect between policy and practice becomes the audit finding.
If you cannot produce five samples of a control today, you will not produce them during the Type 2 observation window. Readiness is the time to discover this.
What happens after day 90
The clean outcome of 90 days is a readiness report with no critical gaps, a policy library, an evidence scaffold, and a team that knows what operational discipline feels like. From here, you can either issue a Type 1 opinion to satisfy a blocked buyer or start the Type 2 observation window immediately. Either path is realistic. Running into the window without readiness is not.
Related reading
- SOC 2 Type 2 roadmap — Indian SaaS
- SOC 2 vs ISO 27001 vs DPDP — which first
- SOC 2 readiness for Indian cloud startups
- AWS security audit — 47-point checklist
- ISO 27001 internal audit — practitioner’s checklist
Work with RingSafe
RingSafe runs SOC 2 readiness assessments and remediation for Indian SaaS companies. Founder Manish Garg (Associate CISSP, CEH, CCNP Enterprise) and the team have run this 90-day playbook with startups across fintech, health-tech, and B2B SaaS. We do the work with you, not for you, so your team owns the program after we leave.
If you have ninety days to get ready and need a senior team to run it, book a scoping call and we will tell you what is realistic given your environment and timeline.