SOC 2 audit checklist: from scoping to report

A first SOC 2 runs in a fixed order: define the system, map controls to the criteria, write the description, settle CUECs and subservice treatment, engage a CPA firm, collect evidence and sign the assertion. This checklist shows what each step produces and who owns it.

Book a callTalk to us
On this page

What a first SOC 2 audit checklist must cover before the CPA starts

If a customer or contract requires a SOC 2 report, the report is issued only by an independent CPA firm, and only after your organization has defined its system, its controls and its written assertion. The work runs in a fixed sequence, from scoping to report, and the CPA does not start fieldwork until the front end of that sequence is settled. Before the first conversation with a firm, your team should be able to state which trust services categories are in scope, whether the engagement is a Type 1 or a Type 2, and which systems, locations and vendors sit inside the boundary. The actual cost and timeline depend on those choices and on how mature your evidence already is, so ask any firm to quote from a written scope rather than a template. No figures for fees or durations are given here beyond what the AICPA publishes.

Ownership is the point most first-time teams get wrong. Your organization owns its controls, its system description and its management's assertion. An implementation partner can prepare systems, configure logging and access tooling, and assemble evidence, but it cannot run your controls, sign your assertion or stand in for the auditor. The CPA firm must remain independent of the work it examines, which is why a firm that writes your controls may be unable to test them. Confirm in writing which party drafts the system description, which party collects each evidence source and which party signs the assertion, and check with the proposed firm how it maintains independence if it is also offering preparation help.

The SOC 2 audit checklist, step by step

This sequence takes an organization from an undefined scope to a signed SOC 2 report, with each step producing a document or record that the next step depends on.

  1. Define the system and trust services categories

    Management names the system, its boundaries, the services it delivers and the customer commitments it makes. It then chooses the trust services categories in scope. Security is always included through the common criteria CC1.1 to CC9.2 (33 criteria). Availability (A1), confidentiality (C1), processing integrity (PI1) and privacy (P1 to P8) are added only when the organization decides they belong in scope and customers need them. The output is a written scope statement listing the system, its components, the categories and any criteria judged not relevant. Confirm the scope with the CPA firm early, because it drives every later step. Owner: the executive sponsor, with the CISO or head of engineering.

  2. Map controls to the 2017 Trust Services Criteria

    The control owner team writes or confirms the controls that operate the system, then maps each control to the criteria it addresses. The 2017 Trust Services Criteria carry points of focus, which are characteristics that help design and evaluate controls. They are guidance, not separate requirements, so not every point of focus needs its own control. The output is a control matrix that shows each criterion, the control or controls that address it, the owner of each control, the evidence source and the review frequency. Owner: the CISO or compliance lead, with each control owner confirming their entries.

  3. Write the system description against DC1 to DC9

    Management writes the description of the system and evaluates it against the nine description criteria in the AICPA's 2018 SOC 2 description criteria (DC 200). The nine criteria, DC1 to DC9, cover the types of services, service commitments and system requirements, system components, significant incidents, applicable criteria and related controls, complementary user entity controls, subservice organizations, criteria not relevant to the system, and significant changes during the period. The output is a draft description that a reader can use to understand the system without seeing internal documents. Owner: the compliance lead, reviewed by engineering and legal. Check that each of DC1 to DC9 has a clear answer in the draft.

  4. Settle CUECs and subservice organization treatment

    Management decides which complementary user entity controls (CUECs) to list, meaning controls that customers must run themselves for the system's controls to work. It also decides how to treat each subservice organization, such as a cloud hosting provider, using either the carve-out method or the inclusive method. Under carve-out, the provider's controls are excluded from the examination and listed as complementary subservice organization controls. The output is a list of CUECs and a documented subservice treatment for each vendor, plus the provider reports collected for review. Owner: the CISO with vendor management, and legal where contracts define responsibilities. Confirm with the CPA firm that the chosen approach matches the scope.

  5. Vet and engage the CPA firm

    Before signing, the organization vets candidate firms. The Journal of Accountancy advised in February 2026 that service organizations check the firm's size and capacity, references, qualifications and peer review results, and ask about examination scope, sampling methods and how the firm keeps its independence. Verify the individual CPA licenses through the state boards and CPAverify where applicable. The output is a signed engagement letter that states scope, report type (Type 1 or Type 2), the examination period, fees and responsibilities. Owner: the executive sponsor and procurement, with the CISO. The engagement letter should be reviewed before work starts, because it sets what the firm will test.

  6. Collect and organize evidence for the auditor

    Control owners gather the records that show each control operated as described. The auditor will request populations and samples, and will test through inquiry, observation, inspection and reperformance. Prefer system-generated reports with dates and parameters over screenshots, and keep evidence for the full period in a single repository so it can be pulled quickly. The output is an evidence index keyed to the control matrix, with an owner and location for each item and a record of any control exceptions found internally and how they were corrected. Owner: each control owner, coordinated by the compliance lead. Test a sample of evidence before fieldwork begins to confirm it answers the control.

  7. Support fieldwork and resolve findings

    During fieldwork the auditor tests the controls, asks follow-up questions and may request additional evidence. The organization assigns one point of contact to route requests, track open items and record answers. Exceptions found by the auditor are discussed with management before the report is drafted, so that the description and the test results match the facts. The output is a closed request log and a list of agreed exceptions with management responses. Owner: the compliance lead, with control owners answering their requests. Do not change historical records to fit a finding, because the auditor will test that the evidence is contemporaneous.

  8. Sign management's assertion and the representation letter

    Management signs its written assertion about the fairness of the system description and the design and, for Type 2, the operating effectiveness of the controls. Under AT-C section 205 the service auditor must obtain written representations from management in a letter addressed to the auditor. The AICPA's illustrative Type 2 letter applies to reports dated on or after June 15, 2022. The output is the signed assertion and representation letter, dated consistently with the report and the examination period. Owner: the officers named in the assertion, typically the CEO and CISO or CTO. Confirm the signers before the letter is drafted, and do not sign until the description matches the final test results.

  9. Receive the report and plan the next period

    The CPA firm issues the report. For a Type 2 report, the four parts are management's assertion, the system description, the service auditor's report and the tests of controls with results. The organization reviews the report for accuracy, then decides how to share it under the restrictions that apply to SOC 2 use. The output is the issued report, a list of any exceptions to address, and a plan for the next examination period. Owner: the executive sponsor and compliance lead. Treat the report as a record of past periods, and keep the control matrix current so the next examination starts from accurate documentation.

