9.1 Procedures to Evaluate Control Design

9.1 Procedures to Evaluate Control Design

Quick Answer: Design adequacy asks one question: if this control operated exactly as designed, would it prevent or detect the risk on a timely basis? CIA Part 2 A6a tests whether you can determine procedures that answer that question — walk-throughs, narrative versus flowchart, inspecting configuration, tracing one transaction, and a RACI (or equivalent matrix) for segregation of duties. A design failure is not an operating failure. If design is broken, you may stop or redirect operating tests of that control.

You have already identified key risks and the controls that are supposed to address them (Chapters 7–8). Section A6 of the 2025 syllabus is still engagement planning: determine procedures and prepare the work program (GIAS Standard 13.6). This section is only A6a — the types of procedures used to evaluate control design. Whether the assembled work program is adequate, which domain methodologies to use, and what financial, human, or technology resources you need are Chapter 10. Sampling theory as an information-gathering method appears later in Section B. Stay on design procedures.

Do not treat “the policy exists” as design evaluation. A policy is a criterion. Design evaluation asks whether the control as built — people, systems, thresholds, evidence, and timing — would actually address the risk if everyone followed it.

The design question

The COSO Internal Control — Integrated Framework describes controls as present (designed and placed in operation) and functioning (operating as designed). CIA Part 2 A6 splits the testing idea into three procedure families: design (this section), operating effectiveness (9.2), and efficiency (9.3). Mixing those families is how otherwise easy items get missed.

Design adequacy = Would the control, if operated as designed, prevent or detect the risk?

Unpack the phrase before you pick procedures:

• If operated as designed — you assume people and systems follow the written or configured procedure. You are not yet asking whether reviewers skipped March.
• Prevent or detect — a preventive control stops the event (three-way match before payment). A detective control finds it in time to correct it (a reconciliation before close). A detective control that can only find the loss after cash has left and cannot be recovered may be inadequate as designed, not merely inefficient.
• The risk — the specific engagement risk, not a vague “something could go wrong.” Dual approval designed to stop unauthorized vendors does not, by itself, address duplicate payments to a valid vendor.
• Timely — design includes when the control fires. An annual access recertification is a weak design for a joiner–mover–leaver risk that changes weekly.

Implementation (placed in operation) sits with design for planning purposes. A beautiful flowchart that the live ERP does not enforce is not an implemented control. A walk-through of one live transaction is how you confirm the design is not a drawer document.

Design failure versus operating failure

The exam loves a fact pattern where two signatures appear on a form, so candidates shout “effective,” while the same person signed both lines or the system never blocked a single-user path. That is design, not a sample-size problem.

If design is broken, continuing a 25-item operating test of that control wastes hours and implies the control could have worked. Standard 13.6 expects the work program to identify methodologies and allows prompt adjustment. Document the design gap, consider compensating controls, and redirect remaining procedures to residual risk. You do not need an elegant sample of a control that cannot work.

Procedures you must be able to choose

Walk-throughs

A walk-through follows a transaction or event from initiation through processing to recording (and, where relevant, reporting). You combine inquiry, observation, and inspection on one path — often two if there is a happy path and an exception path (holds, overrides, returns, match failures).

Walk-throughs evaluate design and implementation. They are not a substitute for a period-wide test of operating effectiveness. Watching one invoice get matched on Tuesday does not prove the match ran every day of the fiscal year.

Use a walk-through when the process is undocumented or last year’s narrative is stale, when multiple systems hand off, when you need to see whether the control is human or automated, or when you must confirm a new workflow rule is actually live.

Narrative versus flowchart

Determining procedures includes which documentation you will obtain or create, then how you will test that it matches the live process. Inspecting last year’s flowchart and calling design evaluated is a planning failure.

Inspecting configuration

For automated and IT-dependent controls, design often lives in parameters: three-way match required, price/quantity tolerance, workflow that cannot skip a role, vendor-master change that requires a second user, SOD conflict rules in a GRC tool.

Inspect configuration in the production (or locked effective) environment, keep a screenshot or extract in the file, and identify who can change the setting. A control that any accounts-payable clerk can toggle off has a design gap in change protection even if today’s flag is “on.”

Configuration inspection answers design. It does not, by itself, prove the control operated throughout the period if IT general controls over access and change management are weak — that pairing belongs in operating-effectiveness procedures (9.2) and in IT testing methodologies (Chapter 10).

Tracing one transaction

Tracing one item is the transaction-level core of a walk-through: source document → system entry → control fire (match, approval, exception) → output (payment proposal, subledger, general ledger). You are confirming the path exists and the control is capable of firing, not estimating a deviation rate.

Pick the item with purpose. A clean, three-way-matched $200 invoice will never reveal that invoices over $5,000 can bypass match. Trace at least one item that should hit the control you care about, and consider an override or hold item if that is how risk actually gets through.

RACI for segregation of duties

A RACI matrix assigns who is Responsible, Accountable, Consulted, and Informed. For design evaluation, you care whether incompatible duties land on the same person in the live role design — not in an organization chart that pretends AP “reviews” while one ERP role can change the vendor bank account and release the payment run.

Typical incompatible pairs in a payables example: vendor-master create/change versus payment execution; invoice recording versus payment approval; purchasing versus receiving. If one user ID is Responsible for both sides, design fails even if two people sit in the department.

RACI is a design procedure. Testing whether people actually used only their own IDs across the year is operating effectiveness.

Worked example: AP three-way match

A shared-service center says every invoice is three-way matched before payment.

Design looks adequate when: the ERP requires purchase order, goods receipt, and invoice within a documented tolerance; an override requires a second role that cannot be the same user; RACI shows vendor-master maintenance is a different role from payment-run release; a walk-through of an unmatched invoice is blocked by the system.

Design fails when: tolerance is set so wide the match never fails; the invoice processor’s role includes the override; the match flag can be switched off by the process owner with no second review; or a traced “unmatched” invoice posts to the payment proposal anyway.

If the walk-through shows the unmatched invoice posts, you do not then test 40 invoices “to see if match operated.” You conclude design is inadequate for that control, look for compensating detective controls (vendor-statement reconciliation, duplicate-payment analytics), and rewrite remaining procedures around residual risk.

Putting design procedures in the work program

For each key control, name: the risk it addresses; the design question; the procedure (walk-through, configuration inspect, RACI, one-item trace, documentation comparison); the evidence you expect; and the decision rule — including stop testing operating effectiveness if design is inadequate.

That decision rule is an A6a skill. It is not “evaluate whether the work program as a whole is adequate” (A6d). You are choosing the type of procedure and when to abandon a dead control.

Exam traps

• Treating a signed policy or last year’s narrative as proof of design adequacy.
• Calling two signatures “operating effective” when the same person can apply both.
• Sampling dozens of items of a control whose configuration the process owner can switch off with no second review.
• Calling a slow detective control a design failure before you test whether detection is timely relative to the risk (pure slowness with timely detection is efficiency, Section 9.3; lateness that cannot detect in time is still design).
• Drifting into statistical sampling formulas or accounting/IT/cyber methodology catalogs — those are later syllabus bullets.

Design procedures are complete when a reviewer can see, for each key control, how you will know whether the control could work — and what you will do if the answer is no.