Pass Isaca CISA Certification Exams in First Attempt Easily

Isaca CISA Certification Practice Test Questions, Isaca CISA Exam Practice Test Questions

Want to prepare by using Isaca CISA certification exam practice test questions efficiently. 100% actual Isaca CISA practice test questions and answers, study guide and training course from Exam-Labs provide a complete solution to pass. Isaca CISA exam practice test questions and answers in VCE Format make it convenient to experience the actual test before you take the real exam. Pass with Isaca CISA certification practice test questions and answers with Exam-Labs VCE files.

Lesson 1

7. Internal Control Classifications

We've talked about risk and what constitutes a risk-based approach to auditing. Let's now talk about controls. And when we think about controls, don't think that controls are simply antivirus software, screensavers, locks, and eight-character passwords. Controls really are all about having policies and procedures in place, which we can then enforce in a number of ways. And when we talk about controls, there are sort of two general objective categories. One is internal controls; the other is control objectives. Now, with internal controls, these are not IT-specific, but they're for the business in general, and they would be protecting the IT assets. But from a business perspective, they would be making sure people are in compliance with the company policy or the government regulations. They would be access controls, not so much like system computer access or network access, but just like access in general, like controlled access into a building with people using badges or man traps or keyed access or something like that. It would also include confidentiality, which largely falls under the purview of IT, but in general, the confidentiality of our data as well as its accuracy or integrity. Now, a lot of these, of course, are achieved through specific methods. If we look at the information systems control objectives, these are much more specific. So like the security of the operating system, the security of an application and the application that we use, or the security of our database and the data in that database, or whatever our data system is, or security in regards to user authentication. Ensure that users are in compliance and that technical controls, such as operating system policies that only allow people to logon at specific times or to specific workstations, are in place. Or you have group policies in Windows, or you have access control on files and folders or printers or the network. And also, in addition, when we talk about the ISS control objectives, we're also trying to make sure that whatever company policies we have are enforced, as are any regulations or laws that govern our industry are also enforced.When we talk about internal controls, the controls we have inside are different types of internal controls. So there are three basic types, and these types you'll just need to be aware of. In general, we have accounting controls, which, as the name implies, are financial controls. controls over how the money is handled, the transactions are handled, the information is stored, the money is moved, and how we keep our books and what we report and that sort of thing. We also have operational controls, which means just our day to day.What do we do day-to-day to run our business? And then we have administrative controls, which is how we know from an administrative or management level that what people are supposed to do, they're actually complying with. And administrative controls require that you actually kind of act like a police officer. Administrative controls are less technical in nature, as opposed to making sure that people are following procedure and policy. Now our internal controls have different classifications, and you'll be expected to know the difference between these. We have preventive controls. Let's not allow this breach or whatever to happen in the first place. And how can we do that? Well, we can hire the right kind of people, we can train them properly, and we can have physical access control, so you can only get in with a key card or knowing the particular sequence. We'll also have detailed security policies. When I talk with a client, my first question after I get familiar with how they operate is, "May I see your security policy?" And that will then tell me not only what it is they're trying to do, but whether or not their policy is adequate for what they are doing. A security policy can be as simple as a one-page document with a couple of sentences, or it can be 100 pages long with sections for everything from wireless access control to door locks. A preventive policy is what we have in place to keep problems from occurring in the first place. And so we'll need not only the policies, but also things like, well, we're encrypting the software to protect it, we're using BitLocker on our laptops, we have NTFS permissions and print permissions and share permissions, and we have rights management systems. So we have preventive measures to prevent people from getting into places they should not be in the first place. So that's preventive. The next one is the detective realising we can't prevent everything because we can't imagine all of the scenarios upfront. So, how can we tell what controls we have in place to detect it if we didn't catch it right away? How can we detect it as it's happening? So this would include, of course, intrusion detection and intrusion prevention. It would include, as we're going through some production line checkpoints to make sure at this point, are we good? At this point, are we good? Also, are there any statements, such as in this case, an example of an overdue statement report, so that money owed to us doesn't slip past our notice and we can catch it fairly quickly? Or activity log reviews? I mean, in larger organizations, you have security officers; all they do is review logs, so we want to detect who's been accessing what. So these are detective tasks, and if you're going to be detecting things, then of course you need to have corrective controls. Okay, we detected something. Now what are you going to do about it? Well, some of it can be automated, like our intrusion prevention. Intrusion detection is detecting abnormal traffic on the network, so it will automatically create some firewall rules. Of course, you must exercise caution when using automated correction, but the correction can also be, Hey, the horses are gone. There's no point in shutting the barn door. What can we do now? So we have a contingency plan, we have disaster recovery, we have good clean backups, or we have ways of preventing this from happening again. So these are the internal control classifications. And then when we implement our controls, what types of implementation are there? Now realise that a control is not merely a technical thing. Like, you have to have a password that's so long, or there's a group policy on Windows. A control is any policy, procedure, method, technical implementation, software, product, or physical something—anything to help minimise and mitigate risk and keep it at a manageable level. That's a control, and it really starts with a policy, which really starts with an attitude at the very top. It starts with corporate culture set by the people at the very, very top, and then it goes all the way down. So when we talk about control implementation types, there are general controls that we implement, and then there are IS or IS-specific controls. And those general controls, well, they can include things like day-to-day operations controls. Okay, you guys have to come in and clock in. You have to take a break at certain times. You have to do certain things. When you start up a computer, you have to go through certain things in order to install something. You have to go through an approval process. So we have controls for just operations. There can be financial controls, of course. So, like, you have to collect the invoice; you have to stamp it; you have to enter the transaction. You have to have names and signatures and dates and times. You can also have administrative controls. Okay, I'm going to review my employees regularly as a boss regularly.I'm just going to kind of check and make sure everyone's doing what they should be doing. Not only so they can be productive and help them in case they're not quite doing as well as they should be, but also just to see if we've had a little bit of slippage. Maybe people aren't quite following every procedure that they should. And, of course, it depends on your industry. If you're in the nuclear industry, there are going to be extremely rigid controls. If you're in health, like what I've worked in, there are some very clear controls to protect patient privacy and data. There will be administrative controls that the manager has to also follow. You can also have them do things like general access controls. People must enter the building by swiping their badge, and they must not tailgate or piggyback behind other people. And there, of course, will be physical security. We'll have cameras; we'll have guards; we'll have locked doors; we'll have lighting in the parking lot. We'll have certain heights of fences and shrubbery and things like that. So, for the IS-specific controls, that is our general control implementation. These secure all the functions, of course. So these are the things we expect from an IT perspective, like, what controls do we have in place to make sure that the applications we develop don't have too many vulnerabilities? And there are tools you can use to check your code. What do we have in place to make sure that our network, our operating system, and all our servers and workstations are as secure as possible? Well, there are best practices. Microsoft has identified the best practices. There are access controls we can put in place—authentication, locking things down, turning off unnecessary services. So these are our more "it type controls," as well as our operational procedures. How do we allow people to connect to the network? So the wireless has to be WPA to enterprise, and we'll have network access protection when you come in from the outside, and you'll have to use a smart card or an RSA token to create a VPN. We'll have these kinds of very specific access controls. So realize, if you're a technologist like me, that controls are not just about setting password policies and requiring smart cards. They're also about what do we doon a general level non It based. And that could well fall within the scope of what the auditor has to take a look at. Now we talked about risk based auditing. Let's talk about the different general types of risk. Here, we only have the overall risk of the thing we're looking at and how we can reduce it. And also, the audit itself is going to have certain amounts of risk. Certain amounts of risk There will be things that are preexisting that we will not catch, just as there will be things that we will not catch. There will be the problem of a client who is not very cooperative. So there are all sorts of risks inherent in the audit process itself. The audit process itself may not be 100% effective, and you have to be very upfront about these risks. And when you have your report, hey, these are the things we ran into. We couldn't get certain departments to cooperate; we couldn't get cooperation on this and that. You have to realise that controls have risks, and there are inherent risks—risks that you just come with, like management overriding policy. That's a huge inherent risk. Yeah, okay, two people are supposed to sign this check and you're supposed to go through a process, but if the company owner says, "I got to go take a check with me," who's going to say no to the guy? Right? Or also, our industry is changing so often that we can't help that. Or people have bad judgments, or there's collusion between two employees working together to perpetrate some kind of fraud. So there are all kinds of inherent risks that we have to document as best we can, but we accept that they're outside of our control. And then, of course, there's the risk that the controls are inadequate or not doing what they're supposed to do. And there's the detection risk as well,that we're just simply not detecting whatwe're supposed to be detecting. So we now understand the process of identifying risk. We understand that there are all kinds of controls that attempt to mitigate or minimise those risks. and the controls can be administrative or very technical. They can be general or they can be very specific, and they can be preventive, detective, or corrective. And that there are risks to the audit itself, risks that we won't find anything, risks that we start with, risks that we can't help but are out of our control, inherent risks to this type of business. So we have to just be clear about documenting all these things so that we know the limit and the scope. So the next thing, now that we know about the risks and the control objectives, let's talk about the planning.

