What a SOC 2 auditor checks during fieldwork

Fieldwork is where the examination stops being about what you wrote down and starts being about what your systems can show. Almost half the fee sits in this phase, and the evidence you can produce is what decides how long it takes.

Last reviewed 2026-09-18Written by Jacob Masse, TrazTech Inc.

In fieldwork an auditor does two things: confirms that each control works the way your system description says it does, then samples evidence across the observation window to test whether it kept working. Testing is 40 to 50 percent of the fee on a first Type 2, which makes it the phase your own preparation moves most.

Everything that goes wrong in fieldwork goes wrong in one of two ways. The control was not running, which is a real finding and cannot be fixed by paperwork. Or the control was running and you cannot prove it, which is the more common case and is entirely preventable.

The shape of the engagement

Most Canadian engagement letters allow additional fees where the client is not ready, and the trigger is usually the testing phase running long because evidence has to be chased or reconstructed. That is the mechanism by which poor preparation becomes a bigger invoice rather than just a longer project, and it is why the readiness line and the audit fee are related numbers rather than independent ones.

Walkthroughs: does it work the way you said

A walkthrough is a working session with the person who actually operates the control. The auditor asks them to perform it, or to show the last time it was performed, and compares that to the description.

Two things commonly surface here. The first is a control that is described centrally and performed differently by different teams, which means it is really two controls and one of them is undocumented. The second is a control nobody owns: it happens when someone remembers, which is not a control.

Prepare by having the operator in the room rather than the compliance owner. An auditor can tell the difference between somebody describing a process and somebody who runs it, and the second conversation is shorter.

Comparing firms for this? Tell us what you need and it goes to the ones in the directory that do this work. No charge, and no phone number required.

Sampling: the part that surprises people

The auditor does not look at every change, every access review or every ticket. They select a sample across the observation window and test each item. Sample sizes scale with how often the control runs.

The consequence is arithmetic. A control that runs continuously and is sampled individually produces a failure the moment any one sampled item is missing its approval. One skipped ticket in a hundred is not a rounding error to an auditor; it is a deviation in the sample, and a deviation in the sample is what the exception language in the report is about.

What counts as evidence

Auditors accept evidence that is dated, attributable, complete and produced by the system rather than about it.

• System-generated beats hand-made. An export from your identity provider is stronger than a spreadsheet somebody maintains, because the spreadsheet evidences the spreadsheet.
• Dated and attributable. Who did it and when. A screenshot with no timestamp and no user context answers neither.
• Complete for the population. When the auditor samples ten changes, they select from a list of all changes. Producing ten good ones from a list you curated is not the same test, and the completeness of the population is itself checked.
• Contemporaneous. Evidence created during the window, not assembled after it. A reconstructed access review is visibly a reconstructed access review.
• Traceable to the fix. For anything that found a problem, the record of what was done about it. A scan report with no remediation trail is half an answer.

The five things that usually become exceptions

1. Access reviews that happened but were never recorded. The review occurred in a meeting, the removals happened, and nothing shows who reviewed what or when. Common, and preventable by exporting the list and recording the decisions on it.
2. Terminations where access removal is slower than the policy. The policy says one business day and the log shows four. Auditors check this against the HR record, and the dates are unambiguous.
3. Changes deployed without the approval the policy requires. Usually emergency fixes with no retrospective approval recorded. Write an emergency change path into the policy and use it.
4. Vulnerabilities found and not tracked to closure. The scan ran on schedule and the high-severity finding has no closure record within the timeline your own policy states.
5. Controls in the description that nobody performs. Frequently inherited from a template, and the walkthrough finds it. Describe what you do, not what a policy library suggested.

An exception is not a failed audit. The report says what the deviation was and carries your management response, and a reader who understands the format weighs it accordingly. What damages a report is a pattern of them in the same area, because that reads as a control environment rather than a slip. There is more on how these read in exceptions and qualified opinions.

What your side of fieldwork costs

Published Canadian figures put fieldwork support and auditor questions at 40 to 80 internal hours on a first examination, inside a total internal load of 200 to 500 hours. The single biggest determinant is whether evidence can be produced on request or has to be assembled.

Two practical measures reduce it more than anything else. Name one internal point of contact for auditor requests and reserve their time, because a request list that fans out to six people returns slowly and inconsistently. And keep a running evidence folder during the window rather than at the end of it, indexed by control, so a request is a lookup rather than a search.

After fieldwork

What the finished document looks like, and which parts a customer's security team will actually read, is covered in how to read a SOC 2 report.

From the end of fieldwork to a signed report, four to six weeks is a good answer and eight to ten is common. Drafting, partner review and an independent quality review all sit in there, and none of them is something you can accelerate. If a customer deadline is driving the project, that interval belongs in the plan from the start rather than discovered at the end.