All Isaca CISA certification exam dumps, study guide, training courses are prepared by industry experts. Isaca CISA certification practice test questions and answers, exam dumps, study guide and training courses help candidates to study and pass hassle-free!

Lesson 5

1. IT Service Delivery And Support

Let us now discuss service delivery management. Let's talk a little bit about service level management and operations management, change and release and configuration management, incident management, and just generally the service level functions. When we look at service level management, it basically says that we're going to agree on a certain level of service and then manage it to ensure that we deliver on that level of service. The service level could be from within your own department or from an external provider. Taking a look at the different kinds of providers Obviously, we have ISP providers, so we have providers that give us access to the Internet, and that can be either through business DSL, a dedicated link of some kind like a dedicated T1, or some other kind of connectivity. Another is an application service provider.

This could be a third-party organisation that manages your customer relations database, your electronic health record system, and your email system. You just decided that you don't have the staff or the expertise to manage that kind of thing in-house, so you've outsourced it to a third-party provider. Another possibility is a managed service provider, and this could be infrastructure-type services like backups or maybe software support. Or if this is non-IT, it could be things like water and power. Another one is your telecommunications provider, which may or may not be the same as your internet service provider. And so your telecom would be the folks who handle your actual phone systems coming in.

Realize that with some of these, especially the phones, their responsibility might end at a certain point. especially with phone providers. There is a point of demarcation, which we call DMARC, which is actually a physical box where the line comes in from the outside. And, unless you pay for a special contract, many service providers' responsibility ends there, and your responsibility begins there. And that's usually in the phone room, which could be in the basement or some other room. And sometimes you might have a telecom provider bring you service, but you might have another provider, like a cabling contractor, actually cable all of the offices from that D mark. All of these, though, require certain levels of service that you have to manage and be on top of with some of the tools that you might use.

And we can see here that we might have reports like exception reports. So these are things that are generated because a task didn't complete properly or didn't complete successfully. And so, as a task tries to run, an exception report is generated, which should be generated automatically. One thing is that if you have too many exception reports, you might have to wonder, "Is there something wrong with the infrastructure?" Is there something wrong with the application—perhaps it wasn't written well—or are there other issues we should look into? You can probably expect exception reports occasionally, but if you get too many now, you have to see why that is. You might also have a job rerun report.

If you work in an environment where you run a large number of transactions at night, you could simply batch a bunch of jobs to income all of these transactions, and then batch them to be processed. Into the database or processed in some way, then you may have reports that say, "Okay, the job failed, and we're going to rerun it again." The job had to be restarted, the application had to be restarted, and so we're going to rerun that job again.

Another one we can see is an operator problem report. Now, a computer operator in a larger environment is somebody who is actually going to be feeding input into the computer and managing the computer. This will be like a large mainframe as opposed to somebody's desktop. And so that person may give you service or may give you reports as well, and those will be manual, and you have to determine OK, what's going on here? Maybe you need to train the operator more, or maybe there's some other issue that you need to investigate. We can also have output distribution reports. We can see here that it can be manual or automated. Maybe we have a whole bunch of reports that need to be disseminated.

So if we are wondering what has happened to certain reports, the output distribution report can say, "Okay, I sent out all of these reports or I didn't." Like I said, it could be a manual or automated task. And then you'll wonder, "Why wasn't I getting these reports here?" On one EHR project, I was working on all output distribution reports. They were done manually because we didn't have an automated process, and we had to investigate why, from one particular facility and actually one particular district, we weren't hearing anything at all. You can also have console logs.

Now, if you've ever looked at, say, the log of a firewall or the log of a system like an event viewer log, if you've ever looked at a Windows event viewer log, there are tonnes and tonnes and tonnes of stuff that gets outputted to this log. Because every time an event occurs—something opens, something closes—something is done that's logged. When something doesn't work, and you'll almost certainly have to because the output is so large, you'll usually need some kind of filter, application, or the logging tool itself to help you narrow down your search, either to find exactly what you want or to just narrow it down.

