SOC 2 Readiness in 90 Days: What Actually Moves the Needle

SOC 2 readiness is a process that most SaaS teams underestimate twice: first when they estimate how long it takes, and second when they estimate what the hardest part is. The most common assumption is that readiness is primarily a documentation exercise, writing policies, filling out questionnaires, and organizing existing records. That assumption is why readiness programs stall at week six of a ninety-day plan and audits return qualified findings on controls that the team believed were in place.

The items that determine whether a SOC 2 audit passes or fails are not missing policy documents. They are technical controls: access control systems with documented review processes, logging infrastructure that captures the specific events the auditor needs to sample, incident response procedures that have been tested under conditions that resemble actual incidents, and vendor management documentation that covers the sub-processors who handle customer data.

This post maps the ninety-day sequence, which criteria generate the most findings, and which architectural decisions determine whether SOC 2 readiness is sustainable.

The AICPA Trust Services Criteria: what gets audited

SOC 2 is governed by the AICPA’s Trust Services Criteria. The Security criterion is required in every engagement. Every other criterion, Availability, Processing Integrity, Confidentiality, and Privacy, is optional and should be included if the organization makes commitments to customers in those areas.

The Security criterion contains the Common Criteria, which are the controls that all other categories incorporate. Microsoft’s Azure SOC 2 attestation is based on the AICPA Trust Services Principles and Criteria, including security, availability, confidentiality, and processing integrity. Microsoft’s own annual audits demonstrate what enterprise-grade compliance looks like at scale.

The 90-day SOC 2 readiness sequence

The ninety-day sequence below is designed to produce audit-ready controls for a Security-scoped SOC 2 Type I for a SaaS company with an existing engineering team and a modern cloud infrastructure. Extending scope to Availability or Confidentiality adds work within each phase but does not change the sequencing logic.

Days 1-30: gap analysis and control inventory

• Commission a SOC 2 readiness assessment from an independent firm. The assessment maps your current state against the AICPA Common Criteria and produces a gap list scored by severity and evidence availability. Skipping this step means the ninety-day plan starts without a validated understanding of which gaps are actually present
• Conduct an access control audit. List every system, every user account, and every service account that has access to production infrastructure and customer data. Identify accounts with excessive privileges, accounts belonging to former employees, shared service accounts without ownership, and service accounts with human-level permissions
• Inventory your logging infrastructure. Determine which events are currently logged, where logs are stored, how long they are retained, and whether logs are protected against tampering. The logging gaps identified here frequently determine what controls can be evidenced during the Type II observation period
• Document your current vendor landscape. List every third-party service that processes customer data, has access to production systems, or provides infrastructure the application depends on. This becomes the sub-processor inventory required by the vendor management control

Days 31-60: control implementation

• Implement documented access review processes. For every system with privileged access, define a quarterly access review cycle, document the review methodology, and complete the first review cycle. The documentation of who reviewed what, when, and what was changed is the evidence auditors will sample
• Deploy or configure centralized logging. SIEM integration or a managed log aggregation service that captures user authentication events, privilege changes, data access events, and system configuration changes is the technical foundation for the audit evidence trail. Ensure logs are immutable and retained for at least 12 months
• Test incident response. Table-top exercises that walk through the steps of the incident response plan, including detection, containment, communication, and post-incident review, produce documented evidence that the plan is operational. An untested plan provides almost no audit value
• Execute and document vendor assessments. Review the security posture and data handling practices of each sub-processor, document the review methodology, and confirm that existing contracts include the security requirements the AICPA Common Criteria mandate

Days 61-90: evidence organization and audit preparation

Compliance automation: the tools that reduce ongoing SOC 2 cost

The cost of maintaining SOC 2 compliance over time is primarily driven by the cost of continuous evidence collection: access reviews, logging verification, vendor assessments, and policy acknowledgments that must be performed and documented on a regular basis. Compliance automation platforms reduce this cost by automating the collection of evidence from connected systems.

