Certified: The ISACA CISA Prepcast

Welcome to The Bare Metal Cyber CISA Prepcast. This series helps you prepare for the exam with focused explanations and practical context.
The Waterfall model is one of the most established approaches to software development, characterized by its linear, phase-based sequence. In this model, each step—requirements, design, development, testing, and implementation—must be completed before the next one begins, with minimal overlap or iteration. Waterfall places a strong emphasis on upfront planning, detailed documentation, and predictable workflows, which makes it particularly suitable for projects with stable, clearly defined requirements. Because of its structure, it is often used in government, finance, and infrastructure settings, where regulation and documentation are especially important. On the CISA exam, candidates must understand how control responsibilities align with each phase of the Waterfall lifecycle and how auditors assess whether controls were implemented early enough to prevent downstream issues.
The Waterfall system development life cycle is divided into distinct, sequential phases that guide a project from conception to deployment. It begins with requirements gathering, during which business needs are collected, reviewed, and fully documented before any technical work begins. Once requirements are finalized, the design phase creates system architecture, interface flows, and data models that specify how the solution will meet those needs. Development follows, where programmers build the system according to detailed specifications, with minimal scope for mid-course adjustments. Testing then verifies the completed system against the original requirements to confirm that functionality is correct and controls are working. Finally, implementation and maintenance phases involve deploying the system into production, training users, and supporting it over time. CISA candidates should be familiar with this flow and understand how the structure supports audit traceability and control review at each stage.
Each phase of the Waterfall model has its own set of control objectives that must be planned, documented, and validated. During the requirements phase, auditors look for stakeholder approval, version control, and traceability between documented needs and future deliverables. In the design phase, security, privacy, and control considerations—such as segregation of duties and secure system architecture—should be evaluated and documented before any development begins. The development phase requires version control, code review processes, and access restrictions to prevent unauthorized changes. During testing, auditors assess whether independence from the development team was maintained, whether test cases were complete, and whether results were logged and reviewed. In the implementation phase, control focus shifts to go-live readiness, including backup, recovery, and user training plans. On the CISA exam, you may be asked to match specific control objectives to the appropriate SDLC phase or evaluate whether missing controls resulted in unmitigated risk.
Documentation is one of the strongest features of the Waterfall approach, and it serves as the audit trail that allows control validation, stakeholder review, and compliance testing. Because each phase generates formal outputs—such as requirements specifications, design documents, test plans, and sign-off records—auditors can trace how business needs were translated into technical solutions and whether controls were implemented as designed. Documentation also enables change control, defect tracking, and issue resolution to be monitored and verified after the fact. It supports regulatory requirements for transparency and accountability, particularly in industries where audit evidence must be retained for years. When documentation is weak, incomplete, or missing, it signals a breakdown in project discipline and often correlates with failed controls. On the CISA exam, expect to assess whether documents exist, are aligned with each phase, and provide enough detail to support objective audit conclusions.
In the Waterfall model, change management must be formal and well-controlled to prevent disruptions to schedule, budget, or scope. Changes to requirements, system design, or development plans must be submitted through a formal process—often reviewed by a Change Control Board that assesses impact, risk, and feasibility before granting approval. Every change must be logged, justified, reviewed, and tested before being implemented, and documentation must show that approvals were secured and stakeholders were informed. This structure helps avoid scope creep, ensures that risks are evaluated, and maintains alignment between planning and execution. Auditors review change logs, approval records, and testing results to verify that changes were made in a controlled and transparent manner. The CISA exam may present scenarios where unapproved changes caused project failures, and candidates will need to recognize the breakdown in change governance and propose appropriate control responses.
Testing is a central phase in the Waterfall lifecycle, and it must be comprehensive, structured, and documented to validate that the system meets all stated requirements. Unit testing is conducted by developers to verify individual components or functions in isolation. Integration testing ensures that those components work together as intended. System testing covers the entire application and evaluates end-to-end performance and reliability. User Acceptance Testing, or UAT, is performed by stakeholders to ensure the system meets business expectations and functional requirements. Testing must be traceable to the original requirements, with documented test cases, expected outcomes, and actual results. Defects should be logged, tracked, and resolved before go-live. CISA candidates are frequently asked to assess the completeness and rigor of test processes, especially in scenarios where production errors or compliance gaps emerge after deployment.
Despite criticism for its rigidity, the Waterfall model offers several advantages, especially in environments where predictability, traceability, and control are paramount. The linear structure allows for clear timelines, budgets, and resource planning, making it easier for governance bodies to assess progress and allocate funding. Defined roles, phase boundaries, and documentation trails simplify stakeholder communication and audit review. For organizations subject to regulatory oversight, the Waterfall model provides the formality and evidence trail needed to demonstrate compliance. It also helps manage risk in large, high-impact projects by requiring early-stage planning and mid-stage validation before major resource commitments are made. On the CISA exam, you may be asked to identify why Waterfall is used in particular sectors, or to evaluate whether the model’s structure supports auditability and control assurance.
That said, the Waterfall model is not without its limitations, and auditors must be aware of the risks associated with using this methodology in dynamic or uncertain environments. Because each phase is completed before the next begins, late changes to requirements or business needs are difficult and costly to implement. The long delay between requirements gathering and user feedback can result in systems that are technically sound but fail to meet actual business expectations. If issues are not identified until the testing phase, it may be too late or too expensive to make meaningful corrections. Waterfall also assumes that requirements are fully understood at the beginning, which is rarely the case in fast-moving or complex organizations. CISA candidates should be able to identify when Waterfall is being misapplied, when flexibility is needed, or when project failures result from delayed testing, rigid structure, or insufficient user involvement.
Auditing a Waterfall-based project requires a lifecycle-aware approach that maps controls, evidence, and stakeholder decisions to the appropriate SDLC phase. Auditors begin by reviewing planning documents, feasibility studies, and signed-off requirements to confirm that the project was well-justified and aligned with organizational goals. They evaluate whether traceability exists from requirements to test cases, ensuring that controls were not introduced too late or bypassed due to oversight. Testing documentation must show that results were reviewed, that independence was maintained, and that defects were resolved prior to deployment. Change logs are examined to verify that scope adjustments were authorized and managed, while status reports and phase approvals show whether the governance model functioned as expected. CISA scenarios often require identifying missing documentation, unapproved changes, or weak testing discipline within the context of a Waterfall audit.
To succeed on the CISA exam and in audit practice, candidates must understand how traditional SDLC models function and how control requirements differ from those in iterative methodologies like Agile or DevOps. You’ll be expected to match control activities to the correct phase, identify weaknesses in documentation or change control, and assess whether governance checkpoints were completed. You may also be asked to contrast Waterfall with more flexible models, especially when determining whether a methodology is appropriate for a particular project type or environment. Waterfall remains widely used in sectors such as banking, defense, and government, where formal approvals, traceability, and structured processes are mandatory. As an auditor, you must be able to adapt your evaluation techniques to the methodology in use and ensure that control design, implementation, and assurance activities are aligned with the selected development approach.
Thanks for joining us for this episode of The Bare Metal Cyber CISA Prepcast. For more episodes, tools, and study support, visit us at Baremetalcyber.com.