Why SOC 2 and why now
If you sell software to other businesses, SOC 2 is almost certainly on your roadmap. It has become the default trust signal in B2B SaaS — the report that procurement teams request, that security questionnaires reference, and that enterprise deals increasingly require before ink hits paper.
SOC 2 is not a certification. It is an attestation — an independent auditor's opinion on whether your controls are designed appropriately (Type I) and operating effectively over a period of time (Type II). The distinction matters. A Type I is a snapshot: your controls look good today. A Type II covers a window, typically 6-12 months, and demonstrates that your controls worked consistently throughout.
Most customers want the Type II. It is more rigorous, more credible, and more useful. This guide focuses on getting you there without the organisational trauma that typically accompanies a first audit.
Scoping: the decision that shapes everything
The first and most consequential decision is scope. SOC 2 is built around five Trust Service Criteria: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Security is mandatory. The others are optional.
Choose your criteria based on what your customers care about and what your product actually does. If you run a SaaS platform with uptime SLAs, Availability is relevant. If you process sensitive data, Confidentiality and possibly Privacy are relevant. If you perform data transformations or calculations that customers rely on, Processing Integrity matters.
Do not include criteria just because they sound important. Each additional criterion adds controls, evidence requirements, and audit cost. Start with Security and one or two others that align with your product and customer expectations. You can add criteria in subsequent audits as your program matures.
Equally important is defining your system boundary — the infrastructure, software, people, procedures, and data that are in scope. A tightly defined boundary reduces your control surface and simplifies the audit. If a service is not part of your production environment and does not process customer data, consider whether it needs to be in scope.
The control framework: what you actually need
SOC 2 is principle-based, not prescriptive. The Trust Service Criteria describe what you need to achieve, not how to achieve it. This flexibility is both a strength and a source of confusion.
Your auditor will evaluate your controls against the criteria and their "points of focus" — supplementary guidance that clarifies intent. You do not need to address every point of focus, but they indicate what the auditor is looking for.
At a practical level, the Security criterion (Common Criteria) covers:
CC1 — Control environment. Management's commitment to security, organisational structure, board oversight. This is satisfied by having a security policy, defined roles, and evidence that leadership is engaged (risk review meetings, security budget approvals, etc.).
CC2 — Communication and information. Internal communication of security policies and responsibilities, and external communication of commitments (like your security page or terms of service). Employee security training lives here.
CC3 — Risk assessment. A documented risk assessment process with periodic reviews. Your risk register, risk treatment plans, and evidence of regular reviews.
CC4 — Monitoring activities. Ongoing evaluation of controls. This includes internal audits, control testing, and management review of security metrics.
CC5 — Control activities. The technical and operational controls themselves — access controls, change management, data protection, network security, vulnerability management, incident response. This is the largest category and the one that requires the most evidence.
CC6 — Logical and physical access controls. Authentication, authorisation, access provisioning, access reviews, and physical security for any on-premises infrastructure.
CC7 — System operations. Monitoring, incident detection, incident response, and data backup/recovery.
CC8 — Change management. How changes to infrastructure and applications are authorised, tested, and deployed.
CC9 — Risk mitigation. Vendor risk management and business continuity planning.
This looks like a lot. It is less than it appears. If you have been running a reasonable engineering organisation — using version control, requiring code reviews, deploying through CI/CD, using an identity provider with MFA, monitoring your infrastructure — you already satisfy a meaningful percentage of these controls.
The 16-week timeline
A realistic timeline for a first SOC 2 Type II engagement, assuming you have basic security hygiene in place:
Weeks 1-2: Readiness assessment. Map your existing controls to the Trust Service Criteria. Identify gaps. This is a structured comparison of what you do today versus what the criteria require. Most organisations find they are 50-70% of the way there before they start.
Weeks 3-6: Gap remediation. Implement the missing controls. Common gaps include: formal security policies (information security policy, acceptable use policy, incident response plan, business continuity plan), access review processes, vendor risk management, security awareness training, and change management documentation.
Weeks 7-8: Evidence collection and testing. Begin collecting evidence that your controls are operating. Set up automated evidence collection where possible. Manually collect what you cannot automate. Test each control to verify it works as designed.
Weeks 9-12: Observation period begins. Your Type II audit window opens. During this period, your controls need to operate consistently. The auditor will sample evidence from across this window to verify sustained compliance. Continue your normal operations — the point is to demonstrate that your controls work in practice, not just in theory.
Weeks 13-15: Auditor fieldwork. The audit firm reviews your evidence, conducts interviews, and tests a sample of your controls. They will request additional documentation, ask clarifying questions, and may identify exceptions — instances where a control did not operate as intended.
Week 16: Report delivery. The auditor issues your SOC 2 Type II report. This includes their opinion, a description of your system, the criteria tested, the tests performed, and the results — including any exceptions.
This timeline assumes a 3-month observation period, which is the minimum most auditors will accept for a Type II. A 6-month or 12-month window is more common for subsequent audits and carries more weight with customers.
Evidence: the operational reality
The audit is fundamentally about evidence. The auditor cannot observe your controls in real time for the entire observation period. Instead, they rely on documented proof that each control operated as intended.
For each control, you need evidence of design (the policy or procedure that defines the control) and evidence of operation (proof that the control was executed). Some examples:
- Access reviews: Documentation showing that user access was reviewed quarterly, who performed the review, what changes were made, and that the review was completed on time.
- Change management: Pull request histories showing that code changes were reviewed and approved before deployment. CI/CD logs showing automated testing. Deployment records.
- Vulnerability management: Scan reports showing vulnerabilities were identified. Ticketing records showing they were triaged and remediated within your defined SLAs.
- Incident response: Incident tickets, timeline documentation, post-incident reviews. If no incidents occurred during the observation period, evidence that your monitoring and alerting systems were operational.
The volume of evidence is substantial. For a typical SOC 2 engagement, expect to collect evidence for 80-120 individual controls. If each control requires 2-3 pieces of evidence, you are managing hundreds of artifacts across your observation period.
This is where automation pays for itself many times over. Connecting your infrastructure, identity provider, and development tools to a platform that continuously collects evidence transforms a gruelling manual process into a background operation. The evidence is there when the auditor asks for it, covering the entire observation period rather than a single point in time.
Exceptions are not failures
Here is something that first-time SOC 2 organisations often do not understand: exceptions are normal. An exception means that a control did not operate as intended in a specific instance — an access review was completed a week late, a vulnerability was remediated outside the defined SLA, a policy acknowledgment was missed during onboarding.
Exceptions do not prevent you from receiving a clean report. The auditor's opinion considers the nature, cause, and frequency of exceptions. Isolated exceptions with reasonable explanations are expected in any operating environment. Systemic failures — the same control consistently not operating — are a different matter.
When an exception is identified, document what happened, why it happened, and what you did to prevent recurrence. This demonstrates maturity. Organisations that acknowledge and address exceptions are more credible than organisations that claim perfect operation — because perfect operation does not exist.
After the report: sustaining the program
The SOC 2 report is not the finish line. It is the starting point of a continuous compliance practice. Your next audit will cover a longer observation period and your customers will expect annual renewals.
Build the habits now: monthly risk reviews, quarterly access reviews, continuous evidence collection, regular policy updates. Treat the SOC 2 program as an operating rhythm rather than a project. When the next audit cycle arrives, there should be no scramble — just a continuation of what you have been doing all along.
The organisations that experience SOC 2 as a fire drill are the ones that treat it as a discrete event. The ones that experience it as routine are the ones that embedded it into their operations from the beginning.
That is the goal. Not just the report. The practice.