SOC 2 readiness assessment: scope, gaps and steps

What a SOC 2 readiness assessment is and when you need one

A SOC 2 readiness assessment is a pre-examination check of your system, controls and evidence against the AICPA's 2017 Trust Services Criteria. It tells you where you would likely fall short of the examination before a CPA firm tests anything, and it does not produce a report, opinion or certificate. Only the CPA firm that performs the examination issues a SOC 2 report. If a customer or bank deadline is close and you cannot say how ready you are, the assessment is the step that turns that uncertainty into a list of gaps you can plan to close.

The answer to whether you need one depends on four things: the system in scope, the trust services categories you add to security, whether your customer needs a Type 1 or a Type 2 report, and how much evidence already exists. The 2017 criteria contain 61 criteria in total, of which 33 are the common criteria (CC1.1 to CC9.2). The common criteria apply to every SOC 2, so the assessment always starts there. The availability, confidentiality, processing integrity and privacy criteria add to that baseline only when you include those categories. A team that has written policies but cannot yet show a year of access reviews, change approvals or incident records will usually need a different plan from a team that already produces that evidence routinely.

Before commissioning an assessment, confirm three things in writing with the requesting customer: which categories they expect, whether they accept a Type 1 as an interim step, and which system boundary they mean. Those answers define what the assessment should cover. Ask any provider whether the CPA firm that will issue your report can also perform the readiness work, because that question determines the independence limits covered later on this page.

How to run a SOC 2 readiness assessment step by step

A readiness assessment works through the system, categories, description, controls, gaps and evidence in a fixed order, so each phase produces an artifact the next phase depends on and the organization knows what the CPA firm will test.

Define the system and its boundaries
Management identifies the products, services, infrastructure, data flows, people and locations that deliver the service to customers, then decides which are inside the examination and which are excluded. Cloud providers and other subservice organizations are identified here, because how they are treated (inclusive or carve-out) changes what the report covers. Ask your CPA firm to confirm the boundary before controls are mapped. The output is a written system boundary statement and a list of in-scope and subservice organizations.
Select the trust services categories
Security is always in scope, because the common criteria CC1 to CC9 apply to every SOC 2. Management then decides whether to add availability, confidentiality, processing integrity or privacy, based on commitments made to customers and what the service actually does with data. Each added category brings its own criteria, and privacy adds points of focus to several common criteria. The output is a documented category decision with the reason for each choice, reviewed against customer contracts.
Draft the system description against DC 200
Management writes the system description using the AICPA's 2018 description criteria (DC 200), covering the services, infrastructure, software, people, procedures and data, along with the controls relevant to the criteria in scope. It also identifies complementary user entity controls and the controls expected of subservice organizations. The draft is checked for accuracy against how the system actually runs, not how the policy says it should. The output is a draft system description that the CPA firm can evaluate for fair presentation.
Map existing controls to the criteria
The team builds a control matrix that links each in-scope criterion to the control that addresses it, the owner of that control and the system where it operates. Common criteria CC1 to CC5 restate the COSO principles, while CC6 to CC9 cover access, operations, change management and risk mitigation, so each area needs named controls. Points of focus are used as design aids, not as a checklist. The output is a control matrix with every in-scope criterion mapped to at least one control or a documented gap.
Test control design and log gaps
Each mapped control is reviewed to decide whether it is designed to meet its criterion and whether the owner can describe how it works in practice. Walkthroughs with the people who run the control, and review of the configuration or policy that governs it, are the usual methods. Where a control is missing, informal or inconsistently applied, the gap is logged with the criterion affected, the owner and the proposed fix. The output is a gap register that management can prioritize and track to closure.
Remediate gaps and document the changes
Owners implement fixes such as updated access reviews, written policies, change approval steps, monitoring or vendor reviews, and the team confirms each fix works as designed. Where a remediation changes the system, the system description and control matrix are updated to match. Some organizations use an implementation partner for the technical work, while management keeps ownership of the decisions and the resulting controls. The output is a closed gap register and an updated, consistent set of controls and descriptions.
Collect and organize evidence
For each control, the team gathers the records that will show it operated: tickets, approvals, access review sign-offs, training completions, log samples, scan reports and similar items. Evidence is stored by criterion and control so the CPA firm can request samples without delay. Gaps in recordkeeping are treated as control gaps, because an auditor cannot test what was not retained. The output is an evidence library mapped to the control matrix, with a named owner for each evidence source.
Confirm readiness with the CPA firm
Management reviews the assessment outputs and confirms the system description, control matrix, gap closures and evidence library are complete and accurate. Where the readiness work was done by a firm that will also issue the report, independence limits apply under the AICPA Code, so management should confirm with the CPA firm which tasks it may perform. The examination itself is performed and reported only by an independent CPA firm. The output is a signed-off readiness package that management and the CPA firm both accept as the starting point for the examination.