8. Planning

Well, we've talked about risk and controls. Let's talk about planning for that audit. Remember how I said you don't just go charging right in there and checking things; you're going to, to some degree, disrupt the business operations? So you need to plan so that you can do things as effectively and efficiently as possible. Maximizing your time, their time, the resources you have, and planning so that, well, if they can only get things, maybe records, out of storage at a certain time, you're prepared for that So you have to plan. And the planning needs to involve the cooperation of the managers whose departments you are auditing. So when we talk about planning, the first thing is that management confirms that this is what we're trying to accomplish. These are the objectives of the audit. And remember that we had the audit committee that has a letter of engagement in the audit charter, which basically says what are we doing and who's doing it? Why? What are we trying to protect, and who's responsible? all of that sort of stuff. So we have our objectives clearly stated, and we have the standards that we can go to Isaac's site and use as sort of a checklist to compare our planning against. We also know that ISATA provides us with the procedures and guidelines, and they have loads of other resources too. So we've got all of that in place, and we confirm with management that we have all of this. And realise that when you're auditing, you have both the audit management and the client management that you're auditing as well. So once we have that, theaudit charter is done, it's distributed. And now we're creating a plan, and we may create a short-term and a long-term plan. Now the difference is, in the short term, what are we going to accomplish in one year? I know it seems like a lot, but you've got a large organisation that's very busy trying to get stuff done. They plan months and months—even years—in advance. And so you can't just say, "Well, in two weeks, you've got to give them a fair amount of time to comply." And you've probably seen in cases where there have been large things like HIPAA that years were given to organisations to comply simply because it just takes a while to move something that big into all of their processes. So what are we going to do within a year? That's our short-term planning and then our long-term planning. Are we doing any auditing that is going to be directed at something that's much bigger? That's going to take more than a year? Is it going to have a much bigger impact on the overall IT strategy of the organisation that we're auditing? And now who is going to do what? When we plan for our audit, the first thing is, of course, to know the business mission. And when we know the business mission, we'll know whether or not their controls and their whole framework for minimising risk are in line with their business. And so we have to determine what the requirements are for how they process information. We have to ask to see all their policies and any standards they have. There may be industry standards, there may becompany standards, as well as ISACA standards andother standards, there may be government standards. So we need to see all their policies, all their standards, and all the standards and policies that are relevant, as well as the regulations that are relevant to them. And then we have to do the risk analysis so that we know what we're targeting, and the risk analysis should support what it is that we're auditing. And then we have to look at what are allof the internal controls, have to know the scope andthe objectives of the audit, the objective of the audit. It might be very specific; it might be to determine if our method of writing software is sufficient and if we have done enough tests on it so that we have reasonable assurance that the software is reasonably safe. So it could be really specific or it could be really broad, like we're going to look at all your books. So, for example, we must define the scope and objectives. And that's something that, when management hires you, that's what they're stating. So you need to know what your objectives are, what the scope is, and then, of course, how we are going to approach it and who is going to do what. And personnel, resources, and logistics? Well, we need one person who can pen test the servers; we need another person who can check code; we need another person who will interview different people. And you have to look at differentpeople with their different kinds of strengths. So you probably wouldn't hire people who are adamant about looking at lines of code. They probably don't have the same skill set as people who know how to chat people up and get people to describe what they do. Because you got to realize, folks, when yougo into audit, you're going to be viewedwith suspicion at best, resentment probably. And so you're going to need to send in your most skilled people when it comes to actually chatting with people—to just chat generally with them while at the same time being professional and respectful and mindful of the fact that you can't waste their whole day. You need to get the information you need. Obviously, you need to be able to be firm when you need to look at logs or records. And that's why you need the charter to give you the authority to do whatever you need to request. And it has to come from the highest level. So when you plan, you need to determine all of these things as part of your plan so that you know ahead of time. Okay? Today we're going to go after these things. Tomorrow we're going to go after those things. And also, at the end of the day, you should always have a debrief. The project manager, whoever the auditmanager is, and everybody gets together. Okay, did you achieve this? I had a checklist. No, I wasn't able to they weren'table to get this out of storage. So and so was sick today, whatever. Okay, we'll roll these into tomorrow. And the project manager, the audit manager, has to be on top of all this to know that you'll be done with your audit in two weeks, or whatever your audit period is, or three days, or whatever your time period is. Obviously, you have to be looking at what laws and regulations are relevant to that industry, and are they in compliance? So we need to determine, are there any external requirements, or do they deal with health informatics, where they're going to fall under things like HIPAA? Do they deal with finances where they're going to fall under things like Sarbanes-Oxley? So what are the laws and regulations required, and are there any external requirements when creating policies and standards and procedures? Well, Sox requires that the company have due diligence, and so they did by creating a policy and training people to do whatever was appropriate to them. So you need to also understand this industry, and then through the planning process, we start by understanding the business and its environment itself. If you're used to auditing one type of business, like maybe health, you're not going to be taking a senior position. That's technical. When you're auditing nuclear facilities, you'll have skill sets that can be used. But we have to analyse the business. We have to understand we have tounderstand what risks are relevant to them. To identify the risks, you'll also need people who understand the industry and the management with whom you work. And then you develop whatever your audit programme will be. So this is all stuff that you plan in advance, and you don't do it in just one meeting or just a couple of days. Once we have our planning, we must remember that everything we do in the audit needs to achieve an objective. So the big thing is that ultimately, everything that we're looking at, we have to see if all these processes, these IT technologies, and these operational procedures support the organisational goals and the business mission set by higher management. That's really what we're looking for. And are there internal controls inplace to minimise the risk? And we need to verify that we are not overlooking any regulatory requirements or legal requirements and make sure that those are all fulfilled. So these are our objectives when we're doing our audit. Now, when you do the audit, there are different kinds of audits. Obviously, there's a financial audit where I say, "Let me see your books, let me see your invoices, let me make sure that your financial statements are complete and accurate, and that you haven't been cooking the books, hiding anything, or simply thinking there are supposed to be tonnes of receivables." How come we didn't? We're down 20% and yet we've had all this business. Well, let's audit and find out what happened. We let invoices go so far out that people lost track of them. So there are financial audits and operational audits, and operational audits are really day-to-day controls in place to ensure that the business is running properly. And there are many large firms that will do an IT audit before they do a financial audit because, if you aren't maintaining the integrity of the data, how can you have a good financial audit? So we can have that. An integrated audit is basically both. Do we have day-to-day controls in place, and how well do they protect the books? The administrative audit is basically howdoes the organisation running in general. And so are there management policies in place to make sure that people follow whatever they're supposed to follow? And then there's, of course, the very specific technical aspect of audits. Okay, we did a vulnerability scan and a pentest, and we did a port scan and checked for weak passwords and checked for open access points and that kind of thing. Let's audit that specialised if you're engaging an external party, a third party, to manage some of your controls. Let's audit them. Let's audit their effectiveness in controlling your assets. So, for example, if you're going to move a bunch of data or a process to the cloud, let's audit that. How well are those folks who are managing the cloud, managing your software as a service, your infrastructure as a service, whatever, protecting your data, your assets, and your functionality? And then finally, there's forensic auditing. Let's figure out what happened. Some major event, okay, let's piece together everything that led up to this and figure out what caused it. And so, that's forensic. So there are all these different types of audits, and you're not necessarily going to do all of them. You'll probably zoom in on one or two. Maybe you'll do an operational or an integrated check where you first check the controls and then someone else checks the finances. So different types of audits. So to kind of look at all of this, when we're planning for an audit, we have to determine if our plan is going to be short-term, one year, or long-term, more than that. Because this is a much bigger thing we're looking at, and we may have to plan for both. Are there any laws or regulations that they may or may not be aware of? We have to do a business analysis, we have to do a full risk analysis, and we have to develop this full audit program. We're looking for controls basedon our whole planning process. We need to know what are the objectives and the scope of the audit, and what type of audit is it? And then finally, we have this plan together. We communicate the plan with the management of the folks who are hiring us. So with that, we have the audit planning process. The very next thing we're going to talk about is the methodology.

