A test of design (TOD) checks whether a control, as designed, is capable of managing the risk and meeting the objective it exists for. A test of operating effectiveness (TOE) checks whether that control actually ran, consistently, over the period under review, performed by someone with the authority and the competence to do it properly. Always test design first. If a control was never going to work even when followed exactly, there is no point checking whether it was followed.
Key points
- A test of design (TOD) asks: if this control runs exactly as intended, is it capable of managing the risk and meeting the objective?
- A test of operating effectiveness (TOE) asks: did the control actually run, throughout the period, by someone with the authority and the competence to run it?
- Test design before effectiveness. A badly designed control cannot become effective just because someone followed it carefully.
- A design can fail in two ways: the control is missing altogether, or it is present but still cannot stop the risk it is meant to address.
- An operating-effectiveness failure also has two causes: the control simply did not run as designed, or the person running it lacked the authority or the competence to do it properly.
- To call a control deficient you need persuasive evidence: evidence strong enough that an independent third party would reach the same conclusion.
What a test of design checks
A test of design involves reviewing the design of a control and determining whether it is adequate to manage the risk and achieve the objective of the organisation. The question is not “does someone do this?” but “if someone does this exactly as written, does the risk actually go away?” For our fuller introduction to controls and the COSO framework, see internal control explained: the COSO framework and examples.
A simple way to see the split: a company designs a control that cash must be physically verified on a surprise basis, every quarter, by a finance person. That is the design. Checking whether the surprise counts actually happened each quarter, signed off by the finance person, is a separate question — that is effectiveness. You can design a control well and still find, separately, that nobody ever ran it.
To test design, an auditor typically:
- observes the control being performed, or performs it themselves, to see how it actually works;
- runs a process walkthrough with the people who perform the control;
- reviews the written policies and procedures behind it;
- checks whether duties are properly segregated; and
- evaluates the access controls around the process.
If the design turns out to be inadequate, the result is a recommendation to change it — there is no reason to go on and test whether an inadequate design is being followed.
The two ways a control’s design can fail
A design deficiency is either a missing control, or a control that is present and even working exactly as intended, yet still cannot mitigate the risk or meet the objective.
Missing control, a real audit case: a company in the diamond-polishing trade (a typically Indian context) regularly bought thermal paper rolls. Each delivery came with three copies of the delivery challan: two were stamped and handed back to the supplier, and the admin department kept the third for its own records. When the invoice arrived later, it came back with one of the supplier’s stamped copies attached — and the control was supposed to be that the admin department compares this returned copy against the copy it had kept at the time of delivery, before clearing the payment. On one occasion that comparison was never made. The returned challan had been altered to show 1,000 rolls instead of the 100 actually delivered, and the company paid for 900 rolls it never received. The control to compare the two challans had simply not been built into the payment process — a missing control, not a design that was followed badly.
Control present but still inadequate, a teaching example: many office buildings ask visitors to write their name and phone number in a register and sign in. The control exists and the security guard runs it faithfully every time. But nothing stops a visitor writing a false name and an unverifiable number, so the risk the register was meant to address — knowing who is actually in the building — is not mitigated. The fix is to redesign the control, for example by checking an ID card and verifying the phone number with an OTP, not to test the existing register harder. A similar gap shows up in procurement: a three-quote rule is followed for every purchase, but if nobody also checks quality standards and delivery timelines, three colluding vendors can still submit inflated quotes that clear the rule while overcharging the company.
What a test of operating effectiveness checks
Once a control’s design has passed, a test of operating effectiveness obtains evidence about whether the control is actually operating as designed. That evidence has to be gathered across the whole period under review, not just for one transaction — and the auditor also checks whether the person performing the control has the necessary authority and the necessary competence to do it properly.
Both of those can fail independently of the design. Take the same visitor register, now assume it has been properly redesigned with ID and OTP checks. If the security guard is never actually given the authority to stop a senior employee’s guest from skipping the check, that is an authority failure. If a newly hired, untrained guard does not know how to run the check and people learn they can walk past, that is a competence failure. In both cases the design was fine; the control still did not operate effectively.
Test of design vs test of operating effectiveness, side by side
| Aspect | Test of design (TOD) | Test of operating effectiveness (TOE) |
|---|---|---|
| Question asked | If it runs as intended, is the control capable of managing the risk and meeting the objective? | Did the control actually run, throughout the period, by someone able to run it properly? |
| When it’s done | First — there is no point testing effectiveness until design has passed | Second, and only if the design passed |
| How it’s tested | Observation, process walkthroughs, reviewing policies and procedures, checking segregation of duties and access controls | Gathering evidence of the control’s actual operation across the review period; checking the performer’s authority and competence |
| Typical failure | A missing control, or a control that works as built but still can’t stop the risk | A properly designed control that was not followed, or was run by someone without the authority or the competence to do it |
| Result if it fails | Recommend a design change; do not test effectiveness | Report an operating-effectiveness deficiency |
How to conclude that a control is deficient
A deficiency in internal control exists when, in the normal course of business, a control fails to mitigate the risk or achieve the objective it is meant to serve. That can happen for either of two reasons: the design itself is inadequate (covered above), or a properly designed control does not operate as designed — including because the person performing it lacks the necessary authority or competence.
The standard to apply is persuasive evidence: evidence strong enough that an independent third party would reach the same conclusion you did. If you cannot obtain persuasive evidence that a control operated as designed, that itself is treated as a deficiency in operating effectiveness. Sometimes you will only find supplementary, indirect evidence that something is wrong — in that case, go back and look for primary evidence that is persuasive enough to support the conclusion on its own.
Worked example: testing a monthly MIS submission control
This follows the course’s own teaching example and is a method illustration, not a real client. A company requires every department to submit a management information report (MIS) to senior management by the 5th of each month. Here is how the two tests apply to that one control.
| Step | What you test | Why it matters |
|---|---|---|
| 1. Test of design | Does the written control actually require a deadline (the 5th) and say what the MIS must contain, and is that adequate to give management timely, useful information? | If the design itself does not specify a deadline or minimum content, no amount of good execution will fix that |
| 2. Test of effectiveness — timing | Across the months in the review period, did each department’s MIS actually reach management by the 5th? | A control that is only sometimes on time is only partly effective |
| 3. Test of effectiveness — content | Does the MIS contain the facts management actually needs to decide something, or is it submitted on time but empty of useful content? | An MIS that arrives on time but cannot support a decision has not met the control’s real objective |
| 4. Test of effectiveness — competence | Does the person preparing the MIS know where to pull the figures from, and can they assemble the report correctly? | Even a well-designed, on-time control fails if the preparer is not competent to produce it correctly |
Notice that a control can be “partly effective” — on time every month, say, but short on useful content — which is why operating-effectiveness testing has to look at more than one dimension of the same control, not just whether it ran at all.
▶ Watch it explained
Short videos from our internal audit course. Each one covers a single topic, step by step.
📄 Get the template
Accounting and Finance Operations: Risk and Control Matrix (Excel). 58 controls (46 key) for 16 objectives and 32 risks — each one with walkthrough questions, evidence to ask for and test steps, so you can run both a test of design and a test of operating effectiveness straight from the sheet.
✅ Test yourself
Questions from our course quizzes. Click a question to see the answer.
An internal auditor wants to check whether a company’s expense-approval control is capable of managing the risk, before even checking whether people are following it. Which test is this?
A test of design. It asks whether the control, as designed, is adequate to manage the risk and achieve the objective — a separate question from whether it is actually being followed.
An auditor finds a control that exists and, if run exactly as intended, would still not stop the risk it’s meant to address. What kind of design gap is this?
An inadequately designed control. This is the second type of design deficiency — the control is present and “effective” in the sense of running as built, but it still doesn’t mitigate the risk. (The first type is a control that is missing altogether.)
A segregation-of-duties control is running exactly as designed, but the person performing it doesn’t have the competence to do it properly. What does this tell you?
There is a deficiency in operating effectiveness, not in design. A test of effectiveness checks two things: whether the control operates as designed, and whether the person performing it has the necessary authority and competence.
Frequently asked questions
What is the difference between a test of design and a test of operating effectiveness?
A test of design checks whether a control, as designed, is capable of managing the risk and meeting the objective. A test of operating effectiveness checks whether that control actually ran, consistently, across the review period, by someone with the authority and competence to run it.
Why test design before testing effectiveness?
Because if the design itself cannot manage the risk, no amount of careful execution will fix that. Testing effectiveness on a badly designed control wastes audit time on a control that was never going to work.
What are the two ways a control’s design can fail?
Either the control is missing altogether, or it is present and running exactly as built, but still cannot mitigate the risk or meet the objective — usually because something in the design, such as verification of identity or quality, was left out.
Can a well-designed control still fail an operating-effectiveness test?
Yes, for two reasons: it simply did not run as designed during the period, or the person running it lacked the necessary authority or competence to do it properly.
What is “persuasive evidence” in control testing?
Evidence strong enough that an independent third party reviewing the same facts would reach the same conclusion. If you cannot find persuasive evidence that a control operated as designed, that absence is itself treated as a deficiency.
Related reading: Internal control explained: the COSO framework and examples · The 17 COSO principles explained, with examples · Preventive vs detective controls, with clear examples · Internal audit interview questions and answers