How to define the system and categories before mapping controls

Scope comes first because every later step depends on it. Before any control is written, decide what the system boundary covers: the services, the production environment, the people who operate it, the data it stores and processes, and the locations and tenants involved. Then decide which legal or organizational entity the report describes, whether that is the whole company, a subsidiary or a division. The 2017 Trust Services Criteria can be applied to controls across an entire entity or at narrower levels, so a company with several product lines may reasonably scope one of them. Write these decisions down, because the auditor will test the boundary as well as the controls inside it.

The security category applies to every SOC 2, and its common criteria CC1.1 to CC9.2 form the base of the examination. The four other categories, availability, confidentiality, processing integrity and privacy, are added only when your customers' commitments make them relevant. Ask your largest customers and your contracts which commitments you have made about uptime, data handling, accuracy of outputs or personal data, and include only the categories those commitments support. Adding a category is not free: it brings its own criteria, controls and evidence, so confirm with the CPA firm how each addition changes the testing before you commit.

A clear boundary is what keeps the work bounded. Every system component inside scope needs an owner, a control and evidence, and every component left out must be explained in the system description and justified against the criteria that are not relevant. A narrow boundary usually means fewer controls, smaller samples and fewer evidence sources for the auditor to request. Before relying on a NIST Privacy Framework crosswalk to the 2017 TSC to speed this work, read the AICPA 2017 Trust Services Criteria directly and check the crosswalk against your own environment. NIST presents it as a starting point, without a guarantee of accuracy.

What must be in place before the CPA firm starts fieldwork

Fieldwork goes quickly only when the system boundary, controls, description and evidence already agree with each other. The six items below are the decisions and records an auditor expects to find on day one, and each one should be checked against the others before the CPA firm is engaged.

A defined system boundary