9. Program

Well, we've talked about planning. Let's now talk about methodology. You have done all of the planning ahead of time. Now just implement the first thing in your methodology. You've got that charter, and you're going to have a document. You're going to have a methodology document that basically contains programme information. The programme information is just, okay; what are we trying to accomplish and how far are we going to go? scope and objectives. And that is communicated to all of your team members who are doing the audit. You've already allocated the resources; you've communicated your whole plan. You've gotten, at least in theory, cooperation from everybody. So you have a document and you say, "Okay team, you do this, you do this, you do this." And we'll connect together tonight, and we'll debrief to see how we did. So we start with our methodology document, and then we have our work program. and this is basically based on our strategy and our plan. Our whole plan is that we're going to pen test the network. We're going to do a vulnerability scan on the servers. We're going to make sure that people are following procedure in terms of locking workstations. We're going to make sure that passwords are complex. We are going to make sure that people are changing passwords. We're going to make sure that there aren't any accounts that are three years old; no one's been there. So we have a very clear document on what we're trying to do, our entire approach. Okay, you have the best sort of method with people. So you're going to chat people up a bit and just find out how many people are tailgating—are they propping open the server room door? Has anybody been getting into the telecom room or whatever? And so we've got this whole strategy and planthat we are now implementing the whole process. We've planned for it already. We know for what it is that we're auditing the subject. We know our objectives. And the objectives again are based on what management is trying to accomplish. And we're going to help them find out whether or not they are accomplishing it. We know the scope. It's only this town. It's only this department. It's only this process. It's only this department. It's only this particular set of servers. It's only something very specific. We have our plans together. Now we are gathering data. We go through our whole methodology. We start asking, we look at logs, and we do pen testing if that's part of it. We look at procedures. We start with, "May I see your policy?" May I see any procedures and any documents that you have people follow, and we can look and see where the procedures are posted? Do people know? Are they being trained? Once we've gathered all of this data, and the data will be evidence, and it can be evidence of compliance or noncompliance, then we evaluate, and remember, we're gathering facts and providing an informed opinion, but our informed opinion is always substantiated by very clear, hard evidence. And then, once we have all of that, we communicate our findings and our results and our recommendations, and we have our report, which is our deliverable. And it will probably also include some follow-up, maybe in three months, six months, or one year's time. As you're doing this, you will be on the lookout for fraud. You should remember how we talked about going in with some professional skepticism? You don't take anyone's word for it. They're doing something. You actually go and observe them, and you try to observe them in such a way that they haven't had time to clean up their act before you walk in the door. And so you must recognise that the chances are very good that you will uncover not only people cutting corners or simply not doing something the right way because they didn't know they weren't trained or whatever the procedure was, it wasn't disseminated properly, but also people deliberately trying to hide things or two employees colluding together, collusion where they're acting together. So you will be looking at this now when you come across this. This is where you have to be extremely professional. You need to report that to management. You need to gather material evidence of the fraud, and it's up to management to determine what the fraud mechanisms could be. But you may discover them, and you must provide due care when performing this work because if you're going to say, Yeah, I saw people stealing this or whatever, or I see evidence of it, it's just got to be the facts. You've got to provide just the facts. And you may hear all kinds of gossip, and it's good to hear gossip because it can alert you to things. You need to also realise that you have to have material evidence to substantiate gossip because who knows why people are gossiping? They could have all sorts of their own agendas, but then again, you could have people gossiping and something really going on that management isn't aware of or is actually trying to play down. So realise that there will be fraud detection in yourwork and as you do that, as you are awareof that, you need to collect substantial material evidence tosupport what you've seen and it is just the facts. So, for conducting your audit, we began with a plan and reviewed the entire plan with management. We got them to agree to cooperate with us. We determine how we're going to approach this. And again, there's no one set way because there's no one style of business. Which individuals should you interview? What departmental policy standards and guidelines should you be looking at? You want to look at all of them, if you can, and identify ones that you were not able to look at. Identify the tools or methods. So I used this particular pen test tool and this particular port scanner, and I reviewed logs. As a result, you can pinpoint exactly how you did things. And once you've got all that, you evaluate all of your findings. You document all of the activities that produce the results. You gather any evidence that you need, and you then create your report. You then communicate the report to the right people. And then, if necessary, you have a follow-up that is conducting the audit in general. Now, remember, Isaka has those guidelines and those procedures. You can look at those, and they're very specific ones. They go very deep and are very specific for very specific types of audits. So depending upon the audit you're doing, you can look that up on the ISACA site. Some of them require you to be a member in order to obtain a copy. And so, anyway, follow these things. The next thing we're going to take a look at is the evidence itself.

