How to Evaluate Design Effectiveness of Internal Controls

To evaluate the design effectiveness of internal controls, you determine whether each control, if performed as written by a person with the necessary authority and competence, would prevent or detect a misstatement that could be material to the financial statements. The work is done primarily through a walkthrough: you select a transaction, trace it through the process, and confirm the control ties to a specific financial assertion and would actually meet its objective. Design comes first in any Sarbanes-Oxley evaluation because there is no point testing whether people execute a flawed procedure faithfully.

What “Designed Effectively” Means

PCAOB Auditing Standard 2201 defines the test directly. A control is designed effectively when it, operated as prescribed by people with the necessary authority and competence to operate it effectively, would satisfy the company’s control objectives and effectively prevent or detect errors or fraud that could result in material misstatements in the financial statements.¹

Keep design and operation separate as you work. Design looks at the blueprint. Operation watches the building in use. A control that requires a manager to review every journal entry over $50,000 against supporting documentation is well-designed for catching unsupported entries. If the manager rubber-stamps everything without reading the backup, the design is sound and the operation is not. A design deficiency exists when a necessary control is missing entirely or an existing control would not meet its objective even if performed perfectly. An operating deficiency exists when a well-designed control is not performed as intended or the person responsible lacks the competence or authority to execute it.¹

Select the Right Controls to Evaluate

AS 2201 requires a top-down, risk-based approach. Start at the financial statement level, identify where misstatements are most likely to occur, then work downward through entity-level controls, significant accounts, relevant assertions, and finally individual process-level controls.¹ Selecting the wrong controls wastes effort while leaving the ones that actually matter untested.

Entity-Level Controls

Entity-level controls operate across the whole organization: the control environment, controls over management override, the risk assessment process, and monitoring activities such as internal audit and audit committee oversight. They vary in how directly they prevent misstatements. Some shape the overall control culture without catching specific errors. Others monitor lower-level controls and can reduce process-level testing. In rare cases, an entity-level control operates with enough precision to address a specific assertion on its own, eliminating the need for further testing of that risk.¹ Your design work has to sort each entity-level control into the right category, because that dictates how much weight it can carry.

Process-Level Controls and Relevant Assertions

Next, identify significant accounts, disclosures, and their relevant assertions. A relevant assertion is one where there is a reasonable possibility of a misstatement that could be material.¹ For revenue that might be occurrence and completeness. For inventory it might be existence and valuation. Identify which controls management has put in place to address each assertion, then evaluate whether those controls, if performed correctly, would actually do the job.

Gather the Documentation You Need

The Risk and Control Matrix

The Risk and Control Matrix is the primary document. A useful RCM identifies each risk, the assertion it threatens, the control designed to address it, who performs the control, and how often it runs. Frequency matters even at the design stage because it affects how much evidence will be available for later operating testing.

Watch for vague objectives. A control objective written as “ensure accuracy of financial reporting” without a specific assertion attached makes it impossible to judge whether the control addresses the right risk. The objective should be concrete, along the lines of “ensure all revenue transactions are recorded in the correct accounting period.”

Flowcharts and Narratives

Flowcharts and process narratives sit alongside the RCM and show how transactions actually move through the business. A good narrative describes who initiates the transaction, how it enters the system, what approvals or reviews occur, and where the data lands in the general ledger. Outdated or imprecise narratives are a frequent reason walkthroughs turn up surprises, because the paperwork describes a process that no longer exists.

Information Produced by the Entity

Many controls depend on system-generated reports. A manager reviewing an aging report to evaluate the allowance for doubtful accounts is only performing an effective control if the aging report itself is accurate and complete. This category is known as information produced by the entity, or IPE, and it deserves its own layer of design scrutiny. Consider whether the report is a standard system output, a custom-built query, or an ad-hoc export. Standard reports carry lower risk. Ad-hoc queries with flexible parameters carry higher risk because they sit outside normal IT change management. If the underlying data is unreliable, the control is unreliable, however well the review procedure reads on paper.

Run the Walkthrough

AS 2201 identifies walkthroughs as frequently the most effective way to evaluate design, and auditors must either perform them personally or directly supervise the work.¹

Trace a Transaction End to End

Select a single transaction and follow it from origination through the company’s processes and information systems until it appears in the financial records. Use the same documents and technology company personnel use, and watch the process unfold rather than reviewing a completed file after the fact.¹ Tracing a purchase order from requisition through approval, receipt, invoice matching, and payment posting confirms each step in the narrative actually happens and that the handoffs work as described.

Probe What the Person Actually Understands

At each point where important processing occurs, ask personnel about their understanding of the company’s prescribed procedures. Go beyond confirming that the task gets performed. Test whether the person knows why the control exists and what they are looking for when they execute it.¹ Someone who signs a reconciliation without knowing what discrepancies should trigger escalation is a design problem hiding behind a completed form.

Cover the Fraud Points

Identify points within the process where a misstatement due to fraud could arise that, alone or combined with other misstatements, would be material.² Then confirm management has controls to address those potential misstatements, including controls over unauthorized use of company assets.¹ Fraud risk is part of the walkthrough’s objectives, not a separate exercise.