I only want to see the criticals or the errors, or I only want to see things from last night. So console output is really good, but usually the logging is so extensive that you'll need to find ways to narrow it down. And search for only specific things, like with Microsoft Windows. It was only in the last couple of years that there were tools that could really effectively search through and find and track certain things because there was so much raw output. Yes, you could filter to critical errors, but if you wanted to find something that was a little bit more meaningful and helped you interpret, we've only recently seen tools to help us with that.

And then, of course, we can also look at operator work schedules. Perhaps we are overutilizing users, or there are gaps; perhaps more transactions will be coming in during the third shift, and we will need to increase our staffing, particularly the input and output control personnel. This is a group of folks. They're responsible for making sure that all the processing of the information actually does what we want it to do, that it aligns with the organization's goals, and they will manage the input and the output, both the automatic and the manual input. Remember how we talked about the idea of automatic input? We can have sensors automatically feeding input into our system and collecting it, or people can manually enter data. So these folks are responsible for making sure that this input is being processed the way the organisation needs it to be.

Now, some of the tasks, the control tasks for input and output, would include processing input and producing the output we want, and that output is typically going to be in the form of reports that are usable for the type of user. So, for example, a high-level manager will want to see summaries and quick dashboards of how certain projects are progressing, or how the entire company is doing. Or, in general, what are our sales? Whereas someone lower down may want to drill down a little further and see how individual tasks, individual users, or individual projects are doing and what their performance metrics are. And the other control task will want to ensure that the right people receive these reports and outputs, because we frequently don't get what we need. I frequently hear directors or project managers complain about not receiving the necessary input. As a result, we want to ensure that the report inputters receive the output.

We can also be concerned with making sure that the files are used, stored, and managed properly. So we've got databases and report files; make sure those, as well as incoming data and the files associated with them, are properly managed during processing. So, for example, a really simple example of that would be when I was in Africa and we had to manually collect input for our database because there wasn't the telecom system to send it, like over the internet, and we didn't have dedicated links. So people actually had to drive with flash drives and collect flash drives. And just simple management of that, as well as ensuring that the flash drives were not infected and were properly labelled We knew who they were, where they came from, and what the date was on that.

So that's even a simple example of managing files. We also need to make sure that when we're controlling input and output, the operators themselves are doing what they're supposed to be doing. And I can't emphasise that enough because when you're busy working like this and you don't know what people are doing or inputting data here, you need to go check. I mean, down at one particular application I was working on, the folks at the clinic level didn't have quite enough training or they had staff turnover.

They didn't know how to input the data properly. As a result, you must stay on top of things. You have to have controls and mitigation. For us, it was about staying on top of things, training those folks, and having someone on staff who could always help and mentor their peers. And then, of course, you need to make sure that the information maintains its integrity, that it's not changed, damaged, or corrupted in any way, that it still stays as it should be, and that it's not modified in any sort of unauthorised manner.

Another thing, of course, we have to worry about is scheduling. We must ensure that the jobs run correctly, in sequence, and that if one job fails, it is safe for another to run. So that is another thing we need to be concerned about. And of course, scheduling can be automated or manual. Hopefully you automate tasks, but again, if you automate tasks, you've got to stay on top of the output and the reports of those automated tests to make sure they were actually done.

I mean, recall the story of, yes, we had backups, and they ran every night, but nobody bothered to actually check to make sure the jobs actually completed properly. So these are all things that you have to look at when managing input and output and looking at controls, and the IS auditor has to make sure that there is no break and that everything is accounted for and done properly from the input, processing, output, and distribution.

2. How To Evaluate Service Level Management Practices

One thing that happens frequently is that maybe one service is being shared among many departments, divisions, or business units. And at that point, job accounting becomes important. Most automated accounting and auditing features, such as those in Windows, can simply log, and then you can look at the log to see, OK, that this particular business unit used 60% of that service, or 60% of the time, or 60% of whatever.

And those folks use that percentage, and these folks use this percentage. It's very common to have departments pay for their share, and you want to have some kind of log so that you can charge them. In Windows Server 2012, in some of the new group policies and the software restrictions, you can have things that, rather than just restricting people from using software, you can actually just log it for accounting purposes so that you can charge back to the different departments. So if you're going to do this, of course you have to have good accounting on this so that you can charge departments. And the IS auditor is going to want to take a look at, well, how well the logs were kept and how accurate were the charges back to the different departments?