10. Evidence

Alright, we've talked about how we can conduct our audit. Now let's talk about gathering evidence. Remember how I said when we are auditing, if we are going to provide a report and say, "Okay, these things are out of compliance with company policy, regulation, or what you expect or what you're trying to do," we have to have evidence that proves that this is the case, and we gather the evidence so that we can substantiate what our final assessment is. So when we talk about gathering evidence, there are actually a number of ways to gather evidence. And we can see here that evidence can be gathered just by watching, just by observing, just by talking to people. and the notes from our interview by looking at the documentation itself. Well, according to the documentation, people should be doing it this way with these steps. Well, I observed it that way, and when I spoke to people, it was even another way. looking at contracts, okay? In order to provide whatever level of service, your contract states that it should be this and this. Well, I observe that, that, and that, and also any other agreements besides just purely contractual ones. also the outcomes of procedures So these are different ways of gathering evidence. Now, remember what we talked about earlier—that evidence must be relevant. So there's a concept called materiality. How significant is this breach, this misstatement in terms of materiality? Is it very significant? What kind of impact does it have? What is its level of materiality? We're interested in collecting evidence with materiality to it.And so we're looking for how significant the error is in the procedure, the process, the system, the job function, and the organization. Because it needs to have some substance to it. Now, evidence, when we collect evidence, itcan go through a whole life cycle. And you should be aware of the life cycle. And you should also be aware that evidence needs to bepreserved and handled and documented properly or it may not beadmissible if it comes down to going to court. So the first thing with evidence is that we discover and recognise that, "Hey, this is evidence," we collect it, and we protect it. And if it's really material evidence and you're looking for outright fraud and criminal activity, you'll have to follow a whole procedure. It'll have to be bagged and tagged. And two people are there, and there's always a person who's in possession of it, and it's sealed in a way that it can't be tampered with, et cetera. So we have to protect it. We have to record the fact that we have it, with complete descriptions. We collect it, we identify it, and we store and preserve it. The main thing is that you want to make sure that nothing happens to the evidence, because if it's been tampered with, then it's no good. As we transport it, we have to make sure that it's securely transported, and there are handoffs with logs and everything. So there's no question; there's no, like, there are a couple of hours we can't account for because the evidence was lying in an open door, a room with an open door, or something. And then we will possibly present the evidence in court, and then we may return it. Now, in the case of computer evidence, one of the things you're going to run into is you may have to confiscate a server. I mean, law enforcement will probably do it for you, but there will be cases where this computer is evidence and people go, "I can't function without it; I need the server to do whatever." So it kind of depends. If the evidence isn't so criminal, it could be a copy of a drive, or a copy of processes, or whatever, so that the business can continue to work with the original. Or sometimes it can't be, and sometimes you take the original evidence. So it just kind of depends on what degree of criminality we should use. So anyway, the evidence can go through this whole lifecycle, and it's up to you to make sure that it is gathered properly, documented, properly preserved, not tampered with, and potentially then ultimately returned. Now, the gathering techniques. We talked earlier about gathering techniques. So we can review procedures; we can review documentation; we can review standards. Mostly we're looking at what do you havein place already, what do you have written? Anything from contracts to procedures to manuals: what are people really doing? And we'll interview, we'll observe, and we'll look at the results. Okay, so you say that you're producing 20,000 widgets a day. How come when they do an inventory, there's only 15,000? Now let me go and see why. And it may not be fraud at all. It could just be that. Now we see, in our automated system, there's a glitch in the counting mechanism. And so we will interview people andwe'll observe and we will observe performance. We'll observe procedures and processes and how people conduct their daily work. Now, when we talk about testing, there are two kinds of approaches. There's compliance and substance. With compliance testing, you're really looking to see: are controls in place, and are they verifying that the controls are there? And so you'll probably do three things. You'll probably first just chat up the person and say, "Hey, how are you doing your job, okay?" And then you'll see if there are any controls in place, and are they adhering to them? And so you'll just chat and you'll verify that, yes, there are controls in place for people logging on, entering, closing doors, starting up equipment, or whatever. And then, once you know that there are controls in place, you can then drill down into that control and see if it's really working. Is that procedure, counting system, or software (or hardware) or device really doing its job? And that's substantive testing; we're looking to see substantially if that control is functioning as it should be. So we have these two testing methods. Now, evidence can be really reliable and really useful, or it can be just junk. And so the factors that make it more reliable are, first of all, how independent is the evidence? Did it come from an independent source? If it comes from someone within the department with an axe to grind, then it's not very independent. But if it came from a third party vendor who said, "Yes, I have this," or from another auditor, or from someone who is not involved in that department, that company, or that process, the more independent the source, the more reliable the evidence is. Also, what were the qualifications of the person who gave it to you? For example, if I get evidence from a doctor discussing a clinical procedure, that person has far more qualification than someone who is not a doctor discussing it—say, an accountant or a plumber—that person does not have the same level of qualification. So what was the level of expertise and qualification of the person who provided it? So did the evidence come from an independent source that makes it much more reliable? Did it come from a qualified person with a certain level of expertise? Do they know what they're talking about? Also, how objective is this evidence, and when did this evidence come about? If this is from ten years ago, it had better be about a case that was relevant ten years ago, as opposed to us trying to find out why this week the production line didn't produce 20,000 widgets. We don't want to necessarily look at five-year-old data. So we're looking at the independence, the qualificationof the person who produced it, the objectivityof it, and also the timeline. There is always a chain of evidence. Whenever you collect evidence, there's always got to be a very clear, as I said before, chain of ownership. There can't be any gaps. Like, we can't say, "Well, we don't know where this evidence sat or who handled it for a 24 hour period." It's got to be very clear that this evidence could not have been tampered with along the way. There is a very clear chain of ownership. Now, for common rules of evidence, make sure that the evidence is reliable, make sure that it is relevant, make sure it's been well preserved, and make sure that it was properly documented and identified. And of course, is it legally permissible? In the case of computer evidence, computerevidence is considered hearsay because it's soeasy to falsify and tamper. Computer evidence can be considered to be corroborated evidence for expert witness testimony. And so you realise that just because I found it on someone's computer, that alone, by itself, could have been placed by somebody, or I could have created it. So computer evidence by itself is considered at the same level as hearsay evidence, and at best it is cooperative evidence for expert witness testimony. In computer forensics, we're trying to find out what happened. It was not always the case that it was criminal activity. We're just trying to figure out what on Earth happened. Let's look at the software. Where did it break down? Where did the system break down? How did the hackers get in? Where did the network break down? So we're looking at the software, but we'll also probably take a look at the system itself. We might even copy the drive. We'll probably even capture the running processes before we simply unplug the machine because we want to see what processes are running. We'll also look at the network traffic itself. Let's see what traffic came across the network. And then at that point, once we've captured it and we know that we've captured all the running processes, we'll shut down the system and then preserve it so no one can go in and wipe out the hard drive or tamper with timestamps. So when we do computer forensics, if you're going to do this and you're going to take people to court, you have to treat it like a crime scene. You take pictures, and you bag them up. Don't do this yourself. Get law enforcement. Get somebody who is highly qualified. And because it's just you doing it, people get upset that it was mishandled and that there wasn't a good chain of ownership. So handle computer evidence with caution and defer to law enforcement or whoever is qualified. Of course, if you're going to court, if you're not going to court, and you're just trying to figure out what happened, you're probably best served by copying the drive, looking at running processes, and dumping it all. There are plenty of tools that you can look at on the Internet that will do that for you. They'll copy out via a USB port, a serial port, or whatever to capture the state of the machine as it is at that moment. Now, there's this concept called sampling. If we're trying to look at hundreds of thousands of transactions, we just can't look at every one, we just can't.So what we're going to do is just take a sample that is representative of the whole population. And the reason why is because we just don't have the time. Of course, obviously, the larger the sample, the more precise it will be and the more representative it will be. So when we do sampling, we use a smaller subset of a larger group to gain knowledge. We can do statistical sampling where we can say, well,we checked 10% of the total population, we looked at10% of the transactions and we found X. We can also conduct non-statistical analysis. You might say, "You know what, I don't need to just look across the board at 10% I, as an auditor, know that the most likely place will be right there. So I'm just going to go right there. So that's nonstatistical. You use your own judgment and different sampling methods. We can say, "Okay, just look at 10%, 20%, 5%, whatever, fix the sample size." Or just go until you find something, and you don't need to go any farther. We found it. Stop and go. We don't need to go any farther. Or discovery. Look a lot deeper because there might be some very small instances of fraud. They might fall under your normal radar, but look really deeply. Or we might do something called a variable method. Don't just look at all the population. Look at the things created by the night shift versus the things created by the day shift. When you stratify, you look at a smaller subset, and then you evaluate those smaller subsets. Or you could just say, "No," to everything that was created by all the shifts last week. Or you can look at the difference. You can say, "Okay, unaudited, supposedly 20,000 widgets came out, but when I did the audit, only 15,000 widgets came out." So you look at that difference. So these are all different ways of going about doing sampling. So when you collect your samples, obviously, you establish the objectives. You decide: What is the population? In other words, a thing you're sampling What is our method? We talked about them earlier. How big is the sample size? We'll do 10% at random. We'll then select our audit sample. We'll do the audit, and then we'll evaluate the results. So that is how we gather evidence. The next thing is, what do we do once we have all of the data results?

