3.5 Business Process Models, Flowcharts, DFDs & BPMN
Key Takeaways
- The ISC blueprint names three business process model forms explicitly - flowchart, data flow diagram (DFD), and business process model and notation (BPMN) diagram - and asks candidates to investigate them to identify potential improvements.
- A flowchart shows the sequence of activities and who performs them; a data flow diagram shows what data moves between processes, data stores and external entities and deliberately omits timing and decision logic.
- BPMN organizes a process into pools (one per participating organization) and lanes (roles within an organization), using a solid sequence flow inside a pool and a dashed message flow between pools.
- A process walkthrough reconciles the actual observed sequence of steps, documents, tools and technology in a cycle to the documented process, and any difference between the two is itself an audit finding regardless of which version is better.
- The recurring improvement opportunities visible in a process model are swivel-chair re-keying between systems, redundant approvals that add latency without adding assurance, rework loops that never reach a control point, and single points of failure where one role both initiates and approves.
Business Process Models, Flowcharts, DFDs & BPMN
Quick Answer: Two ISC blueprint tasks turn on your ability to read a process model. The first asks you to reconcile the actual sequence of steps, information, documents, tools and technology used in a key accounting cycle to the documented process — a flowchart, business process diagram, or narrative. The second asks you to investigate a business process model (flowchart, data flow diagram, or BPMN diagram) to identify potential improvements. Both are Analysis-level tasks, which makes them prime simulation material.
1. The Three Documentation Forms
Narrative
A written description of a cycle in sequence. Cheap to produce, easy for a business owner to validate, and the worst format for spotting a missing control — ambiguity hides in prose ("the supervisor reviews the report" tells you nothing about what the review covers or what happens on an exception).
Flowchart
A diagram of the sequence of activities and who performs them. Conventional symbols a candidate should recognize on an exhibit:
| Symbol | Meaning | Accounting Cycle Example |
|---|---|---|
| Rectangle | Processing step or activity | "Match invoice to purchase order" |
| Diamond | Decision point with labeled branches | "Variance within tolerance?" |
| Parallelogram | Input or output of data | "Enter receiving quantity" |
| Document shape (rectangle with wavy base) | A document produced or used | Purchase order, receiving report, check |
| Cylinder | Data store / master file | Vendor master, open PO file |
| Oval (terminator) | Start or end of the process | "Requisition submitted" |
| Small circle (connector) | Continuation to another point or page | Links a payables flowchart to the disbursement flowchart |
Two variants matter:
- A document flowchart traces the physical and electronic flow of documents between departments, which makes segregation of duties visible at a glance.
- A system flowchart traces data through programs, files and interfaces, which makes automated control points and interface risks visible.
A flowchart drawn with swim lanes — one column or row per department, role or system — is the most audit-useful form, because an incompatible duty appears as two conflicting activities sitting in the same lane.
Data Flow Diagram (DFD)
A DFD answers a different question: what data moves, from where, to where, and where does it rest? It has exactly four notation elements:
- External entity (square) — a source or destination outside the system boundary: customer, vendor, bank, regulator.
- Process (circle or rounded rectangle) — a transformation of data: "validate order," "calculate depreciation."
- Data store (open-ended rectangle or two parallel lines) — where data rests: customer master, general ledger.
- Data flow (arrow, labeled with the data it carries) — "approved invoice," "credit limit."
DFDs are leveled. A context diagram (Level 0) shows the entire system as one process with its external entities, establishing the system boundary. Level 1 decomposes that single process into its major sub-processes, Level 2 decomposes further, and so on.
Exam distinction: A DFD deliberately shows no timing, no sequence, and no decision logic — those are a flowchart's job. If an exhibit shows arrows labeled with data names between circles and open rectangles, you are reading a DFD and should not expect to find the order in which steps occur.
Business Process Model and Notation (BPMN)
BPMN is the international standard notation for modeling processes that span organizations. Its structural idea is the pool:
- Pool — one participating organization or system (e.g., "Customer," "Our Company," "3PL Warehouse"). One pool per participant.
- Lane — a role or department inside a pool ("Credit," "Billing," "Shipping").
- Activity (rounded rectangle) — work performed. A small marker indicates a sub-process, a user task, or an automated service task.
- Event (circle) — something that happens. A thin circle is a start event, a double-ring circle is intermediate, a thick circle is an end event. Markers show the trigger: message, timer, error, escalation.
- Gateway (diamond) — flow control. An exclusive gateway (X) takes exactly one path; a parallel gateway (+) takes all paths simultaneously; an inclusive gateway (O) takes one or more.
- Sequence flow (solid arrow) — the order of work within a pool.
- Message flow (dashed arrow) — communication between pools.
Exam distinction: A solid arrow never crosses a pool boundary and a dashed arrow never connects two activities inside the same pool. If a diagram shows a dashed line from "Our Company" to "Bank," that is a message — an interface — and interfaces are where completeness and accuracy controls belong.
| Model | Core Question Answered | Shows Sequence? | Shows Data Stores? | Shows Organizational Boundaries? |
|---|---|---|---|---|
| Narrative | What happens, described in prose | Implicitly | Implicitly | Weakly |
| Flowchart | In what order, and who does it | Yes | Yes | Yes, with swim lanes |
| Data flow diagram | What data moves and where it rests | No | Yes | System boundary only |
| BPMN | How work and messages flow across participants | Yes | Via data objects | Yes, explicitly via pools |
2. Reconciling the Actual Process to the Documented Process
The blueprint task is a walkthrough: take one transaction through a cycle from origination to its appearance in the financial statements, observing the real steps, and compare what you observe to the flowchart, business process diagram or narrative on file.
The procedure:
- Select a live transaction — not a demonstration, and preferably one that was processed while you were not watching, so the Hawthorne effect does not shape what you see.
- Walk it forward. At each step ask four questions: What step occurred? Who performed it (name and role, not job title)? What document, screen or report evidenced it? What system or tool executed it?
- Inspect the evidence at each step, rather than accepting a description of it. Inquiry alone establishes nothing.
- Record the observed sequence against the documented sequence in a two-column comparison.
- Classify every difference.
The four classes of difference, and what each means:
| Difference Observed | Interpretation | Audit Consequence |
|---|---|---|
| A documented step does not occur | The control does not operate as designed | Deficiency in operating effectiveness; evaluate severity and compensating controls |
| A step occurs that is not documented | Shadow process — often a workaround built around a system limitation | The step is unauthorized and untested; the documentation is also inaccurate |
| A step occurs but a different role performs it | Possible segregation of duties breach | Test the actual performer's other entitlements for toxic combinations |
| The step occurs correctly but the documentation describes it wrongly | Documentation deficiency | Management cannot assert an accurate description of its own process; in a SOC engagement this hits the fair presentation of the system description directly |
The key exam point: a mismatch between the observed process and the documented process is a finding in both directions. Candidates often assume the documentation is authoritative and the practice is wrong. Sometimes practice has improved and the documentation is stale — which is still a finding, because management asserted a description that does not describe reality.
The same reconciliation applies to the change management walkthrough elsewhere in the blueprint: observe how a change actually moved to production, then compare it to the documented policy requirement.
3. Investigating a Process Model to Identify Improvements
When a simulation hands you a process model and asks what could be improved, work a fixed checklist rather than reading the diagram top to bottom.
Efficiency patterns:
- Swivel-chair re-keying. The same data is manually typed from one system into another. Every re-key is an accuracy risk and an integration opportunity.
- Redundant approvals. Three signatures where the second and third review nothing the first did not. Latency rises, accountability diffuses, and the last approver rationally assumes the first two did the work.
- Rework loops. An arrow that returns upstream without passing a control point means errors circulate without being counted; nobody can measure the defect rate.
- Serial steps that could be parallel. A BPMN parallel gateway replacing a chain of independent checks compresses cycle time without removing any control.
- Batch waits. A step that runs only weekly holds every transaction until the batch, even when the work itself takes minutes.
Control patterns:
- An unbroken lane. One swim lane that both initiates and approves a transaction is a segregation of duties failure visible on the diagram itself.
- A data store written by a process with no validation upstream. Input controls are missing at the boundary.
- A message flow with no reconciliation. Every dashed BPMN arrow or interface line should have a corresponding completeness check — record counts, control totals, or an acknowledgment.
- A decision diamond with no defined exception path. What happens on "No"? If the model does not say, nobody owns the exception.
- A manual step where the system could enforce the rule. The strongest improvement recommendation converts a detective manual review into a preventive automated edit check.
Worked Example
A Level 1 DFD for cash collections shows: Customer → "Receive remittance" → Cash Receipts Log (data store) → "Apply cash" → AR Master, with a separate arrow from "Receive remittance" directly to "Prepare bank deposit."
Three observations follow immediately:
- The deposit is prepared from the same step that receives the remittance, with no independent listing in between — the classic lapping exposure.
- Nothing in the model reconciles the Cash Receipts Log total to the bank deposit total; the two flows diverge and never rejoin.
- There is no flow from the bank back into the diagram, so the bank statement is outside the system boundary and no automated bank reconciliation exists.
The recommendations write themselves: an independent remittance listing prepared by someone who does not apply cash, a daily reconciliation of the log to the validated deposit slip, and an automated bank reconciliation bringing the bank file inside the boundary.
An IT auditor is handed a diagram containing squares labeled 'Customer' and 'Bank', circles labeled 'Validate order' and 'Apply cash', open-ended rectangles labeled 'Customer master' and 'AR subledger', and labeled arrows connecting them. Which documentation form is this, and what does it deliberately omit?
During a walkthrough of the purchasing cycle, an auditor observes that the buyer obtains verbal quotes and enters the winning price directly into the purchase order, while the documented narrative states that three written quotes are attached to the requisition before a purchase order is created. The buyer explains that the narrative was written four years ago and that the verbal process is faster and has never produced a problem. How should the auditor treat this?
In a BPMN diagram of an order-to-cash process, which element correctly represents the transmission of a shipment confirmation from the company's pool to a third-party logistics provider's pool?