So that is another thing that the IS auditor is going to want to be looking at when we're talking about input and output control. So as an IS auditor, when we're evaluating service level management practices, here is our checklist. We want to make sure that we take a look at the logs and see that the jobs were scheduled, completed, and completed properly, and that there were no errors or warnings. Watch out even for the warnings, because the warning could mean that the backup didn't complete. We want to take a look at the scheduled applications and their inputs, along with the time estimates for preparing and processing the data, and make sure that they are actually built into the service level agreement. We also want to look at the individuals who have the authority to access and alter the job schedule priorities. As an auditor, you want to see who is changing something and determine whether or not critical applications were identified to make sure that they're covered. And if there aren't enough resources, there won't be enough time, processing power, or memory to run critical applications. In our case, we used to batch run a bunch of reports and leave them overnight. But some reports were much more important than others.

And if we had only so much CPU power, we wanted to make sure those were scheduled first, make sure that there are scheduling procedures that make the best use of system resources, and determine if the workload is appropriate for the scheduled staff. I tell you, the staff is almost always overworked. And so now it becomes a matter of, "Well, how well did you manage what folks could do?" While we try to get more people in or the budget runs out, How well did we manage their workload?

We want to see if the daily work schedule informs the operators of what the work is. so the operators should come in. They should be able to see, "OK, I know what I need to do next." I know what's high on my priority list and whether or not they can hand off something to another operator. When we look at the service level agreements, we should do it in the next shift or pass it off to another person to do and review all of the published procedures for gathering, analyzing, and using performance indicators.

3. Operations Management

The next thing let's talk about is operations management. And this is making sure that, down at the lower level, the operations of that business unit and that department are running smoothly. I remember one time I had to take a look at why we were not getting the data that we needed. And it really came down to the operations management at the health facilities themselves. They were so busy providing their clinical duties that they couldn't provide their data entry duties. And so we found this to be a widespread problem. But we had to actually go down and see the operational management. The superintendents in charge of the facilities were entirely focused on taking care of patients rather than providing the data that the folks above them required to track disease in that country. So when you're talking about operations management, you're talking about allocating resources.

And he'll almost always have too few resources. You're always shorthanded, managing the resources wisely to produce what you need to produce while enforcing standards and making sure that the processes themselves are running properly. You always need to focus more on the process than on individual people. Individuals can come and go; they can be replaced; they can be reassigned. It's the process that needs to be in place. And that was one thing that we had to spend a lot of time on. Can we establish a process, have enough people know the process, have enough documentation, and have that just be part of the daily culture of those particular clinics so that if new people came in, they just kind of folded into the process? That really becomes much more important than one particular person.

Another thing I had to audit one time was: why is this particular department of developers so variable in their output? And what it really came down to was that there was one developer who was really, really strong, but there wasn't a process for distributing the load and increasing the skill set of the other developers. And unfortunately, the manager at the time focused so much on that one developer that everybody else just kind of sat around and languished. And it wasn't good utilisation of the staff. It wasn't a good process because if that one guy went, left, or whatever, they were all dead. So you really need to be focusing on processes rather than just specific individuals when you want to make sure that operations can be sustainable.

One thing that departments will often do is perform a lights-out operation. You probably do it yourself in a small way. Lights out simply means I'm going to leave something running unattended, and I may lock the computer, lock the computer room, shut down, even turn off the lights, or simply lock it up. There's nobody there. It's a two-edged sword to turn the lights out. The good thing about lighting is that stuff just runs. But you have to set it up properly. You have had to account for them; okay, the jobs are scheduled in a certain way. They can proceed if there's an error. The reporting is automated. And the nice part about it is that you can then have personnel focus on something else. And this is really good for automating batch jobs.

We've brought in all of these transactions. Now we're going to process them tonight and put them in the database tonight. Or it could be something like system maintenance. We're going to have automated backups and disc cleanup, defrag the database and the disk, et cetera. The disadvantage is that if you don't have it properly configured, the entire system may fail or stop generating reports. So in the morning, you think everything's good, but the backup actually didn't succeed. Nobody bothers to check. Also, the fact that you don't have people there or you're not attending it means that you're not watching it.