11. Audit Control Evaluation

You've gathered the evidence; you're forming opinions. The final result of your audit is a report that you give to upper management or whoever hired you to audit in order for them to figure out what to do. going to give them recommendations. So as we're preparing to do our post-audit control evaluation, we're going to review the evidence. We're attempting to determine whether the controls, policies, procedures, technical, whatever, software, hardware, physical, environmental, and whatever else they've put in place are effective. Are they effective? Are they meeting business objectives? I mean, that's really the bottom line. Do they have controls and are they meeting business objectives? Are they being implemented effectively or properly, or are they just not meeting the objectives? And we report on these strengths and weaknesses. Now, a report can be just a few pages or it can be hundreds of pages. It really depends upon what you were auditing and the depth to which you're expected to report. But they all have some commonalities. They'll all have some kind of introduction with an executive summary. They'll have you look at the findings, they'll have conclusions, they'll have determinations, and then they'll have detailed lists. Let's actually go take a look at some sample reports just so we can kind of see them for ourselves. Here. This is Global Information Assurance. And we'll take a look at this example here; this is an example certification paper. And so we can see that this is actually a sample of a very specific audit. And we can see that there's a table of contents. It has an executive summary. This is what we did. These were the potential vulnerabilities were.These are our recommended actions, short-term, medium-term, and long-term. Then we specifically looked at physical security and network security. We looked at disaster recovery and backup. So we specifically looked at these administrative procedures, the use of root privilege or admin privilege, and how that was secured. And so, then, we can see all of the details.

