Test of design vs test of operating effectiveness explained

A test of design asks whether a control, performed exactly as described, could prevent or detect the error it is meant to address. A test of operating effectiveness asks whether the control actually ran that way, by the right person, at the right time, across the period. Both feed a SOX conclusion, and neither one proves the other.

Internal controls exist to prevent or detect errors in financial reporting. Knowing whether one works means answering both questions separately. This guide explains the difference in plain terms, with a worked bank reconciliation example and the steps for each test.

What is a test of design?

A test of design checks whether a control is properly designed to address a specific risk. The tester asks one question: if this control is performed as described, could it prevent or detect the error it targets?

Design testing looks at the control's purpose, steps, timing, responsibilities and the information it uses. Take a company that requires manager approval for journal entries above a set amount. The tester checks whether that approval requirement is suitable for reducing the risk of unauthorized or incorrect entries.

A control can have a neatly formatted written policy and still be poorly designed. The procedure has to address the actual risk, not just exist in a binder.

What a test of design examines

• Risk: what could go wrong, and how the control addresses it
• Objective: whether the control objective is clear
• Owner: whether the right person is responsible for the control
• Timing: whether the control happens at the right time
• Precision: whether the review is precise enough to identify errors that matter
• Information: whether the control uses complete and reliable information
• Implementation: whether there is evidence the control has been placed in operation

Design testing usually combines inquiry, inspection of control documents and a walkthrough of the process. SOX testing 101 covers walkthroughs and where they sit in the testing cycle.

What is a test of operating effectiveness?

A test of operating effectiveness checks whether a control actually worked as designed during the period being tested. The tester asks: was the control performed by the right person, at the right time, and according to its requirements?

Operating effectiveness testing is about actual performance. It needs evidence from real instances of the control during the review period. If a manager must approve journal entries before posting, the tester selects entries and confirms each approval happened before posting and came from an authorized manager.

A control can be well designed and still fail in practice. The review gets skipped, done late, or signed without anyone asking about the unusual item. A design test never finds the month the reviewer was on leave and nobody covered. An operating test does.

What a test of operating effectiveness examines

• Performance: whether the control was performed at all
• Authority: whether an authorized person performed it
• Timing: whether it happened at the required time
• Completeness: whether every control step was completed
• Information: whether the information reviewed was reliable
• Follow-up: whether identified issues were followed up
• Evidence: whether something retained shows the control was performed

The tester also investigates deviations and decides whether they change the conclusion. How many instances to test depends mostly on how often the control runs: SOX sample sizes by control frequency has illustrative ranges, and your auditor's minimums and your own methodology win.

Test of design vs test of operating effectiveness, side by side

The main difference is what each test is meant to prove.

A design conclusion does not prove the control worked consistently. An operating test cannot make a poorly designed control effective. You usually need both to understand a control fully, and the scope depends on your testing methodology and what your external auditor requires.

Worked example: a monthly bank reconciliation, tested both ways

Say a company requires its finance manager to review and approve the bank reconciliation every month. The control exists to identify differences between the bank statement and the general ledger. (This example is illustrative.)

Test of design

The tester first evaluates whether the control is suitable. They ask:

• Does the reconciliation compare the correct bank account with the correct ledger balance?
• Is the manager responsible for reviewing differences?
• Does the review happen before the reporting close is finalized?
• Does the process require significant differences to be investigated?
• Is the manager's approval recorded?

If the process does not require investigation of significant differences, the control may not be designed well enough to address the risk. Testing twelve months of it will not change that.

Test of operating effectiveness

Next, the tester checks whether the control worked during the review period. They select reconciliations and inspect:

• The reconciliation for the correct account and month (a file named rec_final_v3_FINAL.xlsx proves neither)
• Evidence that the manager reviewed it
• The reviewer's identity and authority
• The date of review and approval
• Evidence that significant differences were investigated

If approval is missing for one month, investigate before concluding. Missing evidence may point to a deviation, but the conclusion rests on the facts you find and your testing criteria, not on the gap alone.

How to perform a test of design in five steps

1. Understand the risk. Identify what could go wrong and how the control is meant to address it.
2. Review the control description. Confirm it says who performs the control, what they do and when they do it.
3. Walk through the process. Discuss the control with its owner and inspect the documents or system records it relies on.
4. Evaluate the control's precision. Decide whether it is detailed enough to prevent or identify the relevant error.
5. Record the conclusion. Document why the control is suitably designed, or what needs to change.

How to perform a test of operating effectiveness in six steps

1. Define the testing period and population. Identify the period under review and every instance of the control that could be tested.
2. Decide the testing approach. Follow your approved methodology to set the sample or other procedures.
3. Collect evidence. Get records that show the control was performed, tied to the control and the period.
4. Test each selected instance. Compare the evidence with the control requirements: performer, timing, steps and follow-up.
5. Investigate deviations. If a step looks missing, find out what happened. Keep potential exceptions separate from confirmed findings.
6. Document the results. Record the procedures performed, evidence reviewed, exceptions found and the conclusion.

