How to Test Control Design: A Practical Guide for Auditors
Before auditors test whether an internal control is operating effectively, they should answer a more fundamental question:
Is the control properly designed in the first place?
A control can operate exactly as management intended and still fail to address the underlying risk.
That is why evaluating control design is an essential part of internal auditing, SOX compliance, and evaluating internal control under the COSO Framework.
What Is Control Design?
Control design addresses whether a control, if performed as intended, is capable of preventing or detecting and correcting the risk or potential misstatement it was established to address.
Consider a company concerned about unauthorized payments.
Management requires a supervisor to approve every payment before release.
The auditor should not immediately begin selecting a sample of approvals.
First, the auditor needs to determine whether the approval control is adequately designed.
Questions might include:
Who performs the approval?
Does that person have appropriate authority?
What information does the reviewer examine?
What criteria are used to approve or reject a payment?
Is the reviewer independent of the person initiating the payment?
Does approval occur before the payment is released?
Is evidence of the review retained?
A signature alone does not demonstrate that a meaningful control has been designed.
Start with the Objective
A strong control evaluation starts with the organization's objective.
The basic relationship should be:
Objective → Risk → Control → Testing
For example:
Objective: Pay only valid vendors for authorized goods and services.
Risk: A fraudulent or fictitious vendor could receive payment.
Control: New vendors require independent review and approval before activation in the vendor master file.
The auditor can now evaluate whether that control is actually capable of addressing the identified risk.
Without understanding the risk, it is difficult to determine whether the control design makes sense.
Five Questions for Evaluating Control Design
A practical design assessment can begin with five questions.
1. What Risk Does the Control Address?
Every significant control should address an identifiable risk.
If management cannot explain the risk that a control addresses, the control may be unnecessary—or management may not understand why the control exists.
2. Who Performs the Control?
Determine whether the control owner has appropriate:
Authority
Competence
Independence
Information
System access
Segregation of duties should also be considered.
A control performed by the same person responsible for the underlying transaction may provide little independent assurance.
3. What Does the Control Owner Actually Do?
"Management reviews the report" is not a sufficient description of a control.
What does management review?
What criteria are applied?
What differences trigger investigation?
How are exceptions resolved?
What evidence demonstrates that the review occurred?
A control needs sufficient precision to address the identified risk.
4. When and How Often Is the Control Performed?
Frequency matters.
A monthly control may not adequately address a risk requiring daily attention.
Auditors should consider whether the control operates:
Per transaction
Daily
Weekly
Monthly
Quarterly
Annually
When a specific event occurs
The frequency should be appropriate for the nature and significance of the risk.
5. What Happens When the Control Identifies a Problem?
Detection alone is not enough.
The auditor should understand how exceptions are investigated, escalated, corrected, and documented.
A control that identifies errors but produces no corrective action may not effectively address the risk.
Use Walkthroughs to Understand Design
A walkthrough is one of the most useful techniques for evaluating control design.
The auditor follows a transaction or process from beginning to end while interviewing personnel, examining documents, observing procedures, and understanding relevant systems.
A good walkthrough should help answer:
What actually happens—not merely what the policy says should happen?
Auditors should be cautious about relying exclusively on interviews.
Management may describe a well-designed process that operates differently in practice.
Inquiry should therefore be combined with other procedures such as observation, inspection, and reperformance when appropriate.
Design Effectiveness vs. Operating Effectiveness
These concepts should not be confused.
Design effectiveness asks:
If this control operates as intended, can it adequately address the risk?
Operating effectiveness asks:
Did the control actually operate as designed, consistently, during the period being tested?
Design comes first.
If a control is poorly designed, testing 25, 40, or 100 examples will not fix the problem.
The auditor would simply be proving that an ineffective control operated consistently.
Example: Bank Account Changes
Consider the risk that a fraudster could change a vendor's bank account and divert payments.
Management's control is:
"Accounts Payable reviews bank-account changes."
That description is not enough to conclude that the control is effectively designed.
The auditor should determine:
Who reviews the change?
Is that person independent of the employee entering the change?
How is the vendor's identity independently verified?
Is verification made using trusted contact information rather than information contained in the change request?
Is the bank change approved before becoming effective?
Are changes logged and monitored?
What happens when verification fails?
Only after understanding these elements can the auditor determine whether the control is appropriately designed to mitigate the risk.
Common Control Design Deficiencies
Auditors frequently encounter controls that exist but are poorly designed.
Examples include:
No clear control owner
Inadequate segregation of duties
Review performed after the transaction is completed
Control performed too infrequently
Reviewer lacks necessary information
No defined criteria for investigating exceptions
Review is too high-level to detect significant errors
System access allows the control owner to bypass the control
No evidence that the control occurred
Identified exceptions are not followed up
Control does not actually address the identified risk
These are design problems, not simply testing exceptions.
Documentation Matters
The auditor's workpapers should clearly explain why the auditor concluded that a control is—or is not—appropriately designed.
A strong control description should identify:
Who performs the control.
What the person does.
When the control occurs.
Why the control addresses the risk.
What information is used.
What evidence demonstrates performance.
How exceptions are handled.
Descriptions such as "manager reviews," "supervisor approves," or "report is monitored" rarely provide enough information to understand the actual control.
The Bottom Line
Testing control design is not about determining whether a policy exists.
It is about determining whether the control is capable of addressing the identified risk if it operates as intended.
The auditor should be able to trace a logical path:
Objective → Risk → Control → Design Assessment → Operating Effectiveness Testing
If the control fails the design assessment, there is little value in performing extensive operating-effectiveness testing.
You cannot test your way out of a poorly designed control.
Learn Internal Control Testing with Corporate Compliance Seminars
Corporate Compliance Seminars provides CPE training for internal auditors, external auditors, compliance professionals, and management responsible for evaluating internal controls.
CCS programs address topics including:
COSO Internal Control Framework
Design effectiveness
Operating effectiveness
Walkthroughs
Risk and control identification
Entity-level controls
Control activities
Testing techniques
Audit evidence
SOX compliance
Internal control documentation
Relevant CCS training includes programs on Design and Operating Effectiveness, Understanding COSO Framework Compliance, Effective Use of the COSO Framework, and other internal audit and SOX-related CPE events.
The goal is not simply to determine whether a control exists.
Auditors need to determine whether it is the right control for the risk—and whether it actually works.

Comments