And when we go farther, we can see that there were appendices here with the objectives for the controls and the audit guidelines. Here were some printer vulnerabilities we were looking at. This next one was writable files, exceptions, and additional file recommendations. So then it goes through. And here's our executive summary. We did this on this date. We were looking for these specific things. We had these specific objectives. We were looking at formal and non-formal security procedures and policies. And to ensure that contractors, employees, and visitors all adhered to the specified policy, we were looking at physical security, network security, and security on individual servers. And there's a little bit of background there. Our procedure was outlined in Appendix A. We used it based on our scope of objectives. And we also use some network scanning tools. We saw these particular potential vulnerabilities, and we have these recommended actions. And so then the rest of this goes through exactly what they did, how they did it, and in detail. And they will even have some diagrams, like a network diagram. And going further on the description, they have a description of their perimeter hosts and the scanner that they used, what they scanned, and what they were looking at. So here is an example of a very specific report. Here's another example produced by a different organization, and it's written maybe a little more formally: the Customer Information Security Audit Report. We're going to scroll down a little bit to see the acknowledgements, which include the authors, reviewers, and publisher. Let's go down a little bit farther. Take a look at the Executive Summary. Here is the table of contents. It starts with the executive summary, which is what it should have, showing the core assets and the risks. Remember how we talked about identifying what it is we're protecting and what the risks are to that? Also, what is management's knowledge and awareness? Because remember, if we don't have support from the very top, this just isn't going to work. and also a summary of the primary security threats. Remember how we talked about identifying the threat level with those various risks once you know what you're protecting and the risks?

