Skip to content
AtomicReps
SOC 2 Type 2: What the Auditor Tests

A fix before fieldwork does not change a Type 2 report

Lesson 1 of 12

A fix before fieldwork does not change a Type 2 report

A lesson from SOC 2 Type 2: What the Auditor Tests. Play it above, or read it through below.

Level I · The Audit Window and What Gets Graded
  • A Type 2 opinion is about a period. The period is already over.

    The common read: The audit tests the state of our systems, so a remediation sprint before fieldwork buys a clean report.

    Find the failure, fix it, confirm it passes: that sequence has worked throughout your career, and a SOC 2 Type 2 report is where it fails. A SOC 2 Type 2 report says the controls operated effectively throughout a specified period: here, 2026-01-01 to 2026-06-30, 181 dates, all in the past. Nothing you do now makes a control operate on 12 January. A SOC 2 Type 1 report opines as of a specified date, which is why fixing a control before a deadline works for a Type 1 only.

    The control in question emits one artifact per day: an MFA-status snapshot per in-scope account, written by the identity provider export with a snapshot_date on every row. That population is what the auditor tests, and the rows for 2026-01-12 and 2026-01-13, which read MFA disabled, are two rows inside it. Nothing about the state of the account on the day of fieldwork edits those rows, because they are records of dates that already happened, and fixing the account now does not change a record.

    Detection is not automatic, so the accurate statement is narrower than the one a readiness presentation makes. The gap is discoverable, and if it is discovered the auditor will likely document an exception. Being old never takes it out of scope. In the report, it appears as a testing-matrix row reading one deviation, on 2026-01-12 and 2026-01-13, the window's first month, and no exceptions otherwise, filed against the identity team, whose enforcement policy was detached by a group migration during a platform cutover and reattached the same week.

    Takeaway: "We fixed it in May" describes the account after May. The report covers January.

    So the sprint does not fix this report. It lowers the number of deviations in the next window. For the report you are being asked for now, the choices are the ones listed later in this lesson. For the next window, choose the start date: the earliest date whose evidence you would defend, knowing the auditor can test every day after it.

  • A daily control has 181 instances in the window. A quarterly one has two.

    The common read: The auditor samples, so a two-day gap on one account is too small to find and the sample will miss it.

    Say how many instances of your quarterly access review exist inside a six-month window before reading on. The answer is two. No sample size is prescribed for a SOC engagement, and the sizes you will see come from the AICPA's audit sampling guidance applied by analogy: a quarterly control with four instances a year gets about two tested, a monthly one gets two to four, a weekly one gets five to nine. A daily system-generated check is tested much closer to the whole population, because one query returns it.

    Testing a daily check against nearly its whole population runs against the usual intuition. Continuous monitoring is sold as a way to avoid exceptions, and it also makes a two-day gap findable: it emits one dated row per account per day, so a two-day gap is two of the 181 rows that account contributes. Deviations go unfound in a large, sampled population: a weekly control has 26 instances and 5 to 9 tested. The quarterly review tests both instances, so one miss is half the population.

    A common failure: the auditor requests the population of privileged access grants for the period, the team answers with a chat channel and console screenshots, and the sample is drawn from whatever the team could list. The exception that follows names the access review, not the fact that nobody could produce a list with a date field on it.

    So record two facts per control: its cadence and its population size inside the window. Together they show which controls have no margin for a single miss. A quarterly control with two instances has no margin: one missed cycle is half the sample. A daily control has more margin, but no miss goes unseen, because every day is a row the auditor can count. Neither fact is a reason to run fewer checks. Both are reasons to know which of your controls one missed week would fail.

  • Fieldwork is not one date. Some of it happens while the window is open.

    The common read: Nobody is looking until fieldwork opens, so a gap I close before the auditor arrives is a gap nobody saw.

    Name the date the auditor starts testing before reading on. There is more than one. Some controls leave no evidence that can be tested later, so the service auditor may test them at various times throughout the reporting period, and interim procedures inside the window are routine. The ones that qualify are the ones whose trace does not survive: an observed walkthrough, an approval recorded only in a chat channel, a log stream whose retention is shorter than the window.

    Two things follow, and teams rarely plan for the second. Mid-window testing does not shorten the period or freeze it early, because the period rather than the visit is what gets opined on. And a gap you closed in week two was not necessarily unobserved: if the access population the auditor pulls at the February visit covers January, the auditor sees January's data in February, almost five months before final fieldwork.

    A common failure: an evidence request arrives in April for a control the team was still planning to set up in May. An engineer answers it accurately, the answer is quoted in the test-results section as a deviation, and the deviation is blamed on that engineer rather than on the assumption that the audit had not started. So ask which controls the engagement team tests at interim, and write the answer beside those controls in your matrix. One email gets you the list of controls tested in April.

  • The window starts where the artifacts start. A kickoff date is not a start date.

    The common read: The evidence pipeline has to be running by the time the auditor asks, so switching it on at kickoff covers the window we declared.

    Your dashboard shows every check passing, and it only has data from April onward. The declared window opens 2026-01-01 and the first row the exposure table can produce is dated 2026-04-12, which is the day the compliance platform was connected. Eighty of the window's 181 dates carry an exposure row. The other 101 carry nothing, and no query written after the fact turns a date with no artifact into a date with one.

    The MFA snapshots cover all 181, which makes the exposure gap harder to notice. Coverage is a fact about one control and its own table, so a report holding a control instrumented before the window opened and a control instrumented four months into it has two start dates, and the one you can defend for the whole report is the later of them unless you remove the newer control from scope.

    Most teams try to backfill the missing dates first, so be precise about what backfill can do. A configuration history in the cloud provider can often reconstruct what a security group ALLOWED on a January date. That reconstruction is evidence of state rather than the artifact the control was described as emitting, and a control described as a daily review of an exception report has no state to reconstruct at all. An auditor may dispute reconstructed evidence; evidence the control emitted at the time is what gets sampled.

    So record one date per control: the first date its own artifact exists, taken from the artifact, not the vendor's onboarding email. Operating effectiveness cannot be concluded for dates the population does not cover, so you open the window on the latest of those dates, or the auditor raises the 101 uncovered dates before 2026-04-12. A common failure: an evidence request for month two is answered with a July screenshot, and the monitoring platform is blamed. A coverage gap costs less to find in March than in August.

  • Every deviation appears in the report. That does not decide the opinion.

    The common read: One miss in a sample of eight is inside the rate the sample allows, so a single deviation with a documented cause and a dated fix costs nothing.

    You sent a cause, and the auditor answered with more testing rather than closing the deviation. What the auditor does with a deviation is investigate its nature and cause, then decide one of three things: that it is within the expected rate and acceptable, that more testing is needed, or that the control did not operate effectively throughout the period. Your explanation is the input to that decision, and a cause that reaches instances the sample never drew supports the middle one.

    Two teams can each report one deviation and face very different consequences. One missed week with a named reviewer, a dated catch-up and no other affected instance is a rate question. A filing job that stopped writing on 2026-06-01 with nothing watching it is a population question, and it converts one sampled deviation into a request for every weekly record from that date on. In both cases the number of deviations is one, so the number does not decide the outcome: the cause decides it.

    The deviation is reported either way. Materiality is not applied when the results of tests are described, and the report carries identified deviations with their number and nature even where the auditor concludes the control operated effectively. The cleanest statement of that rule is AT-C 320 paragraph .A30, which is the SOC 1 section; the AICPA SOC 2 guide carries the same rule in practice, so take it as the practice and not as a SOC 2 citation. An unqualified opinion can accompany a printed deviation.

    The auditor does not vouch for the sentence beside the deviation. The response is management's own, printed beside the test result at many firms, and it is the part a buyer's security review reads. Months later a buyer's questionnaire asks about the deviation. The buyer can check the auditor's test result but not a response that says only "the issue was promptly remediated", and that vague response loses the buyer's trust. So write it with engineering facts: the cause, the fix date, and what prevents the cause next time.

  • There is no reset. There are three options, each with a cost.

    The common read: A period that failed can be re-run, so the fix plus a fresh window replaces the exception.

    No mechanism restarts an observation period after a deviation. What people call a reset is always one of three trade-offs. Take the exception in the report and answer it. Move the window's start date past the failure and declare a window that opens after it. Accept a modified opinion, run a fresh period, and pay for the second engagement. The first is what almost everyone does, and it is also the one nobody plans for.

    The second trade-off needs its cost stated, because it sounds free. Moving the start date to 2026-02-01, after the failure ended on 2026-01-14, costs one of two things. Hold the six months and the window closes 2026-07-31, so the report arrives roughly a month late. Hold the close date and the window is five months, and buyers read window length: a report covering three months answers a smaller question than one covering twelve. Practice clusters between three and twelve months, so a buyer notices a short window.

    One move is worse than the exception it hides. Backdate an approval, edit a completion record, regenerate an export with a friendlier timestamp, and the deviation is gone. A common form is a ticket to correct a timestamp, filed against the export job, with nothing filed against the approval whose date changed. A deviation that resulted from fraud by service organization personnel makes the auditor reassess whether the description is fairly presented and whether the controls are suitably designed at all. One exception then puts the whole report in question.

    So the deliverable after a deviation is a paragraph and a date, not a new period. Write the cause in the words the auditor will have to defend, attach the artifact that shows when the fix took effect, and let the exception appear in the report. A single deviation with a credible cause and a dated fix does not usually cost the opinion. Practitioner consensus is the only authority behind that claim, so spend an hour on the response you write beside the deviation.