Table of Contents
Controls testing is the process of evaluating whether an organization's internal controls are properly designed and consistently operating to prevent errors, fraud, and regulatory non-compliance. It is required for SOX, SOC 2, HIPAA, GDPR, and most compliance frameworks.
The testing methodology is well established. What makes it expensive is the coordination: collecting evidence from control owners across departments, tracking completion, routing exceptions, and assembling audit-ready packages.
Jefferson Wells' 2024 report found that 66% of internal audit teams feel they lack the capabilities to fully support their company's needs, and most of that gap is coordination capacity, not testing expertise.
This guide covers the five testing methods, the difference between design and operating effectiveness, how to scope and build a controls testing workflow, and where it fits within the broader internal audit checklist.
Key takeaways
The five standard testing methods are inquiry, observation, inspection, re-performance, and CAATs. Each is progressively more reliable. Most compliance frameworks require at least inspection-level evidence.
Most controls testing delays come from evidence collection, not the testing itself. Chasing control owners, tracking outstanding evidence, and assembling packages manually consumes more time than the actual tests.
Moving from periodic testing to continuous monitoring reduces audit burden and catches control failures before they become findings.
The five methods for testing internal controls
Inquiry is asking control owners how they execute a control. It is the simplest method but least reliable alone. For example, asking the AP manager how they verify invoice approvals. Auditors accept inquiry as supporting evidence but never as the sole testing method for key controls, so it must be combined with inspection or re-performance.
Observation is watching the control operate in real time. For example, observing the access provisioning process as a new employee is onboarded. The limitation is that behavior may change under observation (the Hawthorne effect), so it proves the control can operate, not that it consistently does.
Inspection of evidence is reviewing documentation proving the control operated during the audit period. A great example is examining signed approval records, system access logs, or reconciliation worksheets. This is the most commonly used method because it produces the strongest paper trail and covers the full audit window, not just a single moment.
Re-performance means the tester independently executes the control to verify accuracy. Example: re-performing a bank reconciliation to confirm the control owner's work matches the original. It is the most reliable method for operating effectiveness but the most time-intensive, so it is typically reserved for high-risk or high-materiality controls.
Computer-assisted audit techniques (CAATs) use technology to analyze large data sets and test controls at scale. Example: running automated checks across all transactions in a period rather than sampling 25. CAATs are the foundation for continuous monitoring and the path from periodic testing to always-on assurance.
Design effectiveness vs operating effectiveness
Design effectiveness tests whether a control is properly structured to prevent or detect the risk it targets. Operating effectiveness tests whether the control actually works as designed over a sustained period. Both are required for SOX and SOC 2 Type II.
A well-designed approval workflow that nobody follows is a design pass and an operating fail. A consistently executed control that does not address the right risk is an operating pass and a design gap. Auditors evaluate both separately. Design testing typically uses inquiry and inspection.
Operating effectiveness testing requires inspection, re-performance, or CAATs with sufficient sample sizes covering the full audit period.
Controls testing vs substantive testing
Controls testing evaluates whether internal controls function as designed. Substantive testing verifies the accuracy of the data those controls protect.
They serve different purposes but work together. When controls testing shows strong operating effectiveness, auditors reduce substantive testing volume by sampling fewer transactions.
When controls are weak, auditors compensate with more extensive substantive procedures. The practical implication: strong controls testing results equal shorter, cheaper audits.
How to scope and prioritize controls for testing
Regulatory-critical controls come first. SOX key controls, SOC 2 trust service criteria, HIPAA safeguards. These are non-negotiable and typically require the most rigorous methods (inspection plus re-performance with larger samples).
Tier by materiality and risk. High-value financial controls and controls over sensitive data deserve deeper testing. Low-risk routine controls can rely on inquiry plus observation with smaller samples. Not all 200+ controls need the same depth.
Factor in change and failure history. New controls, recently modified controls, and controls that failed in prior periods get elevated priority. Stable controls with clean track records can be tested less frequently, freeing capacity for higher-risk areas.
How to build a controls testing workflow
Assign testing responsibilities with clear ownership and deadlines. Every control needs a tester, a control owner providing evidence, and a reviewer. Ambiguity on ownership is the single biggest cause of overdue evidence. When the request goes to "the security team" instead of the specific IAM admin, nothing happens.
Send structured evidence requests, not emails. Control owners need clear instructions: what evidence, what format, what deadline. Unstructured email requests get lost, delayed, or returned incomplete. Done well, control owners submit evidence through magic-link tasks with structured forms and an automated check that validates completeness on upload, the pattern behind compliance workflow automation.
Track completion in real time. A dashboard showing which controls have been tested, which are pending evidence, and which are overdue. Automated reminders replace the "just checking in" emails that consume audit team bandwidth.
Route exceptions through structured remediation. When a control fails testing, route the finding to the control owner with documented requirements, a deadline, and an escalation path, then track resolution to closure. Running remediation as a workflow step that flags incomplete corrective actions before they slip is the discipline behind automated regulatory compliance.
Document everything as you go. Every evidence submission, test result, and remediation action logged with timestamps and assignees. Do not reconstruct the audit file the week before the auditor arrives. With compliance-grade logging, the documentation becomes a byproduct of the workflow rather than a separate project, an exportable compliance audit trail.
Assemble the audit package automatically. When evidence collection, testing, and remediation run through a single workflow, the package builds itself. External auditors see one structured view, not scattered folders.
How to run a controls testing cycle on Moxo
Moxo is a process orchestration platform that runs the full control testing cycle as one structured workflow, from scoping through audit package delivery, built for the coordination layer where testing usually stalls.
Describe your testing scope and Moxo generates the stages: evidence assignment, collection, testing, remediation, and package assembly.
Each control maps to a named evidence provider and tester with a deadline, AI agents validate submissions at upload and flag gaps before a reviewer opens the file, and exceptions route into remediation with documented requirements and escalation when deadlines pass.
You track completion in real time on a reporting dashboard, every test result and disposition is logged in a compliance-grade audit trail across 65+ action types, and when fieldwork begins external auditors open the finished package through magic-link access, organized by control and framework with no account to set up.
Effective compliance depends on workflow
Compliance frameworks like SOX, SOC 2, and HIPAA make controls testing non-negotiable, but the methodology itself hasn't evolved in decades. The real differentiator between organizations that breeze through audits and those that struggle is the workflow supporting the testing process.
Success hinges on replacing manual chaos with structured evidence collection, real-time tracking, documented remediation, and automated audit package generation. By utilizing a process orchestration layer, you can automate evidence validation, reminders, and assembly, allowing your team to focus on risk assessment and remediation.
If you are ready to shift from periodic testing to always-on assurance, explore our guide to continuous control monitoring to learn how to test controls in real time.
FAQ
What is the difference between controls testing and substantive testing?
Controls testing evaluates whether internal controls function as designed (does the approval workflow work?). Substantive testing verifies the accuracy of underlying data (are the financial statements correct?). Strong controls testing results allow auditors to reduce substantive testing volume, which means shorter and cheaper audits.
How often should internal controls be tested?
SOX key controls and SOC 2 Type II controls are tested annually at minimum, covering the full audit period. High-risk controls may warrant quarterly testing. ISO 27001 requires testing before each surveillance audit. Continuous controls monitoring through CAATs supplements periodic testing by flagging failures in real time.
What is continuous control monitoring?
Continuous controls monitoring uses automated tools to test controls on an ongoing basis rather than periodically. Instead of sampling 25 transactions annually, CAATs analyze every transaction continuously. This shifts from "did the control work during the audit period?" to "is the control working right now?" and reduces the gap between control failure and detection from months to hours.
What happens when a control fails testing?
The finding is classified by severity (critical, high, medium, low). The control owner receives a documented remediation requirement with a deadline. A corrective action plan is created, tracked, and verified upon completion. Critical and high findings typically require re-testing after remediation. The full finding-to-resolution trail must be documented for auditors.
How do I start building a controls testing program from scratch?
Start with your regulatory requirements (SOX, SOC 2, HIPAA) to identify which controls are mandatory. Map each control to the risk it addresses and the evidence that proves it operates. Assign a named owner to each control. Build a testing schedule based on risk tier and regulatory cadence. Execute the first cycle manually to establish baselines, then automate the coordination layer.
