How do auditors test SOC 2 controls during fieldwork?
When a customer or contract asks for a SOC 2, the CPA firm tests controls through inquiry, observation, inspection and reperformance, and it draws samples across the examination period rather than checking every event. The organization owns its controls and the evidence behind them. An implementation partner such as DeployOpen can prepare systems, configurations and records so that evidence exists and can be retrieved, but only the independent CPA firm performs the tests and issues the report. Expect the auditor to ask for different kinds of proof for each control, and plan for that before fieldwork starts.
The answer changes with three factors: how often the control runs, how large the population is, and how good the evidence is. A control that runs many times a day, such as an automated alert on production access, is tested on a sample from a large population, so the auditor will want the system-generated record and the logic behind it. A control that runs once a year, such as an annual risk assessment, is tested on a single occurrence, so the record of that one event must be complete. Manual controls that depend on a person's memory or an unreviewed screenshot give the auditor less to work with than a log or report the system produced on the date it was run.
Before fieldwork, check each control against those three factors. Confirm with the CPA firm how it will select samples and which periods it will cover, because the AICPA staff FAQs on SOC 2 engagements address sampling and testing of operating effectiveness and the firm's approach should match them. Ask whether it will accept system exports directly or needs them re-run, and how it will treat a control that did not operate for part of the period. Record these answers in the control matrix so that owners know what to retrieve and when. Reading the AICPA SOC 2 overview alongside the firm's engagement letter helps confirm that the scope and testing approach are understood by both sides.
Inquiry, observation, inspection and reperformance: what each test proves
Inquiry means the auditor asks control owners, managers or staff how a control works and who performs it. It is a necessary starting point, because it tells the auditor what the organization believes it does and where evidence should be looked for. On its own, though, an answer produces no record that the control ran. Take an access review control. An engineer may explain that managers review production access every quarter. That statement describes intent, not operation.
- What the auditor does: asks the owner to walk through the process, the frequency, the reviewer and the escalation path.
- What it produces: the auditor's notes of the answer, which are not evidence of operation by themselves.
- Why it is weak alone: people describe how a process should work, and may describe an idealized version of it.
- How it is paired: inquiry is combined with observation, inspection or reperformance so the answer can be checked.
- Typical example: asking who approves production changes before the auditor pulls the approval records.
The Journal of Accountancy warned in February 2026 that a rushed or overly automated SOC 2 report may rely too heavily on inquiry rather than thorough procedures. Check whether your auditor's fieldwork plan pairs each inquiry with documentary testing.
Observation means the auditor watches a control being performed as it happens. It shows that the process works in practice and that the person performing it knows the steps. Observation fits controls that leave little durable record, such as a physical badge check, a live deployment gate or an operator working through an alert queue. It is a single point in time, so auditors typically use it to supplement records rather than to cover a whole period.
- What the auditor does: watches a person run the control on a screen, at a desk or in a facility.
- What it produces: the auditor's own working paper recording what was seen, when and by whom.
- Why it is useful: it confirms the steps described in inquiry match real behavior.
- Why it has limits: the person may behave differently when watched, and one occurrence does not prove the control ran across the Type 2 period.
- Typical example: watching an engineer run a deployment pipeline and see the required approval gate block an unapproved change.
Organizations can prepare by scheduling walkthroughs with the actual operators and by keeping the system able to show the step being performed, not only a diagram of it. Confirm with your auditor which controls they intend to observe and whether a recorded or screen-shared session is acceptable.
Inspection means the auditor examines documents, records, configurations and system output that show a control operated. This is usually the strongest form of evidence in a SOC 2, because it leaves a trace the auditor can review after fieldwork. The quality depends on whether the record is complete, dated, attributable to a person and generated by the system rather than typed afterwards. A screenshot of a settings page is weaker than an export that shows the configuration and its timestamp.
- What the auditor does: reads approval tickets, review sign-offs, logs, configuration exports and training records.
- What it produces: a record of what was examined, the sample selected and whether each item met the control.
- Why it is strong: the record exists independently of anyone's memory of it.
- Why quality matters: an incomplete or editable record may draw an exception or lower the weight placed on it.
- Typical example: checking that each quarterly access review has a dated sign-off, the list of reviewed accounts and any removals made.
For access reviews, the evidence that usually passes is a system-generated population with reviewer sign-off and follow-up tickets. Confirm with your auditor which record formats they accept and how long the evidence must be retained.
Reperformance means the auditor independently carries out the control or recalculates its result to check that it works as described. It is the most direct test of whether a control is effective, because the auditor does not rely on anyone else's account of the outcome. It is often used for automated controls, where the auditor can test the logic by recreating the calculation or comparing the output to the input rules. It is also used for manual controls when a reviewer's judgment can be repeated on the same data.
- What the auditor does: reruns a report, recalculates a figure or repeats a check on the same population.
- What it produces: the auditor's own result, compared against the organization's result.
- Why it is strong: it tests the control rather than the story about the control.
- Why it needs preparation: the population and the logic must be reproducible, which requires stable reports and documented rules.
- Typical example: recreating a change approval check by comparing merged changes against approval records to find any deployed without sign-off.
Reperformance is a reason to keep system-generated reports with stable parameters and to document how automated rules are configured. Ask your auditor which controls they plan to reperform so you can prepare the populations in advance.
How samples are drawn across the Type 2 observation period
The auditor first defines a population for each control, meaning the complete set of items the control could have acted on during the period, such as every production access grant, every change ticket or every alert raised by monitoring. The auditor then decides whether to test the control across the whole observation period or at points within it, based on how often the control operates and how much reliance the auditor plans to place on it. A daily or weekly control generates many items and is usually sampled across the period, while an annual control may be tested once. The AICPA staff FAQs issued in December 2020 cover this sampling judgment, along with materiality and the appropriate period, and they are the place to start when your team wants to understand how an examination team reasons about these choices. The 2011 *Journal of Accountancy* article on service organization controls notes that there is no generally accepted minimum period for a Type 2 report, so the length of the window is a judgment tied to what users need, which you should confirm with your CPA firm before fieldwork begins.
For the auditor to draw items that reflect operation over time, the population has to be complete. Keep system-generated populations that the auditor can export and reconcile, such as identity provider user lists, ticketing system exports, deployment logs and SIEM alert records, with filters and date ranges documented. Ask the auditor to confirm how they will verify completeness and accuracy of each population, because a sample drawn from an incomplete list tells the reader nothing about the controls that were skipped. If a population is assembled by hand from several sources, expect the auditor to ask how you know nothing is missing. Confirm early which populations the auditor will request, and whether the sample will be drawn across the full period or in periods chosen by the auditor, since those choices determine what your team must retain and in what format.
What happens from the first evidence request to the draft report
The fieldwork sequence turns a scoped set of controls into tested results: each phase hands a defined output to the next, so management knows which exceptions exist before the report is drafted. The sequence is the same whether the engagement is a first Type 2 or a renewal, though the scale of each phase depends on scope.
Plan the engagement and walk through controls
The service auditor confirms the scope of the system, the criteria in play and the period under examination, then walks through each key control with the people who run it. In a walkthrough, the auditor follows one transaction or change from start to finish to confirm the control exists as described in the system description and the control matrix. The output is an agreed view of which controls are in scope and who owns each one, and any gap between the documented control and the actual process is raised now rather than during sampling.
Issue the evidence request list
The auditor sends a request list that names each control, the population the test will draw from, and the evidence that will be accepted. Management assigns an owner to each request, and the owner confirms whether the evidence is system-generated, such as an access report exported from a directory or ticketing system, or a document such as a signed policy or review record. The output is a tracked list in which every request has an owner, a source and a status, so the auditor can see which populations are complete before sampling begins.
Define populations and select samples
Once a population is complete, the auditor decides how many items to test and selects them across the whole examination period rather than from the most recent weeks. Selection depends on the control's frequency and the auditor's judgment about risk, and the auditor documents the basis for the sample size and the selection method. The output is a sample list tied to specific tickets, accounts, changes or review records, and management should confirm that the population is complete because a missing item can change the result of the test.
Test each sampled item and record the results
For each sampled item, the auditor uses one or more procedures: inquiry of the control owner, observation of the control being performed, inspection of the supporting record, or reperformance of the control by the auditor. Inquiry alone does not establish that a control operated, so the auditor pairs it with inspection of evidence wherever the control leaves a record. The output is a working paper for each control showing the procedures, the items tested, the dates and the outcome of every item.
Document exceptions and evaluate their effect
When a sampled item does not show the control operating as designed, the auditor records it as an exception, then investigates the cause and decides whether it reflects an isolated failure or a wider weakness. Management is asked to provide the root cause, the corrective action and any evidence that the control later operated correctly. The output is an exception log with each item's cause, its effect on the criterion, and whether the auditor considers a related control to have failed as well.
Discuss exceptions with management
The auditor and management review the exception log together, and management may explain facts that change the picture, such as a population that was incomplete, an item that was tested against the wrong period, or a corrective action that already operated. Management has the chance to correct the system description or the control matrix where the testing shows they did not match reality. The output is a settled list of exceptions, each with a management response, and a shared understanding of which findings will appear in the report.
Draft the report and gather the representations
The auditor drafts the report, which includes the system description, the auditor's opinion, the description of tests and results and any exceptions. Management reviews the draft, drafts its assertion about the description and the controls, and prepares the written representations the auditor requires before the report is issued. The output is a draft report with management's assertion and representation letter both in review, and the report is not final until the auditor has completed its own review and management has signed those documents.
Why identical sample sizes across clients draw peer review scrutiny
The AICPA's May 2026 peer review alert treats sameness across SOC 2 engagements as a warning sign. Each card below names one pattern a reviewer checks, why it points to a template instead of judgment on the client's own system, and what sound practice looks like instead.
Identical SOC 2 reports
Reviewers compare report wording across a firm's clients and look for the same system descriptions, control names and test narratives with only the company name changed. Matching text suggests the examiner did not study each system. Sound practice is a report whose system description reflects the client's actual architecture, subservice providers and boundaries, with exceptions and test results written for that engagement.
Identical risk assessments
A risk assessment that reads the same for a payroll platform, a data center and an AI tool suggests the firm did not identify threats specific to each service. Reviewers look for risks tied to the client's own objectives, data flows and changes during the period. Sound practice is a risk register that names the client's specific threats, owners and the controls that address them, with changes documented as the business evolved.
Identical sample sizes
When every client receives the same number of access reviews, change tickets or incident samples, reviewers infer that sample sizes were picked from a table rather than from the population. Sample size should depend on how often the control operates, how many items exist in the Type 2 period, the risk involved and the auditor's assessment of control reliability. Sound practice is a documented rationale for each sample size, tied to the population size reported by the client.
Identical testing procedures
Reviewers also compare the procedures listed for each control. If every client's change management test reads as inquiry followed by inspection of one ticket, the procedures may not match how the control actually operates. Sound practice selects procedures per control, combining inquiry with observation, inspection and reperformance where the control design makes them meaningful, and records why each was chosen.
Why nonconforming engagements matter
The alert notes that engagements found not to comply with standards in all material respects may be concluded nonconforming. For a service organization, a firm under that finding is a weak basis for trust, and buyers reading the report may question its conclusions. Before engaging a CPA firm, ask for its most recent peer review results and how it selects engagements for review.
How test exceptions and results appear in a Type 2 report
A Type 2 report includes the service auditor's description of the tests performed on each control and the results of those tests, and that description is what lets user organizations judge how any failure affects their own controls. The 2011 Journal of Accountancy article on expanding service organization controls reporting makes this point directly: because users can see what was tested, how, and what came back, they can decide whether the findings matter to their own risk assessments. For the team preparing the system, this means exceptions are not hidden in a summary. They appear in the report, attached to specific controls, and customers read them.
When the auditor finds that a control did not operate as designed during the period, the typical path is an exception raised against the sampled item. The team should expect the auditor to walk the exception through with management before fieldwork closes, to ask for the root cause and any compensating evidence, and to record management's response. Management should confirm the facts of each exception, check whether the same failure could have affected other items in the population, and decide whether a remediation is in place by the time the report issues. Ask the auditor early how exceptions will be worded, because that wording determines how a customer's security team reads the result.
Do not expect a clean result when evidence is missing. A control with no retrievable record for a sampled instance is generally treated as a failure to demonstrate operation, not as a pass that the auditor will accept on the strength of an interview. Before fieldwork, check that each control's evidence can be produced for the full observation period, including access reviews, change approvals and monitoring alerts, and that the team can retrieve it without rebuilding it after the fact. Retroactively created records are a risk the auditor will test for, so gaps should be disclosed early rather than papered over.
How an implementation partner prepares evidence without touching the opinion
During SOC 2 fieldwork, the auditor decides what to test, which samples to pull and what the results mean. An implementation partner works one step earlier: it makes sure the systems produce complete, retrievable records and that the organization's own controls are documented and run. Each card below covers one part of that preparation and the boundary the partner must not cross.
Building complete populations
A population is the full list of items a control applies to, such as every user account, every production change or every security alert in the Type 2 period. Auditors draw samples from populations, so a gap in the population undermines every sample drawn from it. The partner builds these lists from the source systems and records how each was generated. Ask the organization to confirm the population is complete before any sample is drawn, and to keep the query that produced it.
Configuring logging and ticketing
Auditors test operating effectiveness by inspecting records, so a control that ran but left no record cannot be shown to have operated. The partner configures audit logs, retention and ticket workflows so that approvals, access grants and changes are captured with timestamps and named approvers. Check that logs cannot be edited by the people whose actions they record, and that retention covers the full observation period.
Setting up evidence collection
Evidence collection defines where each artifact comes from, who exports it, how often, and where it is stored. The partner sets up scheduled, system-generated reports where the platform supports them, and documents where screenshots remain necessary. Evidence should be traceable back to the control and the period it covers. Confirm with the organization who owns each recurring export, since a missed month is an exception the auditor will ask about.
Running internal pre-checks
Before fieldwork, the partner or the organization's internal team can test a sample of its own controls against the same criteria an auditor will apply. This surfaces missing approvals, late reviews and gaps in populations while there is still time to fix them. Pre-checks are internal findings for management to act on. They do not replace the auditor's tests, and results should not be presented to the auditor as the auditor's own work.
Documenting controls and ownership
Each control in the control matrix needs a description of what it does, who performs it, how often, and what record proves it. The partner drafts this documentation from the organization's actual operations, then the control owner reviews and approves it. Ownership stays with the organization: it decides which controls it runs, and it is accountable for them. Documentation that describes controls nobody runs is a finding waiting to happen.
Keeping the independence boundary
The partner does not choose the auditor's samples, does not perform tests on the auditor's behalf for the opinion, and does not issue the report. Only the independent CPA firm does those things. Ask the partner to put this boundary in writing in the scope, and ask the CPA firm how it will document that it selected its own samples and performed its own procedures. Confusion here is a common reason peer reviewers question an engagement.
SOC 2 fieldwork questions buyers ask before engaging a CPA firm
Who is allowed to perform a SOC 2 examination?
A SOC 2 examination must be performed by a licensed CPA firm acting as the service auditor, not by the organization's own staff or a consultant. Consultants can prepare systems, controls and evidence, but only the independent CPA firm can issue the report and its opinion. Before you sign, confirm the firm's licensing status and check the individuals on the engagement through the state board of accountancy. The AICPA staff FAQs on SOC 2 and SOC 3 engagements, issued in December 2020, address who can perform these examinations and are a useful reference when you vet a firm. Ask the firm to confirm in writing that its engagement partner and team meet these requirements.
Will the auditor test every control in the system?
No. Auditors test controls on a sample basis, so they select a subset of items from each population that a control covers rather than checking every transaction or user. For a Type 2 report, the sample must be drawn across the observation period so that the control is shown to operate over time, not only on one day. The AICPA staff FAQs address the use of sampling, materiality and the procedures for testing operating effectiveness. Ask the firm to explain its sampling approach for each control type, how it sets sample sizes, and whether those sizes depend on risk and control frequency. Sample sizes that look identical across very different controls or clients should prompt a question.
What does the team have to provide, and how long does the auditor wait for answers?
The team must provide the system description, the control list, the policies, and the populations and evidence behind each sample, such as access lists, change tickets, and monitoring records. Auditors send request lists during fieldwork, and the speed of your responses directly affects how quickly testing finishes. The turnaround time is set in your engagement letter and by your own staffing, so ask the firm to confirm how it tracks open requests and who on your side owns each one. Ask for these details in writing, along with the list of people the auditor will interview.
Is a rushed SOC 2 engagement a risk to the report?
Yes. A rushed or overly automated SOC 2 can rely too heavily on inquiry, which means asking staff how a control works instead of inspecting evidence or reperforming it. The Journal of Accountancy warned in February 2026 that promises of fast and easy reports threaten the credibility of SOC reports. The AICPA's May 2026 peer review alert also says that engagement timelines that appear unreasonable can lead a reviewer to rate the engagement as elevated risk. Before you accept a compressed schedule, ask the firm how many testing procedures it will perform beyond inquiry and how it plans to keep the review cycle intact.
Can our team prepare the evidence without a consultant?
Often yes, provided the people doing the work understand what the auditor will test. Your team can build the control matrix, gather populations, export system-generated reports, and keep records that show controls operated during the period. Costs usually come from staff time, tooling and any outside help you choose to buy. Consultants and implementation partners can prepare systems and evidence, but they do not issue the report, and the CPA firm still tests the controls independently. Ask yourself whether your team can own each evidence request, produce complete populations, and answer follow-up questions on the same day. If not, outside help may shorten the gap.
What should we ask a CPA firm about sampling and independence?
Ask how the firm selects samples, how it documents sample sizes for each control, and how it handles exceptions found in a sample. Ask how it determines the examination scope and which criteria it will test. On independence, ask how the firm maintains it, including whether it or its staff have provided design or remediation work that could conflict with the examination. The Journal of Accountancy advised in February 2026 that organizations vet a firm's size, capacity, references, qualifications and peer review results. Request the firm's most recent peer review report and check its status through the AICPA peer review resources.
Does a SOC 2 opinion confirm that we comply with laws and regulations?
No. A SOC 2 opinion reports on whether the system description is fairly presented and whether controls are suitably designed and, for a Type 2, operating effectively against the Trust Services Criteria. It does not state that the organization complies with laws or regulations. The AICPA staff FAQs on SOC 2 and SOC 3 engagements address this point directly. If a customer or regulator asks for legal compliance evidence, you will need a separate assessment or attestation that matches that requirement. Ask the CPA firm to confirm in the engagement letter what the report does and does not cover.
How DeployOpen prepares systems and evidence ahead of fieldwork
The sequence below shows how DeployOpen scopes the preparation work in writing, sets up the systems and records a CPA firm will test, and hands over documentation so the firm can run its own procedures. DeployOpen prepares; the CPA firm tests and issues the report.
Agree the scope in writing
Before work starts, DeployOpen and the client agree in writing which systems, locations, Trust Services categories and control areas are in scope, along with the deliverables and timelines. The client owns its controls and names an accountable owner for each area. The scope document is complete when both parties sign it and the CPA firm has confirmed the system boundary it expects to examine. Anything outside the boundary, including subservice providers, is recorded as such so it is not assumed to be covered.
Harden and document the self-hosted platforms
DeployOpen configures the open-source platforms inside the client's own cloud accounts, data centers or air-gapped networks, applying the access, encryption, patching and configuration settings the agreed control set requires. Each configuration is recorded as code or as a versioned baseline so the state of a system at any date can be shown. The output is a configuration baseline per system and a list of any deviations, each with an owner and a documented reason.
Turn on logging, access and change records
DeployOpen enables audit logs for authentication, administrative actions, configuration changes and deployments, and routes them to storage the client controls with retention set in advance. Access rights are tied to a directory or identity source so joiners, movers and leavers leave a traceable record. Change requests, approvals and deployment records are linked through the client's ticketing and pipeline tools. The check is that a sample event can be followed from request to approval to logged deployment without manual reconstruction.
Build the populations the CPA firm can sample
Auditors draw samples from complete populations, so DeployOpen helps the client produce those populations for each control: every user account with its approvals, every change in the period, every security alert and its disposition, every backup job and restore test. System-generated exports are preferred over screenshots, and each export records the query, the date and the person who ran it. The output is a population file per control with a count, a date range and a reconciliation to the source system.
Test the controls internally before fieldwork
Before the CPA firm arrives, the client's control owners perform their own tests on the populations, following the procedures written in the control matrix. DeployOpen supports this by reperforming selected controls, such as a user access review or a restore test, and recording what was checked and what was found. Exceptions are logged with root cause and remediation. The check is that each control has a documented test result, a named tester and an exception log, so the client can answer the auditor's questions from evidence.
Assemble the evidence binder and index
DeployOpen organizes the evidence by criterion and by control, with an index that links each request on the auditor's list to the population, the system export, the approval and the owner responsible. Architecture diagrams, runbooks, configuration baselines and training records are versioned alongside. The index is complete when every request on the list points to a named artifact and the client's owner has confirmed the artifact is the correct version for the period.
Hand over documentation and confirm readiness
DeployOpen delivers the documentation package, the runbooks, the evidence index, the open exception list and the operating procedures the client needs to keep the controls running during the observation period. The client's management reviews the package and decides what to submit. DeployOpen does not issue audit reports, attestations or certifications; the independent CPA firm performs the examination, decides which samples to test and issues the report. The handover is complete when the client confirms receipt and the open items have owners and dates.
Sources and further reading
- AICPA staff FAQs on SOC 2 and SOC 3 engagements (December 2020) ↗
- Expanding Service Organization Controls Reporting (2011) ↗
- AICPA guides peer reviewers to address SOC 2 risks (May 2026) ↗
- Promises of fast and easy threaten SOC credibility (February 2026) ↗
- AICPA SOC 2: SOC for Service Organizations, Trust Services Criteria ↗