And then we have compiled recommendations, the scope of how much we audited, the methodology that we used, how we scored the risk, and then our whole approach. And then the findings about specific things So we have findings about the current security policy, how the information security department was organized, how they manage assets, how they do HR security, and so on. Are they training people? What security awareness are they giving people? physical and environmental security, communications and operations management, access control, information system acquisition, development, and maintenance. Okay, so did you write some programs? How did you buy these things? How did you evaluate them? How did you put them into production? How did you maintain them? And how did you manage security incidents and business continuity? And what is your compliance level? So this particular report is a lot more formal, a lot more formally structured, and it has all the elements that we talked about earlier. This is your deliverable, folks. This is the thing that you're trying to produce. But ultimately, what you're really trying to do is give management something to act on. And you're working with management, and you're working with the teams, and you're working with them so that they can do business in the best possible way. And that's really your job, not to just go barging in and say you're doing something wrong. You're there to help them. And you need to make sure they understand that. Now, very often it is the case that upper management is trying to hide something, they don't believe something, or they've hired you to prove something that isn't true. I mean, that happens all the time. And your professionalism is required when dealing with that kind of thing. And it's not for you to make judgments, except to come to conclusions based on what you find. And then it's really totally up to that management or your client to do something about it. However, you might also be expected to comeback in three months, six months, a year, whatever, to see if they are in compliance. You might have been hired by someone to go and double check, go back in six months, and see if those department managers have implemented what you recommend.