Write down which services, infrastructure, people, data and locations make up the system in scope, and which are excluded. Confirm the scope against the customer commitments the report must support, including whether availability, confidentiality, processing integrity or privacy categories apply. Auditors will ask how the boundary was chosen and will test whether anything that touches customer data sits outside it without a stated reason.

A control matrix mapped to criteria

Build one control set and map each control to the applicable common criteria and any additional categories in scope. Every criterion in scope should point to at least one control, and every control should name an owner and a frequency. Auditors check the matrix against the system description first, so gaps or controls copied from a generic template are usually found here.

A written system description

Prepare the description of the system against the DC 200 description criteria, covering services, system components, significant incidents, relevant criteria, related controls and significant changes in the period. Check that each statement matches what engineers would describe if asked. Auditors read the description alongside management's assertion, so any mismatch becomes an exception before testing begins.

CUECs and subservice treatment settled

List the complementary user entity controls customers must run, and decide whether each subservice organization, such as a cloud or hosting provider, is included or carved out. For carve-outs, collect the provider's current SOC report and list the complementary subservice organization controls. Confirm that customers receive these lists in the description, since the auditor will test the lines between your controls and theirs.

Policies and owners for each control

Confirm that each control has an approved policy or procedure, a named owner with the authority to run it, and a record of the last review. Check that owners can explain their control in their own words and show where its evidence lives. Auditors often ask who performs a control and who reviews it, so a control without a named person is hard to defend.

A first pass of operating evidence

Run each control for a short trial period and collect the output the auditor will expect, such as system-generated access lists, change tickets, alert records and completed reviews. Walk through a sample of each population to confirm the evidence is complete, dated and traceable to the control. Gaps found now can be fixed before the observation period starts, while gaps found during fieldwork become exceptions in the report.

Who owns each step: the organization, the partner and the CPA firm

The service organization owns the SOC 2 from start to finish. Its leadership decides the system boundary, which Trust Services Criteria categories are in scope, and which controls operate to meet them. Management writes the system description, signs the management's assertion, and gives the CPA firm its written representations at the end of fieldwork. None of these steps can be delegated to a consultant or a tool vendor, because the report describes what the organization says it does.

  • System boundary and scope: Leadership defines the systems, services, locations and teams covered, and records the reasons for excluding anything.
  • Control design and ownership: Each control has a named owner who runs it, keeps its records and answers for its results.
  • System description: Management writes the description against the DC 200 description criteria and keeps it accurate as systems change.
  • Assertion and signatures: Management signs the assertion and the representation letter, and it must be able to stand behind every sentence in them.
  • Subservice and customer dependencies: The organization decides how cloud and other vendors are treated and which complementary user entity controls it expects customers to run.

Check that each control has a named owner and that the people who sign the assertion have reviewed the system description personally.

Settling CUECs and subservice organizations early

Complementary user entity controls (CUECs) and subservice organization treatment should be settled before you collect a single piece of evidence. Both decisions shape the system description, and the system description defines what the auditor tests. If you start gathering evidence first and decide later whether a cloud host is carved out or included, you will likely rebuild the description and re-scope populations. Write down the CUECs you expect customers to run, such as managing their own user accounts, reviewing their own integration logs, or approving their own data deletion requests, and confirm each one against what your product actually asks of customers. The list will feed the description criteria for CUECs in DC 200 and the customer-facing reading of your report, so it needs to be accurate rather than generous.

For each subservice organization, including the cloud provider, decide between the carve-out method, where its controls are excluded from your description and its services are covered by complementary subservice organization controls (CSOCs), and the inclusive method, where its controls are described and tested as part of your system. This choice determines which controls you own and which you rely on a third party to evidence. The AICPA's SOC 2 Report Walkthrough covers CUECs, CSOCs and inclusive versus carve-out reporting in detail, so it is a sound reference for the internal team and anyone preparing the description with you. Confirm with your CPA firm which approach it expects before drafting.

Using a cloud provider's SOC report is a separate evidence task, not a substitute for your own. Ask the provider for its current report and any bridge letter it offers, read its complementary user entity controls, and map each one to a control you operate. Then check the report's period against your examination period and note any gaps your own controls must cover. Your vendor oversight work under CC9.2 should record that review. Confirm with the provider where its report and bridge letter are available and under what terms, since access routes and confidentiality conditions vary by vendor.