What must be in place before the examination starts

A CPA firm can only test what it can see, so readiness means having the boundary, description, control design, ownership and records in place before fieldwork begins. The cards below cover each item, how to check it, and why a set of documents alone does not show that controls work.

A defined system boundary

Write down which products, services, environments, data stores, people and locations are inside the examination. Name the infrastructure the system runs on, and state whether cloud providers are included or carved out. To check it, trace one customer request from the public endpoint through every component that touches it, then confirm each component appears in the boundary or is explicitly excluded with a reason.

A written system description

Draft the system description that the report will carry, prepared against the AICPA's 2018 description criteria (DC 200). It should cover the services, infrastructure, software, people, procedures and data for the boundary. Check it by giving the draft to an engineer who did not write it and asking whether they can locate each control the description claims.

A control matrix mapped to the criteria

Build a matrix that lists each control, its owner, its frequency, the evidence it produces and the Trust Services Criteria it addresses, starting with the 33 common criteria. Every in-scope criterion should have at least one control, and every control should trace back to a criterion. Check for gaps in both directions: criteria with no control, and controls that serve no criterion.

Points of focus are not a checklist

The points of focus under each criterion describe characteristics that can help design and evaluate controls. They are not separate requirements, and not every point of focus must be addressed. Check whether each control achieves the criterion's objective in your environment, and record why any point of focus is not relevant. Teams that tick every point of focus often produce controls that are real on paper but do not fit how the system runs.

Policies approved by management

Each policy that a control relies on needs a current version, an approval by management, a review date and a record that staff acknowledged it. Check that the policies match what engineers actually do, since a policy that describes a process nobody follows becomes an exception in the report. Ask whether the policy set covers access, change management, incident response, vendor management and risk assessment.

Named owners for each control

Assign one accountable owner to every control in the matrix, using a person who can perform or approve the activity. Owners should confirm their control at a set frequency and understand what evidence they must produce. Check the matrix for owners who have left the company, roles shared by several people, or controls assigned to a tool rather than a person, because a tool cannot answer an auditor's questions.

A working evidence repository

Set up one location where each control's evidence is stored in a consistent format, labeled by control ID and date. Evidence can include tickets, access review exports, change approvals and scan results. Check that you can retrieve a sample from any control within a short time, and that the records are protected from edits after the fact. Self-hosted tools such as ticketing systems and log stores can generate much of this evidence, but the organization still has to confirm that the output is complete.

Operating history for the controls

Before the examination window opens, run each control long enough to produce several examples of it working. For a Type 2 report, the controls must operate across the period the auditor tests, so gaps in this history become exceptions. Ask your CPA firm how many occurrences it expects for each frequency, and record any control that has not yet run as a first occurrence rather than a finished one.

How to map controls to the Trust Services Criteria without overbuilding

