Practical Guide- Beginner to Pro- Cyber and IT Auditing Part 2 (Fieldwork) | Technology Accountant | Skillshare

Playback Speed

  • 0.5x
  • 1x (Normal)
  • 1.25x
  • 1.5x
  • 2x

Practical Guide- Beginner to Pro- Cyber and IT Auditing Part 2 (Fieldwork)

teacher avatar Technology Accountant, Inspire and educate!

Watch this class and thousands more

Get unlimited access to every class
Taught by industry leaders & working professionals
Topics include illustration, design, photography, and more

Watch this class and thousands more

Get unlimited access to every class
Taught by industry leaders & working professionals
Topics include illustration, design, photography, and more

Lessons in This Class

33 Lessons (1h 10m)
    • 1. Why take this class: Introduction and Roadmap

    • 2. What is IT audits vs control testing and the audit life cycle

    • 3. How to test controls

    • 4. Knowing the difference between Operating Effectiveness and Design Effectiveness

    • 5. Understanding Sufficient and Appropriate Evidences

    • 6. Understanding Population vs Sampling

    • 7. Understanding Exceptions vs Findings

    • 8. Understanding Audit File Structure

    • 9. Understanding Control Design and Operating Effectiveness Roadmap

    • 10. How to evaluate Control Design (ie 7 Design Factors)

    • 11. Knowing the Control Nature and Control Types

    • 12. Knowing the Control Frequencies

    • 13. Knowing the Control Details

    • 14. Knowing how to evaluate a Control Performer

    • 15. Knowing the Control Breakdowns

    • 16. Knowing how a Control Addresses the Risk

    • 17. Understanding the Control Design Effectiveness Testing Outcomes

    • 18. Learning Scenario #1 How to Evaluate Control Design

    • 19. How to evaluate Control Operating Effectiveness

    • 20. Learning Scenario #2 How to Evaluate Sufficient and Appropriate Evidences

    • 21. Learning Scenario #3 How to test controls with evidences

    • 22. Understanding Fieldwork Activities and Cyber & IT Control TechnicalRoadmap

    • 23. Understanding Auditing Fieldwork Activities

    • 24. Knowing how to conduct walkthroughs

    • 25. Knowing how to request evidences

    • 26. Knowing how to control test

    • 27. Knowing how to review and follow-up

    • 28. Overview of Cyber and IT controls

    • 29. How to test privileged access controls

    • 30. How to test incident mgmt controls

    • 31. How to test patch mgmt controls

    • 32. How to test logging and monitoring controls

    • 33. Summary and Credits

  • --
  • Beginner level
  • Intermediate level
  • Advanced level
  • All levels
  • Beg/Int level
  • Int/Adv level

Community Generated

The level is determined by a majority opinion of students who have reviewed this class. The teacher's recommendation is shown until at least 5 student responses are collected.





About This Class

Are you interested in kick starting a career in IT auditing? Tired of learning IT auditing through theory and books? Then this is the perfect course for you! This is a condensed course to go over the basics and advanced concepts in IT auditing. The course is one of the first of its kind to not only cover concepts but to also walk you through practical examples and know-hows to conduct a Cyber and IT audit during the fieldwork stages. The course will also introduce technical knowledge of IT processes/IT controls and IT systems to prepare you to become a knowledgeable auditor.

Your Instructor

Your instructor is a proven and skilled individual with over 6+ years of experience in big consulting, big4 accounting and big5 banks. Chris (The Technology Accountant) has worked in in-demand fields in consulting, advisory and assurance in Cyber and IT space. He holds a CPA (Chartered Professional Accountant), CISSP (Certified Information System Security Professional) and CISA (Certified Information System Auditor) designations and has taught over 20,000 students from 155+ countries on this platform.

Benefits to you

-Gain theoretical and practical knowledge of various auditing concepts and Cyber/IT controls/risk technicals

-Gain theoretical and practical knowledge and skills in creating your own Cyber and IT audit plan through practices;

  a) 10 downloadable course templates and detailed information for your learning/practice

  b) 1 project case assignment to test and practice your overall learning with step by step answer


  c) Scenarios videos/practice questions in course lectures

-Gain expert knowledge and material from proven Instructor

Accomplished Goals

At the end of this course, you would gain the fundamental and practical knowledge and skills in IT Audits Control Testing, Auditing concepts and Cybersecurity/IT Control Technicals, you will also become prepared on how to control test Cyber and IT audit with supporting real world examples/scenarios and templates. Lastly you will also gain technical knowledge of various IT and Cyber controls and technicals within this course to not only help you audit but also effectively execute your audits.

Meet Your Teacher

Teacher Profile Image

Technology Accountant

Inspire and educate!


Technology Accountant is a course provider that provides various topics in Cybersecurity, IT, finance/accounting, personal development, investing and more!

Your #1 instructor in Technology Accountant is Chris. Chris is currently doing IT Infra and Cyber security audits at a Big5/ Fortune500 bank and also as a Sessional Instructor Assistant at the University of Toronto. Chris holds a Bachelors of Business Admin degree and professional certifications such as Chartered Professional Accountant (CPA), Certified Information Systems Security Professional (CISSP) and Certified Info Systems Auditor (CISA). Chris has worked in various in-demand fields (ie mgmt consulting, advisory, assurance etc) and has professional experiences from Deloitte, Accenture, Sapient (now Publicis.Sap... See full profile

Class Ratings

Expectations Met?
  • Exceeded!
  • Yes
  • Somewhat
  • Not really
Reviews Archive

In October 2018, we updated our review system to improve the way we collect feedback. Below are the reviews written before that update.

Why Join Skillshare?

Take award-winning Skillshare Original Classes

Each class has short lessons, hands-on projects

Your membership supports Skillshare teachers

Learn From Anywhere

Take classes on the go with the Skillshare app. Stream or download to watch on the plane, the subway, or wherever you learn best.