So our audit report is going to have those things, the introduction with the summary, the findings, the conclusions, what we determined, and the detailed findings as well in our documentation. Of course, we developed the documentation at the end, but that was based on how we started this whole thing. Our whole planning and everything that we do is supported by the evidence and conclusions made in the report. We have to support our conclusions with evidence. And the documentation, of course, should be stored safely. You shouldn't just be lying. You're having it lie around. It should be locked up. It should be delivered carefully. You'll frequently deliver a printed copy rather than an electronic copy, and it'll be the only one or whatever else is kept very safely and securely. So the components of the audit documentation are what we talked about: what was our strategy, what did we do, what was our planning? We'll have our observations and our notes—and how did we do this? Were there any laws and regulations involved? What were the activities we did, and what did we find? Did we use any external services? What are our follow-up activities, conclusions, and recommendations that we finally put into this report? that we hand up to whoever hired us, basically upper management. Once we're done with the audit and our post-audit tasks, we have the assessment of the findings, we talk with management, and we show it to them. Here's our review, and we have our exit interview. And we may, of course, have some provision to come back as well. When you report, you've got to realise that they're not necessarily going to want to hear what you have to say or that they hired you to say something that isn't true. That happens a lot when you are sharing the reports. Here's where you've got to have your most tactful people work with people. Sometimes you have to kind of negotiate with them to get them to be willing to accept the bad news. The old saying goes, "You can catch more flies with honey than vinegar." So tact and professional courtesy are required. You realise that this is the part they don't want to hear. that the part that they were hoping for would be something different. Sometimes you have to kind of negotiate with them to get them to understand, and you have to work with them. Sometimes you're a facilitator between management and the department, helping management and the department come to an understanding on how to improve processes. And you're the facilitator. Sometimes you're just doing conflict resolution. So this is where it takes a lot of people's skills and a lot of professionalism.

So just realise that if you're the project manager planning this, you're going to take your most senior and most people-oriented person and basically deliver the results. Now, the folks who are going to get your report are going to be the senior management who hired you, the key stakeholders, the board of directors, whoever, your own audit management, the audit committee members, the folks who first wrote up the charter, and the engagement letter, probably comprised of board members and whatever managers manage the whole audit activity. Those are going to be the recipients of your audit report. It is ultimately up to them to do something about your findings. Now, you may indeed have follow ups.You may have to come and see if corrective actions were taken based on your recommendations. And you will almost certainly be involved in the follow-up. How to communicate the issues, the risks, and the results Obviously, you need to be able to present all the evidence and the findings in a sort of nonjudgmental way, just straight facts. This is what we found in a professional sort of manner, and that means you need to be very clear on all the evidence and the findings. You have your detailed report, if necessary. If there are any post-audit tasks, you conduct the findings and assessment of the findings, as well as review your exit interview, as we discussed earlier. You communicate the results to the individuals specified in the audit charter because it should say upfront who's going to receive these results and possibly develop your follow-up program. The last thing we're going to look at in this lesson is how we can help empower the people we've audited to improve their own processes without just simply coming in like a policeman or something and saying, "You did these things." We're going to talk about control and self-assessment? Yes.

So when looking for preparing, you need Isaca CISA certification practice test questions and answers, study guide and complete training course to study. Open in Avanset VCE Player & study in real exam environment. However, Isaca CISA exam practice test questions in VCE format are updated and checked by experts so that you can download Isaca CISA certification exam practice test questions and answers files in VCE format.