The mapping work starts with the common criteria CC1 to CC9, which apply to every SOC 2 whatever categories are in scope. CC1 to CC5 restate the 17 COSO internal control principles, covering the control environment, communication, risk assessment, monitoring and control activities. CC6 to CC9 add the criteria that most readiness projects spend their time on: logical and physical access (CC6), system operations (CC7), change management (CC8) and risk mitigation, including vendor risk (CC9). For each criterion, write down which existing control, owner and evidence answers it. If no control answers it, that is a gap to remediate. If several criteria point to the same control, record the overlap once rather than building a parallel control for each criterion.

The NIST Privacy Framework crosswalk to the 2017 TSC, posted in November 2023, is a useful starting point for this matching exercise, and the NIST resource page offers it as a way for privacy and GRC teams to organize readiness work. Treat it as a draft, not an answer key. The crosswalk carries no guarantee of accuracy, so check each row against the AICPA's own 2017 Trust Services Criteria with revised points of focus and against your environment. Ask your CPA firm early which mapping it expects to test, because a mapping that the auditor does not recognize can cost time later.

Points of focus help you design and judge controls, but they are not a separate checklist. The TSC states that not every point of focus has to be addressed. Building a control for every point of focus is a common way to overbuild, adding tickets, approvals and evidence that nobody reviews. If privacy is in scope, nine common criteria carry additional points of focus: CC1.3, CC1.5, CC2.2, CC2.3, CC6.1, CC7.3, CC7.4, CC8.1 and CC9.2. Map those nine first, and decide with the auditor which of their points of focus your system's design actually needs.

Who owns the controls, who prepares them and who attests

The organization being examined owns its controls, its policies, its people and every final decision about scope and risk acceptance. In a SOC 2, management writes the system description, states its assertion and signs written representations that the examiner relies on. Those commitments cannot be delegated to a consultant or a tool, even when outside help does most of the drafting. Management also decides which trust services categories to include and which risks to accept, and it answers for those choices to customers and the auditor.

Controls and policies: Management approves the information security policy, access rules, change process and incident procedures, and staff must actually follow them.
People and accountability: Named owners run recurring tasks such as access reviews, vendor reviews and training, and they produce the records.
Scope decisions: Management chooses the system boundary, the locations, the services and the categories, and it documents why.
Written representations: Under AT-C section 205, management gives the CPA firm written representations, and the examiner treats them as part of the evidence.
Risk acceptance: Any gap that remains open after readiness work is a management decision that must be recorded.

Before you engage anyone, confirm that a named executive can explain each control and sign off on the system description.

When the CPA firm that will issue the report can also help prepare

The CPA firm that issues your SOC 2 report is bound by independence rules that limit how much it may help you prepare for that same examination. Service auditors apply the AICPA Code of Professional Conduct in full, with limited modifications to the Independence Rule for SSAE engagements under ET 1.297. In practice, a firm that designs your controls, writes your policies or builds your evidence library may find that its later testing of those same controls is compromised. The Journal of Accountancy's April 2026 discussion of ethics risks with tool providers covers the same concern for arrangements where a firm and a tool vendor work together, and the AICPA's 2026 guidance on auditor and tool vendor arrangements sets out the risks a firm must weigh. Before you sign anything, confirm with the firm's engagement partner, in writing, which preparation work it may perform without impairing its independence.

Keep preparation and testing in separate hands wherever you can. Preparation includes drafting the system description, mapping controls to the criteria, closing gaps and organizing evidence, and the organization owns that work. Testing is the firm's job, and it should rely on evidence the organization produced, not on controls the firm built for you. Ask the firm to list, by activity, what it will do for readiness, who on its team will do it, and whether those people will also perform fieldwork. If a single person would design a control and then test it, treat that as a decision to revisit. An independent readiness assessor, separate from the issuing firm, can cover the preparation side, and the cost and scope of that choice belong in your written scope.

