1. What SOC 2 Actually Is
SOC 2 stands for System and Organization Controls 2. It is an auditing framework developed by the American Institute of Certified Public Accountants (AICPA). The framework provides criteria for evaluating whether a service organization has controls in place to protect customer data and maintain system reliability.
The framework is organized around Trust Services Criteria (TSC). There are five criteria categories:
- Security (required): controls that protect systems against unauthorized access, both physical and logical
- Availability: systems are available for operation and use as committed or agreed
- Confidentiality: information designated as confidential is protected appropriately
- Processing Integrity: system processing is complete, valid, accurate, timely, and authorized
- Privacy: personal information is collected, used, retained, disclosed, and disposed of in accordance with stated commitments
Security is the only required criterion. Most B2B SaaS companies also include Availability. Confidentiality is included when the service involves handling sensitive customer information. Privacy and Processing Integrity are added based on the specific service model.
There are two types of SOC 2 reports:
- Type I assesses whether controls are appropriately designed at a specific point in time.
- Type II assesses whether those controls operated effectively over a defined observation period, typically between three and twelve months. Enterprise customers generally prefer a Type II report because it demonstrates consistent execution, not just design.
A SOC 2 report is not a certification or a pass/fail evaluation. It is a report issued by an independent CPA firm. The report describes the service organization's system, the applicable trust criteria, and the auditor's findings on control design and, for Type II, operating effectiveness.
2. What SOC 2 Readiness Really Means
SOC 2 readiness is the state of having controls designed, implemented, and operating in a way that would withstand audit review.
Readiness is not the audit. The audit is a formal process conducted by an independent CPA firm. Readiness is the internal preparation that must happen before that external review begins.
A company that is ready for SOC 2 has completed the following:
- Defined its in-scope systems and services
- Selected the applicable trust service criteria
- Identified control gaps and addressed them
- Documented policies and operational procedures that reflect actual practices
- Collected evidence demonstrating that controls are functioning
- Assigned internal ownership for ongoing program management
Readiness does not require a perfect security posture. It requires that gaps are documented, controls are operational, and evidence exists to support audit testing. Companies often conflate readiness with security maturity. They are related but not the same. A company can be highly mature and not ready because it has not structured its controls against the specific trust service criteria. A company can also be adequately ready without having the most sophisticated security tooling in place.
3. Who Typically Needs SOC 2
SOC 2 is not a legal requirement. It becomes operationally necessary when customers or partners require it as a condition of doing business.
The most common scenarios:
- Enterprise contract requirements: a prospective enterprise customer will not sign a contract without a SOC 2 report
- Procurement reviews: mid-market buyers include security assessment requirements in vendor reviews
- Security questionnaires: prospects send detailed security questionnaires that reference SOC 2 compliance
- Platform and integration requirements: API providers or marketplace platforms require SOC 2 as a condition of participation
The typical trigger is a deal that requires proof of security controls. The company realizes it does not have a report and must decide whether to invest in readiness.
B2B SaaS companies most likely to encounter this requirement include:
- SaaS platforms that store or process enterprise customer data
- Infrastructure, API, or data pipeline providers
- Companies in sectors where customers have their own compliance obligations, such as financial services, healthcare, or legal
- Any service that operates within a customer's regulated environment
4. The Typical SOC 2 Readiness Path
The sequence of readiness work is predictable, even when the timeline varies. Most programs follow this order:
- Scope definition
- Trust criteria selection
- System and vendor inventory
- Gap analysis
- Remediation planning
- Policy development
- Technical control implementation
- Operational procedure documentation
- Evidence collection
- Observation period (required for Type II)
- Readiness review
- Auditor selection and audit engagement
Deviating from this order creates problems. Starting evidence collection before controls are stable generates inconsistent records. Starting the audit before the observation period is complete creates a Type II timeline problem. Beginning policy documentation before scope is defined can produce policies that do not match what will actually be audited.
5. Common Mistakes Teams Make
Defining scope too broadly
Including every system in the organization creates work that is not required. Scope should reflect systems central to service delivery and customer data handling.
Treating policy writing as completion
A documented policy is not a control. The control is the practice the policy describes. Auditors test whether the practice runs, not whether it is written down.
No designated internal owner
When responsibility is distributed across a team without a named owner, priorities compete. Evidence goes uncollected. Decisions are deferred.
Stopping after the gap analysis
A gap analysis identifies problems. It does not fix them. Many teams treat the gap analysis as a milestone and then lose momentum before remediation is complete.
Implementing controls briefly and then letting them lapse
A control that ran for three weeks and then stopped creates an audit finding. For Type II, controls must operate consistently throughout the observation period.
Collecting evidence before controls are stable
Gathering screenshots and logs before the underlying process is running correctly creates a record that does not reflect what will be in place at audit time.
Assuming the auditor will guide the program
Auditors evaluate what you present. They do not build readiness programs. That work belongs to the organization before the audit begins.
6. What Determines Timeline Length
Several factors affect how long the readiness process takes.
Current security maturity
Organizations with existing access management, logging, incident response, and change management processes move faster. Those starting with minimal controls take longer.
Infrastructure complexity
Environments with multiple cloud providers, third-party integrations, and distributed teams have more controls to address. Single-cloud, single-product environments are generally faster to scope and address.
Internal bandwidth
Readiness requires time from engineers, technical leadership, and operations personnel. If those people are fully committed to product work, readiness moves in parallel but slowly.
Type I vs. Type II
A Type I audit can proceed as soon as controls are designed and implemented. A Type II audit requires controls to operate over a defined period, adding months to the overall timeline.
Scope decisions
A focused scope covering only the systems central to service delivery moves faster than a broad scope that includes supporting systems, internal tools, and edge services.
Auditor availability
After readiness work is complete, scheduling depends on the CPA firm's calendar.
No fixed timeline applies to all companies. These variables interact with each other. A team with an existing security foundation and clear internal ownership will reach readiness faster than a team starting from no documented controls with limited bandwidth.
7. What Internal Work Is Required
Outside advisors and compliance tools reduce confusion and provide structure. They do not eliminate internal work.
- System and process documentation: only your team knows how your systems actually operate. Advisors rely on your engineers to describe and confirm what is real.
- Access reviews: your team must conduct access reviews, confirm who has access to which systems, and document the process.
- Policy review and approval: policies must reflect how your organization actually operates. Internal leadership must review and approve them.
- Evidence generation: access review records, change logs, security training completion records, and incident logs are produced by your team's activities.
- Risk and scope decisions: decisions about which systems are in scope, which risks are accepted, and how gaps are prioritized belong to internal leadership.
- Ongoing control execution: after the initial readiness phase, controls must continue to operate. Someone in your organization is accountable for that.
The goal of structured readiness support is to reduce wasted effort and direct internal work toward what actually matters. It does not eliminate internal effort. It focuses it.
8. When to Bring in Outside Help
Outside help is a practical choice when specific conditions exist.
No internal GRC or security governance experience
Building a SOC 2 program without prior exposure to the trust service criteria typically produces scoping errors, missed controls, and poor evidence practices. These create audit findings that could have been avoided.
Compliance is a secondary responsibility
When the CTO, engineering lead, or founder is managing compliance alongside other work, the program advances inconsistently. External support provides structure and keeps it moving.
The gap analysis is unclear
The first structured assessment of controls against the trust criteria is difficult without a reference point. Someone with experience can run that assessment more efficiently and identify issues that are easy to miss.
A deal depends on moving quickly
When an enterprise contract requires a SOC 2 report within a defined timeframe, an external advisor with a defined methodology reduces risk compared to a team working through it for the first time.
Outside help does not replace internal ownership. The two work together. An advisor can direct and structure the program, but your team must execute the controls and own the outcomes.
9. Step-by-Step Readiness Breakdown
Define the audit scope
Identify the systems, services, and teams included in the audit boundary. Focus on the systems that directly support service delivery and handle customer data. Avoid over-inclusion.
Select trust service criteria
Determine which criteria apply based on your service model. Security is required. Evaluate whether Availability, Confidentiality, Processing Integrity, and Privacy are relevant to your commitments to customers.
Inventory in-scope systems and vendors
Document all systems within scope. Identify third-party vendors that process, store, or transmit data within the service boundary.
Conduct a gap analysis
Compare existing controls, policies, and practices against the selected criteria. Document gaps, missing controls, and areas where controls exist but are not documented or consistently running.
Build a remediation roadmap
Prioritize gaps based on risk and effort. Assign ownership and target completion dates. Treat this as an operational plan, not a list.
Address policy gaps
Write or update policies for access control, incident response, change management, data handling, risk management, and other areas required by the selected criteria. Policies must reflect actual practice.
Implement technical controls
Put in place the access controls, logging, monitoring, encryption, and other technical safeguards required by the gap analysis.
Document operational procedures
Record how processes run, including employee onboarding and offboarding, access reviews, vulnerability management, backup and recovery, and incident response.
Begin evidence collection
Establish the process for collecting and organizing evidence. Gather the first set of evidence that controls are operating. Review for completeness and consistency.
Operate controls consistently
For a Type II audit, controls must run consistently throughout the observation period. Maintain evidence as controls execute.
Conduct a pre-audit review
Before engaging an auditor, review the full control set against the selected criteria. Identify remaining gaps and address them before the audit begins.
Engage an auditor
Select a CPA firm with SOC 2 experience. Provide system documentation, respond to evidence requests, and complete the audit process.
10. SOC 2 Readiness Checklist
Scope and criteria
- In-scope systems and services are identified and documented
- Trust service criteria are selected based on service model
- Third-party vendors with access to in-scope systems are inventoried
Policies and documentation
- Information security policy is in place
- Access control policy is documented
- Incident response plan is documented and reviewed
- Change management policy is in place
- Data classification and handling policy is documented
- Risk assessment process is documented and current
- Acceptable use policy is in place
Technical controls
- Multi-factor authentication is enforced on critical systems
- Access is provisioned based on least privilege
- Logging and monitoring are configured on in-scope systems
- Data is encrypted at rest and in transit
- Vulnerability management process is in place
- Backup and recovery are documented and tested
Operational procedures
- Employee onboarding includes system access provisioning and security training
- Employee offboarding revokes access promptly and consistently
- Access reviews are conducted on a documented schedule
- Incident response procedures have been reviewed or tested
Program readiness
- Gap analysis is complete
- Remediation roadmap is current and tracked
- Internal owner is designated for program management
- Evidence collection process is established and running
11. What Happens After Readiness
Once controls are implemented and operating, the readiness phase transitions into the audit phase.
Selecting an auditor
SOC 2 audits must be conducted by a licensed CPA firm. The auditor is independent of the organization and of any advisory firm involved in readiness work. Selection criteria include experience with SaaS service environments, familiarity with the selected trust criteria, and scheduling availability.
Type I or Type II
A Type I report assesses whether controls are appropriately designed at a point in time. A Type II report assesses whether controls operated effectively over a defined period. Most enterprise customers request Type II. If speed is the primary objective, Type I can be completed faster, with a plan to pursue Type II in the following audit cycle.
The audit process
The auditor reviews system documentation, tests controls through inquiry and inspection, and may interview key personnel. They issue findings. The organization has the opportunity to respond. The final report reflects the auditor's conclusions.
The SOC 2 report
A SOC 2 report is typically shared with customers under a non-disclosure agreement. It includes a description of the service organization's system, the applicable trust criteria, and the auditor's opinion. Reports do not expire, but customers commonly request a report issued within the prior twelve months.
Maintaining the program
After the audit, the compliance program continues. Controls must keep operating. Policies must stay current. Access reviews, risk assessments, and other recurring activities must run on schedule. Governance does not end with the first report. It is an ongoing operational function.