Handle IT and Automated Controls

AS 2201 treats IT controls as part of the top-down approach, not a separate workstream. Understand how information technology affects the flow of transactions and evaluate both automated application controls and the IT general controls that support them.¹

Automated controls have a useful property. When the underlying IT general controls over program changes, access, and computer operations are effective, and the automated control has not changed since it was last validated, you can conclude the control continues to be effective without repeating full testing every year. Software performs the same check identically every time. Even so, the design assessment has to confirm the automated control depends on reliable data. An automated interest calculation is only as good as the rate table feeding it.¹

Spot the Common Design Gaps

Segregation of Duties

The most recognizable design gap is a failure to separate incompatible responsibilities. When one person can both initiate and approve a transaction, the structure has a built-in blind spot, because no independent check exists against error or fraud. If the procedure on paper assigns both functions to the same person, the control fails the design test regardless of how trustworthy that person has been.

Smaller companies with limited staff face this constantly, and AS 2201 acknowledges it. When segregation is not feasible, the company may implement alternative or compensating controls to achieve the same objective, and the design assessment then evaluates whether those alternatives are effective. A compensating control has to operate at enough precision to prevent or detect a misstatement that could be material. A vague management review does not compensate for a fundamental segregation gap.¹

Insufficient Precision of Management Reviews

This is where most design failures hide. A manager who reviews a high-level variance report without access to the underlying transaction detail is performing a control that looks real on the RCM but cannot actually catch a material error. The PCAOB has identified factors that determine whether a management review control operates at sufficient precision:³

Level of aggregation. A review performed by location or product line is more precise than one performed at the total-company level.
Investigation thresholds. A control that investigates variances of $10,000 or more is more precise than one that only flags items approaching financial statement materiality.
Predictability of expectations. The reviewer needs a reasonable basis for what the numbers should look like. Without well-developed expectations, any result looks acceptable.
Correlation to assertions. A control directly tied to a specific assertion catches more than one loosely related to the general topic.
Frequency of performance. A monthly review catches misstatements before they compound across quarters.

Also evaluate whether the person performing the review has the competence and authority to investigate anomalies and force corrections. A review performed by someone who lacks the seniority to push back on questionable entries is poorly designed even if the reviewer is technically skilled.³

Broken Links Between Risk and Control

A subtler gap occurs when a control activity does not actually address the risk it is mapped to. A three-way match between purchase orders, receiving reports, and invoices is a strong control for the occurrence assertion on accounts payable. It does nothing for completeness, because it only validates transactions that already entered the system. If the RCM maps that control to completeness, a design gap exists even though the control works perfectly for its actual purpose. These mismatches often survive multiple audit cycles because people test the control without questioning whether it addresses the right risk.

Grade the Severity

Not every design flaw carries the same weight. AS 2201 sets a hierarchy that determines what gets reported and to whom. A control deficiency exists whenever a control’s design or operation does not allow personnel to prevent or detect misstatements on a timely basis. A significant deficiency is a deficiency, or combination of deficiencies, important enough to merit attention from those overseeing financial reporting, such as the audit committee. A material weakness is a deficiency, or combination of deficiencies, where there is a reasonable possibility that a material misstatement of the annual or interim financial statements will not be prevented or detected on time.¹

Severity turns on two factors: the likelihood that controls will fail to catch a misstatement, and the potential size of that misstatement. A deficiency does not need to have caused an actual error to qualify as a material weakness. The question is whether it reasonably could.¹ Individual deficiencies that seem minor in isolation can aggregate into a material weakness when they affect the same account or assertion.

What Follows a Design Gap

When a design deficiency rises to a material weakness, disclosure becomes mandatory. Management cannot conclude that internal controls are effective if a material weakness exists, and the company must disclose the weakness in its annual filing. Significant deficiencies that do not individually reach material weakness do not require public disclosure, but they must be communicated to the audit committee. Multiple significant deficiencies in related areas can aggregate into a material weakness, so treating them as safely below the radar is a mistake.⁴

Remediation typically means redesigning the control, updating the RCM, and running the redesigned control long enough before year-end for auditors to test both its new design and its operating effectiveness. Discover a design deficiency too late in the year, and you may try to implement a compensating control, but that compensating control has to operate at sufficient precision to prevent or detect a material misstatement. Auditors are skeptical of compensating controls introduced in the final weeks before a filing deadline. Building the design review into the compliance calendar early enough for remediation to breathe is the practical answer.

1
Public Company Accounting Oversight Board. AS 2201 – An Audit of Internal Control Over Financial Reporting That Is Integrated with An Audit of Financial Statements
2
Public Company Accounting Oversight Board. AS 2110 – Identifying and Assessing Risks of Material Misstatement
3
Public Company Accounting Oversight Board. Staff Audit Practice Alert No. 11 – Considerations for Audits of Internal Control over Financial Reporting
4
U.S. Securities and Exchange Commission. Management’s Report on Internal Control Over Financial Reporting and Certification of Disclosure in Exchange Act Periodic Reports – Frequently Asked Questions