SOC 2 Readiness: How to Prepare for Your First Audit

Preparing for your first SOC 2 audit comes down to five decisions and a lot of evidence. You define the system in scope, choose which Trust Services Criteria apply, find and fix gaps, write policies that match how you actually operate, and plan when the auditor's observation period starts. Most of the work happens before the CPA firm arrives.

A realistic readiness effort for a small or mid-sized organization takes several months before a Type I, and a Type II adds an observation period on top. This guide walks through each step and ends with a sample timeline.

What is a SOC 2 audit?

A SOC 2 report is an attestation report issued by an independent CPA firm under AICPA standards. It describes your system and gives the auditor's opinion on the controls relevant to security and, if you choose, availability, processing integrity, confidentiality or privacy. Customers and their auditors use it to judge whether they can trust you with their data.

There are two types:

• Type I reports on whether your system description is fairly presented and your controls are suitably designed as of a specific date.
• Type II adds whether those controls operated effectively throughout a period of time.

SOC 2 is different from SOC 1, which addresses controls relevant to customers' financial reporting, and from SOC 3, a shorter general-use report on the same subject matter as SOC 2. A SOC 2 report is generally shared with customers under a nondisclosure agreement.

Which Trust Services Criteria should you include?

SOC 2 examinations use the AICPA's 2017 Trust Services Criteria. They were issued in April 2017 and have been required for SOC 2 reports since December 15, 2018. The criteria are aligned with the 17 principles in the COSO 2013 internal control framework.

The criteria fall into five categories:

The security criteria are called the common criteria because every SOC 2 includes them. They cover the control environment (CC1), communication and information (CC2), risk assessment (CC3), monitoring activities (CC4), control activities (CC5), logical and physical access controls (CC6), system operations (CC7), change management (CC8) and risk mitigation (CC9), which includes vendor and business partner risk.

Choose additional categories based on what you've promised customers. If your contracts include uptime commitments, availability is a natural fit. If customers send you data they treat as confidential, consider confidentiality.

Each category you add means more controls and more evidence. For a first report, starting with security alone and expanding later is a reasonable path unless customers need more. Ask your largest customers what they expect before you decide.

Each criterion also comes with points of focus. They're examples of characteristics a control might address, not a checklist you must satisfy line by line.

How do you define the system and scope?

In SOC 2 terms, "the system" is the set of components that deliver a service to customers: infrastructure, software, people, procedures and data. Your scope should match a service customers actually buy.

Start by answering these questions:

• Which service or product is in scope? Pick the one customers are asking about. You don't need to cover every product in your first report.
• What are your service commitments and system requirements? These are the promises in your contracts, service level agreements and public statements, plus the internal requirements that support them.
• Which infrastructure and locations support it? Include cloud environments, data centers and offices where in-scope work happens.
• Which teams operate it? Engineering, IT, security, support and HR usually all touch in-scope controls.
• Which vendors are involved? For subservice organizations such as hosting providers, decide with your auditor whether to use the carve-out method, which excludes their controls from your report, or the inclusive method, which includes them. Carve-out is simpler, but you'll still need to monitor those vendors.

Tight scope makes the audit manageable. Too narrow, however, and the report won't answer the questions your customers are asking.

How do you run a SOC 2 gap assessment?

A gap assessment compares your current controls against the criteria you've chosen. You can run it internally or engage an outside firm, but be honest either way. The goal is to find problems now, not during fieldwork.

For each criterion:

1. Identify the controls you have that address it.
2. Check whether each control is documented, consistently performed and able to produce evidence.
3. Record gaps, assign an owner and set a date to close each one.

Common gaps in first-time assessments include missing or outdated policies, informal access reviews, undocumented change management, no formal risk assessment, weak vendor oversight and incident response plans that were never tested. With many teams working remotely in 2020, also confirm your endpoint, access and logging controls reflect how people work now.

What policies do you need, and how do you write them?

Auditors test whether you follow your policies, so write policies that describe what you actually do. An ambitious policy you don't follow creates an exception. A realistic policy you follow creates evidence.

Most SOC 2 programs include policies or procedures covering:

• Information security (the umbrella policy, approved by leadership)
• Access control, including onboarding, offboarding and periodic access reviews
• Change management and software development
• Risk assessment
• Incident response
• Vendor management
• Business continuity and disaster recovery
• Data classification, retention and disposal
• Acceptable use and HR security, including background checks and security awareness training

Keep them short enough that people read them. Assign an owner to each, record approval and set a review cycle, usually annually.

Which controls will you need evidence for?

A Type II auditor will sample evidence from across the observation period, so controls need to run on schedule and leave a record. Expect requests like these:

Where you can, generate evidence automatically through ticketing systems, logs and configuration exports. Screenshots gathered by hand at the last minute are slow and error-prone.

What goes into the system description?

The system description is written by management, not the auditor. It follows the AICPA's description criteria (DC section 200) and typically covers:

• The types of services you provide
• Your principal service commitments and system requirements
• The system components: infrastructure, software, people, procedures and data
• The applicable criteria and the controls designed to meet them
• Complementary user entity controls, which are the things customers must do for your controls to work, such as managing their own user accounts
• Subservice organizations and the controls you expect them to have
• Any significant system incidents and changes during the period

Draft it early. Writing the description often exposes scope questions and gaps that are cheaper to resolve before fieldwork.

How do you choose a CPA firm?

Only a licensed CPA firm can issue a SOC 2 report. Talk to more than one, and ask:

• How much SOC 2 experience does the firm have with organizations of your size and type?
• Who will actually do the fieldwork, and how much continuity will you have year to year?
• How do they handle evidence requests and sampling, and what tools do they use?
• Can they perform fieldwork remotely if needed?
• If the firm also offers readiness services, how do they preserve their independence as your auditor?

Engage the firm early. They can confirm your scope and criteria before the observation period starts, which avoids surprises later.

How long should the Type II observation window be?

The observation period is the span over which the auditor tests whether controls operated. It commonly runs from three to twelve months. First reports are often shorter so a report reaches customers sooner. Later reports often cover twelve months, with each period starting where the last ended.

Start the window only when your controls are actually running. Every control has to operate throughout the period, and quarterly controls such as access reviews need to occur at least once inside it. Some organizations get a Type I first to give customers something sooner, then begin the Type II period.

A sample SOC 2 readiness timeline

Every organization moves at a different pace. This is a typical sequence for a first Type II:

Frequently asked questions

Do we need a Type I before a Type II?

No. A Type I is optional. It's useful when customers need something quickly or your controls are too new to have a track record.

Is SOC 2 a certification?

No. It's an attestation report containing an auditor's opinion. There's no pass mark, and readers decide whether it gives them enough assurance.

Can we use the same firm for readiness and the audit?

Sometimes, but independence rules limit what your auditor can do for you. Discuss it with the firm before you engage them for both.

Key takeaways

• Scope your first SOC 2 around the service customers are asking about, and start with the security criteria unless customer commitments call for more.
• Run an honest gap assessment and fix gaps before the observation period starts.
• Write policies that match reality, and make sure every control leaves evidence.
• Draft the system description early. It's a management document and a useful scoping check.
• Pick a CPA firm early, agree scope with them, and start the Type II window only when controls are running.