What Happens in the 90 Days Before Your SOC 2 Audit?

‍Most SOC 2 audit issues aren't caused by weak security. They're caused by poor timing.

The controls exist. The policies are signed. The evidence collection platform is connected. But audit readiness and security maturity are not the same thing. SOC 2 audits are won or lost in the months before fieldwork begins. The final 90 days determine whether your organization has enough time to validate controls, remediate vulnerabilities, collect evidence, and respond to auditor questions without scrambling.

This guide walks through exactly what should happen during those final 90 days, what auditors actually evaluate, and where organizations most commonly create audit risk without realizing it.

SOC 2 Audit Timeline

If your audit date is less than 60 days away and your penetration test has not been completed, you are already operating with very little margin for remediation and retesting.

The discovery of vulnerabilities does not cause most audit exceptions. They are caused by the lack of time required to fix them, validate the fixes, and assemble the evidence needed to demonstrate that controls operated effectively.

Type I vs. Type II: Why the Audit Type Matters

Before discussing timelines, it's important to understand which type of SOC 2 audit you're preparing for.

SOC 2 Type I

Evaluates whether controls are suitably designed at a specific point in time. The timeline is shorter because there is no observation period. Organizations need to finalize the scope, complete pentesting, and gather evidence before the selected audit date.

SOC 2 Type II‍

Evaluates whether controls operated effectively over a defined observation period, typically 6 to 12 months, with the shortest acceptable observation period being 3 months. The 90-day timeline in this article applies primarily to Type II audits.

One of the most common mistakes organizations make is treating the audit date as the finish line. In reality, auditors sample evidence from across the entire observation period. If a penetration test was completed nine months ago but the findings were never remediated, or the remediation wasn't documented, those gaps remain relevant during fieldwork. The result may be audit exceptions or even a qualified SOC 2 opinion, undermining the trust you've worked hard to build with customers and partners, potentially delaying or costing you enterprise deals.

Days 90-60: Lock Scope and Schedule Your Penetration Test

The most common SOC 2 preparation mistake happens before pentesting begins. Organizations finalize their System Description but fail to ensure that their penetration testing scope matches the systems described in the audit. Auditors routinely compare evidence across documents, so if the assets listed in your System Description do not appear in your penetration testing scope, expect additional questions and evidence requests.

Match Your Pentest Scope to Your System Description

If your SOC 2 scope includes:

• Customer-facing web applications
• Mobile applications
• Network surfaces

Your penetration test should explicitly cover those same assets. For most SaaS organizations, a network-layer scan alone is unlikely to provide sufficient evidence that application-layer controls were independently evaluated.

How Trust Services Criteria Expand Testing Scope

Security (Common Criteria) is always included in a SOC 2 audit. Additional Trust Services Criteria (TSC) can significantly expand the scope of what a penetration test needs to cover and is dependent on the data you process, clients you serve and commitments you make. 

Security is always included in a SOC 2 audit. Each additional Trust Services Criteria expands the scope of what a penetration test needs to cover. Availability introduces infrastructure resilience testing; Confidentiality focuses on data boundaries and access controls; Privacy expands application-layer testing around personal data handling; and Processing Integrity introduces business logic and workflow validation.

For most SaaS companies, adding multiple criteria transforms a standard pentest into a broader application security assessment that requires additional testing time and expertise.

Days 60-45: Execute Testing and Validate Controls

This is where organizations discover the difference between compliance automation and actual security validation. Tools like Vanta, Drata, and Secureframe are extremely valuable. They automate evidence collection, reduce manual effort, and help teams stay organized and proactively aware of the gaps to close before their audit. What they do not do is validate whether controls actually work under adversarial conditions.

What Compliance Platforms Verify

A compliance platform can typically confirm:

• An identity provider is connected
• MFA is enabled
• Endpoint protection is installed
• Security awareness training software exists
• Ticketing workflows are configured
• Basic infrastructure controls are met

What SOC 2 Pentesting Validates

A penetration test evaluates whether those controls hold up in practice.

Examples include:

• Tenant isolation weaknesses
• Broken object-level authorization (BOLA)
• Session management flaws
• Authentication bypass opportunities
• Business logic vulnerabilities
• Privilege escalation paths

A compliance platform may confirm that MFA is enabled. A penetration test may reveal that MFA can be bypassed through a legacy authentication endpoint that still accepts username and password authentication.

The compliance check passes. The control fails.

What GRC Platforms Don't Catch Before a SOC 2 Audit

Many audit exceptions originate from controls that exist completely outside automated integrations. These gaps remain invisible until fieldwork begins.

Human process controls are the biggest offender. GRC tools like Vanta will verify that a training platform is connected, but won't flag that your Q3 contractor cohort never completed it or that someone's access persisted for 3 days after their last day. Auditors pull samples, and they will find the exceptions you forgot about.

Password/auth policy mismatches are a classic gap. Companies write a policy saying "minimum 12 characters, MFA required for all users," but the Okta config enforces 8 characters and exempts a handful of service accounts from MFA. The policy document and the technical enforcement don't match, and that's an automatic exception.

