Achieving SOC 2 compliance is one of the most important steps a service organisation can take to demonstrate trustworthiness to customers, partners, and prospects. But the process can feel overwhelming without a clear roadmap. This checklist breaks the entire SOC 2 compliance journey into 15 actionable steps across four phases, from initial scoping through to audit completion and ongoing compliance.
Whether you are pursuing SOC 2 for the first time or preparing for your annual renewal, this guide provides the practical detail you need at each stage. Every step explains what to do, why it matters, and how to approach it effectively. Use this as a working checklist to track progress, assign ownership, and ensure nothing falls through the cracks.
Phase 1: Scoping and Planning
The first phase establishes the foundation for your entire SOC 2 programme. Poor scoping is one of the most common reasons organisations face delays, scope creep, and unexpected costs during an audit. Investing time here pays dividends throughout every subsequent phase.
Step 1: Define your compliance objectives
Before diving into technical controls, clarify why your organisation is pursuing SOC 2 and what you intend to achieve. Common drivers include satisfying customer contractual requirements, entering new markets, reducing sales cycle friction, or strengthening your overall security posture. Your objectives directly influence decisions about report type, scope, and timeline.
Document your objectives in a formal compliance programme charter. This should include the business rationale, target completion date, budget constraints, and executive sponsor. Share it with leadership to secure buy-in early. Organisations that treat SOC 2 as a top-down initiative rather than a purely technical exercise consistently achieve faster, smoother audits. Without clear objectives, teams often over-scope the audit, wasting time and resources on controls that do not align with business needs.
Step 2: Select your SOC 2 report type
SOC 2 offers two report types, and selecting the right one depends on your maturity and timeline. A Type 1 report evaluates the design of your controls at a specific point in time. A Type 2 report evaluates both design and operating effectiveness over a period, typically three to twelve months. Type 2 carries significantly more weight with enterprise buyers and is generally the standard expectation.
If your organisation is pursuing SOC 2 for the first time and has limited existing controls, consider starting with a Type 1 to validate your control design before committing to a Type 2 observation period. If you already have mature security practices, you may skip directly to Type 2. Document this decision along with the rationale, target observation period (for Type 2), and expected audit window. This decision shapes your entire project timeline and resource plan.
Step 3: Determine which Trust Service Criteria are in scope
SOC 2 is built around five Trust Service Criteria (TSC): Security, Availability, Processing Integrity, Confidentiality, and Privacy. Security (also known as the Common Criteria) is mandatory for every SOC 2 report. The remaining four are optional and should be included based on customer requirements, the nature of your service, and the types of data you handle.
Review your customer contracts and RFP responses to identify which criteria prospects and customers expect. If you process personal data, Privacy is likely in scope. If your service has uptime SLAs, include Availability. If you perform data transformations or calculations, Processing Integrity is relevant. Start with Security alone if you are new to SOC 2, then expand scope in subsequent audit cycles. Each additional criterion adds controls, evidence requirements, and audit cost, so scope deliberately rather than broadly.
Step 4: Identify systems and data flows in scope
Map every system, application, infrastructure component, and data flow that touches the services covered by your SOC 2 report. This includes cloud environments (AWS, Azure, GCP), SaaS tools (identity providers, monitoring platforms, ticketing systems), databases, CI/CD pipelines, and any third-party integrations that process or store customer data.
Create a formal system inventory that includes each component’s name, owner, purpose, data classification, and hosting location. Then map the data flows between these systems to understand how customer data enters, moves through, and exits your environment. This exercise frequently reveals shadow IT, undocumented integrations, or forgotten legacy systems that must either be brought into scope or formally decommissioned. Your auditor will request this inventory, so building it early ensures accuracy and avoids last-minute surprises during the audit itself.
Step 5: Assign internal stakeholders and owners
SOC 2 compliance requires coordination across engineering, IT, HR, legal, and executive leadership. Assign a compliance programme owner who is responsible for driving the initiative end to end. Then identify control owners for each domain: access management, change management, incident response, vendor management, human resources, and physical security.
Create a RACI matrix (Responsible, Accountable, Consulted, Informed) that maps each control area to specific individuals. Hold a kickoff meeting to communicate the project scope, timeline, and each person’s responsibilities. Establish a regular cadence of check-ins, whether weekly or fortnightly, to track progress and surface blockers. Organisations that distribute ownership broadly and hold individuals accountable for their control areas consistently outperform those that centralise all compliance work in a single person or team. Shared ownership also builds institutional knowledge that makes renewal audits significantly easier.
Phase 2: Gap Assessment and Remediation
With your scope defined and stakeholders aligned, the second phase focuses on understanding where you stand today and closing the gaps. This is typically the most labour-intensive phase, but it is also where you make the most meaningful security improvements.
Step 6: Conduct a gap analysis against SOC 2 requirements
Perform a systematic assessment of your current controls against the SOC 2 Trust Service Criteria you have selected. For each criterion, evaluate whether you have a control in place, whether it is documented, whether evidence exists to prove it operates effectively, and whether there are any gaps or weaknesses. Use the AICPA’s Trust Service Criteria framework (TSP Section 100) as your reference.
A thorough gap analysis should cover access controls (logical and physical), change management processes, incident response procedures, risk assessment practices, encryption standards, logging and monitoring, vendor management, HR policies (background checks, onboarding, offboarding), and business continuity planning. Document each finding with a severity rating (critical, high, medium, low), the current state, the desired state, and the remediation effort required. A GRC platform like Prova can automate much of this mapping by pre-loading SOC 2 control requirements and tracking your progress against them.
Step 7: Build a remediation roadmap with timelines
Transform your gap analysis findings into a prioritised remediation roadmap. Start with critical and high-severity gaps that represent fundamental control deficiencies, then address medium and low items. Each remediation item should have a clear owner, a target completion date, defined acceptance criteria, and any dependencies on other workstreams.
Group related items into workstreams where possible. For example, access control remediation might include implementing single sign-on (SSO), enforcing multi-factor authentication (MFA), establishing quarterly access reviews, and documenting your access control policy. Sequence these logically so that foundational work (such as deploying an identity provider) precedes dependent tasks (such as enforcing SSO across all applications). Build buffer into your timeline for unexpected complications. Most organisations underestimate remediation timelines by 30 to 50 percent, particularly for tasks that require cross-functional coordination or procurement of new tools.
Step 8: Implement missing controls
Execute your remediation roadmap by deploying the technical, administrative, and physical controls identified during the gap analysis. Technical controls typically include configuring MFA on all critical systems, enabling encryption at rest and in transit (TLS 1.2 or higher, AES-256), deploying centralised logging to a SIEM or log management platform, implementing automated vulnerability scanning, and establishing infrastructure-as-code practices with peer-reviewed change management.
Administrative controls include formalising onboarding and offboarding checklists, conducting background checks on new hires, running regular security awareness training, and establishing a vendor risk management programme. Physical controls, even for cloud-native organisations, may include securing office spaces, managing visitor access, and ensuring endpoint security on employee devices. For each control, ensure you can articulate how it maps to a specific SOC 2 criterion, how it will be monitored on an ongoing basis, and what evidence it produces. Controls that do not generate evidence are effectively invisible to your auditor.
Step 9: Document all policies and procedures
SOC 2 auditors expect to see formally documented policies and procedures that describe how your organisation manages security and operations. At a minimum, you need an Information Security Policy, Access Control Policy, Change Management Policy, Incident Response Plan, Risk Assessment Policy, Data Classification and Handling Policy, Acceptable Use Policy, Business Continuity and Disaster Recovery Plan, Vendor Management Policy, and Human Resources Security Policy.
Each policy should include a clear purpose statement, scope, defined roles and responsibilities, specific requirements, enforcement mechanisms, and a review cadence (typically annual). Procedures should provide step-by-step operational guidance that staff can follow. Critically, policies must reflect your actual practices rather than aspirational goals. Auditors will compare your documented policies against observed controls and evidence, and any disconnect between the two will result in findings. Store all policies in a centralised, version-controlled repository so you can demonstrate review history and approval workflows. Date and version-stamp every document.
Phase 3: Evidence Collection and Testing
The third phase ensures your controls are not only in place but provably effective. For Type 2 reports, this phase runs throughout the entire observation period. Establishing robust evidence collection early prevents the last-minute scramble that derails many audits.
Step 10: Establish evidence collection processes
Define how you will collect, organise, and retain evidence for every control in scope. Evidence types include system-generated logs, screenshots, configuration exports, policy documents, meeting minutes, training completion records, ticket histories, and signed attestations. Each control should have a documented evidence collection procedure that specifies what evidence is required, how frequently it must be collected, who is responsible, and where it is stored.
Automate evidence collection wherever possible. Pull access review logs directly from your identity provider. Export vulnerability scan results from your scanning tool on a scheduled basis. Capture change management records from your ticketing system via API. Manual evidence collection is error-prone, time-consuming, and difficult to sustain over a full observation period. A GRC platform can automate the collection, normalisation, and storage of evidence across dozens of integrations, reducing the burden on control owners and ensuring completeness. Establish a naming convention and folder structure so evidence is easy to locate during the audit.
Step 11: Test controls internally
Before your auditor arrives, test your own controls to verify they operate as intended. Internal control testing should mirror the procedures your auditor will perform: select a sample of events (access grants, change requests, incidents), review the evidence for each, and confirm the control operated correctly. Document any exceptions and remediate them before the audit begins.
Focus testing on high-risk areas: access provisioning and deprovisioning, change management approvals, incident response execution, and evidence of regular risk assessments. For each test, record the control being tested, the population and sample size, the testing procedure, the results, and any exceptions found. If you discover a control failure, investigate the root cause, remediate it, and collect evidence that the control operated correctly after remediation. Auditors expect some exceptions, but they want to see that you detected them, understood them, and addressed them. Internal testing also builds confidence in your team and reduces audit anxiety.
Step 12: Conduct a readiness assessment
A readiness assessment is a mock audit that evaluates your overall preparedness before the formal examination begins. You can conduct this internally if you have sufficient expertise, or engage a third-party advisory firm (distinct from your audit firm, to preserve independence). The assessment should cover the completeness of your control environment, the quality and sufficiency of evidence, the accuracy of your system description, and any remaining gaps.
The readiness assessment should produce a detailed report with findings categorised by severity. Address all critical and high findings before scheduling your audit. Share the results with your executive sponsor and control owners to maintain visibility and accountability. This is also an excellent opportunity to rehearse the audit process itself: practice responding to auditor inquiries, locating evidence quickly, and explaining your control environment clearly. Organisations that invest in a thorough readiness assessment almost always receive cleaner audit reports with fewer, if any, qualified findings or exceptions.
Phase 4: Audit and Ongoing Compliance
The final phase covers the audit itself and the critical work of maintaining compliance on an ongoing basis. SOC 2 is not a point-in-time achievement but a continuous commitment to security and operational excellence.
Step 13: Select and engage a qualified CPA firm
SOC 2 reports can only be issued by a licensed CPA firm. When selecting your auditor, evaluate their experience with organisations of your size and industry, their familiarity with your technology stack, their communication style and responsiveness, their fee structure, and their availability relative to your target audit window. Request references from current clients and ask about the typical audit duration and any common pain points.
Engage the firm well in advance of your target audit start date, ideally three to six months prior. During the engagement planning phase, your auditor will review your system description, confirm the scope and criteria, agree on the observation period (for Type 2), and outline the information requests they will make during fieldwork. Provide your auditor with a clear point of contact and establish communication protocols. Organisations that build a collaborative, transparent relationship with their auditor consistently have smoother audit experiences. Avoid adversarial dynamics; your auditor is evaluating your controls, not trying to catch you out.
Step 14: Support the audit process
During the audit, your primary role is to respond to information requests promptly, facilitate auditor access to systems and personnel, and provide context for your control environment. Auditors will typically issue a Prepared by Client (PBC) list detailing every piece of evidence they need. Assign responsibility for each PBC item to the appropriate control owner and set internal deadlines that are earlier than the auditor’s deadlines to build in buffer time.
Prepare your team for auditor walkthroughs and interviews. Control owners should be able to explain what their controls do, how they operate, what evidence they produce, and how exceptions are handled. Maintain a centralised tracker for all auditor requests, noting the status of each item (not started, in progress, submitted, accepted, follow-up needed). If the auditor identifies exceptions or findings during fieldwork, respond constructively. Provide additional context where relevant, implement compensating controls if needed, and document your management response. A well-organised, responsive approach to the audit process directly influences the quality of your final report.
Step 15: Plan for continuous compliance and renewal
After receiving your SOC 2 report, shift focus to sustaining compliance on an ongoing basis. SOC 2 Type 2 reports must be renewed annually, and your next audit period begins immediately after the current one ends. Any gaps in control operation between audit periods will be visible to your next auditor and could result in qualified findings.
Establish continuous monitoring for all critical controls. Automate alerts for control failures such as MFA bypass events, unauthorised access attempts, unapproved changes, or missed access reviews. Schedule regular internal reviews: monthly control owner check-ins, quarterly risk assessments, and annual policy reviews. Maintain your evidence collection processes without interruption. Track changes to your environment (new systems, new vendors, organisational changes) and assess their impact on your control environment. Use each audit cycle as an opportunity to refine and strengthen your programme. Organisations that treat SOC 2 as a continuous programme rather than an annual project find that subsequent audits become progressively easier, faster, and less disruptive to normal operations.
Key Takeaways
SOC 2 compliance is a structured, multi-phase process that rewards thorough planning, disciplined execution, and consistent follow-through. The fifteen steps in this checklist cover the full lifecycle from initial scoping to continuous compliance. While the effort required is significant, particularly during the first audit cycle, the returns are substantial: stronger security, faster sales cycles, and demonstrable trust with customers and partners.
Start by scoping tightly and assigning clear ownership. Invest in a thorough gap analysis before implementing controls. Automate evidence collection wherever possible to reduce manual burden and improve consistency. Test your controls internally before the auditor arrives. And above all, treat SOC 2 as an ongoing programme rather than a one-time project.
Organisations that follow this structured approach consistently achieve cleaner audit reports, spend less time on remediation, and build security programmes that genuinely protect their customers’ data rather than simply ticking boxes.