Task Statements

Video Activity

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...

Join over 3 million cybersecurity professionals advancing their career
Sign up with
or

Already have an account? Sign In »

Time
13 hours 35 minutes
Difficulty
Intermediate
CEU/CPE
9
Video Description

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]

Video Transcription
00:04
So let's start talking about the first domain
00:08
I asked. Audit process. One thing that's interesting about the breakdown of the domains is that
00:15
Sokka does tell us roughly what percentage of this domain is covered in the exam. So 14% for the 1st 2 main This is the smallest. There's a few that are 14%. That's a smallest amount
00:28
that a particular domain will taking the exam one of one of the domains takes 30% so it's twice as much material. This one's kind of a smaller 14%. So we're trying to think about what are the
00:39
auditing process is our methodologies for information systems?
00:44
And how do we
00:45
adhere to the industry standards for doing this activity in a way that provides the auditor with predictable
00:55
results and also provides your client
00:58
with the information they need, nor to make decisions based on risk and other factors? All right, so for each of the domains, we have tasks, statements and knowledge statements.
01:07
Ah, this might be a little bit ah, lot to read when you're first looking at it,
01:11
so I'll just try to cover the highlights in each of these. So for the first domain. We're trying to think about first a risk based on its strategy. As I was just mentioning, you're trying to make risk based decisions,
01:23
so that's why we oughta things to begin with,
01:25
We find out that we've got a problem
01:27
or some inconsistency or a,
01:30
UM,
01:30
configuration that doesn't match
01:33
what's expected
01:34
than that affects your risk, posture your security posture and also subsequently effects
01:42
your ability to make decisions based on the
01:44
the assurance that's provided by a particular system or some security controls. Then we have to think about planning our audits.
01:52
So an audit sometimes is a planned scheduled event.
01:57
Other times it might be something that is more spontaneous
02:00
from the from the perspective of the oddity. Rather,
02:04
the auditor knows that the audits coming, but
02:07
it might not be something that's announced while ahead of time. There's different philosophies on this.
02:12
I'm of the opinion that using a mix of scheduled audits
02:15
and some things that are a little bit more short, short term notice are are good idea.
02:21
If everybody knows that the audits coming at the end of the month, for instance,
02:25
it may be
02:28
attempting to scurry around and fix all the different problems that you think might be discovered in the audit,
02:35
and then everything looks better than it might have looked otherwise. If, for instance, someone says the audit's gonna happen tomorrow night, I've got a different situation on your hands.
02:44
That short term
02:46
announcement of an audit
02:47
is likely to uncover things that that would not have been uncovered if you were given more notice. Because people aren't they don't have enough time to fix or go and verify anything if you tell him it's gonna happen 24 hours from now.
03:00
So it's an interesting con contrast between those two different
03:04
methodologies.
03:07
Having properly ah,
03:09
crafted audit objective is something to think about, too.
03:14
So you can't just say, Well, we're just gonna measure everything and test some stuff.
03:19
You need to have objectives that might already be defined because the organization is has done these kinds of oddities before.
03:27
Or it could be something that's new because there's some some new information that's that's come to light that triggers an audit
03:34
two things that could trigger an auditor, a time based right. I already mentioned that
03:39
maybe it's an annual or semiannual or quarterly audit
03:44
some particular system or group of systems
03:46
or some financial aspect of your organization,
03:50
or could be something that's event based.
03:53
So in this day and age, when we see a lot of hacking incidents
03:58
and a lot of, um,
04:00
fraud from officers and large organizations,
04:04
certain events might trigger an on it because someone says, Well,
04:09
this and this and this happened and someone did this and someone stole this money
04:13
and we've got these fraudulent transactions We just discovered
04:16
You really don't want to wait until the next schedule audit to start looking into that, right? So that's what I would call an event based on it. Something 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.
04:34
They're the ones that have
04:36
reliance on this information to decide what's best for the organization,
04:42
and
04:44
they have the
04:45
requirement to understand the findings and aside one actions to take. So producing a report
04:51
that's concise has the required level of detail
04:55
and has the, uh,
04:58
the assurances of the auditor that it was done correctly and is providing truthful information is what's most important here.
05:05
Then we go to number four,
05:08
conducting follow ups
05:10
or or preparing status reports. This is an important thing to think, to think about as well,
05:15
because it could be the case that the auditor does some work,
05:19
discover some findings
05:21
and prepares a report for management or for the other oddity to look at.
05:28
And they might have to go back and change some things. Fix some things,
05:31
um,
05:32
correct problems.
05:34
So now the auditor has to think about at what interval should they follow up
05:40
to reinvestigate or re examine
05:43
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 that. You know, you've got 30 days, you know, just kind of like a
05:58
ah 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
06:08
and the management style of the organizations for what they want to do. And that was different
06:13
areas
Up Next
Certified Information System Auditor (CISA)

In order to face the dynamic requirements of meeting enterprise vulnerability management challenges, this CISA course covers the auditing process to ensure that you have the ability to analyze the state of your organization and make changes where needed.

Instructed By