Did you know Cybrary has FREE video training? Join more than 2,500,000 IT and cyber security professionals, students, career changers, and more, growing their careers on Cybrary.
This lesson covers Domain 3 which is about IS acquisition, development and implementation and centers on providing assurance that the practices for the acquisition, development and testing of information systems meet the organization's strategies and objectives. This unit also discusses task and knowledge statements. [toggle_content title="Transcript"] Alright, welcome to domain number three. In this domain we'll be talking about the acquisition, implementation and development of information systems. The auditor is trying to provide assurance or confidence that the processes involved in getting systems into the environment are being followed correctly. So we'll look at our task statements for domain three. We start off with evaluating the business case. So this is a way of proving that there is a need for some system or some software and trying to make a connection between that need and what the leadership of the organization is willing to spend to achieve those goals. Then we have to think about evaluating project management practices. Are these projects being managed cost-effectively? Are they staying on-target? These are the kind of questions that might come up. Then the auditor has to conduct reviews to make sure that projects are moving along as expected. Reaching milestones, staying within budget, and so on. Number four is evaluating controls for the systems. There's a lot that goes into this, of course, but it's basically trying to make sure that the system is developed and tested properly before it's implemented. We need to think about number five; making sure that systems; after they've been properly developed and implemented, that they're ready to be moved into production and trying to have an eye for all the details that are involved in making that happen. Number six: conducting post-implementation reviews to make sure that the deliverables were done on-time and were done according to the plan. Alright, moving on to our knowledge statements for domain number three. Having knowledge of different business practices, realizing different benefits. Concepts like total cost of ownership and return-on-investment. These are important concepts because the leaders of the organization that are deciding money needs to be spent to achieve some goals want to be able to measure the performance of their funds as have been outlaid for various different initiatives. Knowing about project governance mechanisms: we'll talk about steering committees, project management offices and the oversight board. These are important groups within the organization to try to manage complex environments with lots of different projects happening simultaneously. Then we'll look at project management control frameworks; some different ways that you can think about managing projects, maybe using certain software tools to assist in these tasks. Then number four is looking at risk management practices. Risk management is a broad topic, as I mentioned in earlier sections. We also need to think about how it applies to managing projects. Then number five: knowledge of IT architecture. So understanding how the organization's architecture is designed, what the security functions are supposed to do, and so on. Then we have a few more to go here. Acquisition practices as it relates to dealing with vendors, contracts. There's lots of different details that will need to be covered relating to the acquisition of resources or tools. Number seven: requirements analysis. So are the requirements for a project detailed? Are they complete? Have they been verified? How do we deal with managing vulnerabilities, and so on? There's a lot of different details that go into this. What constitutes a successful project? What are the criteria that are used to judge whether something is successful or otherwise? Number nine: control objectives. These are concepts that are trying to understand how your applications actually work; what kinds of transactions happen in the environment and different ways to measure that and verify that transactions are being done correctly and completely. Then we move on to number ten: system development methodologies. Of course, some of the tools that go along with that; we have things like agile development prototyping, rapid prototyping, object oriented design. We move on to number eleven: testing methodologies. What's involved with testing a system during development and while it's actually in production? That's a topic that continues throughout the life-cycle of a system. The testing begins as early as possible in the process and should continue until that system gets de-commissioned. Configuration management, a big topic as well. We want to make sure that we can understand the change control process and how changes to a system or its environment of operation might affect other areas of the organization. So it's an area that needs to be focused on at some level. Then we have knowledge of system migration and infrastructure. So how do you move data around when systems are being de-commissioned, for instance, and you're replacing an older system with something new? How do we move the data? What's involved in some of those considerations? Then the last knowledge statement is a post-implementation review. This is sort of a lessons learned idea where once a system is in-place, or an application's in-place, doing some review after the fact to see how well everything went, or didn't go, and trying to identify those areas where there could be some type of improvement. [/toggle_content]