Did you know Cybrary has FREE video training? Join more than 2,500,000 IT and cyber security professionals, students, career changers, and more, growing their careers on Cybrary.
This lesson covers task statements. This lesson discusses the IT Audit Process which is Domain 1. Task statements help a company assess a situation and develop a risk based IT audit strategy. [toggle_content title="Transcript"] So let's start talking about the first domain. The IS audit process. One thing that's interesting about the breakdown of the domains is that ISACA does tell us roughly what percentage of this domain is covered in the exam. So 14% for the first domain. There are a few that are 14% but it's the smallest amount that a particular domain will take in the exam. One of the domains takes 30%, so it's twice as much material. But this one's kind of a smaller one, 14%. So we're trying to think about what are the auditing processes or methodologies for information systems and how do we adhere to the industry standards for doing this activity in a way that provides the auditor with predictable results and also provides your client with the information they need in order to make decisions based on risk and other factors. Alright, so for each of the domains we have task statements and knowledge statements. This might be a lot to read when you're first looking at, so I'll just kind of try to cover the highlights of each of these. So for the first domain we're trying to think about first a risk-based audit strategy. As I was just mentioning, you're trying to make risk-based decisions, so that's why we audit things to begin with. We find out that we've got a problem or some inconsistency or a configuration that doesn't match what's expected. Then that affects your risk posture, your security posture, and also subsequently affects your ability to make decisions based on the assurance that's provided by a particular system or some security controls. Now, we have to think about planning our audits. So an audit sometimes is a planned scheduled event. Other times it might be something that is more spontaneous from the perspective of the auditee, rather. The auditor knows that the audit's coming but it might not be something that's announced well ahead of time. There's different philosophies on this. I'm of the opinion that using a mix of scheduled audits and some things that are a little bit more short-term notice are a good idea. If everybody knows that the audit's coming, at the end of the month, for instance, it may be tempting to scurry around and fix all the different problems that you think might be discovered in the audit, and then everything looks better than it might have looked otherwise. If, for instance, someone says, 'The audit's going to happen tomorrow.' Now you've got a different situation on your hands. That short-term announcement of an audit is likely to uncover things that would not have been uncovered if you were given more notice, because people don't have enough time to fix or go and verify anything if you tell them it's going to happen, you know, 24 hours from now. So it's an interesting contrast between those two different methodologies. Having properly crafted out an objective is something to think about too. So you can't just say, 'Well, we're just going to measure everything and test some stuff.' You need to have objectives that might already be defined because the organization has done these kinds of audits before, or it could be something that's new because there's some new information that's come to-light that triggers an audit. Two things that could trigger an audit are time-based, I already mentioned that, maybe it's an annual or semi-annual or quarterly audit of some particular system or group of systems, or some financial aspect of your organization. Or it could be something that's event based. So, in this day and age, when we see a lot of hacking incidents and a lot of fraud from officers in large organizations, certain events might trigger an audit because someone says, 'Well, this and this and this happened and someone did this and someone stole this money and we've got these fraudulent transactions we just discovered.' You really don't want to wait until the next scheduled audit to start looking into that, right? So that's what I would call an event-based audit. Something happens, now we've got work to do. The other thing we think about is once the audit is completed, we have to make sure that the stakeholders get the results of this audit. They're the ones that have a reliance on this information to decide what's best for the organization and they have the requirement to understand the findings and to decide what actions to take. So producing a report that's concise, has the required level of detail and has the assurances of the auditor that it was done correctly and is providing truthful information is what's most important here. Then we go to number four. Conducting follow-ups or preparing status reports. This is an important thing to think about as well because it could be the case that the auditor does some work, discovers some findings and prepares a report for management or for the other auditee to look at and they might have to go back and change some things, fix some things. Correct problems. So now the auditor has to think about at what interval should they follow-up to re-investigate or re-examine this information to find out if, indeed, the problem is resolved? That interval could be decided mostly by the client but there could be some standards that might be effectively used to say, you know, 'You've got 30 days.' Just kind of like a typical window where something might be required to be fixed. If it's more critical, maybe you've got three days, or five days, it just depends on the situation and the management style of the organization as far as what they want to do in those different areas. [/toggle_content]