| name | soc-control-walkthrough |
| description | Document a SOC 1 / SOC 2 control walkthrough — control description, test of design vs test of operating effectiveness, evidence-of-control patterns, sampling, exception triage, deficiency severity classification (control deficiency / significant deficiency / material weakness). Reach for this skill during pre-audit prep, when documenting a new control for the next SOC cycle, or when responding to an auditor's walkthrough request. Used by `audit-prep-specialist` (primary). |
Skill: soc-control-walkthrough
Purpose: Produce control walkthrough documentation that satisfies an auditor on first review — not third. Walkthroughs are where most SOC audit time gets burned. Used by audit-prep-specialist (primary).
When to use
- Pre-audit prep (SOC 1 Type II, SOC 2 Type II, SOX, ICFR)
- New control activated — document before the first audit cycle that will test it
- Process / system change that alters an existing control
- Auditor walkthrough request (planning / interim / year-end)
- Internal audit testing
- Post-deficiency remediation documentation
What a walkthrough is
A walkthrough demonstrates that a control:
- Exists as documented (Test of Design — ToD)
- Operates consistently as documented (Test of Operating Effectiveness — ToE)
The walkthrough is the package: control description + evidence-of-control across a representative time period + the auditor's reperformance results.
Anatomy of a control description
Every control walks through six dimensions:
| Dimension | Question | Example |
|---|
| What | What does the control do? | "Bank reconciliations are prepared monthly for every operating bank account" |
| Who | Who performs it? Who reviews? | "Prepared by Staff Accountant; reviewed by Accounting Manager; both sign off" |
| When | What frequency? When relative to other steps? | "Monthly, completed by working day 5 of close" |
| Where | What system / artifact? | "In NetSuite Bank Recon module; sign-off captured in NetSuite review log" |
| Why | What risk does it mitigate? | "Mitigates risk of unrecorded transactions, misappropriation, or recording errors" |
| Evidence | What proves it happened? | "Reconciliation report exported; preparer + reviewer sign-off timestamps in audit log" |
A control description missing any dimension is incomplete. The walkthrough cannot pass.
Test of Design (ToD)
ToD asks: if the control operates as designed, would it actually prevent or detect the risk?
Test of Design steps:
- Read the control description with the risk it's meant to address
- Identify the completeness, accuracy, validity, restricted-access (CAVR) assertions the control supports
- Walk through one instance of the control end-to-end with the operator
- Confirm the evidence trail captures enough to demonstrate the control happened
- Note any design gap (e.g., "control says monthly but the risk requires daily")
Output: a memo or table — "Control X is designed to address risk Y. Design is adequate / inadequate because Z."
Test of Operating Effectiveness (ToE)
ToE asks: does the control actually operate as designed across the period?
ToE requires a sample:
| Control frequency | Standard sample size |
|---|
| Daily | 25-40 instances (more for high-volume) |
| Weekly | 15-25 instances |
| Monthly | 2-6 instances depending on auditor's risk assessment |
| Quarterly | 2 instances |
| Annual | 1 (the population) |
(Exact sample sizes vary by audit firm and risk assessment. AICPA AT-C §205 and §315 govern. PCAOB AS 2410 governs for ICFR. State the framework being applied.)
For each sample item:
- Operator provides the source artifact (the reconciliation, the approval, the reviewer sign-off)
- Auditor re-performs the control or independently inspects the evidence
- Auditor notes pass / exception / not-able-to-test
Evidence-of-control patterns
The most-tested control evidence patterns:
| Control type | Evidence |
|---|
| Authorization | Approver name + date + dollar threshold check |
| Reconciliation | Recon worksheet + reviewer sign-off + supporting documentation reference |
| Segregation of duties | Two distinct users on the workflow (initiator ≠ approver) |
| Access control | User-role assignment list + last-access review + termination notice tie-out |
| System-generated report | Report parameters + timestamp + spot-check of inputs |
| Manual review | Reviewer initials / electronic sign-off + date + variance / exception notes |
| IT general controls | Change-management ticket + test evidence + production-deploy log + reviewer sign-off |
Smell test: if the evidence is "we always do it," the evidence is missing. If it's "here's the artifact dated Day Z signed by Person A and reviewed by Person B on Day Z+1," it's evidence.
Sampling discipline
- Random selection from the population, not "the auditor picked a month they like." Document the random-selection method.
- Stratified sampling when the population has obvious sub-groups (e.g., big-dollar vs small-dollar approvals) — sample both strata.
- Population definition matters. A control over "all journal entries" requires a population list. A control over "manual journal entries above $X" has a different population. State which.
- Coverage of the period. Samples should span the audit period — not all from Q1.
Exception triage
When ToE finds an exception (the control didn't operate, or evidence is missing):
Step 1. Confirm the exception is real (not an inspection error)
Step 2. Quantify the population affected (just this one? more?)
Step 3. Classify the cause:
- Operator error (one-off vs systemic?)
- Design gap (control doesn't cover what it claims)
- System failure (automation didn't fire)
- Evidence gap (control happened but no proof)
Step 4. Assess potential impact:
- Direct financial misstatement risk?
- Compensating control covers it?
- Is it a single instance or symptomatic?
Step 5. Document the cause + extent + management response
Deficiency severity classification
After exceptions are triaged, classify:
| Class | Definition | Auditor action |
|---|
| Inconsequential | Deficiency exists but does not rise to a meaningful concern individually or in aggregate | Note for management; usually no report mention |
| Control deficiency | Design or operation does not enable management or employees to prevent / detect misstatements timely; less than significant | Management letter |
| Significant deficiency (SD) | A deficiency, or combination of deficiencies, that is less severe than a material weakness, yet important enough to merit attention by those charged with governance | Communicated to those-charged-with-governance |
| Material weakness (MW) | A deficiency, or combination, such that there is a reasonable possibility that a material misstatement will not be prevented or detected | Reported in audit opinion (for ICFR); restricts the audit opinion |
(Definitions from PCAOB AS 2201 / AICPA AU-C §265. Pull the current authoritative wording for the engagement's framework.)
Threshold question: "Could a material misstatement in the financial statements arise from this and not be caught?" — yes → MW track; no → SD or lesser.
Document the rationale for the classification explicitly. Auditors will challenge.
Compensating controls
When a primary control fails, a compensating control may reduce the deficiency severity. Compensating controls must:
- Be in place and operating during the same period
- Be effective at detecting the same risk
- Be at sufficient precision (a quarterly review doesn't compensate for a daily authorization gap on transactions > $X)
Document the compensating control's design and operating-effectiveness evidence the same way as a primary control. Don't claim a compensating control without testing it.
Remediation tracking
Each open finding gets:
- Description of the deficiency
- Severity classification
- Root cause
- Remediation owner (named)
- Remediation target date
- Validation step (re-test after remediation)
- Status (Open → In Progress → Remediated → Validated → Closed)
Track in a central tracker. Roll forward monthly. Stale "Open" items > 90 days are themselves a finding pattern.
Common failure modes
- "We do it" without evidence — verbal walkthrough with no artifact. Auditor cannot test.
- Reviewer sign-off without a date — meaningless. Sign-off must be timestamped.
- Sample of 1 from the start of the period — fails coverage. Spread across the period.
- Operator describes what they "should" do, not what they actually did — interview vs evidence mismatch. Always ask for the artifact.
- System-generated report claimed as evidence without parameter / timestamp — claim is unverifiable.
- Compensating control claimed but never tested — doesn't count.
- Deficiency-severity classification done without consultation — significant deficiencies and material weaknesses are auditor calls; management's view matters but doesn't bind.
- Remediation "in progress" for 18 months — itself a deficiency in the remediation process.
- Different auditor framework cited inconsistently — SOC 1 vs SOC 2 vs ICFR have different criteria. State which.
Walkthrough output
Each walkthrough produces:
- Control description — six dimensions (What / Who / When / Where / Why / Evidence)
- Walkthrough memo — narrative of the one-instance demonstration
- ToD conclusion — design adequate / inadequate + rationale
- ToE testing memo — sample size + selection method + per-item result
- Exceptions log — for any items that failed
- Deficiency classification (if any)
- Cross-reference to risk register / control matrix
See also