Confirmed exceptions then need a severity. The deficiency classification guide covers how likelihood and magnitude decide between a control deficiency, a significant deficiency and a material weakness.

Common mistakes in TOD and TOE testing

Treating a walkthrough as operating testing

A walkthrough helps a tester understand a control and assess its design. It traces one instance. It does not show the control operated consistently through the period.

Testing only the written policy

A policy describes what should happen. Operating effectiveness testing needs evidence of what actually happened. The two are not always on speaking terms.

Losing sight of the control's risk

A tester can confirm a signature exists without checking whether the approval addressed the risk. Testing should follow the control objective, not just the presence of a mark on a page.

Treating missing evidence as an automatic conclusion

Missing evidence may signal a problem. Investigate the circumstances and apply the testing criteria before calling it an exception.

Reusing old design conclusions without reassessment

Processes, systems, people and risks change. Confirm each year that the prior design assessment still describes the control people actually perform.

How TOD and TOE support SOX compliance

SOX control testing assesses the controls relevant to financial reporting. A test of design tells you whether a control is structured to address its risk. A test of operating effectiveness tells you whether it worked during the relevant period. PCAOB AS 2201, the auditor's standard for ICFR audits, treats them as separate tests for the same reason.

A control can pass design testing and fail operating testing. It can also be performed perfectly every time and still be too weak to address its risk. That is why both questions matter.

Where SOXLayer fits in design and operating testing

The judgment in a test of design (is this control precise enough for this risk?) stays with your team. SOXLayer, a SOX compliance application built around control testing, records that judgment and carries it into operating testing:

• Design attributes in the RCM: versioned controls with their full design attributes, with risks mapped to controls
• Test templates: reusable, versioned attributes with pass and fail criteria, so the operating test checks what the design says
• Population and sampling: a population upload is totalled and SHA-256 fingerprinted before samples are drawn
• AI first pass on evidence: the AI proposes Pass, Fail, Insufficient or N/A per attribute, with a confidence score and the exact quote and page it relied on
• Exceptions to deficiencies: exceptions raise deficiencies automatically, and every decision lands in a hash-chained audit trail

AI never submits, reviews or approves a test. With auto-fill on, it can record a result it is at least 90% sure of, with a verified citation, while the test is still being prepared. Anything flagged, disputed or Insufficient waits for a person, and admins can switch auto-fill off so every result waits. More on how that works on the AI testing page.

Common questions about test of design vs test of operating effectiveness

Is a test of design the same as a test of operating effectiveness?

No. A test of design evaluates whether a control is suitably designed to address its risk. A test of operating effectiveness evaluates whether the control actually operated as intended during the period.

Which test comes first?

Teams generally assess design before relying on operating effectiveness results. If a control is not suitably designed, testing its repeated performance may not tell you much about the risk it is meant to address.

Can a control pass a test of design but fail a test of operating effectiveness?

Yes. A control can be well designed but not performed consistently. A required manager review may be the right control, but if it gets skipped in some months, it fails operating testing.

Can a control pass a test of operating effectiveness but fail a test of design?

Yes. A control can be performed exactly as written and still be inadequate. A reviewer may approve every transaction on time, but if the review does not include the information needed to spot the relevant error, the design fails.

What evidence is used for a test of design?

Control descriptions, policies, process documents, interviews, walkthroughs and evidence showing how the control is set up.

What evidence is used for a test of operating effectiveness?

Records showing actual performance, such as approvals, reconciliations, review logs, system records and follow-up documentation. The evidence has to support the specific testing criteria for each selected instance.

Sources and further reading

The standards and guidance behind this article. Your external auditor's methodology and your company's own policy still set the requirements for your program.

• PCAOB AS 2201, An Audit of Internal Control Over Financial Reporting: the auditor's standard for ICFR audits, including testing design effectiveness and operating effectiveness
• SEC Release No. 33-8810, Commission Guidance Regarding Management's Report on Internal Control Over Financial Reporting: guidance for management's own evaluation of ICFR
• COSO, Internal Control: Integrated Framework: the framework most companies use to design and evaluate ICFR

A well-written control and an effective one look identical in the policy binder. Only the testing tells them apart.

Back to top

Furqan Abaid

Furqan Abaid builds SOXLayer, AI-assisted SOX control testing software, and writes about how SOX programs scope, test, review and document their controls.

Read these next

Testing

Rollforward testing for SOX controls: best practices

Eight steps from the interim workpaper to a full-year conclusion, a monthly bank reconciliation rolled forward from September to December, and the mistakes that leave a gap.

Furqan Abaid·October 24, 2026·10 min read

Testing

Three-way match in accounts payable: how to test the control

Seven attributes, five documents per sample and four exceptions to check, plus an illustrative worked sample with a 4-unit quantity variance.

Furqan Abaid·September 2, 2026·9 min read