How to vet the CPA firm before you engage it

A SOC 2 report is only as useful as the firm that signs it, so vetting happens before any fee is agreed. The cards below cover the firm's capacity, track record, people, peer review, independence, and how it will test your controls, plus the license and engagement terms to confirm in writing.

Size and capacity

Ask how many SOC engagements the firm runs at once, who will lead fieldwork, and whether the same people stay with you through the observation period. A firm stretched across too many reports may schedule fieldwork around its own calendar rather than yours. Ask for the names and roles of the staff who will test your controls, and for the review process that sits above them before the report is issued.

References and comparable clients

Ask for references from service organizations of similar size, architecture and industry, and ask whether the firm has examined companies that run on self-hosted or cloud-native infrastructure. Speak to those references about the audit process, how the firm handled exceptions, and whether timelines held. Treat any firm that promises a fast or guaranteed outcome as a reason for closer questions, not a reason to hire.

Qualifications and licensing

Confirm that the firm and the engagement partner hold current CPA licenses and that the firm is registered to perform attest work. Check the license through the relevant state board and through CPAverify, the NASBA-run lookup, rather than relying on a copy of a certificate. Ask who holds the engagement partner role and what SOC or attestation experience that person has.

Peer review results

Ask for the firm's most recent peer review report and its rating, then read the letter of comments and any corrective actions. Peer review is a required quality check for firms that perform attest work under AICPA standards, and it is one of the few independent signals of how the firm runs its engagements. Confirm the review covered accounting and auditing work relevant to attestation engagements.

Independence safeguards

Ask how the firm maintains independence from you, including whether it or its affiliates have designed, implemented or hosted the controls it will test. Ask whether the firm sells tools, GRC platforms or remediation services to the same client, since that can create a conflict that a reviewer will question. A firm that prepares your evidence and then tests it needs clear documentation of where that line sits.

Examination scope and sampling approach

Ask the firm to describe the scope it expects, the trust services categories it will cover, how it will select samples across the Type 2 period, and what populations it will need from you. Ask whether it uses the same sample sizes for every client, because identical samples across unrelated engagements are a warning sign. Get the answers in writing and compare them with the engagement letter before signing.

SOC 2 audit checklist questions buyers ask

How long does a first SOC 2 take from start to report?

No duration has been researched for this page, so the honest answer is that it depends on your starting point, the categories in scope and how many controls already run with evidence. Ask the CPA firm for a written plan with milestones for scoping, readiness, the observation period if you are going for a Type 2, fieldwork and report issuance. Ask which steps are on your critical path and which depend on your engineers' availability. Treat any firm that promises a fixed short timeline without reviewing your systems with caution, since the AICPA has publicly warned that fast and easy promises can threaten the credibility of SOC reports.

How much effort does a first SOC 2 ask of internal staff?

Effort lands mostly on the people who own systems, not on the compliance lead. Expect time from engineering for access configuration, logging, change records and vulnerability management, from HR for joiner and leaver records and training, and from leadership for the system description, risk assessment and the signed assertion. Effort is driven by how much of the control set already exists, how many systems are in the boundary and how well evidence is generated automatically. Ask any partner to estimate hours by role in writing before work starts.

Can our team run a first SOC 2 without an outside partner?

Yes, a team can run the program internally, but the organization owns every control and must be able to produce evidence for each one across the examination period. The questions to answer honestly are whether someone can build a control matrix mapped to the criteria, write a system description that meets the description criteria, collect populations for sampling and keep evidence consistent over months. An implementation partner can prepare systems, hardening and evidence collection, while only the independent CPA firm tests controls and issues the report. Decide early which work you keep in-house and which you buy, and document that split.

Can the auditor also prepare us for the SOC 2?

Usually not, and the reason is independence. An auditor who designs your controls, writes your policies or configures your systems is then testing its own work, which weakens the opinion that customers and regulators rely on. Professional standards and the AICPA's guidance on attestation engagements both expect the examining firm to stay independent of the controls it tests. Ask any firm how it maintains independence, whether it offers preparation services, and how those services are separated from the examination team. Preparation should come from a consultant or implementation partner, with the CPA firm kept at arm's length.

What changes between a Type 1 and a Type 2 SOC 2?