1. Why take this class: Introduction and Roadmap: Every day technology helps connect us to different people. It helps brings us closer mix of world smaller. And at the same time, every day billions of emails, data messages are sent across the planet from one place to another. So how do companies protect themselves and your data? One way is having internal AND IT cyber controls that ensure the systems data and everything is working. And to ensure that internal controls are working IT and cyber audits are conducted via control testing. So by taking this course, who develop IT and cyber auditing skills, you also gain knowledge and how to do control testing and Sanborn IT fieldwork phases. And last but not least, you also develop a foundation in cyber AND IT control processes and technical. Hello and welcome to the Technology campaigns course, cyber in IT auditing part to a Practical Guide from beginner to Pro. Lets go through who your instructors are programmed in the Course Features. My name is Chris, I'm your instructor. I have a bachelors of Business Admin. I'm also chartered professional counting a CPA, a Certified Information Systems Security Professional, and also a Certified Information System order as csa. I phi plus years experience in IT consulting advisory audits. I taught consulting firms and also big four accounting firms and big five banks experiences. I also have knowledge in cybersecurity, IT infrastructure and applications, anti processes, project management, assurance, and finance and accounting. Now in terms of a program, we have over 20 thousand students from over a 155 plus countries. And course topics include things like cybersecurity IT auditing, risk management, project management, finance and accounting, stocks and bifolia investing, tax and budgets and personal development. Now for this course, the features include a progressive roadmap, quizzes, checkpoints, learning scenarios, a practice assignment, downloadable attachments, increased technical skills and knowledge and asked her soft skills as well. So let's jump to it. This course is a continuation of Part one, which focuses on cyber in ITER, in planning. The course is focused on fieldwork in execution stages of the Arctic, which mainly covers control testing. Other parts of the series focused on other concepts and guides such as audit planning and reporting. Now the course is broken down into three sections. The first section we'll go over what IT Arctic show testing is and the basic control testing concepts. Next we go into how to assess control design and operating effectiveness, which are key components and add a few work. And lastly, we'll also go over the practical guide. And odd if you work activities along with some cyber and IT controlled technicals. 2. What is IT audits vs control testing and the audit life cycle: So what exactly is audit control testing will control testing is really part of the overall audit. Let's go over what an audit really is. First, an audit is to attests and entities id processes and control design and or operating effectiveness. And this is done by conducting internal or external audits. And the objective, which is also the why, is to provide a reasonable assurance to issue an opinion or a rating. Now, in terms of control testing, controlled testing is one of the core components in any audits. It's essentially how the audit is completed and executed. So what exactly is controlled tests and wall? What is a test is whether the control was designed and operating effectively to meet the control objective. For example, let's say we have access cards, which is the control to prevent unauthorized users and the datacenter. Then this control that you're testing, you're going to validate that this axis car mechanism is designed an operating effectively to prevent unauthorized users from accessing the datacenter. And the how. And this control testing is conducted by testing the design n or operating effectiveness, which also documents with sufficient and appropriate evidence. And lastly, the why is really the final outcome to conclude whether the control is effective in effective or effective with exceptions. So in order to really understand control testing, we need to look at the audit lifecycle. And the lifecycle is split into three stages. Planning fieldwork, also known as execution and reporting. For the course. As I mentioned, we are only looking at the funeral because this is where the control testing falls into. Now within these phases, you will also find that the few work we'll take the most time and effort because this is essentially where the bulk of the work will be conducted by the auditor. So let's take a closer look at what each of these phases entails and get a deeper understanding. So in terms of the lifecycle, planning really covers fears, activities such as pre-planning administration's understanding the client and the processes, the finding of the scope, objectives, and creating fears, planning documents such as planning memos, procedure's, risk assessments and really want to test and when not to test. But lastly, it also entails communicating with the client and internal team to outline the expectations, logistics and structure, and the fieldwork phase, we then dive into the work itself by creating and managing evidence requests is selecting samples and populations for testing, conducting meetings and work sessions with the client and the team. Examining evidence isn't deviations and work papers and really reviewing and approving those work papers near the end. And of course, having client in team communications throughout is important as well. Lastly, in terms of the reporting stage, the stage really assesses to control findings and drafting the audit report, creating lessons learned, summary, MOs, and also wrap ups. Stakeholder reviews and approvals, again, are important, but it's also important to have communication to report the results to the team and the client stakeholders as well. So how this control tests that look like fieldwork. And the easiest way is break it down into four stages because control testing is insight for your bulk phase of the lifecycle. And the first part is really having a walk-through with the client on the controls that were determined during the planning phase. And a walkthrough is really a meeting or interview with the client to learn more about the controls processes, and go over any questions with them, such as what type of evidence can they support who the contracts, and even having them show you an example of how the control works. Now, after getting this understanding, the auditing team would then request and obtain evidence is based on their understanding of the Patrol and the test procedures. Once this evidence is obtained, the auditor on the team would then test the controls by evaluating and validating the design and or control operating effectiveness in the work papers. Now once this is done, the audit team managers or senior managers would review the work and follow ups by the auditors may also Kurzweil if there's review notes to really wrap up the control testing. So this is how fear works in a nutshell, and we will go over these in more detail in section 23. However, that's going over some of the basic control tests and concepts first. 3. How to test controls: So how are controls really tested? As mentioned earlier, the idea is to gain an understanding of the client's controls address to rescue or audit makes sense? And this understanding is done by having a walk-through with the client. And the second step is to conduct test scripts. Fea audit test methods on procedures were sufficient and appropriate evidence. Now in the next couple of slides, I'll go over what these terms are and some examples. Lastly, control should also be documented what results to conclude on the control design and operating effectiveness for the audit period. And the audit period isn't usually space on the calendar year, which is say, January first 2020 to December 31st, 2020. But it can be actually any length and time for exam point audit can also be things like maybe the period is March first 2020 to April 30th, 2021. Procedures are really instructions that are in the work papers to guide an auditor on how the tests are control. And these are generally created by the audit manager or the senior team members during the planning phase. Now, if during the fieldwork phases the control turns out to be different and had challenges to test the procedures. Then the procedures can really be changed and update it. Now procedures themselves half steps. And these steps may include things like obtaining certain evidence is relevant to look intros, steps in evaluating the design, and also steps in evaluating the operating effectiveness of the control itself. Now what about testing methods? What are these and how do they tie in with procedures? Wise mentioned earlier, procedures are the instructions show the test methods are really the methods and the actions that the auditor does to conduct the procedure. For example, there's actually five common types of procedures across both cyber and IT audits and also regular audits. And these are observation, examination, inquiry, performance, and analytical. Observation is the auditing procedures to test the controls by observing a few in the control performer, excluding the control. Now examination is really inspecting the irrelevant Audit Evidence is like screenshots, documents and usually listings. Inquiry is really the auditor asking the questions to the oddity to determine the relevant information and read performance. Is the auditor independently executing the controls that they are validating. Finally, analytical as when the auditor uses Analytics and computer assisted auditing testing tools to determine patterns and trends for relevant information. 4. Knowing the difference between Operating Effectiveness and Design Effectiveness: We went over the terms controlled design and operating effectiveness many times. But what exactly are these terms? Now in design effectiveness is defined as evaluating the control design and whether the control can address derisk. Auditors generally tests in incidence of one to conclude whether the control was designed and implemented properly. For example, we're testing that change management on the IT systems is the sign and implement it. Then we would then test fairs factors in the control design to first ensure that it is designed properly based on the risk. In that second, it is implemented with a sample of one. Now, operating effectiveness is defined as evaluating the controls and ability to operate for a period of time. Auditors generally obtained the sample from the population to conclude whether the control can operate effectively for the given period. For example, once we know that the change management control was designed and implemented, we then select additional samples to see that it was actually operating for the intended audit period. 5. Understanding Sufficient and Appropriate Evidences: As mentioned earlier, evidence is important when conducting control testing. Evidence is defined as the support or proof needed to verify and validate that the true objective is met. We'll go over some common types of evidences in the next slide. Now you may also notice that I constantly mentioned sufficient and appropriate evidence and the reasons that in order for an auditor to conclude on a control testing outcome, they really need to have sufficient in appropriate evidence. Sufficient is defined as having enough samples or multiple evidences. You can show testing to validate and verify that the control objective is met. For example, let's say we are validating that OS servers are patched to in the IT environment. While you wouldn't have really pick only one certain say that all the other sharers are patch. This isn't sufficient. Instead you either test awe or get a sample that is representative do population to make that conclusion. Now the appropriate evidence is that it is defined as having relevant samples or multiple evidences. And your control testing to validate and verify that the control objective is met. For example, if we are testing that the shivers our patch with the latest security updates, we wouldn't be using evidences. A password parameters are logins because this isn't relevant. And instead, we will be using evidences of logs or patch histories from service to demonstrate that the patching was conducted. And therefore, this is the concept of sufficient and appropriate evidence. Alright, so in the autofill and there's many different types of evidence that you may encounter as an auditor, especially as a cyber and IP auditor. And there's much more than this, but here's some of the most common forms of evidences to first is listings and data extracts. Listings can be things like a list of change management tickets from a ticketing system like sure wish now, data extracts can also be things like Cmd B, or inventory of computer acids. And listings in data extracts are really used to provide data reconciliations, but also act as populations for the auditor to choose or pick samples. And the next is really emails and documents. Now, often when auditors conduct inquiry, it is selfishness, efficient and appropriate because this is verbal confirmation. And therefore having written confirmation or correspondents in form of emails or documents is important. So documentation can also take a form, policies, procedures, plans, or even process design and documents and diagrams as well. The next is logs and schedules, and these are generally extracted from the system, such as databases, servers, and applications. Now, Logs really show the historical activity performed by the system and users and are great ways to investigate or determine if an action was taken. Schedules should also show system processes and jobs are being ran and conducted. System configurations involve things like specific settings, codes are features are enabled or disabled in the system. For example, pass parameters on a Windows Server is a form of system configuration evidence. Lastly, users, one of the most critical form of evidence use and cyber NIT privileged user testing. Usually listing show which users are administrators, but also the number of users having access to that system. Now these are just some of the evidence is that you may encounter as in IT or in cyber auditor, every system and client that you audit would have different forms and idea however, is that these types of evidences will stay the same. The next concept is really having completeness and accuracy in evidence. And these are important because completeness is defined as evidence being complete and full and not subjugated to admissions and deletion. Whereas accuracy is defined as evidence being accurate, which it is not manipulate it or change by intention, error, or fraud by actors. And with folk completeness and accuracy in evidences, the auditor may not be actually able to use those evidences and the control testing. So N the audit fieldwork processes, there's fears procedures in the world papers that would ensure that the auditor conducts to ensure that their evidence is being used in the control testing is complete inaccurate. So here's an example. What it means by completeness. Below is a d to extract that was pulled from a database. And you can see that there's no filters applied and that the data extract it in CSP would have provided this small set of data. Now let's see if we have filter which was applied to exclude cities in the US. And then this dataset, we're now only display data with Canadian locations. And because the data was filtered, records were omitted and removed. And this is an example of evidence not being complete. And therefore, as an auditor, you will need to conduct procedures that ensure that the data is complete. And these may includes things such as taking screenshots, have the query that the client uses to give you the evidence or even observing them to generate the evidence directly. Next is accuracy that see that we know the original data in the coats of chichi and DF. And now when the client has given SDE evidence, it turns out that it was WW. And this means that the data itself is not accurate and was manipulated and changed. Now evidence that is not accurate cannot be used and therefore us in our editor and we'll need to conduct procedures to ensure that the data here is accurate. And this may include things like observing them to generate the evidence that they don't have the time to change the data. Or even cooperating with other evidences yourself by reconciling are matching with other records. 6. Understanding Population vs Sampling: Samples and populations are important control tests and concepts. The ideas at Indie audits, auditors cannot audit every single systems or users, especially if the IT environment is large. Instead, auditors what select samples to obtain reasonable assurance that the controller is designed and or operating effectively. That's what were some of these concepts. A population is defined as the pool of instances, individuals, objects, or items that the sample was pulled from. Population is generally related to the evidence use and the control testing. For example, if you are testing change management IT control change tickets, which would be your population. Now samples is defined as set of instances, individuals, objects, or items that is selected from the population. For example, we notice that there's a 1000 system change tickets in the year. We may then select 25 out of 9 thousand of the control testing. Now sampling techniques are broken down into two main categories, and these are statistical and non-statistical statistic's sampling gives an equal chance of samples to be selected. Random sampling generally is done through a random number generated by the auditor to select samples. Systematic sampling involves select samples from an ordered sampling frame. For example, if there was a Dow's and system change tickets and you as an auditor, may choose to select a sample every 50 counts. And this means that the record number 5150, et cetera, it would then be potentially selected as samples. Non-statistical sampling is sampling in which instances in a population may not have an equal chance of being selected. And this includes haphazard sampling, which involves the auditor picking random samples themselves. But because they don't have a random sampling generator or have statistical approaches, there's a chance that these samples may not have had an equal chance of being selected. Block sampling was similar to systematic sampling, but uses sequential series of selection. For example, in the thousands system changes of the population, the auditor decides that tickets numbered 25-30 is a block for sample tickets numbered 45 to 50 is another block for sampling as well. And finally, professional judgment is an under non-statistical sampling technique which the auditor, based on their understanding of the control and risk, purposely select certain samples for control testing. For example, if the auditor knew that some system changes were large and complex in the year, he or she may then decide to include those samples for testing. Now there's many different forms of sampling techniques like stratify, sampling, Monte terrors sampling and so forth. Have are the ones listed here are generally the most commonly used in cyber 90 audits. Another note is that you should also be aware that controls can also have multiple populations, subpopulations, and fair samples. If it is complex. Population frequency is not a topic that you should know when conducting control testing. And the idea is that the controls have populations with different frequencies. And the frequencies will help determine whether we select certain amount of samples. And every controller, the controller itself is performed, executed, are automatically conducted on a frequency. And these may include things as short as hourly or daily. Sometimes it can extend to weekly, bi-weekly, monthly, or even become longer in the form of quarterly, annually, by annually and semiannually. Now in some cases they can also occur multiple times a day. And lastly, sometimes control themselves are only performed on an as-needed basis, such as whenever an incident or change occurs. Other times it can also be continuous like having an active logging, monitoring and control, or a password parameter. The idea is that every control is different, but they would still have their own frequency. And the frequencies would then be dependent on the design of the control. And we will go over this in a bit more detail in section two of the course. Like I mentioned earlier, the population frequency will help the auditor determines the amount of samples. Four, in other words, this is the sample size. Now below is a table of the defined frequency of the populations and examples of sample sizes. And every company, we would have their own set of sample sizes so that the table below is not always the same across every company for now nonetheless, you can still see that the samples are likely going to be far smaller than population itself. For example, if we're happens to be a daily control the population and likely would be over 365 plus. But we're only going to take 25 samples. And the same thing as monthly, there's going to be at least 12 months, but we won't take 2N bows. And the idea is that we obtain reasonable assurance and not test every single instances in a population because you won't have time in an audit. So sample sizes are important. 7. Understanding Exceptions vs Findings: Another concept that auditors should be aware of is exceptions first findings. And the reason is that when you test controls during fieldwork, there will be times when he encountered exceptions and potentially findings and these will impact your control conclusion and even the audit report. So exceptions are defined as issues and errors identified and the control testing and these are documented in work papers. And generally a nominally isa can be reasoned and explain R-naught exceptions. For example, if you're testing user provisioning controls and one user is found to be non appropriately and axis, this is an exception and it may or may not lead to a finding until you further investigate and determine if a risk axises. I finding is defined as an aggregate or thematic set of exceptions with risks that can lead to control, design, and or operating effectiveness failure. And these are reported on the audit report. And generally, when the number of exceptions is pervasive, high and impactful, audit findings may likely than occur. For example, let's say that the user that we found out was not appropriate, but that this account was actually a super huge as well, then there's a risk. So potentially this can lead to a finding. In terms of control testing, it's important to know that there's many different outcomes. And the outcomes are important because they help contribute to the overall audit report inclusion. And there's fewer elements of how a control outcome is determined and what they end up to be. As I mentioned earlier, exceptions and findings can potentially impact the outcome. And the control KM is actually derived from a few different elements. This includes the controlled design and implementation and, or the controls operating effectiveness outcome to give an overall outcome and the control. Now in terms of the control outcomes itself, these can be ineffective, which means that the control is not the sign and implement it. Pan or operating effectively to tress derisk, effective means that the control is assigned and implement it and or operating effectively to address the risks within the odd period. And lastly, controls that are effective with exceptions means that the controller is designed and implemented and or operating effectively. But there's anomalies and exceptions. Now every company and firm will have their own methodologies and types of control outcomes. But this is one of the most common examples. Going a little bit deeper, I mentioned how exceptions can tie into conclusions. Well, how and when exactly do the numbers of exceptions cause controls, design, and operating effectiveness to fail? Well, here's a table example which outlines how the number of exceptions within a sample can potentially trigger ineffectiveness. Again, every company and firm will have their own methodologies, but this is a simple example. So let's go through one of these examples. For example, when we are testing a show, The operates daily. Great, we have 25 samples, but up to 25, we then test and notice that there are two that have exceptions. That in this case, we may likely need to increase our sample size just to be sure that the control isn't really ineffective. So we test ten additional more. Now let's say we tested those ten additional samples and then two of the ten also have exceptions. Now we know that the control is likely ineffective. So this is a common and simple way that auditors sometimes use to help determine the controls outcome. Again, auditors do also investigate further and consider risks as well to then determine the overall outcome and whether it leads to a finding. 8. Understanding Audit File Structure: This now comes down to one of the final concepts of section one, which is file structure. The file structure is important to understand because as an auditor who need to document the work somewhere, somewhere in how do you document? To begin, the auditor uses software repositories which store on the testing and evidences. And every company in firm will have their own software. But there's three terms that you should understand to know the structure. And these are audit file, how to program and we're papers. The audit file is defined as the overo file repository containing the contents of the audit, such as the planning documents to work papers, to finding the report, and so forth. The audit file itself encompasses everything within the specific audit. Now, the audit program is to structure within the audit file which outlines the process objectives, entity and client details, risk controls and test procedures which the auditor will test and validate for their audit. Work papers are patriots and documents which outline the results of the auditor's control testing. And evidences are uploaded and attach as part of the world paper and other details such as sampling populations and testing details may be attached and reference in these as well. You can see that in the diagram that the order is hierarchical. And for example, the audit file encompasses the audit program, and the audit program encompasses the warp paper. So in summary of the concepts that we discuss, there's many different terms and concepts. But for this course, we mainly went over the specific concepts that can assist you as practical fieldwork and execution guide. And as you progress through the different sections or the concepts and terms will also be explained. And there's many more concepts by 0s are covered in other parts of the series and outside of the course. And the main idea is to provide you only the important day-to-day concepts in this Practical Guide. 9. Understanding Control Design and Operating Effectiveness Roadmap: This comes down to the second section of the course and we'll go over how we can evaluate and assess the control design and operating effectiveness. 10. How to evaluate Control Design (ie 7 Design Factors): How do you assess a control design? What the best way is to assess the control design factors. Every company or firm has their own design factors to evaluate and meet regulatories like the PCA will be Cp board and other regulatory agencies. The most of them have these common design factors. And design factors are controlled type which outlines a weather control is preventative or detective. A preventative control means that the control is intended to prevent a risk and a detective control. As we can show which texts had arrest has cursor that appropriate action can then be taken automated first manual nature of the control was also a design factor. And this lets us understand if the control operates without human intervention, such as this system doing the work or requires human input and work. And the next set of slides will go over the types of controls and the nature and more detail. Control frequency is another design factors similar to populations having frequencies, you can show has a frequency as well in most cases to show frequency and population would generally be the same. Control details are other details like prior year conclusions, complexity of controls, control dependencies and more will go through these in the next set of slides. Control performer is another design factor and looks at the background of the person or system performing the control is objective, is a competent and so forth. For example, we have an entitlement review, which is known as an axis or review, is employee reviewing their own axis and saying that the level of access is fine or that the control performance, someone else will look into this in more detail. Control breakdown is really how the control is broken down. There's a have a threshold before the controls activated. What happens when the patrol fails? What the control follow-up and remediation processes. Lastly, risks aggression means whether the controller itself addresses their underlying risks. For example, if there are risk is inappropriate axis, we would want to control that EDA prevents architects in appropriate axis specifically, we wouldn't be looking at something else and this is what risks aggression means. 11. Knowing the Control Nature and Control Types: So here's a set of control types in atria. In most cases, controls are either automated or manual. Automated controls or controls performed by systems like automated tools, RPA scans, and built on workflows, manual controls or controls and involve human interaction and performance. So once we now understand how true natures are, what are some types. So in general, most controls are really preventative and detective Hao Ru, some companies and firms like to photo classified these. And I'll go through each one and provide an example. So a preventative control is implemented before I thread event occurs and reduces or avoids the likelihood and potential impact of that threat from occurring. For example, if someone is trying to access the office building, a preventative control would be to prevent unauthorized individuals from accessing the building. And the control that may take place in the form of heat cards OR gates that require you to swipe your IDs. And this control is also automated nature. A detective control is implemented to detect errors, issues, and threads that have already occurred. For example, a motion sensor and the datacenter is set up to monitor whether intruders have entered into the datacenter J22 computer assets. The motion sensor is the detective control and also automated and nature. A corrective control is implemented to remediate and resolve issues, errors and impact caused by the threat. For example, an employee has led in and fires in the computer and ex expanding in the computer network, the corrective control would be having a cyber analysts respond and resolve this issue, and this is also manually nature, compensating controls are implemented as alternative security measures. Ion is deemed too difficult to implement. For example, let's say that a fire's occurs and the company decided that having a cyber team to respond quickly is a bit more complicated and requires resources and expenses. And instead, they decided to have a compensating control, which may be having the infective workstations automatically disconnect from the computer networks whenever it detects fire signature. And this prevents it from spreading further, but also at the same time, compensates to address the underlying risk. Administrative controls are training procedures and policies that aim to mitigate threats presented by individuals. For example, having a cybersecurity annual training would reduce the chances of employees falling victim to viruses, malware or phishing scams. Launched Go and technical controls are designed to protect systems, networks, and environments in data, the most common form is logical access controls for privileged users, for example, the system is configured to not only allow super users to edit and modify features in settings. This is a automated control in nature and logical n-type recovery controls are in signing to enable resumption of operations after an event. A common example is having backups or disaster recovery plans. And depending on these control designs, they may be automated, manual, or even mixed. Fiscal controls are implemented to physically protect IT assets. And these can be simple things like having a log or even having motion sensors. So over you can see that there's many different types and natures of controls. Every company will have their own form and it will not exactly be the same in each company because everyone uses different solutions specific to the needs. However, the types and nature of controls would still be consistent. And as auditors, having this knowledge will help you better assessed control design. 12. Knowing the Control Frequencies: Control frequency is an adult sign factor. Each control has its own frequency tailored to the organizations needs. In general, the population of the evidence largely is connected through the control frequency itself. For example, we notice that there are system change tickets being created almost on a daily basis. Then the control likely operates on a daily as needed or multiple times a day. Now in this case you can see I mentioned several different forms of frequency, but the idea is that the auditor, based on their understanding of the control during the walkthrough, won't choose the most appropriate one. 13. Knowing the Control Details: Control design is a design factor that touches a bit more in the control itself. And this includes things like prior your conclusion, priority exceptions and findings prior your fraud, security breaches, the complexity of the control itself, volume, instances and transactions in the intro, and also the control dependencies. And every company and firm will have their own methodologies, but some may require the auditor to says all these, and others may pick one or two points. Again, this is based on methodology that company or the firm uses. 14. Knowing how to evaluate a Control Performer: Control performers can be a person or a system, and the best way is to evaluate a control performer is to look into three things. Now for systems, only two of the three would then apply. Refers as competency, which a person or individual as a control performer will usually be assessed at gans. And these can include things like understanding there, years of experience, education, certification. A second is independence, for example, of the control performer does not have any conflicts of interests and performing the control. An example would be, let's say a developer creating code. And then the controller is to verify that the code is reviewed before being implemented. The developer that reviews cold shouldn't be the same as the person that develops code. And the risk is that they may have the opportunity to slip in malicious code. The third is objectivity. There is a person or the system performing the control have any bias and subjectivity, for example, of the true is to review that managers are revealing entitlement axis for the direct reports, control performer realizes that he should a manager doesn't review the direct reports on and timely manner because he knows that the manager is quite busy. The control performer may not have flagged or called manager l. And this is bias and subjective and the goal is to be objective. Therefore, having competency, independence, and objectivity, you proves that the controller is designed to be effective. 15. Knowing the Control Breakdowns: Controlled breakdown can be looked into how the controller has thresholds and the resolutions and follow-ups. The threshold was defined as the limit, the amount that is allowed before the show is trigger. For example, we have an automated control which sounds in alert if someone has tried to access an account with failed login attempts of the seek more than five times the control wall only trigger when the threshold is five or more. Now for the resolution fall up, this relates to if there are other controls are processes to remediate, readdress the controls identified exceptions. For example, of the automated show sounds, the alerts for failed login attempts. What does the resolution follow-up? Is there process or control where the security team would then investigate? So overall, this is what control breakdown is. 16. Knowing how a Control Addresses the Risk: Risks, attrition is a final design factor and it's important because you really requires the auditor to use a professional knowledge, judgment, and skills. Do you think this is a control? Address the risk. A simple way to understand this is that the risk can be looked at as a problem and the control as a solution. And if you were to ask yourself based on your understanding of the control, that is, it really solved the problem. This is one way of tackling how risks aggression is obtained. 17. Understanding the Control Design Effectiveness Testing Outcomes: Finally, after assessing and then documented control design in the world paper, the auditor will again conclude, but this time on the control design. Similar to what we mentioned earlier, the outcomes again can be ineffective design, effective design, or design that is effective with exceptions. Last but not least, it is also important when the auditor assesses the design and they also test for implementation. Implementation simply means that the control was actually put into production and is working. Implementations simply means that the auditor needs to obtain one working sample to show that the control is indeed designed and implemented. 18. Learning Scenario #1 How to Evaluate Control Design: Let's go through some learning scenarios. In this scenario, you will look into the situation and an answer, a question. I wanted to provide step-by-step explanation of why the answer is as such. So here is the scenario. You are auditing a client and analog through meeting with them to understand the control. And the client simply tells you the following. Thank you for helping us with the audit as you are in the autofill, what phase? I thought that I'll share with you about our user access provisioning process in this Walkthrough, I am the IT manager in charge of axes provisioning. Am I hadn't listened. I have over ten years of experience in this field within education and information systems. Whenever a user requests access, they would submit a ticket to our internal ticketing system. We usually get about multiple tickets per day. My team's analysis would then review the tickets to verify if they have approvals by the managers, which is embedded within the ticket as this is an automated workflow which requires the managers sign off and addition, they would also check to see if the employees roles and duties or client with the required systems access via a row matrix. Lastly, we'll never really had any issues and provision process before, but if there's any new users with inappropriate axis, this is detected by our monthly user access review. So overall, this is our process to ensure that inappropriate access to systems is minimize. You can take this information back and assess the design. So looking at the shop verbage, what and where would you find the control designs? And you can pause this video and simply have a piece of paper and less of the 77 factors and what they are in this Walkthrough. Once you've done this, I would then reveal the solution. Okay, I'm ready to review the solution already. So the first set of sentences show who the control performers. And the performer is the IT manager and his analysis. And they all have over ten years of experience in an educational background in IT systems. And the small blue here tells us about the IT manager and the teams competency. Now in terms of independence and objectivity, we can see this a little below. The next is the control frequency. And some of the control design, the frequency. We can see that the control will operate multiple times a day because he said that they get multiple tickets per day. And also gives us a bit of the control details as well because it tells us some information about the volume and the number of instances occurring in the day. Next is the control nature type and also the control performer information. So looking at these highlights, we can see that the control nature and the type can be determined when the IT manager mentioned that they use an automated workflow which requires employees managers to sign off, but also that his team would review the tickets to verify that the approvals are obtained by the employees managers. This lets us know that the control has an automated and manual aspects to it, and therefore can be classified as mixed in nature. For controlled type itself is luckily preventative because they would need to see if an employee has manager approval and that their roles and duties acquiring with the required access in order to be granted such access. Another design factor that information also provides us is at the control performer, it's likely independent and objective. The control performer is independent because they are not the ones approving the employees axis. The employees managers are. Moreover, the control performance is not improving their own axis as well. So there's no conflict of interests. For objectivity. The control performer grants access only base on two conditions. And the first is that the employees managers provide approval and the second is using the row matrix to determine whether the axis can be granted. And these removes subjectivity and bias because these conditions are both black and white, the requests either has an approval or doesn't. The row matrix e2 specifies you get axis or does it? The next set of design factors that are answered in this example is the control breakdown and the control details. The control breakdown is discussed to the auditor by indicating that there is a monthly user access review process. And this means that the control hazard resolution and a follow-up process where accounts are mistakenly provisioned and the monthly huge Jack's review what the tack those inappropriate provisions Control Detail is also indicated because the IT manager indicated that they are not really having any large issues and the provisioning process. And lastly, in terms of risk for depression, this is answered When the IT manager indicates that the process of provisioning would be there can show to address inappropriate access to the system. As an auditor, YouTube would evaluate and think whether this control process here really addresses the rest. So overall, this is a quick example to show you how you can evaluate design based on gaining an understanding of the control in a walk-through. 19. How to evaluate Control Operating Effectiveness: Assessing operating effectiveness is a little bit easier. There's no factors because it's only based on two things. The first is obtaining sufficient appropriate evidence that satisfies the audit period, fear appropriate samples from a population. And the second is testing procedures with the auditing methods. To get at these would then allow the auditor to conclude on the controls operating effectiveness. Now, as mentioned earlier, these concepts and terms are already covered in Section one of the course. Section three of the course will also go into more detail on how to test shirt in IT and cyber controls. Again, operating effectiveness testing outcomes should be evaluated and concluded separately as well from design. Similar to design testing outcome, the honor won't need to conclude whether the operating effectiveness is ineffective, effective, or effective with exceptions. 20. Learning Scenario #2 How to Evaluate Sufficient and Appropriate Evidences: So looking at a learning scenario here and the subsample your task to test the operating effect as the control. You have now met with the client a second time, but this time you are aiming to gather the evidence is first. And as mentioned earlier, control testing requires evidence so that a client would say the following, Hey, welcome back. I hope the walk from our prior meeting helped you with your design testing and see that you are now testing for operating effectiveness of your control for the period of January first 2020 to December 31st, 2020. Can you let me know what type of evidence you need to validate the axis provision and control. Then look at your procedures. Based on my auditing procedures for access provision and controls, I can see that the following audits steps are listed. Remember, procedures are really a set of instructions of how you can test a control. It includes instructions on what to obtain and also what to test. So take a look at the procedures and on a separate piece of paper, write out what evidence is you think you might need, and then continue. So continuing with our example of the client says, I don't know much about auditing, but here's some evidences that I can provide you. Let me know which ones are sufficient and appropriate for you. Select all that apply. So feel free to pause the video to think about what options and evidences your need from the client base on the procedures from the video noted earlier. After you selected that, keep playing. So ready, 321. So the answers are B, C, and F. So the reason is that we take a look at the procedures and we can see that the first two steps specifically asks you to obtain a listing of users provision in the ADA period and also a role-based matrix. But in third audits step, it also requires you to obtain evidence of the sample users approvals by the managers. Although this isn't explicitly stated, you know that your need as evidence because you needed to test attribute a. Therefore, you need these three types of evidence. Now for attribute B, the evidence would have been satisfied by auctions sees Role-Based Access Matrix document, which is obtained as part of step two. 21. Learning Scenario #3 How to test controls with evidences: Let's take a look at another example. This time you are testing the control. Alright, I got the required evidence and a sample. I was one of how I should test my first sample for attributes a and B. Here are the evidence and the test procedures. And we'll show two pieces of evidence. And then afterwards I will show two options which you will need to decide whether the testing is conducted properly based on your inspection of the evidence. So below is a piece of evidence of the approval for one of the sampled users. To good luck. Next is the row matrix. Again, take a good look at what this is. In work papers and tests and templates. Auditors must demonstrate how they tested their controls and samples. In here we can see two options of how the sample was tested, documented. Now, based on your knowledge of the procedures in your inspection of the evidences earlier, which one is right? And pause and review. Once you determine the answer, click and play again. Ready? 321. The answer is option a. And the reason is that if you look at the evidences In the EMA approval, the manager has provided their approval for the employee, which satisfies attribute way. However, if you look at the level of access granted to the employee will change, including Credit module, a RAP module, expense module, and FR module and compare it with the Role-Based Access matrix. You can see that the Credit module should not be provided for junior accounting rules, which the employee and the sample has a junior accounting role with these axis. Now therefore, we have to say that this axis is not appropriate for attribute B. And this would then create an exception in our result. 22. Understanding Fieldwork Activities and Cyber & IT Control TechnicalRoadmap: This now comes down to the last section of the course which we will go over the audit fieldwork activities in more detail with practical examples and also some cyber 90 technical knowledge. 23. Understanding Auditing Fieldwork Activities: Quick revisit of the RFQ work activities show us that there are four main areas that we can understand and how fieldwork is conducted. The first seven walkthroughs, The second is requesting evidence and obtaining them, and the third is controls testing. And finally, the fourth is review and follow up. 24. Knowing how to conduct walkthroughs: In a walkthrough, as you already know, these are meetings or interviews with the auditor, meets with the control performer or the owner. And the intent is to ask questions about the control and process. Really observe an example, an instance, and how the control works and also clarify any questions and ways to obtain evidence for operating effectiveness. And the reasons that when an auditor audits new clients who controls, they don't have much knowledge and the control specifics. And in this case, a walk-through either helps reconfirm some assumptions or provides an update on how the auditor understands show. So one of the best ways is to conduct a walkthrough is to really prepare a list of questions. So here's a list of questions I use myself during walkthroughs. And this list of questions not only provide me an understanding of the control, but also gives me details to fill in control design factors. And you can download this attachment in your own leisure as well. Now, I also use these questions to us to remind myself to ask the control performer or the owner, show me how the control works and also allow me to set expectations and next steps. And you can take a closer look at these questions as well later on and reading them, you should also understand why you should be asking some of these questions. I put these two columns so you can take a look into further. 25. Knowing how to request evidences: The next is three requests less, which provides clients and RDDs are lists of evidence and questions that the ADA requires for the control testing. And it's important because during the audits to will be a lot of controls and evidence needed. So it's important to have an organized requests lists can manage these requests. Let's take a look at an example. So here's the request list, and you can see that there's many different columns. And the reasons that you have these columns to best organize and categorize so that the client can find what evidence you need. And some of the poor columns include having the Request details. So you need to specify an outline when exactly. You need to minimize confusion. Having the priority column is also important because haven't requested was Shouldn't a priority indicates your client that they need to work on certain things as soon as possible. I'll details like the requester owner day Request State they received and status are important to keep track of who requested and one is the requested and if it's outstanding or not. So this is massless. 26. Knowing how to control test: Sure. And control testing. There's several things that the auditor should be aware of is work papers because these are page Recent Documents which the auditor tests and attaches evidence alongside what paper, there are other supporting documents like the tests and Sheet, which provides documented testing results at the samples. And the sampling template, which provides details of the sample is selected and the population used by the auditor and the control. At the same time the auditor wash so have status updates that they need to provide to the client and oddity and the internal team on the progress and the issues of the audit. So external status is when the auditor provides updates to the client in oddity, whereas the internal status is 1D audit manager provides the status updates to the internal team. So let's take a look at some of these examples and you can download the download war attachments to follow along. This is the downloadable attachment control testing number one. So in the work paper, we can see that this is specifies the details of the control that we're testing and also the risk. We can also see that we have information about the walkthrough details. Alongside, we can also see that the SIM control design factors are listed and evaluated based on the verbiage and the walkthrough. I also documented and explained about the control design being affected based on my assessment in the seven design factors. Now in terms of implementation, you can see that I reference only which is operating febrile illness as being the same sample. And this is generally allowed. Now in terms of how I evaluated each of these control design factors, you can read more about it in the downloadable attachment and also assess how the walkthrough for a page is conducted. So scrolling down, you can also see that the word paper there specify procedures and we'll papers, the auditors wass document or testing. You can also see how the language of an auditor typically documents. For example, they use third person to describe how a procedures test it. And you can also see that auditors love to reference. And the idea is that referenced in items, the reviewer of the word paper can see where the auditor tested or what evidence the auditors looking at. Finally, you can also see that the wallpaper has conclusions for the operating effectiveness and that can control conclusion. Now in our example, our testing and this work papers based on previous user axis. And the idea is to test privileged users, obtaining users listings, and conducting attributes a, B, and C. So in our example, the auditor first step one, by obtaining the evidence. And we can see that the auditor obtains this generate lists of admin users and evidence tab dash one. So we go into this tab, we can see that evidence of the extracted lists of users is attained along the support to show completeness and accuracy. And you can also see that the auditor has inputted texts to explain the evidence. And this is one of the best practices because it makes it easier for the reviewer show. Let's go and take a look into the user listing here, we can see that there's actually five min users. So going back into the work paper tab, we can see that the auditor finally documents that the evidence is obtained and that there were no exceptions. But then we also notice that the auditor has talked about populations and sampling. Well, the truth is that the auditors can always test each and every instance of a population, so sapling as required. So the select samples fee at the sampling template. So let's go there and take a look. So in the sampling template, we can see that the auditor has specify the population sampling details and also selected a sample. Let's go back to the work paper tab and we can see that we need to test attributes a, B, and C. And this is conducted through the testing shape because now we have for sample. So we go to the testing sheet, we can see that the results are documented and that the attributes are tests as well. We can see that each of the attributes are tested and documented and also support it with evidence. For example, an attribute, a. The auditor indicated that the axis is appropriate based on confirmation from the manager and that they use is appropriate for such axis. We can also see natural PB that the auditor confirmed based on examination that the user's role is appropriate based on the user matrix and attribute c, since this sample is non-existent count it's not applicable. So let's take a look at the evidence is so in second evidence, we can see the confirmation from the IT manager. The IT manager is simply states that this is a written confirmation and that the user is appropriate and access and that they are reporting to the IT manager. We can also see and part number three that the row matrix specifies that IT ops in IT teams had him in axis. So all in all, this explains why attributes a and B are yes, and that the sample results have no exceptions. Now going back into the world paper, we can see the same results. And this is why the control is effective. Control testing dash T2. So this document is about internal and external statuses. And statuses are important because you need to communicate to bore for your clients and internal team members on the progress and any issues or standing items as well as statuses can be conducted through PowerPoint, Excel, Word, and other documents, it really depends on your team. So for internal status, there's a couple of things that you should be aware of. Those sample having things like dates, listen attendees, and also the overall status for the different phases of the life cycle. It's also important to discuss and less so the items that you want to talk about in your meetings, for example, if someone's going on vacation, you might want to specify that exceptions, findings in issues, and any other challenges are outstanding items you might want to bring that up. Next steps is also important because it sets a direction for your auditor's on the team to follow through. For example, someone needed to clear review notes to someone needed to do a certain task. Next steps is where you should document this. It's also important to have a detailed table that outlines the different Progress Status assignment of the controls. And last but not least, having a detailed list of the exceptions findings is important. Now in terms of external status, it's roughly the same. You might want to keep some of these in the higher level, for example, testing status, testing progress. You might just want to give a number and not go into too much detail as well. The findings and exception should also be communicated to decline as well because it'll be interested and how to rate some of these. And also the details. 27. Knowing how to review and follow-up: This comes down to the final audit fieldwork activity, which is Review and follow-up, which actually relates to quality control and the Audit project. So review notes and fall ops relates to auditors receiving review notes on their work papers by the reviewer. And this is usually the audit manager. And the auditor must fall up and address these review notes, ensure quality and the audit work now sine ofs and improve those really just demonstrate that the reviewer has conducted the quality assurance on the control testing and sign off and improve. Those are usually conducted by the Audit Manager. Lets take a look at some of these examples. Reviewing follow-ups so you can download the attachment to follow along. So in our example here, we can see that the reviewer has signed off and also provided their proven. We can see the date as well. In many companies and firms, they usually have this document in the system, but in our case, we have a documented and the Excel, which is fine as well. Now when reviewers GIF review notes, they generally have it by opening a comment right beside him and beat the areas that they have questions and the auditor would simply address. Now in some cases, the reviewer may have questions which the auditor doesn't have at this point. So then the auditor would need to follow up and follow it means really reaching back out to a client requesting for additional evidence, questions to clarify. And this is all in a nutshell, review or follow-up. 28. Overview of Cyber and IT controls: Alright, let's take a look at some examples of cyber AND IT controlled technicals. For the next set of slides, we'll concentrate on these four controls. These are privileged access, login monitoring system patching, and incident management. I will go over why does typically tests in these controls such as their attributes and also real-world examples of evidences. 29. How to test privileged access controls: Privilege access is one of the most critical controls because if a system has inappropriate axis, the entire system is compromised. Therefore, it is essential to secure the system. And below a typical procedures that the auditor may tests privileged user access. And the procedure is as follows. Obtain the user listing from the system. We're privileged users and supporting role based on design documents and verified the following. So for example, attribute a would be privileged users are appropriate access space on confirmation for management. Attribute B would be privileged users are appropriate based on their roles and duties. And attribute c would be System accounts in privileged users are superior to authorize individuals. So let's take a look at an example. In this slide, we have three sets of evidence and these are the usual listings. Evidence, a confirmation of approval and role-based access support evidence. The user listing in our example is a suitors less from Linux or Unix systems and a simply displays the users would privilege axis. And in the Unix and Linux systems, a term suitor as the same as privileged users. In this case, you will first identify users that have access, which is the root and the groups we owe, and sysadmin and Unix and Linux hashtag signs are really just comments. So if you see a hashtag or a number sign in front of a line of code. This is just a comma and does not impact the system. Taking this information, we will know that these are the groups and users as a mint. So now in the second piece of evidence, this is an example of a system repository that stores results monthly user access reviews. Earlier in our examples for user axis, we generally use email confirmations to prove that axis was appropriate for users. In this case, the oddity or the client has multi-user access reviews. And we can actually use this evidence to ascertain this same set of support that the user has appropriate axis. Now in this case the client in oddity hazard repository, which shows us the admin users that have access and the uses that also have access to the system accounts. Moreover, at asha shows us that there was a tested on a certain date by management which confirms that the accounts are appropriately attested. So this is evidence that can satisfy both attributes a and C. The last piece of evidence is simply a policy for page which slightly is different than a row matrix that we saw earlier. In this case, the policy can be used as evidence because it outlines how privilege axis is governed and use. It simply indicates that privilege accounts are only system counts and that the system count can be accessed only by team members. And this is true if we take a look at evidence number two, where the IT ops team have access to the root account. So overall, this satisfies attribute B, and this is an example of how the procedures and evidence is used to test privilege access. 30. How to test incident mgmt controls: The next is incident management. Incident management typically involves issues, events, security incidents, and even production issues. And the goal of incident management is habit the issues resolved by the applicable IT teams. Typical procedures that is generally test for NCD management involves obtaining the lists of instant tickets and alerts for the audit period and for sample fair phi the following. So for attribute a, incidents are resolved within a timely manner. Actually be, be, incidents are properly resolved by a football teams. So let's take a look at an example. Here we have three pieces of evidence. In our example, we have an incident take it, which outlines the issue, incident number and any other information, incident tickets on good evidences because they provide an audit trail and how the incident first occurred, actions taken and also the resolution dates. In our example, the incident taken is related to job failure. Next, we have evidence of timely resolution and the instant ticket ASU generally displays when an incident has been resolved and when it is opened. And the best way to determine timeliness in a resolution is by comparing the open unresolved dates. And in this example, this evidence most satisfied attribute a. The last piece of evidence is evidence that the incident is resolved by the team. In this case, the incident ticket, which only half the information along x indicating that the actions taken by the football team to resolve. Now having just the IT team confirm that it is a job, it's generally not sufficient. So the other piece of evidence that we need as having screenshot of the job being resolved in this case. So we can see that the job was indeed resolved before the incident ticket was marked as resolved. And these two evidences satisfy attribute B. So this is an example of how to test incident management and also an example of job feel their incident evidence. 31. How to test patch mgmt controls: The next control is patch management. Patch management is important in security aspects because it enables a system to address vulnerabilities that may exist due to flow coating backdoor or weaknesses in the system that can be exploited by hackers. And the best way is to reduce vulnerabilities on system is patch it regularly. Typical procedures to audit patch management involves obtaining the less of latest patches and verifying that, for example, attribute a server was Patch accordingly based on the latest published security patch attribute B, sugar was patched consistently per process. Let's take a look at an example. Below are two pieces of evidence. One is Microsoft Les Apaches, and this is a monthly listing Apaches in Microsoft, this vendor releases monthly patches, which includes security updates, fixes, and other items. A second piece of evidence is a history. Apache is installed on the Windows server. So if we were to verify if the Windows Server has the latest patches and has been patchy regularly. We can see that the history patches matches the patches published on Microsoft. Moreover, because the server was patched on a monthly basis, we can see that the server is likely patched regularly and this satisfies attributes a and B. And this is an example of patch management procedures and also evidence. And I'm window less sugar. 32. How to test logging and monitoring controls: The last control that we will go over is logging and monitoring. Logging and monitoring is a detective control that track security events. And the goal is to detect these events and properly addressed them. Typical procedures include obtaining the listserv, logging alerts, use cases, and corresponding alerts for the other period. And from a sample, verify that actually a logging alert use cases is enabled and configure to generate annular attribute B, alertness responded by the QuickBot security team. So let's take a look at an example. Here are some examples of the evidence. That first piece is I will go over is the configuration of logging Use Cases in alerts. In this example, this is a logging monitoring systems. Solar, for example, Splunk trip wire would have these alerts and use case configurations. But in our example here, the use case alert is for failed login attempts. And if a user's detected to fail login over five times, the alert is triggered and this will satisfy attribute a. The next piece of evidence is an example of an alert actually happening. And in this example, the system has in alert because it detects that the user had five logins. The evidence is also contributes to support attribute a. The last piece of evidence is that the security event is investigated or resolved. In our example, this is a snippet of a related incident which shows that the security team had investigated this security events. In most cases, having security or incident ticket would be fine. And this evidence.satisfies to attribute b over r. This is an example of the logging and monitoring of security events, procedures and evidences for auditing. 33. Summary and Credits: This now comes down to the end of the course and your lessons learned. There are three sections that we went over. The first section we talked about what does IT auditing control testing. And we mainly went over the audit lifecycle and also few work. We also talked about basic controls testing concepts such as how controls are tests and procedures. First methods, Audit Evidence, population for samples, exceptions for his findings. And also we went over the file structure. And the second section of the course, we talked about assessing control design and went over the same controller design factors. We also looked at assessing control operating effectiveness and went over several learning scenarios. Last but not least in section three, we talked about ADA field work activities. We went over walkthroughs, evidence requests is control testing, and also reviews and follow-ups. And last but not least, we also went over CyberKnife IT technicals for controls. So thank you for learning, jumped to it in your cyber 90 odd and, and career. If you enjoyed this lesson, have suggestions for more topics or even have feedback. Please rate and comment. Actually beats and credits.