Transaction cycles, process flow, processing integrity, and vendor risk.
This chapter follows how business processes are executed within information systems. The exam focus is on understanding transaction flow well enough to identify control points, processing risks, and breakdowns that affect reliability.
Business-process questions should be traced from initiation to recording and monitoring. The strongest answer identifies where an error, omission, duplicate, unauthorized change, or vendor failure could enter the process and which control should prevent or detect it.
| Process area | What to trace | Common ISC trap |
|---|---|---|
| Transaction cycles and modules | How events enter the system and move to reporting. | Evaluating a control without knowing where the transaction came from. |
| Flowcharts and process diagrams | Where approvals, system edits, handoffs, and exception points occur. | Reading diagrams as documentation rather than risk evidence. |
| Processing integrity controls | Whether inputs, processing, outputs, and corrections stay complete and accurate. | Focusing only on access controls while missing data integrity failures. |
| Control deficiencies | What could fail and which mitigation addresses the failure. | Recommending a control that does not match the deficiency. |
| Vendor dependencies | Which outsourced process affects reliability, security, or evidence. | Treating third-party systems as outside the organization’s control responsibility. |
| Step | What to do | Why it matters on ISC |
|---|---|---|
| 1. Trace transaction initiation | Identify who starts the event, what data enters the system, and which module captures it. | Control analysis fails if the process entry point is misunderstood. |
| 2. Locate approvals and edits | Find authorization, validation, edit checks, exception queues, and supervisory review points. | Processing integrity depends on controls at the right handoffs. |
| 3. Follow processing to reporting | Track updates, interfaces, reconciliations, outputs, and report generation. | Errors can enter during processing or reporting even when input controls work. |
| 4. Match deficiencies to controls | Identify the specific failure and choose a preventive, detective, or compensating response. | Generic controls do not solve specific process weaknesses. |
| 5. Evaluate vendor impact | Determine which outsourced activities affect reliability, security, evidence, or accountability. | Vendor use changes oversight needs but does not remove responsibility. |
| Checkpoint | Exam use | What to avoid |
|---|---|---|
| Entry point | Identify who initiates the transaction, what source data enters, and which module captures it. | Testing a downstream control without understanding transaction origin. |
| Handoff and approval | Locate approvals, edit checks, exception queues, interfaces, and supervisory reviews. | Assuming a process is controlled because a flowchart contains many steps. |
| Processing integrity | Check completeness, accuracy, authorization, duplicate prevention, and correction controls. | Focusing only on access while missing data-quality failures. |
| Deficiency match | Tie the control recommendation to the precise failure mode. | Recommending a generic review control that does not address the error. |
| Vendor dependency | Determine which outsourced step affects reliability, evidence, security, or accountability. | Treating vendor processing as outside the organization’s responsibility. |