Write down the answers before fieldwork begins and keep them in the engagement file. A short memo listing permitted preparation activities, excluded activities and the firm's independence confirmation gives you a reference if a customer or banking reviewer asks how the report was produced. Confirm too that any tool vendor the firm recommends does not create a financial or referral arrangement that the AICPA guidance would flag. Where the firm cannot give a clear answer, the safer course is to prepare with a separate party and let the firm test the result.

What makes a readiness assessment deeper or shallower

A readiness assessment grows or shrinks with a handful of decisions made before any control is mapped. Each driver below changes how many systems, criteria, vendors and policies the assessor must examine, and each one can be narrowed or sequenced deliberately.

Systems and locations in the boundary

Every production system, data store, administrative console and office or remote location inside the boundary needs its own access, change and monitoring evidence. A single product on one cloud account is far shallower than a platform spread across several accounts, regions and a self-hosted data center. Before mapping controls, list each system and location, then ask which ones actually store or process customer data. Systems outside that path can often be excluded with a documented rationale.

Third parties and subservice organizations

Each cloud provider, hosting company, identity service or support tool that touches the system either falls inside the description as an inclusive subservice organization or sits outside it as a carve-out. Carve-outs reduce the readiness work on the vendor, but the organization still must review that vendor's own SOC report and document complementary subservice organization controls. Ask whether each vendor provides a current report and a bridge letter, because gaps there create extra work late in the cycle.

Additional trust services categories

Security alone runs on the common criteria CC1 to CC9. Adding availability, confidentiality, processing integrity or privacy adds criteria, and privacy adds points of focus to nine common criteria. Each category added multiplies the controls to design, document and test. Sequence the work by starting with security, then adding a category only when a customer or contract requires it, so the first examination stays focused on what the buyer actually asked for.

Existing policies and evidence

The depth of a readiness assessment depends heavily on what already exists. An organization with approved policies, dated access reviews, ticketed changes and centralized logs needs a mapping exercise and some remediation. One that relies on undocumented practice needs policy drafting, process design and months of evidence generation before the examination. Inventory existing artifacts against each criterion, note their owner and last review date, and record which ones an auditor could sample without explanation.

Type 1 or Type 2 target

A Type 1 report tests control design as of a date, so readiness focuses on whether controls exist and are described correctly. A Type 2 report also tests operating effectiveness over a period, so the assessor expects consistent evidence across that window. Aiming at Type 2 without a stable control set usually means the readiness work must cover the controls for the whole observation period. Ask the CPA firm and any readiness provider which report type the assessment is preparing for before setting its depth.

Access and change process maturity

Common criteria CC6 and CC8 generate the most evidence requests, so the maturity of identity and change processes sets the workload. Check whether joiner, mover and leaver steps are tied to an authoritative source, whether production access is granted through tickets and reviewed, and whether infrastructure and application changes pass through peer review with recorded approval. Gaps here often require tooling changes rather than paperwork, so they are worth identifying early in the assessment.

Which readiness option fits: in-house, consultant or platform

This table compares building SOC 2 readiness in-house, hiring a readiness consultant or implementation partner, and using a compliance automation platform. Read each column for what the option can do, what it cannot do, and when it fits, then decide which combination matches your team's skills and deadlines. The main takeaway is that none of the three options issues the report, so the CPA firm's independence and the organization's own control ownership stay fixed regardless of which path you choose.

Option	What it can do	What it cannot do and when it fits
In-house team	Scopes the system, writes policies, maps controls to the Trust Services Criteria, and collects evidence using the organization's own staff	Cannot issue a report or guarantee the result. Fits when staff already know the systems and have time for sustained remediation work
Readiness consultant	Runs a gap assessment, drafts the control matrix and system description, and coaches owners through evidence collection	Cannot issue a report or own controls. Fits when the team lacks SOC 2 experience and wants an outside review before the CPA firm starts
Implementation partner	Prepares and hardens the infrastructure, configures logging and access controls, and documents the evidence those controls produce	Cannot issue a report or decide the scope alone. Fits when the controls depend on self-hosted platforms that need engineering work before evidence exists
Compliance automation platform	Tracks tasks, stores policies, links integrations, and gathers evidence from connected tools on a schedule	Cannot decide what the controls should be, verify that they operate, or replace the CPA's testing. Fits when the team needs a central record and reminders
CPA firm (readiness work)	May offer readiness support, but independence rules limit what the firm can prepare for the report it will issue	Cannot prepare and attest to the same controls without independence limits. Confirm the boundary with the firm before engaging it for preparation
Hybrid model	Splits ownership: staff own controls, a consultant or partner prepares evidence, and a platform tracks tasks	Cannot remove the need for management ownership. Fits when deadlines are fixed and internal capacity is limited

