14.1 Workflow Segments, Process Maps, Walk-Throughs, and RACI
Key Takeaways
- 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.
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.
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.
When should an internal auditor use a SIPOC rather than a detailed swimlane flowchart?
A RACI for payment release shows both the AP manager and the shared-services director as Accountable. What is the best interpretation for B4b?
An auditor draws a detailed AP flowchart from last year's narrative and samples 40 invoices without following a live item through the current system. Which B4b step was skipped?