Is SOC 2 required?
SOC 2 isn't a law or a government regulation. It's an examination framework built on AICPA standards, and the demand for it usually comes from customers: a security questionnaire, a procurement review or a contract clause that asks for a current SOC 2 report. For a SaaS company or a startup selling to larger businesses, that request can arrive before the first big contract.
When a customer asks about SOC 2 compliance, ask which report it wants and which services the report must cover. Those answers set the scope of everything that follows.
The outcome is an attestation report. In a SOC 2 examination, a CPA acting as the service auditor gives an opinion on whether your system description is presented in line with the AICPA description criteria and whether your controls were suitably designed. In a Type 2 report, the opinion also covers whether the controls operated effectively.
SOC 2 doesn't produce a certificate, and readiness work can't stand in for the examination. Readiness is what happens before the CPA firm starts: deciding scope, fixing gaps and organizing evidence.
The SOC 2 readiness checklist at a glance
Use this list to plan the work and assign owners. The report type and the system boundary shape everything else, so get customer input on both before you spend time on policies or tools.
- Decide which report you need: Type 1 or Type 2, and which services it covers.
- Define the system boundary, including subservice organizations and complementary user entity controls.
- Choose the Trust Services Criteria categories that match your commitments.
- Run a gap assessment against the common criteria, CC1 to CC9, and any added categories.
- Write the policies your team will actually follow, and get them approved.
- Collect evidence that shows each control operating, including scans and tests where they apply.
- Choose a licensed CPA firm, check its license and peer review, and agree on timing.
Step 1: Decide which report you need
The AICPA description criteria recognize two types of SOC 2 examination. A Type 1 report covers your system description and whether controls were suitably designed, as of a specific date. A Type 2 report covers the same things plus whether the controls operated effectively during a period of time.
The choice changes the work. A Type 1 needs controls designed and in place by the report date. A Type 2 needs controls that run consistently across the whole review period, with records to prove it. You set the length of that period with your CPA firm, and customers sometimes say what they expect.
Questions to ask your customers
Customer requirements decide scope more than any framework does. Ask the people requesting the report, and keep their answers in writing.
- Which report type do you need, Type 1 or Type 2?
- Which of our products or services must the report cover?
- Which Trust Services Criteria categories do you expect beyond security?
- Is there a contract date or a renewal that the report has to meet?
- Would a Type 1 report meet your needs while a Type 2 review period runs?
Step 2: Define the system boundary
The system is what the report describes and what the CPA firm examines. Description criterion DC3 asks management to describe the components of the system used to provide the services: infrastructure, software, people, procedures and data.
Draw the boundary around the service your customers rely on, not around the whole company. Map where customer data enters, where it's stored and processed, who can reach it, and which tools run the service.
Subservice organizations: inclusive or carve-out
A subservice organization is a vendor that performs controls your service commitments depend on, such as a hosting provider. Description criterion DC7 gives management two ways to present one. Under the inclusive method, the relevant parts of the vendor's system are included in your description and in the scope of the examination.
Under the carve-out method, the vendor's components are excluded from the description and the examination. The description still identifies the nature of the vendor's services, the types of controls you assume the vendor operates, and the controls you use to monitor the vendor. You can carve out some vendors and include others.
Complementary user entity controls
Description criterion DC6 covers controls that management assumed, when designing the system, would be implemented by customers, and that are necessary together with your own controls to meet your service commitments. These are complementary user entity controls, and the description has to list them.
Keep the list short and specific. Each one is something your customers must do for your commitments to be met, so it belongs in onboarding material or contracts too.
Step 3: Choose the Trust Services Criteria categories
The 2017 Trust Services Criteria, with points of focus revised in 2022, define five categories. The common criteria, CC1 to CC9, apply to all of them and on their own are suitable for evaluating controls over security. Availability, processing integrity, confidentiality and privacy each add their own series of criteria on top of the common criteria.
Pick categories from your commitments, not from a wish to look thorough. Each category you add brings its full set of criteria, and more controls and evidence, into the examination.
| Category | Criteria used | Consider it when |
|---|---|---|
| Security | Common criteria only | Always relevant, because the common criteria apply whichever categories you choose |
| Availability | Common criteria plus the A series | Contracts or service levels commit you to uptime, capacity or recovery |
| Processing integrity | Common criteria plus the PI series | Customers rely on your processing being complete, valid, accurate, timely and authorized |
| Confidentiality | Common criteria plus the C series | You commit to protect information designated as confidential, such as customer business data |
| Privacy | Common criteria plus the P series | You collect, use, keep or disclose personal information and make commitments about it |
Step 4: Run a gap assessment against CC1 to CC9
A gap assessment compares what you do today with each applicable criterion. The criteria are the closest thing SOC 2 has to a list of requirements, and they describe outcomes rather than specific controls. The common criteria are aligned to the 17 principles of the COSO internal control framework, as revised in 2013, plus supplemental criteria for logical and physical access, system operations, change management and risk mitigation.
Each criterion comes with points of focus. The Trust Services Criteria describe them as important characteristics that can help management design controls and help evaluate them, and they state that using the criteria doesn't require assessing whether each point of focus is addressed. Treat them as prompts, not a checklist.
Record each gap against its criterion with the risk it creates, the fix, an owner and a target date. Rank gaps by risk and by how long the fix needs to run before it can be evidenced: for a Type 2 report, a control should be operating when the review period starts.
The common criteria cover these areas:
- CC1: control environment
- CC2: information and communication
- CC3: risk assessment
- CC4: monitoring activities
- CC5: control activities
- CC6: logical and physical access controls
- CC7: system operations
- CC8: change management
- CC9: risk mitigation, including risks from vendors and business partners
Step 5: Write policies you actually follow
Policies set expectations, and controls and records show that the expectations are met. In a Type 2 examination the service auditor evaluates whether controls operated effectively, so a policy that promises more than the team does invites exceptions rather than credit.
Name an owner for each policy, have management approve it, and set a review cycle you'll keep.
Organize policies around the criteria areas instead of a long template. Clear, approved statements usually cover these areas:
- Governance, roles and responsibilities, and how leadership oversees security (CC1)
- Risk assessment: how risks are identified, analyzed and reviewed (CC3)
- Access: granting, reviewing and removing logical and physical access (CC6)
- Operations: vulnerability management, monitoring and responding to security incidents (CC7)
- Change management for infrastructure, software and configurations (CC8)
- Vendor and business partner risk (CC9)
Step 6: Show that controls operate
Evidence is how a control proves itself. For each control, decide what record shows it ran, where that record lives, and who produces it. Records a system generates on its own, such as tickets, logs and configuration exports, are easier to keep complete than screenshots taken by hand.
Rehearse before the CPA firm arrives. Pull a few records for each control and check that they're complete, dated and approved by the right person. Gaps found in a rehearsal are easier to fix than exceptions found in the examination.
Common evidence includes:
- Access requests, approvals, periodic access reviews and removals
- Change tickets with review and approval before deployment
- Risk assessment records and the decisions that followed
- Vendor reviews, including the SOC 2 reports your own vendors provide
- Vulnerability scan results, remediation tickets and rescans
Vulnerability scans and penetration tests
The Trust Services Criteria don't set a fixed schedule for either. Under CC7.1, a point of focus describes infrastructure and software vulnerability scans run periodically and after significant changes, with identified deficiencies remediated in a timely manner. Under CC4.1, a point of focus lists penetration testing and vulnerability scans among the kinds of evaluations management can use.
Because points of focus are guidance, the decision rests on your risks, commitments and customers. If a contract requires a penetration test, that requirement applies whatever the criteria say.
Step 7: Choose and check a licensed CPA firm
Only a CPA firm can perform a SOC 2 examination and issue the report. The AICPA description criteria describe the examination as performed under the AICPA attestation standards, with a CPA, called the service auditor, expressing the opinion. The AICPA also says it takes action with respect to members who are unlicensed or not enrolled in peer review, and assists regulators, including through referrals to state boards of accountancy, regarding unlicensed firms and practitioners.
Check two things yourself. Confirm the firm's license with the state board of accountancy where it practices; NASBA keeps a directory of the boards for all 55 U.S. jurisdictions. Then look the firm up in the AICPA Peer Review Public File, which lists firms and their enrollment in the AICPA Peer Review Program and, for some firms, their latest accepted peer review documents.
Keep the roles separate. Under the AICPA Code of Professional Conduct, a CPA firm that accepts responsibility for designing, implementing or maintaining internal control impairs its independence, so the people who build your controls shouldn't be the firm that examines them. Contract with the CPA firm directly, and ask it questions like these:
- Is your firm licensed where you'll perform the work, and what was the result of your most recent peer review?
- How many SOC 2 examinations has this engagement team performed for systems like ours?
- How will evidence requests work, and in what format do you want records?
- Who on your team signs the report?
What drives SOC 2 readiness time and cost
There's no standard answer to how long SOC 2 takes, because the work depends on where you start. The biggest factors are scope and maturity: how many systems, products and locations sit inside the boundary, and how much of the control set already runs with records.
For a Type 2 report, the calendar also includes the review period itself, then the CPA firm's fieldwork and reporting. Plan backward from the date your customer needs the report, and budget for readiness and the examination separately, because the CPA firm prices its own work.
The main factors are:
- Report type, and for a Type 2, the length of the review period
- The number of Trust Services Criteria categories in scope
- The size of the system boundary and the number of subservice organizations
- How many controls already exist with owners and evidence
- Remediation projects, such as rolling out multi-factor authentication or centralized logging