Control testing is one of the most consequential steps in any audit or compliance engagement. A well-designed control that is never properly tested offers little real assurance. Yet, even experienced audit teams make recurring errors, errors that produce rework, weaken audit opinions, and create unnecessary risk for both the firm and the client.

In this article, I will break down the 12 most common control testing mistakes, explain why they happen, and provide practical guidance for avoiding them. It also covers best practices, warning signs to watch for, and how purpose-built tools like Roz can help audit teams work more efficiently without sacrificing professional judgment.

What Is Control Testing?

Control testing refers to an evaluation process performed by auditors to determine whether an internal company control is designed effectively and operates effectively to address the identified risks. Control testing also assesses whether the control can be considered dependable for the purpose of an audit or compliance evaluation.

Control testing involves two evaluations:

• Design effectiveness: Assesses if the control is appropriately designed to either prevent or detect a certain risk. A control can be documented in great detail but can still be designed poorly and, therefore, be ineffective.

• Operating effectiveness: Assesses if the control was performed as designed and was, in fact, performed throughout the review period.

Control testing is an essential element of a variety of audit and compliance engagements, including but not limited to SOX compliance, SOC 2, ISO 27001, internal audits and assessments, and audits of financial statements. While the procedures for control testing differ depending on the standards adopted and the purpose of the engagement, the basic concept remains the same: obtain sufficient and appropriate evidence to support the assessment of a control's design and operating effectiveness in the context of mitigating the risk.

12 Common Control Testing Mistakes

1. Testing Controls Without Understanding the Risk

Control testing should begin with understanding the risk that the control is meant to address. Control tests done without understanding the risk may result in audit procedures that confirm that the control operated as intended; however, the auditor may not determine if the control addresses the risk.

How to avoid it: Controls should be mapped to the risks and associated financial statement or compliance assertion before control testing procedures are defined. This helps the auditor understand the control’s objective and the risk the test is meant to address.

2. Confusing Design Effectiveness with Operating Effectiveness

Evaluating design effectiveness requires determining whether a control can address a specific risk. Assessing operating effectiveness, on the other hand, involves evaluating whether the control operated as intended throughout the review period. Both assessments are to be considered separately.

How to avoid it: Prior to testing the operation of a control, determine whether the control is adequately designed. If the control design is deemed sufficient, then determine whether the control operated as intended during the review period.

3. Relying on Inquiry Alone

Although inquiry may assist in understanding the operation of a control, it may not be relied upon as the sole audit evidence. Conclusions should be based on sufficient and appropriate audit evidence.

How to avoid it: Corroborating inquiry should be supplemented with inspection, observation, or reperformance. Evidence supporting a control should be sufficient to demonstrate that the control operated as intended.

4. Selecting Poor or Biased Samples

Testing based on an incomplete or convenient sample may not result in a reliable basis for evaluating control effectiveness. A sample should be representative of the population being tested and relevant to the objective of the audit.

How to avoid it: Use a sampling methodology that is appropriate to the control frequency, population, level of risk, and relevant audit guidance. Provide thorough documentation of your sampling methodology.

5. Failing to Validate Information Produced by the Entity (IPE)

Audit evidence is often based on system-generated reports and data extracts. Auditors should determine if the IPE is complete and accurate, as the use of incorrect information can impact the results of audit testing.

How to avoid it: Confirm that the report or data extract includes the complete population, was generated using appropriate criteria, and accurately reflects the underlying data. Retain documentation of the validation procedure.

6. Treating Evidence Collection as Control Testing

The mere collection of relevant documentation does not indicate that a control is functioning. Auditors are required to assess the evidence to determine whether the control operated effectively in relation to its stated control objective.

How to avoid it: Clearly document the control testing in detail and the evidence evaluated, the results of the evaluation, and the conclusion for each control.

7. Testing Management Review Controls Too Broadly

Merely confirming a management review is inadequate. Auditors must verify that the review was sufficiently detailed to flag where errors or exceptions may have occurred.

How to avoid it: Analyze the review's scope, the criteria or thresholds set, the information reviewed, how exceptions were treated, and if the exceptions were resolved.

8. Misinterpreting Control Deviations

Not all control deviations should be considered a significant deficiency or a material weakness. Control deviations should be considered in relation to the severity of the control deviation, how often it occurs, and the reason for the deviation.

How to avoid it: Assess the severity of the control deviation, the control weakness, or the control deficiency, and if control deficiencies exist, identify what other controls mitigate the control deviation before you conclude.

9. Ignoring IT Dependencies

While some controls are manual, they may rely on automated systems or IT general controls. Failure to consider these dependencies may affect the reliability of testing conclusions.

How to avoid it: For each control, determine what manual controls, IT systems, and reports are used and what automated calculations and access controls are used, and make sure that the appropriate IT dependencies are addressed in the engagement.

10. Poor Testing Documentation

Testing documentation must have sufficient detail and clarity to allow an experienced auditor to understand what was done, what evidence was collected, how a conclusion was drawn, and what that conclusion was.