The upside is that maybe you won't have any human error from people coming in and doing stuff or even malicious intent. The downside is there's no one there to watch, and you're just wondering if they're suspicious individuals. So, if you do turn off the lights, you'll probably just double-check in the morning. OK, did everything get done? And that you have enough configuration, monitoring, and security in place to ensure that no one sneaks in while you're not looking. But as the IS auditor is going to want to be checking on all of this, Was turning the lights out effective? And were people checking the next day to make sure that last night's tasks were finished properly? Let's also talk about data entry controls. Remember that control can be anything from a policy, a procedure, technical control software, or a process—anything that helps to reduce risk and keep processes running smoothly.

So some data entry controls can include, "Well, wait, let me authorise all those things before you just start inputting them. Let me just make sure that these things should be inputted into these transactions." Maybe you've got a whole bunch of documents that people have been filling out, and before we process this, before we input it, let me take a look.

Another thing would be, okay, we've inputted a whole bunch of stuff. Allow me to compare inputs and outputs and reconcile differences. I was looking into why reports weren't coming out the way we expected them to one day. And what I had to do was actually look at, okay, what were people inputting? And I had to actually look at the paper because in those rural areas, people were collecting data on paper. First, they were collecting patient information, doctor's orders, prescriptions, procedures, and all this stuff on paper. And then later, a truck would come around with a mobile computer lab, and people would take all these batches and input them into the system.

And so we weren't getting the kinds of reports that we expected to see. So I had to actually look at the paper and reconcile it with the reports that were coming out. As it turned out, there was nothing wrong with the data entry. The problem was that the actual way the reports ran, the structure of how it managed the data, and the reports didn't output the data the way people expected them to.

The reports actually did what they were designed to do, but the people didn't understand how to interpret what they saw. So they thought they saw something here, but the intent of that was really this. And so it took a while to figure out why, when I was trying to reconcile inputs and outputs, it wasn't suiting the business need; it turned out to actually be neither an input problem at all nor a report problem at all, but just the way people assumed when they saw the fields in the report.

They assumed that it meant this when it actually meant that. Another thing you can do is just divide the duties among staffers. And dividing the control duties simply means that if you input, you reconcile, or if you back up, you restore. It is not only to divide the workload, but also to ensure that the same error does not occur on both ends. It's just like if you write something, don't proofread your own work; have someone else look at it. And this will cut down on errors. not only honest errors, but also maybe someone trying to hide something as well. Plus, if you have a different person, they may notice things that somebody else may not notice or that the input may not notice. Another thing you have to worry about is how files are handled. And not just paper files but also those flash drives, removable media, tape backups of databases, and database files.

Are they being taken off site for storage? Are they being carried around in someone's pocket? I know that sounds funny, but when you're in a place where you don't have a lot of telecommunications infrastructure, people carry around flash drives and carry computer viruses with them, and they spread that infection everywhere. So, and also, where are the backups? So the backup is just sitting right there. I mean, we've had cases of theft where people just walked right in and stole laptops off of desks even when people were in the office. And had they known what they were actually doing, they could have gone into the server room and stolen data out of there. But they were, of course, interested in selling laptops.

They didn't realise how valuable the data was. So the auditor needs to be looking at how people are handling the storage, the transport, and the offsite storage of any kind of data on any kind of media. When we talk about operations management best practises, we are really interested in how well the company serves its customers. It really drives me crazy. This is a personal pet peeve of mine: walking into an IT department and discovering that the people working there are arrogant toward the customers they serve. And when I say "customers," I mean the users. Yeah, we all have jokes about how users have broken this or users don't know that, but really, it's the users.

