A SOC 2 audit does not begin on the day your auditor arrives. It begins months earlier, when you define your scope, select your Trust Services Criteria, and start building the evidence your auditor will review. This SOC 2 checklist covers every stage of that preparation — from the initial scoping decisions through to the audit itself — so you can approach the process with a clear plan rather than a growing list of last-minute findings.
What Is SOC 2 and Who Needs It?
SOC 2 — System and Organization Controls 2 — is an audit framework developed by the American Institute of Certified Public Accountants (AICPA) to assess how a service organization protects the data it processes on behalf of customers. It is not a certification in the way ISO 27001 is; it is an attestation, meaning an independent auditor issues a report confirming that your controls meet the relevant criteria.
You need a SOC 2 report when your customers — typically enterprises in financial services, healthcare, or technology — need independent evidence of your current compliance status. For financial institutions selling into US markets or to enterprise buyers, a SOC 2 Type 2 report has become a standard procurement requirement. Without one, deals stall.
A SOC 2 compliance checklist is a structured list of tasks, policies, controls, and documentation used to prepare for the audit.
Step 1: Decide Between Type 1 and Type 2
The first decision in any SOC 2 programme is which report type you are working toward, whether that is a Type 1 report or a type ii audit.
Type 1 is a point-in-time assessment. The auditor evaluates whether your controls are designed appropriately at a specific point as of a specific date. It does not assess whether those controls have been operating consistently over time. Type 1 is faster to obtain — typically two to four months of preparation — and is often suitable for early-stage companies that need quicker audit readiness or customer evidence.
Type 2 assesses both the design and the operational effectiveness of your controls over a defined observation period, usually six to twelve months. This type ii report is more comprehensive and often expected by enterprise clients because it provides more detailed information and reasonable assurance that your controls function effectively over time. Most organisations should plan for Type 2 from the outset, even if they obtain a Type 1 first.
The observation period for a Type 2 report starts running the day your controls are in place and operating. The sooner you stand up your controls, the sooner that clock starts for an ii audit.
Step 2: Define Your Scope
SOC 2 scope defines which systems, services, and data flows the audit scope will cover. Getting scope right is the most consequential early decision in the programme. Too broad, and you spend time and resource demonstrating controls on systems that do not matter to your customers. Too narrow, and your auditor will flag systems you missed.
Your scope should include every system that stores, processes, or transmits customer data, and the audit scope should reflect the service organization’s operations, relevant systems, locations, and the information processed. It should also cover supporting infrastructure — logging systems, identity management, ticketing — and any critical systems required to operate securely or process users data. Document the scope in a formal System Description: a written narrative of what is in scope, who operates it, and how customer data flows through it. Defining scope is also part of broader audit preparation and early compliance efforts.
Step 3: Select Your Trust Services Criteria
The AICPA defines five Trust Services Criteria (TSC) that align with industry standards: Security, Availability, Processing Integrity, Confidentiality, and Privacy. You must include at least one in every SOC 2 audit. Security — also called the Common Criteria — is mandatory in every report, is derived from the COSO framework, and acts as the baseline across industries. The other four are optional and should be selected based on your customer commitments and regulatory context.
Security (mandatory): Controls protecting against unauthorised access to systems and data. Covers logical access, change management, risk assessment, monitoring, incident response, and data protection. This is the foundation of every SOC 2 programme.
Availability: Controls ensuring your systems are available for operation and use as committed. Relevant if your customers depend on uptime guarantees or if your service level agreements include availability commitments.
Processing Integrity: Controls ensuring that system processing is complete, accurate, timely, and authorised. Most relevant for transaction processing systems, payroll platforms, or any service where data accuracy is a customer obligation.
Confidentiality: Controls protecting information designated as confidential. Relevant if you handle commercially sensitive data — intellectual property, financial projections, or data your contracts require you to keep confidential.
Privacy: Controls governing the collection, use, retention, disclosure, and disposal of personal information. Relevant if your service processes personal data and your customers or regulators expect privacy controls beyond the Security criteria; whether to include it depends on the services you provide and the nature of the user data you handle.
For most financial institutions, Security plus Availability and Confidentiality covers the criteria that enterprise buyers will scrutinise. Adding Privacy is worth considering if your programme overlaps with GDPR obligations — the control work is largely the same.
Step 4: Conduct a Readiness Assessment
Before you engage an auditor, conduct a readiness assessment — a gap analysis and self assessment that compares your current security efforts and controls against the Trust Services Criteria you have selected. The readiness assessment tells you what is missing, where security gaps exist, what exists but is not documented, and what is documented but not operating consistently.
The most common gaps Copla finds at this stage:
- Access reviews that happen informally but are not documented or timestamped
- Change management processes that work in practice but have no formal policy or ticket trail
- Vendor security assessments that were done once at onboarding and never repeated
- Incident response procedures that exist as a slide deck but have never been tested
- Logging that is enabled on production systems but not reviewed on any regular schedule
Each of these is a finding if it surfaces during the audit. Found during readiness, the findings feed a structured gap remediation process to remediate gaps before the actual audit, and some control gaps needing attention require updated workflows, training, or added control documentation before reassessment.
Step 5: Implement and Document Controls
SOC 2 does not prescribe which controls you must implement. It defines criteria your organisation must meet, and you decide how to meet them. That flexibility is genuine, but it means you must design and document the internal controls and security controls that satisfy those criteria, then explain and evidence how your auditor will test the organization’s controls using up-to-date control documentation.
The controls auditors focus on most consistently, mapped to the Common Criteria, are:
Access control and identity management (CC6): Every user account provisioned with the minimum access needed for their role; multi-factor authentication (MFA) enforced on all systems in scope; formal access review completed at least quarterly; joiners-movers-leavers process documented and evidenced. These access controls should be consistently applied across systems in scope.
Risk assessment (CC3): A documented risk assessment, updated at least annually, that identifies threats to in-scope systems, assesses likelihood and impact, and maps mitigating controls to each identified risk. Where gaps are identified, remediation may include workflow changes, employee training, and new control documentation.
Change management (CC8): A formal process for approving, testing, and deploying changes to in-scope systems, with a ticket or log entry for every change that links the change to an approver and a test outcome. A ticketing system can provide the change records, approvals, and testing evidence auditors review.
Monitoring and logging (CC7): Logs enabled across all in-scope systems; a process for reviewing logs for anomalous activity; documented responses to any alerts generated. Together, these support risk mitigation by helping teams detect and respond quickly.
Vendor risk management (CC9): An inventory of third party vendors with access to in-scope systems or data; a documented assessment of each vendor’s security posture; evidence of ongoing monitoring, not just point-in-time onboarding checks. Those reviews should address third party risk and help manage third party risk for vendors touching customer data or critical systems.
Incident response (CC7): A tested incident response plan; documented evidence of at least one tabletop exercise or live incident response during the observation period.
Business continuity and disaster recovery: Documented recovery time objectives (RTOs) and recovery point objectives (RPOs); evidence that backup and recovery procedures have been tested so essential business processes can continue.
Step 6: Select an Auditor
SOC 2 reports must be issued by a licensed CPA firm. The auditor must be independent — your consultancy partner cannot issue your report. When selecting an auditor, look for demonstrable experience with organisations of your size and complexity. Request references from comparable clients, compare fees, and confirm their expected timeline for the observation period and report issuance.
Engage your auditor before your observation period begins. An early conversation clarifies exactly what evidence they will request, which prevents the situation where you have been collecting the wrong artefacts for six months and improves audit readiness by aligning evidence expectations before fieldwork begins.
Step 7: Manage the Observation Period
For a Type 2 report, the observation period — typically six to twelve months — is where organizations demonstrate and maintain compliance, not just design controls. The controls you implemented in Step 5 must be operating consistently throughout this period. This means access reviews must run on schedule, change management tickets must be raised for every change, vendor assessments must happen as planned, and incidents must be logged and responded to according to your documented procedure.
Ongoing compliance depends on continuous monitoring, regular internal reviews, and keeping documentation up to date throughout the year so controls stay effective beyond the audit date.
The most common reason SOC 2 audits surface unexpected findings is that controls that were fully operational at the start of the observation period drifted during it. Someone left the team and their access was not revoked promptly. A change went through outside the normal process. A vendor review was skipped because the team was busy. These gaps compound over time, can weaken the control environment, and delay a clear view of your compliance status during fieldwork. Annual SOC 2 cycles make this a discipline to maintain compliance, not a one-time project.
Step 8: Prepare for Fieldwork
Auditor fieldwork is the stage of the audit process when your auditor reviews evidence and conducts walkthroughs. This typically runs over two to four weeks. You will need to provide:
- Evidence of controls operating throughout the observation period: access review logs, change tickets, incident records, vendor assessment reports, with documentation kept current and ready for the auditor
- Policy and procedure documentation for every control area in scope
- Walkthroughs of key systems and processes — the auditor will ask someone to demonstrate how a control works, not just confirm that a policy exists
- The System Description reviewed and approved by management
Organise your evidence collection in advance. An auditor who has to chase evidence generates a longer fieldwork period and a longer list of observations, while organised evidence collection makes the audit process more efficient during the actual audit.
Step 9: Review the Draft Report and Close Findings
Your auditor will issue a draft report before the final version. Review it carefully. Any exceptions — instances where a control was not operating effectively during the observation period — will appear here. You can provide management responses to exceptions, which become part of the final report. You cannot remove exceptions from the report, but a clear management response that explains the root cause and the remediation step demonstrates programme maturity.
A clean Type 2 report with no exceptions is the goal, but a report with minor exceptions and strong management responses is substantially more credible than no report at all.
Frequently Asked Questions
How long does SOC 2 compliance take?
For a Type 2 report, plan for twelve to eighteen months from the start of preparation to the final report. That includes two to four months of readiness and control implementation, six to twelve months of observation period, and two to four months of auditor fieldwork and report issuance. A Type 1 report can typically be obtained in three to six months.
Is SOC 2 mandatory?
SOC 2 is not a legal requirement. It is a market requirement. Enterprise customers — particularly in financial services, healthcare, and regulated industries — routinely require a SOC 2 Type 2 report as a condition of doing business. For service organisations selling into those markets, it is effectively mandatory.
What is the difference between SOC 2 and ISO 27001?
SOC 2 is an attestation framework developed by the AICPA, widely used in the United States and by organisations selling into US enterprise markets. ISO 27001 is a certifiable international standard with broader global recognition, particularly in Europe. The two frameworks overlap significantly in their control requirements, and organisations that build a strong SOC 2 programme will typically satisfy a substantial portion of ISO 27001 Annex A in the process. Many organisations also fold SOC 2 into a broader compliance program that spans multiple frameworks to reduce duplicated effort. Compliance Auditing helps verify that operations align with GDPR and other relevant cybersecurity frameworks alongside SOC 2 obligations.
How much does SOC 2 cost?
Costs vary significantly by scope and organisation size. Auditor fees for a Type 2 report typically range from €15,000 to €50,000. Internal preparation costs — staff time, tooling, consultancy — can match or exceed auditor fees, particularly for a first-time programme.
SOC 2 is demanding but the structure is predictable. Every finding that surfaces during an audit was, at some earlier point, a gap that could have been identified and closed. The organisations that move through their first SOC 2 programme most efficiently are those that treat the readiness assessment seriously, document their controls from the first day of the observation period, and maintain the discipline to operate those controls consistently for the months that follow.
How Copla Supports SOC 2 Compliance Programmes
We work with financial institutions and technology companies through every stage of the SOC 2 process. The engagement begins with a scoping workshop and readiness assessment — helping define audit scope, mapping your in-scope systems, identifying control gaps against the Trust Services Criteria you have selected, centralizing control documentation, and building the remediation plan before the observation period starts.
From there, we generate the policy and procedure documentation your auditor will review, populate your risk register and vendor assessment records in the Copla platform, and track control implementation across every criterion area. The platform also supports evidence collection and gives teams valuable insights into progress across the programme. During the observation period, we support the operational discipline that SOC 2 requires with continuous monitoring to help maintain compliance between annual audits: access review scheduling, change management process oversight, and incident response testing. We also manage the auditor relationship through fieldwork, which shortens the back-and-forth that typically extends the audit timeline.
Schedule a call with Copla to walk through how this would look for your team.