How to avoid it: Testing documentation must include sampling, the methodology and rationale, and any exceptions identified with a clear and consistent layout.

11. Overlooking Compensating Controls

When a primary control is ineffective, there is still the opportunity to address the risk with additional controls. These compensating controls are relevant before determining the impact of a control deficiency.

How to avoid it: Assess the presence of other controls that address the same risk and the extent to which they are effective. Then, determine and communicate their impact on the overall control system.

12. Overrelying on AI Without Auditor Validation

While working with AI when it comes to the organization of evidence and extraction of controls and even the drafting of initial workpapers has its benefits, there is still a need to use professional judgment when it comes to evaluating the effectiveness of a control.

How to avoid it: AI-generated documentation needs to be treated as draft work, which will be subject to a review and validation by an auditor. The final conclusions will need to be based on sufficient evidence and need to be approved by the engagement team.

Best Practices for Effective Control Testing

Strong control testing programs share several common characteristics:

• Start with a risk assessment: Testing should be scoped based on risk as opposed to what is most convenient.

• Standardize testing procedures: Using standardized templates and methodologies reduces variability across staff members and increases efficiency in the review process.

• Validate audit evidence: Prior to relying on evidence, confirm that it is complete, accurate, and appropriately supported, including validation of IPE where applicable.

• Document professional judgment: Workpapers should include the auditor’s reasoning for the decision as opposed to the result.

• Review testing results throughout the engagement: Catching issues is more cost-effective to resolve mid-engagement as opposed to during the review.

• Use AI to accelerate documentation: While AI has the potential to accelerate first-pass drafting, auditor review of all AI-developed documentation remains essential before conclusions are finalized.

Common Warning Signs That Your Control Testing Process Needs Improvement

These common issues in control testing do not reflect a defect in a single instance. Control testing has clear issues when:

• Reviewers frequently comment on the same testing documentation or other documentation.

• Different team members or engagements exhibit testing methods that are distinct.

• Evidence is incomplete or missing when work is reviewed.

• Workpapers are revised multiple times within the same engagement.

• Control testing exhibits cumbersome tracking methods.

• Audit timelines are extended due to gaps in evidence.

Typically, the issues in control testing are clear defects in a process that reflect the need for improved structure, quality templates, or adequate training.

How Roz Helps Firms Streamline Control Testing

Roz is an AI platform built specifically for external audit and advisory firms. It helps teams accelerate evidence collection, perform readiness assessments, and support first-pass control testing workflows while keeping auditor judgment at the center of every engagement.

Roz helps firms streamline control testing by:

• Organizing policies, evidence, and workpapers in client-specific workspaces

• Supporting documentation review and readiness assessments to surface potential documentation gaps

• Accelerating evidence organization and mapping for more efficient testing

• Generating AI-assisted first-pass workpapers with source-linked traceability

• Supporting evidence sufficiency assessments before the review stage

Roz streamlines documentation and first-pass analysis, allowing auditors to focus more on evaluating controls. Professional judgment, testing conclusions, and final audit opinions remain the responsibility of the engagement team.

Conclusion

Mistakes in control testing occur for numerous reasons, but an obvious one is that auditors do not take control testing lightly. Mistakes occur because of uneven testing, time constraints, or difficulties of a mental nature when an auditor tries to maintain discipline for numerous controls in the same engagement.

Strong control testing practices begin with understanding the underlying risk, distinguishing design from operating effectiveness, validating audit evidence, documenting professional judgment, and reviewing work throughout the engagement.

Audit teams that develop these behaviors and reinforce them with appropriate tools and structured workflows are more likely to produce consistent documentation, defensible conclusions, and fewer reviewer comments.

Frequently Asked Questions

What evidence is required for control testing?

Evidence is required to be sufficient, appropriate, and corroborated. Control evidence can take the form of system reports, access logs, approvals, screenshots, or signed forms, which must be validated prior to testing.

What is Information Produced by the Entity (IPE)?

IPE refers to audit evidence in the form of data or reports generated by the entity being audited. Due to the inherent risk that IPE may not be reliable, the PCAOB Standards require auditors to first assess IPE for its accuracy and completeness before consideration.

What happens if a control fails testing?

A control that fails testing will result in a documented failure. The auditor is required to determine the cause of the failed control, assess the severity of the compensating controls, evaluate the failing control’s effect on the control objective, and decide if additional testing is warranted. The audit opinion may be impacted if controls fail frequently or are considered severely deficient.

Can AI perform control testing?

No. AI may help with drafting, organizing evidence, and spotting gaps, but control testing is beyond AI because it involves auditor judgment. Roz and similar tools are built to support that judgment.

How often should controls be tested?

The type of engagement, the chosen framework, and the level of control risk determine the testing interval. For example, in SOX 404 and SOC 2 Type II engagements, controls are generally tested after a period of 6 to 12 months. Controls that are considered to be of a higher risk may require more frequent and intensive testing within that interval.