What to check before hiring a readiness partner

A readiness partner prepares your systems, controls and evidence, but it cannot issue the report. The checks below separate a partner that strengthens your examination from one that blurs roles or leaves gaps in documentation.

Confirm the partner does not issue the report

Only an independent CPA firm can examine your controls and issue a SOC 2 report. Ask the partner to state in writing that it will not sign, attest or certify anything, and that your report will come from a separate CPA firm. A partner that describes its work as certification, or promises a report, has misunderstood the examination or is misrepresenting it. Ask which deliverables it will hand over and confirm that management, not the partner, owns each control and the description.

Ask how deliverables are documented

Readiness work produces the control matrix, gap register, policies, procedures and evidence samples that the CPA firm will later test. Ask for the file formats, version control and naming conventions, and whether each deliverable maps to a specific Trust Services Criterion. Confirm who keeps the source records after the engagement ends, so your team can answer auditor requests without the partner present.

Request references and relevant experience

Ask for examples of readiness work on systems similar to yours, including the hosting model, the categories in scope and whether subservice organizations were carved out or included. Request references you can contact, and ask what the partner delivered and what the CPA firm later reported. Treat unverifiable claims, or refusals to name any past engagement under confidentiality, as a reason for more questions.

Verify the CPA firm was consulted

If the partner also helps prepare the system, the CPA firm that will issue the report must confirm that the arrangement does not impair its independence. The AICPA Code applies to SOC 2 examinations with limited modifications for SSAE engagements. Ask the partner for the CPA firm's written view, or ask the CPA firm directly, before any work starts, so that a conflict does not surface after the report is drafted.

Require a written scope before work

Agree on the system boundary, the Trust Services Criteria in scope, the locations, the subservice organizations and the deliverables before work begins. DeployOpen works on fixed scope agreed in writing, and a written scope lets you compare proposals on the same basis. Ask any partner to state what is excluded, what happens if the scope changes, and how change requests are priced and approved.

Check how gaps are handed back

A readiness assessment should end with a prioritized list of gaps, owners and dates, not a general opinion that controls are ready. Ask how the partner will record each finding, whether it will retest remediated controls, and what evidence it will produce to show a fix works over time. Confirm that the partner will not edit historical evidence to make a gap disappear before the examination period begins.

Questions buyers ask about SOC 2 readiness assessments

Is a SOC 2 readiness assessment required by law?

No. A readiness assessment is an optional preparation step, and no law mandates SOC 2 or any readiness review. Customers, banks and partners ask for a SOC 2 report because their own vendor reviews and contracts require it. The examination itself is what those parties usually want to see, so the readiness step exists to make that examination go smoothly. Ask the customer or regulator who is requesting the report whether they accept a Type 1 first, what period they expect a Type 2 to cover, and whether they need a readiness review at all. Their answer determines whether this work is worth doing before the examination begins.

How much internal time does a SOC 2 readiness assessment take?

The internal time depends on how many systems, teams and vendors are in scope, how documented your controls already are, and how many gaps the assessment finds. The biggest drivers are usually the system description, access reviews, policy approval and collecting evidence from engineering, HR and operations. Expect a named owner from engineering, one from security or IT, and someone from people operations to answer questions and approve documents. Ask the firm you hire to list the staff roles, meeting cadence and evidence owners in writing before work starts, so you can plan around the time rather than discovering it during fieldwork.