CUECs (Complementary User Entity Controls) are expected and often forgotten for 1st time compliance journeys. They list controls that your clients are responsible for implementing. Nobody puts these in their GRC tool, nobody reviews them annually, and auditors increasingly know to ask about them.

Change management exceptions are most common in fast-moving engineering teams. The hotfix that went straight to prod at 12 am, the Terraform run someone kicked off from the console with no ticket. These show up in audit log samples. Segregation of duties (the person who approves a change shouldn't be the one deploying it) is technically enforced almost nowhere.

Risk assessment cadence is underrated. Most companies conduct their risk assessment once a year, in the month before their audit window, or as part of their initial gap assessment when they hire an auditor or deploy a GRC automation tool. Auditors want to see that it's a genuine, ongoing process with documentation of how risks changed over the period, reporting to the board or Security Committee, not a checkbox document.

Pentest remediation evidence is a gap distinct from the pentest itself. Even if you have a great test, if you can't show a formal risk acceptance or closed ticket for each vulnerability, you'll get flagged.

‍

Days 45-30: Remediate Critical and High-Risk Vulnerabilities

The goal is not to achieve zero vulnerabilities before your audit. The goal is to demonstrate that the identified risks were evaluated, appropriately addressed, and tracked through to completion or formal acceptance. Auditors generally care far more about the maturity of your remediation process than whether every medium- and low-severity vulnerability has been eliminated.

Critical and high-severity vulnerabilities should be addressed quickly enough to allow retesting before fieldwork begins, aligned with your Vulnerability Management Policy SLAs.

Each vulnerability should have:

• Named owner
• Remediation ticket
• Vulnerability severity
• Date found
• Closure date
• Validation evidence
• Retest confirmation

Do not wait until every vulnerability is fixed before scheduling retesting. Coordinate with your testing provider early so remediation validation can occur as fixes are completed.

For vulnerabilities that will be risk accepted rather than remediated, documentation should include:

• Risk owner
• Business justification
• Approval record
• Review date

Days 30-14: Gather the Evidence Auditors Want

By this stage, most control gaps should already have been identified, and remediation should be nearing completion. The focus now shifts from finding issues to organizing evidence.

Your evidence package should typically include:

Access Control Evidence

• User provisioning records
• User deprovisioning records
• Annual access review documentation
• Privileged access approvals

Security Testing Evidence

• Penetration test report
• Remediation records
• Retest executive summary
• Risk acceptance documentation

Vendor Management Evidence

• Vendor inventory
• Vendor risk assessments
• SOC 2 review records

Change Management Evidence

• Approved change requests
• Deployment records
• Emergency change documentation
• Segregation-of-duty evidence

This phase should be administrative rather than investigative. If you are still discovering missing controls or scrambling to collect evidence at this stage, the timeline is already under pressure.

Days 14-0: Package, Review, and Submit

The final two weeks should focus on validation rather than remediation. Before submitting your evidence package, confirm:

• Pentest scope matches the System Description
• Critical vulnerabilities are closed or formally risk accepted
• Retest attestation has been received
• Access reviews are complete
• Vendor reviews are documented
• Change management evidence is retrievable

Where possible, provide auditors with structured evidence repositories rather than individual files spread across multiple systems. The easier it is for auditors to validate controls, the smoother fieldwork tends to go.

The Biggest SOC 2 Audit Preparation Mistake

The organizations that move through SOC 2 audits smoothly don't have better security. They have better timing. The 90-day window is an operational project with real dependencies: 

• Scope alignment
• Independent testing
• Remediation
• Retesting
• Evidence collection

Each phase depends on the one before it. The teams that struggle most during SOC 2 audits are not usually the ones with the weakest security programs. They are the ones who discover too late that audit readiness and security maturity are not the same thing.

Frequently Asked Questions

When should you schedule a penetration test for a SOC 2 audit?

Most organizations should complete their penetration test at least 60 days before fieldwork begins. Forty-five days is generally the minimum practical timeline because remediation, retesting, and evidence collection all require time.

Do Vanta or Drata replace a penetration test?

No. Compliance platforms verify that controls are in place and integrations are connected. They do not independently evaluate whether controls function effectively under adversarial conditions.

Can you pass a SOC 2 audit with open vulnerabilities?

Possibly. Auditors evaluate severity, documented risk acceptance, remediation plans, and management response. A documented low-risk vulnerability is often easier to defend than a critical vulnerability with no remediation evidence.

What evidence do auditors want from a penetration test?

Auditors typically expect:

• Scope definition
• Testing methodology
• Tester independence statement
• Vulnerability findings
• Remediation records
• Retest attestation
• Risk acceptance documentation

What causes the most SOC 2 audit exceptions?

The most common exceptions include:

• Incomplete access reviews
• Missing policy attestations
• Vendor management gaps
• Failure to evaluate CUECs
• Change management documentation issues
• Delayed offboarding
• Missing remediation evidence