Overview
You'll learn how to use ISMS Copilot to prepare for a SOC 2 audit, from selecting the right report type and defining scope through implementing controls, collecting evidence, and achieving audit readiness.
Who this is for
This guide is for:
SaaS companies pursuing their first SOC 2 certification
Security and compliance teams managing SOC 2 readiness
Startups required by enterprise customers to obtain SOC 2
Organizations transitioning from Type I to Type II audits
Companies expanding SOC 2 scope to additional Trust Services Criteria
Prerequisites
Before starting, ensure you have:
An ISMS Copilot account (free trial available)
Basic understanding of your technology infrastructure and data flows
Access to existing security policies and documentation (if any)
Executive commitment to SOC 2 certification timeline
Budget allocated for audit fees and potential tool investments
Before you begin
What is SOC 2? SOC 2 (System and Organization Controls 2) is an auditing standard developed by the AICPA that evaluates how service organizations manage customer data based on five Trust Services Criteria: Security (mandatory), Availability, Processing Integrity, Confidentiality, and Privacy.
Timeline expectations: SOC 2 Type I typically takes 3-6 months to prepare. Type II requires 6-12 months because controls must operate effectively for a defined period (minimum 3-6 months). Starting preparation too late is the most common reason for missing customer deadlines.
Cost awareness: SOC 2 audit fees range from $15,000-$80,000+ depending on organization complexity, scope, and auditor. Budget for audit fees, potential tool purchases, and 20-30% of one FTE's time for coordination and evidence collection.
Understanding SOC 2 fundamentals
Type I vs. Type II
Choose the right audit type for your situation:
Aspect  | SOC 2 Type I  | SOC 2 Type II  | 
|---|---|---|
What it evaluates  | Control design at a point in time  | Control design AND operating effectiveness over time  | 
Audit period  | Single point in time (1 day)  | Minimum 3-6 months, typically 12 months  | 
Preparation time  | 3-6 months  | 6-12 months  | 
Evidence required  | Policies, procedures, configuration screenshots  | Logs, reports, tickets spanning entire period  | 
Cost  | $15,000-$40,000  | $30,000-$80,000+  | 
Customer acceptance  | Acceptable for initial proof  | Preferred by enterprise customers  | 
Strategic approach: Many organizations start with Type I to prove control design, then immediately begin the observation period for Type II. This allows you to demonstrate progress to customers while building the evidence portfolio for the full Type II audit.
Trust Services Criteria
Understand which criteria apply to your services:
Security (mandatory): Protection against unauthorized access, both physical and logical
Availability (optional): System uptime and performance commitments (e.g., 99.9% SLA)
Processing Integrity (optional): System processing is complete, valid, accurate, timely, and authorized
Confidentiality (optional): Confidential information is protected per commitments
Privacy (optional): Personal information collection, use, retention, disclosure, and disposal
Ask ISMS Copilot to help determine scope:
"We provide [describe your services: SaaS platform, data processing, hosting]. We promise customers [uptime SLA, data protection, etc.]. Which SOC 2 Trust Services Criteria should we include in our scope? Explain the rationale for each."
Step 1: Set up your SOC 2 preparation workspace
Create dedicated workspace
Log into ISMS Copilot
Create new workspace named: "SOC 2 Type [I/II] Preparation - [Company Name]"
Add custom instructions:
SOC 2 audit preparation context:
Organization: [Company name]
Industry: [SaaS, fintech, healthcare tech, etc.]
Services in scope: [describe what you provide to customers]
Infrastructure: [cloud provider, architecture details]
Team size: [employees, IT/security team size]
Audit details:
- Report type: Type [I or II]
- Trust Services Criteria: Security + [additional criteria]
- Audit period: [dates for Type II]
- Target completion: [date]
- Auditor: [if selected]
Current state:
- Existing compliance: [SOC 2 renewal, ISO 27001, none]
- Documentation maturity: [starting fresh / have policies]
- Technical controls: [tools in use]
- Main gaps: [areas of concern]
Preferences:
- Emphasize practical, auditor-accepted implementations
- Provide evidence collection guidance
- Reference AICPA Trust Services Criteria directly
- Suggest automation opportunities
- Consider cost-effective solutions for [startup/growth company]Step 2: Conduct SOC 2 readiness assessment
Assess Common Criteria (Security - mandatory)
The Security criteria include control categories across:
Ask ISMS Copilot for a readiness checklist:
"Create a SOC 2 Security Common Criteria readiness assessment checklist covering all control categories: CC1 (Control Environment), CC2 (Communication), CC3 (Risk Assessment), CC4 (Monitoring), CC5 (Control Activities), CC6 (Logical Access), CC7 (System Operations), CC8 (Change Management), CC9 (Risk Mitigation). For each, list: example controls, typical evidence, and implementation difficulty."
Map current controls to SOC 2 requirements
If you have existing security controls:
"We currently have: [list tools, policies, procedures like: Okta for SSO, AWS CloudTrail logging, incident response plan, quarterly access reviews]. Map these to SOC 2 Common Criteria. Which control objectives do we already meet? What gaps exist? What additional evidence collection is needed?"
Identify documentation gaps
Upload existing policies for gap analysis:
Upload your security policies, procedures, and documentation (PDF, DOCX)
Ask: "Review these policies against SOC 2 requirements. Identify: missing policies, incomplete procedures, weak areas requiring enhancement, and controls without documented procedures. Prioritize by audit criticality."
Common gap: Organizations often have controls implemented (e.g., MFA enabled) but lack documented policies and procedures describing HOW controls operate. SOC 2 auditors require both implementation AND documentation.
Step 3: Define your system description
What is a system description?
Your SOC 2 report begins with a system description that defines:
Services provided to customers
System components (infrastructure, software, people, procedures, data)
System boundaries and interfaces
Principal service commitments and system requirements
Create system description with AI
Ask ISMS Copilot to draft your system description:
"Create a SOC 2 system description for our [type of service]. Include: overview of services provided, infrastructure components (we use [AWS/Azure/GCP]), key personnel and their roles, data flows, third-party services integrated, and our commitments to customers regarding [uptime, data protection, etc.]. Format according to SOC 2 requirements."
Refine with specifics:
"Enhance this system description with: network architecture details (we have [VPC, subnets, security groups]), data storage and encryption approach, authentication and authorization model, monitoring and logging infrastructure, backup and disaster recovery capabilities. Make it specific to our actual implementation."
Document principal service commitments
Define what you promise customers:
"Based on our customer agreements and SLAs, document our principal service commitments for SOC 2. We promise: [uptime percentage, response times, data protection, encryption, access controls, incident notification]. For each commitment, identify which SOC 2 controls demonstrate we fulfill it."
Step 4: Implement required policies and procedures
Core policy requirements
SOC 2 requires comprehensive security policies. Generate them systematically:
Information Security Policy
"Create a SOC 2-compliant Information Security Policy covering: policy purpose and scope, management commitment, roles and responsibilities, acceptable use, data classification, incident response, physical and environmental security, access control principles, and policy review process. Context: [company description]."
Access Control Policy
"Create an Access Control Policy for SOC 2 including: user provisioning procedures, least privilege principle, role-based access control, authentication requirements (MFA), password standards, access review frequency, privileged access management, termination procedures, and remote access. We use [your IAM tools]."
Change Management Policy
"Create a Change Management Policy for SOC 2 covering: change request process, risk assessment for changes, approval workflows, testing requirements, rollback procedures, change documentation, emergency change process, and post-implementation review. We use [your development/deployment tools]."
Incident Response Plan
"Create an Incident Response Plan for SOC 2 including: incident classification and severity levels, detection and reporting procedures, response team roles, containment and eradication steps, recovery procedures, communication protocols (internal and customer notification), and post-incident review. Include timelines for each severity level."
Risk Assessment Procedure
"Create a Risk Assessment Procedure for SOC 2 including: risk assessment frequency (at least annually), risk identification methodology, likelihood and impact criteria, risk scoring approach, risk treatment options, risk owner assignment, and documentation requirements."
Additional procedures based on scope
Depending on your Trust Services Criteria:
"For SOC 2 with [Availability/Processing Integrity/Confidentiality/Privacy] criteria, what additional policies and procedures are required beyond Security? For each criterion, provide: mandatory procedures, content requirements, and typical evidence auditors request."
Step 5: Implement technical and operational controls
Access controls (CC6)
Critical for SOC 2 compliance. Assess and implement:
"For SOC 2 logical access controls, we need to implement: user provisioning/deprovisioning, multi-factor authentication, password complexity, session timeouts, and quarterly access reviews. We currently use [tools]. Provide: implementation steps, configuration requirements, evidence to collect (logs, reports), and common audit questions."
Logging and monitoring (CC7)
Essential for Type II evidence:
"What logging and monitoring is required for SOC 2? We use [cloud provider, applications]. For each system in scope, specify: what events to log, log retention period (typically 1 year), who reviews logs and how often, alerting requirements, and what reports to generate for audit evidence."
Critical for Type II: You must collect logs and evidence for the ENTIRE audit period (3-12 months). Start logging immediately—you cannot retroactively create historical evidence. Missing logs = automatic control failure.
Change management (CC8)
Document your development and deployment process:
"We deploy code using [CI/CD tools, process]. For SOC 2 change management compliance, help us document: how changes are requested and approved, testing procedures (we do [testing approach]), deployment process, how we track changes (we use [ticketing system]), and rollback capabilities. What evidence demonstrates this process was followed?"
Vulnerability management (CC7)
Implement scanning and patching:
"For SOC 2 vulnerability management, we need to: scan for vulnerabilities regularly, prioritize based on severity, patch critical findings timely. We can use [tools in budget]. Recommend: scanning frequency, acceptable remediation timeframes by severity, how to document exceptions, and what reports to keep for audit."
Backup and recovery (CC7, Availability)
Prove you can recover from incidents:
"For SOC 2 backup and disaster recovery, define: backup frequency (we can do [daily/hourly]), backup testing schedule (quarterly?), recovery time objective (RTO) and recovery point objective (RPO) targets, offsite backup storage, and restoration testing documentation. We use [backup solution]."
Step 6: Establish evidence collection processes
Understand evidence types
SOC 2 Type II requires evidence of control operation:
"For each SOC 2 Common Criteria control category (CC1-CC9), what evidence will auditors request for a Type II audit? For each evidence type, specify: what it proves, how to collect it, collection frequency, and where to store it for audit access."
Create evidence collection calendar
Automate evidence gathering:
"Create a SOC 2 evidence collection calendar for a [audit period length] audit period. Include: monthly evidence (access reviews, vulnerability scans), quarterly evidence (security awareness training, disaster recovery tests), annual evidence (penetration testing, policy reviews), and continuous evidence (change tickets, incident reports, system logs). Assign responsible parties."
Common evidence requirements
Build your evidence repository:
Control area  | Typical evidence  | Collection frequency  | 
|---|---|---|
Access provisioning  | New hire tickets, approval emails, access logs  | As they occur  | 
Access reviews  | User access reports, review sign-offs, remediation tickets  | Quarterly  | 
Access termination  | Termination tickets, access removal confirmations  | As they occur  | 
Change management  | Change tickets, approvals, test results, deployment logs  | Per change  | 
Vulnerability scanning  | Scan reports, remediation tracking, exception approvals  | Monthly/quarterly  | 
Security training  | Training completion reports, acknowledgment forms  | Annually + new hires  | 
Backup testing  | Backup logs, restoration test results, sign-offs  | Quarterly  | 
Incident response  | Incident tickets, response timelines, resolution documentation  | As they occur  | 
Pro tip: Create a shared folder structure (Google Drive, SharePoint) organized by control category. Collect evidence continuously rather than scrambling during the audit. This reduces audit preparation from weeks to days.
Step 7: Conduct internal readiness review
Self-assess control implementation
Before engaging an auditor, validate readiness:
"Create a SOC 2 internal audit checklist for self-assessment before the formal audit. For each Common Criteria control category (CC1-CC9), provide: control objective, what to test, what evidence to review, pass/fail criteria, and common deficiencies. Include testing procedures suitable for non-auditors."
Test controls are operating
Don't just check if controls exist—verify they work:
"For these SOC 2 controls [access reviews, change management, vulnerability patching, backup testing], provide testing procedures to verify they operated effectively during our audit period. For each: sample size recommendations, what to look for, red flags indicating control failures, and remediation steps if gaps found."
Review evidence completeness
Audit your evidence repository:
"We collected evidence for our SOC 2 Type II audit period [dates]. Review this evidence inventory [upload or describe]. Identify: missing evidence, gaps in coverage, evidence that doesn't prove the control, weak evidence needing supplementation, and evidence organization improvements. What will auditors question?"
Common readiness failure: Controls are implemented but evidence is incomplete, poorly organized, or doesn't clearly demonstrate control operation. Auditors cannot "assume" controls work—they need explicit proof.
Step 8: Select and engage your auditor
Understand auditor selection criteria
Ask for guidance on choosing an auditor:
"What should we consider when selecting a SOC 2 auditor? Include: qualifications to verify (CPA license, AICPA membership), industry experience in [our sector], pricing models, timeline expectations, reputation considerations, and questions to ask during auditor selection. What are red flags?"
Prepare for initial auditor meeting
Make a strong first impression:
"We're meeting with potential SOC 2 auditors. Create a readiness presentation including: company overview, services in scope, system description summary, Trust Services Criteria we're pursuing, audit period, current control maturity, evidence collection status, timeline expectations, and key questions for the auditor. Make it professional and audit-ready."
Understand the audit process
Know what to expect:
"Walk me through the SOC 2 Type [I/II] audit process from engagement to report issuance. Include: kickoff meeting, planning phase, testing phase, management representation letter, draft report review, final report delivery, typical duration for each phase, and our responsibilities during each phase."
Step 9: Prepare for common audit challenges
Scoping questions
Auditors will challenge your scope definition:
"What questions will SOC 2 auditors ask about our system scope and boundaries? For a [service type] company using [infrastructure], what scoping debates are common? How do we justify: excluding certain systems, relying on subservice organization reports (AWS SOC 2), or defining 'in-scope' vs 'out-of-scope' components?"
Control design challenges
Prepare for pushback on control adequacy:
"For these controls [list controls you're concerned about], what questions will auditors ask to test if they're 'suitably designed'? What makes a control design insufficient? Provide examples of control enhancements that address common auditor concerns."
Operating effectiveness evidence
Type II audits test consistent operation:
"Auditors will sample our evidence to test operating effectiveness. For [access reviews, change tickets, vulnerability remediation], what sample sizes do auditors typically test? What constitutes a control exception? How many exceptions cause control failure? How do we respond to identified exceptions?"
Pro tip: Auditors typically sample 25-40 instances per control for annual audits. If you have 4 access reviews during the period, ALL 4 will be tested. Plan to have documentation for 100% of control instances, not just samples.
Step 10: Handle findings and remediation
Understand finding types
Not all findings are equal:
"Explain SOC 2 audit finding classifications: control deficiencies, significant deficiencies, and material weaknesses. For each, provide: definition, example scenarios, impact on SOC 2 report opinion, and remediation urgency. What findings can be accepted vs. must be fixed?"
Respond to draft findings
When auditors identify issues:
"Auditors identified these draft findings [describe findings]. For each, help us: understand the root cause, assess severity, develop remediation plan, determine if we can provide additional evidence to resolve the finding, draft management response for the audit report, and prevent recurrence. What responses are auditor-acceptable?"
Remediate before report issuance
Fix what you can during the audit:
"We have [timeline] before audit report issuance. These findings were identified [list findings]. Which can be remediated in time to remove from the report? Which must be disclosed as deficiencies? For remediable findings, provide: quick remediation steps, evidence to demonstrate fix, and how to communicate remediation to the auditor."
Common SOC 2 preparation mistakes
Mistake 1: Starting evidence collection too late - Beginning evidence gathering weeks before the audit. Solution: Start collecting evidence from day one of your audit period. For Type II, you need 3-12 months of evidence—it cannot be created retroactively.
Mistake 2: Implementing controls without documentation - Having controls in place but no written procedures. Solution: Document EVERYTHING. Ask: "For each control, do we have a policy/procedure that describes how it works? Where is it documented? Can a new employee understand it?"
Mistake 3: Assuming cloud provider controls = your controls - Believing AWS/Azure security absolves you of responsibility. Solution: Understand the shared responsibility model. Ask: "Which SOC 2 controls can we inherit from our cloud provider's SOC 2 report (complementary subservice organization)? Which controls are our responsibility regardless of cloud provider?"
Mistake 4: Poor evidence organization - Collecting evidence but storing it chaotically. Solution: Create a structured evidence repository from day one: "Design a folder structure for SOC 2 evidence organized by: Trust Services Criteria, control category, evidence type, and time period. Include naming conventions."
Next steps after audit preparation
You've now prepared for your SOC 2 audit:
✓ Report type and scope defined
✓ Readiness assessment completed
✓ System description documented
✓ Policies and procedures implemented
✓ Technical controls deployed
✓ Evidence collection processes established
✓ Internal readiness review conducted
✓ Auditor selected and engaged
Maintain ongoing compliance:
Continue evidence collection throughout audit period
Conduct quarterly self-assessments to catch issues early
Update policies and procedures as your environment changes
Plan for annual SOC 2 renewal at least 90 days before expiration
Getting help
Upload documents: Learn how to upload and analyze files for policy gap analysis
Verify outputs: Understand how to prevent AI hallucinations when reviewing audit preparation guidance
Best practices: Review how to use ISMS Copilot responsibly for audit-ready documentation
Start your SOC 2 preparation today: Create your workspace at chat.ismscopilot.com and begin your readiness assessment in under an hour.