4.2 Core Workflows and Decision Points

SDLC Models

The exam expects you to match a development model to its risk profile.

Waterfall is predictable and well-documented but detects defects late, because testing happens only after all build phases complete; a requirement error caught at the end is expensive to undo. Agile delivers working software incrementally in short sprints and welcomes change, but the auditor must confirm that lighter documentation still leaves an evidence trail — approved user stories, definition-of-done sign-offs, and sprint retrospectives — so that control evidence is not lost in the speed.

DevOps merges development and operations with continuous integration/continuous delivery (CI/CD) pipelines; releases are frequent and largely automated, so the auditor's chief worry is segregation of duties: when the same automated pipeline both builds and deploys to production, automated gates, approvals, and immutable logs must replace the manual separation that existed in slower models. The reusable takeaway is that the control objective (authorized, tested, segregated change) is constant across all models — only the mechanism changes.

Project Management Techniques

CISA tests which technique fits which objective:

• PERT / CPM — estimate project duration and identify the critical path (the longest sequence of dependent tasks). PERT uses three estimates (optimistic, most likely, pessimistic); the critical path has zero slack, so any delay there delays the project. Prefer PERT when uncertainty is high.
• Gantt chart — monitor progress and milestones against the schedule.
• Function Point Analysis (FPA) — estimate software size from functionality (inputs, outputs, inquiries, files, interfaces), independent of programming language. Prefer FPA over source-lines-of-code (SLOC).
• Earned Value Management (EVM) — measure cost and schedule performance by comparing budgeted, earned, and actual values (CPI, SPI).
• Timebox management — fix the schedule/budget and flex scope to prevent overruns.

A classic exam pairing: "to determine which tasks would delay the project if late" → the critical path. Two refinements help: in PERT, the expected duration of an activity is a weighted average of the optimistic, most-likely, and pessimistic estimates, which makes it the preferred tool when uncertainty is high; EVM lets a manager forecast the estimate at completion by extrapolating current cost and schedule performance rather than waiting for the project to finish to discover an overrun.

The auditor confirms these techniques are actually used to drive decisions, not merely produced as paperwork — a Gantt chart no one updates provides no control value.

Acquisition, RFP, and Vendor Risk

When buying rather than building, the organization issues a Request for Proposal (RFP) describing requirements so vendors can bid comparably. The auditor verifies that selection used predefined, weighted evaluation criteria applied consistently — not subjective preference. Due diligence includes financial viability, references, security posture, and a proof of concept for fit.

Third-party risk management (TPRM) continues after signing: the contract should include a right-to-audit clause, SLAs with penalties, data-protection and exit/transition terms, and review of the vendor's SOC 2 report. Escrow of source code protects the buyer if the vendor fails.

Application Controls

Application controls ensure data is complete, accurate, valid, and authorized across three stages:

• Input controls — keep bad data out (edit/validation checks, authorization, batch totals).
• Processing controls — ensure correct computation and completeness (run-to-run totals, reconciliation).
• Output controls — ensure results are accurate, distributed only to authorized recipients, and reconciled.

Because input controls are preventive, they are the most cost-effective place to stop errors before they propagate. Processing controls are largely detective and corrective — they catch what input controls missed by reconciling totals as data moves through programs. Output controls protect the confidentiality and integrity of results, ensuring reports reach only authorized recipients and that printed or transmitted output is reconciled to expected values.

Together these three layers give the auditor a structured way to assess any application: trace a transaction from entry, through computation, to its final report, and confirm a control exists at each handoff. When a scenario describes errors entering the system, suspect an input-control gap first.

Requirements, Design, and the Cost of Getting Them Wrong

Between justification and build sit two control-rich phases. Requirements definition captures what the system must do; the auditor checks that requirements are complete, unambiguous, testable, and approved by the business, because untestable requirements cannot be verified at UAT and ambiguous ones invite scope disputes. Poorly managed requirements are a leading source of project failure, and scope creep — uncontrolled growth in requirements after baselining — is a frequent exam theme; the control is a formal change-control process for requirements, not ad-hoc additions.

Design translates approved requirements into architecture, data models, interfaces, and the application controls themselves. The auditor's value here is timing: a missing control identified in design costs a design revision, but the same gap found after go-live may require re-engineering live data and processes. This is why CISA repeatedly favors answers that involve the auditor and control owners acting early — the economics of defect correction worsen sharply with each phase a problem survives, a relationship the exam expects you to apply to almost any "when should X happen" question.