A Type 1 report describes the system and gives the CPA's opinion on whether the description is fairly presented and the controls are suitably designed as of a specified date. A Type 2 report adds an opinion on whether those controls operated effectively over a period of time, with the auditor testing samples across that period. In practice, a Type 2 needs controls running consistently for the whole observation window, reliable population reports and recurring evidence such as access reviews and change approvals. Plan the Type 2 observation period before choosing a Type 1 as a stepping stone, and confirm with the firm what its Type 1 will and will not tell your customers.

What could the proposed attestation standard changes mean for engagements starting June 15, 2029?

The AICPA Auditing Standards Board exposed proposed revisions to its baseline attestation standards in February 2026. If adopted, they would apply to engagements beginning on or after June 15, 2029, according to the Journal of Accountancy. No final text is settled, so do not plan around specific requirements yet. For a SOC 2 program, the practical step is to keep the control matrix, system description, representations and evidence repositories well organized and version-controlled, so that any new requirements can be absorbed at the next engagement. Ask your CPA firm how it will track the final standards and what it expects from management in response.

What usually delays a first SOC 2 and how to avoid it

The most expensive delay in a first SOC 2 is an unclear system boundary, and it should be caught at the scoping step, before any control is written. If the team cannot list which production environments, data stores, support tools and administrative consoles belong to the system, the system description, the control matrix and the auditor's sample populations will all drift apart. Confirm the boundary in writing with the CPA firm early, and check that every in-scope component appears in the system description. Scope decisions about which categories to include belong at the same step, because adding a category later means new criteria to design and test.

Copied template controls are the second common delay. A control set downloaded from a template or lifted from another company's report often describes processes the organization does not run, which makes the first fieldwork round a series of corrections. Map each control to the criteria during the mapping step, and for every control ask who performs it, in which system and how a reviewer would see it happen. Auditors and peer reviewers look for controls that are specific to the system. Reusing an ISO 27001 or NIST mapping is reasonable only after the controls have been checked against how the organization actually operates.

Evidence gathered as screenshots and vendor reports collected at the last minute cause the largest share of late nights before fieldwork. Screenshots are hard to tie to a population and a date, so auditors often ask for a system-generated export instead. During evidence collection, decide which system will produce each record, confirm that it can export the population for the full period, and set a recurring owner for it. Vendor reports for each subservice organization should be requested when the vendor is first assessed under CC9.2, not after the audit has started. Confirm with each provider whether its current report covers the period you need, and whether the report's own complementary controls apply to your setup.

How DeployOpen prepares systems and evidence for a SOC 2 audit

DeployOpen helps organizations prepare the systems, controls and evidence that a SOC 2 checklist calls for, from scoping through to the report. The organization keeps ownership of its controls and management's assertion, while an independent CPA firm performs the examination and issues the report.

How we scope

  • Engagements are fixed-scope, with the system boundary, categories and deliverables agreed in writing before work starts.
  • The written scope names the self-hosted open-source platforms, environments and infrastructure covered by the examination.
  • Scope also records which subservice organizations and customer-run controls need to be addressed in the system description.

How we build

  • We configure and harden the in-scope platforms inside your cloud accounts, data centers or air-gapped networks.
  • We map the agreed controls to the applicable Trust Services Criteria, keeping points of focus as guidance rather than checklist items.
  • We set up logging, access and change records so the evidence an auditor samples is produced by the systems themselves.

How we hand over

  • You receive documentation of the controls, configurations and evidence sources, written so your team can run them after handover.
  • Deliverables include a draft system description and evidence request mapping for your review before the auditor is engaged.
  • Your organization reviews and signs management's assertion and representation letter, which DeployOpen does not sign on your behalf.

How we support

  • Ongoing support, upgrades and continuous security testing are available as retainers after the initial engagement ends.
  • Retainers can cover evidence collection between audit periods, so a Type 2 observation period does not depend on one-off effort.
  • Confirm with your CPA firm which evidence formats it accepts before we configure reporting, since auditor requirements vary.

Sources and further reading

Related

Talk to our team.

Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.

  • 30-minute call: free, with no obligation.
  • NDA on request: we can sign before you share details.
  • Clear next steps: a scope and plan after the call.
Book a callhello@deployopen.com