Study guide
14.1 Workflow Segments, Process Maps, Walk-Throughs, and RACI
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
14.1 Workflow Segments, Process Maps, Walk-Throughs, and RACI
Key Takeaways Explain This Topic AI
CIA Part 2 2025 B4a–b (Section B, 40% of the exam): define process workflow segments, then analyze workflows through process mapping, walk-throughs, and responsibility assignment matrices (RACI).
SIPOC and other high-level maps lock scope (suppliers, inputs, process, outputs, customers); detailed swimlane flows show tasks, decisions, controls, and exception paths.
A spaghetti map (conceptual) traces physical or click-path movement and rework; it does not, by itself, prove segregation of duties.
Walk through a live item — and usually an exception — to validate the map before you sample, score, or write findings from the drawing.
RACI: Responsible does the work; Accountable owns the outcome (exactly one per task); Consulted before; Informed after. Two Accountables is a finding seed, not teamwork.
Last updated: August 2026
B4a and B4b: map the work, then prove the map
Quick Answer: CIA Part 2 2025 Section B — Information Gathering, Analysis, and Evaluation is 40% of the exam. B4 asks you to apply appropriate analytical approaches and process mapping techniques . B4a is define process workflow segments . B4b is analyze process workflows through process mapping , walk-throughs , and responsibility assignment matrices . Draw the live path at the right altitude, walk one item to prove the drawing, and assign one Accountable per task. Two Accountables is a finding seed, not a consensus culture.
Chapter 11 used walk-throughs to obtain information . Chapter 9 used them to evaluate control design . This section uses maps and walk-throughs to analyze the workflow — that is B4's job. The official 2025 English syllabus (IIA expanded test specifications, V2.09.2024 FINAL, testable in English since 28 May 2025) is the source: define segments, then analyze with maps, walk-throughs, and responsibility matrices. Older 2019 Part 2 language already named process identification, workflow analysis, spaghetti maps, and RACI diagrams; those tools still answer B4 items. Stay off Chapter 13's technology catalog (AI, machine learning, RPA, dashboards, embedded modules) and off Chapter 15's ratios, variances, trends, and benchmarks. B4a–b is how the work actually moves .
Global Internal Audit Standards Principle 14, Conduct Engagement Work , still sits underneath. You cannot analyze a process you have not segmented, and you cannot trust a map nobody walked. GIAS Standard 14.1 is gathering information that can be analyzed; this chapter is the analytic approach you apply to the process itself.
Process workflow segments
A process is a repeatable set of activities that turns inputs into outputs for a customer (internal or external). A procedure is the instructed way to perform a step. A control is an activity designed to prevent or detect a risk. CIA stems mix these words. If the item asks for workflow segments , it wants the pieces of the path, not the policy title and not the engagement-team milestone list from Chapter 6.
Name segments before you draw boxes. If you cannot name the trigger, the customer of the process, and at least one exception path, you do not yet have segments. You have a slogan (we pay vendors).
Segment What it is Why the auditor names it
Trigger / start Event that opens the process (requisition submitted, claim filed, joiner ticket) Wrong trigger means you mapped the neighbor process
- Task / activity Work a person or a system performs Where time, error, and evidence live
- Decision Split in the path (amount over $5,000; three-way match fail) Exception paths are where controls die
- Handoff Work leaves one role, system, or location for another SOD, delay, and lost documents cluster here
Queue / wait Item sits (parking lot, unmatched GR/IR, approval inbox) Hidden inventory of risk; aging becomes a later test
Control point Designed check (match, dual approval, system block) Must appear as a segment, not a footnote
Output / end What the process customer receives (paid vendor, provisioned user, closed claim) Scope ends here unless reporting is in scope
Worked split: match-to-pay is not one box. Invoice arrival is the trigger. Park-in-workflow is a queue. Three-way match is a control point. Match-fail is a decision. Buyer-to-AP is a handoff. Override is another control (or a bypass). Treasurer release is a task. The payment file is an output. If your map hides override inside match, you will sample the happy path and miss the risk.
SIPOC and high-level maps versus detailed flows
SIPOC (Suppliers, Inputs, Process, Outputs, Customers) is a high-level map: one page, five columns, the process itself usually five to eight steps. Use it to lock scope . A SIPOC that lists suppliers as the vendor master and receiving, inputs as purchase order / goods receipt / invoice, process as three-way match through payment, outputs as a payment file and a GL posting, and customers as the vendor and the controller, is enough to stop you from auditing treasury wires by accident. It is not enough to conclude SOD, to pick a sample, or to rate operating effectiveness.
A detailed flowchart — often swimlanes by role or by system — is the task-level map. Each box is a segment: who, what system, what decision, what evidence. Use it when you need control points, exception paths, and incompatible duties. You do not spend week one drawing ninety boxes before anyone agrees which subprocess is in scope. Altitude is a professional choice, not a personality trait.
Map Altitude Question it answers well Poor use
SIPOC / high-level block diagram Process in 5–8 steps What is in scope? Who supplies input? Who is the customer? Which subprocesses exist? Sampling, SOD conclusions, exception-path testing
Detailed / swimlane flowchart Task, system, decision, control Where is the control? Who hands off? What happens on match-fail? First-day scoping when AP still means three different things
Spaghetti map Physical path or click-path How much rewind, travel, and extra routing exists? A substitute for naming control owners
Spaghetti maps are conceptual on this exam. In Lean they trace a person, product, or document across a floor. In internal audit they also trace a click-path : a joiner ticket that bounces Help Desk to HR to IT and back, or an invoice PDF that prints in AP, walks to a director, returns for a stamp, then is scanned into a different folder. The map's job is to make waste and unclear routing visible. You are not graded on warehouse CAD. You are graded on choosing spaghetti when the risk is movement and rework, and choosing a detailed flow when the risk is a missing approval rule. A spaghetti drawing that never names who can change vendor bank details has not analyzed SOD.
High-level and detailed maps are a sequence , not rivals. SIPOC first (what is in). Detailed flow second (how it actually runs, including the exception). Spaghetti only if layout or bouncing systems are the story. Then walk.
Loading diagram... B4a–b sequence: segment, map at the right altitude, walk, then RACI
Walk-throughs validate the map
A process map is a hypothesis . The walk-through in B4b is how you confirm or falsify that hypothesis with one live item — and usually a second item on the exception path (hold, override, return, match failure). Follow the item through every segment you drew. Combine inquiry, observation, and inspection of the documents that item produced, the same physical technique as Chapter 11, with a different product: here the workpaper is an annotated map (what matched, which box to add, which control never fired).
If the map says Buyer creates the PO, Receiving posts the receipt, AP matches, Treasurer releases, and the live item is a weekend upload that never hits the Friday proposal review, the map is wrong . Fix the drawing before you sample, score vendors, or copy last year's RACI onto this year's file. Last year's narrative is another hypothesis, not evidence that the ERP cutover left the path unchanged.
The unit is still one path , not operating effectiveness for the period. Watching Tuesday's invoice match does not prove March. B4b is asking whether you analyzed the workflow , not whether you closed the effectiveness objective.
Pick the item so it should hit the control you care about. A $200 fully matched invoice will never show you that invoices over $5,000 bypass match. Walk the override if override is how risk gets through. Ask the performer to use the live system, not a training screen. Inspect the user ID that approved, not only the printed name.
RACI: responsibility assignment for SOD and accountability
The syllabus says responsibility assignment matrices . On CIA Part 2 that matrix is RACI , built for the activity under review , from live roles and system IDs , not from the kickoff org chart.
- Letter Meaning Count rule
- R — Responsible Does the work May be several people or a system job
- A — Accountable Owns the outcome; answerable if it fails Exactly one per task
- C — Consulted Two-way input before the task Keep short or the process is a standing meeting
- I — Informed One-way notice after Not a second approver
Chapter 6 used RACI for the audit team's tasks (who writes the program, who reviews). If the stem shows vendor-master swimlanes, do not answer with the in-charge's engagement matrix.
Read the process RACI for two families of issues.
Segregation of duties (SOD). The same person or user ID is Responsible or Accountable for incompatible tasks: vendor-master change and payment release; PO create and goods receipt; access grant and access recertification. That design problem also appears in Chapter 9. B4's contribution is seeing it on the workflow , including system jobs that have no human name on the org chart.
Accountability gaps. No Accountable on release payment means the process is orphaned — when it fails, nobody is answerable. Two Accountables on the same task is the exam's favorite seed. If AP operations and the shared-services director are both A for payment release, a duplicate payment produces two speeches and no owner. Record two A's as a potential finding : accountability is not uniquely assigned. Do not score it as healthy collaboration. Consulted is before; Informed is after. Marking six directors C on every invoice is delay dressed as governance. Marking the control owner only I when they must approve is a bypass.
Worked example: procure-to-pay
SIPOC: suppliers = vendor, buyer, receiving; inputs = PO, receipt, invoice; process = match, approve, pay; outputs = payment and GL; customers = vendor and controller. Scope is match-to-pay, not contract sourcing.
Segments: invoice arrival; park in workflow; three-way match; match-fail decision; buyer/AP handoff; override; treasurer release; payment file.
Detailed swimlanes by Buyer, AP clerk, AP supervisor, Treasurer, ERP.
Walk-through of one unmatched invoice that paid: override is the same user ID as match; a weekend-upload segment appears that the SIPOC never showed. The map is updated before any sample of 40.
RACI: payment release has two A's (AP manager and SSC director). Vendor create and payment release share one R. Those two cells are the finding seeds. The pretty SIPOC is not the finding.
Exam traps
Testing operating effectiveness from a SIPOC, or scoping from an unvalidated 90-box map.
Treating a spaghetti diagram as a SOD analysis.
Scoring two Accountables as teamwork.
Answering a process RACI item with the engagement-team RACI.
Calling the validating walk-through a year of operating effectiveness.
Importing Chapter 13 tools or Chapter 15 ratios into a mapping item.
B4a–b is done when a reviewer can see the segments, the altitude of each map, the live item that proved (or rewrote) the drawing, and a RACI that names a single Accountable — or documents that it does not.