A successful SOC 2 audit does not begin the week your auditor arrives. It begins months earlier, with deliberate planning, cross-functional coordination, and systematic evidence collection. Organisations that treat audit preparation as a project — with clear milestones, ownership, and tooling — consistently achieve cleaner reports and spend less time in remediation cycles.
This guide walks through every stage of SOC 2 audit preparation, from understanding what actually happens during the audit to managing costs, selecting the right auditor, and avoiding the most common pitfalls that delay or derail the process.
What is a SOC 2 audit?
A SOC 2 audit is a formal examination of your organisation’s controls related to security, availability, processing integrity, confidentiality, and privacy — known collectively as the Trust Service Criteria (TSC). The audit is conducted by an independent CPA (Certified Public Accountant) firm and results in a SOC 2 report that your customers, prospects, and partners use to evaluate your security posture.
There are two types of SOC 2 report. A Type 1 report evaluates whether your controls are properly designed at a specific point in time. A Type 2 report evaluates both the design and the operating effectiveness of those controls over a defined observation period, typically between 3 and 12 months.
The key parties involved in a SOC 2 audit are:
- Your organisation — the service organisation being audited
- The auditor — a licensed CPA firm that examines your controls and issues the report
- Your customers — the user entities who rely on the report to assess risk
- Subservice organisations — third-party vendors whose services are part of your control environment (cloud providers, payroll systems, etc.)
The auditor’s job is not to tell you what controls to implement. Their role is to independently assess whether the controls you have in place meet the Trust Service Criteria you have selected. This distinction matters: you define the scope and the controls, and the auditor evaluates them.
SOC 2 audit timeline
Timelines vary based on your organisation’s size, existing security maturity, and whether you are pursuing a Type 1 or Type 2 report. The following is a realistic month-by-month breakdown for an organisation starting from a moderate security baseline.
Type 1 timeline (3 to 6 months)
Months 1 to 2 — Scoping and gap assessment. Define which Trust Service Criteria are in scope. Most organisations start with Security (the Common Criteria), which is required, and add Availability or Confidentiality based on customer requirements. Conduct a gap assessment against the selected criteria to identify missing controls, undocumented processes, and areas requiring remediation.
Months 2 to 4 — Remediation and control implementation. Close the gaps identified in your assessment. This typically involves writing or updating policies (information security policy, acceptable use policy, incident response plan, etc.), configuring technical controls (encryption, access management, logging), and establishing operational procedures (change management, vendor reviews, employee onboarding). Document everything as you go — the documentation is itself part of the evidence.
Months 4 to 5 — Evidence collection and internal review. Gather evidence that demonstrates your controls are properly designed. Conduct an internal readiness review or engage your auditor for a formal readiness assessment. Address any remaining gaps before the audit begins.
Months 5 to 6 — Type 1 audit. The auditor examines your controls at a single point in time. This typically takes 2 to 4 weeks of active engagement, including document review, walkthroughs, and testing.
Type 2 timeline (9 to 15 months)
A Type 2 audit follows the same preparation steps as Type 1 but adds an observation period during which your controls must be operating effectively.
Months 1 to 4 — Preparation (same as Type 1 above).
Months 5 to 10 — Observation period. Your controls must be in operation and generating evidence continuously. The standard observation period is 6 months for a first-time Type 2, though some organisations opt for a 3-month window to get their initial report faster. During this period, you must consistently follow your documented procedures — any lapses during the observation window will be flagged.
Months 10 to 12 — Type 2 audit. The auditor reviews evidence from the entire observation period, conducts sample testing, and evaluates operating effectiveness. This phase typically takes 3 to 6 weeks.
Many organisations pursue a Type 1 first to demonstrate initial compliance to customers, then transition to Type 2 for subsequent audits. This is a pragmatic approach that balances speed-to-market with long-term rigour.
How much does a SOC 2 audit cost?
SOC 2 costs are often underestimated because organisations focus on auditor fees alone. The true cost includes four components.
Auditor fees
This is the direct cost of engaging the CPA firm. Expect to pay:
- Type 1 audit: £15,000 to £40,000
- Type 2 audit: £25,000 to £80,000
Fees vary based on scope (number of Trust Service Criteria), organisation size, system complexity, and the auditor’s experience. Large firms with recognisable names charge more but may carry additional weight with enterprise customers.
Compliance tooling
Manual compliance management using spreadsheets, shared drives, and email threads is technically possible but dramatically increases internal time costs and error rates. Most organisations invest in a compliance automation platform, which typically costs £10,000 to £50,000 per year depending on the vendor and feature set. This tooling pays for itself through reduced preparation time, automated evidence collection, and continuous monitoring.
Internal staff time
This is often the largest hidden cost. Audit preparation requires significant time from multiple team members: the compliance lead, engineering, IT, HR, and legal. For a first-time audit, expect 200 to 500 hours of internal effort spread across the organisation. At fully loaded employee costs, this can easily represent £30,000 to £100,000 in opportunity cost.
Remediation costs
If your gap assessment reveals significant deficiencies — missing endpoint protection, no formal change management process, inadequate access controls — remediation can add substantial costs. Budget for potential investments in security tooling, infrastructure changes, and process development. Remediation costs range from negligible (for mature organisations) to £50,000 or more (for organisations building foundational controls from scratch).
Total cost by company size
- Startup (10 to 50 employees, narrow scope): £30,000 to £60,000
- Mid-market (50 to 500 employees, moderate scope): £60,000 to £120,000
- Enterprise (500+ employees, broad scope): £100,000 to £250,000+
These ranges assume a Type 2 audit inclusive of tooling, internal time, and auditor fees. Type 1 audits fall at the lower end of each range.
How to choose a SOC 2 auditor
Your choice of auditor affects the quality of the engagement, the credibility of the report, and your team’s experience throughout the process. Not all CPA firms are equal in their SOC 2 expertise.
What to look for
SOC 2 specialism. Look for firms that conduct SOC 2 audits as a primary service line, not an afterthought. Ask how many SOC 2 engagements they complete per year. Firms with high volume develop standardised processes that make the audit smoother for you.
Industry experience. An auditor who has worked with organisations similar to yours will understand your technology stack, common control configurations, and typical risk areas. Ask for references from companies in your sector.
Communication style. The audit process involves regular back-and-forth. Choose a firm that communicates clearly, responds promptly, and assigns a consistent engagement team rather than rotating staff.
Peer review results. CPA firms that perform SOC engagements are required to undergo peer reviews. Ask to see the firm’s most recent peer review results. A clean peer review is a baseline expectation.
Questions to ask prospective auditors
- How many SOC 2 engagements does your firm complete annually?
- Who will be the engagement lead, and what is their SOC 2 experience?
- What is your expected timeline from kickoff to report delivery?
- How do you handle evidence requests — portal, email, or shared drive?
- What compliance platforms do you integrate with?
- Can you provide references from organisations of similar size and industry?
- What is included in your fee, and what triggers additional charges?
Red flags
- Firms that guarantee a “clean” report before the audit begins
- Unusually low fees that suggest inexperience or corners being cut
- No dedicated SOC 2 practice or limited engagement volume
- Inability to provide recent client references
- Inflexibility on observation period length or scope discussions
Preparing your team
SOC 2 is not a solo effort. It requires coordinated participation from multiple functions. Define roles and responsibilities early to avoid bottlenecks during evidence collection and auditor walkthroughs.
Compliance lead. This person owns the project. They coordinate between internal teams and the auditor, manage the evidence collection process, track remediation items, and serve as the primary point of contact. In smaller organisations, this role often falls to a Head of Security, VP of Engineering, or Operations lead.
Engineering and IT. Responsible for implementing and maintaining technical controls: access management, encryption, logging, monitoring, change management, and infrastructure security. Engineering is typically the team most impacted by evidence requests, so early involvement prevents friction later.
Human Resources. HR owns controls related to employee lifecycle: background checks, onboarding procedures, security awareness training, acceptable use policy acknowledgement, and offboarding processes. Auditors will sample HR records, so these processes must be documented and consistently followed.
Legal. Reviews and maintains contracts, data processing agreements, privacy policies, and terms of service. Legal input is particularly important if Privacy or Confidentiality criteria are in scope.
Executive sponsor. A senior leader (CTO, CISO, or CEO) who champions the audit effort, removes blockers, allocates budget, and ensures cross-functional cooperation. Without executive sponsorship, compliance initiatives stall when they compete with product priorities.
Hold a kickoff meeting with all stakeholders at the beginning of the preparation process. Set clear expectations for time commitments, evidence deadlines, and escalation paths. Schedule regular check-ins throughout the preparation period — fortnightly is a good cadence — to track progress and resolve issues before they compound.
Evidence collection
Evidence is the substance of a SOC 2 audit. Your controls may be well designed and effectively operated, but if you cannot demonstrate that through evidence, the auditor has no basis for a favourable opinion.
What auditors look for
Auditors need evidence that each in-scope control is both designed appropriately and (for Type 2) operating effectively over the observation period. Evidence falls into several categories:
Policies and procedures. Written documents that define your organisation’s approach to security, access management, incident response, change management, data handling, vendor management, and employee conduct. These must be formally approved, version-controlled, and communicated to relevant staff.
System configurations. Screenshots or exports showing that technical controls are properly configured: firewall rules, encryption settings, access control lists, logging configurations, backup schedules, and monitoring alerts.
Access control records. Evidence of who has access to what systems, how access is granted and revoked, and regular access reviews. Auditors will look for role-based access, least privilege enforcement, and timely deprovisioning when employees leave.
Change management records. Tickets, pull requests, or change records showing that changes to production systems follow a defined process: approval, testing, review, and deployment. Auditors often sample 25 to 50 changes from the observation period.
Incident documentation. Records of security incidents, including detection, response, resolution, and post-incident review. Even if no significant incidents occurred, auditors want to see that your incident response process is documented and tested.
Monitoring and logging. Evidence that systems are monitored, logs are retained for an appropriate period, and alerts are configured for security-relevant events. Auditors may request log samples or monitoring dashboard screenshots.
Vendor assessments. Documentation of your third-party risk management process, including vendor inventories, risk assessments, and due diligence records for critical subservice organisations.
Training records. Evidence that employees complete security awareness training, acknowledge policies, and receive role-specific training where applicable.
Evidence management best practices
Centralise your evidence. Store all audit evidence in a single system rather than scattered across email threads, shared drives, and individual laptops. A compliance platform with evidence management capabilities eliminates the chaos of last-minute evidence gathering.
Collect continuously. Do not wait until the audit to collect evidence. Set up automated evidence collection where possible (system configuration snapshots, access reviews, training completion records) and establish a regular cadence for manual evidence (policy reviews, vendor assessments).
Timestamp everything. Auditors need to verify that evidence corresponds to the correct time period. Ensure screenshots include dates, logs have timestamps, and policy documents show approval dates and version history.
Organise by control. Map your evidence to specific controls and Trust Service Criteria. When the auditor requests evidence for a particular control, you should be able to retrieve it immediately rather than searching through unstructured folders.
Maintain a chain of custody. Track who collected each piece of evidence, when it was collected, and where it is stored. This is particularly important for evidence that involves sensitive data or system access.
Common audit findings
Understanding the most frequently flagged issues helps you address them proactively rather than scrambling during the audit.
Incomplete or outdated policies. Policies that have not been reviewed in over a year, lack formal approval, or do not reflect current practices. Auditors compare what your policies say against what your systems and processes actually do. Inconsistencies result in exceptions.
Access control gaps. Former employees with active accounts, shared credentials, excessive privileges, or missing multi-factor authentication. Access control is one of the most heavily tested areas in any SOC 2 audit. Conduct thorough access reviews before the audit begins.
Insufficient change management. Changes deployed to production without documented approval, peer review, or testing. Even if your team follows a rigorous process informally, the auditor needs documented evidence. Ensure your ticketing system or version control platform captures the full change lifecycle.
Missing or incomplete risk assessments. SOC 2 requires a formal risk assessment process. Many organisations either skip this step or conduct it superficially. Your risk assessment should identify threats and vulnerabilities, evaluate likelihood and impact, and document how identified risks are mitigated.
Gaps in vendor management. Failing to assess the security posture of critical third-party vendors. If your application runs on AWS and processes payments through Stripe, auditors expect to see evidence that you have evaluated these vendors’ security practices and obtained their SOC 2 reports.
Inadequate monitoring and alerting. Systems without centralised logging, missing alerts for critical security events, or log retention periods that do not cover the observation window. Ensure your logging and monitoring infrastructure is in place and operational well before the observation period begins.
Inconsistent employee onboarding and offboarding. Missing background checks, unsigned policy acknowledgements, or delayed access revocation for departing employees. Auditors sample employee records and expect consistency across all hires during the observation period.
The audit day
The phrase “audit day” is somewhat misleading — a SOC 2 audit is typically conducted over several weeks rather than a single day. However, there are periods of intense interaction with the auditor that benefit from preparation.
Kickoff meeting. The auditor will hold an initial meeting to confirm scope, review the system description, discuss the timeline, and identify key contacts for each control area. Attend this meeting with your full audit team.
Evidence submission. The auditor will issue a request list (often called a PBC — Prepared by Client — list) detailing every piece of evidence they need. Respond promptly and completely. Incomplete submissions generate follow-up requests that extend the timeline and frustrate both sides.
Walkthroughs. Auditors will schedule walkthroughs with control owners to understand how specific processes work. These are conversations, not interrogations. The goal is for the auditor to understand the control, observe it in operation, and confirm that it matches the documented procedure. Prepare control owners by reviewing what they will be asked about and ensuring they can demonstrate the process.
Sample testing. For Type 2 audits, the auditor will select samples from the observation period — a set of changes deployed, employees onboarded, access reviews completed, incidents responded to — and request evidence for each. Ensure your records are complete for the entire observation period, not just the recent weeks.
Management representation letter. At the end of the audit, your management will be asked to sign a representation letter confirming the accuracy of information provided to the auditor. This is a standard part of the process.
Managing auditor requests efficiently
Designate a single point of contact to coordinate all auditor communications. This prevents duplicate responses, conflicting information, and requests falling through the cracks. Use a shared tracker to log every request, assign ownership, and monitor response status. Set internal deadlines that are 2 to 3 days ahead of the auditor’s deadlines to build in buffer time.
After the audit
Receiving your report
The auditor will issue a draft report for your review before finalising. Review the system description carefully — it describes your environment and controls in detail, and inaccuracies should be corrected. The final report includes the auditor’s opinion, the system description, the controls tested, and any exceptions identified.
An unqualified opinion means the auditor found your controls to be suitably designed and (for Type 2) operating effectively. This is the outcome you want.
A qualified opinion means the auditor identified one or more significant issues. This does not make the report useless, but it raises questions from customers reviewing it.
An adverse opinion indicates pervasive control failures. This is rare and typically signals that the organisation was not ready for the audit.
Handling exceptions
Individual control exceptions — instances where a specific control did not operate as designed — are common even in otherwise clean reports. A handful of exceptions does not result in a qualified opinion. However, you should:
- Understand the root cause of each exception
- Implement corrective actions before the next audit cycle
- Document the remediation steps taken
- Consider whether the exception indicates a systemic issue rather than an isolated failure
Planning for renewal
SOC 2 is not a one-time achievement. Reports are valid for 12 months, and customers expect a current report. Begin planning your renewal audit at least 3 months before your current report expires. Use findings from the previous audit to prioritise improvements, update your control environment, and refine your evidence collection processes.
Establish a continuous compliance posture rather than treating each audit as a discrete project. Organisations that monitor their controls year-round, collect evidence automatically, and address issues as they arise spend a fraction of the time on audit preparation compared to those that scramble in the weeks before the auditor arrives.
How automation reduces audit prep time
The most time-consuming aspects of SOC 2 preparation — evidence collection, control monitoring, policy management, and vendor tracking — are highly repetitive and well suited to automation. Organisations that rely on manual processes typically spend 300 to 500 hours on audit preparation. With a compliance automation platform, that figure drops to 50 to 100 hours.
Automation delivers value in several specific areas:
Continuous evidence collection. Rather than taking manual screenshots and downloading reports before the audit, automated platforms pull evidence from your infrastructure, identity providers, version control systems, and HR tools on an ongoing basis. When the auditor requests evidence, it is already collected, timestamped, and organised.
Control monitoring. Automated checks continuously verify that controls are operating as designed: MFA is enabled, encryption is active, access reviews are current, and configurations have not drifted. When a control falls out of compliance, you are alerted immediately rather than discovering the gap during the audit.
Policy management. Templates, version control, approval workflows, and employee acknowledgement tracking replace the manual process of drafting policies in word processors and chasing signatures via email.
Audit workflow. A structured workflow for managing auditor requests, tracking evidence submissions, and coordinating across teams replaces ad hoc email chains and spreadsheets.
Prova’s GRC platform is built specifically to streamline SOC 2 preparation. By connecting directly to your infrastructure and business systems, Prova automates evidence collection, monitors controls in real time, and provides a centralised workspace for managing the entire audit lifecycle — from initial gap assessment through to report delivery and renewal planning.
The result is not just faster preparation. It is a fundamentally different relationship with compliance — one where your SOC 2 posture is maintained continuously rather than reconstructed annually.