• Vanta, Drata, and Secureframe integrate with AWS, Azure, Google Cloud, GitHub, identity providers, and HR systems to continuously monitor controls and collect evidence automatically. Instead of a team member manually exporting access logs before each audit, the platform collects and organizes evidence in real time
• Automated evidence collection reduces the labor cost of annual SOC 2 Type II audits substantially. The primary remaining human effort is reviewing and approving the collected evidence, conducting access reviews, completing vendor assessments, and managing the auditor relationship
• Compliance automation platforms also reduce the risk of findings from missed evidence. Manual programs rely on human memory to collect evidence on schedule. Automated platforms generate alerts when a required evidence item has not been collected or when a control has drifted out of compliance

The controls that most commonly cause SOC 2 audit failures

Understanding where audit findings are most likely to occur allows teams to prioritize those controls during the readiness period rather than discovering gaps during fieldwork.

• Untested incident response: an incident response plan that has never been exercised produces almost no audit evidence of operational effectiveness.

WebOsmotic’s compliance-focused development practice for clients in fintech and healthcare builds the logging infrastructure, access control architecture, and audit evidence trail into software from the start of development. Teams that build these controls in from day one avoid the most expensive part of SOC 2 readiness: retrofitting compliant infrastructure onto an existing system that was not designed for it.

Frequently asked questions

What is a SOC 2 readiness assessment and why does it matter?

A SOC 2 readiness assessment is a pre-audit exercise that maps an organization’s current controls against the AICPA Trust Services Criteria and produces a prioritized gap list. It functions as a practice run before the actual audit. Organizations that skip the readiness assessment and proceed directly to a Type II audit frequently encounter gaps during auditor fieldwork that generate qualified findings, delay the report, or require remediation before the audit can conclude. The cost of a readiness engagement, typically $15,000 to $50,000 for a mid-sized SaaS company—is substantially lower than the cost of remediating gaps discovered during an active audit.

How long does SOC 2 Type I vs. Type II take?

A SOC 2 Type I audit assesses whether controls are suitably designed at a single point in time. With a completed readiness assessment and organized evidence, Type I fieldwork typically takes two to four weeks, and the report is issued a few weeks after that. SOC 2 Type II requires a minimum six-month observation period during which evidence of control effectiveness must accumulate continuously. Microsoft’s SOC 2 compliance documentation confirms that reports are issued a few months after the end of the observation period. A full SOC 2 Type II program, from starting readiness to holding a 12-month observation period report, typically takes 14 to 18 months.

What controls do SOC 2 auditors most frequently find gaps in?

The most common audit finding categories are: access reviews without a documented and repeatable cadence; logging infrastructure that does not capture the privileged activity and data access events auditors need to sample; incident response plans that exist but have never been exercised; and sub-processor vendor management documentation that lacks formal security assessments for third-party services processing customer data. Policy documentation gaps are less frequently the cause of audit failures than these technical and operational control gaps.

What does compliance automation do for SOC 2?

Compliance automation platforms including Vanta, Drata, and Secureframe integrate with cloud infrastructure, identity providers, code repositories, and HR systems to continuously collect evidence against SOC 2 controls. This replaces manual evidence collection processes that require team members to export logs, conduct access reviews, and document vendor assessments on a scheduled basis. Automation reduces the labor cost of annual Type II renewals substantially, generates alerts when controls drift out of compliance, and organizes evidence in a format that auditors can review efficiently.

Can SOC 2 readiness be achieved in 90 days?

SOC 2 Type I readiness, the state in which controls are suitably designed and evidence is organized for a point-in-time audit, can be achieved in 90 days for a SaaS company with modern cloud infrastructure and an engineering team that can implement the required access controls and logging. SOC 2 Type II readiness requires the 90-day control implementation phase plus a minimum six-month observation period during which continuous evidence accumulates. The 90-day goal is realistic for Type I and for establishing the foundation that makes the Type II observation period productive.

How does WebOsmotic help with SOC 2 compliance?

WebOsmotic approaches SOC 2 compliance as an architecture decision rather than a retroactive audit exercise. For new products, we embed the access controls, logging infrastructure, and audit evidence trail into the software design from the first sprint. For existing products preparing for audit, we conduct a technical gap analysis, design the remediation architecture, and implement the controls that most commonly generate audit findings. We work with SaaS, fintech, and healthcare technology clients and treat compliance architecture as a first-class deliverable in every engagement.