Trust BuildingAudit Insights & Preparation
How to Prepare for a SOC 2 Audit: Readiness Guide
Published · Updated ·10 min read
A gap assessment compares your current security posture against SOC 2 Trust Service Criteria requirements. We recommend using a GRC platform for the fastest approach — platforms like Vanta, Drata, Secureframe, and Sprinto connect to your tools and automatically identify configuration gaps.
Key Takeaways
- •The preparation phases overlap — we always advise clients that policy development, control implementation, and evidence collection run in parallel, not sequentially
- •We consistently recommend addressing access management first because it produces the most audit findings and carries the highest qualification risk
- •Ten core policies are required; customize GRC platform templates rather than using them as-is, and ensure policies match your actual practices
- •Complete all control implementation before starting the observation period to avoid carrying exceptions into your audit
- •We advise conducting a readiness assessment (self-assessment or formal readiness review) to validate completeness before engaging the auditor
This guide provides an actionable preparation framework for organizations that have committed to SOC 2 and need a practical roadmap for getting audit-ready. It covers every phase from initial planning through audit day, with realistic timelines, prioritization guidance, and common mistakes to avoid.
For the next operating decision, compare SOC 2 compliance for startups with policies needed for SOC 2. Confirm the work included, the evidence you need, and who will own implementation before committing to a provider.
Which stages belong in an audit preparation plan?
Phase Summary
| Phase | Timeline | Key Output |
|---|---|---|
| 1. Team assembly and project planning | Week 1-2 | Compliance team defined; project plan created; executive sponsorship secured |
| 2. Scope definition and criteria selection | Week 2-3 | Trust Service Criteria selected; system boundaries defined; auditor requirements documented |
| 3. Gap assessment | Week 3-5 | Gap report identifying current state vs SOC 2 requirements; prioritized remediation list |
| 4. Policy development | Week 4-8 | Ten core policies written, reviewed, approved, distributed, and acknowledged |
| 5. Control implementation | Week 5-14 | Technical and administrative controls implemented and operational |
| 6. Evidence collection setup | Week 10-14 | Automated evidence collection running; manual evidence processes established |
| 7. Readiness assessment | Week 12-16 | Pre-audit validation confirming controls are operating and evidence is complete |
| 8. Auditor engagement | Week 14-18 | Auditor selected; engagement letter signed; observation period begins |
Phases overlap — policy development begins during gap assessment, control implementation starts as gaps are identified, and evidence collection begins as controls become operational.
Who should be on the compliance team?
Core Roles
| Role | Responsibility | Time Commitment |
|---|---|---|
| Compliance lead | Owns the SOC 2 project; coordinates all preparation activities; primary auditor contact | Depends on scope and readiness |
| Executive sponsor | Provides organizational authority; approves policies; removes blockers; signs management assertion | Depends on scope and readiness |
| Engineering lead | Implements technical controls (access management, encryption, monitoring, change management) | Depends on scope and readiness |
| IT / DevOps | Configures infrastructure controls (logging, endpoint management, backup, disaster recovery) | Depends on scope and readiness |
| HR | Manages personnel controls (training, background checks, onboarding/offboarding procedures) | Depends on scope and readiness |
| Control owners | Individual team members responsible for maintaining specific controls in their domain | Depends on scope and readiness |
Common Staffing Approaches
| Company Size | Typical Approach |
|---|---|
| Under 50 employees | CTO or engineering lead acts as compliance lead; external consulting for guidance |
| 50-200 employees | Dedicated compliance lead (may be first compliance hire); engineering lead contributes significantly |
| 200+ employees | Compliance team with dedicated compliance lead; security team involvement; distributed control ownership |
What should the system scope and criteria cover?
Scoping Decisions
| Decision | How to Decide |
|---|---|
| Which Trust Service Criteria to include | Start with Security (mandatory); add Availability if customers depend on uptime; add Confidentiality if you handle confidential data; add Privacy if you process personal information; add Processing Integrity if data accuracy matters |
| Which systems are in scope | All systems that support the services covered by the report — production infrastructure, identity provider, code repository, monitoring, HR system, endpoint devices |
| Type I or Type II | Type II is preferred by enterprise buyers; Type I is an acceptable intermediate milestone if you need a report quickly |
| Observation period length | Depends on scope and readiness |
Criteria Selection for Common Business Types
| Business Type | Recommended Criteria |
|---|---|
| B2B SaaS | Security + Availability |
| Healthcare technology | Security + Availability + Confidentiality + Privacy |
| Financial technology | Security + Availability + Processing Integrity |
| Data analytics | Security + Processing Integrity + Confidentiality |
| Developer tools | Security + Availability + Confidentiality |
| EdTech | Security + Availability + Confidentiality + Privacy |
Phase 3: Conduct a Gap Assessment
How to Assess Your Current State
| Assessment Area | What to Evaluate | Common Gaps |
|---|---|---|
| Access management | MFA enforcement, provisioning/deprovisioning processes, access reviews, privileged access | MFA not enforced everywhere; no formal deprovisioning timeline; access reviews not performed |
| Change management | Code review requirements, deployment controls, branch protection, emergency change procedures | Branch protection not configured; no documented emergency change process |
| Policies | Existence, currency, management approval, employee acknowledgment | Depends on scope and readiness |
| Monitoring and logging | Security event logging, log retention, alerting, anomaly detection | Insufficient log retention; no alerting on security events; gaps in log coverage |
| Risk assessment | Formal risk assessment, risk register, annual review | No formal risk assessment completed; no risk register maintained |
| Vendor management | Vendor inventory, risk assessments, contractual security requirements | No vendor inventory; vendor security not assessed; BAAs missing where required |
| Business continuity | BCP documentation, DR plan, backup procedures, recovery testing | DR plan not documented; no backup testing; RTO/RPO not defined |
| Employee training | Security awareness training, policy acknowledgment, background checks | Training not completed; no training for contractors; background checks inconsistent |
| Encryption | Data at rest, data in transit, key management | Encryption not enabled on all storage; TLS not enforced on all endpoints |
| Incident response | IR plan, severity classification, communication procedures, post-incident review | No documented IR plan; no severity levels defined; no communication templates |
Prioritizing Remediation
After identifying gaps, we advise prioritizing based on the combination of audit impact and implementation effort:
| Priority | Gap Category | Rationale |
|---|---|---|
| 1 | Access management gaps | Produces the most audit findings; highest qualification risk |
| 2 | Missing policies | Required for every SOC 2 engagement; no policies means no audit |
| 3 | No risk assessment | Auditors check this early; absence is a clear finding |
| 4 | Change management gaps | Second most common finding area; directly testable |
| 5 | Monitoring and logging gaps | Evidence gaps here create exceptions across multiple criteria |
| 6 | Employee training gaps | Must be complete before observation period; easy to remediate but takes time for completion |
| 7 | Vendor management gaps | Requires outreach to vendors; time-dependent |
| 8 | Business continuity gaps | Important but less frequently cited in findings than access and change management |
Phase 4: Develop Policies
Required Policies
| Policy | What It Covers |
|---|---|
| Information Security Policy | Security program scope, governance, management commitment |
| Access Control Policy | Provisioning, authentication, MFA, access reviews, deprovisioning |
| Change Management Policy | Change authorization, code review, testing, deployment, emergency changes |
| Incident Response Policy | Detection, classification, response, communication, post-incident review |
| Risk Assessment Policy | Risk methodology, frequency, register maintenance, risk treatment |
| Data Classification Policy | Data categories, handling requirements, encryption, storage, disposal |
| Acceptable Use Policy | Employee technology use expectations, prohibited activities |
| Vendor Management Policy | Vendor evaluation, risk assessment, monitoring, contractual requirements |
| Business Continuity / DR Policy | Recovery priorities, DR procedures, testing, communication |
| HR Security Policy | Background checks, onboarding, training, termination procedures |
Policy Development Process
| Step | Action | Timeline |
|---|---|---|
| 1 | Use GRC platform templates as starting points | Day 1 |
| 2 | Customize each policy to reflect your actual practices | 1-2 days per policy |
| 3 | Compliance lead reviews for SOC 2 alignment | 2-3 days total |
| 4 | Management approves each policy with signature and date | 2-5 days (schedule early) |
| 5 | Distribute all policies to employees through GRC platform | Same day as approval |
Critical rule we emphasize with every client: Policies must match your actual practices. Do not write policies that describe aspirational processes. If you conduct access reviews quarterly, write "quarterly" — not "monthly." The auditor will verify policy-practice alignment during interviews.
Phase 5: Implement Controls
Implementation Priority
We advise addressing controls in order of audit impact:
| Priority | Control Area | Implementation |
|---|---|---|
| 1 | MFA enforcement | Enable MFA on all production systems, cloud consoles, code repositories, and administrative tools through your identity provider |
| 2 | Automated deprovisioning | Configure identity provider to revoke access across all systems when employment ends |
| 3 | Branch protection and code review | Enforce branch protection on all production repositories; require at least one reviewer for all pull requests |
| 4 | Security awareness training | Deploy training platform; assign training to all employees; set completion deadline |
| 5 | Quarterly access reviews | Schedule the first access review; document the process and results |
| 6 | Centralized logging | Configure log aggregation for all production systems; set retention to at least 365 days |
| 7 | Endpoint management | Deploy MDM/endpoint management on all company devices; enforce encryption and screen lock |
| 8 | Formal risk assessment | Conduct and document the first formal risk assessment with likelihood/impact scoring |
| 9 | Vendor inventory | Build vendor inventory; conduct initial risk assessment for critical vendors |
| 10 | DR plan and testing | Document the disaster recovery plan; conduct and document the first test |
Phase 6: Set Up Evidence Collection
Automated Evidence (GRC Platform)
| Evidence Type | Collected By |
|---|---|
| Cloud configuration (encryption, security groups, IAM) | Cloud provider integration |
| MFA enforcement status | Identity provider integration |
| Code review completion | Code repository integration |
| Employee device compliance | Endpoint management integration |
| Employee onboarding/offboarding dates | HR platform integration |
| Training completion status | Training platform or GRC platform module |
Manual Evidence
| Evidence Type | How to Collect | Frequency |
|---|---|---|
| Access review documentation | Quarterly review records uploaded to GRC platform | Quarterly |
| Risk assessment | Annual risk assessment document and risk register | Annually |
| Vendor risk assessments | Individual vendor assessment documents | Annually per vendor |
| Incident response records | Post-incident review documentation | Per incident |
| DR test results | Test execution records and results | Annually at minimum |
| Management meeting minutes | Security committee or governance meeting records | Quarterly |
Phase 7: Readiness Assessment
Pre-Audit Validation
Before engaging the auditor, we recommend validating that your program is complete:
| Validation Area | What to Check |
|---|---|
| All technical controls operational | MFA enforced; branch protection active; logging configured; endpoint management deployed |
| Evidence collection running | GRC platform showing evidence for all automated controls; manual evidence uploaded and current |
| Risk assessment documented | Depends on scope and readiness |
| Access review completed | At least one quarterly access review documented before the observation period begins |
| Vendor inventory complete | Critical vendors identified and assessed |
| Incident response plan tested | At minimum, a documented tabletop exercise |
Phase 8: Engage the Auditor
Auditor Selection Criteria
| Factor | What to Evaluate |
|---|---|
| SOC 2 experience | Number of SOC 2 engagements per year; industry specialization |
| GRC platform familiarity | Experience with your specific GRC platform (Vanta, Drata, Secureframe, Sprinto) |
| Timeline and availability | Can the auditor begin within your required timeframe? |
| Pricing | Fee range for your company size and scope |
| Communication style | Responsiveness and willingness to answer questions during preparation |
| References | Customer references from similar-size organizations |
Common Preparation Mistakes
| Mistake | Consequence | How to Avoid |
|---|---|---|
| Writing policies that do not match practice | Auditor identifies policy-practice gaps during interviews | Write policies based on what you actually do; update policies when practices change |
| Delaying access reviews | Access review evidence is the most commonly missing evidence | Schedule the first access review immediately; complete before observation period starts |
| Not enforcing MFA for all access types | MFA exceptions create findings | Enforce MFA through identity provider for all production and administrative access |
| Starting the observation period before controls are ready | Exceptions accumulate from day one | Complete all control implementation before starting the observation period |
| Not engaging the auditor early enough | Auditor availability delays the timeline | Depends on scope and readiness |
AICPA & CIMA’s SOC overview describes CPA assurance services. It defines the assurance context; it does not establish vendor rankings, market prices, or a particular company’s readiness.
Frequently Asked Questions
What causes the most SOC 2 audit findings and delays?
Access management is the single biggest source of audit findings and qualification risk, followed by change management and monitoring/logging gaps. These controls require cross-team coordination and often reveal infrastructure gaps, which is why control implementation taking longer than planned is the most common reason for delays.
Do I need a GRC platform like Vanta or Drata to pass SOC 2?
No. Assess the work required to collect evidence, track acknowledgments, and maintain records with your chosen process. A platform may support that work, but this guide does not quantify time saved. Above a handful of controls and integrations, the time and effort cost typically exceeds the platform subscription cost.
How many policies does SOC 2 require, and what are they?
SOC 2 requires ten core policies: information security, access control, change management, incident response, risk assessment, data classification, acceptable use, vendor management, business continuity/DR, and HR security. Customize GRC platform templates rather than using them as-is, and make sure each policy matches your actual practices since auditors verify alignment during interviews.
Should I get a SOC 2 Type I before a Type II?
A Type I is not required before a Type II.
Tyler Carbone
Managing Director and Cofounder
Tyler Carbone is a Managing Director and Cofounder of Agency and one of the industry's leading voices on governance, risk, and compliance. He holds degrees from Harvard and a JD/MBA from the University of Virginia, and previously worked in cybersecurity at Deloitte. Tyler has helped hundreds of companies operate SOC 2, ISO 27001, HIPAA, and GDPR programs.
LinkedIn
