Latest / VoraPrep Audio — Professional Licensure & Certification Exam Prep / [CISA] CISA3: Auditing the System Development Life Cycle (SDLC)
Transcript
- Hey, welcome to VoraPrep Audio. Glad you could join me. Today we're talking about the System Development Life Cycle, or the SDLC. This might sound a little dry, but it's where the real action is for an IS auditor. The reason this matters so much, on the exam and in the real world, is that getting it wrong can be catastrophic. Think about this for a second. A regional bank was in a huge rush to get its new mobile app out the door. A big marketing push was planned, so they cut a few corners. They skipped a formal security design review. They also let the developers handle the final testing, instead of bringing in actual end-users. Within two days of launch, attackers found a flaw. They started draining money from customer accounts. The audit team found the problem later, of course, but the damage was already done. The brand took a huge hit. That’s why we, as auditors, care so much about the SDLC. It’s not about being a process police officer. It’s about building controls into the system from day one, not trying to bolt them on after a disaster. So, what is the SDLC.? The System Development Life Cycle. At its heart, it’s a structured, logical map for building something complex, like new software. Think of it like building a house. You wouldn't just show up with a pile of lumber and start nailing boards together. You'd have a plan. You’d have blueprints. You’d have inspections at key stages. The SDLC is that plan for building an information system. Now, there are different models. But the one you absolutely need to know for the exam is the traditional "Waterfall" model. It's a straight line. You finish one phase completely before you move to the next. Let's walk through that journey. It all starts with the Feasibility or Initiation phase. This is the "is this even a good idea?" stage. Someone has a concept. The business develops a case for it, does a cost-benefit analysis, and decides if it's worth the investment. Is this project going to solve a real problem? Will it make us money? If the answer is yes, it gets a green light and funding. Once it's approved, we hit what is arguably the most critical phase: Requirements Definition. This is where we figure out exactly what this thing needs to do. We sit down with all the stakeholders to document everything. We gather the business, functional, technical, and security requirements. What reports does it need to generate? What security permissions are required? What regulations does it have to comply with? This document becomes the foundation for everything that follows. If you get the requirements wrong, the entire project is built on sand. Next up is Design. We take those approved requirements and turn them into a technical blueprint. This is where architects and senior developers figure out the system's structure. They map out the database layout and how it will connect to other systems. They're basically drawing the detailed blueprints for the house before anyone picks up a hammer. A key part of this is designing the security controls right into the architecture. Then comes Development. This is the construction phase. The coders take the design documents and start writing the actual software. They're building the individual components—the walls, the rooms, the plumbing. As they build each little piece, they do what's called "unit testing" to make sure that one specific function works as it should. After the pieces are built, we move into Testing. This is a big one. It's not just one thing. All the individual components are put together for integration testing to see if they work with each other. Then there's system testing, to see if the whole application works as a whole. We also perform security testing. And crucially, there's User Acceptance Testing, or UAT. This is where we hand the system over to the actual business users. These are the people who will use it every day. We ask them, "Does this do what you asked for? Does it solve your problem?" Their sign-off is non-negotiable. Once it passes all the tests, we're ready for Implementation. This is go-live. We move the system into the production environment. We migrate any necessary data, train the users, and flip the switch. But we’re not done yet. A few weeks or months later, we do a Post-Implementation Review. We look back and ask: Did we meet our goals? Are the controls we built actually working in the real world? What did we learn that we can apply to the next project? It’s about closing the loop. Okay, that’s the whole sequence. To help you remember the order for the exam, there’s a simple mnemonic: I Really Do Desire To Implement Properly. That’s Initiation, Requirements, Design, Development, Testing, Implementation, and Post-Implementation. I Really Do Desire To Implement Properly. So, where do you, the IS auditor, fit into all this? Your checkpoints are what we call Phase Reviews or Quality Gates. Think of a quality gate like the security line at the airport. You can't get to your gate until you've shown your ID and your bag has been scanned. It’s a hard stop. A project can't move from Requirements to Design until all the requirements have been properly documented and formally signed off by the business owner. A common mistake is to see a project plan with a checkmark next to "Requirements Complete" and just accept it. That checkmark is a project milestone, not a control. As an auditor, you need to see the evidence. You'd ask to see the signed-off requirements document itself. That signature is the proof that the control—the quality gate—was effective. Let's walk through an exam-style scenario. Imagine you're auditing 'Project Phoenix,' a new CRM system. The project is just about to go live. You're looking at the User Acceptance Testing documents. You see the final sign-off was done by the lead developer. It was not done by the head of the sales team, who is the primary business user. Okay, let's break this down. First, what's the control objective here? UAT is supposed to confirm the system actually meets the business's needs, from their perspective. Second, how's the control designed? Well, it's broken. A developer signing off on their own team's work is a huge conflict of interest. They can't provide independent validation of its business fitness. Third, what’s the risk? The risk is massive. You could deploy a new system that the sales team can't even use, or that doesn't do what they need. It could fail to deliver any business value. So, what is the BEST recommendation an IS auditor can make here? The CISA exam will give you options. One might be, "Document the finding in the final audit report." Another might be, "Recommend additional training for the project manager." But the best answer directly addresses the immediate risk. It's to recommend halting the implementation until proper UAT is completed and signed off by the business users. You have to stop the flawed system from going into production. That's the trap. Documenting the finding is passive; it happens after the damage is done. The auditor's primary job is to provide assurance and prevent risk before it materializes. On exam day, when you see a question about the SDLC, especially around testing, always look for the issue of independence. Developers do unit testing on their own code, that's fine. But final system testing, security testing, and especially UAT, must be done by an independent party. Developers should never, ever sign off on UAT. The answer that reinforces independence and business user validation is almost always the right one. So, to wrap up: the SDLC is a structured roadmap. Each phase has its purpose and its controls. As an auditor, you focus on those quality gates, looking for hard evidence like a signature, not just a checkmark on a schedule. A key tool for this is the Requirements Traceability Matrix, or RTM. It lets you trace each requirement from its origin all the way through testing, ensuring nothing gets missed. And remember, User Acceptance Testing is the business's final word. It has to come from them, not the people who built the system. Finally, while we focused on the traditional Waterfall model, your audit approach needs to adapt for other methodologies, like Agile, where the cycles are faster and controls are embedded differently. VoraPrep is a full exam-prep app — lessons, practice questions, and an AI tutor in one place. Get started at Vora Prep dot com. Alright, that's it for today. Keep putting in the work, one concept at a time. You've got this. Talk to you on the next one.