What an Auditor Actually Does During a SOC 2 Type II Review
Demystifying Type II fieldwork — samples, walkthroughs, exceptions, and why “we have a policy PDF” is not enough.
A SOC 2 Type II examination tests whether controls operated effectively over a period — not whether you can narrate a secure architecture in a sales call. Licensed CPA firms (or firms that issue under AICPA attestation standards) perform the work; ComplianceBase does not.
Type I vs Type II in one sentence
Type I asks: at a point in time, were controls suitably designed? Type II adds: across the observation window, did they actually operate? That operating-effectiveness layer drives most of the calendar and sample work founders feel during fieldwork. Compare fees and sequencing at /compare/soc-2-type-1-vs-type-2.
The rhythm of fieldwork
1. Planning and readiness
Before samples begin, the engagement team confirms:
- System description boundary — products, infrastructure, data flows, subservice organizations
- Trust Services Categories in scope (Security baseline; others additive)
- Observation period start and end dates
- Population completeness — can the company produce lists of users, changes, tickets, alerts, and vendors for the period?
Weak planning shows up later as “we cannot reconstruct Q2 access reviews.” Cost of that scramble: /costs/soc-2/timeline.
2. Walkthroughs
Auditors trace how controls actually work, not how the policy says they should work. Typical SaaS walkthrough themes:
- Logical access — provisioning, MFA, privileged accounts, termination (CC6.1)
- Change management — ticket → approval → deploy → emergency change handling (CC8.1)
- Logging and monitoring — what gets logged, who reviews alerts, escalation paths (CC7.2)
Walkthroughs inform which populations get sampled and whether design gaps exist before testing begins.
3. Sampling operating effectiveness
For Type II, auditors select items from period populations — access reviews, change tickets, vulnerability scans, incident records — and inspect evidence that the control operated as described. Sample sizes depend on methodology, risk, and population size; they are not “check three boxes and leave.”
Teams surprised by sampling usually had incomplete populations (missing service accounts, shadow admin consoles) or undated evidence (screenshots without review signatures or ticket IDs).
4. Exceptions and management responses
When evidence does not support the control as written, the firm documents an exception (wording varies by firm). Management may respond with remediation narrative. Exceptions do not automatically kill a deal — buyers read severity, scope, and recurrence — but they extend fieldwork and erode trust when they cluster in access or change domains.
Incident response samples often expose gaps here: dusty IR PDFs vs exercised playbooks (CC7.4).
5. Report assembly
Deliverables typically include the auditor’s opinion, system description, tests of controls summary, and complementary user entity controls where applicable. The report belongs to management; customers receive it under NDA or via a trust center.
What auditors are not doing
- They are not “certifying” you as secure forever.
- They are not validating every marketing claim on your website.
- They are not a substitute for GDPR/HIPAA legal compliance.
- They are not penetration testers for your entire product surface (unless separately engaged).
- They are not responsible for fixing your controls — management owns design and operation.
Evidence patterns that make fieldwork boring (in a good way)
Dated, attributable records
Access reviews should show who reviewed, what population, when, and what was removed or confirmed. Change records should link ticket ID → approver → deploy artifact. Logs should exist where the system description says they exist.
Inventories that match reality
CMDB theater hurts when walkthroughs find admin consoles not in the inventory. Include service accounts, break-glass identities, CI/CD roles, and vendor portals with production access.
Monitoring with a story
Alerting controls fail samples when nothing ever fires or when every alert is ignored. Define severity, ownership, and escalation; retain closed-loop records for incidents and near-misses.
How your team should prepare
| Phase | Engineering / ops focus | GRC focus | |---|---|---| | Pre-window | Close obvious IAM and logging gaps | Draft system description; align TSC scope | | Window start | Operate controls consistently | Calendar reviews and vendor attestations | | Mid-window | Avoid “freeze changes” theater | Track exceptions and remediation tickets | | Fieldwork | Respond to evidence requests quickly | Single point of contact for auditor queries |
Auditor selection and fee parity: /costs/soc-2/how-to-choose-auditor. Price comparison methodology: /costs/soc-2/auditor-price-comparison.
Timeline pressure is a cost driver
Fieldwork length interacts with observation window duration and auditor scheduling. Promising customers a report month before the window ends creates rush fees, incomplete samples, or interim Type I only. Model honestly with /tools/soc-2-timeline-calculator.
Hub reference: /frameworks/soc-2.
Disclaimer: Educational only — not an audit guide from your CPA firm. Examination procedures follow professional standards and your engagement letter.