Study guide
9.1 Procedures to Evaluate Control Design
CIA Part 2 Study Guide Exam
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: CIA Part 2 Exam Orientation
1.1 Current CIA Part 2 Exam Facts 1.2 Eligibility, Fees, and Pearson VUE Scheduling 1.3 Scoring, Results Timing, and the 2025 Syllabus Map
2 Chapter 2: Engagement Objectives and Scope
2.1 Topical Requirements in Objectives and Scope 2.2 Elements Used to Build Engagement Objectives 2.3 Scope Limitations, Stakeholder Requests, and Scope Changes
3 Chapter 3: Evaluation Criteria and Planning Context
3.1 Selecting and Testing Evaluation Criteria 3.2 Applying Topical Requirements When Planning 3.3 Strategy, Risk Management, and Performance of the Activity Under Review
4 Chapter 4: Technology, Continuity, and Finance in Planning
4.1 Cybersecurity, IT General Controls, Privacy, and Data Security 4.2 Business Continuity, Disaster Recovery, and Resilience 4.3 Finance and Accounting Concepts for the Activity Under Review
5 Chapter 5: Business Process and System Risks in Planning
5.1 Asset, Supply Chain, Inventory, Payables, Procurement, and Compliance Processes 5.2 Third-Party Process Risks 5.3 CRM, ERP, and GRC System Risks
6 Chapter 6: Engagement Approach and Project Management
6.1 Agile, Traditional, Integrated, and Remote Approaches 6.2 Project Management While Planning and Conducting Engagements
7 Chapter 7: Engagement Risk Assessment
7.1 Topical Requirements and Pervasive Financial, Operational, IT, Cyber, and Regulatory Risks 7.2 Emerging Risks and the Impact of Change 7.3 Methods to Evaluate and Prioritize Risks and Controls
8 Chapter 8: Structure, Environment, and Culture
8.1 Centralized vs Decentralized, Flat vs Traditional, In-Person vs Remote 8.2 Culture, Group Behavior, and Tone at the Top
9 Chapter 9: Control Design, Effectiveness, and Efficiency Procedures
9.1 Procedures to Evaluate Control Design 9.2 Procedures to Test Operating Effectiveness 9.3 Procedures to Test Control Efficiency
10 Chapter 10: Work Programs, Testing Methodologies, and Resources
10.1 Evaluating Adequacy of the Engagement Work Program 10.2 Testing Methodologies for Accounting, Finance, IT, Operations, and Cybersecurity 10.3 Financial, Human, and Technological Resources and Limitation Implications
11 Chapter 11: Information Sources and Preliminary Survey
11.1 Interviews, Observations, and Walk-Throughs 11.2 Data Analysis as an Information Source 11.3 Policies, Checklists, Risk-and-Control Questionnaires, and Self-Assessments
12 Chapter 12: Evidence Relevance, Sufficiency, and Reliability
12.1 Criteria for Evidence Quality 12.2 Independence, Corroboration, and the Control Environment 12.3 Evidence an Informed, Competent Person Could Rely On
13 Chapter 13: Technology Options for Findings and Conclusions
13.1 Artificial Intelligence, Machine Learning, and Robotic Process Automation 13.2 Continuous Monitoring, Dashboards, and Embedded Audit Modules
14 Chapter 14: Process Mapping and Data Analytics
14.1 Workflow Segments, Process Maps, Walk-Throughs, and RACI 14.2 Structured vs Unstructured Data and the Analytics Process 14.3 Diagnostic, Prescriptive, Predictive, Anomaly, and Text Analysis
15 Chapter 15: Analytical Review and Finding Evaluation
15.1 Ratios, Variances, Trends, and Benchmarking 15.2 Selecting Analytical Techniques for Engagement Objectives 15.3 Comparing Existing Conditions to Evaluation Criteria 15.4 Root Causes, Effects, and Significance of Findings
16 Chapter 16: Workpapers and Engagement Conclusions
16.1 Organizing Complete Workpapers with Sufficient Evidence 16.2 Linking Workpapers to Results; Retention, Regulation, and Policy 16.3 Aggregating Findings and Concluding on Governance, Risk, and Control
17 Chapter 17: Engagement Supervision
17.1 Supervision Throughout Planning and Fieldwork 17.2 Coordinating Assignments and Reviewing Workpapers and Conclusions 17.3 Evaluating Auditors' Performance
18 Chapter 18: Communication During the Engagement
18.1 Formal and Informal Communication Across Planning, Fieldwork, and Reporting 18.2 Situations That Require Escalation 18.3 Selecting Appropriate Stakeholders for Engagement Communication
19 Chapter 19: Final Review and Test Day
19.1 2025 vs 2019 Traps and Part 2 vs Part 3 Boundaries 19.2 Pacing, Test-Center Rules, and Official Results
9.1 Procedures to Evaluate Control Design
Key Takeaways Explain This Topic AI
Design adequacy asks whether the control, if operated as designed, would prevent or detect the engagement risk on a timely basis — COSO 'present,' not yet 'functioning'
CIA Part 2 A6a tests choosing design procedures for the work program: walk-throughs, narrative versus flowchart, inspecting configuration, tracing one transaction, and RACI (or equivalent) for segregation of duties
A design failure is not an operating failure: two signatures can appear on a form while the same user ID can apply both, or a match flag can be switched off by the process owner
If design is broken, stop or redirect operating tests of that control, document the gap, and consider compensating controls — do not sample a control that cannot work
Implementation (placed in operation) is tested with design; a drawer flowchart that the live ERP does not enforce is not an implemented control
Last updated: August 2026
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
Design failure Operating failure
Question Even if followed perfectly, would this control address the risk in time? Did people and systems actually follow a sound design throughout the period, by the right people, with evidence?
Typical procedures Walk-through, configuration inspect, one traced item, RACI / SOD map, narrative versus flowchart Inquiry plus observation, inspection, reperformance, period coverage, IPE tests (Section 9.2)
Example Dual approval required, but both “approvers” can be the same user ID; match required, but tolerance is 100% Dual approval is enforced in the system; 6 of 25 sampled invoices lack the second approval
What you do next Stop or redesign tests of that control; look for compensating controls Exception in operating effectiveness; expand, investigate, or conclude on the deviation
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
Form Strength for design work Weakness if used alone
Narrative Fast for a simple linear process; captures “why” and informal workarounds Easy to hide missing decision points and SOD breaks inside paragraphs
Flowchart Shows handoffs, loops, system boundaries, and decision diamonds Can look complete while omitting the override path you did not ask about
Both Narrative explains intent; flowchart exposes structure Still only alleged design until a walk-through tests the live path
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.