Can we run a SOC 2 readiness assessment ourselves?

Yes, an organization can run its own readiness review, provided someone understands the Trust Services Criteria, the 2018 description criteria and how an examiner samples evidence. The work includes scoping the system, mapping controls to the criteria, identifying gaps and collecting evidence. Teams that have run an internal audit or security program often manage it well, while teams new to the framework tend to miss criteria that are not obviously about security, such as vendor management or change management. An outside implementation partner can prepare systems, controls and evidence, but only an independent CPA firm can examine them and issue the report.

How does a readiness assessment relate to the Type 1 or Type 2 date?

A readiness assessment happens before the examination and is not a report. A Type 1 report looks at whether controls are designed suitably as of a specific date, so readiness work should finish before that date. A Type 2 report also tests whether controls operated effectively over an observation period, so readiness should identify controls that will operate consistently for the whole period. Gaps found late can push the date back. Agree the target report type and date with your CPA firm and the customer who needs the report, then schedule the readiness work backward from that date.

Does a readiness assessment guarantee a clean SOC 2 report?

No. A readiness assessment shows where your controls, documentation and evidence stand against the criteria, but the final opinion belongs to the independent CPA firm after it tests the controls. Its opinion can include exceptions, and a qualified opinion is possible. A readiness review reduces surprises by finding gaps before the examiner does, yet it cannot promise the examiner will reach a particular conclusion. Ask any provider to describe what the assessment covers, what it does not cover, and how findings are documented, rather than to promise an outcome.

What should we ask a CPA firm about independence before it helps us prepare?

Ask whether the firm will issue the report and whether it will also prepare you for it, because the answer affects independence. Under the AICPA Code, service auditors apply the Code in full with limited modifications for SSAE engagements, so a firm's preparation work can create threats to independence. Ask which services it would provide, who on the team would do them, whether it has conflicts with any tool vendor it recommends, and how it documents independence decisions. Get the answers in writing. If you need preparation support, ask the CPA firm to confirm what it will not do, and consider a separate firm for readiness work so the examiner stays independent of the controls it tests.

Which parts of a readiness assessment should a consultant or partner do?

A consultant or implementation partner can review your system boundary, map controls to the criteria, draft or refine policies, configure tooling and organize evidence. Your organization still owns its controls, its risk decisions and its management assertion, and it must operate those controls day to day. The CPA firm then tests them independently. Ask any outside party for a written list of deliverables, what they will not do, who on their team will do the work, and how handoff to your staff will happen. The quote should follow from that written scope.

How DeployOpen prepares systems and evidence for your SOC 2

DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, so the systems and records a SOC 2 readiness assessment examines are the ones you run. We prepare systems, controls and evidence for the examination, while your organization owns its controls and an independent CPA firm alone issues the report.

How we scope

Fixed-scope engagements, with the systems, categories, locations and deliverables agreed in writing before work starts.
Written scope names the in-scope system boundary, including platforms, environments and any cloud or subservice providers involved.
We confirm which Trust Services Categories beyond security are included, so the control set matches your commitments.

How we build

We map existing and planned controls to the Common Criteria and any added categories, recording gaps against each criterion.
Remediation covers access, logging, change management and backup configuration on the self-hosted platforms in scope.
We document control procedures and build repeatable evidence collection, such as access review exports and configuration records.

How we hand over

You receive a control matrix, gap register, policy set and evidence index that your CPA firm can review directly.
Handover includes runbooks explaining how each control operates, who owns it and how often the evidence is produced.
We do not write the system description or management assertion for you, so your leadership reviews and signs them, and your CPA firm evaluates them.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the readiness work is complete.
Retainers can keep evidence current between examination periods, which matters for a Type 2 observation window.
Ask us to confirm in writing which items remain with your team, your auditor and your tooling vendors after handover.