Most SOX teams rebuild the same testing template every year in a spreadsheet, tab by tab, then spend the cycle keeping the RCM, the test plans, and the evidence in sync by hand. The template below is the version worth keeping. Paste it into a workpaper and it will hold up under an external auditor's review.
A complete SOX control testing template has two parts: a risk-control matrix (RCM) that maps each risk to the controls that mitigate it, and a control test plan that documents how each control was tested and concluded. This article gives you both as copyable tables, plus a worked example and the sample-size reference you need to fill them in.
What Goes in a SOX Control Testing Template
A complete template answers, for every in-scope control, six questions:
- What risk does this control mitigate?
- What is the control, and what are its attributes (owner, frequency, type, key/non-key, assertion)?
- How will we test it, and on what population?
- How many items, selected how?
- What evidence did we examine and what did we conclude?
- If it failed, how severe is the deficiency?
Questions 1 and 2 live in the risk-control matrix. Questions 3 through 6 live in the test plan. You need both.
The Risk-Control Matrix (Copy This)
The RCM is the scoping backbone. Each row is one control mapped to the risk it covers.
| Control ID | Process | Risk / what could go wrong | Assertion | Control description | Control owner | Frequency | Type (P/D) | Manual/Auto | Key? |
|---|---|---|---|---|---|---|---|---|---|
| C-01 | |||||||||
| C-02 | |||||||||
| C-03 |
Attribute shorthand:
- Assertion: Existence, Completeness, Accuracy, Valuation, Rights/Obligations, Presentation.
- Type (P/D): Preventive stops an error before it happens; Detective catches it after.
- Key?: Mark "Key" only for controls that, if they failed, could result in a material misstatement. Key controls get the testing focus.
The Control Test Plan (Copy This)
For each control in the RCM, one test-plan row records how it was actually tested.
| Field | Content |
|---|---|
| Control ID | C-01 |
| Test objective | Confirm the control operated over the full period |
| Design conclusion | Effective / Not effective (from walkthrough) |
| Population | Source, period, total count, how obtained |
| Sample size | From control frequency or attribute sampling — see the linked reference |
| Selection method | Random / haphazard / judgmental — and why |
| Attributes tested | The specific things each item must show |
| Pass criteria | What a passing item looks like |
| Exception criteria | What counts as a deviation |
| Evidence examined | Documents, screenshots, system reports per item |
| Result | Pass / Exception(s): count and detail |
| Operating conclusion | Effective / Deficient |
| Preparer / date | |
| Reviewer / date |
Sample Sizes
Sample size for each control test comes from either the control's operating frequency (for manual controls) or a statistical attribute-sampling calculation. Rather than restate the numbers here, see the sample-size reference for the full frequency-based and attribute-sampling tables — they drop straight into the Sample size field of the test plan above. As a rule of thumb, the more often a control operates and the more you rely on it, the larger the sample; expecting any exceptions raises it further.
A Worked Example
Here is one control carried through both templates.
RCM row:
| Control ID | Process | Risk | Assertion | Control | Owner | Frequency | Type | Manual/Auto | Key? |
|---|---|---|---|---|---|---|---|---|---|
| C-01 | Revenue | Revenue recorded without valid, approved order | Existence | Orders over threshold require documented manager approval before invoicing | Sales Ops Mgr | Daily | Preventive | Manual | Key |
Test-plan row:
- Population: All invoices over threshold, Jan 1 to Dec 31, 4,120 items, from the billing system export.
- Sample size: 25 (daily, key, no exceptions expected).
- Selection: Random via spreadsheet function, seed documented.
- Attributes tested: (a) approval exists, (b) approver is authorized, (c) approval predates the invoice, (d) amount matches the approved order.
- Pass criteria: All four attributes present for the item.
- Exception criteria: Any attribute missing or out of sequence.
- Result: 24 pass, 1 exception (approval dated after invoice).
- Operating conclusion: Deficiency — evaluate severity via the deficiency process.
That single exception does not automatically fail SOX, but it does trigger a documented severity evaluation rather than a quiet pass. Getting that discipline right is the difference between a clean cycle and a restatement conversation.
Design vs. Operating Effectiveness
The template captures both because SOX 404 requires both:
- Design effectiveness is assessed by walkthrough — would the control, operating as intended, catch a material error? Record the conclusion before you test operation.
- Operating effectiveness is assessed by testing a sample of real instances over the period. A control that is well-designed but did not consistently operate is still a deficiency.
How Audvera Supports This
A spreadsheet template works, but it has the same failure mode every year: the RCM, the test plans, the sampling, and the evidence drift out of sync, and reconciling them at the end of the cycle eats days. Every control that changes owner or frequency has to be updated in three places by hand.
Audvera keeps the risk-control matrix, the test steps, the sampling, the evidence, and the preparer/reviewer signoff in one linked system, so a change in one place flows to the others and the audit trail is queryable rather than reconstructed. Deficiencies from control tests land in a unified register instead of a separate tab.
If you want to see it against your own controls, start with a free risk assessment — it drafts the risk-to-control skeleton you can review and take into a real testing cycle.