Latest / VoraPrep Audio — Professional Licensure & Certification Exam Prep / [CISA] CISA3: Auditing SDLC Methodologies: From Waterfall to DevOps
Transcript
- Marcus: Welcome back to VoraPrep Audio Office Hours. Today we're tackling a topic that can make or break a multi-million dollar IT project: the Software Development Life Cycle, or SDLC. Emma: And specifically, why choosing the wrong one is so risky. We’ve all heard horror stories—a project is months behind, the original requirements are totally obsolete, and the whole thing is a mess. As an IS auditor, you’re the one who has to explain why. Marcus: Exactly. And often, the root cause isn't the programmers or the project managers. It’s a mismatch between the project's needs and the development methodology itself. Let's start with the classic: the Waterfall model. Emma: The one everyone learns first. It’s very linear, very sequential, right? Marcus: Precisely. Think of it like its name. Water flows from one level to the next, and it can't go back up. In this model, each phase has to be one hundred percent complete before the next one can begin. Emma: So what are those phases? What's the first step in that waterfall? Marcus: It all starts with Requirements. This is where every single thing the system needs to do is gathered, analyzed, and documented. And critically, it ends with a formal sign-off from all the stakeholders. Emma: Okay, so requirements are locked in. What's next? Marcus: Then comes Design. Based on those approved requirements, the team creates the system architecture and all the detailed technical specifications. It's the blueprint for the entire system. Emma: So we have the blueprint. Now the team actually builds the thing? Marcus: That's the Implementation phase, or development. Coders write the software based on the design specs. This is also where they'll typically do their own small-scale unit testing. Emma: After the code is written, it has to be properly tested. Marcus: Right. The next phase is Testing, or Verification. This is where the complete system is tested against those original requirements. You'll see integration testing, system testing, and finally, User Acceptance Testing, or UAT. Emma: And assuming it passes UAT, it goes live. Marcus: That's the Deployment phase. The software is released into the production environment for everyone to use. Emma: But it doesn't end there, does it? There's one more phase. Marcus: The final one is Maintenance. The system is supported with bug fixes, security patches, and any small enhancements over its lifetime. Emma: That all sounds very orderly. As an auditor, what am I looking for in a Waterfall project? Marcus: You're looking for evidence at the "gates" between each of those phases. Your key control points are the formal sign-offs. Did the business formally sign off on the Business Requirements Document? Is there a documented, approved result from the User Acceptance Testing? Emma: So I need tangible proof at each stage—signed documents, approved diagrams, test results. Marcus: Exactly. Without that evidence, the project has no baseline for what "success" even means. Emma: This model seems very rigid. What's the biggest risk with this approach? Marcus: The rigidity is its primary risk. If there's a mistake or a misunderstood requirement from that very first phase, you might not find it until you're six months down the road in the testing phase. At that point, fixing it is like trying to move a supporting wall after the house is already built. It's incredibly expensive and time-consuming. Emma: So if Waterfall is like building from a fixed blueprint, what’s the alternative for projects where requirements might change? Marcus: That brings us to Agile methodologies. Agile is an iterative approach. It's built for flexibility and customer collaboration. Instead of one giant, all-or-nothing project, the work is broken down into small, manageable pieces. Emma: I like your house analogy for Waterfall. Is there one for Agile? Marcus: Think of Agile like building that same house, but one room at a time. You build the kitchen, show it to the owner, and they say, "You know, I'd actually love another window over the sink." Because the rest of the house isn't built yet, adding that window is a manageable change. You get feedback and adapt as you go. Emma: That makes sense. I know there are different flavors of Agile. What's Scrum? Marcus: Scrum is a popular Agile framework where work is done in fixed-length iterations called "sprints," which are usually two to four weeks long. Each sprint delivers a small, potentially shippable piece of the final product. Emma: And what about Kanban? I hear that term used a lot. Marcus: Kanban is another framework, but it doesn't use fixed sprints. It's all about continuous flow. The main goals are to visualize the work, limit the amount of Work In Progress—or WIP—at any one time, and just optimize the flow of tasks from start to finish. Emma: Okay, so for an auditor, this is a whole different world. We don't have those big, formal sign-off gates between phases. So how does our audit approach change for Agile? Marcus: Your focus shifts from end-of-phase reviews to continuous assurance. You're not auditing a finished product once a year; you're auditing the health and integrity of the development *process* itself, as it's happening. Emma: What would that look like in a Scrum project, specifically? What controls am I checking? Marcus: You'd look at their "Definition of Done." Is it a formal standard that includes critical quality and security checks? You'd also review the product backlog—the master list of features—to ensure work is being properly authorized and prioritized. You might even observe a sprint review meeting to see that stakeholders are truly involved. Emma: And for Kanban, with its focus on flow? Marcus: For Kanban, you'd verify that their Work In Progress limits are actually being enforced. This prevents bottlenecks and ensures the team isn't sacrificing quality for speed. You could also analyze their flow metrics, like cycle time, to see if their process is efficient and predictable. Emma: All this talk of speed and small, rapid changes naturally leads to DevOps. How does that fit in? Marcus: DevOps is a culture, supported by a set of practices, that aims to shorten the development life cycle even further. It does this by combining software development—the "Dev"—and IT operations—the "Ops"—through a massive amount of automation. Emma: When we talk about DevOps practices, what are the key ones we need to know? Marcus: The first is Continuous Integration, or CI. This means developers merge their code changes into a central repository very frequently, and each time they do, an automated build and a suite of tests are run. Emma: And that leads to CD, Continuous Delivery or Continuous Deployment. What's the difference? Marcus: They're related. Continuous Delivery extends CI by automatically preparing every code change for release. However, the final push to production requires a manual, human approval. Continuous Deployment takes it one step further and automates that final step, too. If the code passes all the automated tests, it goes live without any human intervention. Emma: And I've heard the term Infrastructure as Code, or IaC. Marcus: That's another key practice. It means managing your servers, networks, and databases through code, using definition files, rather than manually configuring everything. It makes your infrastructure consistent, repeatable, and version-controlled, just like your application code. Emma: This level of automation raises a huge red flag for auditors: Segregation of Duties. If a single developer can commit code that an automated pipeline deploys to production moments later, where is the control? Marcus: That is the DevOps SoD paradox. You're absolutely right. The traditional control of having a separate Ops team deploy a developer's code is gone. The control point has moved. It's no longer a manual handoff between people; the control is now the security and integrity of the automated pipeline itself. Emma: So as an auditor, I'm not looking for a sign-off sheet anymore. I'm auditing the pipeline's configuration. What specific controls should I be looking for there? Marcus: First, access controls on the source code repository. Are there rules, like protected branches, that prevent an unauthorized person from committing code directly to the main line? Emma: Okay, so control over who can submit the code. What else? Marcus: Next is automated testing within the pipeline. Does the pipeline mandate security scanning? And more importantly, does a failed security scan automatically "break the build" and stop the deployment cold? That’s a critical preventive control. Emma: That makes sense. The pipeline has to enforce quality. What about a trail of what happened? Marcus: That's logging and monitoring. Every single action within the pipeline—every commit, every test, every deployment—must be logged. This creates an immutable audit trail so you can see who changed what, when, and how it got to production. Emma: One last thing. What about passwords or API keys? You can't just have those sitting in a script. Marcus: That's a huge point. Secret management. You need to audit how the pipeline accesses secrets. They must be stored in a secure vault and retrieved at runtime, never, ever hardcoded into the source code or build scripts. Marcus: So, Emma, think about that SoD shift. If a developer can't deploy code to production manually, but they can commit code that an automated pipeline deploys, where has the control point for Segregation of Duties moved? Emma: It's moved from a person—the Ops team member who used to do the manual deployment—to a system: the CI/CD pipeline's configuration and security settings. Our job is to audit that system. Marcus: Precisely. Emma: This is a fantastic framework for understanding the models. But how do we use this knowledge to answer questions on the CISA exam? Marcus: There's a four-step process you can use. First, identify the methodology. The question will have keywords. "Phases," "gates," or "upfront requirements" means Waterfall. "Sprints," "backlog," or "iterations" points to Agile. "CI/CD pipeline" or "automation" signals DevOps. Emma: Okay, step one: identify the model from the keywords. What's step two? Marcus: Step two: pinpoint the core risk. For Waterfall, it's inflexibility. For Agile, it might be scope creep or a breakdown in the process. For DevOps, it's the concentration of risk in that automated pipeline, especially around SoD. Emma: Step three must be about the audit action itself. Marcus: Yes. Step three: match the audit action to the methodology. The correct answer must fit the context. You wouldn't recommend a formal phase-gate sign-off for an Agile project. For DevOps, the best answer will almost always involve auditing the automated controls *within* the pipeline. Emma: And the final step? Marcus: Step four: evaluate the control's purpose. Is it preventive, stopping a bad thing from happening? Or is it detective, finding it after the fact? In a rapid environment like DevOps, preventive controls, like an automated security check that blocks a deployment, are almost always stronger. Emma: Let's walk through an example. Can you give us a scenario? Marcus: An auditor is reviewing a new e-commerce project. The team has daily meetings, two-week 'sprints,' and a 'product backlog.' They have an automated pipeline, but their 'Definition of Done' is just an informal checklist. The auditor finds that features are being marked 'done' without any security scanning. Emma: Okay, let's use the framework. Step one, identify the methodology. I see 'sprints' and 'product backlog,' so that's definitely Scrum, which is an Agile framework. Marcus: Correct. Now, step two. What's the core risk? Emma: The risk is that the informal 'Definition of Done' means security is being skipped. Vulnerabilities are likely being pushed into the code and won't be caught. Marcus: Perfect. Now step three, find the best audit recommendation. Imagine one option is to recommend a formal, end-of-project UAT sign-off. Another is to recommend formalizing the 'Definition of Done' to require that all code must pass automated security scans. Emma: The end-of-project sign-off sounds like a Waterfall control. It doesn't fit the Agile process. The best answer has to be formalizing the 'Definition of Done' to include security scanning. It embeds a preventive control right into their existing sprint workflow. Marcus: Exactly. You identified the common trap. So many people fall for applying a Waterfall control to an Agile project. In Agile, assurance has to be continuous and integrated, not tacked on at the very end. Your recommendation strengthens the process within the sprint. Emma: That trap seems like a really important pitfall to avoid. Auditing Agile with a Waterfall mindset. Marcus: It's the most frequent mistake. An auditor must focus on the integrity of the ongoing process—the health of the backlog, the quality of the retrospectives, the reliability of the automated checks—not on forcing after-the-fact approvals that disrupt the team's flow. Emma: This is incredibly helpful. For Scrum specifically, there are a few key meetings or ceremonies. Is there a good way to remember those? Marcus: There is. Use the mnemonic PSRR. P-S-R-R. It stands for Planning, Standup, Review, and Retrospective. Emma: So, Planning is where the team decides what to do in the sprint. Marcus: Correct. Standup is the brief daily sync meeting. Emma: Review is where they show the finished work to stakeholders. Marcus: Yes. And Retrospective is the final meeting where the team reflects on the sprint to find ways to improve their process for next time. PSRR: Planning, Standup, Review, Retrospective. Emma: So to recap, the big picture here is that the SDLC methodology you choose directly shapes the project's risks. And as auditors, our strategy has to adapt to that methodology. Marcus: That's the key takeaway. Waterfall is linear, so you audit the gates. Agile is iterative, so you audit the process. DevOps is automated, so you audit the pipeline. There's no one-size-fits-all approach. Emma: This really solidifies the concepts. It's clear that knowing the theory is one thing, but applying it through practice questions is what makes it stick. Marcus: Absolutely. And getting comfortable with these concepts takes practice. For anyone looking to solidify this, VoraPrep is a full exam-prep app — lessons, practice questions, and an AI tutor in one place. You can get started at Vora Prep dot com. It's free to try. Emma: Perfect. Thanks, Marcus. This really clarifies how to think about these different models and, more importantly, how to audit them. Marcus: My pleasure. Keep up the great work, everyone. We'll see you next time.