IT Audit Fundamentals

1. 1. Introduction: Hello, and welcome to the IT audit Fundamentals course. My name is patient and as your instructor, my goal is to share with you the foundational principles of IT audit. This course is a foundational building block that is important to gaining a better understanding of IT. Auditing and controls tested. 2. 2. Introduction to IT Audit and Controls: Okay, let's get started with the first lecture, Introduction to IT audit and controls. In this lecture, we will cover the following items. We will define IT, audits, defined controls, explain the hierarchy of controls, reasons for controls and elements of controls. We will also review control types and go over several examples to get you comfortable with the concept of controls. So first, what is an IT audit? On the screen you can see what I call the more formal definition of IT audits. In layman terms though, an IT audit is simply an examination of controls that are embedded in and around the IT system. And this controls are evaluated for effectiveness. That means we're evaluating to determine if it is working the way it's supposed to be. Easy mitigating the risk that was designed to address or does it meet minimum compliance requirements? You may be wondering, what is a control? If you do not know what a control is right now, that's okay. Hang on. We'll cover that a little later. One thing I do want to cover here is that when IT audit are performed, they only provide reasonable assurance regarding the completeness and accuracy of data in the IT systems. They do not provide absolute assurance because they are always aspects of the control environment that cannot be accounted for. E.g. automated controls can feel maybe a system goes down. Or a manual control may be overridden by any human being. Or you may have control objectives that are not adequately designed to begin with. It. Audits are not meant to be absolute. They can only give reasonable assurance regarding the completeness and accuracy of data in the IT systems. Alright, next, let's define controls. What our controls. Again, on the screen you can see a more formal definition of controls. But in layman's terms, a control is like a checkpoint activity that is implemented to reduce the risk of an unwanted action happening. The goal of a control is to mitigate risks that can hinder the company from achieving its corporate objectives. The risks could be compliance risks, operational risks, reputational risks, or even financial reporting risks. So the control is the activity that is implemented to reduce that risk. Now, let's talk about key controls, because there may be several, even hundreds of controls in an organization. However, typically only a subset of them are considered key controls. Keep controls are the controls that are really vital to protecting the integrity of the systems from a compliance perspective or from any of the other risk area perspectives, as noted on the slide. And you can see their key controls are required to achieve an objective. The failure of a key control typically has significant impact on the organization. If a non-key control fills that sometimes, okay? But if a key control fields, that usually means there's a bigger problems. So let's have an example here. E.g. a. Key control may be limiting access to make changes to the balance sheet. Meaning there's a control that limits individuals that can change the balance sheet directly. If that control fills, it means that the information in the balance sheet may not be reliable because another because an unauthorized individual may have made inappropriate changes. Please, I do want you to note that a deep understanding of controls, how they are defined and implemented is key to your success as an IT auditor. My belief is that you need to understand why you are testing a control before you can effectively designed how you test that control. If you don't understand what the control is protecting, e.g. the balance sheet or invoice payment approvals, the test that you design and perform may not be adequate to address the risk of that control not being properly implemented. Alright, let's discuss the controls hierarchy. This image depicts the hierarchy of controls or control typically exists to meet a control objective. An example of a control objective could be one. Controls provide reasonable assurance that access to the accounts payable system is limited to authorize individuals. Or second one, controls provide reasonable assurance that access to make changes to financial systems is limited to authorize individuals. These are control objectives. In order to meet these control objectives, controls such as user access controls, which limits. Individuals that can access those areas or password controls which determines or mandates that passwords must be used to access those systems. And privilege controls are implemented. Next, I'll control objective is in place to meet an audit objective. An example of audit objective is there is reasonable assurance that the financial statements can be relied upon and are free of material misstatements. Or for PCI related audit, an audit objective could be there is reasonable assurance that system's processing payments adequate, quickly secure to protect customer information. So this audit objectives are the higher level. They are the top level what needs to be achieved. In order to achieve the audit objective, we have to come down to the control objective that breaks it down further. And then in order to achieve a control objective, you need to have the actual controls that are going to help you to meet that objective. And as you can see on the slide, the audit objective is usually the purpose of the audit, what the auditor expects to achieve. And then the control objective is the objectives of management that are used as a framework for developing and implementing controls in order to meet the overall objective. Welcome to the second part of the lecture on IT audit and controls. We will start off with the reasons for controls. So let's discuss why organizations implement controls. Controls are implemented for many different reasons. One that I have here is reliability of financial reporting. Organizations need to show that they have controls in place to provide reasonable assurance that the financial reports are accurate and can be relied upon by public or private keys, the stakeholders. So in order to be able to show these, organizations need to show that they have controls in place to allow that assurance. Another item we have here is compliance with applicable laws and regulations. Controls are implemented because laws and regulations require them to be implemented. E.g. the Sarbanes-Oxley Regulation requires management to provide an assertion on controls they have implemented and tested around their financial reporting process. This is called Eco for internal controls over financial reporting. Other examples include PCI and SSE 16 regulatory standards. This also require controls to be implemented so that they can be tested against as appropriate based on those particular standard. Another reason for controls would be to achieve effectiveness and efficiency of operations. When organizations have controls, certain operational activities are more streamlined and they are better positioned to help the organization achieve its goals. While this may not be related to certain laws and standards, they are still crucial to the success of the company. E.g. there are controls around HR hiring practices to ensure that qualified candidates get hired. Or there could be controls around the protection of trade secrets or formulas. Another reason for controls is they help achieve definable, repeatable processes that improve consistency of operating results. When controls are adequately implemented, certain activities become repeatable and standardized and potentially even automated to ensure the ongoing consistency of processes. E.g. a. Trial balance reports may be reviewed periodically to identify and address any discrepancies in the financial books. Also, you may have reconciliation controls that are implemented to ensure that financial balances are always in sync across entities so that you can quickly identify and address any discrepancies. So you want to be able to check items frequently to make sure that things that are supposed to be in sync or still incident. Last and definitely not the list system security system security warrants that controls are implemented to keep or at least deter bad guys from accessing systems. User access controls, password controls, network controls, example, firewall configuration. These are all implemented to ensure that only users that are authorized and appropriate or accessing systems. So this gives an overview of some reasons for controls. Next, we'll go over elements of controls. Controls should have certain elements in order to qualify as adequate controls. Depending on the type of control, it may not have all the elements listed in this slide. However, it should have enough of these elements in order to be considered adequate. Adequate example of a control. I'm going to read an example out and then we'll go over this element. Passwords are required prior to accessing the system. So this is the password check or another control is access to the system requires a completed user access request form and approval from the manager. Those are controls for specific items in the system. So the first element is, what is a control activity? What is the control activity? E.g. it could be an authentication control and authorization control, a password control, like what I just read out. Access control or books, reconciliation control. Your control has to state what the activity is in one of the examples I read earlier, part of that is the approval of an access request form by a manager. The second element here is how often the control occurs, which is the frequency. It could be hourly, daily, weekly, or even M0. And you could also have an automated control that is just the frequent check. So you want to state what the frequency is. And if there's no set frequency, if it's automated, you want to set that as well. I'll stick that as well rather. Another element is the title the WHO that's performing the control. And if there's any segregation of duties involved, are there any potential conflicts with the person performing the control, the manager approving the form shouldn't be the same person that's creating access in the system, e.g. you want to make sure that you have a separation of duties in place. So you want to state the title of the person performing the control. In an example that I stated earlier, the manager is the person or proven the form, but then access to the system is typically granted by the administrator and you may want to include that into control. Another element here is when does the control activity occur? Is there a specific time of database occurs that's important to note. So e.g. a. Daily review of journal entries may occur at 04:00 P.M. every day before the close of business or does it occur after specific activities? Does it have any predecessors in the process? So you may want to stick this all. You may also want to state something like a temporary privilege user account activity that may take place after a user has locked out. So if there's any specific sequence for that control, That's something that you would consider adding to the control. Another element that we have here is if there are any report document files that are going to be used in performing the control, it may be reasonable to include that into control. E.g. if there is a control regarding user access reviews and you need specific access report to be generated from the system. You may want to stick that into controls so it's clear what that control is about. Or if they are balanced cross checks, account balance cross checks that requires reports from different specific systems. You may want to state that so it's clear which system or which reports are being reconciled. Last but not least, we have evidence that's produced as a result of performing the control. So when the control has been performed, what evidence will be retained to show that the control was actually performed? E.g. that could be a report with the results of reviewing users access or a report showing the account balances that were reconciled. It's something that you may consider including in your control. Now I know we've talked a lot about controls, but one important thing to notice here on the slide, a process is not in control. The process supports the control. The control objective is not the control. The control objective is simply the objective of the control. And last item is that testing is performed over the actual control. It's important to know the difference between a control which is the checkpoint activity and the process that surrounds the supports that control. And then the ultimate control objective that many key controls are going to support. This concludes this part of the lecture and the next part of the lecture, we will talk about control types. Alright, welcome to the next part of this lecture. We'll start off by talking about control types. There are different types of controls, and these are the three main types of controls. You may find other texts or other control types in audit texts, but these are typically smaller categories. These are the main categories of control types. The first one we have at the preventive controls. Preventive controls are implemented to prevent an undesirable event from happening. So these controls are put in place to try and stop something bad from happening. So the development of these controls involves trying to predict potential problems that could occur and then implementing ways to avoid those controls, e.g. passwords, you require individuals to use login IDs and passwords before they can get into systems. Or you can have another list, privilege control, meaning you only give individuals access to what they need to perform their job function. So by doing this, you are preventing potential issues down the road. The next control tab is the detective controls. Detective controls are implemented to identify undesirable events that have already occurred. So e.g. if your preventative control was not able to stop something from happening, you want to have detective controls in place so that you can actually identify if something that already happened. So this could be a periodic review of usual access to make sure that only the right individuals to have access. Or you can have several alerting and event management controls in place that notify when issues happen. So these all fall under detective controls. And the third category here, the corrective controls. Corrective controls are designed to correct errors or irregularities that have been detected. So if you already have issues that are ongoing and you are thinking of ways to fix them. That's when you bring in corrective controls. And one good example for corrective controls is the user training or retraining. If you identify that user error is the reason why a lot of preventative preventive controls are failing, then you may want to retrain or train users if they were not initially trained. Now, let's go over some control examples. The examples I have on the screen here are in no particular order, so we'll just go through them. The first one on the screen is access authorization. And the control. User access to the application must be authorized by the individual's manager prior to access being granted. Here you'd see the control element that talks about what the activity is, which is the approval or authorization by the individual's manager. And you understand that that should occur before the user access is actually granted in the application. So you can see that some of the elements we discussed previously are in this particular control. The next example that we have on the list is administrative access, and it reads super user access to the SQL Server database is restricted to DBAs. Again, this also has the element of saying who this restriction is two. Because you see here that it's talking first about the super user access in the database. And it seemed that only individuals that have a job role of DBA should have superuser access to. And it tells you what the SQL Server database, again, you can see where some of these control elements that we discussed earlier have been covered. The third example we have is about terminated user access. And it reads, all terminated users have their network account removed within two days of termination. This is also very clear. It's talking about terminated users. It's talking about the axis, specifically the network account access and is given a duration two days. Within two days of termination, network access must be removed. So it's very clear what this particular control activity is about. And the last one we have on the screen is a password control that reads. The Oracle database requires users to have passwords with at least eight alphanumeric characters, and the password must be changed at least every 90 days. Again, you can see this is very specific. It's telling you this is for the Oracle database specifically. And it's telling you the characteristics or the sentence, the configuration settings that must be enabled. So the password setting should have eight alphanumeric characters that are noted. And then you also want to make sure that there's an exploration setting that says a password expires after 90 days, which time it must be changed. Here are some additional control examples. This first one says physical access and it reads, access to the data center is limited to IT personnel. And this one is also very clear. It's talking about the datacenter and access, and it's talking about the roles IT personnel that should have access. This control could be improved upon by stating if there's any groups within the IT group that should have access or shouldn't have access. That could be an improvement to this control where you are a little bit more specific about who should have access to the data center. The next control we have on the screen is changed management. All change requests to the organization's systems must be appropriately authorized, tested, and approved prior to implementation. This also has some of the elements we discussed because you can see here we're talking about the change requests. That's the part of the control and it's telling you the specific activities that have to occur for change requests, which includes authorization, testing, and approval before you implement it in production. So the word production is missing here. That's an improvement that we could add. But you can see here that several elements are present to make it very clear. This control is about the last control that we have here, is IT policy training? And this states the new hire orientation includes basic security awareness training. And upon completion, the new hire is required to sign that they completed the training. And you can see here that it's telling you what is occurring. The activity that's occurring is the training on security awareness. And you can see here that the evidence of that control taking place or being performed is the signature of the new hire that says that they have actually completed the training. And you can see some elements coming into play here. As previously discussed. All the elements we covered a few slides ago do not need to be present in every single control, but you need a good amount of booze to make sure that control is very clear. Alright, we've reached the end of this section. Let's talk about the items that we've learned in this lecture. We learned about the definition of IT audit. We also learned about definition of controls and key controls. We reviewed the hierarchy of controls, the reasons behind controls, why organizations implement controls. We also went over the basic elements of controls. And then we discussed the different types of controls, the three main types of controls, and we close that with control examples. Thank you very much for listening to this lecture. We'll see you in the next lecture. 3. 3. Controls Testing and Sampling: Welcome to the section on controls testing. Now that we know what controls are, let us talk about testing of controls. Here are the items that we will address in this section. We'll review. Why do we test controls? The types of controls that we test, the types of tests that we perform, and how to make selections for testing. So in this first lecture here, the question is, why do we test controls? The key reason, the main reason is that we test controls to determine if they are fulfilling the purpose for which they were implemented. If a control is not fulfilling the purpose for Egypt was implemented, then it's ineffective and it may need to be changed. So it's not enough just to say, I've designed and implemented controls in the environment. It is absolutely necessary to test those controls periodically to make sure that they are actually performing and doing the work they were implemented to do. And if there are any gaps, then management will need to make the decision on how to change those controls as appropriate. Let's talk about the types of controls that we test. There are two broad categories of controls. It general controls, or some people may call it general IT controls and application controls. Application controls are specific to certain business processes that occur in an application. And B are typically based on the client's customization of an application. E.g. application controls will be controls over approval limits, authorizations for payment, e.g. this person can only approve up to X dollars for payment. Or you can also have authorization to edit specific journal entries or access to run and view specific HR reports. For a regulatory audit, the audit team, the financial audit team that is typically identified, the application controls that are part of the scope of the audit. It's important to note that application controls are alcohol them, the business controls that drive the IT general controls that are tested. On the other hand, IT general controls or you may see them referred to as IT GCS. And we refer to them as that. They are pervasive controls that support the IT environment of the organization and the impact multiple applications in use by the organization. What does that mean? This means that the IT general controls support the entire IT environment which includes the specific application that may be in scope for an audit. Generally, the IT GCS, they need to be operating effectively in order for the application controls to be relied upon. Let's talk through an example just to make things a little bit clearer. It general controls around passwords and access, which we'll look at a few examples in our prior section. Because these are for authentication and authorization, they help to ensure that individuals need to be authenticated into the IT environment before they can access systems where they have authorization. If this controls are not operating effectively, meaning many users can access finance applications without proper authentication. And they can access parts of the application without proper authorization. It will be pretty difficult to prove that only authorized users have access to the finance applications. Unauthorized individuals may have access to approve payments in the application because the IT general controls were not effective. This example goes to show the importance of IT. General controls being effective in order for the auditors are those that are testing to rely on this application controls. In the next slide, we'll go through a pictorial example. This slide here is an image that depicts what we just discussed. So you can see here the IT environment is the big circle. The IT general controls over the entire network, servers, database, and applications. The controls are all encompassing. Well, I shouldn't say all, but they have a far reach and they are very pervasive. And you can see it covers various application systems that are in scope. However, you can see that each system will have its own specific application controls that are specific to the processes within that application, depending on which of these systems is in scope for an audit, you first need to test the overall IT environment and see how reliabilities, which will then determine the extent of testing that will be performed on each individual system. So hope this has given you a little bit more clarity on the differences between IT, general controls and application controls. Since this course is about IT auditing here as some subcategories of the IT general controls. We don't go into this in depth in this particular course, but it's good to give you guys an overview of what the subcategories are. The categories are logical security, which has to do with access. We also have program changes, program development, computer operations, physical and environmental controls. Now, let's discuss the types of tests that we perform for controls. In order to test controls, you have to first determine if the control is designed adequately before you determine if it is operating effectively. The test of design is to determine whether a control is properly designed, such that if you were implemented as designed, you would operate effectively. This means that you test the control to determine if there are any gaps or issues that will prevent it from working as it is designed. E.g. let's take a look at password controls. If you want to test the design of password controls that's picked up, passwords must be alphanumeric. You want to make sure that there are documented policies in place to govern the password settings for IT systems. You would want to make sure that the system being tested also has the capability to support alphanumeric passwords. If there are no corporate policies that require alphanumeric passwords, or if the system is unable to support alphanumeric passwords, then the control is not properly designed because it will fail when you try to test the operating effectiveness. The test of design can be performed using several methods so that we can conclude on the appropriateness of the design. And we'll go over that in the next slide. The test of operating effectiveness comes after the test of design. And it's used to determine if the control is operating as intended when it was designed. Going with the example of password controls. In order to test the operating effectiveness of that control, we would obtain the password settings from the system that's been audited and make sure that the settings, the configuration settings require alphanumeric passwords from users. Showing that the setting is enabled will be the evidence that the control for alphanumeric passwords is operating effectively. There are also several methods that can be used to perform tests of operating effectiveness. And we'll also go over that in the next slide. Before we wrap up this slide, there are certain things that we need to consider when we're performing a test of operating effectiveness. You have to consider the nature of the control. Is it an automated control or is it manual? This will impact the type of evidence that you need to review for testing. You also have to consider the frequency of the operation. How often is the control performed? This will impact the selection size that you need to make to test. And you also have to consider the significance of the control and the risk of failure. How important is this control? How key is a key control? And is it prone to failure? This will also impact the selection sizes that you make when you're testing this particular control. We'll go over selection sizes in a different lecture. In general, all these items will help determine how you design the test to be performed and how you make the selection of items that you will test. Next, let's talk about testing techniques. On the previous slide, I mentioned that there are various methods to perform tests of design and test the operating effectiveness. Here are some techniques and methods for tests of design would typically perform inquiry. First, which is the same as asking people questions by an interview. We inspect documents and then we also observe processes. You have to use at least two of these methods for tests of design, because inquiry alone is never sufficient for tests of design. In cases where it is absolutely impossible to inspect evidence or observed processes, it might be acceptable to perform what is called a collaborative inquiry, which means asking two or more people the same set of interview questions in order to determine if their responses regarding the process and control are the same. For test of operating effectiveness, you can utilize the techniques listed here. Let's go through each one. Observation means that you can observe a process occur to make sure the control is performed as part of that process. An example would be observing someone using their badge. To access the server room, to test the control that access to the server room is restricted by badge access. Inspection means that you review evidence provided to you to determine if the control is operating effectively. E.g. let us look at the server room access control. You can request and obtain a report from the batch system to determine if only approved individuals have the server room permissions on their badges. You want to make sure that everybody doesn't have the brought the server room permissions on their badge. And that's restricted only to individuals that need to access the server. Re-performance means that you are performing the control again to determine if you arrive at the same conclusion as the originally performed control. An example here would be e.g. a. Reconciliation control, where you reconcile the same items in the process and see if you come up with the same results. Recalculation means that you calculate items from the controller again to determine if he come up with the same result. E.g. if the control is supposed to calculate two numbers in different accounts for reconciliation, you can manually recalculate those numbers to make sure that the numbers that we use in the reconciliation where Correct. The last item that we have here is a system query. This means you can run reports from the system to view new users that are created, changes made to a field or other applicable reports that can be used for control testing. E.g. if you want to test the approval process for new users, you can run a report from the system of all new user accounts that were created. Then you can use that list to make a selection that you would then test to determine if each user had an access request form completed and properly approved by their manager. So this actually has two elements. The example I just used, you use the system query to generate a report that you can use for selection. And then when you get your evidence for the selection, you can then use the inspection to perform a test to make sure that all the elements of the control were met. This concludes the lecture on testing techniques. Let's go into selection sizes. Welcome to the lecture on Selection sizes. In this lecture, we will cover the concept of selections. This concept is based on the fact that when performing control testing, there are usually a lot of items that are testable, but it is not practical to test everything. As such. Only sample of items that are eligible for testing, do you get tested? So let's start with what is a selection? Simply put, according to the dictionary, acylation is a carefully chosen or representative collection of people or things, in this case, items or evidence for testing. Why do we make selections? As noted earlier, it's simply because it's not feasible to look at an entire population. Let's talk through an example. So we have a control about obtaining supervisor approval prior to granting users to access. The test of operating effectiveness be to check new users created and make sure approval was granted for each user. In order to identify the new users, we would run a system query, as we discussed previously, to determine the number of new users that were created during the audit period. And for a large organization, this can easily be in the hundreds. So this could be a hundreds of individuals. If the number of new hires is say, 200, 300, 500, it's not feasible or even reasonable to test all those users. In this case, it will be more practical to make a representative selection of those users and test those. By testing a representative sample of users, we can then extrapolate the conclusion of testing for the selection to the rest of the population. When selecting samples, you have to consider how frequently the control is performed and the risk of failure. This helps you to determine what an appropriate sample size selection should be. Most organizations have sample size guide that provide guidance and the number of samples to select based on the frequency of the control and the risk of failure. And I will show you a sample guide on the next slide. Finally, you also have to consider the range of variables in the population. What this means is that you should try to cover the entire audit period in your sample selection. So it covers the entire range of variables. E.g. if your audit period is from January to December, you want to make sure that you select samples that cut across the whole year, as opposed to having samples that are skewed towards just some months of the year. So this means that sample size selection is not entirely random because it has to be a representative sample of the whole population of items. Let's look at a sample guide of selection sizes. In this particular guide, you would see here that the control frequency is on the left column. And then you have the risk of failure on the right two columns lower and higher. So what this depicts is that for each control frequency, if based on the risk of failure, if it's a lower risk of failure or higher risk of failure, you get to select which the number of items that you would test. Let's look at weekly, e.g. for a control that occurs weekly, if it has a lower risk of failure, you only need to select five items to test per this particular guide. However, if it has a higher risk of failure, then you would want to test at least eight. These numbers are just minimums. You can test at least five on the lower end of the risk of failure, or eight on the higher end of the risk of failure. It's not telling you the maximum is just the minimum number of items that need to be tested to give comfort that a representative sample has been tested. Check with your organization to see if they have a similar chart whenever you're performing testing. One thing to note is that if the nature of the control is sporadic and the control frequency cannot be clearly identified. You should determine the frequency using the entire population. If the population is 12 items in total, then you can use the frequency of Motley. Or if you have about 52 items on the population, you want to use the frequency of weekly. However, if the population is between two control frequencies defined above always use the higher frequency. So e.g. if you have 25 items, then you don't want to use monthly. You want to use weekly because you're going to that next control frequency on the chart. Alright, we've reached the end of this section. Let's go over the items that we've learned. We learned about why we test controls. We discussed the types of controls that we test, the types of tests that are performed, and then how to make selections for testing. 4. 4. Thank You: Thank you so much for taking this course, and I hope that you find are the course objectives have been met, you should have learned the fundamentals of IT auditing. If you have any questions, please do not hesitate to reach out to me. Thank you.