Latest / VoraPrep Audio — Professional Licensure & Certification Exam Prep / [CPA] ISC: Mastering IT Governance and the System Development Life Cycle (SDLC) for the ISC Exam
Transcript
- Hey, welcome to VoraPrep Audio. Glad you could tune in. Let’s talk about a mistake that costs millions. A huge national retailer decides to build a brand new inventory system. They spend fifty million dollars on it. It’s a massive project. Launch day comes… and the whole thing crashes. It just can’t handle the number of sales coming through. Stores can’t ring people up. Online orders are getting lost. And the company’s stock price just tanks. We’re talking a two-hundred-million-dollar loss in market value, just gone. So what happened? The development team skipped a crucial step—performance testing. And management, who was supposed to be overseeing the whole thing, never asked. This isn't just a scary story. It's what happens when a company gets the System Development Life Cycle wrong. As a future CPA, this is your world. Because the integrity of the financial data you rely on flows directly through these systems. Protecting them is about protecting the company itself. So, what is this process? The roadmap for building a system is called the System Development Life Cycle, or SDLC. It's a structured, phased approach to plan, build, test, and launch a new information system. Think of it like the blueprints and construction schedule for building a house. It gives you a process to follow so you end up with what you actually wanted, on time and on budget. And it doesn't matter if you're building the system from scratch or buying it from a vendor. The same principles apply. But the SDLC doesn't just happen on its own. It's overseen by something called IT. Governance. This is like the board of directors, but for technology. It's the framework that makes sure all IT projects actually support the company's main strategy and goals. This includes all the spending and all the new systems. IT. Governance sets the rules. It decides how much risk is acceptable. So, IT. Governance is the 'why' and the 'what'—the big picture strategy. The SDLC is the 'how'—the step-by-step process to get it done. A popular framework that guides this is called COBIT, which stands for Control Objectives for Information and Related Technologies. We'll touch on that a bit more later. Now, on the exam, you'll often see scenarios where something went wrong in a project, and you have to identify the control weakness. Here's a simple way to approach those questions. First, figure out what phase of the life cycle you're in. Are they planning the project? Are they in the middle of testing? Or is the system already live and being maintained? Just knowing where you are in the process cuts down your options immediately. Second, look at who is doing what. Is it a developer? A business user? An IT manager? So many of these questions boil down to a failure in segregation of duties. Someone is doing something they shouldn't be. Third, ask yourself: what is the purpose of the control in this situation? For example, the whole point of user testing is to make sure the system actually meets the business's needs. The point of change management is to protect the live, production environment from breaking. If you can frame the problem around the control's objective, the risk becomes much clearer. And that leads to the final step: pick the answer that strengthens control. The right answer almost always adds independent oversight, enforces separation of duties, or requires a formal, written sign-off from the right person. And by the way, that right person is very often the business user, not just another IT person. Alright, let's walk through the classic SDLC model. It’s called the "Waterfall" method. That's because each phase flows into the next, and you have to finish one completely before the next one can start. It all begins with Phase One: Planning. This is the "should we even do this?" stage. You're defining the project, figuring out its goals, and doing a feasibility study. Is this technically possible? Is it economically viable? Will people actually use it? The goal here is to get a formal 'yes' or 'no' to proceed. The key control is the IT. Steering Committee. This is a group of senior leaders from both business and IT. They're the ones who review the business case, poke holes in the cost-benefit analysis, and give that official green light. An auditor would want to see the meeting minutes from that committee to make sure they did their job properly. Once the project is approved, you move to Requirements Analysis. This is probably the most important phase. It's where you figure out exactly what the system needs to do. We're talking about functional requirements, like the system must be able to calculate sales tax. And also non-functional requirements, like the system must respond within two seconds. The key control here is non-negotiable. The business users—the people who will actually use this system every day—must formally sign off on the requirements document. An auditor is going to look for those signatures. They want proof that the business agreed, "Yes, this is what we need." With signed requirements in hand, we get to the Design phase. This is where the IT architects take those business needs and turn them into a technical blueprint. They design the database, the user interface, and the security controls. A critical control here is to design things like audit trails and access controls into the system from the very beginning. They can't be bolted on as an afterthought. You can't just hope for security; you have to design for it. Next up is Development. This is the coding phase, where programmers actually write the software. The most important control here is separation. All this coding has to happen in a separate, segregated development environment. It can't be happening on the live system. You also need a version control system to track every single change made to the code. Another good practice is having peer code reviews. This is something an auditor looks for. It's where one developer checks another's work for errors before it moves on. Now we get to Testing. This is where you try to break the system to find all the bugs before your customers do. This should be done by an independent Quality Assurance team, or QA. Not the developers who wrote the code. Why? It creates a conflict of interest. A developer might be hesitant to find flaws in their own work, or they might only test the things they know work well. You need a fresh, unbiased set of eyes. The single most critical control in this phase is User Acceptance Testing, or UAT. This is where the business users get to test the system. These are the same people who signed off on the requirements. Their goal is to validate that the system actually does what they asked for. Their formal, documented sign-off is the final gate before the system can go live. An auditor will always ask for proof of UAT sign-off. After a successful UAT, it’s time for Implementation. This is the "go-live" event. You're deploying the new system into the production environment. Key controls here include a few things. First, a formal go-or-no-go decision from that same IT. Steering Committee. Second, a carefully controlled plan for converting data from the old system to the new one. And third, a rollback plan. This is crucial. You have to have a plan to go back to the old way if something goes catastrophically wrong. And finally, once the system is live, we enter the Maintenance phase. This phase is forever. It's about providing ongoing support, fixing bugs, and making enhancements. The absolute critical control here is the formal change management process. Any change to the live production system has to go through a formal process, no matter how small. It requires a formal request, approval by a Change Control Board, and testing. You can't just let developers poke around in the live system. That’s how you get outages. Let's make this real with that retailer example. The warehouse team said they needed the system to handle five thousand orders per hour. That was a non-functional requirement, written down and signed off on. But the IT team, under a tight deadline, designed a database that was easy to build but couldn't handle that kind of volume. In the testing phase, the QA team checked that the system worked for a single order. Functionally, it was fine. But they never did performance testing with a large volume of data. They never checked if it could handle the five thousand orders per hour. The business users did their UAT, saw that it processed one order correctly, and they signed off. Then it went live, the holiday rush hit, and the system crashed. The root cause? The lack of performance testing. A tempting wrong answer on an exam might be to blame the business users for signing off on UAT. But that misses the point. UAT is for validating functional requirements—"does the system do what I asked it to do?" It's not the business user's job to simulate thousands of transactions. That's a technical, non-functional requirement. Testing it is the responsibility of the independent QA team. That distinction is key. This also highlights the difference between two words people often mix up: verification and validation. Verification is asking, "Did we build the system right?" according to the technical specs. Validation is asking, "Did we build the right system?"—one that actually meets the business's needs. The retailer’s system passed verification. It was built the way it was designed. But it failed validation, because it couldn't perform in the real world. Now, that whole Waterfall model is very rigid and sequential. For a lot of modern projects, that doesn't work. So you'll see more flexible approaches. One is called Agile. Instead of one giant project, Agile breaks the work down into small, two-to-four-week cycles called sprints. It's much more collaborative and iterative. For an auditor, this is a challenge because the documentation can be less formal. So, an auditor's approach has to change. Instead of reviewing a giant design document from six months ago, they might observe sprint planning meetings. Or they might check that the automated testing controls are working properly. And that leads into DevOps. DevOps is a culture that combines software development and IT operations to automate and speed everything up. It relies on something called a CI./CD pipeline, which stands for Continuous Integration and Continuous Deployment. It’s an automated process that builds, tests, and deploys code. The control is no longer a person signing a piece of paper; the control is embedded in the automated pipeline itself. So an auditor's job shifts to auditing that pipeline. Who has access to it? Are the automated security tests robust? So you can see how all this—the SDLC, Agile, DevOps—is the "how." The "why" and the oversight comes from IT. Governance, and that framework I mentioned earlier, COBITCOBIT organizes IT into a few domains. For the SDLC, the most important one is called Build, Acquire, and Implement, or BAI. It’s the bucket that contains all the detailed control objectives for things like managing requirements, testing, and handling changes. A really solid change control process is the heart of IT governance after a system goes live. You can think of it as a formula. It starts with a formal request. Then, an impact analysis. Next comes approval. That's followed by segregated testing and implementation. And finally, a review after the fact. That formula ensures no one person can just push a change into production on their own. When you see these scenarios on the exam, put on your auditor hat. The right answer will almost always point to something that increases independent verification, requires a documented sign-off from a business owner, or enforces that crucial segregation of duties. The core ideas to take away are these: IT. Governance sets the strategy, and the SDLC is the process that executes it. User Acceptance Testing by business users is a critical checkpoint. Segregation of duties is paramount—developers don't test their own final code and they don't deploy it. And as an auditor, your job is to look for the evidence of these controls at every single stage. Alright, that’s all for today. Keep up the great work. You've got this. VoraPrep is a full exam-prep app — lessons, practice questions, and an AI tutor in one place. Get started at Vora Prep dot com.