Their job is to be productive, bring in income, and do all the things that the business needs to do. Its job should be very customer-oriented so that users can do their job to the best of their abilities and make the money that pays for it. I mean, true, IT is now a big business supporter, not just simply a cost center, but the IT staff needs to understand that. And I compliment people when I see that a department really has a customer service event. I know it's easy to lose patience with users, but they're the ones who are actually doing the business, and we're there to support them so they can do their job. And so, in operations management, we must ensure that there is a customer service department, that we respond quickly and effectively, that we follow up, and that everyone can be productive and that their needs are met immediately, so they are not sitting dead and unproductive.

And also making sure that, of course, our operational environment itself is running smoothly and is stable. So when we are evaluating operations management as an IS auditor, we'll be looking at the following things: We want to make sure, of course, that there are schedules for each shift and that we're effectively using resources and justifying efficient and effective use of resources. Our justification is sound. Why are you doing it that way? Okay, I see why. We want to make sure that IT monitoring is in line with policy. If we need to be very secure, very accurate, or whatever, we want to make sure the monitoring is in line with that.

We want to make sure that vulnerabilities are identified and dealt with very quickly. And we want to be looking at logs to make sure changes are authorized, and if they are, that they are made promptly to whatever the system, the network schedule, to ensure that we're in compliance with standards and that operations are accountable. As a result, don't let everyone log in as administrators or use the same account. One of the things that we really had to hammer into people's heads was that you needed to logon as your account and not as somebody else's, because we needed to see who was doing something.

Likewise, don't share your password with someone else because if they make mistakes or they do something deliberate, you'll be the one who gets in trouble for it, and you'll be responsible for it. We want to make sure that there's accountability. The users and the IT department ensure that physical and logical access to resources is limited only to authorised users. So not everybody can get in to see this.

Not everybody can view reports, especially with something as critical and private as patient data. It's okay for a district officer to see general statistics. It's not okay for a district officer to see that a particular user is on that particular HIV drug regimen to verify that the computing environment itself is maintained and that if there are any errors or problems with the processing system, we can recover in a quick and timely manner and not lose any data.

4. Databases

Ultimately, every organization and every business is going to have some kind of database. Now, a database could be as simple as a phone book or your contact list in your phone, but more likely it's going to be a software-based database that is a repository that stores all the data in some sort of structured manner. The database itself is a storage device, and it maintains and organises the data in such a way that you can then access it.

If we look at this little diagram here, we can see that a user can query a database, something we call an "ad hoc query," or an application can go and fetch data out of the database. For example, I can have a web application that checks inventories, prices, availability, or something like that from a database for a customer who wants to buy something. Let's take a look at the different kinds of databases. There are a number of them, but there's really only one these days that we'll generally be thinking about. Now there were several different kinds of database structures. In the older days of the early mainframes of the DBMS, or database management systems, we had a concept called a hierarchical database. And it was here that the records were arranged in a tree-like fashion. We had parents, children, and then grandchildren.

We'll see a diagram in just a moment. There's also something called the "network database model." And with a network model, you didn't have to have a strict hierarchical structure. You may have far too many relatives. And with the network model, we could see the whole structure laid out in a sort of graph, and relationships would be represented by arcs. The one we most often see these days is something called a "relational database management system," or Rd BMS.In a relational database, the data is organised into tables, and the tables are related to each other because the tables have these fields and these columns that describe attributes of the data. and tables will have fields in common. In a moment, we'll look at an example of this as well. So here is a simple diagram of a hierarchical database model. And just so that you have sort of a sense of context, we're talking about, okay, pavement improvement.

And under pavement improvement, we have three sort of separate sets of records: reconstruction, maintenance, and rehabilitation, and then they further break out. So you've got a route with children, and they break out more and more. So we can have routine, corrective, and preventive actions under maintenance. It's very strict and hierarchical, and there are too many beneath it and then too many underneath that. Here is the same sort of concept, but in a network database model.

Again, we have the maintenance here, and we have rigid pavement and flexible pavement, and it looks like it's in a tree. But you'll notice that one set of records can have multiple parents. So you can have a set of records that have multiple parents and multiple children. It doesn't have to be strictly hierarchical. It can be one to many or many to many. Here's an example of a relational database. In this case, I have three little tables that are related. In a relational database, each type of thing has its own table. So down here, I've got a customer table, then a product table, and then an order table. And in the customer table, I'm not going to list any of their orders or any outstanding balances or anything like that. It's just customer information in the product table. I'm not going to list any orders for the products or anything like that.

It's just the products themselves and information about the products. Then the order table has a relationship with both. Most tables have something called a primary key, which is usually the very first column and the very first attribute, and it is some way of describing each record uniquely. Employee ID, product ID, order number, and social security number Sometimes it can be a compound of several columns together, like the first and last name as the primary key, but usually it's some kind of numeric value. It doesn't have to be, but it's a unique identifier so that we don't get them mixed up. And then, when you have tables that are related to each other, the table that has the relationship will have the same primary key as the other tables. But it's called a foreign key, and that's what ties the tables together.

So, for example, in the product table, I have item numbers like A 125, which is the M18X laptop for two for $300, and B 45, which is the D15 laptop for $800. In the customer table, I've got three customers, each with their own customer ID. So here's Susan with a customer ID of 0234; Kusala is five, and No. A is six. The order table I have orders, yes, and each order is individual, like orders 10 01 and 10 02. But notice the next columns here: I have an item number that is a foreign key to the primary key on the product table. So order number 1001 is for product A 125. So here's the primary key for products, and here's the primary key for orders. But this item number is a foreign key to the products. So these are how the tables are related. The next field here is a foreign key for customers. So I've got the customer number, so I can see that Susan, whose customer number is 0234, has ordered item number A 125 and in-stock number 1001. And this is the whole premise behind relational databases.

We keep the separate entity separate so that it just makes sure that the data is clean and not redundant anywhere. And then, if we need to get information from several tables, we can structure our query accordingly. And of course, we'll have tables that are related to other tables. In this way, with these relationships, you can't delete a customer while they still have an outstanding order. You can't maybe delete a product while you still owe a vendor for it. So that's the whole concept behind the relational database model. When we're creating a database, there are a lot of administrative tasks. And one of the first things, of course, is that you need to stand up a server that can support the throughput that database needs. Most database management systems will take all the resources they can. They'll take all of the RAM and all of the CPU. So you've got to set up a physical server or allocate a virtual machine.

Then you've got to install the database system. Then you've got to design the databases themselves, which means you have to actually understand what it is we're tracking. We're tracking employees, departments, managers, job descriptions, or something like that. And we create tables for all of them. Or we're tracking products, customers, orders, vendors, and what the relationship is between them. And some of these can become extremely complex, with numerous key relationships. Once we design it and create it, we create the tables and the key relationships, and then we'll put some constraints on what kind of data can go in. If this is a zip code field, no letters are allowed unless it is in another country where they use letters in zip codes. Or if this is a dollar amount field, no letters unless it is for some other reason. But usually, if it's numeric, it's just numbers. If this is a name, we generally don't put numbers in there. And if this is a state code, like California, Arizona, or whatever, it can only be two letters.

So you put in constraints so people cannot accidentally or purposefully put in the wrong kinds of information. And we can also set up some indexes so we can search the tables quicker; we can set up procedures so we can find stuff quicker. So we have to design it, we have to create it, we have to put it on a server, and we have to maintain it. Databases require constant maintenance. You're constantly reindexing because the data is changing constantly. So you're constantly defragmenting the database, you're constantly tuning it up, you're reindexing the tables, and you're resetting security so that only people who are supposed to get in that table can. Maybe you're creating views so that some people in HR can see all the employee information and other people can only see some of it, like the salary or other designations or Social Security numbers or private information like that.

So as an IS auditor, you need to look specifically at whether they are maintaining the database, how well they planned and implemented the security, and how well they are updating the security. Because, as I tell you, it is so frequent that people come and go out of job roles, and then you've left them in as a system administrator or a database administrator or someone who has the ability to change the structure of a table. You've got to stay on top of all of that. which is why it's better to put people in groups and give the group the right, and then you take people in and out of groups. Here is an example of a relational database management console, but I'd like to actually show you one live.

CISA certification practice test questions and answers, training course, study guide are uploaded in ETE files format by real users. Study and pass Isaca CISA certification exam dumps & practice test questions and answers are the best available resource to help students pass at the first attempt.