diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S01-Course-objectives-and-structure.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S01-Course-objectives-and-structure.md index fbf049e..18ce008 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S01-Course-objectives-and-structure.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S01-Course-objectives-and-structure.md @@ -12,6 +12,8 @@ status: active ## Abstract +This session introduces the PECB ISO 27001 Lead Auditor training course, delivered by instructor Nathalie Klaas. It outlines the course objectives, which include understanding ISMS concepts, interpreting ISO 27001 requirements from an auditor perspective, and planning, conducting, and closing compliance audits. The course covers seven competency domains and is grounded in ISO 19011, IIA, IFAC, and GAAS best practices. Certification prerequisites include passing the exam, five years of professional experience, and 300 hours of related activity. The session also introduces PECB as a global certification body and explains the digital badge system via Credly. + ## Transcription Hi, my name is Nathalie Klaas. I'm from Belgium and I have my own company in Belgium. Where I help organizations with the implementation of ISO 27001 and ISO 9001. Besides the implementation um projects that I do. I'm also an external lead auditor for ISO 27001 and ISO 9001. Besides my work for customers, I also teach at university and of course for people This training course is intended to help participants strengthen their knowledge and skills which help them when auditing an ISMS. So from an educational perspective, competence consists of the following three elements, knowledge, skill, and behavior. So we will be working on all three of them. By the end of the course, you will be able to explain the fundamental concepts and principles of competence. An information security management system based on ISO 27001. You will be able to interpret the ISO 27001 requirements for an ISMS from the perspective of an auditor You will be able to evaluate the ISMS conformity to ISO 2701 requirements in accordance with the fundamental audit concepts and Principles, you will be able to plan, conduct and close an ISO 2701 compliance audit, and you will be able to manage an ISO 27001 audit program. In section one, we will be talking a little bit how the training is structured, what are the objectives of the structure, and of course we will talk a little bit about the examination and certification. alongside with some explanation about PECB. Now this course is really intended to help you to be able to conduct an ISO 27001 audit. So by the end of the training course you will be able to explain and understand the fundamental concepts and principles of an information security management. System based on the ISO 27001. You will also be able to interpret the ISO 2701 requirements from an ISMS from the perspective of an auditor You will be able to evaluate those requirements in accordance with the fundamental audit concepts and principles. You will be able to plan, conduct, and close an ISO 27001 compliance audit in accordance with the ISO 17021-1 requirements, ISO 1911 guidelines, and other best practices of auditing. And finally, you will be able to manage an ISO 27001 audit program. From an educational perspective, competence consists out of knowledge, skills, and behavior. So we will be working on those three elements throughout the course. The training course for an ISO 27001 lead auditor is intended for both internal and external auditors. The necessary competences for internal and external auditors are common throughout all types of audits. The characteristics of the different types of audits will be explained during this training course. Internal audits will be discussed in a dedicated section in the last day. The objectives of this training course is to really help you to acquire that knowledge on audit techniques and not acquire expertise in information. security management. However, basic knowledge of information security management concepts is necessary to be able to conduct a successful audit. Now when going through the course, we will do a couple of notes, you will get a lot of examples, you will be able to do a lot of um readings as well so when you want to have some little bit more information because this is an online course of course you will not be able to have discussions with the participants But you can find additional information on the PECB website, where you can find additional worksheets, additional articles and toolkits where you can find a lot of information that will help you Grow your knowledge even further. This training course has been created when looking at the best practices in a couple of areas So the course is really based on ISO 1911, which provides guidelines on auditing management systems, including the principles of auditing. ISO 1911 also talks about how you should manage an audit program and how you should conduct management system audits, as well as guidance on the evaluation of the competence of individuals that are involved in that audit. process. So it applies to all organizations that wish to conduct both internal and external audits. We also had a look at the International Federation of Accountants This is a global organization which is focused, as the name states, for accountant. It operates in more than 130 countries with over more than 175 members and associates to protect public interest by encouraging the use of best practices in accounting. So standards developed by the IFAC provide guidance in the following fields, so it's audit, insurance, control and services related to quality, training, ethics and accounting. We also use the Institute of Internal Auditors. This is a global organization that advocates, educates, and connects internal auditors worldwide. It also develops international guidance almost exclusively for those internal audits. This guidance is based on careful analysis consultation and the fundamental principles concerning the performance of internal audit services by members of the Institute of Internal Auditors. And lastly, we also had a look at the generally accepted auditing standards, which are auditing standards developed by the American Institute of Certified Public Accountants including general standards, standards by activity sector and reporting standards with interpretation. So you see we have based the content of the course of a lot of worldwide best-known best practices To include it in the training course. Now, when talking about the exam, after you've completed the full e-learning course, you will be able to take an exam. The exam will be focused on the seven competency domains that We will be talking about throughout the course. So let me walk you through the seven competency domains. First of all, there will be questions about the fundamental principles and concepts of an information security management system. Of course, there will also be questions about security management system requirements. There will be questions about fundamental audit concepts and principles. Fourthly, there will be questions about preparing an ISO 27001 audit, as well as conducting an ISO 27001 audit and closing an ISO-2111. 27,000 audits. And lastly, you will get some questions about managing an ISO 27,000 audit program. So the purpose of the certification exam is really to evaluate whether candidates have to grasp the audit concept and techniques so that they are able to plan, manage, conduct an audit program and as well lead a team of auditors. The PECB Examination Committee ensures that the exams questions are adequate and based on professional practices. So all of the competency domains as I stated will be covered during the exam. If you wish to get more information on how the exam is set up, how the examination works, you can also find a little bit more information On the PECB website. Passing the exam is not enough to earn your certification. It is, of course, the first step, but you need to meet all the prerequisites for certification. So, to get a PECB ISO 27000 lead auditor certified, you need to have a couple of things that you need to do. These prerequisites will be discussed later in the course as well, but I'll walk you briefly through Through them. So, first of all, you need to pass the exam. Secondly, you also need to adhere to the PECB Code of Ethics. You need to have at least five years of professional experience of which two of them are related to information security management. You need to be able to present at least three three hundred hours of related activity, so related to information information security management and auditing. You need to provide two professional references that will be checked by PECB. And if you have done all of those of If you checked all the boxes of those prerequisites, you will become a PECB ISO certified ISO 27001 lead auditor. And obviously, after you received your certificate, you will need to maintain your certificate. certification. More information about that will also be given later on in the course. The PECB certificate will look like the one that you have in front of you on the slide So we'll you will receive that um through via your PECB dashboard. So you will be able to find it there. You will be able to download in a PDF format, and you will also be able through the PEC PCB dashboard to gain your credly digital badge because PCB partnered with Credly, so it will allow you to also download that digital badge which you can use on your resume or on your digital media media like LinkedIn to also show to your network that you have achieved a new certification. Lastly I want to talk a little bit about PECB PECB is Professional Evaluation and Certification Board, is a certification body that provides education, certification, and certification. certificate programs for individuals on a wide range of discipline. Besides the training programs, PCB also offers PCB skills, which is a new format where you can find snackable content in a wide range of expertise. And you have also the piece store where you can find a lot of um useful um uh standards as well where you can buy the standards but also white papers articles toolkits and so on The mission of PECB is really to provide their clients with comprehensive examination and certification services that inspire trust and benefit the society as a whole. Their vision is to become the global benchmark for the provision of professional certification services, and their values are integrity, professionalism, and fairness. PCB helps professionals show commitment and competence by providing them with valuable education, evaluation, and certification against internationally recognized standards. Their principal objectives and activities are establishing the minimum requirements necessary to certify professionals. Reviewing and verifying the qualification of applicants for eligibility to be considered for the certification evaluation. Developing and maintaining reliable, valid and current certification evaluations, granting certificates to qualified candidates, maintaining records and publishing a directory of the holders of valid certificates. Establishing requirements for the periodic renewal of certification and determining compliance with those requirements. Ascertaining that our clients meet ethical standards in their professional practice and lastly representing its members where appropriate in matters of common interest. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S02.1-Introduction-to-management-systems-and-ISO-27000-family-of-standards.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S02.1-Introduction-to-management-systems-and-ISO-27000-family-of-standards.md index df06b88..cd1d6dc 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S02.1-Introduction-to-management-systems-and-ISO-27000-family-of-standards.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S02.1-Introduction-to-management-systems-and-ISO-27000-family-of-standards.md @@ -12,6 +12,8 @@ status: active ## Abstract +This session introduces ISO as a global standards body and explains the ISO 27000 family of standards. It traces the family's origins from the British Standard BS 7799 through to the current ISO 27001:2022, and provides an overview of related standards including ISO 27002 (controls guidance), ISO 27003 (implementation guidance), ISO 27005 (risk management), and ISO 27701 (privacy extension). The session explains which standards are certifiable and which are guidance-only, and outlines the business advantages of implementing an ISMS, including improved data protection, compliance, risk management, and security posture. + ## Transcription Section 2 introduces you to the International Organization of Standardization, short for ISO, and provides an explanation of management systems and a definition of an ISMS. It also provides you with a summary of the development of ISO 27000 family of standards and elaborates on each of them. In addition, the advantages that organizations can obtain by implementing an ISMS based on ISO 27001 are also discussed. And lastly, we will also give a short explanation. On legal and regulatory conformity throughout the world in this section. So let's start with what is ISO. So ISO stands for the International Organization for Standardization. And it really consists about well, it's an international organization of national standards bodies, and it consists out of uh whole 160 countries So 160 countries contribute to the ISO organization. The final results of ISO works are published as international standards. And since the beginning, which was 1947, ISO has published over 24,000 standards. So I usually say if you can think about something, there will probably be a standard available for that. Now ISO applies a couple of principles when uh developing international standards. So firstly there needs to be a need in the market So ISO response to that need in the market. So that either comes from something that they see themselves or from formal requests. from industry sectors or stakeholders that can also be consumer groups. Typically the request for a standard is communicated to national members within a country that then contact the international standardization. organization. ISO standards are always based on global expert opinion. So ISO standards are developed By various technical committees. And those technical committees consist out of experts from all over the world. And these experts really negotiate all the aspects of the standard. including what is the scope, what are the key definitions, what is the content that needs to be added. ISO standards are developed through a multi-stakeholder process. So the technical committees, they consist out of global experts, but they consist out of experts from relevant industries but they also include consumer associations, academia, NGOs and governments. So it's really a multi-stakeholder process. And lastly, which also explains why it sometimes can take up to a couple of years before an ISO standard is published or renewed, ISO standards are based on consensus So the development of an ISO standard is based on a consensus approach. So it takes into account comments from all uh stakeholders and um all ISO country members uh regardless of um the size of the strength of the economy have the same footage within um the organization so that means that it uh sometimes takes a little bit of time um before a standard gets approved or gets developed. Everybody knows of course the ISO 27001 standard because that is the standard everybody knows and that everybody wants to get certified against However, the ISO 27001 is part of a bigger family of standards, which is called the ISO 27000 family of standards. On the slide you see an overview of the different types of standards that you have. So not all of the standards that are part of the ISO 27000 family of standards are standards against which you can get certified. So let's have a look at what are the standards that are on the slide. And we will go a little bit deeper in each of the standards in the following slide. So firstly, everything starts with the ISO 27000, which is really a vocabulary or dictionary that gives an explanation of all of the Yeah, all of the words, all of the terminology that is used in the rest of the standards. ISO 27001 specifies then the requirements for establishing, implementing, maintaining, and continually improving an ISMS. ISO 27701 specifies the requirements and provides guidance for establishing, implementing, maintaining, and continuing Improving a privacy information management system, also called PIMS, in the form of an extension to the ISO 27001. So it's basically an add-on to the ISO 27001 ISO 27006 specifies the requirements and provides guidance for bodies that want to provide audits and certify certification of an ISMS. So your certification body. That you contact to do an audit will need to have ISO 27006 in place. Then you have a couple of general guides that really help you with implementing your ISMS So the ISO 27002 is the one that is mostly known with everybody, as commonly known. It's a set, uh it's a reference set of generic information security controls, including with implementation guidance. So it gives an explanation of the annex A controls of the ISO 27001 and it helps you in understanding how you could potentially implement Them. ISO 2703 provides explanation and guidance on ISO 2701. So it basically is the manual on how you should implement an ISO 27. ISO 27004 gives guidelines to help organizations come up with good information security performance indicators So it has a whole standard which gives you indication on what can you use to measure the effectiveness of your ISMS. ISO 27005 provide guidance on information security risk management. ISO 27000 And uh and seven provides then guidance on managing an ISMS audit program, how you should conduct audits, what are the competences that an ISMS auditor uh should have um and you will see uh parts of that coming back throughout this course obviously um and then you we have a couple of other ones so um and lastly we have the ISO 27008 uh which provides guidance On reviewing and assessing the implementation and operation of the information security control. So that's really linked to the ISO 2702. And then you have a couple of uh industry specific uh standards and you also have the ISO 2700799 which provides guidelines for organizations in the health information industry implementing the controls provided by ISO twenty seven thousand and two. And you have a couple of them you have uh one for the health uh sector you have one um which Is 27011, which gives information on the telecoms industry, and you have a lot of other standards that provide insight either per sector or either per specification within the realm of information. Security. Now looking at the development of the ISO 27000 family of standards is actually uh begins already um in the early 90s or in the middle of uh the the 90s where um the British Standard 7799 was published, which was actually a code of conduct that was published by the British Standards Institution. Many of these controls that were in that original standard are still visible in the ISO 2702. So the the British standard was basically developed by the UK government and by the Department of Trade and Industry. So that document provided really practices for information security management, and it was intended to help organizations establish and implement an ISMS and ensure the availability, integrity and confidentiality of their information. So Uh moving on, in um basically in 2002, so seven years later, the BS uh seventy-seven nine nine um was published, which was an uh specification of that uh first uh code of practice. Um that was um at the previously published uh 7799 became then the dot one um so it gave a little bit more explanation In the meantime, in 2000, there was also a code of practice on information security management published by ISO itself. So it already took some elements from the British standard. And that standard was then called the ISO 17799. So the specifications became a little bit more clear. Eventually all of these documents uh became adopted by the ISO standards. So where the um British Standard 779 DOS 2 became the ISO 27000 and one and the one version became um the ISO 27000 and two. So um this logically uh puts the requirements first and the code of practice and the guidance is basically uh second. Um they were uh later um so 2013 ish um they were um and uh as well in between 2008 and 2012 they were um yeah supplemented by uh several other ISO standards like the 2700345 um and other uh specific um interpretive guidance uh standards were created. where the latest version of the ISO 27001 and 27002 standard were published in 2020. So you see you see the the history of the uh 27,000 family uh goes already a long way back where um we recently had in 20 The latest revision. So let's dive a little bit deeper in each of the standards. First of all, of course, the most important one I would almost say is the ISO 27000M1 So this standard really gives the requirements for establishing, implementing, maintaining, and improving an ISMS The clauses are expressed with the verb shell. So that means that it is a requirement, it's mandatory, so you cannot choose to do it. It is mandatory, so you need to implement it. The standard is applicable for all organizations, though it doesn't matter which industry you're in, what size you're in, what type of organization you are, you can use it in whatever format that you like Organizations can obtain certification against this standard. So it really helps you with getting that ESMS. implemented um and as we already also explained in the lead implementer course of course and there needs to be a link when implementing the ISO 2701, there needs to be a link with your business strategy. It's not set up in isolation. Um, and you set it up to really um Yeah, preserve the confidentiality, integrity, and availability of information by really applying that risk management process And to give confidence to your interested parties and your customers, your employees, your shareholders, that risks are adequately. managed. Looking at the ISO 27002, this standard gives guidance. So that means that the clauses are expressed with the verb should So um it really looks at the annex A controls that are present in the 27001. So it gives a little bit guidance on What is um what is the control about? So it gives uh the context of each control and what is the reason why a control was chosen by um the International Standardization Organization. It will give some guidance on how you could implement a certain control within an organization. It will give some best practices and it will also help you in developing organizations specific organization uh security guidelines. So this is really guidelines and there's nowhere written that organizations um are mandated to implement the controls as they've been written down in the 27-2 standard, but it helps you to give some insight. side that also means that um you cannot gain um certification against the ISO twenty seven thousand and two standard I use this standard a lot because it helps you when you have a discussion with your technical teams, when you're stuck in how it something should be implemented in an organization, then you can have a look at the best practice and you you can start your discussion from that point in time. The 2703 is also a guidance uh standard um so it gives guidance and explanation on the requirements of an ISO 27001 So it basically contains also 10 clauses with clauses 4 to 10 exactly mirroring the ISO 27001. So This document um does not contain any new requirements, but it really consists out of giving you an indication on how you should be implementing the ISO 27001. So you get some insight on what is meant with context of the organization, what is the standard expecting you to deliver there. Since it's a guidance standard, you can also not obtain certification against this. ISO 27701. That standard or this standard is an extension to the ISO 27001 and the ISO 27002 specifically for privacy manner. So it provides, as does the 2701, but it provides requirements and guidelines for establishing, implementing, maintaining, and continually improving a privacy information management system. Which is also called PIMPS in short. It provides guidance both for controllers and processors, information on or guidance on that personal identifiable information processing. Organizations can also obtain certification against this standard. It's usually done together with an ISO 27001 certification. Like an ISO 27001, this standard is also applicable to all types and size of the organization. So both public and private companies, government organizations. um which are uh PII controllers or PII processors. Um so it it follows the same structure as the ISO 27000 ISO 27009 provides requirements for creating sector-specific standards as an extension to the ISO 27001. So it really gives an explanation on how you can include specific requirements additional to those in 2701 um how you should interpret the 27001 requirements and how to include or modify controls in addition to those in ISO 27001 and ISO 2700 So if you would want to create a new ISO standard for your specific industry and there's no ISO standard available yet, this is the standard that you want to have a look at to understand how you can create additions to the already existing. Existing one. ISO 27010 and everything that comes after 27010 are sector-specific standards. So you have specific standards for telecommunication, for health. For finance and insurance, but you have also ISO standards for specific sectors related to information security. So you will find ISO standards on application security on cybersecurity, on security incident management, on privacy protection, 27,017 and 18. are both for public and private clouds. So for each of them you will find specific ISO standards that relate for that. So if you look on the website of the of ISO, you can find all of them and of course you can also purchase those either on the ISO website or on the PECB website. Website, you can uh purchase them as well. But you can find um really on everything that you can think about in information security, like storage, like privacy, like um incident investigation, incident response uh you can find um uh a lot of um isost standards uh related uh to that Now when looking at the implementation of an ISMS, besides having the certificates, there are a couple of advantages on implementing an ISO 27001. Firstly, it will of course help you to protect your data. That's the basis, that's the reason why you do it. So you will have robust data protection, so you will have enhanced security measures. That protects sensitive data from unauthorized access, from breaches, from leaks. And you will also be able to assure that you have the confidentiality integrity and availability of your data ensured. It will help you to assure compliance First of all, as security practices are aligned with laws and regulations, because that's a standard element in the ISO standard, and you will also adhere to data protection laws. You will be able to make a step up in risk management. You will be able to identify and evaluate information security risks And that will able enable the organization to really prioritize and also proactively address potential threats. You will be able to implement security controls and incident response plans, and that will also minimize, of course, the impact. of potential security incidents. You will be able to improve your security posture. You will be able to better manage Your information security threats, and you will be implementing, of course, a standard that is internationally recognized with internationally recognized information security controls And you will be able to prevent certain security incidents from happening. Prevent the prevention of security incidents. uh is uh of course cheaper than uh recovering from a cyber attack. So uh the financial losses that would be associated with a security incident will be less And you will have efficient resources, of course, to mitigate those risks. So you will be able to do a better resource allocation in line with the risk management that you've done. So there is a multitude of advantages that are related to an ISO twenty-seven thousand and one implementation, besides having the certificate So when starting with an ISO implementation, the goal should not be having the certificate. It's a nice reward, but all the other advantages should be the reason why you implement I saw twenty seven thousand and one. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S02.2-Introduction-to-management-systems-and-ISO-27000-family-of-standards.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S02.2-Introduction-to-management-systems-and-ISO-27000-family-of-standards.md index 0048152..867beb8 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S02.2-Introduction-to-management-systems-and-ISO-27000-family-of-standards.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S02.2-Introduction-to-management-systems-and-ISO-27000-family-of-standards.md @@ -12,6 +12,8 @@ status: active ## Abstract +This session covers the legal and regulatory landscape relevant to information security and data protection. It explains ISO 27001 control 5.31 on legal, statutory, regulatory, and contractual requirements, and walks through key compliance areas including data protection, privacy, cybercrime, digital signatures, intellectual property, electronic payments, and records management. The session surveys major information security and privacy laws across regions, including GDPR, HIPAA, SOX, CCPA, LGPD, NIS2, and equivalents across Asia, Africa, and Oceania, emphasizing the need for organizations to identify applicable legislation based on where they operate. + ## Transcription ISO uh standards uh more specifically in the annex A, and we have a clause um 531 Which says legal, statutory, regulatory, and contractual requirements. So an organization needs to understand what are those requirements That are relevant for uh the business that you're in, the type of organization that you're in. So the purpose of that control is really to ensure that compliance. I still see a lot of organizations when auditing that don't really know what are the applicable laws and regulations that needs to be there. So whatever organizations should do is to start either with their legal counsel or they need to hire a lawyer to help them with that To understand what are all the laws and regulations that have an impact on the organization. That can be quite a lot depending on the organization that you're in there, but you need to uh check If you are compliant, you need to check what are the different countries that I'm working for. Are the countries, do I have all the laws and regulations? What specific clause in the law do I need to adhere to? And how have I tackled that? What are the specific processes? What are the policies that I use to be able to show that conformity So that ISO 27000 and one can really help you with that to really get a step up in that good overview of laws and regulations. Now there are a lot of key areas um especially nowadays it was different fifty years ago, but uh today There are a lot of key areas that should be considered. On the slide you see a couple of things that you really need to think about if they are applicable for your organization And let's walk through them one by one. First of all, data protection. Today there are a lot of countries. That have established data protection laws and regulations, think about the GDPR, that really aim at protecting, safeguarding data and data subjects. Organizations need to understand what is the law and regulation, and we need to have procedures and processes in place to ensure that we can protect that personal identifiable information. we can adhere to any requests that data subjects have and we can uh look at that. Related to data protection is of course privacy. Privacy, also in order to comply with certain laws, many organizations are also obliged to establish a policy for ensuring information privacy Throughout which they increase awareness of those statutory, regulatory, and business requirements regarding the treatment and protection of that personal information. So data protection and privacy usually go hand in hand. Cybercrime is another thing to consider. They encompass any illegal activity that is performed through a computer and network. And that is intended to really harm the organization system and gain unauthorized access to the data. Targeted organizations might experience financial and reputational damage In order to prevent and to respond to those activities, organizations should also establish procedures like an incident management procedure, um like uh ways uh for ethical hackers uh to provide them with information. Um so um protective measures as stated are are not considered as crime but also there you need to see what is applicable in your country. Sometimes ethical hacking um needs to uh adhere to certain um yeah specific guidelines and I'm talking from Belgium of course and Belgium it's it's only for one or two years that it's really legal uh to perform ethical hacking. Um and To communicate to an organization that you find some vulnerabilities. So you really need to check what is legal in your country that you reside and how can you take care of that in your organization. Dignital signatures is something else that is really something of the last years. We used to sign everything in paper. That time is far behind us. So an electronic signature today is um it it helps organizations of course to verify the um authenticity of a message or a document and by verifying the author. To check if the content has been modified. As a result, an electronic document that is digitally signed has the same legal validity as a hard copy. So, like a document document that is signed in handwriting, as long as there are regulations that give that full legal value to it. And some countries Electronic records must ensure the um preservation of uh traces as evidence of that integrity. So there you need to see okay what is the tool that we are going to use To provide those dignity, what are the certificates, for example, that are used, and what is the law again that we need to look at Intellectual property is something that you need to think about, both your own intellectual property and what how do you work with customers and how is intellectual property taken care of there, but also the intellectual property of your employees. Ensure that you have everything written down in contracts so that There is no reason to come to a conclusion later. Also, there I see a lot of companies that take care of the intellectual property with their customers, but forget that their employees also have intellectual property. Electronic payments. If your organization has a web store or something like that, electronic payments laws have been created as well. So you need to check if there is something that you need to adhere to there in ensuring that you protect the rights of the clients of which you receive those electronic payments. And then lastly we have the records management. Some national laws also require from organizations that they establish procedures for identifying, classifying, storing, modifying, and even destroying records ISO 15489. 1 delivers those specific contents or concepts and guidance that can help you in that records. So you see there are a lot of um key areas that you need to consider uh because there are a lot of uh relevant laws that might be there. So after um the so now we've spoken about the key areas Let's dive a little bit deeper into all the information security and data protection laws by region. For sure, not all of the laws have been added because that would lead us a little bit too far, of course. But um you do well um especially also when you're auditing um to uh have a general understanding about general laws that are applicable for on a country level at least And then you can still have a look. Companies need to know what is specifically for their industry applicable. So let's start with America, starting with North America. You have, of course, the HIPAA, which is the health insurance Portability and Accountability Act. It regulates the privacy and security of medical information in the United States So that's very specific for the United States. A lot of companies that are working in the United States and that have have their headquarters in the United States put those requirements also on European organizations. So it's not because it's applicable in the US that everybody who's residing in the EU is no longer falling under it. So HIPAA might be something that you need to take in. into account. So if you're auditing a finance company, that might be something that you want to check upon. Surveyus Oxley Act, a well-known act, short SOX regulates financial reporting and auditing requirements for public organizations in the United States. So public organization The California Consumer Privacy Act, the CCPA, that comes back if you're working with um US organizations, which is Is a little bit similar like the GDPR. It regulates how organizations handle California residents' personal information So it's only applicable to California. The New York State Department of Financial Services Cybersecurity Regulation, in short, 23 NYCRR 500 Requires financial institutions to establish and maintain a cybersecurity program. Personal Information Protection and Electronic Documents Act, which is called PIPEDA Regulates how Canadian private sector organizations collect, use, and disclose personal information And then lastly, the Personal Information Protection Act, in short, PIPA, is a privacy law that governs the collection, use and disclosure of personal information by private sector organizations in British Columbia and Canada. So you see and the difficulty in North America is of course you have different states and different states have different laws, so you really need to have a look on, okay, what are the laws that they're uh looking at. Then uh jumping over um to South America, um there are also a couple of things that are in place. Um so in Brazil You have the General Personal Data Protection Act, and it's a data protection law that regulates the processing of personal data in Brazil. So it applies to both Brazilian but also foreign organizations that process personal data of individuals that are located in Brazil. In Argentina, you also have a personal data protection law, uh, which is number uh 25326 And that addresses the collection, processing, storage, and transfer of personal data. And under this law, individuals have the right to access, modify, and delete their personal data held by the data controllers as well as the right to object for the processing. So you see a lot of things coming back that were also part of the GDPR And then you have in Peru also the data protection law, a Peruvian law that regulates the processing of personal data by individuals and organizations. And the law aims to protect basically the privacy of individuals by establishing principles and requirements for collection, use, storage, and transfer of personnel. Looking at Europe, um, first of all, the GDPR, well known, regulates the privacy and security of personal information for individuals within the European Union. The NIST2 Directive is an initial EU-wide legislation on cybersecurity designed to attain a uniform and elevated level of cybersecurity throughout the member states. And then we also have the EU Cybersecurity Act, which creates basically a unified system for certifying ICT products, services, and processes related to cybersecurity in Europe. Then going to the other side of the globe, Asia. In China, there is a cybersecurity law which regulates the security of networks and personal information. In China. In Singapore, we have the Personal Data Protection Act, which regulates again the collection, use, and disclosure of personal data in Singapore. In India, we have the Information Technology Act, regulates electronic transactions and digital signatures in India. In Japan, we have the Act on the Protection of Personal Information, which regulates the handling of personal information in Japan. And also in Japan, we have the basic act on cybersecurity. Which establishes basic policies for Japan's cybersecurity efforts and it formulates also a cybersecurity strategy and it effectively advances cybersecurity initiatives. In Africa, South Africa, we have the protection of personal information, is also a data protection law in South Africa, and it applies to any individual or legal entity that handles personal data. In Mauritius, we have the Cybersecurity and Cybercrime Act of 2021. That's a law that deals with cybercrime and cybersecurity. So the act provides also for different penalties based on the severity of course of the offense committed and it can include a fine not exceeding two million uh rupees and imprisonment even um for a term um not exceeding 25 years so that That's already pretty hefty. In Tunisia, we have the Organic Act number 2463 on the protection of personal data. It's a primary legal framework for data protection in Tunisia. In Ghana, we have the Cybersecurity Act 2020. It promotes a safe and a secure digital environment and it also protects critical information infrastructures and combats cybercrime in Ghana. In Kenya, we have the Data Protection Act 2019, which regulates the processing of personal data and seeks to safeguard the privacy and data protection of individuals in Kenya. And then we have in Nigeria the data protection regulation, in short, NDPR, established in 2019. It's really the first comprehensive Data protection regulation in Nigeria, and it sets out the legal framework for again the protection of personal data in Nigeria. And then we still have Oceania left. There we have the Privacy Act 1988, which governs the handling of personal information by Australian government agencies and private organizations. So it requires organizations really to have a privacy policy, but also to obtain consent for collecting personal information and to provide access to those individuals to their own personal information. To assure that their personal information remains accurate, of course. In New Zealand, we have the Privacy Act 2020, which regulates the collection and disclosure of personal information in New Zealand. It applies to all organizations, also including Including government uh agencies. And then in Fiji we had the Cybercrime Act of uh 2001, um the which was enacted by the Fiji government um and that criminalizes range of cyber offenses, including the unauthorized access to computer systems, cyber stalking and cyberbullying. So uh a lot of uh laws that um and acts that have been uh put in place uh across the globe. So When working internationally, it's a smart thing to check where are we working, where are we data transferring to and what potential legislation might be in place So you can reach out to legal counsel, to sector industry bodies that can help you understand what are the different legislations that are applicable. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S02.3-Introduction-to-management-systems-and-ISO-27000-family-of-standards.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S02.3-Introduction-to-management-systems-and-ISO-27000-family-of-standards.md index c5ab2f7..4ea1bc8 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S02.3-Introduction-to-management-systems-and-ISO-27000-family-of-standards.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S02.3-Introduction-to-management-systems-and-ISO-27000-family-of-standards.md @@ -12,6 +12,8 @@ status: active ## Abstract +This session explains what a management system is, defining it as a set of interrelated elements for establishing policies, objectives, and processes. It describes an ISMS as a systematic, risk-based approach to protecting information assets, linked to business activities. The session introduces integrated management systems (IMS) and explains how ISO standards share a harmonized structure (clauses 4-10), enabling organizations to combine frameworks like ISO 27001, 9001, and 14001 efficiently. It also surveys other certifiable ISO standards including ISO 45001, 22301, and 20000, and summarizes the key benefits of ISMS implementation. + ## Transcription So let's have a look at what a management system is. Now if we look at ISO 27000, a clause 341 gives a definition on a management. So a management system is a set of interrelated or interacting elements of an organization to establish policies and objectives and processes to achieve those objectives. So basically it's a very complicated, or it seems a very complicated sentence, but it isn't really All organizations have some form of a management system because it's just the way you operate your business. It's nothing more complicated than that. It's a way on how you operate your business. So a coherent and a well-functioning management system combines processes, resources, tools and workforce And a management system can be very complicated or can less can be very documented or less documented depending on the maturity of the organization. So again, a documentation is not a purpose in itself. An appropriate level of documentation is Preferable because it will help you to ensure that consistency, continual improvement, and retention of organizational knowledge Of course, an organization changes in the course of its lifetime. You have an internal and external context It changes so um the management system really needs to be um agile as well, and it needs to be able to respond to those changes as well. So whenever setting up a management system Very important to keep in the back of your mind is whatever is implemented must be controlled and measured and what is controlled and measured must be managed. And so the performance evaluation clause in every ISO standard is a very essential component of any management system. Because everything that you write down should be able to be evidenced So you always need to think really hard on okay, what is it what we're going to do, and am I able to measure and to see if the control or whatever management system that we've implemented, if it's working effectively When looking at an information security management system, the ISO 27000 also gives some explanation about that. So an ISMS consists of the policies procedures, guidelines, and associated resources and activity collectively managed by the organization in the pursuit of protecting its information assets So it's again a very long sentence. So an ISMS is basically a systematic approach for both establishing, implementing, operating Monitoring, reviewing, maintaining, and improving the organization's information security to achieve its business objectives. And it's always based on a risk assessment approach and the risk appetite or the risk acceptance criteria from the organization to effectively treat and manage those risks. So a couple of things that are very important here, so it's a systematic approach, and very important is that an information security management system does not live in isolation. So it needs to be linked to the business activities. And it's always based on a risk management approach and the risk appetite of an organization to really treat and handle those risks. Now, when an organization, and uh today I see it more and more happening, uh, an organization can handle Multiple compliance frameworks. I see organizations that have an ISO 9001, they start with the 27,000 one, and they also want to Include the fourteen thousand one. If you want to do that, you want to um look for uh implementing an integrated management system In short, it's IMS. And it's really a management system that integrates all the components of a business into one coherent system to enable basically the achievement of its purpose and mission. If you look at um the table on the slide, you see and that's also the reason why um ISO has uh made a lot of changes to their ISO standards to ensure that The clauses 4 to 10 in each standard are pretty similar to each other. That's also the reason why they're called a harmonized structure. So if you look at leadership and commitment, for example, you see that in the ISO 9001, 14001, 2020, 20,000 23001 and 27001, and it all comes back to clause 5. 1. And more likely, the text that is in that clause is the same Policy comes back in all the ISO standards in 5. 2. The same for objectives, you can find them in 6. 2 documented information is always 7. 5 internal audit always 9. 2 management review 9. 3 Only with continual improvement you sometimes have three subclauses like is the case with 9000 and 14001 where uh you have it in 10. 3 and with the other standards in 10. 2 But the information that is in the continual improvement clause is exactly the same for all standards. So that will help you to harmonize and optimize practice. because it doesn't make sense to write in three different management systems the same explanation for leadership, for example. Of course, for a policy, you can say, oh, I want to create three different policies, but the way you set up a policy, the way it needs to be treated in the organization, it's the same So it will help you, of course, reduce duplication and therefore costs, of course. It will also reduce the risks. It will increase Profitability, it will help you to maintain consistency and it will for sure help you with uh improving the communication as well. So you if you work with different management systems consolidating into one is the best practice because it will also help you in communicating to the organization because otherwise it becomes pretty complex for your employees to understand what you're actually are talking about. Now apart from ISA publications range beside the ISO 27001 organizations can get certified against a lot of uh primary standards So ISO publications range from traditional activities such as agriculture and construction to the most recent developments of course in information technologies like as digital coding of audio visual signals for multimedia applications. So there are um a couple of standards that the organizations can still get certified against Mo the most well known and um I always say the oldest, but that's because I get older, is the ISO nine thousand one, uh which is quality management system. Uh twenty years ago that one was uh really uh was well known, uh was um Required for a lot of organizations. Today I see less questions about ISO 9000 and an increase on 2700001, but also on ISO 14001, which is an environmental management system. With the rise with everything related to climate change um and environmental uh issues the ISO uh 14001 is gaining in importance again, but it's already a pretty old standard as well. You can certify against ISO 45001, which talks about occupational health and safety The ISO 37301 is a compliance management system. We have uh a food safety management system which is 22000. Um we have business continuity management. Um 22301 also on the rise. I see a lot of customers asking for uh the business continuity management system Of course, also spiked through NIST2 regulations, increasing regulation on incident response and operational resilience There is an anti-bribery management system, ISO 37000 and one, and there is also a service management system which is ISO 2000- So you see there are a lot of primary standards that can be used, of course. If I look at this, I would say 9,000 and 14,001 would be the the two that are uh pretty well known uh throughout the world um with um the business continuity management system as third runner up um So yeah, if you want to have more information on each of the standards, you can also visit the PECB website again to get a little bit more information on each of them. standards. So it was a pretty long section that we've spoken about. So let me summarize a little bit. So the International Organization for Standardization In short, ISO publishes standards in response to market demand. ISO standards are based on global expert opinion and consensus and are developed through a multi-stakeholder process ISO 27001 specifies then the requirements for establishing, implementing, maintaining and improving an ISMS and assessing and treating information security. Risks. Advantages of implementing an ISMS can include the improvement of organizational security posture, achievement of good governance, increase of international recognition improvement of customer satisfaction and an increase of competitive advantage. A management system then refers to a set of interrelated and interacting elements of an organization to establish policies and objectives and processes to achieve those objectives, and organizations can two or more management systems by integrating them. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S03-Certification-process.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S03-Certification-process.md index a33e06f..1ced836 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S03-Certification-process.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S03-Certification-process.md @@ -12,6 +12,8 @@ status: active ## Abstract +This session explains the ISO 27001 certification process from initial ISMS implementation through to certificate issuance. It describes the roles of certification bodies and accreditation bodies, and the standards governing them: ISO 17021 and ISO 27006. The session walks through the initial audit cycle, including the optional pre-audit, stage one, stage two, and follow-up audits, as well as annual surveillance audits within the three-year certification cycle. It also explains the International Accreditation Forum (IAF) and multilateral recognition, and warns against using non-accredited certification bodies. + ## Transcription Certified instructor and I just wanted to tell you a little bit about my background. So as you might be able to pick up from the accent, I'm based in the UK specifically I live near a city called York in the northeast of England. A little bit of background about myself from a career point of view. So I've been in and around technology and specifically information security since around around about the year 2000. I started life in the technical side of IT, doing IT support, so desktop and server support. Later on I moved into networking, spent a few years in that space where I got a real interest in security through implementing things like intrusion detection systems. Systems, firewalls, etc. Then she moved into more of the management side of security and worked for a number of years for the National Health Service in the UK, implementing standards like What at the time was BS7799, so the forerunner to ISO 2701. Since then I've worked for a couple of very large IT outsources and providing services to customers, doing things like ISO implementations, PCI DSS, developing security architectures and policies. And since then basically I now essentially work as a consultant, so I have clients that I'm still helping. implement security standards and frameworks. I also spend a bit of time as an auditor conducting audits against a number of ISO standards and of course as a trainer with a doing a lot of work with PCB like these courses Um so I hope to bring some useful knowledge and experience in the uh courses I'm delivering. Welcome to this ISO 270001 Lead Auditor course I just wanted to tell you a little bit about the training and its aims. So the aim of the lead auditor course is to give you a good introduction to the ISO 27001 standard, to give you an overview of how that works and the overview of a an information security management system but with a focus on actually auditing an existing management system. So throughout the course we'll look at key things like audit principles, procedures and processes And then basically we'll take you through the steps of initiating an audit, right through to making audit conclusions, and also we'll take you through what happens after the audit. We'll look at this from an external perspective, so we'll also uh uh examine how certification bodies operate and your role as a lead auditor within that. Okay, so in this section we're going to examine the certification process for ISO standards. So specifically we'll look at the process itself. We look at something called the certification scheme and then we're going to look at the role of two very important organisations in this process which are accreditation bodies And certification bodies, and we'll have a look at the difference with each and the purpose and the role that they play. So the first thing to take a look at here is this diagram that outlines the certification process. As I'll explain in a moment, this is the certification process that would be followed by what we call accredited certification bodies. So let's just have a look at this. So let's imagine we have an organization that wants to be certified To ISO 2701. First of all, of course, before any audit, they're going to implement their ISMS But not only implement it, the organization will need to check that its own ISMS is working effectively by implementing and conducting internal audits. and having the management review conducted as well. So let's imagine an organization has implemented its ISMS, it's had its internal audit and management review. At that point the organization will need to choose an organization called a certification body. We'll have a discussion on those in just a moment. Let's imagine the organization selected its certification body. We then have, for the very first time, an organization is going for certification, something called the initial audit So the organization of course will prepare for this initial audit. There is an option, but it is completely optional, to have what's known as a pre-audit. a situation where a cert body can do an initial review to see if the organisation is ready for the actual audit, so to speak. That's an entirely optional thing. But the first part of an actual initial audit is what we call the stage one audit. What I tell people in a stage one audit it's typically about 30%. of the overall audit time is spent at stage one. And the purpose of stage one is to allow the certification body and the audit team to get familiar with the organisation and to validate that the basics of the management system are in place. such as the key documentation, some of the key processes that are required. So let's for now just assume that everything goes well at stage one and we then move to stage two and there's usually a gap between stage one and two Which typically is about two to four weeks, although that can differ, but the idea of that gap is to allow for preparation for stage two And stage two is what I call the detailed audit. This is where the auditors are looking beyond the basics of the management system, but looking for real evidence that the controls, for example, that are implemented are really working. And during this course we will get into both stage one and two and the kind of activities as auditors we need to be performing. Now it says in the diagram here on-site audit. That might vary depending on the nature of the organization, but typically it is certainly an in-depth audit. Now, after the stage two is done, depending on the recommendation made by the lead auditor, a couple of things could happen. One of those is if the audit uncovers what we call non-conformities, it might, not always, because it depends on circumstances, but it might be be required to conduct something called a follow-up audit And a follow-up audit is where an organization is given the opportunity, for example, to address a non-conformity, and the auditor will essentially come back at some point in time and validate that that non-conformity has being addressed. Again, we'll get into the details of the process and when a follow-up is necessary and when it isn't, but that could happen in some cases. In some cases that won't be necessary at all. But let's imagine that the organisation has implemented its management system, has had a successful stage one and two audit It's at that point where, of course, the auditor could make a recommendation for certification and the certification body if they're satisfied that the audit has been conducted correctly. After a quality review of the audit report, it is the certification body who will ultimately issue the certificate to the organisation and certify their management system. And as we'll explain in more depth as we progress through the course, when an organization gets certified, they get certified for a period of three years, and every year in between there'll be what we call a surveillance audit. The certification body will validate that the organization maintained its management system. So during this course we'll look in depth at all these procedures, but for now I just want to give you that sort of high-level overview, if you like. So the question then becomes, well, who are the key players in a certification audit? You know, who is doing what? And actually this diagram here that lays out the certification scheme is a really useful one to understand the position. So what I want to start off by talking about is the role of what we call a conformity assessment body or certification body. Now there are multiple types of certification bodies that do different things. So for example, PCB are what we would call a personal certification body So they certify individuals. So when you take your PCB Lead Auditor exam, for example, and you pass that, it's PCB who will award you as an individual professional your certificate. But in this discussion, we're really focused on a different type of conformity assessment body called management system certification bodies. So a management system certification body is usually, not always, but usually a profit-making organization. There are some that are not. And their job basically is to go out and conduct audits of management systems to ultimately certify organizations against various management systems. System standards. And there are many conformity assessment or management system certification bodies operating. And so the question you might ask is: okay, well, if we've got a management system certification body issuing certificates, how do we know that the certificates that they're issuing are credible, that they'll be recognized by people And how do we know that the certification body is trustworthy and professional? And all these very important questions. So to answer that question, there is a standard that certification bodies can follow, and that's called ISO 17021 And this standard lays out various rules about how certification bodies operate to ensure that they're operating in a credible, trustworthy and professional manner. Those certification bodies can themselves be audited by a separate organisation. And that separate organisation I'm speaking about is something called an accreditation body. So around the world in most countries there is usually one and one only accreditation body which is usually appointed by government and their job is essentially to supervise the activity. of certification bodies. Now I say usually there's one and one only. That does differ for the US who have three or four essentially, but in most countries there's one. And so the idea is: let's imagine I went away tomorrow and decided to set up a management system certification body. If I wanted to issue certificates that were valid, recognized, and trustworthy I'd need to implement ISO 17021. If I want to issue ISO 27001 certificates, I'd also need to implement another standard called ISO 27006. which lays out how certification bodies who issue ISO 27001 certificates need to operate. And then what we'd need to do is we need to go and approach an accreditation body and ask them to audit us and accredit us. So the key thing here is certification bodies get accredited by accreditation bodies certification bodies certify organizations management systems. Now it's really important to note that if an organization chooses a certification body that is not accredited, then you could argue that the certification they're issuing is worth precisely zero. And we have to be careful with this because Whenever you're selecting a certification body, it's always important to ask them, are they accredited to issue ISO 27001 certificates? i. e. , are they accredited under ISO 17021 and ISO? or 27,006. Second question is who are they accredited by? Now this is the important point. So I said that around the world in most countries there's one and one only accreditation body So how do you know who that accreditation body is so that you can actually check that the certification body is properly accredited? Well there is an organization called the International Accreditation Forum And you can find their website, it's www. ieaf. nu. If you go to that website and look under members and signatories, you can search by country So you can find in each country who the national accreditation body is for that country. So if somebody tells you we are accredited by UCAS in the UK, Well I could tell you straight away that's genuine, but of course you could go to the IAF website and check that it is indeed UCAS and then you could go to the UCAS website and see whether that certification body is listed. One important point to make about this is it's not a requirement for the certification body to be accredited in every single country in which it operates. Let's imagine a large certification body that operates all over the world. It wouldn't make a lot of sense if they had to be audited in every single country they operated in. So the IAF does have this thing, the International Accreditation Forum Called multilateral recognition. So for example, a few years ago I used to work for a German certification body who operated in the UK and they were accredited in Germany by DAX, which is the German accreditation authority. But those certificates were recognized in the UK because DAX and UCAS, which is the UK equivalent, are both members of the IAF and both sign that multilateral recognition agreement. So that's also something to note. So the main important point that I'm trying to get across here is select a certification body that is accredited by a member of the International Accreditation Forum. Uh and my final sort of word on that is do be careful to check those things because unfortunately, as I've experienced, there are certification bodies operating who are not properly accredited and I've even seen cases where there are some certification bodies who claim to be accredited, but then they're accredited by organizations that are not members of the IAF. In any of those circumstances It's unfortunately a case that that certificate may not be recognized. So just make sure when you're investing you can you know work well with the certification body in question So in summary then, what we've confirmed is there's a formal certification process that exists A certification body that is accredited based on what we've discussed in this section will follow the process that we presented at the start of the section. That is to say, conducting a stage one and stage two audit, and they will certify an organization assuming they're successful for a period of three years. Certification bodies certify management systems and the standards they should be following are ISO 17021 and ISO 27006 and accreditation bodies are the organisations who supervise the activity. of certification bodies and we should always select an accredited certification body to have an assurance about the audit process and the credibility of the certificate that's going to be Be issued. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S04.1-Fundamental-concepts-and-principles-of-information-security.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S04.1-Fundamental-concepts-and-principles-of-information-security.md index f303047..7161ccf 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S04.1-Fundamental-concepts-and-principles-of-information-security.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S04.1-Fundamental-concepts-and-principles-of-information-security.md @@ -12,6 +12,8 @@ status: active ## Abstract +This session introduces core information security concepts from the ISO 27001 perspective. It defines information assets, documents, specifications, and records, and explains ISO's definition of information security as the preservation of confidentiality, integrity, and availability. The session explores each of the three CIA pillars in depth, including practical examples from healthcare and industrial control systems, and clarifies that relative importance of each pillar depends on organizational context and risk. It also explains how availability depends on redundancy, monitoring, physical security, and business continuity plans. + ## Transcription So in this section we're going to look at something we've called the fundamental concepts and principles of information security. Now of course I appreciate that many people looking at this training may well have a security background already, maybe you've you've got a lot of experience or other certifications and so forth. And the idea of this section isn't to sort of repeat what you may already know or to reteach the same thing. The idea is is to make sure that we're all speaking the same language and in particular from an ISO perspective. So the idea of this section is to introduce the sort of terminology and meanings, if you like, that uh ISO 27001 contains so that as we go forward When we start talking about auditing a management system, we can all understand the meaning of different terminology. So what we're going to look at in this section is the concept of information assets and information security according to ISO 20. The three tenants of security that ISO 27001 speaks about, which is confidentiality, integrity and availability. And we'll also look at the risk terminology, things like vulnerabilities, threats and consequences and how all these relate to the topic of risk. We'll also have a look at security controls because as you know the standard has annex A with multiple controls and we'll talk about how those controls can be classified and thought of. And we'll also examine the topics of cybersecurity and information privacy because you'll have noticed in the title of the standard it does refer to both cybersecurity and privacy and information privacy. So what do those things mean and how do they fit into the ISO information security concept? So let's start with information and asset then because one thing that ISO 27001 says is that we're trying to protect our information assets. So we can get the official definition of these two words from ISO 9000, basically a quality management series of standards, and ISO 55000, which is the asset management series of standards. So I think most of us would accept hopefully that information is meaningful data, that is to say data that we can do something with. So if I've got a customer database. containing customer records, you know, names, addresses, order histories, etc. That has some meaning, some use and some purpose. And an asset, we we typically say an asset is something that has value Now when I say value, that might be a financial value, something you can sell an asset for, for example, but it can also mean value in terms of usefulness and service to the organization. And most people, I would imagine, if I asked them what an asset was, would probably think of something tangible, you know, a c a computer, a building, some equipment, etc. And they'd be correct But also assets can be intangible. So actually the people who work for your organization are assets and ideas and intellectual property and of course information And even if I can't sell information for a you know a dollar, euro uh fee, so to speak, it still has uh a value to the organisation, hence the term asset So ultimately an ISMS based on ISO 27001 is about identifying those assets, those pieces of information, those you know, uh data sets, etc. , working out how valuable they are, and then essentially protecting them accordingly Now when we think about information assets and we think about running an information security management system, there are some other terms that we just need to be familiar with. The concept of document specifications and records. Now of course it might sound a little bit odd to uh tell you what a document is, I'm sure many people can imagine that, but there is a general saying which is a document is the information and the medium upon which it's contained. So yes, you could be thinking about a traditional Microsoft Word document here, but equally a confluence or a wiki page with information that we follow would also, in ISO speak, be considered to be a document. And of course some of the documents that we create or use in an ISMS will state very clear requirements. You know, maybe I've got a document that states things like secure coding standards requirements. for example or a document that says how a network device should be configured. And we would call that in ISO terminology a specification. And when an organization runs an ISMS and follows the requirements laid out in some of these documents. then essentially they end up generating records. So let's say for example you're running an ISMS and you have a process for reporting information security incidents. And let's imagine somebody follows it and they report an incident through whatever reporting channel. Of course then there'd be a record, there'd be some evidence that that process has been used. If you had a specification about how backups should be done and those backups run, of course there'd be logs generated, those logs would be records because they would serve as evidence that that activity is taking place. And records are very important in an ISMS, not just because the server's an audit trail, which is important. uh and certainly as auditors we'll be looking at records but also the fact is that records can be in their own right sensitive and need a certain level of protection. So an ISMS will concern itself with protecting documents specifically. and records. So it probably makes sense at this point to answer the question, what is information security? But more importantly, what is information security according to ISO 27000? And we have the uh the definition here which says Information security is the preservation of confidentiality, integrity and availability of information. And I'll come to that. And explore that in a little bit more depth in just a moment. Now the other thing that we we we say or ISO says about this is that information security is about determining what information needs to be protected. how it should be protected and from what. Now that would imply when you read that that that means that when we set up an ISMS we'll need to identify the kind of information we have. Trying to protect. And we'd need to do some kind of study or research into the potential risks that that information faces. So in other words, when we implement an ISMS, if I had two organizations implementing an ISMS They may protect their information very differently depending on the type of information we're speaking about and the type of risks they face. So the standard is flexible enough so you tailor your controls as needed. Now the other thing that's important in the definition about information security is the fact that it covers information in all formats. Now this is interesting. A little bit later in the section we're going to talk about this concept called cybersecurity. And certainly what I've noticed over the last few years when you look at job descriptions and you know, what a lot of people talk about. You hear a lot about cyber. And cyber of course is focusing very much on the technology aspects, you know, protecting the technical systems that will store and process information. And of course that makes sense because the vast majority of information today is indeed processed electronically. But it's not all processed electronically. It is still possible to have information in paper format, in video format, in spoken word, etc. So information security concerns itself with protecting that information regardless of format. And maybe a very quick example I could give. I recall having a train journey where on that particular train there was a solicitor from a law firm having a conversation with a client. uh quite openly for the entire carriage on the train to hear and s in and discussing some quite sensitive topics. It was actually discussing a divorce case with a client uh and basically pretty much with the phone on loudspeaker uh to you know revealing uh people's names, addresses, dates of birth, salaries, you know, a lot of very sensitive information which Let's say I or somebody else in that carriage was a cyber criminal, for example, or a fraudster, we could have gathered plenty of information to conduct things like identity theft. and so on. The point of that story is to say that organization for all I know, I don't know them, but for all I know they might have extremely strong cybersecurity. They may have, you know, um robust networks, strong application security, etc. But they've obviously still got some weak links in their information security program. In this case maybe the awareness of some of the employees who work for them So information security will concern itself with all those things. And ultimately the last thing to say before we look at this confidentiality, integrity and availability bit is of course when we look think about information security what ISO says is we're always focusing on the business objectives There is a saying that information security should be an enabler, not a disabler. So in other words, we're not implementing security to stop the organisation operating and achieving what it needs to achieve. What we want is the organization to achieve. to achieve what it's aiming to achieve but in a secure manner essentially. So let's have a look at this confidentiality integrity and availability bit and I just want to run through those and again I realize people have been in security for quite some time should be already familiar with this but again let's just make sure we're on the same page Now the first thing is that ISO says that these are the three pillars of security, the three tenets of security. But I must stress that when you set up an ISMS, you're not limited to just thinking about these three. things. These are the minimum three things you would think about. So just for those who might be in other industries, for example, if you're in a regulated industry where you need to have strong audit trails of activity and you're concerned about accountability, for example. There's no reason why we cannot implement controls and manage that through an ISMS. If you're an organization that's producing products or services and you're concerned about you know counterfeiting or piracy and risks like that. Um your controls to ensure authenticity, your digital rights management. authenticity management, etc. , can be considered. And similarly, if you're in the business of doing transactions and you don't want people to be able to deny activities, so you're concerned about non-repudiation those things can be considered. So my point is just because they're not explicitly called out by ISO doesn't mean that they don't matter or can't be thought about. But let's focus on the first three, the confidentiality, integrity and ability So what I typically tell people is imagine if you went outside and stopped somebody in the street who doesn't really know much about information security. Somebody who's not really in that space, and I asked them what is information security, probably I imagine the answer I would get back would be something like stopping unauthorized access to data or you know, um only allowing people access who should have access, something like that. I imagine the vast majority of people would probably focus on confidentiality, says the most obvious one. So indeed confidentiality is is exactly that, about limiting access to information to only those people who need it, about having control over information and and who can access it. And of course organisations can achieve that in many ways by implementing robust authentication for example, establishing a clear data access policy, having proper access control, perhaps using things like encryption or data masking, all of these are confidentiality techniques. But of course, whilst confidentiality is important, if we're building the argument that information is an asset because we use it to make business decisions, to respond to uh uh various problems and challenges, then we surely want some confidence that the information is actually trustworthy, up to date, accurate, and so forth. And that's where we concern ourselves with integrity. So integrity is about implementing controls that reduce the risk of unauthorized changes to data, data corruption. helps us ensure minimum data quality so that when we do come to rely on a system or the information it contains we can have a confidence within it. And whilst we were talking about confidentiality a moment ago, confidentiality is all well and good and we could achieve it by locking down all kinds of things, but it's not much use if Those people in an organization who need access can't gain access. So there's a balance and that's where we look at availability. So availability and the principle of it is about making sure information and systems are available as required when required by the right audience and of course some organizations will have very important um commitments on this you know maybe you have a commitment as an organization to ensure certain systems are available for a certain amount of time. So this is all about focusing on things like system resilience, ensuring that there's Where necessary, there's failover in place, so that we have disaster recovery and business continuity plans in place. Now whilst ISO says we should uh focus on those three things I think it's important to point out one point. It doesn't tell us which one of those is more important. This depends on the context of your organization and looking at risk. And a couple of very quick examples I can give on two two totally different industries. So of course I mentioned in my introduction that I spent some time working with the health service in the UK. So in that context Obviously confidentiality was very high on our radar, you know, respecting the patient's right to privacy, protecting very sensitive medical records. was right up there. But equally integrity was. You know, I always say to people, imagine a doctor treating a patient with inaccurate medical records or data that's been corrupted. You know, the consequence could be extremely significant. Separately, I did some work for an electricity distributor, so think of it like a national grid organization. And on that project we were doing an industrial control system security project. So what we were interested in was protecting essentially computer systems that controlled electricity substations on the on the uh power grid. Now for that there wasn't really a lot of confidential information. you know there's no patient records or customer data. Maybe the designs of the system were probably the confidential information we wanted to protect. Our focus was very much on system integrity, controls to prevent or reduce the risk of people tampering with those systems And of course availability. You know, if somebody could do a denial of service attack and bring one of those systems down, they could cause significant disruption in the country that we're speaking about. So that project was much more focused on availability. My point being, n neither of them are right or wrong. Both of them are perfectly compatible under ISO twenty seven thousand and one and it's all about focusing in the right areas and looking at the organisation priorities. Just speaking of availability, um this diagram here just tries to pin together the relationship between information availability versus confidentiality and integrity. So of course we have on the side here it says information security. So information security is supported by uh data confidentiality controls and integrity. If we think about availability, what we should say is availability isn't just about a system being up and running. It's about other things as well. A system may be up and running, but is it reliable? In other words, if I go to use the system, you know, is it still going to function correctly And timeliness and performance are all part of that. You know, let's say I'm um I'm an online customer going to a website, uh that website might well be there, but if I can't make, for example, a purchase because because of performance issues, then I still wouldn't argue that the system is available. And there are multiple things that support system availability. So the there are those things that prevent systems going offline in the first place, such as housing those systems in an environment with adequate physical security, your professional data center with fire suppression and um you know air conditioning and uh monitoring and all of those things. Having effective security policies in place which reduce the risk of actions being taken that could bring systems offline Designing systems in such a way that they're what we call redundant. So let's imagine we have a a hardware failure, that we don't just lose the system because of one hardware failure, that another piece of hardware Where um that kicks in. So even with networking, you can do that with firewalls, you know, you can have failover firewalls, for example. Uh making sure there's adequate monitoring. So these are all preventative things, hopefully to stop the loss of availability when things go wrong. And then of course in worst case scenarios, having adequate business continuity plans which lay out how we would recover. if something significant happened in terms of interruption and also thinking about backups and having adequate backups in place so we could recover from a trusted uh backup. Now one thing to say about all of the things I've mentioned, because I've mentioned them at a very high level, when we look at ISO 2701, uh how rigorous we need to be in each of these areas comes back to your risk assessment. So for example, ISO 27001 is not sitting. For every piece of hardware you must have an equal and uh uh opposite duplicate for example or that you must have two power feeds into your data centre etc you might determine that your availability needs are so high that that makes absolute sense and you need to invest in those controls. In other environments where the availability requirement may be less, then you can make different decisions. So ISO is not dictating here, but what it is saying is these are the areas to think about when it comes to availability So ultimately, yes, yes we're about protecting confidentiality and integrity, but we also want to make sure we have information systems we can trust and have a confidence in and have a confidence. That they'll be there when we need to use them. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S04.2-Fundamental-concepts-and-principles-of-information-security.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S04.2-Fundamental-concepts-and-principles-of-information-security.md index 5c821e2..d61dfd3 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S04.2-Fundamental-concepts-and-principles-of-information-security.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S04.2-Fundamental-concepts-and-principles-of-information-security.md @@ -12,6 +12,8 @@ status: active ## Abstract +This session covers risk-related terminology central to ISO 27001 auditing. It defines vulnerability as a weakness exploitable by threats, drawing on ISO 27005 examples across hardware, software, networks, people, and physical infrastructure. Methods for identifying vulnerabilities are discussed, including security testing, penetration testing, Common Criteria evaluation, and red/blue teaming. Threats are categorized as deliberate, accidental, or natural, and the relationship between threat sources, threat actors, and threat scenarios is explained. The session concludes by defining information security risk as the effect of uncertainty on objectives and linking vulnerabilities, threats, and consequences to the CIA triad. + ## Transcription So now that we've talked about confidentiality, integrity, and availability. We just need to focus on some other terminology that ISO brings to us, which is related to the topic of risk, because ultimately managing information security risk is what having an ISMS is all about. So let's just have a look at these terms again just to make sure we're all on the same page, so to speak. And the first one of those I wanted to speak about was the term vulnerability. And we'll look straight away here at the ISO definition of the term vulnerability, which says the following. A weakness of an asset or control that can be exploited by one or more threats. So what I tell people generally if I'm talking about vulnerability is exactly that, the definition, weakness. Let's go with a very simple example of vulnerability. Let's imagine I go out the house in the morning and leave my door unlocked uh you could argue that we have a security vulnerability. There is a weakness in security in that case. If I was to connect my laptop to the internet without any uh firewall or without any anti-malware control, I would have a series of vulnerabilities. or weaknesses. Now for those of you who've been in information security for some time and maybe have worked in the technical part of security, maybe you've done things like vulnerability scans using tools like Aqualis or OpenVAS and S's something like that. And of course if you've done that, you'd be very familiar with a lot of common technical vulnerabilities, you know, missing patches, misconfigurations. you know, default manufacturer passwords left on systems and various things. And you'd be correct to point out that all those things would be weaknesses or vulnerabilities. But I must point out that vulnerabilities are not just technical when we think about an ISMS. We can have vulnerabilities in multiple places. So if for example we have an organization that uh has flaws in its background checking process when it hires people, that would be a vulnerability. If I have an organization that has gaps in its physical security, in its buildings and premises, those would also be vulnerabilities. So what we've got here is a a table from ISO 27005, well more to the point, an extract from ISO 27005 So ISO 27005 is a guidance document on information security risk management. And when you look up a vulnerability in that guidance document, you can see there's a number of categories and some examples of vulnerability. Now this is not of course an exhaustive list, it's just there to help you understand the terminology. So we can see examples of vulnerabilities in multiple areas in hardware, software, networks, with people with buildings, etc. And so the real thing is in the the real world when we're looking at an ISMS we'll be looking at where we have vulnerabilities in an organization. Now one key thing I always tell people on this about wording is you can work out if something's a vulnerability by the kind of language we use. So this is true for the real world and if you're taking the exam and you see any questions that might ask you about vulnerabilities, for example, the key words we're looking for there is usually words like, as you can see, insufficient. missing, absent, uncontrolled, poorly controlled, etc. If I hear things like that, that typically tells me those are my weaknesses or my vulnerabilities Now, of course the question is from a practical point of view in the real world how do organizations identify vulnerabilities Well for non-technical vulnerabilities like say flaws in the human resource processes or physical security there may be specific assessments and reviews of processes that can reveal that. But if we think about technology, the security testing and evaluation is where we might look at particular components, let's say in a network. network equipment so let's take a switch or a firewall and we basically have uh some experts sort of take a look at that and identify weaknesses So for example, one piece of work I sometimes do for organizations is exactly that. So we'll take a firewall and we're not going to try and break into that firewall, for example. in this example but we're going to take a look at the rule set. We're going to look for potential holes if you like traffic that that's being allowed through that possibly shouldn't be. Perhaps we'll look for misconfigurations that we can see that may be open to manipulation or misuse. So security testing and evaluation is one way of doing that. We can also do more deep dive tests, you know, as well as doing vulnerability scans, we can try and prove whether vulnerabilities exist For vendors who are producing products that they're selling, they can go through quite a rigorous process of security testing and evaluation. One particular scheme that you may be familiar with is something called Common Criteria. So Common Criteria is a global standard. It's based on an ISO standard called ISO 15408. What this is, is a security testing and evaluation process. So let's take a vendor. So take one at random, let's say a company like Cisco, for example. So let's say that they produce a new firewall that they want to sell, and maybe they want to sell it to very specific sectors like healthcare or government, etc. They may make a number of claims about the security of that device. They can then take that device to a common criteria lab and there are a number of those listed, an official lab, and that lab will set about doing a number of very rigorous tests to validate the claims that are being made and at the end of those tests we'll produce a report and also an i an evaluation level rating. And the evaluation level rating isn't necessarily about how good the security is, it's more about the level of tests that have been done. done. But the vendor, assuming it's successful, can then state our product is listed on the Common Criteria Portal and it's had this level of evaluation. And a customer can then go and look at the report and understand what testing's been done and what vulnerabilities may or may not have been addressed. So that's Obviously a very specific example. There are other schemes out there like that. So you can do your own testing, but there are independent security tests available. Another way that organizations discover vulnerabilities, not so much in products like the example I've given there, but in their environments more widely, is through a topic of what we call penetration testing. Now penetration testing is is worthy of uh possibly many hours of discussion, but I'll try and keep this as uh brief and to the point as I can. So in penetration testing This is where an organisation will invite qualified professionals to come and essentially probe their systems and essentially attempt to act in a similar way to a potential attacker. So not only will they ask the penetration tester to try and find vulnerabilities, they'll actually ask that test team to see if they can exploit those vulnerabilities. To then give advice on how we might remove those vulnerabilities to stop a real-world attacker taking advantage. There are different types of pen tests that can be done. depending on what you're trying to understand. And you may have heard of the term white box and black box penetration testing. So for example in a black box test This is where you might be concerned about, let's say, an unauthenticated attacker on the internet who doesn't have any existing access to your systems. So you're asking the tester to see what they can do without any information, without any credential. That's one extreme. On the other extreme where we talk about white box testing, that's where you give the testers information about your system. maybe even standard login credentials because what you're doing in a white box test is maybe looking at the system from an internal perspective. You know, so could somebody who already has access, legitimately or not, for example, elevate their privilege or do something that um they shouldn't be doing. So you choose which scenario is appropriate. You can also think about does the security team that are monitoring networks, for example, need to know about the the test? In other words, do we want them to be aware so they can be aware that when there's strange logs, etc. that's something Something's happening. Or are we using the pen test to test their capability to detect? A lot of organizations now are good are using this idea in something you may have heard of called red and blue teaming, for example where you've got the blue team that essentially defends the network and systems and the red team which is essentially pro-bring and testing all of the time There's a lot more we could say about that. The only thing I'd say right now is we need to be very careful with pen testing to make sure that we get best value from it by focusing it on those systems. that need that level of scrutiny and making sure we select testers who are competent. So maybe having a look at whether your testers are uh properly registered under schemes such as Crest or Tiger. There's many of other other schemes out there. So you can be sure that when they are giving you a report that there's a level of accuracy around it. The only limitation I would tell people about Pentel testing as well before I move off this is of course a pen tester has a limited amount of time because you buy their time based on a budget. A real-world attacker is not limited by a number of days, a number of hours, etc. So that's always something to bear in mind. But certainly security testing of products, doing your own security reviews and vulnerability tests and penetration testing can all come together to help us understand the kind of vulnerability. We have from a technical perspective. Now, of course, that all being said, we could produce lots of reports about all the vulnerabilities that exist, and some people would be correct to say, well Why is that an issue? Is somebody really going to take advantage of those vulnerabilities, etcetera? And that's where we move on to the concept of threat The ISO definition of threat, the potential cause of an information security incident that can result in damage to a system or harm to an organization. So think of the threat or threats as things that will potentially take advantage of those vulnerabilities. Now what I tell people before we have a look at the list from ISO is that you could break threats down really into three categories. You've got your deliberate or malicious. So this is groups of people who are deliberately aiming to gain unauthorized access, conduct any denial of service, conduct fraud, wherever it might be. So the deliberate and malicious threats We've got our accidental threats and there's plenty of those. So that's you know things like human errors. Imagine the employee who accidentally sends confidential data to the wrong email address or you know, copies data to Dropbox by mistake or something silly like that, but still extremely serious, but just not malicious, accidental threats. And then of course from the availability point of view we might have natural threats, things like fires, floods, weather events, etc. So we do need to think about all of them And if we take a look at this table from ISO 27005, again an extract from the table, this gives us some examples of threat. And you can see that they're bunched into multiple areas. And also you can see this column that talks about risk sources. So within ISO 27005, a risk source is basically saying where essentially a risk comes from So for example, you know, if you had a building and in that building you're you're um storing lots of um let's say dangerous chemicals, for example, that's that's a source of risk. That those are there give rise to risk. Now, one thing I'd like to say is if you're doing this in the real world and thinking about threats, you might want to think very carefully, particularly about the deliberate threats about the source of those threats. So you might want to think just for a moment about as an organization based on the type of organization you are and the type of data you're processing How interesting might your organization or its business be to certain threat sources? So for example, we could say threat sources are things like organized criminal groups, competitors. foreign governments or intelligence services, media outlets and journalists, and so on. And we could we could add many more to that list. And what you want to ask yourself is, well, do are we doing anything or do we have anything that might be interesting with those groups and how capable and how motivated are they? Now I can't just come up with the answer to that out of thin air. Often we'd need to look at the threat intelligence, we'd need to to do a lot of research around this. So why bother to do that? Well if we do that, then we understand the kind of threats we face, of course we can can uh put in a level of protection that's suitable, you know, protecting yourself from a determined advanced persistent threat. such as a foreign intelligence service, is a very different matter to protecting yourself against, let's say, your trivial technical hackers. They're both uh offer a level of threat, but those levels of threat are very different. So I do think it's worth thinking that through. It's also worth thinking through uh threat scenarios, that is to say, how maybe a s a threat source could influence what we call a threat actor. And I always just use a real-world incident just to just to call this out. And it's it's a little dated one, but I think it still really helps. This was a real-world story of a bank based in London uh quite quite some time ago now, but long story short, a um organised crime group who were looking to commit fraud and essentially They basically bribed a cleaner who had access to the office after hours unsupervised. They bribed this cleaner to install keylogger devices on a number of machines. Now today that attack probably wouldn't work because you would imagine most organisations would then put restrictions in place around USB, etc. But at the time restrictions weren't there. And then essentially with the login details they'd gleaned through these keyloggers, they were able to log in and basically commit large amounts of um data transfers. So but the point about that story is is that you have different people involved. You have a threat source uh essentially uh affecting the behaviour of an insider in this case. So that's a threat scenario. So it is worth thinking about that in the real world and really sort of doing some work to get under the hood as to how threats might you know manifest themselves in reality. We could say a lot more about that, but we'll park that there for the moment because beyond that we're getting into the realms of threat hunting, threat intelligence. etc. But what I want to just uh sort of point to here on this table is the relationship between vulnerability and threat. Now we've deliberately done it here as more of a one-to-one mapping just so that the the you know it's understandable. Like the first line, if we have a warehouse that's unprotected without surveillance, that's a vulnerability that could be exploited through theft. Or if we're using pirated software, then that software might be vulnerable to malware and other such things like that. In real life it can of course be a lot more complex than this. You know, one vulnerability might be exploited by multiple threats, or the other way around, you know, a threat might attempt in order to launch its attack to attack several vulnerabilities. However, for the sake of where we are now, these are the things that we need to be clear about. So let's imagine then, just uh hypothetically, a threat takes advantage of a vulnerability. When that happens and an incident takes place, we have what we call a consequence. Now here I'm not talking about business consequences like cost or legal action or reputational damage. First, we're going to talk about the consequences to the three tenants of security. So is the scenario affecting or could it affect availability of bringing a system offline? interrupting uh performance. Could it be a consequence on confidentiality, you know, a data leak, unauthorized access to data, unauthorized sharing of data Or could it be something that has an integrity impact? You corrupts data, allows people to make changes without authorisation, allows fraud, for example, to take place. And the reason we're bringing this up is when we think about risk in ISA 27001, this is what we're trying to look at each time. Now there may be some scenarios that affect all three tenants of security some that are very specific, but of course understanding that can allow you to think very carefully about the prioritization of risks And in this next table, now you've got the vulnerability and threat and the consequence in the column here as well. So if we had the unsupervised warehouse and we had theft, of course we would suffer from a financial loss. If we were transferring passwords across a network in the clear and we had some kind of eavesdropper or hacker, whatever their motivation, you know, intercepting that traffic, we could have potential information thing. I would argue we could have a lot more problems as well. But the idea is there's a relationship between all of these. And when we look later on at risk management, This is the important aspect. Now as an auditor, um you're not necessarily conducting the risk assessment for the organization, but what you are doing is validating that their risk scenarios make sense. So to be familiar with these things These concepts is really important. So the final thing to say on these terminologies is these all play into the concept of risk. And according to Weissot 27005, the definition of risk, information security risk, is the effect of uncertainty on objectives. So what we mean is um Risk is something that hasn't happened yet. It's an uncertain situation. And the study of risk is to try and think about the likelihood of some of these scenarios that we're talking about playing out. and the impact of them, the damage that can be done. And we have further discussion here based on the the NIST standards, the special publication 830 And it has a definition of information security risk which says the risks of organizational operations, organisational assets, individuals, other organisations and the name the nation in this case, due to the potential for unauthorised access, use, disclosure, disruption, modification, or destruction of information and or information system That's quite a long definition, but in a nutshell, what it's saying is it is the uncertainty related to the potential compromise of information. Now in this case where it mentions the nation, just to be clear on that, that's because NIST is a federal government standard in the US that focuses not just on organisational security. But national security, but even if you're not concerned about in your organization national security, I think everything else in that definition is absolutely perfect. So that's what we're trying to do in an ISMS And as an auditor, we're trying to validate that the organisation has got their approach right and they really do understand these issues and they really have identified the right kind of risks that's relevant to them. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S04.3-Fundamental-concepts-and-principles-of-information-security.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S04.3-Fundamental-concepts-and-principles-of-information-security.md index 25b0a17..a6ba183 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S04.3-Fundamental-concepts-and-principles-of-information-security.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S04.3-Fundamental-concepts-and-principles-of-information-security.md @@ -12,6 +12,8 @@ status: active ## Abstract +This session covers security control types and functions within an ISMS context. Controls are categorized by type (technical, administrative, managerial, legal) and by function (preventative, detective, corrective). The session emphasizes the importance of detective controls, noting industry data suggesting organizations take six to seven months on average to detect a breach. It explains the layered relationship between ISO 27001 clause requirements, Annex A controls, and underlying technical implementations. The session concludes by distinguishing information security, cybersecurity, and privacy, explaining that cybersecurity is a subset of information security and that privacy protection requires additional ethical and procedural considerations beyond pure security controls. + ## Transcription So as we we know, we as part of an ISMS expect an organization to understand its risk and to To understand the risk scenarios. And in response to those risks, an organization will be implementing various security controls. And if we look at Annex A of the standard, we know there's 93 security controls in there. And of course they can add others as well. But controls all have a different purpose. So we're just going to look at security controls by type and function. So let's start by type first of all. We could categorize security controls. According to what they do and their purpose. So we have some controls that you might call technical controls. So technical controls in information security is where we implement some kind of technology to restore respond to a problem. So if we implemented a multi-factor authentication system or a firewall or an intrusion detection system, for example, these would all be pieces of technology designed to achieve some kind of objective, a technical context. control and there's a variety of them that we could have. But I think most people would accept, even with really good technical controls, that a lot of them are dependent on good processes and uh that are followed by an organization. And this is where we talk about administrative controls. So administrative controls are where organizations bring in certain processes to manage risk. So you could have things around people like segregation of duties, job rotations, proper approval processes, your change management processes. These would all be example of administrative controls. But also having adequate procedures in place to manage technical controls. So for example, let's say we introduced a a security incident and event monitoring tool, which is a technical control, we'd probably have a bunch of administrative controls to go with it, such as stating how often the reviews of those logs have having a process that would be followed if we detected something suspicious. Those would be administrative processes. So often these will go hand in hand. And when we think about setting up an ISMS, we also have managerial controls. So managerial controls are very focused on people and management of people within the organization. So having things like management reviews, training and awareness programs, having proper internal audits to check that policy, etc. has been followed properly, disciplinary processes, etc. These would all fit under the the banner of managerial controls. And then we also have legal controls and there's two points of view on that. Legal controls are controls we would implement in order to fulfil our obligations under laws and regulations. And also where we use legal instruments to protect our information and information systems. So for example, if we asked people to sign a non-disclosure agreement, providing it's you know legally sound, that would be a legal control. Or let's imagine you have a supplier and you expect that supplier to meet certain security requirements and that's specified in contract. then that contract is essentially a legal instrument, it's a legal control that's helping to protect us. But as well as talking about the types of security controls, we also need to think about the function and the purpose of different securities. security controls. Now in this course we present this as three different functions, preventative, detective and corrective. I'm aware that in some other security studies etc you might have even more categories But for these we we keep it at three. And I just want to run through those three. The first one then, preventative control, is basically a control that we will implement to avoid or prevent the occurrence of a risk as best we possibly can. So for example, if I put strong access control in place on a system with multi-factor authentication, the objective there is hopefully to prevent unauthorised access. If I put a robust firewall at the perimeter of my network again, you would argue that's a preventative control. Or in the physical world, you know, if we put a you know, a vehicle barrier in place or a a strong entry control, these would all be there for the purpose of preventing things. Also, anything that's there to deter people, what you might call a deterrent, I would put in the preventative book it as well. So if I put signage up outside the building saying we're monitoring you with CCTV or a login warning banner that says you're about to log into a confidential system, you've been monitored. Now some people might say, well that doesn't prevent anything. People can just ignore those things. Well of course they can, but they're still there to to to with an effort to deter the attack Now all of this being said, there is plenty of studies to show that pretty much every preventative control that exists can, with enough time, enough motivation, potentially be compromised. Now I don't say that to frighten people or to imply that preventative controls aren't needed. Of course they are, absolutely they are The point I'm trying to make is that we need to think very carefully, going back to my point earlier, about threat. How capable and how motivated are the threats that you face? Because the larger, the bigger capability and motivation they have, the more we're going to need to do on the preventative front. One of my colleagues puts it like this. He says You're never 100% stopping an attack. What you're trying to do is raise the bar so high that the effort required to compromise those preventative controls is so great that the attackers maybe go somewhere else. Essentially that's what you Trying to do. So all of that being said, yes, we need absolutely robust preventative controls in place, without a doubt. But knowing that some preventative controls could be with enough effort and energy and time be compromised, we need the ability to actually spot when preventative controls have been compromised. And that moves us into detective controls. So detective controls are controls that allow us to see that. So things like monitoring and auditing, a security incident and event monitoring tool. our threat hunting activities, intrusion detection, file integrity monitoring, etc. These are all examples of detective controls Now, personally speaking, as somebody in the security business, I'm very focused in this area because um because of various industry statistics and publications etc. And I wanted to draw your attention to a couple of those. So uh over the last couple of years the National Cybersecurity Centre in the UK uh and totally separately uh HP so the um the the large infrastructure Company HP both did separate studies and without getting into too much detail they both implied that there was essentially a significant gap in general between organizations having a security compromise and spotting it. So approximately, and I'm not quoting the days exactly here, but in the ballpark of uh NCSC has suggested around six months things HP is at seven, you know, give or take a few days here and there. But the point is, um these studies are suggesting that organizations on average are taking six to seven months to notice that a security compromise has happened. Now of course you might be watching this and saying, well that's not true for my organizers, you know, you're we we we're much better organized. And that and if that's true, that's Fantastic. But clearly in the industry at large there is a challenges here. So what's that telling us? It's telling us that some organizations at least have blind spots. So investing in detective controls for me is super important to having an effective ISMS. There was a um a saying that a chief information security officer was quoted as saying that I think the RSA Security Conference when they said it's not a case of if you've been compromised, it's a case of you have, but have you detected it? And I don't say these words again to to frighten anybody or anything like that, but it's just to get you thinking about let's not overlook the importance of detective controls. When anybody tells me we've never had a security incident, I would say I'm quite sceptical and my question is well okay what detective controls do you have and how are you using them. Now equally if we are capable of detecting and we are detecting things or things are happening, then of course we need the ability to respond to that. And that's what a corrective control is. So corrective control seeks to respond to identified problems. So things like disaster recovery plans, business continuity plans. plans, um incident management processes, all of these uh root cause analysis processes, all of these would be good examples of corrective controls. And we'd expect to see again a good mix of those in an ISMS. Now one thing that's really interesting actually to talk about is this slide here which gives you layers of control and I think this is this is really interesting to explain what ISO 27001 gives an organization and what it doesn't. So let me just try and clarify this. So we can see essentially three layers in this diagram. At the top, controls that an organization would implement based on clauses 4 to 10. So you can see those controls are all quite managerial in nature, you know, having proper risk management. having a proper policy in place, conducting management reviews, looking at security from a strategic standpoint. And then of course we have annex A. Now we will say that Annex A are general controls. What I mean by that is When I look in Annex A of ISO 27001, it's not going to tell me how to configure security settings in Microsoft Azure or in AWS or on a Cisco firewall. What it's going to give me is a general set of controls and principles that we need to think about as an organization. What's not in there but still needs to be thought about is then how you apply specific technical controls at the technical level. Now what's this got to do with auditing an ISMS then? So let's imagine I come along as an ISMS auditor and you tell me that you have an access control policy and you require multi-factor authentication. Well of course as an auditor I need to get some assurance that that multi-factor authentication in this example is implemented in an effective manner. That means I'm going to have to take a look at the technology that's being used in your state, whether it's Microsoft Azure, AWS, something like that. completely different and look under the hood. And I need to understand that your organization, who I'm auditing, has uh the necessary technical controls at those levels. So what I'm saying is a good auditor isn't just familiar with the content of ISO 27001. You or somebody in your team will of course need to be familiar with the underlying technology. Otherwise it's going to be difficult to have a reasonable assurance that control those controls are implemented properly. So that's the part that requires you, I guess, outside of this course to get familiar with different technology environments and so forth. But just to sum all of this up, we've got a good slide here that might look a bit busy at first glance but is really trying to explain the relationship between all of these things. So in the bottom corner there we've got assets. In the end, the whole purpose of an ISMS is to protect information assets. And what we're saying, or we're trying to explain here, is that risks can of course cause damage, can harm assets And risks are caused by what? They're caused by vulnerabilities and weaknesses that are being exploited by threats. Now, and of course we respond to this by implementing controls, all the different types I've just been talking about. So some controls will reduce vulnerabilities, that's their purpose. Some can be implemented to reduce the amount of damage that can be done, reduce the impact, and or both. But it is worth noting, as it shows you in this diagram here, that controls themselves can have vulnerabilities. You know, I always say if you can fix one problem, could you be creating another one? So let's say for example we decide to introduce an intrusion prevention system for network security. because we have a number of vulnerabilities. So great, we go and implement this intrusion prevention system which when it detects something suspicious starts dropping network traffic Now if we get that properly tuned and implemented correctly, that's excellent. But what happens if it's not tuned very well and it starts dropping network traffic And causing a denial of service problem. So essentially we could create a new problem by fixing an old problem. So we call that secondary risk. So we're simply saying here, do think about that. When you're responding to risk. think very carefully about any new vulnerabilities that might be being introduced. So this is always in an organization an ongoing thought process. Now the last couple of concepts we wanted to introduce you to in this section were based on the fact that the title of the standard talks about setting up an information security management system. with a focus on cybersecurity and privacy. And sometimes the difference between information security, cybersecurity and privacy can cause a little bit of confusion. So we just want to make sure that we're all sort of on the same. same page. So ultimately cyber security based on ISO's definition of it is this safeguarding of people, society, organisations and nations from cyber risks What we mean by cyber risks, essentially they're technical risks. And if you look at ISO standards, they'll they'll still talk about a concept that I remember being talked about a long time ago called cyberspace. And cyberspace is basically think of it as the internet if you like. So any technologically connected system that processes information for faces potential cyber risks. So for the avoidance of any doubt When we set up an ISMS and we do everything in there that we should be and we implement those technical controls, we are and we should be addressing cybersecurity as part of it. So cybersecurity is not a separate thing from information security. Cybersecurity is an element of information security, protecting the technology, the infrastructure, the applications that form part of it. Information privacy, on the other hand, is also mentioned in the standard. And from ISO's perspective, that's about protecting what they call PII, personally identifiable information. So personally identifiable information is anything that will reveal the identity of a living individual. So of course there's obvious things, your your name, address, telephone number. date of birth, etcetera as PII. But even more subtle things. So things like let's say the the IP address you're using when you're connecting to let's say an online service, if that could potentially reveal your identity. In some cases that potentially could be PII. What we're interested in when we look at privacy is a little bit different to security. So bear with me on this. So obviously security is relevant for privacy, but if we look at look beyond ISO and we look at a definition for say for example from GDPR And it talks about privacy being uh essentially protecting the rights and freedoms of individuals. So there's a subtle difference. Of course, in order to ensure somebody's privacy to respect the rights and freedoms of an individual, we need to have adequate security. We need to protect that data. But privacy goes beyond that a little bit. And I always just try to use a very quick example of a project I worked on some time ago to distinguish between the two. So this project in brief was a road tolling project I was working on a project for a a UK project for a bridge essentially where they wanted to change the road tolling system. So previously people could drive to this bridge, uh pay in cash and drive across across it And the the organization behind that wanted to change to an automated system to stop queues basically. What they wanted was that people could drive across that bridge. have a picture taken of their number plate, automated number plate recognition, and then basically be asked to pay the bill online. So you could pay beforehand, you could pay afterwards If you crossed regularly you could even buy a transponder to put in your car and every time you crossed, there'd be an amount debited off that. So let's think about that. I was on that project as the security architect or one of the security architects. So of course my focus there is very much about the security of the network, the applications, you know, the whole sort of operation. And we had separately to that a privacy officer And the privacy officer did the um the privacy impact assessment. And the discussion in that, yes, there was definitely discussion about security of the system, security of the data, but they were then also looking at rights and freedoms and ethical issues. You know, now we're moving from a system where you could drive relatively anonymously across this bridge to one where there is a footprint, there is a record. And what could the impact be on an individual if uh those records were shared? You know, maybe certain people don't want. people to know that they were travelling on that road at that point in time during the day. So the questions start to become how long should we keep that data for? How much should we keep Who should we be sharing it with? What happens if somebody wants to access that data? You know, so a lot of procedural and ethical questions. And does that get included in ISO 27001? It does. There are some controls in there about that, which is why we bring it up. So all we're saying is if you're processing PIR, you need to think beyond just pure security, we do need to build privacy thinking into our ISMS. If you want further guidance on that, you can extend your ISMS to cover privacy in further depth with an extension standard called ISO 27701. which basically takes everything we have in ISO 27001 and adds further controls from a privacy point of view. But even without ISO 27701 there are some privacy controls. within the standard. So in summary, what we've tried to make sure is here that we're speaking the same language when it comes to security in the world of an ISMS So we know that information is meaningful data. That is an asset to the organization. We are building a management system to protect those assets. We at least focus on the three pillars of confidentiality, integrity and availability. We can go beyond that. We focus when building an ISMS on risk by understanding the threats and vulnerabilities that are relevant to us and the consequences if those threats were to exploit vulnerabilities. We can implement controls in response to that, preventative, detective and corrective controls, with a mix of legal, administrative, technical and managerial controls, or blend of controls to manage risk. And we will take care of both cybersecurity and privacy as part of the overall ISMS. So hopefully this has given you a good flavour of all the things we need to think about. And as we move forward, we'll start to examine as auditors how do we really test whether these things are effectively implemented. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S05.1-Overview-of-ISO-27001-requirements.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S05.1-Overview-of-ISO-27001-requirements.md index 236b258..01c7e0e 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S05.1-Overview-of-ISO-27001-requirements.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S05.1-Overview-of-ISO-27001-requirements.md @@ -17,6 +17,8 @@ status: active ## Abstract +This session provides an auditor-focused overview of ISO 27001 clauses 4 and 5. Clause 4 covers understanding the organization's internal and external context, identifying interested parties and their requirements, determining ISMS scope, and operating the ISMS. Clause 5 addresses leadership and commitment from top management, including establishing an information security policy that reflects organizational objectives and commits to continual improvement, and assigning clear roles, responsibilities, and authorities for ISMS operation. The session emphasizes that an ISMS must be strategically aligned with organizational objectives, not implemented merely as a compliance exercise. + ## Transcription What we're going to do in this section is take a close look at the requirements of ISO 27001. So as an auditor of course we need to be familiar with all of the clauses of the standard and the annex to be able to add. Ask the right questions and conduct our audit. So basically, what we're going to do here is take you through clauses four to ten and also describe a little bit about annex A as well. Now before I start this, I think it's important to point out That we're not as we go through these teaching you to implement these or how to audit these things yet at this stage. We will be getting into how to audit and assess these things. What we're trying to do is just keep you a good broad overview of the requirements. So I like to call this section a bit of a helicopter tour of the standard. So by the time we've sort of finished this you'll have a good idea of some of the points within So let's start off with clause four, context of the organization. So this is broken down into four different subclauses, and essentially it's all about making sure the organization understands itself if you like in order to build an ISMS that's fit for purpose, that's tailored to the needs of the organisation. So when we use the word context, context basically means what is the organization about and from two perspectives, both what we call an internal context and an external context. So for example, an internal context is all about what's happening inside the organisation, such as how is it structured, who makes decisions, you know, what's the governance and oversight look like, what's the capability and maturity of the organisation. Whereas the external context is about what's happening in the outside world. You know, what's the legal and regulatory landscape look like? What part of the world are you operating in? What's the economic landscape look like? What's the demands of your customs, etc. So what we're saying is when we build an ISMS, an organization shouldn't just be building an ISMS out of the blue, but essentially should be taking all of these considerations. into account. And clause 4. 2 sort of expands on that because what it says is that we should understand the needs and expectations of interested parties. So in an ISMS, interested parties can be both internal and external. So external interested parties parties, maybe things like customers, regulators, business partners, suppliers as examples. Internal can be people like senior management. your user base, different teams and departments. And the idea is when an organization builds an ISMS, it should be examining what the needs and requirements of all these different parties are again so it can build an ISMS to respond. So maybe a quick example of that I can give. I remember at one point I worked for a training company that provided services to a government department And there was a requirement, so they were our customer in the contract which said if we discover any compromise of data relating to them, we must report it within four hours of detection 24-7. So that tells us that we need an incident response capability. That's 24-7 that has that response time built into it. ISO doesn't tell us that. but the expectation of our customer does. So we'd need to build the ISMS with that expectation in mind. And we'd also as an organization build an ISMS based on a scope. So One of the things to say is that when an organization puts an ISMS together, they don't necessarily implement it in the entire organization. They can choose which part of the organization it applies to or which business processes are in scope or which particular systems are in scope. And when an organization determines the scope, it should be credible based on the work done in clause 4. 1 and 4. 1 So as an auditor when I'm coming along and talking to an organization and I'm asking them about the scope, it's not so much that I'm there to tell them whether the scope is right or wrong. It's more about have they done the groundwork? Can they logically explain why the scope that they have makes sense? And then we have clause 4. 4 which talks about operating the information security management system. Now in reality, although this is a standalone or it's a subclause, that can only be fulfilled if the ISMS is actually fully established so that all the other clauses and relevant controls are implemented. So as we'll speak about a little bit later, as an auditor, we'll answer the question as to whether 4. 4 is fulfilled after we've looked at some of the other areas. So just elaborating a little bit on the understanding the organization in its context part, so let's think about a typical organisation. An organization, all organisations, whether they're a government agency, a non-profit or a profit-making business, all in the end have a mission, they have a purpose. So a Razondetterie, you might say a reason for existing. And maybe an organization has a mission statement or something like that that we can look at to understand. understand them. All organizations have objectives, things that they're looking to achieve. So if it's a say a a profit-making enterprise they might have objectives over the next X number of uh years for example to expand by a certain amount to launch new products in a new market whatever it might be If it's a non-profit like a government agency, they might have objectives in improving efficiency or improving quality of service or whatever it might be. But the point is organizations should have objectives and most organizations will have strategies. That describes how they are going to reach those objectives over a period of time. So, why is this relevant to a discussion on ISO 2701? Well, let's imagine an organization is implementing ISO 277. 27001, it needs to formulate its information security policy and its objectives. So the last thing it wants to do is create a set of objectives that are contrary to the mission or objectives of the organization. And let me try and give sort of a really good example, I think, of where an organization did this really well. So it was an organization I worked with some time ago. They were an IT service provider. And they'd called us in actually to help them implement an ISMS because they had a contractual duty. There's a contract that they'd won which said you need to have an ISMS and you need to be certified by a certain date. Now as the implementer in this case, not the auditor, as the implementer in this case, we could have easily gone in and just kind of done what we needed to do to get them compliant with that contract, get them certified and leave it there. But early on I had a conversation with some of the directors. I had a good relationship with the finance director at the time and I started asking him about the longer-term objectives of the organization And in that conversation, he kind of revealed that their aim was to start d expanding into the defence sector. They wanted to start selling various services into Ministry of Defence and other defence organizations around the world. And the conversation I had with him based at a very high level went along the lines of, well, in order to be able to achieve that, you're going to need to have a certain security capability. a certain level of maturity to be able to get into that kind of supply chain. Long story short, that led to the formulation of a security strategy which didn't just focus on getting ISO 27001 certified but it focused on building the organization's security capabilities so they were in a position to win business in the defense sector. So what I'm trying to say is we produced a security strategy that was aligned with the strategy of the organization. This is the kind of thing that clause 4. 1 is talking about. We're not building an ISMS just to tick some boxes off for the sake of it. We're trying to build an ISMS so the organisation should be to achieve its longer term objectives. So as an auditor, if I'm wearing my auditor hat, that's what I want to understand when I'm talking to the organisation. What is this delivering for you? When we talk about understanding the needs and expectations of interested parties, as I said a few moments ago, there are many interested parties. that might be affected by an ISMS. There are those who might be directly affected, you know, for example internally, if we start implementing security controls in order to fulfill requirements You know, those that will see that first hand, like users and employees, etc. And then may maybe those who are less affected but are nonetheless interested. You know, somebody like a regulator, for example, might not be seeing your ISMS on a day-to-day basis, but might be So it is a important thing that the organization takes its time to map out its interested parties and to map out what the requirements are. Now in some cases requirements might be explicit. So like the example I gave a little bit earlier on about that training company, it was clearly stated in the contract that we shall report these incidents within four hours of detection. Section. That was non-negotiable. That's a requirement. There may be cases where interested parties don't have a written explicit requirement But a an implied requirement exists nonetheless. So for example, if your organization is selling goods or services to the general public, you might not have a written contract specifying all the security controls you need to have in place. But you'd still say there's an expectation, you know, the members of the public would still have a certain expectation about how you process and store their data, as well as obviously the legal and regulatory aspect. The other thing that's important when an organisation does this is have they identified their legal, regulatory and contractual obligations. So as an auditor very early on in the audit this is a question I ask and I like to see has the organisation spot spotted that And if you're thinking about organizations that operate globally, then of course that might be even more complex. But what I want to find out is have they took these points into account. It wouldn't be a particularly useful ISMS if they've overlooked key legal obligations in the end. An organization needs to determine the scope of its ISMS, and the standard says the following: the organisation shall determine the boundaries and applicability of the ISMS to establish its scope. But as we can see, it's not just establishing any scope from anywhere. We should take into account A the internal and external issues we've just been talking about. The requirements referred to in 4. 2, that is to say the requirements of your interested parties, and this is an interesting one as well. Interfaces and dependencies between activities performed by the organisation. and those performed by other organizations. So let's take an example. Let's say we've got an organization, pretty much every organization I could give this for now, and it uses cloud services. So let's say you use a SaaS platform, software as a service platform provided by a cloud service provider. So I think we could all agree that a lot of the technical delivery of that service would be the responsibility of the cloud service provider. And the organization isn't necessarily going to put the cloud service provider and all its activity inside the scope of their ISMS But the management and oversight of that cloud service provider and the processes for that would be in scope. So we've got to look at what I I actually call it the reliance scope to some degree. degree. In other words, who or what are you reliant on? And if we drew dru do draw a boundary around that, how do you have some assurance and oversight? So this is an important point. And it says that the scope shall be available as documented information. So as I've said a little bit earlier on, as an auditor, I want to see the scope document and I really want to understand how the organisation arrived at the scope and And as I've said before, it's not about whether I agree or like the scope or don't like the scope, it's more does it make logical sense in terms of how they've got there. And 4. 4 is that the organization should establish and maintain and continually improve their ISMS. Well, in the end The fact of the matter is in an audit that's what we're trying to work out at the end of the audit, I want to really be able to say, is this clause fulfilled? Have I seen enough evidence of other stuff going on to say whether or not they have an effect? So let's move on to clause five then. Clause five is entitled Leadership and it has three controls, leadership and commitment, policy organization roles, responsibilities and accountabilities. So clause five, when we use the term leadership This is all about making sure that there is support and commitment from what ISO calls top management to run and operate an ISMS in the long term. So when we see this term top management This basically means that senior leadership within an organization should be overseeing and supporting the implementation of an ISMS. Now who top management are might vary depending on the type of organization we're talking about. So often when I ask this in a classroom, I'll say, well, what do you think top management is? A lot of people say things like directors, C level, you know, executives, etc. etc. And by and large that would be absolutely true. Now, obviously it's context driven to some degree. So I remember working with a uh a large global IT service provider helping them implement an ISMS But the ISMS scope was limited to some services specifically in the UK in this case. So I wouldn't expect the global chief executive necessary. necessarily to be involved in this case, but certainly the UK directors who were accountable for that business unit in that case were our top management. In a small business Very small business, it could even be the owner of the organization. So it will kind of vary uh vary depending on the organization. But what does the standard expect? Well, without going through each and every requirement A to H, because you're so you can read through those um in detail but I'll give you sort of a summary. What the standard is expecting is that those people in those leadership permissions support the ISMS in a number of ways. And some of them that are important are making sure the security objectives that we decide Define and the scope and so forth is aligned with the objectives of the organization, a bit like we were talking about earlier in clause four They should be ensuring that we have the necessary resources to run and operate that ISMS, not just to implement it. but to run it and operate it in the long term. Those resources might be financial, technological, it might be people. Now I'm not arguing here that management must have an open checkbook. and no budget, but what I'm saying is provide adequate justified resources to run the management system. Another key role that top management plays making sure that people in the organization are aware that this is actually a top management concern. So getting involved in communication, sharing. uh information with the wider organization. So people can see in reality that this isn't coming from an IT department or isn't a technical thing, but it's a concern of top management. And the more likely people see that, the more likely we're going to get back. in and also top management should be proactively reviewing the management system, ensuring that we are driving in continual improvement. This is why separately in clause 9. 3 we have this concept of management review. which we'll come to a little bit later. Now one way that top management can demonstrate their commitment is of course by establishing an information security policy So according to ISO, a policy is the formal intent and direction as expressed by an organization's top management. So, clause 5. 2 says we shall have an information security policy that does a number of things that's appropriate to the purpose of the organization. That includes the security objectives or if not includes them provides reference essentially. to those objectives. Includes a commitment to continual improvement and a commitment of satisfying applicable requirements. That could be legal, regulatory, contractual. requirements. Now usually what I would say here is an information security policy would be a fairly short document, maybe one or two pages that everybody in the organisation can see. It's setting the tone and direction. It's saying, okay, we top management take security seriously, therefore we're going to commit to the following things. For example, we're going to commit to implementing appropriate training. We're going to commit to ensuring risks are properly assessed and treated. We're going to ensure that we're going to monitor our ISMS, etc. There might be other policies produced later that are topic-specific, you know, topic tech technical topics like cryptography or network security or application security but we'll talk about them in annex A because there's a particular control in the there for that. For now, this is about top management showing that there is commitment and setting the tone and direction in policy. And of course we can't have an effective ISMS or argue that there's top management commitment unless people are appointed to actually run and operate the ISMS. And that's what clause 5. 3 is all about. establishing organizational roles, responsibilities and authorities. So who does what when it comes to running the ISMS? And who's authorized to do what? So, you know, who's doing the risk assessments? Who is it who's going to create policy? Who's responsible for handling incidents or conducting internal audits? We'd want to answer all of those questions And it clearly says in the standard, top management shall assign the responsibility in authority for ensuring the ISMS conforms to the requirements of this document. to the standard and reporting on performance to top management. So top management can't just allocate roles and then just forget about it. and there needs to be a link between whoever's performing those roles, for example an information security manager or CISO and top management. Note that the standard does not give us a list of job titles or qualifications or anything like that. Every organization will be different, but it should be very clear who is doing what. Those people should be aware of their roles and be formally authorised to do that. Based on the um authority of top management. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S05.2-Overview-of-ISO-27001-requirements.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S05.2-Overview-of-ISO-27001-requirements.md index 6f19028..def8057 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S05.2-Overview-of-ISO-27001-requirements.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S05.2-Overview-of-ISO-27001-requirements.md @@ -14,6 +14,8 @@ status: active ## Abstract +This session covers ISO 27001 clause 6, focusing on planning. It distinguishes between clause 6.1.1 (risks and opportunities affecting the ISMS itself) and clause 6.1.2 (information security risk assessment). The session explains how to define risk criteria, select a suitable risk assessment methodology, and apply the three-stage risk process of identification, analysis, and evaluation. It also covers risk acceptance criteria, risk appetite, and the role of risk owners. Both event-based and asset-based risk identification approaches are discussed, and examples of established methodologies such as OCTAVE and IRAM are mentioned. + ## Transcription Let's have a look at the next clause in the standard, clause six planning. Now this is broken down into three particular parts, the actions to address risks and opportunities, information security objectives and planning to achieve them planning of changes. So let's start on this first one, actions to address risks and opportunities. We see this in clause 6. 1. 1 and something I want to really draw your attention to here because often there's a little bit of confusion about this. 6. 1. 1 isn't specifically about information security risk We'll come to that shortly. It's about something slightly different. So let's just have a look at the words and then I'll try and explain my point here. So what we see is the following that when planning for the ISMS that the organisation shall consider the issues referred to in 4. 1 and the requirements referred to in 4. 2. So remember that's context of the organisation, the needs and expectations of interest. parties and then it says and determine the risks and opportunities that need to be addressed to ensure the ISMS can achieve its intended outcomes prevent or reduce undesired effects and achieve continual improvement. So what's this speaking about? This isn't necessarily speaking about identifying information security risks to particular systems or particular information. This is about risks to the ISMS itself. So let me try and explain this. So let's think about a project. Any project for that matter. You imagine a project manager would usually do a risk assessment. When they're doing a risk assessment, they're not focusing on security or any other matter. What they're focusing on is what's the risk of the project failing You know, could the project overrun? Could it uh go over budget? Could it completely fail to deliver? Well this is a similar story here. What we're looking at is when we're thinking about establishing an ISMS, are there any situations, risks, etc. that could affect the ability of the ISMS to work as expected. ? So for example, if we identified that we had a resource shortage, that would be a risk to the ISMS itself. There might be a chance that the ISMS cannot fulfil its objectives. If we didn't have appropriate support from management, we'd have a risk to the ISMS. On the flip side, an opportunity is indeed the chance to potentially improve something or or uh gain some benefit. So the opportunity of establishing an ISMS could be it could open the doors to more commercial opportunities for example Or one of the opportunities in an ISMS could be that we're going to conduct detailed risk analysis and we'll identify opportunities to drive efficiency in certain processes or remove duplication, etc. So 6. 1. 1 wants us to focus on those particular risks and opportunities. Now that doesn't mean that we're going to ignore information security risk. quite the opposite. That's why there's a separate clause on that, clause 612. And clause 612, and I won't read it all out line by line, again I'll just give you the sort of summary. The organization shall define and apply an information security risk assessment process that does a number of things. The first one establishes and maintains information security risk criteria. Information security risk criteria, think of criteria as rules, are the rules we're going to use to understand our risk. So for example, we might lay out things like risk acceptance criteria. That is to say when a risk is identified, how do we decide? whether or not that's acceptable to the organisation. Now we might have an answer to that because the organisation may already have some general rules or criteria. And the criteria for performing those risk assessments, so when do we need to perform an information security risk assessment Is it at the start of a new project, during a project? Do we trigger an at risk assessment again if we have some kind of incident? Do we do them every so often? These are the questions that will answer in a documented risk assessment process. We then talk about the fact that it should ensure repeatable results. I'll get into that a little bit later in this section where we talk about having a proper risk assessment. assessment method and then we will do a number of things including identifying information security risks and something I want to draw your attention to right now which I think is important right at the start identifying risk owners so risk owners are individuals in the organization who have a let's say a level of authority, a level of trust to make risk decisions. It's very important that we know who those risk owners are early on. Because when we start to identify risks, we're going to have to consult with those owners to make decisions on what we're going to do with risks. If we don't have risk owners, then the process could come grinding to a halt. So this is an important uh point that the standard. that is calling out. And in a risk assessment, as we'll see in just a moment, we have three stages in a risk assessment, the risk identification, analysis and evaluation. So we expect to see according to clause 612 a very clearly defined, understandable risk assessment process. So as an auditor, when I'm coming in to look at this, I'll be looking at is the process defined, and then I'll be looking at evidence by getting somebody to maybe take me through risk assessments. that have been performed. But let's talk about some important factors then about a risk assessment approach. So there are three sort of things to cover off here which you can see in mentioned in the slide. here that we need to identify a methodology. So let me explain this very clearly. So clause 612 tells us what should be considered when doing risk assessment It does not tell us how to conduct a risk assessment. It doesn't say you shall calculate your risks on a scale of 1 to 10 or high, medium, and low, or using some other kind of formula. Nor does the guidance document, I suppose. 2705. What does that is what we call a methodology and I'll talk in a moment a little bit more about methodologies, but we need to have an agreed way of conducting those risk assessments As well as having an agreed way to conduct those assessments, we must have predefined risk acceptance criteria. So let me give you an example. I was working with an organization. I spent that they didn't have such a process in place. We were trying to get this set up. I spent some time with the finance director. And we started to come up with some ways we could calculate risk. So we had what's called an impact table. So we had five levels of impact. So when we're calculating the damage that could be done, we could place it on a scale. And I sat with the finance director and I remember him pointing out a particular number on this scale and he basically said to me If as part of these risk assessments we identify any risk that could result in the loss of this amount of money, and he mentioned a specific figure, or more And the likelihood of that happening is medium or above, that cannot be accepted by the Information Security Committee. This needs to come to the board for review So in this case he's given me, involuntarily you might say, some criteria, in this case risk escalation criteria. And these are the kind of conversations that an organization should be having to define this. And an organization should be identifying the overall level of acceptable risk. When it comes to information security. Now ultimately that is set by top management. And the level of acceptable risk will vary, of course, depending on organisation. And sometimes when we talk about risk, we talk about this concept of risk appetite. And risk appetite is the amount of risk that senior management or directors or or company owners are willing to take in certain circumstances. That might influence the answer here. So for example, I've worked in organizations that have very different risk appetites. So I've worked in um Your government entities that might have a low risk appetite because they are looking for stability. They don't want to take unnecessary risk Whereas if you go into say a venture capitalist organization that's looking for rapid growth, they might have a much higher risk appetite because indeed that's That's what they're doing. They want to innovate and take risks, but not reckless risks, but risks to grow. And again, as an auditor It's not for me to say what is right or wrong here or to enforce my preferences on the organisation but I do want to understand have they defined these things and why and does it have the appropriate support from top management. Now there is a note here which says the following. The organisation must ensure that the risk assessment generates comparable and reproducible results. So how does an organization ensure comparable and reproducible results and what does that actually mean? Well what it basically means is let's say that there's two of us doing risk assessments for an organization and I come along and do some and you know you come along and do another one that we both approach the problem in the same way and that means basically we should have a defined methodology And there are a few things an organization should think about when they're choosing a risk assessment methodology. Now the first thing I would say here is there are many methodologies available for assessing information security risk. Some of them very simple, some of them very, very detail-oriented and extremely complicated. It's also possible to design your own methodology. So ISO doesn't dictate what methodology to use. So how can an organisation settle on one that makes sense? Well there are a few things that the organisation should think about. The first, compatibility with the requirements of 27001, that's relatively easy because basically as long as the methodology considers threat and vulnerability impact and likelihood and the three tenants of security pretty much that that that part's answered straight away so as long as your method does those three things that's point number one So what else might an organisation want to take into account when thinking about this? Well other things that are important, vocabulary of the method, in other words, the way it's written Does the language make sense? I don't mean language as is as in is it in English or French or German? What I mean is um does the terminology make sense? So if it refers to the concept of threat, for example Do we understand the work that word in the same way? So when we get output from these assessments, will it be understandable Now I'm not going to go 1, 2, 3, 4, 5, 6, 7 here, because actually for me the next one, which I want to talk about, number 5 on here, ease and use and pragmatism of the method. Let me explain what I'm saying here So there are some methods that are extremely rigorous and extremely complex and are really good for deep dive risk assessment. So I can think, for example, spending time in government departments, there are some methods we would use and one risk assessment of one information system could take 50 days or more because we're really looking under the hood at a lot of technical detail, but in that circumstance that's justified because of the type of systems and information we're trying to protect But that wouldn't necessarily be very useful if I took that method and tried to apply that in a small sort of startup company or commercial business It it it would be rigorous, yes, but it probably wouldn't be practical. So this is not me, I'm not trying to argue that we don't need to be rigorous. What I'm trying to say is we set up a method that is suitable for the organisation at that time. An example I can give, I worked with a very small organisation not too long ago. They had nothing in place for this at the time. They weren't overly familiar with this idea, so they didn't it's not like they had a team of risk professionals in the organization. So we started with something simple. We actually built an Excel spreadsheet with some very simple to use steps. Now is that the end game? Is that where I want them to be long term? Of course it isn't. We can get more sophisticated and we will over time as the organization matures. So let's make sure we pick something that's fit for purpose. Now if we are using a relatively complicated method, then there might be good questions in points three and four. Is there any software that the organisation can use to aid their risk assessments. The only caveat I would give to that point is that software tools are only as good as the person operating them So you can have the best security tools available, but the person using it still needs to be familiar with the method to be able to explain the output. And that also speaks to point four. If we're going to select a method, are we selecting one that's well used, that other organizations use? that's properly documented where we can get training or professional support if we need it rather than something that's a little bit more obscure for example. And we can also think, last couple of points, about cost to utilisation. That's very similar with ease and pragmatism. You know, how much time does it take to conduct this risk assessment? Do you need to bring in a specialist to do it, etc. We want to get that balance right. So all of these things can help. And whilst I don't promote any particular risk assessment method, just to maybe point you in a direction a little bit, there are methods out there you can think about So some that I've seen in this space are things like Octave, for example, from Carnegie Mellon University. There is actually Octave S and Allegro that's targeted at smaller organizations, things like um IRAM from the Information Security Forum is a really good example of a risk assessment methodology, platforms like VS Risk or a Rambuffer, etc. None of these are me promoting anything in particular, but just some examples that might help you to start looking and thinking about risk assessment methodologies. But there are plenty out there if you do that research But all risk assessment methodologies, regardless of how complex or not they are, go through a series of stages and they should follow the stages that are laid out in ISO 20 the guidance document that is there to support conformity with these particular clauses. So the first risk identification So risk identification is the step of identifying risk scenarios. This is not about likelihood and impact, this is about simply identifying potential scenarios, working with risk owners and other experts in the organization to see what risks might be relevant And there are typically two ways we can set about identifying risk in an organization. Now, firstly I would say this is never done by one individual on their own. Often it's a collection of people. From a given part of the organization. So you might have a facilitator, a risk expert, but then other experts who can contribute. And we can do either an event-based or asset-based approach or both. But let's say an event-based risk assessment. or risk identification I should say is where we talk about specific events in general. So let's say for example ransomware we could have a general discussion about the risk related to ransomware in our organization and think about that event and think about how that event might play out. That's quite a generalized thing. But an asset-based approach is where we take the asset, we look at the asset and we look at potential vulnerabilities and threats. So let's say one of the assets is a CRM system So in an asset-based risk assessment, we'd take that CRM system, we would look at the design, the build, all the details we can, and then we'd say, okay, does this system have any vulnerabilities? What do they look like? How could they be exploited? And from that, we would identify a set of risks that would be quite specific to that asset. So an event-based approach gives you a good organizational overview, but then the asset-based very specific. So let's take the ransomware example. Let's say we look at ransomware in general Hitting the organization. And then when we do our asset-based assessment, we can say, okay, how would that ransomware scenario play out for this system system because it might play out differently in one environment to how it does in another. So for me, if you want to be really rigorous, I would say both approaches probably need to be done hand in hand. Now again I caveat that with that depends on the um importance of the assets, the level of rigor you need to go to. ISO 27001 does not demand this, but I think if you want to do risk assessment, or risk identification rather well, a combination of the two approaches would be really helpful. Now one of the things that sometimes I found comes up in risk identification workshops, for example are people saying things like, uh well that scenario is uh never going to happen, so we shouldn't really talk about it, and things like this. And I always argue in risk identification Let's not have that argument now, let's have that argument in the next phase. And that next phase is risk analysis and evaluation. So risk analysis is where we can have that debate, because what do we do in risk analysis? That's where we look at the potential consequences if this scenario played out and the likelihood And there are multiple ways of doing this. Likelihood can be arrived at by looking at events and how frequently they might occur. It can be worked out potentially by looking at previous historical events, if not in our organization but in others. But with the absence of that information, let's go back to the conversation we had in the previous section about threat and vulnerability. And the way I think about it is if you've got an environment that has vulnerabilities The question is, how easy are those vulnerabilities to exploit? So some vulnerabilities will be very trivial to exploit. Some will require possibly a lot of uh insider knowledge, a lot of expertise, a lot of determination and motivation to exploit. And then you ask yourself the question Well how motivated and capable are our threat sources? If you've done your threat analysis properly, you can answer this question. So logically speaking If I've got vulnerabilities that are easy to exploit and highly motivated and capable threat sources, logic would tell you that the likelihood of that risk playing out is probably a lot higher than the opposite way around. If I've got a vulnerability which yes could be exploited but requires hours of effort insider knowledge and various other things And I'm not facing sophisticated threats, let's say, from foreign intelligence services or organized crime groups. It might be a less of a likelihood Now again there's a lot more we can say about that, but for now what I'm looking for from an audit point of view is does the organization calculate likelihoods and consequences and does it have a proper system for doing so And risk evaluation is then taking those things, determining the level of risk, so usually by looking at a combination of the likelihood and consequence. And then making a decision about prioritization, and that often happens by looking at the results of the risk analysis Looking at the risk criteria, the risk criteria are the rules we use to prioritize, a bit like the finance director example I gave earlier, you know This is a level where something needs to be escalated, for example, and then prioritizing risks and deciding which ones might need treatment. and treatment comes where we decide that risks are unacceptable and action needs to be taken. And that decision should be being made by the risk owner. And as we'll see shortly, the risk owner is the one who should be approving the risk treatment plan and validating that risk treatment is taking place. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S05.3-Overview-of-ISO-27001-requirements.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S05.3-Overview-of-ISO-27001-requirements.md index 6733f49..6e626de 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S05.3-Overview-of-ISO-27001-requirements.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S05.3-Overview-of-ISO-27001-requirements.md @@ -14,6 +14,8 @@ status: active ## Abstract +This session covers ISO 27001 clause 6.1.3 (risk treatment) and 6.2 (information security objectives). Risk treatment options are explained: modification, avoidance, sharing, and retention. The session describes how Annex A controls are selected and documented in the Statement of Applicability (SOA), explaining how controls must be justified whether included or excluded, and how ISO 27002 supports implementers in understanding control intent. The 2022 Annex A restructure from 114 to 93 controls is discussed, noting the addition of new controls such as threat intelligence and data masking. The session closes with requirements for setting measurable, policy-aligned information security objectives with supporting plans. + ## Transcription So let's imagine an organization has took the time to identify risk and to analyse risk. According to clause 613 We then move into the need to do risk treatment. And risk treatment is all about choosing risk treatment options. Which we'll have a look at here in just a moment, and also determining which controls we might implement to respond to that risk. And we know that in Annex A, there are a list of 93 security controls that we can choose from. which you're not limited to, remember that. And we will need to state which of these we're going to implement or not in a document called the statement of applicability. That's all part of risk treatment. So we'll certainly run through in just a moment creating a statement of applicability. And also what's important in 613. f. Formulate an information risk security risk treatment plan. Also what's important is point F, obtaining the risk owners approval for the risk treatment plan and the acceptance of residual risk. That's the risk that's going to be left. after the treatment has took place. This is vitally important. This is one that sometimes I have identified as being a problem as an auditor where I've seen very good risk processes but then a disconnect between the process and the risk owner. So I'm always looking to see that the risk owner was involved and ultimately made that final decision. But before we look at the statement of applicability and a risk treatment plan We need to talk generally about the different risk treatment options that exist. So let's imagine an information security risk has been identified and we want to do something about it I'll go through a few different options. Now first one, risk modification. Risk modification means changing the circumstances around a risk. So that might be about implementing controls to reduce vulnerability. So let's say for example I have a network architecture and we identify the way in which the network segregated leaves its vulnerable to the attack. So we propose you know more granular segregation and introducing some kind of firewalling technology. We'd be doing a risk modification. To reduce the vulnerability and the likelihood. Or let's imagine we want to reduce impact. A very simple example of that. Let's think about organizations that use mobile devices like laptops if they do if they apply whole disk encryption to that laptop. It doesn't reduce the likelihood of the laptop being lost or stolen, but it does reduce the potential impact when that happens because we have more of a confidence, that confidential data isn't being disclosed. Both of those would be taking risk modification actions. Now the reason ISO calls it modification rather than reduction is In theory, we could allow risk to go the other way. If we identify, for example, we're spending a lot of time and money on a security control that's keeping a risk really low, you're well be well below the risk tolerance level, it may be a case that We can remove security controls to some degree, allowing an increase of risk, as long as it's managed, to assign that budget, time, etc. , somewhere else. So ISO does leave it as very flexible. hence the term risk modification. Other things an organization could do, risk avoidance, risk avoidance is where we take a decision to deliberately as you as you gathered there, avoid the risk scenario uh either partially or to some degree. So for example, um if we were selling goods online and we were seeing a particular amount of credit card fraud, let's say coming from a particular particular territory, we could take the view to stop taking card payments from that particular territory. Now that might be commercially a bad decision, possibly, but it is a theoretical example at least of risk avoidance Or if we said we will not use a particular type of technology because we're concerned about the risk level, you're taking a risk avoidance step. That's not always practical, but it is an option. Another potentially practical option to deal with risk is what we call risk sharing. In previous guidance and in other books, you might read this as risk transfer. ISO deliberately stopped using the word transfer. Because we're not passing a risk to somebody else. Risk sharing is where two organizations of people might share the burden. So let me try and give an example. Outsourcing is a good example of risk sharing. So let's say we have a particular problem, we share that with a third party, the risk still rests with us. I'll give two sort of worked examples on this. So one, I worked with one organisation that identified that it had quite a number of network security problems. And the organisation openly said, look, we don't have the expertise in-house to address some of this stuff And therefore they took a decision to enter into a partnership with a s a company who would maintain their network equipment for them. And they were very transparent about the vulnerabilities they had. And it was therefore the responsibility of the network service provider. to deal with some of these security vulnerabilities. But it's a shared risk because my client can't just then say, ah well, it's managed by somebody else if there's a security breach, an incident, etc. It would still be my client answering to the regulator, answering to the customer, but they have shared the workload, obviously with due diligence, with that third party. You often see this as well. Another example is with card payments, so websites that take card payment online. Some companies will say, well, rather than us take the risk of processing those credit card details ourselves We'll have a module that's run by a trusted third party, usually a PCI DSS service provider, and we'll share the burden with them. So they're going to deliver the service obviously for a fee, but the risk is shared. Now there may be cases where none of those options are practical or affordable. It could be that the cost of implementing modification is prohibitive or technically not feasible. There might not be a partner you can share it with and maybe risk avoidance just doesn't make sense At this point we might be into the realms of what ISA would call risk retention. That is to say that we have to accept that risk. That doesn't mean accept it forever. We might accept it for a period of time until better options come along. But accepting risk is something that ISO allows, providing that it's done as part of a proper process. in in in line with your risk management process and providing it's not just the default go-to option so we can't just say well uh we've got a long list of risks let's just sign everything off and hope the auditor uh is happy with that But where it makes sense those decisions can be made. But let's talk about risks where the treatment will be to implement controls. So according to clause 8. 3 of ISO 27005, the guidance document on risk management, it says that we shall select controls in order to address risk And those controls can be preventative, detective or corrective in nature. So we mentioned that in uh in the earlier section in the course and the difference between them. But practically speaking, we will find the controls that are very relevant here in annex A of ISO 27001. So let me just mention a couple of things about Annex A. So as we've said earlier, there are 93 security controls in there. It is not mandatory to implement every single one of those controls. An organization will need to run through them and decide which ones are applicable and which are not. Where a control is not applicable, the organization will need to mention this in a document called the Statement of Applicability and basically give a justification. You also need to justify the controls you've included by the way as well are marked as applicable. But when it comes to things that are not applicable, wearing my audit hat, I'll often talk the organization to say, okay, how have you come to the That conclusion. And sometimes it might be that a control isn't needed because the process isn't in place. For example, there are controls in Annex A about software development. Well, if your organization doesn't do software development or it's not in scope of the ISMS, that might make sense to mark that control as not applicable. And we'll have a look at that in a bit more detail in just a moment. But one thing I always like to tell people about Annex A is when you look at those 93 controls and try and read them, they're often described in no more than a sentence or a couple of sentences at best. And whilst you know you could read them and they probably make some sense, it doesn't give you a lot of implementation guidance as an organization. Let's take A5. 7 on threat intelligence. It simply says, you know, threat intelligence shall be gathered and processed by the organization or something along those lines. Not with a lot of detail in it. Now let's imagine I'm the implementer here and not the auditor. Then I might want some greater advice and guidance on how I'm going to fulfill that control. Well, that's where ISO 27002 comes in. So what ISO 27002 does is it's a document, a guidance document. It takes all the requirements of Annex A, or all the controls I should say, of Annex A, and for each and every one of those gives an explanation. So let's say let's take A5. 7. It's numbered the same in ISO 27002. You could go to that section and it will explain the control and its purpose or the objectives of such control. control is. It will give some implementation guidance and examples of things to think about and some additional reading what we call supplementary information. Now the key thing is about ISO 27002, it is there to help the implementer. Now as an auditor, I still look at ISO 27002. to make sure I'm familiar with the control, to make sure I'm asking the right questions as an auditor. However, I am not auditing an organization against ISO 2702 because it's not a set of requirements. So I cannot raise a finding to say you've not done something where the word should is used Because the word should is guidance. But at least if I've read it, I understand what the control is about. It puts you in a better position as an auditor to ask the right questions. But as an implementer, I would argue 27,002 is absolutely vital Now, there's a diagram we've included here, this sort of thing that looks a bit like a wheel, if you like. And this is for people who may be familiar or may have worked with the 2013 version of the standard. and want to see the comparison between the Annex there and Annex A in the newer standard, the newest version being the 20th So in the 2013 version of the standard, and some organizations are still aligned to that because they've got till the uh I think the end of uh October in 2024 to try transition so maybe some of us still sort of uh using that. That had in the annex 114 security controls grouped into areas which were called control objectives A5 through A18, covering many topics. And what we've seen in the new version is an effort to simplify that. to put 93 controls into four distinct areas. And people certainly have their opinions on what they prefer, but that's where we are today. And of course, the logical question I get asked is, hang on, we've gone from 114 controls to 93, so surely the newer version of the standard isn't quite as strong. That's not actually true at all because None of the controls from 2013 have been deleted as such. What's happened is in the newer version in 2022 quite a few of those controls have been merged. So in other words, where you had separate controls. describing something that have been brought together. And actually there's new controls in Annex A of the 2022 version. Things like threat intelligence, data loss prevention, data masking and information deletion. and configuration management, web filtering, those are a few that I can name, that have been added. So believe it or not, actually you've now got more control in the annex than you did in the previous version. There are plenty of documents out there that do show a mapping as well available online that if you want to see the mapping between the two annexes So, with all of this in mind, we need to create a document called a statement of applicability. As a when I say we need to create it, the organisation implementing the ISMS needs to to create it. We as auditors will of course review it. And as I've said, this SOA statement of applicability is a document that lists all 93 controls And the organization will state whether they apply or not. If they do, why? If they don't, why not? Usually if they do, though the answer to that will be to address risk, to address a legal or regulatory requirement. fulfill the customer requirement. Our job as auditors is to review that SOA and make sure, as we'll see in a second, that those controls and those selections are justified. If an organization decides it's going to add other controls into its ISMS, so let's say we have a company that needs to follow PCI DSS because it's processing credit card data and they include those controls, those controls should also be spoken about in the statement of applicability. So let's just explore that a little bit further. Let's imagine you're looking at a statement of applicability and an organization has marked some controls as applicable. So they've said yes, they need it We need to see the justification. Why does it apply? So they can't just say, yes, because you know we're just ticking a box. There's got to be a reason. So let's take this uh example on the slide here, uh which is related to A5. 20. Relevant information security requirements shall be established and agreed with each supplier based on the type of supplier relationship. And they've said They want to implement this control because they want to ensure security across all IT components. A number of IT components are being used or delivered by suppliers. This is perfectly fine justification. As I say, they could have said we've identified a risk in this area and therefore we need this control to address risk X, Y, and Z. They could have said we have a legal and regulatory obligation to monitor our supply chain, therefore the supplies, or we have a customer uh requirement in our contract if that was applicable. So there's many ways there, depending on what the right answer is, to justify it. But they've given an explainer. Note that that explainer is only a paragraph. We don't need as I like to say to people, war and peace in here. You can show me other more detailed technical documents separately, but just enough of a summary would be sufficient On the flip side, excluding a control, we've got a few examples here, of A6. 1, an organization deciding not to implement that because it violates legal or contractual requirements. Now in reality it's probably a partial uh answer to that because I'm sure there's still some background checking they could do. But anyway, if a control was at odds with a law or a regulation We could exclude it. Or if it's just not relevant, like remote working, if we don't actually have people working remotely or software development if we're not doing that in-house, those are perfectly sensible reasons to exclude exclude controls. As an auditor our job is really to look at especially those excluded controls make sure the organization has fully understood them and fully their their reasoning makes sense So here we have a simple example of a statement of applicability. Obviously, there's only two controls in it, a real one would have 93. And this is just to show typically how an SOA is laid out So you can see in here two controls. One is marked as applicable, yes, with a description and a justification. And then we have the one there on remote working, applicable no. justification. One thing to say is this is a living breathing document. The organization should always be adjusting and updating its statement of application. Is necessary. And the last thing to say about a statement of applicability is when an organization is certified on their certificate, it will refer to the statement of applicability version and anybody who's looking at the certificate is entitled to ask to see a version of the SOA. In other words, if I'm doing due diligence on an organization and they tell me they're certified to ISO 27001 as well as understanding the scope of the ISMS, I would want to know which controls they've implemented and which ones they haven't. And it would be perfectly reasonable to ask that question. The last part of clause six is also worth mentioning here as well, is not so much about risk, but objectives. It says the title of it is the information security objectives and planning to achieve them. So all organizations should have information security objectives. Some of those objectives might be derived from the risk assessment we've done, hence why 6. 2 for that. 6. 1. Some objectives may be derived from commercial objectives, you know, things we want to achieve. But of course the whole point of having an ISMS is to fulfill certain objectives. just have an ISMS for the sake of having one. And what the standard says here is the information security objectives that the organization does identify shall, as we see, be consistent with the information security policy. which would make sense, be measurable, if practicable, I'll come back to that in a second. Take into account applicable information security requirements. and results from the risk assessment which we've just been talking about and those objectives shall be communicated and updated as appropriate. So what this means Is depending on the work you've done in clause four, understanding the needs and expectations of interested parties Depending on the work we've done in clause 6. 1, understanding our risk, depending on the discussions we've had with our management, we'd put together a set of objectives Now some security objectives might be very high level, you know, basically long-term. You know, you might say an organization might say they have an objective to ensure ongoing legal and regulatory compliance, for example. But some may have shorter term, much more measurable objectives. So if you said, well, based on our understanding, we want to improve our security incident management response time by X percent in the next 12 months. That would be a very clear short-term objective. But what we're looking for is not that the organization just has a list of objectives, but are there clear plans that really specify how they will achieve them. Because in the end, from an audit point of view, the judgment we're making is not only Does this ISMS conform to the requirements of the standard? The other big one is does this ISMS allow the organisation to achieve its objectives? Because that's the whole thing. purpose so of course they can only achieve it with adequate plans in place. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S05.4-Overview-of-ISO-27001-requirements.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S05.4-Overview-of-ISO-27001-requirements.md index 82a0626..317b0ef 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S05.4-Overview-of-ISO-27001-requirements.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S05.4-Overview-of-ISO-27001-requirements.md @@ -17,6 +17,8 @@ status: active ## Abstract +This session covers ISO 27001 clause 7 (Support), which establishes the building blocks of an effective ISMS. Topics include resource planning (clause 7.1), competence requirements for security roles (clause 7.2), awareness programs for all personnel (clause 7.3), communication planning with internal and external interested parties (clause 7.4), and documented information management (clause 7.5). The session emphasizes that documentation must add value rather than exist for compliance appearance, and that the level of documentation should be proportional to organizational complexity. Document lifecycle management including creation, approval, distribution, archiving, and disposal is also addressed. + ## Transcription So next let's take a look at clause seven. So clause seven in the standard is entitled support and it covers five distinct areas from resources to documented information. So before we sort of look through these what I describe clause 7 as is the building blocks of the management system. In other words, these are all the things that would need to be in place in any organization for a management system to work effectively. So let's just take a run through and understand what the standard is requiring and some of the things we should be thinking about. So clause 7. 1 then says the following. It says that the organisation shall determine and provide the resources needed for the establishment, implementation, maintenance and continual improvement of the ISMS Now when we say the resources needed, these resources could be human resources, as in people, financial resources, so appropriate budgets. tools and technologies, you know, physical workspace if that's relevant. This is what we mean by resources. So what we're looking for is that the organization has Planned the resource requirements has a proper resource plan in place. They should be thinking longer term as well So one question I always like to ask is, you know, if you expand, for example, over the let's say coming 12 months, if that's in the organisation's plans, have they thought about how they'll ensure that there's adequate resource provision in this case? Particularly relevant with roles and responsibilities as well, do those resources have enough time? So there was a case with one organization where it was a relatively small business And the IT director was also named as the information security manager. And this person was perfectly able to do that job, except for the fact that they didn't really have time. Their IT director duties were so large if you like they didn't have the time to do that that would point to me as a resource problem. So have they properly planned that resource out over the long term Now if we focus specifically on human resources, not only do human resources the people need to have time, they also according to the standard in clause 7. 2 need to be what we call competent. And clause 7. 2 states that, without necessarily reading out every line, that the organisation shall determine the necessary competence of persons doing work under its control that affects security performance. That the organisation should ensure that those people are competent on the basis of what this is, education, training, or experience And where applicable, in other words, where there are situations where we need to improve competence, that those gaps are essentially plugged. And there should be evidence of that. So let's think about that practically speaking. So this means when an organization establishes roles and responsibilities for security, this should also establish the kind of skill sets that those people fulfilling those roles should meet. Now you won't find anything in the standard saying that somebody in a certain position needs to have X amount of experience or you need to hire somebody with this qualification. it's down to the organisation to determine that. A really good example of that I saw on a real world audit was a quite a large organization and they had a large cybersecurity function and they had what they called a competence matrix. So basically on on in this matrix they basically had one axis which was all the job roles in the cybersecurity function from SOC analyst to red team test right through to sort of uh your governance risk and compliance roles, so real variety And then across the top axis they had a bunch of skills described there from networking knowledge to application security to risk management. And each area on the map on the axis you could sort of plot it had a number assigned to it and that number was basically the required skill level for that role. from a level one, which they said was introductory or basic knowledge, through to level five, which was subject matter expert knowledge in this case And so the idea was you could look at any role and say what are the kind of skills and knowledge that the an individual within that role needs to have. And that organization used that to first of all develop its own internal employees so it could work with their staff to see where they might want to enhance their skills and provide them with training and support. They also used it as a career development mechanism. So if you were in one position and wanted to move or progress, you could see the kind of learning path you would need to take, the training path you'd need to take to get there And they also used that when they were onboarding new employees because they could actually then test somebody's competency through not just looking at their qualifications but maybe getting them to do some tests or competence-based activities in their interviews. So being clear about what the skill set requirements are is going to be important. Because you imagine running an ISMS and having individuals who might not have the required skills that could undermine things very easily. Let's take software development, for example. Let's say I have software developers who are not familiar with secure coding, for example, then you know that could potentially then lead to vulnerabilities which otherwise wouldn't have been present. So ensuring competence across the board is important. There's a lot we can say about that, but at this level, this is what clause 7. 2 is asking us to think about. Now that's slightly different to awareness, which is a much more broad thing. So when we look at clause 7. 3 it says The persons doing work under the organization's control, so that can be both employees, freelancers, contractors or even suppliers. shall be aware of the information security policy, their contribution to the effectiveness of the ISMS and the implications of not conforming to the requirements of the ISMS. Now many organisations tackle this by having quite a broad awareness program for both new employees joining the organization and for people there longer term. So you might think see things like e-learning activities, you know, awareness training sessions and so forth. But what we're looking for is what efforts are the organization making to really drive the right security behaviours in the organization Longer term that might be about building a strong security culture where people think about security almost as just being a normal part of their duties, not as a sort of a separate discipline. And again a bit later in the course we'll talk about as an auditor the kind of evidence you can seek out in this area. For example, looking at training records, I often as an auditor we'll choose a sample of employees and I'll interview those employees during the uh the audit. Not to catch them out or anything like that, but just to understand what are they aware of when it comes to security. Do they recall what training they had? Do they you know what do they think the most significant security issues are often just those kind of questions could soon tell you uh what levels of awareness are generally in place in the organization Now another thing that clause 7 focuses on is this topic of communication. So let's think about what we said in clause 4. We said in clause 4 that the organization should identify its interested parties, both internal and external. But it's not just a case of identifying them. Obviously to run an effective management system the organization and those running the management system would need to have regular communication with different interested parties. And there might be different reasons for that regular communication. It might be about giving interested parties an assurance when it comes to security. So for example customers, we might want to keep customers appraised of what we're doing to give them or instill and maintain confidence. It might be about support. We might be regularly communicating with our top management in order to get the ongoing buy-in and commitment that we need. Or we might be regularly talking to users in order to encourage the right behaviours. So for every interested party, there might be different reasons and purpose. for communicating. But what the standard says is we should essentially come up with a plan laying out on what we're going to communicate to who, so what kind of topics, how frequently we're going to do that and the methods we're going to use. Because every interested party, the way in which we communicate may need to vary depending on their level, their purpose, what they need to know. And so there should be a strong communication strategy and plan. And obviously from an audit point of view, I would want to see that plan, I'd want to see the examples of communication. And not only that What are the organisation then doing with that? In other words, is the communication effective? So, you know, it's great, for example, to send a let's say a report to top management every month on how we're performing from a security point of view But what impact is that having? In other words, is that leading to the desired effect of, in this case, let's say more buy-in? What sort of feedback are they the organization getting and are they adjusting it? But what we're looking for is on that ongoing communication. And one thing I should maybe just add to this is that the examples I've given there might seem a bit one way, like I'm talking about the organisation talking to its interested parties. Obviously communication comes back the other way as well and so how does the organisation manage that? So for example, let's say an employee in the organisation has a question about security and wants some help. Well, how can they go about seeking that? How responsive is the organization to that? Because if you could see gaps there, that could be a potential problem. You know, if people are coming for advice and not receiving it very quickly it might happen happen the next time round that they say well I won't bother I'll just skip that particular step. So we're looking for the overall communication plan and approach Now in any ISO standard, any management system standard, of course, there is always talk about documentation or documented information as ISO would put it. And I've heard sort of some myths if you like about ISO standards when it comes to things like this. I've heard people saying things like, well all ISO standards are documenting what you do or you need to create loads of documents in order to meet the requirements of an ISO standard. So two things to tell you there. It's not just about documenting what you do. Because ultimately you could be documenting things that you do that aren't particularly very good. So the point is it's about creating documentation that's needed to support the organization in doing tasks um well and doing tasks in a consistent manner. Also it's not true to say that you need to you need to create mountains of documents for the sake of it. So let's actually have a look at what's what the standard actually says and then we can work this out. So it says the following in clause 7. 51. The organization's information security management system shall include documented information required by this document. That's quite a mouthful isn't it? But basically documented information required by the standard So it is true that there are some minimum documents that need to be created when implementing ISO 2701, but there's not a huge amount of them. The main documents, I won't necessarily be able to recite every single one of them, but the main ones that spring to mind here are things like the scope. Of course, the scope needs to be documented the information security policy, the risk management process, the statement of applicability, the resource requirements. These kind of things you would expect to see, the internal audit process, you'd expect to see those documented. And how do you know if something is required? Well when you read the standard, if you see the words this shall be available as documented information, that's point A. But the myth bit about creating lots of documents is the bit in B, point B, 751B, which says documented information determined by the organization as being necessary, key word, for the effectiveness of the ISMS. So what you've sometimes see and I've certainly witnessed in real life and I shouldn't criticize consultants because I am one myself but I sometimes see consultants who are going to an organization They'll look up clauses 4 to 10, all 93 security controls and write a document for each one. Well there you are, here's a huge bunch of documents for you and guess what happens? Those documents don't get read. You might end up calling them shelfware. You might have heard of that term before, just documentation that isn't looked at. So that's not what the target is here. We've got to determine what documentation we need. So if we're in a complex environment with a complex task, let's say a system administration task that we need the system administrators to do consistently in detail, then of course something like that you'd expect to see a detailed document with step-by-step instructions. Maybe for simpler tasks, lower risk tasks, where we have a highly competent workforce, the level of documentation won't be quite the same. An example from an audit I actually give when I teach this course is the following one. I did an audit of an IT company that had 15, that's 1-5, employees. Uh and in this audit I um spoke to the uh the basic the owner of the company and we were talking about HR security and I asked him about the leavers process. So I said, can you take me through what happens when somebody leaves And how do you ensure that you remove all system access when they've gone? And he said, well, being honest with you, in the last five years I've only had two people leave the organisation, but here's what we do, and he talked me through it And I checked the uh all the uh the various systems, the Active Directory, a few other applications. I could see that those accounts had been removed. I'd seen an email to the administrator confirming this. So I was happy that the two individuals we're speaking about had had their access remote So I asked him, I said, if you're not here, given that you know the process, well what would happen then? And he explained how his colleague also would cover this and I interviewed that colleague separately. So long story short, by the time I'd done those interviews and looked at that evidence, I was satisfied that they had managed those levers effectively. But I asked the classic question, which is, you've verbally explained this procedure to me and I've seen evidence that it's happening. But have you documented it? And the answer that came back was no we haven't. We haven't written a document. And then I have a decision to make as an auditor. Well the standard doesn't actually say, believe it or not, that there shall be a document So in that organisation I took the view that what I've seen is effective. I did raise an opportunity for improvement and I said to them, if you grow and there's more people involved then this is more complex. You probably ought to document this, but certainly it's not a mandatory requirement. Now had I have been told that story in a company with a a thousand or two thousand employees, I would have taken a very different view because the lack of documentation could mean that the process would be ineffective. So this is the point about point B. Every organization is different and especially as an auditor you just need to think about the proportionality. Documentation should always add value, not just be there for the sake of ticking boxes. Now one thing that is important for the documentation that is created, whether that's created in Word documents, on wiki pages, in products like Confluence or wherever it might be is that the organisation has what we call a document life cycle. There should be some rules that specify how documents are created and who can create them. So maybe some levels of authorisation There should be some information about how the organisation will identify those documents. Is it a policy, is it a procedure, including the classification and security level. So in other words, is this a document that is limited to internal use only, limited to a certain audience? Does it have a certain level of sensitivity? If the answer to those are yes, obviously I would expect to see security handling rules in an audit, we'd be testing that as well to see if those security rules have been followed. What are the rules about modifying documents? So do we have access restrictions to stop people simply making changes to documented information unless they're authorized? And I'd want to understand the approval process. Now approval processes may differ. A corporate policy may need a different approval channel to a let's say a local procedure in a given department. But how does that work? I'd also want to understand how documents are actually distributed. It's one thing to have good quality documents, but how do the people who are meant to use them know that they're there? So how do we share them with people And of course we can test that in real life during an audit by looking at the documentation people are using, asking them questions about it So recent audit I did, for example, the organization had launched a new AI policy just a few weeks before the audit. So when I did my awareness interviews, I asked a number of people, I just said, have you seen the AI policy? Where would you find it? And I wasn't grilling them on their knowledge, it was more about could they find it, did they know it existed, you know, could they consult it if they needed it. How does the organisation check whether the documents are being used adequately or not? Again, in other words, are people actually referring to them? Are they actually following what's stated in these documents? That can be discovered through things like monitoring and metrics, through the internal audit process perhaps. These are all relevant points. And then the last two bits, archiving and disposal. Depending on the information or data retention policies of the organisation, there might be a point in time when organisations archive documents, that is to say keep them, but just store them for the longer term. And there may be a point when they actually decide to destroy or dispose of those documents. Again, I'd want to understand what the rules are about that From an archiving point of view, are there any security rules? How are those archives protected? Now thankfully the vast majority of documentation today is electronic and there are electronic archiving solutions Back when we had a lot of paper documents, I'd have to concern myself with physical archive storage, for example, and how secure or well protected that might be. And then disposal, the way in which data is destroyed, might vary depending on sensitivity. So there's no right or wrongs for all of these, but there is an expectation that all of these points can be answered. Now typically that would be answered in a document management policy. So an organization really ought to have a document management policy that answers all of these. The last point I want to make on this is if an organization who is implementing ISO 27001 has another management system in place, let's say 9001 for quality it might be that they already have these processes in place and could essentially reuse them because all ISO management systems have the same demands so that's always something to explore as well. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S05.5-Overview-of-ISO-27001-requirements.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S05.5-Overview-of-ISO-27001-requirements.md index cd4e79a..667bf21 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S05.5-Overview-of-ISO-27001-requirements.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S05.5-Overview-of-ISO-27001-requirements.md @@ -18,6 +18,8 @@ status: active ## Abstract +This session completes the overview of ISO 27001 requirements, covering clauses 8, 9, and 10. Clause 8 addresses operational planning, control of externally provided services, and execution of risk assessments and treatment plans. Clause 9 covers performance evaluation through monitoring and measurement, internal audits (including auditor independence and audit programme requirements), and management reviews. Clause 10 addresses continual improvement and the distinction between corrections (fixing symptoms) and corrective actions (addressing root causes through structured root cause analysis). The session emphasizes that risk management in clause 6 underpins all other ISMS requirements. + ## Transcription Let's take a look at the next clause, clause eight operation. And that has three parts to it, operational planning and control, information security risk assessment, and information security risk treatment. So let's have a look at operational planning and controls. So what this is about in clause 8. 1 is we've said that when we establish an ISMS we'll implement security controls from Annex A and various processes. But of course an organization should think very carefully about how to roll out those controls and processes so that when they are implemented, they're implemented effectively in what I would call a sustainable manner. In other words, they're there to last. speak. So this means thinking through how those processes will be defined by having clear criteria to say this is what what success looks like and having a level of planning. So for example, let's imagine an organization was going to deploy, let's say, a log management solution to monitor and that they're going to use to capture logs, maybe monitor for suspension. Well what you'd expect is there'd be a series of um series of things done. The organization would specify the need for such a lock management. management system, you know what sort of functionality should it have, what sort of events and logs should it capture, what sort of capacity it should have, all of these things. It would specify some criteria before actually making that decision. The organization would specify how that's going to be used, you know, what's the processes to be followed to review those logs. how does that process link to the incident management process of the organisation and so on. They'd probably want to think about the resource requirements to operate that control effectively. Do they need a dedicated member of staff or a team. They might want to think about whether there's any training requirements that are needed before it's rolled out. how that might be communicated to the wider organization. So there'd be all these things essentially thought about before the deployment. And that's what we mean by operational planning and control. So that we have a confidence that what we roll out is going to be effective. Now there is an interesting point in here as well, which says that the organisation shall ensure that externally provided processes, products and services that are relevant to the ISMS are controlled. What this means is is if the organisation is depending on let's say a service provider or some some um process from the outside that this is still managed. So for example if we said right we're going to use a a SaaS platform, a software as a service platform to let's say for let's say for risk management. Well we're not just going to just buy the platform and just start using it even if we argue that the the actual tool is provided by a SAS provider We as the purchaser of that, the implementer of ISO 27001, would still need to make sure that that service provider meets our requirements you know offers the functionality that's required, offers the level of service, maybe availability, the level of security that's required. And it would still be part of the ISMS to monitor the activities of those kind of service providers or outsourcers. There is a separate ISO standard document that might help here which is not security specific but it does look on look at um outsourcing and it's called ISO 37500 it's called guidance on outsourcing Certainly isn't a requirement to look at that for this particular aspect, but it might help in giving you some guidance on how to have proper governance and oversight of um organizations like service providers and outsourcers. So that's what 8. 1 is speaking about. Now you might when you've looked at the beginning of this section have thought, what's this about information security assessment and risk treatment? Surely we've already spoken about that and looked at it in clause six And that's true. And this isn't telling us to do anything different, but essentially what we're arguing is you implement your risk management processes as per clause six. essentially 612 and 613 and then you in clause 8 the do phase of the plan due checkup cycle you execute those things So that this is confirming that those risk assessments are actually being carried out, that the risk treatment plans are actually being implemented. So essentially you're moving from the plan stage of risk assessment and treatment in six to the actually doing it in cloud. So there's nothing different here other than we have to execute the stuff we plan to execute in clause six. And that then feeds into implementing controls and planning them properly, which is what 8. 1 is talking about Now when we think about an ISMS and going through a series of steps, at some point when we've implemented controls, the organization needs to be checking whether those controls work effectively. And that's what clause nine tackles. Clause 9 is performance evaluation broken down into three areas, the monitoring, measurement, analysis and evaluation, basically metrics. Internal audit and management review. So let's just have a look at those and what they mean and some of the key points. So clause 9. 1 talks about this concept of monitoring, measurement, analysis and evaluation. What that means in a practical sense is deciding what parts of the ISMS the organization would like to monitor on a regular basis in order to identify its performance essentially and to evaluate performance. Now the ISO standard itself does not say which controls or which processes to monitor and what performance evaluation targets to have So what we typically say here that's up to the organisation to select. But the important point is we don't expect an organization to take clauses 4 to 10 and take every control in the annex and try and have a measurement or performance evaluation for everyone. Instead we expect them to focus on key things. And the big one for me would be security objectives. So an organization should be looking at what security objectives it has and then asking the question how will it measure and check whether those objectives are being fulfilled. That's the primary priority here. Other things an organization might want to measure regularly might be things like legal and regulatory compliance. It might be about measuring controls that are implemented to deal with significant risks. Because obviously if those controls aren't working as expected, then risk may be higher than it should be. And what we want to see is not just a list of things that will be measured, but some information on how frequently those measurements will take place. um how practical they are, you know, who's doing it and so forth and what action is going to be taken in response. Now when it comes to performance evaluation, in other words deciding based on these measures what good looks like. The ISO standard doesn't say this to us. So it doesn't say, for example, with patch latency, how long it takes to apply patches that we shall do that in five days or ten days or something like that. The organisation will set its own targets. Those targets might come from contractual obligations, legal obligations. obligations and other standards or it might come through its own setting its own KPIs. So what we're looking at when I say KPIs key performance indicators when an organization designs and implements an ISMS it will want to identify early on what those key performance indicators are. From an audit point of view we want to make sure that the organisation is checking those things regularly. Now the other thing an organization should be doing to validate whether its ISMS is working effectively is to be conducting its own internal audits. So when we deliver this course, we're talking about this from an external auditor's perspective. That being said, everything we teach in this course can be applied by people who are doing internal audits as well. So if you're an internal auditor Everything you learn here you can still apply. But basically the standard requires that internal audits are performed at what it says regular intervals And the purpose of internal audits is to validate whether the ISMS meets the requirements of ISO 27001, but also to validate whether the ISMS is actually effectively implemented, maintained, is it set up in a way to help the organisation fulfil its objectives and so forth. Now there's a few points to make about internal audit that are important. As we'll describe in audit principles Independence is a very important part of audit. Now, internal auditors aren't necessarily independent of the organisation, but they still need to be independent of the work they're assessing. So we need to make sure that whoever's working as an internal auditor is not auditing areas under their control. They're not essentially auditing their own work. We need to make sure those auditors are in a position wherever they sit in the organization. to be able to openly make honest observations based on the evidence that they see. We also want to validate that internal auditors have the necessary competence We mentioned competence in clause 7. 2. We will go through a little bit later on the specific competence requirements for auditors. We need to make sure the internal auditors have those skills to perform them. And we also need to make sure that the organisation doesn't just do a one-off audit, but they have what we call an audit programme in place. An audit programme means there'll be a series of audits over a period of time. In some organizations, rather than doing sort of one ISO 27001 internal audit every year, they might spread that work out over a period of time, perhaps doing deeper dive audits into particularly critical areas. A quick example is I work with a software as a service provider who they have quite a unique product. They develop all the software themselves and therefore one of the critical areas is secure software development. So their internal audit programme includes many reviews of software development practices, possibly more reviews in that area than others because they see that as a critical area to be more closely monitored. So some of those audits focus regularly on that as part of a bigger audit program. And then in clause 9 we also have what's called the management review. So the management review is the opportunity for top management, which we talked about earlier on. It's their opportunity to see what is happening with the management system. So a management review does not have to be a meeting called management review, although that can happen that way, but at regular intervals top management need to get together, whether it's physically, online, or wherever it might be. to take a look at the management system. Now usually this would be facilitated by a security manager or a CISA or whoever's sort of overseeing the ISMS And in management review, it's important to point out is usually looking at strategic aspects. In other words, does the management system meet the requirements of the organisation? Is it aligned to objectives? Does the scope of the management system need to change in any way? Does it need to be updated to respond to risk or legal and regulatory requirements? And some people ask, well, what should be on the agenda in these management reviews? You know, what should we talk about and what should we cover? Well the answer to that is I don't need to give you an agenda because you've actually got it here as you can see on the slide, A through G, the management review shall include consideration of all of these points. Whenever I conduct an audit we always comment on whether all of those points have been covered. The point about a management review though is it's not just a meeting where these things get discussed. It is a place where decisions can be made about how we continue to operate the ISMS going forward. So management review should be an effective program for top management to have an influence and an oversight of the management system Now, given that those three things we've talked about are all to do with checking how well the management system is actually working. Clause 10 then is focused on what we do in response to those things or what the organization does in response to those things. So there are two things in clause 10. 10. 1, continual improvement. and 10. 2 non-conformity and corrective action. So if we talk generally about continual improvement, 10. 1 This is one of the requirements which basically has a one, well almost like a one-paragraph requirement, which basically says the organization shall continually improve the suitability, adequacy and effectiveness of the ISMS. That's literally all it says. So suitability, is the ISMS fit for purpose? Adequacy, is it meeting the minimum requirements that need to be met by the organisation? and effectiveness, is it working to the organization's needs? So the issue with this as an auditor is you might ask well how do you even check this? And there's two things. If this is an initial audit, that is to say this is the first time we've ever been to see the organisation and the ISMS implementation is relatively new. There might not be lots of different improvements that the organisation can point at to prove this is in place, but what they could point at is how they're going to measure and what mechanisms they've got in place to respond. As an example, I did a recent audit. and the chief information security officer showed me an analysis that the organisation had done. So they took all these areas of security, they called them capability areas, like incident management, education and awareness, risk management. and so on. And for each area that identified where they currently were in terms of maturity. And basically the seesaw had set. a strategy for the year ahead saying these are the improvements we expect to see and every month they were checking their metrics to see are they on the right track So even if not everything is in place that they want to have in place, they're demonstrating a culture of continual improvement. Over time, when an organisation gets certified, of course, every year, as we'll get to, we do what's called surveillance audits, and in a surveillance audit we're always looking for examples of continual improvement. Now this is slightly different to clause 10. 2, non-conformity and corrective action. So in brief in non-conformity is the non-fulfilment of a requirement. So in other words when a requirement of the standard or requirement of the organisation's own requirements is not being met and the organisation know that it's not being met, whether they've detected that through metrics an incident or through the audit process, clause 10. 2 requires that action is taken to address it and to prevent a recurrence in this case. So this is where we just need to quickly draw a distinction between a correction and a corrective action. Both of them are important but they're both slightly different. And this is an audit example I can give. So I did an audit of an organization and we found that on their network there were a number of devices that had not had their software patches applied for over 12 months. And the organization openly said, look, this is an oversight, this is a mistake. So it wasn't a risk-based decision. They basically had a number of flaws and problems. And they said, ah, well what we'll do immediately is we'll apply all the missing patches. will pretty much do that straight away. Now that's obviously a good thing. I'm not going to discourage that. That's what we call a correction. They're taking action to address the symptoms of a particular problem. But the question is, what gave rise to these machines having missing patches for over 12 months in the first place? And what's the chances when I come back in three, six, twelve months time, that I'm going to find the same problem again? So they need to do some kind of root cause analysis to get to the bottom of it and then take action to prevent the recurrence. And in their case, they'd found a number of problems with their process. They'd update in response they updated their patch management process. They did a lot more close monitoring. They made somebody particularly responsible for that process. And eventually that addressed the problem and stopped it recurring. And what we've described in the latter part of that example is a corrective action plan And that's what this slide here is showing you with the steps involved in a corrective action process. So in any case where a non-conformity is detected. We would expect an organization to describe that non-conformity, conduct a root cause analysis, maybe they've got a root cause analysis process. An organization I spoke to recently about this demonstrated an example to me called the five wise analysis which basically asks you to as it says look at a problem through multiple angles and at least five times ask each uh for each answer to each question we keep asking why until we get to a root cause. An organization needs to evaluate and select solutions to that problem but and then implement them, but not just implement the solution and assume it's worked. they will monitor for a period of time has that action worked. So like that organization I was just telling you about with their patch management, they didn't just rewrite the process and say, well, let's close the non conformity, they monitored that for a period of time and over several months they could see that they were no we were no longer falling behind on their patch management cycles So in summary what we've tried to do in this section is give you sort of an overview of an ISMS. by doing a bit of a helicopter tour of clauses 4 to 10. All of those are worthy of much more discussion and please be assured we will be digging into some of these a lot more as we go through here But all of clauses 4 to 10 are mandatory in order to achieve ISO 2701 certification Based on risk, an organization will then choose which controls from Annex A to implement as well, and they can decide which are applicable and which are not. And ultimately at the heart of ISO 27001 is risk management. So what I would say is the part clause six where we talk about Identifying, analysing, evaluating and treating risk is fundamental because that then influences everything else that we see in clauses four to ten. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S06.1-Fundamental-audit-concepts-and-principles.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S06.1-Fundamental-audit-concepts-and-principles.md index 41fac72..07959c9 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S06.1-Fundamental-audit-concepts-and-principles.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S06.1-Fundamental-audit-concepts-and-principles.md @@ -12,6 +12,8 @@ status: active ## Abstract +This session introduces fundamental audit concepts based on ISO 19011, ISO 17021, ISO 27006, and ISO 27007. It defines an audit as a systematic, independent, and documented process for evaluating objective evidence against audit criteria. The session covers audit types: first-party (internal), second-party (customer or supplier audits), third-party (certification bodies), and combined audits. Key terminology including shall, should, may, and can is explained in the context of ISO verbal forms. Involved parties are defined: audit client, auditee, auditor, audit team, technical experts, observers, and guides. + ## Transcription Hi there, my name is Carl Carpenter. I will be your instructor. I am a consultant for Arrakis Consulting, a full service cybersecurity firm. I've been dealing with cybersecurity for over 30 years. I'm also a former chief information. Security officer for a $6 billion entity dealing with all types of regulatory environments. And for this course, this is the ISO IEC 27001 lead auditor course Sponsored by PECB. Hi, thank you for joining me. This is section six for the ISO IEC 27001 course. Fundamental audit concepts and principles. In this section, we're going to talk about audit standards, what is an audit, types of audits, involve parties, audit objectives, and criteria a combined audit, principles of auditing, and competence and evaluation of auditors. Be warned this is a fairly long section, so make sure that you have plenty of coffee So what is an audit? Well as per ISO 19011 Clause 3. 1, it's a systematic, independent, and documented process For obtaining objective evidence and evaluating it again objectively to determine that the extent to which the audit criteria is fulfilled. So it's basically An assessment by an auditor on the evidence and the facts that a company is trying to present to that auditor. So it's it's very simple just asking a lot of questions and then evaluating the evidence that's provided, making sure that the evidence is in alignment with uh policy standards, procedures, processes, things like that, as well as possibly national or international guidelines So audits can come in a variety of flavors. There could be financial audits, there could be administrative audits, there could be an information systems or information security audit, which is what ISO 27001 is based on. So there's international standards on auditing, so ISO 1911, that provides guidance on managing an audit program, planning and conducting management system audits, as well as the competence of auditors. 19,011's most crucial aspect is that it provides the fundamental principles of auditing. But we also have 17,021. Uh-huh, which contains requirements for bodies providing audit and certification of management systems. So by complying with this standard, a certification body can prove competence, consistency impartiality and ensure credible certification. There's also ISMS audit standards, so 27,000 six-1, in addition to the requirements of 20 of 17,001-1 Certification bodies that provide ISMS auditing and certification services must also meet the requirements of 27006-1. This standard specifies requirements regarding the competencies that auditors must possess to audit an ISMS. There's also 27,007 And that twenty that standard provides guidance on managing an ISMS audit program, on auditing an ISMS against the requirements of ISO IEC 27001, and on the necessary competencies. That auditors should have to effectively audit an ISMS. So this standard focuses on ISMS audit activities and their steps. The importance of vocabulary is critical when it comes to auditing, not only from the standpoint of what the auditors say or do or write, but also from the standpoint that when the auditors are interacting with the auditee, that we're all using the same language and we understand that. So auditors need to have a firm understanding of the vocabulary and terminology that ISO uses in its management system standards and the terms and definitions that are specific to 27001. And we'll go over some terms and definitions in a few slides for now. So there are potential sources for the different types of vocabulary. So the one that uh is highly suggested is online browsing platform. It's a tool developed by ISO which provides access to ISO standards, terms, and definitions. But you can have other sources as well. So there could be specific publications by ISO, guidance documents, articles. possibly a glossary or or so on. You just want to make sure that if you're going to pick a term for vocabulary in or when you're interacting with the auditee, that you are using consistency in in relation to the terms. So standards themselves, like guidance standards, they will also have terms that could be relevant that you'd want to make sure that you're consistent with in relation to your conversations and your uh your recording of information or reporting or so on. So for example, ISO 9000 has uh deals with uh quality management. 27,000 is the ISMS family of standards. 27,001, as you know, is this is the course that would be for uh information security. And then based on the harmonized structure of the management system standards, clause three of a management system. Standard will contain relevant terms and definitions which are typically organized according to the veri uh hierarchy of concepts It's also important to understand that clause 3 is fairly consistent across any standard. They're always going to have the same set of terms. So we also have verbal forms. So ISO IEC directives provide the general principles for structuring and drafting ISO IEC documents. So, among other things, the document states that particular attention should be given to the verbal form of a document to distinguish between requirements, recommendations, permissions, possibilities, and capabilities. So auditors should be aware of these forms as well as how they evaluate the auditees when they're evaluating the audite's conformity to 27,001. So the important part in in relation to these uh different verbal forms, so if we have the verb shall, That is a requirement. That's not something that the uh the oddity can decide to not do. It's they shall do it. If there is the the verb should is uh in use, then that means they should do it, but that's not a requirement. It's highly suggested that they do it, but it's not a requirement. And then may means that the auditee could do something if they chose to, or maybe they don't. And then the other one is can, which is a possibility or a capability. So again, from the standpoint of shall, should may can, it is very important that you understand the difference Not only from the standpoint of auditing, but also from the standpoint of when you're going to basically be taking the certification test, you are expected to understand those words. Now in relation to shall uh shall you know is a requirement. It's also important as an auditor to understand that in certain cases if something is not done then there needs to be uh there needs to be some sort of explanation of why it's not applicable. So for example If a company is completely hybrid, they have no physical location, but the ISO 27001 requires physical security. uh it it's not possible. So while there is a shall statement in relation to physical security, that doesn't mean it's uh completely applicable. So isoglossary, these are the definitions, so terms uh applicable means relevant, appropriate, possible to apply appropriate, suitable, meaning suitable, authority, power to command or give a decision. And the authority could be in a variety of different ways. It could be the CEO of the auditee uh or could be some other internal group. Competence, the ability to apply knowledge and skills to achieve the intended results I think that's fairly fair fairly self-explanatory and what competence is you guys are taking this course so you can gain the uh the competence so you can perform activities But that doesn't mean you're not going to continuously learn elsewhere. Conformity, fulfillment of a requirement. So in 27,001 If there is a requirement and they uh they meet the requirements, the guidelines of the requirements, then then that's a conformity. They've conformed with it. And obviously the opposite of that would be a non-conformity. which are repeatedly discussed in 27001. Continual improvement, that's recurring activity to enhance performance. Corrective action, that's some sort of action to remediate or mitigate a possible nonconformity and to prevent recurrence. So if there's an issue with an oddity of some sort, uh and you've identified that issue and they've they've understood it, they've recognized it, and so on. And you've said, hey, we need to have a plan to fix this problem, that would be known as a corrective action plan. So or a CAP, CAP. Documented information, that's pretty self-explanatory, information required to be controlled and maintained by an organization and the medium on which it's contained. So continuing on with glossaries. Determine, appraise or analyze quantitatively or otherwise find out. Identify Find out, mark or label, show, to reference something without ambiguity. Interested parties, persons, or organizations that can affect, be affected by or perceive itself to be a affected by a decision or activity. In relation to interested parties, it's important to understand that interested parties don't always have to be internal. They could be external. They could be regulatory bodies. They could be law enforcement It could be clients, it could be board of directors or shareholders. Interested parties are essentially going to be anybody that might have a reason to care about whatever it is. Maintain can enable to continue. So if you're sufficiently doing something correctly and you continue to do it correctly, then you are maintaining Nonconformity, that's the opposite of a conformity, that's when you're not meeting the requirements of the standard or whatever particular area of the standard. Organization, company, corporation, firm, enterprise, authority, or institution, person or persons or part of combination thereof, whether incorporated or not, public or private. That has its own functions and administration. So again, in 27001, you'll hear this a lot through other sections, understanding the context of the organization. So think of that as uh in most cases it's going to be the um the odd T. Retain means keep top management. Person or group of people who directs and controls an organization at the highest level. So there's different types of audits that you should be aware of. We'll go through those. The first party audit is when the organization audits its own processes. So say for example an organization had an internal audit team. And they audited themselves and most organizations at some point will get to that point or uh or have somebody do it for them. That's a first-party audit. Now you can also have It's still a first-party audit, but you can also have an organization outsourcing internal audit functions to a trusted entity that basically acts as an internal audit team. So if you're auditing yourself, that's a first-party audit. We also have second party audits. So if uh a second party audit Could be where the uh the the actual customer of the organization itself is auditing the organization to determine if they want to do business with the organization. And it's important to understand that the organization is the auditee. So we have the audit the auditee and we have the customer. If the customer wants to do business with the auditee, then they can audit them And to find out if they're safe to do business with. That would be a second party audit. Another type of second party audit is when the organization or the auditee has vendors So possibly say for example uh an audit T is uh on Amazon or or Azure or G Suite or something like that, and they want to evaluate are those entities safe to do business with. So they may audit them. That's also a second party audit. In some cases that's that could be known as vendor due diligence. Now in a lot of cases, not saying Microsoft or Google or Amazon or Oracle are dangerous to do business with, because they're probably not. But other vendors that are less well known, that are probably startups or something like that, that an organization might do business with, this might be more critical for that. You can also have third-party audits. A third-party audit is when a organization is audited by an independent organization that's completely independent. They have no knowledge of any previous audits. Uh they have no knowledge of anything. They're coming in uh basically not knowing anything at all, and uh they're gonna audit and and uh give an assessment. And that's the kind of audit that uh you'll have certifying bodies uh participate in so that they can certify the auditee themselves So in this particular slide, we can see different forms of audits. We have the customer, which could audit the organization. That would be a second-party audit. We have the organization that could audit their own vendors That would also be a second party audit. If the organization audits themselves, that's a a first-party audit. And then again, a third-party audit would be something like a certifying body coming in to uh to double check make sure the organization is following the the guidelines of 27001 and then that could lead to certification for the organization You can also do a combined audit, and a combined audit is exactly what it sounds like. It's taking more than one framework or more than one standard, but auditing it all of it at the same time. There are some benefits to this because uh most in most cases it's going to save time and money. Uh so it's not necessarily a bad bad thing to consider. In relation to combined audits, 27,000 one, 9001, 37,001, and then 20,000-1 A combined audit can be much more than just ISO IEC frameworks. So in the United States, for example, it's very common to do 27001 and SOC2 together. And that's two different two different standards, two different frameworks completely. So again, from the standpoint of combined audits, they're certainly possible. You just need to make sure that there's adequate planning And again, if you're going to have somebody who's going to do a combined audit, make sure you have adequate competence training, certification to even do the audit um and and go from there. Involved parties out of 1911, clauses 312, 313. 314, 315, and then out of 17,021-1 clauses 38, 39, and 316. So these are some examples of A uh involved party, we have the audit client, otherwise known as the auditee. That's the organization or person requesting an audit. We have the auditee, that's the organization as a whole, or parts thereof being audited. And again, remember for 27001 or basically how you set up different frameworks. You don't necessarily have to audit the entire organization. You can audit just sections of it if if that's the goal of the audit client. You have the auditor, the person who conducts an audit, and that's basically you guys who are taking this course. You're going to be the auditor. You have the audit team, one or more persons conducting an audit supported if needed by technical experts. So obviously the audit team would be people composed of auditors. and everybody's capable of doing the auditor job, they're certified, or or so on. You can also have a technical expert, person who provides specific knowledge or expertise to the audit team. It's important to understand that as an auditor, you're not required to know every single thing for every possible concept of every single framework that's out there. So for example, if you're going to audit a software development company, for example, and you're not a developer, you probably are going to have to have some help. Or maybe there's a company, an auditee. uh audit organization that uh wants to that's heavily heavily using databases or something like that but you're not necessarily a database person you may want to bring in a database person to evaluate their configuration So technical experts are certainly possible. They're certainly also possible in the areas of network engineering, network security from the standpoint of network architecture, and so on. So it's not it's not unheard of to do that. There's also observers, a person who accompanies the audit team but does not audit. This could be a person from the audit company themselves, possibly somebody who's uh learning how to be an auditor or possibly somebody within the audit company that is uh evaluating the performance of the auditor or the audit team uh themselves And then there's also a guide. That's a person appointed by the client to assist the audit team. I'm a huge fan of implementing and using guides whenever I help a company get ready or if I'm involved directly with audits. The reason why is because a guide will generally have direct access uh to people or areas of the auditor or audity environment that allows for faster access to get things done. They basically can cut through what we call red tape. You can get things done faster and smoother with less hassle. And realistically, guides make things go uh a lot easier \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S06.2-Fundamental-audit-concepts-and-principles.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S06.2-Fundamental-audit-concepts-and-principles.md index 1fdbbf9..a317bf1 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S06.2-Fundamental-audit-concepts-and-principles.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S06.2-Fundamental-audit-concepts-and-principles.md @@ -12,6 +12,8 @@ status: active ## Abstract +This session covers the seven principles of auditing from ISO 19011 clause 4: integrity, fair presentation, due professional care, confidentiality, independence, evidence-based approach, and risk-based approach. It explains each principle in practical terms, including the importance of professional skepticism, impartiality, and honest reporting. The session addresses special situations such as encountering illegal acts or mandated reporting obligations, and details confidentiality requirements for auditors under ISO 17021-1, including non-disclosure agreements and lawful exceptions for criminal activity disclosure. + ## Transcription So there's audit principles. This is out of ISO 1911, clause four Auditing is characterized by reliance on a number of principles. Adherence to those principles is a prerequisite for providing audit conclusions that are relevant and sufficient and for enabling auditors working independently from one another to reach similar conclusions in similar circumstances. So we have an example of integrity, fair presentation, due professional care Confidentiality, independence, evidence-based approach, and a risk-based approach. And we'll talk about each one of those in the following slides. So integrity out of 1911 clause 4A. Integrity is the foundation of professionalism. Auditors and the individuals managing an audit program should Perform their work ethically with honesty and responsibility, only undertake audit activities if competent to do so Perform their work in an impartial manner, and in other words, remain fair and unbiased in all their dealings. Be sensitive to any influences that may be exerted on their judgment while carrying out an audit So in relation to cybersecurity or auditing of any kind, integrity is the core principle of professional behavior. So let's talk about this a little bit. So perform their work ethically with honesty and responsibility. So meaning that You're not going to lie in relation to or be un less than truthful in relation to the work that you perform. We're we're not going to uh uh create wordy words and reports and documents or emails or anything like that that could possibly be misleading. We also want to make sure that we only undertake audit activities if competent to do so. So if you'll remember in a previous slide we talked about technical experts. You want to use technical experts if you feel like you need to. Just because you're the only auditor, that doesn't mean that you're expected to know every single thing about the audit. You want to perform your work in an impartial manner remaining fair and unbiased in all everything you do. That doesn't mean that you have to be insulting in how you do the work, but you do have to remain impartial. You have to be truthful. Fair presentation. So this is out of 1911 clause 4B. The obligation to report truthfully and accurately So audit findings, audit conclusions, and audit reports should reflect truthfully and accurately the audit activities So how did you perform the audit? Who did you interface with? What date and time did you interface with them? What evidence was provided to you? Things like that. All of this should be documented in the audit report. Significant obstacles encountered during the audit and unresolved diverging opinions between the audit team and the auditee should be reported. Now a lot of times in relation to obstacles, if you have a guide, some obstacles can go away. If you understand the organization that you're auditing uh fairly well, you get along with them, you're polite, you're respectful, and so on, then a lot of times uh obstacles can go away very easily. It depends on how diplomatic you are I don't want to say how politically correct you are, but you do need to understand the environment, the culture, the political situation, possibly with the audit. The communication should be truthful, accurate, objective, timely, clear, and complete. So again, no ambiguity. Make sure that you're always objective during the audit. You're not going to compromise yourself, your professional judgment on the ground of any predetermined prejudice or conflicts of interest or anything like that. If there is an issue in relation to some sort of bias or whatever, then you definitely want to try to avoid that at all all opportunities Due professional care, so 19011 clause 4C, the application of diligence and judgment in auditing Auditors should exercise due care in accordance with the importance of the task they perform and the confidence placed in them by the audit client and other interested parties. An important factor in carrying out their work with due professional care is having the ability to make reasoned judgment in all situations. So one of the examples I'd like to give for this particular slide The application of diligence and judgment in auditing relates to the the the fact that as an auditor, when you're asked to come in to audit a client or an auditee There's a tremendous amount of trust placed into you as the auditor. So we don't want to violate that trust The confidence and trust that the auditee is placing into you is expected to be upheld at all times. So, to conduct an audit, auditors will have to consider the following beforehand: the context of the organization, critical processes of the organization, the expectations of the clients complexity of the client activities to be conducted, and the resources needed in order to do the actual audit Again, there's a tremendous amount of trust placed in auditors, so you don't want to violate that trust. Professional judgment, this again goes into the trust. by the auditees. Professional judgment means applying relevant training, knowledge, and experience to make informed decisions in various situations. During an audit. In exercising professional judgment, auditors maintain independence and objectivity and adopt an attitude of skepticism to reach the audit objectives Again, a lot of the professional judgment that you're going to be making as an auditor is going to rely not only just on the auditor training that you're going on right going through right now, but also possibly prior training. So for example, if you're an auditor and you before you became an auditor, maybe you were a network administrator, maybe you were a network engineer, or maybe you were a security architect. That knowledge can carry over into auditing, but you want to make sure that if you're if you're uh auditing particular areas that you're not necessarily trained on or you don't have the knowledge on, then don't make informed decisions based on things that you don't know. Rely on technical experts or possibly other members of your own audit team Professional skepticism, that's necessary to reduce the risk of overlooking possible issues or intentional issues that are intentionally being hidden from you. Which could obviously lead to incorrect audit conclusions. So auditors should not ever take the word of the auditee as fact. Instead, what you want to do is look for evidence to support their claims. of whatever they're trying to tell you. So an attitude of professional skepticism implies that auditors perform a critical evaluation on the validity of the evidence obtained and are on the lookout for evidence that could contradict or question the reliability and validity of the documented information received The answers to questions asked during an interview or any other information related to the audit itself. So again, just because the auditee says that they they have antivirus, for example, across their entire network, that doesn't mean that you should believe them. You should ask them, okay, prove it. Uh you say you do, but prove it. Irregularities and illegal acts in an audit If auditors encounter exceptional circumstances, so significant irregularities or illegal acts that affect their ability to continue with the audit, they should take into account the legal implications. And they should also consider withdrawing from the audit. However, I will uh expand on this a little bit. So in the United States, and and I assume most other countries have something similar to this. We have the concept of mandated reporting if it's an illegal act. So examples of mandated reporting if it's an illegal act. Could involve national security like terrorism, uh things like that, anything to do with child pornography, uh that's a illegal act that it requires a uh reporting to law enforcement So based on the country that you're in the and the company that you're auditing as an auditor, you need to understand what your legal implications are. If, for example, I ran across a company that had a mandated reporting event and I detected that, I uncovered it somehow or another, and I did not call law enforcement, then I personally to be held accountable for that. So I'm I don't want that risk, uh that burden. So uh just understand if you have something that's a mandated reporting event, then you you have to report it, whether the c audity likes it or not. Now in other cases though, let's say for example theft, you run across a person who has stolen a computer. The victim would be the auditee. That is not a mandated reporting event. That might be something where you report to the auditee, hey, we we caught this guy stealing a laptop. or or something, uh you can do whatever you want with it. We're just letting you know. The victim in this case would be the auditee and it's up to the auditee if they want to report it or do something about it. However, you could also run across irregularities that may put the auditor, you guys, the students. For this course, then you may consider withdrawing from the audit because you're just not comfortable anymore in dealing with it Obviously, if you're in a situation where you're auditing a company and you run across a mandated reporting event, depending on how that interaction goes, You may still consider withdrawing from the audit just just because it's not appropriate for you to be there anymore. So there are different types of situations. So again, notifiable illegal acts Countries around the world have established various laws that obligate this to happen. Child pornography, again, is a major one. It's certainly a mandated reporting event in the United States. highly suggest that you understand the country laws uh for whatever uh country you're going to be auditing in. You may also want to understand your own country laws if you're auditing a client that's not in your country, but you are in your country where you reside and you're auditing remotely Confidentiality. So clause 19011, clause 4D, rationale is security of information. Auditors should exercise discretion in the use and protection of information acquired in the course of their duties. Audit information should not be used inappropriately for personal gain by the auditor or the audit client or in a manner detrimental to the legitimate interests of the auditee. And the con this concept includes proper handling of sensitive or confidential information. In most cases, when you go uh and Perform an audit, you're most likely going to be required to sign a non-disclosure of some sort. In addition, the certifying body that you're working under, so you can do the audit They're probably going to have a non-disclosure as well. It would be extremely irregular if you did not sign non-disclosures and then started doing audits. So again, with with some exceptions, always attempt to protect the auditee or the audit client. With whatever information that you're exposed to because again, as an auditor, there's a tremendous amount of trust that's placed on your shoulders by them working with you The only area that you need to be aware of in relation to confidentiality has to do with criminal activity. So again, there's mandated reporting criminal activity, which a non-disclosure clause is not going to protect you from. Confidentiality requirements. So there's several different requirements from 17021-1, 8. 4. 1. The certification body shall be, and again, shall means it will be. It's not an option. The certification body shall be responsible through legally enforceable agreements for the management of all information obtained or created during the performance of certification activities at all levels of its structure, including committees and external bodies or individuals acting on its behalf. 8. 4. 3 Except as required in the part of 1702 information about a particular Certified client or individual shall not be disclosed to a third party without the written consent of the certified client or individual concerned. So again, if you're going to release anything, make sure that the people you're releasing information about agree. Personnel, including any committee members, contractors, personnel of external bodies or individuals Acting on the behalf of the certification body shall keep, again, shall is a requirement. Keep confidential and information obtained or created during the performance of the certification body's activities except as required by law. That's your clause right there that says if there is a mandated reporting event, then as required by law, it's okay to release that information. The certification body shall have processes and where applicable equipment and facilities that ensure the secure handling of confidential information. So certification body is going to hold on to the information and get and going to protect it. A lot of certification bodies, they have the material and then uh after a certain time period uh they they purge the material so they don't have to protect it anymore. It's just simply not there. Implications for auditors in relation to those requirements. So the certification body will most likely include confidentiality requirements in the contract which the auditor signs. Auditors must be aware of these requirements and their implications. Again, it would be extremely irregular if you audited anybody without some sort of non-disclosure in place. Auditors must obtain written consent from the audit client before disclosing any information to a third party. The certification body may also have to be kept informed. Auditors must handle with confidentiality all information created or obtained during the audit except when disclosure is required by law. We talked about that Auditors must handle all confidential information per the certification body's processes. Auditors must have knowledge of the certification body's solutions for handling confidential information. information. This doesn't mean you have to be a network engineer and understand in great detail how data is encrypted or backed up with the certificate certification body, just that it is being performed. And again, a lot of certification bodies, they will capture the data, they'll produce a certification of some sort once they've evaluated that there's no more need for the audit evidence or whatever information that could be viewed as sensitive. A lot of them are actually uh deleting them uh on a on a time-bound basis. Exceptions to the confidentiality principle. Confidential information can be disclosed only if it is authorized by law by the audit client or by the auditee. So if it's authorized by any of those law clients or auditee, then it can be disclosed. Or required by law. So required by law is uh something you again you have to be aware of. An obligation or right to disclose when not prohibited by law. And I can't really think of too many examples why you would want to uh disclose something when not prohibited by law because you felt obligated uh to do so as an auditor. Uh you may not be asked to do too many more audits if that's if that's the case In a general sense, what I suggest people do, just don't release anything about any of your auditees, your audit clients, unless they say it's okay or the law requires you to do so. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S06.3-Fundamental-audit-concepts-and-principles.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S06.3-Fundamental-audit-concepts-and-principles.md index 4c5779f..7e1f68f 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S06.3-Fundamental-audit-concepts-and-principles.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S06.3-Fundamental-audit-concepts-and-principles.md @@ -12,6 +12,8 @@ status: active ## Abstract +This session covers the audit principles of independence, evidence-based approach, and the practical threats to auditor impartiality. It explains threats to independence such as self-interest, self-review, familiarity, and intimidation, with concrete examples including gifts, trips, and contract promises. The session details requirements from ISO 17021-1 and ISO 27006-1 on avoiding conflicts of interest, including the two-year waiting period between providing consultancy and performing audits for the same client. The evidence-based approach principle is explained, emphasizing that auditor conclusions must be based on objectively obtained and evaluated evidence rather than verbal claims alone. + ## Transcription Independence, this is out of 1911, clause 4E, the basis of impartiality of the audit and objectivity of the audit conclusion. So we have independent auditors that are going to audit the ISMS. We have management that deals with the information security management. Then we have the auditee and then we have the users. There's an independence in relation to all of those. So the independent auditors are not going to report directly to management. Their independent auditors are not one of the users. They're not the auditee either. Threats to independence. This is actually something that can happen and has been discussed repeatedly in a lot of different auditor courses. But out of 17021-1 clauses 4. 2. 4 and 5. 2. 11, the certification body shall take action to respond to any threats to its impartiality arising from the actions of other persons, bodies, or organizations. Threats to impartiality may include, but are not limited to self-interest, self-review familiarity or trust and intimidation. So it's important to understand the certification body shall take action, meaning again, it's not an option. They must take action. If they don't, then there could be an issue with the certification body itself, which could be very detrimental to their business So we want to make sure that we are always accurately being aware of what's going on. We're protecting all the information. So threats to uh independence, uh self-interest is one of them. So threats that arise uh from a person or body uh acting on their own interest. Uh so a concern relating to certification uh could be that way like financial self-interest. So say for example I was auditing a company and I, strangely enough, for some reason or another, had a whole bunch of shares of stock in this company Uh and I knew that if they passed an ISO 27001 certification audit that their business would uh improve and their likely their sales would go up or things like that And that would naturally make my uh my shares of stock uh be more v more valuable. Uh that would be a an example of self-interest. We also have self-review. You can't audit yourself. That's essentially what that means. You can't audit yourself Intimidation is obvious. If somebody says, you know, you are going to give us a good report so we can get certified or bad things will happen. But then there can also be familiarity or trust. So that's not necessarily self-review. That's where you have so much of familiarity with the oddity that It's almost you're almost part of the team that's being audited, which kind of rolls back into self-review. So items of or threats to independence. So we can uh some examples. Items Or GIFs. That's certainly something that I've I've never personally run across any of these before. But I have heard of situations where an auditor uh may have received a gold Rolex or may have received something else. a free laptop. I have heard of a in one case I heard of an auditor. He was going through an audit and the auditee said, here's the laptop we want you to use and when we're done you can keep it. So that's that would be a gift, we can't do that. Trips, there could be cases of of in of threat to independence for a trip where for example let's say a company says hey we're gonna get audited we want you to be our auditor okay great oh and we're gonna do the uh the we're gonna do the audit in Maui uh or in Hawaii uh or in Bora Bora or in Fiji uh and it's gonna take three weeks but we're only actually gonna be interviewed for uh four days That would be can viewed as a as a gift. It would be basically a bribe. Meals, again, very expensive meals or elaborate meals. That could be a threat to independence And another one is contracts. I have heard of cases where uh uh companies, an auditee has told uh uh an auditor If you pass us and if we get certified, then we will give your organization a follow-on contract. So again, that that is a threat to independence. We we don't want to We don't want to put ourselves in that position. We don't want to put the certifying body in that position. And we don't want to put our company into that position Consultancy services and audits. Auditors should not provide management systems, consultancy services for the auditee Meaning they cannot contribute to the design, implementation, or the maintenance of a management system for the Auditee. In case the auditee received consultancy from a body that has a relationship with the certification body A minimum period of two years must pass before the certification body can certify the auditee. So essentially this goes back into self-review and familiarity. You cannot Help the auditee get ready for the audit, uh maybe perform functions for the auditee, maybe perform services for the auditee. And then turn around and act as an auditor to evaluate your own work. That would be inappropriate. Now, that second bullet, in case the audite receives consultancy from a body that has a relationship with the certification body. It's in most cases I've seen companies they will have different wings or different divisions. They'll have the implementation division, then they'll have the auditing division, but it's the same company In my opinion, that is inappropriate. And in a lot of cases, they'll have a separate legal entities, but it's it would be common knowledge that they're the same company. Again, in my opinion, that's that would be inappropriate. Realistically, if you needed uh as an auditor, if you're auditing an auditee uh and the auditee needs help, then it should be a completely independent uh entity from the audit firm That doesn't mean that the auditee and the the consulting party as well as the audit auditing firm, that doesn't mean they may not know each other or they may not uh you know, interact with each other through different clients or or so on. But we definitely want to avoid the case of of a uh consulting company acting as an auditor and then uh grading their own work so to speak All right, consultancy services and audit requirements for the certification body. So this is out of 17,021-1, clauses 5. 2. 1 and 27006-1 clause 5. 2. 2. Conformity assessment activities shall be undertaken impartially. The certification body shall be responsible for the impartiality of its conformity assessment activities and shall not allow commercial, financial, or other pressures to compromise impartiality. So again remember commercial financial or other pressures, so other pressures could be viewed as intimidation. Commercial could be gifts in some form of fashion. Financial could be literally somebody trying to bribe you or the certifying body. And again, understand that conformity assessment activities shall be undertaken This is something that the certification body is going to do. Certification bodies may add value during certification and surveillance audits by identifying opportunities for improvements. Those are commonly called OFIs as they become evident during the audit without recommending the specific solutions. So they there could be a situation the auditor sees that there is a potential for improvement by the auditee. And they say, hey, you really need to do this, it's not a requirement, you really need to do that, but not explain exactly how to do it. That's where the audit T is uh suggested to go talk to a third party to maybe help them uh with that OFI. without it being considered as consultancy or having a potential conflict of interest. Again, avoid conflict of interest. And again, if you're the auditor and you're telling the auditee specifically how to do something or what to do step by step, then that could be viewed as consultancy. So you want to avoid it. The certification body shall not provide internal information security reviews of the client's ISMS subject to certification Furthermore, the certification body shall be independent from the body or bodies which provide internal ISMS audit So the certification body is an independent body. Then you have the the auditor, which is generally going to be a contracted individual or possibly a contracted company And then you're gonna have a separate the auditee in whatever environment they're in. Consultancy services and auditors. So 17,021-1 requirements In order to ensure there's no conflict of interest, personnel who have provided management system consultancy, including those acting in a managerial capacity. shall not be used by the certification body to take part in an audit or other certification activities if they have been involved in the management system consultancy towards the client or the auditee. A recognized mitigation to this threat is that personnel shall not be used for a minimum of two years following the end of the consultancy. So what this means if if I'm helping a company, uh XYZ company, uh get ready for an audit and then uh maybe their their audit company that's gonna come in and do the certification uh on this XYZ company, they say, hey Carl, we really want you to show up and and be an auditor uh for us because we we like your work and everything else Then essentially I can go to work for them as an actual auditor doing certification audits and things like that. But XYZ company I can't even go to for at least two years Now in my experience, uh it's actually a lot longer than two years. Uh I've seen companies that say three to five years just to make sure that any interaction you may have had, including maybe people actually just not working there anymore, uh That there's no uh connection anymore. So the implication of this clause, uh the provision of consultancy services may constitute a conflict of interest. Certification bodies establish safeguards such as a two-year waiting period or possibly longer, or even prohibit their auditors from providing consultancy services to their audit clients. Auditors must be aware of the safeguards and policies established by the certification body. So 5. 2. 12, all certification body personnel, whether internal or external, or committees Who could influence the certification activities shall act impartially and shall not allow commercial, financial, or other pressures to compromise impartiality. Basically, that means doing the right thing. Don't let yourself get bribed or influenced in any way that could be uh could look like a conflict of interest. uh that could affect the certification process or even the certification body or the auditee themselves. You have to maintain your independence through the audit. You have to be aware of possible threats to independence. And I gave some examples like gifts, hotel stays, trips, financial promises, or anything like that. Any undue pressure from the audit client should be reported to and consulted with the certification body. In a lot of cases, you're not going to run across any of these. I've personally never run across any of them myself, but I've heard about it. One that would definitely affect me would be anything that would concern me greatly would be anything involving the concept of a bribe or intimidation. You need to understand as auditors, your name means everything. The very second that your name is tarnished, and that means your integrity is untarnished And it very rapidly will go around the audit world that your integrity is not to be trusted. 5. 2. 13 Certification Body Shall require personnel, internal and external, to reveal any situation known to them that can present them or the certification body with a conflict of interest. In other words, if you're going to go in and audit a company and you are you have more information or you have a past with this company or something something like that, you have to disclose it before you actually do anything. Uh you want to disclose it right away to the certification body. We simply don't want to have any sort of conflict of interest. We have an evidence-based approach as well. 19011 clause 4F. The rationale behind this is the rational method for reaching reliable and reproducible audit conclusions in a systematic audit process. So we have information that's objectively obtained. It's also evaluated objectively, and then we have the evidence. So ideally, uh if we ask a company, uh, you know, we're interviewing somebody We're going to ask them, say, say for example, do you have encryption at rest? If they say yes, okay, well what level of encryption at rest? Encryption at rest is AES 256. Okay, well then how do we know that? So one of the things we can do is compare what they're telling us with the actual evidence. And the actual evidence could be a policy. an encryption policy for example. Or maybe they have encryption at rest in relation to their databases. We could say let show us the database settings that show us what level of encryption to support the words that you're telling us. Again, unless there's absolutely no way of doing it, never trust the just the words that uh an interviewee or auditee uh tell you because they in in some cases in most cases they're wrong uh or in some cases they'll just tell you what they're expecting you to hear \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S06.4-Fundamental-audit-concepts-and-principles.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S06.4-Fundamental-audit-concepts-and-principles.md index 7ee3897..d967a07 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S06.4-Fundamental-audit-concepts-and-principles.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S06.4-Fundamental-audit-concepts-and-principles.md @@ -12,6 +12,8 @@ status: active ## Abstract +This session covers auditor negligence, ethics, and the risk-based auditing approach. Four levels of auditor responsibility are discussed: no negligence, ordinary negligence, gross negligence, and fraud, with corresponding consequences for each. Practical measures to reinforce auditor ethics are outlined, including background checks, codes of conduct, ethics committees, continuous auditor evaluation, and external accreditation audits. The session then explains the risk-based audit approach from ISO 19011 clause 4G, emphasizing that audit planning and testing should prioritize higher-risk areas, use a top-down approach, and avoid creating additional risk for the auditee during the audit process. + ## Transcription Negligence of auditors, there's different uh four levels of responsibility in case of torturous acts Now you may go, what does tortuous acts mean? Tortuous means the actual damage that is done as a part of your involvement in that. What damage is done to the company because you're involved? And that could be a variety of different ways. It could be financial, it could be commercial, it could be reputational. So definitely understand that. So first off is no negligence. And that's realistically where. Where you want to be. That means that you are a perfect auditor. You did everything great. You followed the rules exactly the way they're supposed to be followed, and everything else. And it's it's just ideal There's also ordinary negligence. Now that doesn't mean that you are a bad person or you're a bad auditor, but possibly you just didn't do 100% in one area. uh more like 98 or 95 or 80 percent uh success in that particular uh area that you're you're working in. So you're still able to produce enough evidence to show that The auditee does deserve a certification of some sort. They pass their certifying audit. It's just that there's areas that could be done a little bit better the next time So during a surveillance audit, anything that could possibly be viewed as ordinary negligence, that could get double-checked to make sure it's adequate at that point in time. However, there's also other forms of negligence, and that's not the kind that we ever want to be in. So gross negligence is certainly one of them. So that's basically a total lack of diligence. The auditor did not report the facts that another auditor could have easily observed without being even without being qualified to conduct an audit. So for example, let's say an auditor did not really conduct the audit very well, but submitted a uh a positive audit report to the certifying body. So what could happen, the audit findings could be challenged by the certifying body and a new audit assigned before the auditee can claim some sort of certification or be granted or awarded that certification. Disciplinary actions could happen in cases like this for uh you know for the auditor themselves, including uh administrative actions like termination uh or Just basically being banned from working with that certifying body. Now, in cases of ordinary uh negligence, if there were cases of ordinary negligence, That could be just additional training, or it could be just maybe somebody's observing the auditor the next time they go around. So gross negligence is not something that we ever want to be in. Fraud, though, is the worst kind. That's where the auditor knowingly, consciously and deliberately participates in falsifying uh reports that is being sent to the certifying body in order to deceive this the uh certifying body or maybe even another party of some sort, law enforcement, regulatory bodies Anything like that. That is pretty much a worst-case scenario if if you're accused of fraud and actually found to have been fraudulent as an auditor. uh you might as well just plan on not being an auditor anymore uh because again as an auditor there's a tremendous amount of trust placed on you not only from the auditee with the information they give you but also on the certifying body that has contracted you to perform the audit. So it's super important that you never want to be in the gross negligence or fraud areas. Always strive for the best job you can do. Ways to reinforce ethics with auditors, conduct background checks before contracting the auditor, if if that's uh or or employing the auditor Make sure you understand the background of people. So one of the examples I give in relation to background checks for auditors If you're going to hire an auditor to do a financial records check of some sort, you want to make sure that that auditor wasn't convicted of embezzlement. Uh if same thing with uh information security. If you're gonna hire an auditor to perform information security, uh you may wanna make sure that the auditor not only is qualified to do the standpoint of information security audits. But also they were not charged with or convicted of some sort of cybersecurity crime. So it's also important to understand that background checks also don't necessarily mean uh criminal action that could have happened, but also from the standpoint of what's their knowledge. If they say that they are former network engineer, Then they should be able to prove that. And a background check should possibly, depending on how you're doing it, uh, could possibly prove that yes, they were a network engineer. So they understand the concepts of TCPIP and subnetting and VLANs and routers and switches. Or maybe they don't, but they put it on their resume. So make sure that you do a adequate background check for your uh your contractors, your auditors, whether the contractors or employees, to make sure they're they're living up to the name that they say they are. We can also have the uh sign, the auditors sign a code of ethics on uh company policy, company actions code of conduct, things like that, uh on ethics or surrounding auditing, uh possibly you could make the uh auditors that you're uh bringing on aware of the laws that they have that they will be beholden to, things like that. Conduct training and awareness programs. This is always good. There's computer security awareness training in any company, in any regulatory environment requires it. There's no real reason you could not add additional auditor training. to auditors in relation to uh being an auditor or awareness around things they should that the company or the certifying body wants to make sure that they're aware of Draft workplace policies and procedures based on best practices. That's going to vary based on the entity that you're working with. Establish an ethics committee and implement their decisions. Just because an auditor really does a great job and everything, that doesn't mean that they would pass ethically. There might be cases where reports need to be reviewed, they need to be approved, they need to be uh evaluated, and so on. Number six, evaluate the auditors continuously. Always do that. Always make sure that you're being aware of what your auditors are doing, what their experiences are like, how they interact with the auditees, and so on. Implement legal and professional sanctions if necessary. And again, the certifying body, the auditee, the auditor environment, that's going to vary based on what it is. and perform external audits by accreditation authorities. So we also have a risk-based approach to auditing. So this is 19011 clause 4G. So the rationale behind this is an audit approach that considers risks and opportunities. The risk-based approach should be a Should substantively influence the planning, conducting, and reporting of audits in order to ensure that audits are focused on matters that are significant for the audit client and for achieving the audit program objectives. So we want to, when we're performing the audit or when we're going to perform the audit, we don't want to perform the audit in such a way that it creates risk for the auditee because you pretty much will never get asked to come back if you cause a problem for the auditee as a part of doing the audit. So we want to ensure that the audit process is being conducted efficiently. And as an auditor, we should follow a risk-based approach by focusing on the audit areas that pose the greatest risk. The audit process would be inefficient if auditors use the same level of effort and utilized the same techniques in less risky audit areas So an audit risk-based approach helps enhance the effectiveness of the audit, as well as reduce risk for the auditee So one way to address the audit planning and testing while considering a risk-based approach is the top-down approach. So a top-down approach is basically the ranking of detailed audit procedures from the highest risk to the lowest risk. And then auditors should obviously use professional judgment to perform a top-down risk-based approach This implies, if we're going to do something like that, this implies that we have technical experts who can help out, as well as constant communication with the auditee to make sure that they agree with our risk-based approach. So clause uh 6. 3. 2. 1 out of 1901, the audit team leader should adopt a risk-based approach to Plan the audit based on the information in the audit program and the documented provided by the auditee. Audit planning should consider the risks of the audit activities on the audite's processes and provide the basis for the agreement among the audit client, audit team, and auditee regarding the conduct of the audit Planning should facilitate the efficient scheduling and coordination of the audit activities in order to achieve the objectives. effectively. So again all of the planning that's going to go into place, we're going to communicate uh everything, make sure everybody's in complete agreement uh specifically uh not only in relation to the audit team uh with each team member understanding but specifically the audit client And the audit. We want to make sure that we don't create additional risk by performing the audit themselves. Audit risk refers to the risk that the auditor may express a flawed audit opinion. and recommendation for certification based on inaccurate audit evidence. There is no audit approach that ensures a perfect audit process. Each client is going to be different, each company is going to be different, each environment's going to be different. Different. However, the risk-based approach is considered as an effective approach for most organizations for minimizing the possibility of not meeting audit objectives. The focus of risk-based approach is analysis and risk management. So simply due to the nature of audit process, every audit is a challenge to auditors. Every audit is a puzzle that has to be solved, and every puzzle is going to be different. Every client is different Given that there are no two organizations with the same complexity of operations, meaning that while you may have two two two organizations that do the same thing, they don't Internally they don't do the same thing the same way every single time. They may produce the exact same thing that gets marketed to the public, that gets sold to the public or whatever, but how they do it is completely different for every single company. Risk-based audit planning requires auditors to keep a focus on risk throughout their audit activities. It requires that the focus on risk is maintained throughout the planning process, including the way that plans are broken down and implemented. It needs to be responsive to the risk management cycle as well as the adequacy of the cycle in meeting the changing risks of the industry. It must be based on and aligned with the organization's priorities and that of their key interested parties. Changing and evolving perspectives could come into play. And again, remember that uh interested parties could be anybody. It could be a regulatory body, could be law enforcement, could be uh clients, end users. The risk-based approach should continuously promote the view that risks are an integral part of the organization's operating processes, and they are not only related to compliance. and regulatory issues. So examples of risks that an organization could face that an auditor might be might want to keep in mind. Operational, so utility failure, inaccessible offices. So again, a guide can help out with inaccessible offices or areas. Utility failure, that could be something that the auditor accidentally creates or maybe somebody else creates it. IT and communication, loss of the internet and phone access. That's going to be out of the hands of the auditor in most cases. as well as the auditee, but it's could be something that needs to be reviewed or understood. Regulatory fines as a result of non-compliance violations of contracts. That could be a risk Financial budget reduction, fund canceling or decreasing personnel, staff loss, or possibly not enough staff in the first place. Or unqualified staff. And then reputation, negative media coverage, loss of trust from key interested parties. And again, key interested party could be uh shareholders, clients, law enforcement, regulatory bodies, and so on. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S06.5-Fundamental-audit-concepts-and-principles.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S06.5-Fundamental-audit-concepts-and-principles.md index 6aab5ba..80ea983 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S06.5-Fundamental-audit-concepts-and-principles.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S06.5-Fundamental-audit-concepts-and-principles.md @@ -12,6 +12,8 @@ status: active ## Abstract +This session covers auditor competence requirements based on ISO 19011 clause 7.2.3.2 and ISO 17021-1 Annex D. Competence is defined across three dimensions: knowledge, skill, and attitude. Key personal behaviors for auditors are described, including being ethical, open-minded, diplomatic, observant, tenacious, and organized. Generic knowledge and skills required include understanding audit principles, applicable management system standards, organizational context, and statutory and regulatory requirements. The session also covers specific regulatory knowledge areas such as data protection, cryptographic controls, intellectual property, electronic commerce, workplace surveillance, and penetration testing legality across jurisdictions. + ## Transcription Competence of auditors You do have to know what you're doing. So number one, personal behavior, generic knowledge and skills, discipline, specific knowledge, communication skills, and knowledge of certification bodies processes So in relation to competence, the three dimensions of competence are knowledge, skill, and attitude So knowledge is the acquaintance of facts, truths, principles during a study or an investigation, and it's the mastery of those concepts and theoretical knowledge So when you know something, that is knowledge. Now how you know it is is relative. So did you have a previous job where you learned it? Are you formally trained? Or are you Googling it and figuring out what knowledge means? Whatever the knowledge is for the uh oddity It's important to understand that if you're going to audit something, you should be competent enough to actually do that. And if you can't audit a particular area because you simply don't have the knowledge, get a technical expert to help you Skill refers to the practical competence and expertise of an individual. Attitude refers to the ability to display professional or behavior according to the characteristics of the environment situation or people. So read the room is a common common term. Make sure that you're professional in nature and so on and you understand the culture of the company. So personal behavior. So this is out of 17021-1 Annex D. Examples of personal behavior that are important for personnel involved in the certification activities for any type of management system are described as So ethical, open-minded, diplomatic, collaborative, observant, perceptive, versible Tenacious, dis decisive, self-reliant, professional, morally courageous, and organized. So let's go over a few of these So first off, ethical. Your word is your bond. If your word is bad, uh then then that means you're pretty much unethical. So always be fair, truthful, sincere, and honest. This ties greatly into integrity And again, in auditing, there's a tremendous amount of trust placed in you in information that's provided by the auditee. It would be unethical if you just simply disclosed all of that information uh unless you're r required to by law, it would be unethical to to do that. It would be unethical to uh not be truthful when you're writing uh you know certification suggestions or things like or uh reports to certification bodies. We always want to be ethical in relation to all activities we we do. We want to be beyond reproach. Open-minded. Willing to consider alternative ideas or points of view, basically meaning that maybe maybe you're making a mistake, maybe you're not right in uh how you're doing things So being open-minded. That could be being open-minded with your audit team, but it could also mean being open-minded with the audit client or the audit team. Diplomatic, being tactful and understanding, respectful of other people that you're interacting with and so on. Collaborative, working with other people as a part to uh you know coming up with a solution So you don't act like you're the Lone Ranger and nobody's there to help you. You're part of an audit team. They're there to help you and you're there to help them. observant, actively aware of physical surroundings and activities. As an auditor, I start the audit process the very second I get out of the car and I'm on the on the auditee's property. Uh if as I'm walking into uh the audit environment, I'm observing The doors, how are the doors secured? Are there cameras? Do I have to check in with somebody as a part of the you know a guest check-in process? I just observe all of those things before I even ask anybody questions And I take notes out of all of that. Perceptive, being aware of and able to understand situations. And those perceptiveness could be a variety of different types of situations could be uh also tied directly into diplomatic Versatile, adjust readily to different situations or be avail uh be able to uh uh flex. Tenacious, don't don't quit. Persistence is uh uh another way of saying tenacious, but uh just don't quit. Decisive, reaching timely conclusions based on logical reasoning and analysis. Self-reliant, basically you can act independently. You don't need other people. Professional, again uh being uh understanding of the culture, the environment, the people you're talking to, uh your professionalism is uh uh highly valued. Now also understand that a lot of these, for example, morally courageous, uh morally courageous and ethical are kind of hand in hand with each other. Diplomatic and professional are also diplomatic or also connected with each other So, and then organized, uh be organized in your activities, uh especially as an auditor in relation to organization. If uh if you're going to interview people and it it it appears that you're not organized, then what could happen is that the auditee uh might have a concern that you're not doing a very good job. Additionally, when you're interviewing people based on the stature or the position of those people, they simply just don't have the time for you to learn how to get organized while you're interviewing them So be very organized as much as you can. Generic knowledge and skills of auditors. So 19011 clause 7. 2. 3. 2. Auditors should have knowledge and skills in the areas outlined below. So audit principles, processes, and methods. That's the first one. So we should understand as auditors How to perform an audit. We should understand concepts of auditing, which we've talked about in other slides, like understanding risk. opportunities, understanding that we're supposed to be truthful and ethical and morally courageous as an audit principle. We should also understand the processes of audits That while an auditee or an audit client may say they have encryption, how are we really going to prove that? We should also understand other concepts around auditing in relation to processes and methods. uh like say possibly sampling or or so on and that that's other sections of uh this course We also have management system standards and other references. So this is a uh ISMS 27001 course. So Understanding 27001. That would be the management system that you need to understand. But this is this particular slide is talking about 1901, clause 7. 2. 3. 2 Which does not specifically say 27,001. So if you're going to audit, say for example, also 9001, make sure you understand it. Make sure you understand all the connecting references In relation to the management system that comes out. So here's an example. You have the ISMS 27001. But let's say you're a European company that you're also heavily involved in the GDPR space. You want to understand GDPR because there is a connection with 27001 in GDPR. So understand these references. The organization and its context. So essentially, in a nutshell, what does the organization do? What is the audity? What is their function? Do they make a product? Do they sell a product? Are they only financial? Are they this? Are they that? So understand the organization in its context. And an easy way of saying that is this is the organization, XYZ Company, and this is what the organization does. So understand as a part of that. You might also want to figure out what what regulatory environments are the organizations or the entity are they beholden to Do they have to uh you know comply with HIPAA or FERPA or GDPR, for example? Understand how big they are. Understand uh the the org chart of the company Understand the companies that they interact with. Try to understand the countries that they're in, and so on. So understand the organization in its context means understand the auditee. You don't have to be perfect at it. You don't have to know in great detail every single thing, but you do have to have the basics. Applicable statutory, regulatory requirements, and other requirements. I kind of touched on that under management system standards and other references. But yes, if if the company or the auditee is in a situation where they have to comply with other regulatory or statutory requirements, try to understand those too. Also understand though That every company is going to be different and not every company is going to have to comply with the same requirements that other companies do. Now it's it's also important to understand When it comes to statutory regulatory requirements or maybe contractual requirements, you don't have to be and you're not expected to be an attorney or a lawyer in order to uh do that portion of general of knowledge and skills. It it is expected that, you know, for example, if you're gonna work uh with a European company that once you get 27,000 women and they're also in a GDPR environment, it's expected that you understand what GDPR is, the basic concepts behind it But you don't have to understand every single article in GDPR in order to perform your skill as an auditor It would not be unreasonable though as a auditee if I was talking to an auditor and I knew I was in a GDPR environment. It would not be unreasonable of me to ask the auditor to have the ability to look up specific articles to make sure that we were good to go as a company. Knowledge of regulatory requirements again continuing. Auditors should have knowledge and understanding of regulatory requirements on the following Intellectual property, so non-disclosures are certainly going to come into there. Content protection and retention of organizational records That's going to vary based on the country and or state you're in. Data protection and privacy. So again, I've referenced GDPR, but there's other uh regulatory environments like uh hippa, FERPA, CAPA, CCPA. Uh the other countries like Brazil has a really uh intense privacy regulatory environment. Regulation of cryptographic controls. So regulation of cryptographic controls is something that uh you definitely want to be aware of. Some cryptography solutions are actually uh They actually fall under government entities uh environments in relation to arms trafficking. So for example, There's this guy named Phil Zimmerman. He's the guy who created PGP, Pretty Good Privacy. That was released outside of the United States. The United States FBI investigated him. Ultimately he was it was fine, he was let go, but um they the US government uh viewed PGP at one time as a uh regulated cryptographic control and it fell under uh ITAR. International trafficking and arms regulation So be aware, especially if you're crossing going from one country to another, be aware of the cryptographic controls. uh in the regulatory environment around that. Some countries literally do not allow high complex encryption because uh well It makes their spy agencies work harder to break in if they have to. But in other countries, they just don't care. Electronic commerce, so like uh uh PayPal and everything else. Um How money is uh transmitted from point A to point B electronically. Uh electronic and digital signatures, those are becoming more and more popular. Workplace surveillance The key thing to remember about workplace surveillance, regardless of the environment that you're in, the one place you absolutely can never have surveillance in would be restrooms, latrines, lavatories. things like that. You cannot record people using the bathroom. But in some other countries, uh the very second you walk through the door, you you could be expected to be surveilled The United States, for example, cameras everywhere. The U United Kingdom, cameras everywhere. And it's expected. You'll see signs that say you have no expectation of privacy. uh things like that in relation to surveillance. The other areas of workplace surveillance that could come into play could be electronic surveillance of basically What people are doing on their computers, what emails they're sending and receiving. That could be a form of surveillance. So understanding the regulatory requirements around workplace surveillance Also goes into what country you're in. Some forms of workplace surveillance in the United States would actually be illegal in the United Kingdom or European Union. Telecommunications interception and monitoring of data like email. In most places, if it's a company email system, You have all sorts of rights to monitor whatever you want and intercept and do whatever you have to in order to protect the company, not for surveillance reasons because you're trying to intrude upon people's privacies. Computer abuse. So what are the hacking laws in the country that you're in? In the United States, we have the Computer Fraud and Abruce Abuse Act. We have the Interstate Commerce and Communications Act. Uh there's all sorts of different things. Different countries have different laws around this. Electronic evidence collections or forensics You know, again, if you're gonna investigate somebody and you don't know how to do that, then uh get a forensics person to do that job for you. And also understand the concept of chain of custody Penetration testing. This is a big one. I'm a hands-on penetration tester in addition to being an auditor. But penetration testing is something that you want to make sure that you are doing legally Uh in some companies or some countries penetration testing is not as strict as other countries In the United States, if you perform penetration testing without a contract that allows you to do it, then it's a felony. You could be arrested for it. And so you don't want to get caught doing unauthorized penetration testing. In some other countries, simply having the ability penetration testing tools on your laptop is could be viewed as a crime. So make sure you understand that. International and national sector specific requirements, for example, banking. uh the SWIFT concept is comes to mind, uh but how uh national and international sector specific uh environments interact with each other. So there banking is an example, but it could be something else. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S06.6-Fundamental-audit-concepts-and-principles.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S06.6-Fundamental-audit-concepts-and-principles.md index 5bb2df0..f48dd72 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S06.6-Fundamental-audit-concepts-and-principles.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S06.6-Fundamental-audit-concepts-and-principles.md @@ -12,6 +12,8 @@ status: active ## Abstract +This session covers discipline-specific and sector-specific auditor competence requirements from ISO 27006-1, including knowledge of ISMS documentation structures, risk management, ISO 27001 Annex A controls, and applicable legal and regulatory frameworks. Communication skills for auditors are discussed, emphasizing tailoring presentations to the audience and using open-ended interviewing techniques. The session also addresses knowledge of certification body processes, audit team leader responsibilities including scope management and report preparation, and methods for maintaining auditor competence such as continuing education, on-site evaluations, and peer review of audit reports. + ## Transcription All right, discipline and sector specific competence of auditors. So this is out of 27006-1 clauses 7. 1. 3. 1. 2. And 3. 1. 3. 1. 3. Each auditor in an ISMS audit team shall have, that means must. Shall have knowledge of ISMS-specific documentation structures, hierarchy, and interrelationships, information security risk assessment and risk management, processes applicable to the ISMS. Each auditor in an ISMS audit team shall have knowledge of all requirements contained in 27001. An easy way of thinking about that is. You have to be certified in 27,001 as an individual in order to be an auditor. That's the whole purpose of this course that you're in right now. The audit team members shall collectively have knowledge of information security management related tools, methods, techniques, and their application. The current technology where information security can be relevant or an issue. So the audit team members shall collectively, that's a key word, have knowledge of all controls contained in 27001 Annex A and their implementation. That doesn't mean that each audit team member has to know every single thing, but collectively you do. And again, if there's particular areas when you're performing an audit that you're simply not aware of uh then get a technical expert to help out. Specific knowledge about clients this is out of 27006-1 clauses 7. 1. 3. 1. 5 and 7. 1. 3. 1. 6 Each auditor and ISMS audit team shall have knowledge of the legal and regulatory requirements in the particular information security field, geography and jurisdictions. So again, I've said repeatedly how You need to be aware of the organization and its context. So where it is, what it does, what regulatory environments it's involved in. So a big one that's easy to use. would be uh GDPR in European countries or companies. Um it's it's just something you have to know. If you're in California And you meet certain requirements, you're going to be held bound to CCPA. If you have anything to do with the medical field in the United States, it's going to be HIPAA-based. If you have anything to do with credit card transactions globally, you're going to fall under PCI DSS. So you have to be aware of all that. Information security risk related to business sector. That's again going to change based on the type of auditee that you're working with. generic terminology processes and technologies related to the client business sector that they're in. The one thing I will say about generic terminology, if if you have a client that you're auditing Make sure your terminology aligns with their terminology. There could be cases where somebody views auditing terms. differently inside the company. So make sure that uh you have some sort of Rosetta Stone translation capability in there to understand uh what auditors mean is is the same or if there is a difference than what the uh business sector uh agrees with. Also the relevant business sector practices, so the criterion may be shared among the audit team The audit team also needs to have collectively have knowledge of impact of organization like type, size, governance, structure, functions, relationships. implementation of the ISMS and certification activities, including outsourcing, complex operations in a broad perspective, as well as the legal and regulatory requirements applicable to the product or the service. All right, communication skills, presentation, and interviewing. This is 17021, Annex A, 2. 9, and Annex A 2. 10. Perhaps two of the most important aspects related to communication are presentation and interviewing skills. The auditors should be capable of presenting audit findings and conclusions to be easily understood for the team leader. Easily understood. So the team leader presenting in a public forum, like a closed meeting, audit findings, conclusions, and recommendations appropriate to the audience So an easy way of understanding this is that if you're going to do something highly technical as an auditor and you're going to report on it, don't get highly technical for the non-highly technical people. uh that you're reporting on. If if for example y you have to s uh basically give a presentation about lack of encryption Uh you don't really need to tell the CEO of a company about how AES 256 works or the lack of uh configuration uh based on your findings or something like that. All you have to really do is say you're not adequately protecting data at rest. and have the other people within the company uh maybe give them a more technical explanation of something, but You don't really need to overwhelm people because ultimately what will happen if if you don't if you're not aware of your audience when you're doing a presentation They will get confused, they'll get lost, there will be numerous questions about what do you mean, how does this work, stuff like that. It could raise uh raise their stress level uh get them you know they could freak out or something you just don't want to do that just be aware of the people that you're presenting to interviewing skills so capable auditors should be capable of interviewing to obtain relevant information by asking open-ended, well-formulated questions and listening to understand and evaluate the answers. So there's a actually a lot in relation to interviewing, but definitely be open-ended, well formulated. And you want to listen, evaluate the answers, but at the same time you want to understand that the answers that a person that you've interviewed may not be the same answer as another person you've interviewed. So not only understanding and evaluate the answers, but also comparing the answers to make sure that they align with each other. Knowledge of certification bodies processes. So this is out of 17021-1. Annex A 2. 4. The auditor must have knowledge of certification body's processes sufficient to perform in accordance with the certification body's procedures and processes. This implies that the auditor must thoroughly understand the certification body's policies and procedures relevant to them. applicable to the audit process. Other relevant policies such as quality and information security of the certification body, not the auditee. So, if you're an auditor working for a certification body, performing a certification audit, you need to understand the policy relating to information security and quality for the certification body itself. So you understand so you don't violate those policies. Any established guidelines from the certification body. And then tools such as forms, templates that the certification body provides to its auditors. In in most cases, if you're an auditor and you're working for a certification body or you're contracted to a certification body, For a particular audit, they're gonna provide all the templates for you and they'll they'll give you all this uh in advance. But While certification bodies may do that, that doesn't mean that every certification body is going to have the exact same template for every single audit. So make sure you understand that it will be provided to you, but at the same time also understand there's no consistency. From one certification body to another. Responsibilities and competencies of the audit team leader. So as stated in 17021-1, the audit team leader is responsible for assigning or reassigning work to each and audit team member to audit specific processes, functions, sites, areas, or activities Generally, when work is assigned to an audit team member, that is going to be based on the skill sets of that audit team member And generally that also means the audit team leader is aware of those skill sets in advance of assigning uh work. Now reassigning work could be for a variety of reasons. Maybe the audit team leader felt like It wasn't done very uh good very well, or maybe uh the audit team leader didn't assign work uh equally across the board and somebody's now has has too much work and it has to be reass uh allocated to somebody else. The audit team leader is responsible for reporting to the audit client and certification body when evidence indicates that audit objectives are unattainable. Reviewing with the audit client any need for changes to the audit scope. In all of my experiences with uh audit clients, every single time the audit scope is going to get discussed Either the audit client uh underscopes or they over scope. And uh the auditor and the team leader uh uh you know has to Help the audit client saying, yeah, you know, this is really not in scope or that should be in scope. The audit team leader should attempt to resolve any diverging opinions between the audit team and the client concerning audit evidence or findings. It's going to be uh politically, diplomatically, uh professionalism, things like that. Uh but that doesn't mean that The audit client is going to be accurate in their assumptions. Sometimes audit clients produce evidence that totally contradicts what they believe is true. Overseeing the preparation of audit conclusions. conducting the opening and closing meetings and preparing the final uh the preparing the audit report. Uh in relation to preparing the audit report, uh that's the responsibility of the team leader, but that doesn't mean that the audit Team itself is not going to be involved in preparing the audit report. I I've worked in uh audits for very large entities. Can't name them, but uh very large entities where the team leader uh basically said, okay, Carl, you're gonna do this section, Bob you're gonna do that section, Joe, you're gonna do this section, you know, Janet, you're gonna do this section And then I will do this part, and then we'll all come together and and put all these sections into a singular document, and then we're going to do a constant peer review process to make sure we all agree. That is a very realistic scenario. Maintaining competence out of 17021-1, clause 7. 2. 10, 7. 2. 11. Auditors should maintain their competence and aim to complete their audit assignments. To the best of their abilities, they should adhere to all competency, requirements, standards, policies, and procedures of the certification body This is important because as per 17021-1, the certification body monitors and evaluates each auditor considering the type of management system. To which the auditor is deemed competent. So there's a variety of ways that we can maintain competence. We've listed some. We can have an on-site evaluation by the By the certifying body. We could review audit reports after the fact to understand the competence in relation to auditing. Do they write well? Do they read well? We could also have feedback from clients in general or the market. Now there's other areas where you can maintain competence, and that's something after you finish this complete course and you take your test And you get certified, you've met all the minimum requirements, and you're certified, and that's called taking uh continuing education. So that's another way of maintaining competence. Another area of maintaining incompetence or maintaining competence is taking other courses related to 27,001. For example, you could take 27,002, you could take 27,005. All of that can tie into maintaining competence and improving yourself. So a form of professional development. All right, and that is the summary of section six. So ISO 19011 provides guidance on managing an audit program and planning a management system, whereas 17021-1 Consists of requirements for bodies providing the audit and certification to the management system. An audit is the assessment of the fulfillment of certain criteria by means of evidence and professional evaluation Internal audits are also known as a first party audit. External audits are known as second and third party audits. Understand the difference. A second party audit could be A client auditing the auditee in order to determine if they want to hire the auditee for a function. Or it could be the auditee auditing vendors or their suppliers. And that's commonly called vendor due diligence. A combined audit is an audit carried out together at a single audity on two or more management systems. So it could be 27,001 or 9,001 at the same time. If you're going to do a combined audit, make sure that you have appropriately certified and trained people to do that Some audits, well for example, ISO uh ISO audits require that, but in other cases, for example, you could do an ISO 27001 and a SOC 2 with less certified people. Also understand that you may actually have in relation to a combined audit, you may actually have multiple audit teams in order to save time and money in relation to the auditee. The principles of auditing are integrity, fair presentation, due professional care, confidentiality, independence, evidence-based approach, and risk-based approach So keep in mind what I said about integrity. Once your integrity has been tarnished, it's going to be difficult for you to be an auditor So make sure that your integrity, your honor, your ethics, your moral courageousness, that is never violated It's your name means everything in the world of cybersecurity and auditing. Also understand the concepts of confidentiality. Unless you are given permission, do not release information about anything In relation to the client. The only exception to that is what's called what I call mandated reporting events. Audit team leaders must be professionally competent to plan and audit using resources efficiently Manage and counsel the audit team members, prevent and solve conflicts, and prepare, explain, and defend the audit conclusions. So if you're a team leader Leading an audit team, you have to be able to lead your team. Sometimes you'll have team members on your audit team, they will just disagree with each other. So maybe you have to change some work assignments As a team leader, you may also understand the culture or the personality of the people that are being interviewed. And you might want to reassign uh interview people Who are going to interview the auditee based on the type of culture and environment that you're in? There's also some questions. We'd ask those if this was a uh uh in-person class there's an exercise exercise two in quiz five you should do those on your own time obviously we can't do them because this is uh recording And with that, I want to thank everybody for your time. I will see you on the next one. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S07.1-The-impact-of-trends-and-technology-in-auditing.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S07.1-The-impact-of-trends-and-technology-in-auditing.md index 25f79b6..ff05c98 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S07.1-The-impact-of-trends-and-technology-in-auditing.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S07.1-The-impact-of-trends-and-technology-in-auditing.md @@ -12,6 +12,8 @@ status: active ## Abstract +This session examines how technology trends are transforming audit practices. Big data concepts are explained, including structured versus unstructured data, and how tools such as Microsoft Power BI support data analysis, visualization, and anomaly detection during audits. Artificial intelligence and its audit applications are covered, including inductive language programming, robotic process automation, expert systems, and neural networks. Practical AI use cases in auditing include automated risk assessment of individual transactions, augmented audit interviews using speech pattern analysis, automated confirmation letters, and data validation. + ## Transcription Hi everyone, thank you for joining me. This is section seven for ISO 270001 Lead Auditor. This is the impact of trends in technology and auditing, and we're going to talk about big data The use of big data and audits, artificial intelligence, machine learning, and cloud computing, the use of artificial intelligence and audits. The impact of cloud computing and audits and auditing outsourced operations So the impact of technology and auditing, uh, technology makes auditing a whole lot simpler than it than it uh could be. The advances in technology are changing on a daily basis. In relation to operations of organizations around the globe. Companies that are wanting to make more money, be more efficient, they're all obviously always trying to figure out how they can add more technology to do so. Technology has also been an impact on the way audits are being conducted and data is being analyzed. The use of new technologies like audit tools and software contributes to the increase of the audit quality by providing tools that can help deal with large amounts of data. Tools that can increase the audit efficiency, tools that allocate more time to the audit analysis instead of more time to conduct some sort of technical tests because the tools take care of that. Tools help minimize costs and they can also help provide transparency. However, the use of new technology tools Can also present certain challenges. Data security and quality control are two important factors that have to be considered by organizations to ensure that their data used is reliable, complete, and accurate. Not only that, but also has to be safe, has to be protected. So we have the concept of big data. So the dictionary defines big data as an accumulation of data that's too large and complex for processing by traditional database management tools. If you're interested in artificial intelligence, this is going to be covered in the 42001 course, which is also hosted by PECB. And I'll talk about that later. Big data includes a large number of structured and unstructured data. So structured data is organized, easily reachable. Unstructured data cannot be organized in relational databases and are not easily reachable. So structured data can have a defined data model and are based on relational databases. So example of structured data could be like SQL databases, Microsoft Excel files. And so on. Unstructured data would be an example would be MongoDB, Mongo database. So remember the two differences, especially from the vendor standpoint. Structured data would be like SQL SQL, SQL Server, or Microsoft Excel, but I don't really view Excel as a database, but SQL databases. And then MongoDB would be unstructured data. The use of big data in audits, so technology tools for big data processing can be beneficial in that auditors Can easily identify data that is available and use it easily. Retrieve data that may be considered sensitive, design their program to manage big data better. Collect more qualitative audit evidence, gather data from different systems, and combine structured and unstructured data Big data technology is often used for data analytics as it provides a scalable infrastructure for storing, processing, and analyzing large and complex data sets. Data analytics involves analyzing and examining data to obtain valuable outputs that support organizations in making strategic decisions. Big data analytics enable the integration of different data types quickly and efficiently. So there's a variety of different things we can do in relation to big data, but If we want to optimize the value of data so we can implement various technologies, and some of those could be uh data management, so referring to the activities that are conducted to ensure the accessibility, reliability, and timeliness of information, including the gathering of that information, the structuring structuring of the information, verifying, securing, and so on of the information. Auditors can rely on data management technologies to gather and organize data from various sources to support the audit process. We can also have data mining and that refers to the process of analyzing data to identify patterns and relationships between events. In auditing, data mining technologies are used to identify anomalies and unusual patterns in financial transactions or other data. So in relation to data mining, there may or may not be that much involvement with uh 27001, depending on the type of client you're interacting with. Auditors, however, can use data mining to identify potential areas of risk, such as fraudulent activities or financial reporting. We can also have predictive analytics. Basically, we take the data, we look at it, we start to see trends, and we start to anticipate what could happen. So, the use of big data and audits. So, Microsoft Power BI is an example of a tool. So, Microsoft Power BI is a powerful tool that can be used by auditors to analyze data and identify patterns, trends. and anomalies. Auditors can use Power BI for the following aspects during an audit. So data analysis, visualization, data cleansing, collaboration, and monitoring. And we'll talk about those. But again, from the standpoint of big data and audits, and as well as structured and unstructured. So again, structured data would be like Microsoft SQL Server, unstructured data would be MongoDB. But from the standpoint of Microsoft, think Power BI. Now, artificial intelligence. So the dictionary defines artificial intelligence as the theory and development of computer systems Able to perform tasks usually requiring human intelligence, such as visual perception, speech recognition, decision making, and translation between languages So the interconnectivity fast data transfers that are now possible used to not be so possible through the usage of 5G and there's other technologies besides just 5G. Is expected to allow AI applications to become integral parts of our lives. AI is increasingly ubiquitous across industries. Some common applications of AI are banking, marketing, healthcare. autonomous vehicles and so on. So as it relates to AI, it's becoming more and more prevalent across uh various technologies. I just got a new iPhone 16. It's new to me, maybe not so new to everybody else. But one of the options when I set it up was include artificial intelligence uh uh upgrading some of the uh older iPhones to a current uh iPhone tech iPhone operating system that now allows for AI. There's numerous areas of AI that's now being included across the board. But it is important to understand that artificial intelligence solutions don't necessarily make the right decision the first time. They have to be trained. They have to understand. They have to learn. And so on. So there could be, for example, I saw a video Where a guy had a bunch of balloons on the wall and he said, track all the yellow balloons. And the camera moved all around, but it didn't really know what to do other than track the yellow balloons. And it but it knew what the color yellow was. So it was able to visually perceive the color yellow. It was visually or it was capable of understanding its directive, of tracking the yellow balloon But it didn't know what to do after that. There that had to be another command uh with a decision made by uh a human being I also don't want people to get the impression I I think most people across the planet have seen the Matrix movies or the Terminator movies or so on and so forth. Uh don't want people to think that it that uh artificial intelligence is to that level. It's it's it's not. So the use of artificial intelligence and audits, artificial intelligence is mostly applicable in the domain of information collection or collecting, which refers to data extraction, comparison, and validation processes. By leveraging AI-enabled technology, auditors can extract information from documents and use it more efficiently AI-based systems such as expert systems and neural networks can help auditors in their decision-making processes by addressing potential biases and omissions that could arise. In a manual decision process. The aim is to improve the overall quality of auditor judgment. So there's various technologies that can be used in conjunction with AI technologies To help collect and analyze data that could be used to facilitate the audit process. So, for example, we have the inductive language programming. It could be used in auditing to show patterns and anomalies in large data sets. as well as prepare a hypothesis based on data itself. We can have robotic process automation, which can be used to help automate repetitive tasks Mimicking iterative auditing tasks by identifying inconsistencies and outliers. Expert systems can be used to imitate the auditor's way of thinking to solve problems. Be very cautious about saying the word expert systems because again, artificial intelligence has to learn. You're not gonna flip a switch and they're gonna be as smart as a human being the very second it's turned on. Decision networks can help auditors make more informed decisions based on incomplete or uncertain data because we can predict what the data could be. And then artificial neural networks analyzing large data sets and identify patterns and relationships between different variables without any sort of other prior instruction. But again, that implies learning. AI applications for auditing, risk assessment of individual transactions, augmented audit interviews, and then augmented analysis. So we can perform risk assessments in relation to individual transactions by automatically assessing the accuracy and legitimacy of the individual transactions Without AI or without technology, this could be a labor-intensive process that's could be prone to human error, particularly for small businesses or small entities in general By using AI, the process can be improved, resulting in cost savings, not only to the company, but also increased profit because that reduces human effort, which means they can do other things. To generate revenue, as well as increase the quality of the auditing process itself. The AI-based risk assessment involves automatically detecting and flagging abnormal transactions. between accounts that are unrelated, infrequently used, or do not match the transaction detail. So this helps connect things that did not appear to be obvious independently Could help identify transactions that appear suspicious or fraudulent by looking at outliers as well as evaluating authorizations for transactions. In relation to the cybersecurity space for SIMS, security information event monitoring, a lot of the SIM solutions are actually implementing artificial intelligence to help identify suspicious or fraudulent activities. As a part of the outliers. We can also use AI to augment audit interviews, capture and analyze clients' verbal interactions, so basically their voice speech patterns and uh understand what they're saying, why they're saying, or maybe possibly pick up uh some other things, which could lead into an augmented analysis So if we're if we're able to augment the audit interviews and able to determine speech patterns and uh and so on in relation to the truthfulness or body language if there's visual recognition, then we might possibly be able to use artificial intelligence as a uh ability to analyze that and and augment it a little bit more We can also do an automated confirmation letter, automated data validation, and augmented physical observations. So automated confirmation letter to validate transactions and account statuses Auditors often need to automate or to communicate with external parties during the audit, such as creditors, debtors, customers, regulatory bodies. and so on, or law enforcement, or maybe shareholders. These validations commonly involve repetitive tasks such as selecting the accounts that should be verified, composing and sending the confirmation requests receiving and reading the response, updating the confirmation status, and so on. So all of that could be automated to save a lot of time for the audit team uh itself. By automating uh such processes, auditors can save time and resources. Nonetheless, there are some challenges associated with the use of this technology, such as the financial cost to even make it happen. If it's obviously if it's a smaller entity and the audit the confirmation letter is only gonna be to ten different entities, probably don't want to do that, but if you're looking at a hundred thousand, a million confirmation letters or whatever, you're probably much better off to figure out some way of automating all of it. Automated data validation prior to publishing the annual report of a of an entity, we could validate the accuracy and completeness of the numerical data in that report for that. uh entity that uh ought a T. And then also we can augment physical observations based on uh what uh artificial intelligence, how it's set up and how you're if if they even have a need for a physical observation of the oddity. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S07.2-The-impact-of-trends-and-technology-in-auditing.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S07.2-The-impact-of-trends-and-technology-in-auditing.md index f240444..b2e59fa 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S07.2-The-impact-of-trends-and-technology-in-auditing.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S07.2-The-impact-of-trends-and-technology-in-auditing.md @@ -12,6 +12,8 @@ status: active ## Abstract +This session distinguishes between artificial intelligence and machine learning, explaining supervised and unsupervised machine learning algorithms and their relevance to audit analysis. Cloud computing service models are explained: infrastructure as a service (IaaS), platform as a service (PaaS), and software as a service (SaaS), along with the shared responsibility implications for auditors. Practical auditor approaches to cloud adoption include risk assessment, inventory of cloud activities, and role clarification. The session closes with guidance on auditing outsourced operations, emphasizing vendor due diligence, contractual verification, governance oversight, and contingency planning for outsourcing termination. + ## Transcription We're gonna get a little bit more into this, uh, but again, from the standpoint of artificial intelligence, machine learning. and so on. If you're really interested in this or you want to learn a whole lot more, highly suggest you take the PECB course for 42,001, which will provide a lot more information rather than just a few slides. So machine learning and artificial intelligence are sometimes mistakenly used interchangeably, although they do not represent the same thing. So AI encompasses a broader concept of machines that have the capacity to mimic a human being, whereas the main purpose of machine learning is to enable computers to learn automatically. Okay, so just to be clear, even though AI has a capability to mimic a human being, the AI has to understand what it means to be a human being in order to mimic it. So there it's not a light switch where you turn it on and it automatically works. In machine learning, the processor is given the entry data, and the machine solves the problem by applying various methodologies. Some of the essential algorithms that are used utilized by machine learning are linear regression. logistical regression and decision tree. So the two types of machine learning that's important to understand are supervised and unsupervised Supervised machine learning is used in context of classification and regression. So algorithms used in supervised machine learning including logistic regression, support vector machines, and so on. The aim of both classification and regression is to find the structure of the input data so that it can produce accurate output data. Unsupervised machine learning includes clustering, representation learning, and density estimation. Groups data based on output. So algorithms used in unsupervised machine learning include autoencoders, principal component analysis, and clustering. And then the cluster method is, or cluster analysis is the most common method. So again, if you're interested in uh artificial intelligence machine learning, you really want to take the 4200-1 course as well. There's also cloud computing. This is uh uh something that's been in use for several Seems like at least a couple decades by now. Cloud computing is a delivery of computing services like servers, storage, databases, networking, and processing power. So in general, cloud computing delivers a service of some sort over the internet to the auditee or to you as the customer. There's different categories of uh of uh cloud services or cloud computing. So we have infrastructure as a service or IAAS. So that delivers servers with CPU, memory storage, and so on. And it allows customers to directly access the virtualized hardware. So you could think of Microsoft, Azure, where you're building a virtual server. That would be infrastructure as a service. Platform as a service. Is a complete development and deployment environment in the cloud. It allows developers to scale their cloud resources according to the needs such as CPU cores, memory, and storage. And then we also have software as a service, which is the applications are hosted by the provider and delivered through the web. This allows providers to offer a cloud service to run existing online applications Multiple users can access the same application while the user's data and sessions are isolated from others. So a good example of software as a service would be like uh uh Microsoft O365, where you're accessing the platform itself. We are accessing Outlook through through the browser or maybe G Suite or Gmail. That would be software as a service. So there's uh traditional levels or levels of integration in relation to uh cloud computing. You should sort of understand uh the concepts behind these. So you have traditional IT and that's pretty much the no cloud computing at all. What that means is that uh you as the IT team or the auditee. Would be responsible for everything. And as the auditor who is auditing, the auditee, if they had no cloud computing, then you would have a lot of different areas to audit. So then we get into infrastructure as a service. So for example, there we have less management that we personally have to care about. And we've offloaded some of the responsibility like the storage, the network, the server's virtualization, and so on. We've offloaded that to the hosting provider. Then we also have platform as a service where more and more is offloaded to the hosting provider and the only thing we care about is the application and the data. And then there's even more, software as a service. Again, Gmail is a perfect example of software as a service, or O365 from Microsoft Where you pretty much just use it as as you need to. But they manage everything else on the back end to make it work. Practical approaches for auditors in cloud adoption. The revolution of various organizations brought about by cloud computing necessitates careful consideration. of substantial associated risks. So a few methods auditors use effective to effectively handle the possible challenges that could come out of this are risk assessment and adjustment Inventory of cloud activities, roles and responsibilities, clarification, timely involvement, internal training initiative, and a team-focused approach So all of those come together from the practical approaches for auditors and cloud adoptions. If the uh an auditor is going to uh audit a client or an auditee that has cloud Solutions, then or even if they don't have cloud solutions, auditors should ask the client, do you have any cloud solutions in use? It could be anything. For example If uh if they're a G Suite uh company, uh they should ask them, hey, do you have any cloud solutions that you're using? And if they say, yeah, we use G Suite, okay, they should declare that to the auditor so the auditor can understand it. But also as a part of that, the auditor needs to understand the risks of involving that cloud hosting provider of some sort. What are the risks? And if a company is going to migrate to the cloud, then they need to that company needs to understand the risks and possibly do a risk assessment. And if the auditor is showing up right after that, or possibly right before that That might be something that the auditor asks the auditee, have you done a risk assessment in relation to the transition? What's your risk? And if there's a problem, what are you going to do about it? Outsourcing operations. Um, first off, if you're using a cloud service, you are actually outsourcing something Organizations can select or identify potential controls from any standard or source, like legislation, industry best practices. that it deems appropriate and applicable. Organizations can also outsource different kinds of services like payroll, technical support, HR, and so forth It's very common for uh corporations to outsource something, uh if not one thing, but a whole lot of things. The company ADP, which does payroll transactions in the United States, maybe globally, but they do payroll transactions, a lot of corporations outsource that function of payroll to ADP. So you can outsource responsibility. So in this case it's outsourcing payroll to ADP. uh meaning that ADP has to pay the people, but you can't outsource accountability. And that's important to understand when it comes to ISMS or cybersecurity. So organizations outsource in order to reduce their costs, become more efficient, and focus on crucial operations So again, it's very common to outsource. It could be a variety of different things. Payroll is certainly possible. Technical support is possible. Security operations, forensics. uh cybersecurity in general, human resources, all of that could be outsourced and it's totally applicable. In the case of GDPR, for example, It it literally states in there you can outsource the role of the data protection officer to a third party, provided that they have the same amount of authority. uh to perform their duties uh per GDPR requirements. So auditing the outsourced uh operations, the process of auditing outsourced operations Involves the following steps. This is not just these steps, but basically the understanding of them. Reviewing and evaluating the organization processes for monitoring the quality of their outsourced operations. So how good are they going to do? Do you have SLAs in the contract? Verifying if contractual requirements are met So again, contractual requirements, whatever they are. In some cases, uh in most cases, if you're outsourcing something that's cloud-based. . It's not unreasonable to think that the company is going to require what's known as 5. . 9s. So 99. 999 uptime of that outsourced cloud-based solution Determine whether appropriate governance processes are in place with regard to the engagement of outsourced persons or organizations So are they safe to do business with? Uh do they actually do what they say they're going to do? Do they have to report to anybody? Do they have to be certified in 27,000 one as well? And then reviewing and evaluating the organization's plans in case of expected or unexpected termination of the outsourced agreement. Again, this goes into risk and vendor due diligence, but uh in relation to outsourcing, it's always a suggestion for a company if they've outsourced something. Find a backup in case that primary uh outsourced hosting provider uh goes under, goes out of business, uh decides to, you know, maybe they get a breach or something, who knows? But it's always good to have a backup plan And as a part of that, it's important that the auditor uh gather enough audit evidence regarding contractual agreements between the auditee and the outsourced hosting provider to validate that the the out the auditee has done their vendor due diligence to make sure that they've done what they said they were going to do and that the outsourced hosting provider is safe to do business with. So this could be done a variety of different ways, conduct interviews with persons or persons responsible to uh you know check on the vendors or the suppliers. Uh but it could also be done by looking at the evidence that a uh a uh internal person within the auditee firm, like, okay, did you check this company? Yes. They had a SOC two and ISO twenty seven thousand one. Okay, show them to me. So they can see it. If the uh internal person for the auditee has the material or possibly a risk assessment sheet for that uh outsource per uh outsource company, then it can demonstrate to the auditor that uh proper vendor due diligence was being done. So this is the section summary summary. We're almost over with this one. Technology allows auditors to work more efficiently by minimizing time and costs. Thus, they increase the audit quality. Big data includes a large volume of structured and unstructured data Remember structured data would be think Microsoft SQL SQL. Unstructured data, think uh MongoDB. The Merriam-Webster Dictionary defines big data as an accumulation of data that's too large and complex for processing by traditional database management tools. Artificial intelligence encompasses a broader concept of machines that have the capability or capacity to mimic a human being. Machine learning is related to AI, but they are not interchangeable. The goal of machine learning is to let computers learn automatically. Cloud computing includes the delivery of hosted services over the internet, software as a service, infrastructure as a service, platform as a service are all there. Outsourcing is the practice of hiring a third party, which could be a human being, a person, or an organization, to perform activities, tasks, and provide services for the organization. Again, if you're interested in more learning more about artificial intelligence or machine learning, highly suggest you take the ISO 42001 course. With that, I want to thank everybody for your time. I will see you on the next one. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S08.1-Evidence-based-auditing.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S08.1-Evidence-based-auditing.md index f061d0d..4dafec2 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S08.1-Evidence-based-auditing.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S08.1-Evidence-based-auditing.md @@ -12,6 +12,8 @@ status: active ## Abstract +This session introduces evidence-based auditing as defined in ISO 19011. Audit evidence is defined as verifiable records, statements of fact, or other information relevant to audit criteria. The session explains the difference between qualitative and quantitative evidence and covers the main types of audit evidence: physical (direct observation), mathematical (calculated metrics), confirmative (third-party validation), and technical (requiring specific expertise such as firewall configuration analysis or penetration test results). The session emphasizes that evidence types are not mutually exclusive and that auditors should seek objective verification rather than relying on auditee assertions alone. + ## Transcription Hi everyone, thank you for joining me. This is section eight for ISO 27001 Lead Auditor, Evidence-Based Auditing We're going to talk about audit evidence, the different types of audit evidence, quality and reliability of audit evidence as well. So we're going to talk about the different types and how they interact with each other and their applicability. So 19011 clause 3. 9 defines audit evidence as records, statements of fact, or other information which are relevant to the audit criteria and verifiable. So audit evidence must be verifiable and can be either qualitative or quantitative. The uh the important thing about audit evidence is the verifiable part in relation to the actual evidence. So again, in a previous section we talked about Don't don't just take somebody's uh the oddity's word as fact. Uh you have to have some sort of way of validating the fact to prove that it's it's actually uh being done the way they say it is. So qualitative evidence. So that's the uh basically the concept of uh evaluating something from the standpoint of high, medium, and low. So for example, if uh if there's a risk of a breach, and we said it's a high risk of breach. then that that doesn't necessarily mean that there's going to be a breach, but there's the belief that it's a high risk as opposed to and that's qualitative As opposed to saying something like there's a 90% chance of a breach. If we said that, now we've qualified or we've quantified it with a number And generally, as an auditor or somebody who helps companies get ready for audit, I'm always a huge fan of quantitative evidence, especially when it comes to risk. So understand the difference between qualitative and quantitative. So different types of audit evidence. We have physical, mathematical, confirmative, technical. analytical, documentary, and verbal. And again, uh I hope everybody remembers when people say things, uh if it's possible to validate their their words, then you should absolutely do so. Don't don't assume that they're uh being uh a hundred percent truthful or accurate. So audit evidence does not have to be mutually exclusive either. So it's possible That you might have a uh a process, for example, with the within the audit T, and the process itself, just the mere existence of it, is audit evidence. But then the output of that process could be audit evidence for a completely different area. So it's possible to collect more than one type of evidence to uh determine the conformity or if somebody's the if the audit T is doing what they're supposed to be doing in relation to a particular uh control in the system So, for example, an external audit report is both a confirmative and documentary evidence. So we have an external audit that's confirming, but it's also documented, so it's documentary evidence The verification of the configuration of a firewall is not only physical because there's a firewall, it's also technical, but it's also analytical. And then an interview with a third party could both be confirmative and verbal. So we'll talk about physical evidence first out of that list we just had. Physical evidence is obtained through the observation or direct inspection of tangible elements. It is evidence that can be counted, inspected, examined, or observed. For example, the auditor can observe the physical access controls in the server room, or maybe the physical access controls to even get into the building. The auditor can observe the supporting utilities in the organization, and then the auditor could observe security measures across the board or maybe safety of human life measures Now, in relation to observation, it's important to understand that the auditor must observe it themselves. They can't take the uh the word that somebody else observed it and then just believe it. Observation is helpful in determining audit evidence for a particular kind of evidence because that allows for a faster response. So for example, If an auditor went to some sort of a shipping container for an organization because it's part of the inventory to make sure they're possibly counting inventory or whatever Or look inside the container to make sure that what's inside the container as listed on the packing slip is actually there. That would be an observation Other areas of observation could be walking into the building and observing how did you get inside the building? Do you have to register as a guest? Are there cameras? Are there badge entries? Are there turnstiles? There's all sorts of different things. We also have mathematical evidence. Mathematical evidence is obtained by validating the mathematical exactness of certain documents or records For example, the auditor can calculate the number of training hours relating to the ISMS provided to the personnel. They could also risk uh count the average time it takes to respond to an information security event or incident. as well as the number of nonconformities and corrective actions taken after each internal audit. Mathematical evidence is something I really like because It allows for numbers to be used. And why do we care about numbers? Because numbers can relate to percentages. Numbers can be related to dollars or revenue. So mathematical evidence is is really important from my standpoint as an auditor. Because it gives me a better understanding of the context of the organization. So for example, if we talk about training hours to the ISMS That are provided to people. I could say mathematically that you know each person went through three hours of training. There's a hundred people, so 300 hours of training was initially provided. I could even go so far as to say uh 52 phishing emails were sent out and uh 10% clicked the link or whatever, and then that 10% was uh provided with uh remedial training. So I like mathematical evidence a lot because it allows for a lot of different things. Obviously in financial audits, mathematical evidence is going to be utilized just to make sure that the numbers are right, but that makes sense. Uh how you use math as a part of uh mathematical evidence collection is really up to the auditor, but it's it's certainly uh something that could be done. Confirmative evidence, that is evidence that is obtained by the confirmation of a third party regarding one or more elements observed during the audit. Examples of confirmative evidence are the results of an intrusion test conducted by an external organization. So an external organization or intrusion test, think of that as penetration testing. Verbal statements by the external parties confirming that the organization has engaged in external communication activities. Now if you don't have verbal statements, you could have uh contractual statements that could mean uh something that along the same lines You could also have a prof professional certificate recognized by a recognized uh uh professional certification body So, for example, once you take this complete course and you pass the test and you apply for certification you'll get a professional certificate recognized by a certification body, which is PCB. So there's all sorts of different ways, but the important part in relation to confirmative evidence is it's done by a third party Not the people that you're actually auditing just by a third party. I like to use penetration tests as a really good example Because uh they're practically irrefutable. The the auditee, if you ask the auditee for examples of a penetration test or if it was even done, they're gonna hand you the same document that was handed to them So areas that can help in a auditee have an easier process for auditing is uh has to do with one of the uh other sections that we discussed, and that's dealing with the um outsourcing operations so or outsourcing services to a third party like payroll or uh onboarding and background checks and things like that So the reliability of confirmative evidence will depend on the reliability of the auditee in relation to the third party who provides the evidence. So a reputable third party is more reliable than a disreputable third party. This type of evidence is usually reliable if produced by an independent entity, so a third party, which should be external to the audite. So they're hired to come in and do a particular service or function or whatever. So, examples of mathematical evidence that could be used could be in the areas of competence. So, for example, if you had 10 people on your cybersecurity team But only three of them are certified in cybersecurity, then you could say your competence rate is 30%. Uh and the other s seven people on the team would have to get training in order to bring up that confirmative evidence And of course you wouldn't just assume they're certified, you would ask to see their certification papers. You could do segregation of networks showing that uh information services, users and groups are segregated. There's a variety of different ways you could come up with some sort of confirmative evidence. And as a part of that, you could even say, you know, a network drawing confirms that there is segmentation. There's also technical evidence characterized by the specific knowledge or expertise required to obtain it. This knowledge or expertise can be related to the organization, an activity, a process, a product, a service. or something else. Technical evidence is often, but not necessarily always, obtained with the help of a technical expert and requires conducting detailed inspections or observations of relevant operations. So again, in a previous section, we talked about competence of auditors. And I repeatedly said, if you're not fully aware of how to do something, then get a technical expert. As an auditor, you're not required to know every possible aspect of cybersecurity as a part of the audit itself, but you are expected to be able to contact people to help you out. So an example of technical evidence are number one, analysis of an IPS, so that's intrusion prevention system, analysis of IDS, intrusion detection system, and then analysis of a firewall, like maybe the access control lists. Or if there's a VPN, what VPN encryption is in use? Or how are they connecting? That could all be technical evidence So there's a lot of different ways. You can do the same, have that same concept with uh asking for configurations, uh password configuration uh for uh in uh uh Microsoft uh Active Directory or something, what's the minimum requirements? Just ask for a screenshot of that. That would be technical evidence. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S08.2-Evidence-based-auditing.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S08.2-Evidence-based-auditing.md index db1c5e4..a3a31eb 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S08.2-Evidence-based-auditing.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S08.2-Evidence-based-auditing.md @@ -12,6 +12,8 @@ status: active ## Abstract +This session continues the evidence-based auditing topic by covering analytical evidence (statistical analysis of log data and incident reports), documentary evidence (policies, SOA, procedures, management review records), and verbal evidence (interviews and discussions). Verbal evidence is identified as the least reliable type, while physical and mathematical evidence are the most reliable. The session explains that audit evidence must be appropriate (relevant and reliable) and sufficient, and discusses reliability factors including objectivity, timing, source independence, collection techniques, and internal control oversight. Auditors are expected to seek additional evidence if initial evidence is insufficient. + ## Transcription Analytical evidence is obtained by analyzing data and their variations to find their tendencies as well as potential deviations. Analytical evidence includes any evidence collected by statistical methods. So examples of analytical evidence are analysis of network access logs to detect deviations or exceptions. Sometimes, depending on the level of intelligence you have with your technology, that could be called outliers. And again, we talked about outliers in artificial, the section about artificial intelligence Analysis of information security incident reports. Analysis of a sample of worker competency tests to measure the understanding of the information security controls, or possibly the the uh pop quizzes or quizzes at the end of information security awareness training. Come up with some analysis based on that. So there's a whole lot of different ways you can analyze the evidence. Obviously, as an auditor, we want uh we desire that our Auditees are up to speed on uh on as many things as possible. So we expect high numbers as auditors. And if they don't have high numbers and you know, we need to come up with a corrective action plan. There's also documentary evidence. This is really the easy ones uh to deal with and you're certainly going to see this in a stage one portion of a ISO 27001 audit We'll talk about the stages in a different section. But documentary evidence is obtained by verifying any record or document that exists already. So for example, information security policy. or any policy relating to information security for that matter. It could be encryption or asset management, it could be development, it could be anything. But those written documents that could be used as documentary evidence. Statement of applicability, where you're stating exactly in 27001 what is applicable and what is not and why for each one. Documented procedures. And any other documented information that the organization views as necessary for the effectiveness of the ISMS? And then also super important ed evidence of the result of management reviews. We can't create uh evidence or reports or reporting in generals, things like that and not actually have management review it to to sign off and endorse it. If uh if management is not aware of cybersecurity, then that is actually not a good thing. Not only in relation to the audit, but it's not good in relation to the health of the entity itself So other areas of documentary evidence could be non-disclosure agreements, policies of any kind, possibly records of backup. uh backup, you know, backing up the data, as well as if you're going to do a backup, you have to do a restore. Other areas of documentary evidence could be a penetration test provided by a third party uh which which would also be confirmatory uh evidence. There's also verbal evidence, which is obtained during interviews with persons that have the necessary knowledge and responsibilities to perform the operations. That are being audited. So general discussions carried out during the audit could be viewed as verbal evidence, and then formal interviews conducted during the audit. However, I will point out Do not assume that your answers from a ver from an interview, the verbal evidence, are accurate. Verbal evidence is very unreliable. compared to actually seeing like the firewall access control lists or seeing a penetration test. It's unreliable And you will find that uh there will be one person that says one thing to this to a question and there will be a person that says something else to the exact same question. And that's generally because the co the organization is not in sync with each other. or that or one person just doesn't know. So there's a whole lot of different ways we can have verbal evidence, but it's also important to understand that verbal evidence could could be uh a tied uh tied to different areas like for example is your leadership and management are they behind uh deploying the ISMS do you have top-down support People could say yes. Uh leadership is totally behind it. But how would we prove that? So we can believe it, but if we had some sort of email from leadership saying We're deploying a 27,001 ISMS. Everybody needs to be on board and we expect full cooperation. That's better evidence than just saying yes, top-down management or top-down support is in place. Quality of audit evidence, audit evidence must be first appropriate and then sufficient. So we have evidence And you can see there it's it's a is the evidence appropriate? Is it relevant? And is it reliable? So is it is when I say relevant, is it relevant to the requirement? But then more importantly, is it reliable evidence? If it's unreliable evidence, then as auditors, we need to figure out how to make it reliable or get different evidence. Once we've done all that Then we can compare it to the control, to the requirement, and we can determine is it sufficient or not. And if of course, if it's not sufficient, then uh going circling backwards, taking a step back. We go find more s more evidence until it is sufficient. But we have to get to a point Whereas auditors, we are comfortable that the evidence provided for any particular control in 27001 is sufficient to meet that control. And if it's not sufficient then we uh have to you know ask for more. Uh reliability of audit evidence, so the main determining factors is objectivity of the evidence, the timing, independence of the source evidence collection techniques and then the internal control system. So objective evidence is based on facts and proof Not hearsay, not belief or anything else. It's based on facts and proof. And we want to make sure that is accurate. So an example of this. If we uh if we said, hey, do you have uh surveillance system, physical security, like cameras or something, we could go around and observe the cameras in place, but that doesn't mean the cameras are recording anything. We could then ask, well, let's see the the the screen where all the camera feeds are going into and if we saw that then we could even go so far as to say Uh hey, uh how long are you retaining the data, the video uh surveillance? So there's all sorts of different things that um That's could be based on. So the objectivity is it's the evidence is based on facts and proof that you can actually see There's also timing of the evidence. So if if we had something with timestamps on it, then uh that proves that the evidence is recent, then that's sufficient. If we have uh evidence that's Say evidence is only required once a year for something. Uh so provided it's within that year time period, technically it's supposed to be good. But if we can regenerate evidence that's closer to the actual audit, then that's even better. But we don't want to say if we have a requirement for evidence that's some kind of task that has to be done monthly, we don't want to submit evidence that's six months old for a task that's supposed to be done monthly Independence from the source is super important to make sure that the evidence is collected outside of how it was generated And then we also have to care about the evidence collection techniques. There could be a variety of different ways on that one. There's collecting evidence or creating evidence in relation to sampling and collecting it that way as well. There's all sorts of different ways. I believe there's other sections where there's evidence collection techniques are discussed in greater detail. There's also the internal control system That has to do with uh the evidence that's collected. Where is it stored? How is it tracked? Who's monitoring it? Who's approving it? Who's saying that this is sufficient enough Are other controls being monitored and adhered to? So there's a quite a variety of different ways of looking at audit evidence. We have verbal evidence, which we've already said is the least reliable Documentary evidence, which could be like a document itself, like a policy standard procedure, but it's written down and we assume that they're doing it right. Analytical evidence. Is uh analysis of evidence to come up with a determination of the uh analytics for whatever the evidence is around Technical evidence like configuration files or evaluating like a server password management uh complexity, things like that. confirmative evidence, uh something that confirms evidence as being accurate and realistic. Then we have physical and mathematical evidence, which we talked about, uh physical evidence could be uh like an you're observing something. of you personally observe it. You're physically observing it, whether it's like a a surveillance camera or maybe antivirus on the workstation, uh could be anything. And then mathematical evidence is calculating, uh coming up with a calculation of of the auditee's environment to figure out, you know, how things are So a good example that they provide here is for mathematical evidence, calculations of the number of auditees computers and the number of antivirus licenses acquired. So if you had a hundred computers, but if you only had 50 antivirus licenses, well you got a problem. And in this slide you can see um The uh the layout of the types of audit evidence least reliable is verbal. Don't believe that uh when somebody says this is the way we do things, don't believe that that's the way they do things The most reliable is physical and mathematical evidence. Alright, this is the summary for section eight. There's seven major types of audit evidence, physical, mathematical. Confirmative, technical, analytical, documentary, and verbal. Again, remember, verbal is the least reliable. Physical and mathematical is the most reliable Documentary is when they uh you're you actually see copies of administrative controls like policy standards, procedures, and so on. Any information that can be verified, measured qualitatively or quantitatively, and used to determine the audit findings can serve as evidence Remember qualifying something is a relative term like high, medium, and low. Quantitatively is a numerical term, like 90%, 100%. Audit evidence should be relevant, reliable, and sufficient to be considered acceptable. In relation to sufficient, remember again that if it's not sufficient, your job as an auditor you would go around and uh and basically uh request more evidence. So there is a quiz for this section, but this is a recording, so you'll have to do that on your own. Thank you. I'll see you on the next one \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S09-Risk-based-audit.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S09-Risk-based-audit.md index 0b2e6bb..e074fe8 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S09-Risk-based-audit.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S09-Risk-based-audit.md @@ -12,6 +12,8 @@ status: active ## Abstract +This session explains the risk-based audit approach, covering three types of audit risk: inherent risk (sector-related defects), control risk (defects not caught by internal controls), and detection risk (defects not caught by auditors). Risks associated with audit program planning, resources, team selection, communication, and auditee cooperation are discussed. The session introduces the concept of materiality, borrowed from financial auditing, defining it as the threshold at which an omission or error could influence decisions of interested parties. Materiality is evaluated progressively during initial contact, stage one, and stage two audits, and auditors must accept that only reasonable rather than absolute assurance is achievable. + ## Transcription Section 9 presents the type of audit risks discusses how to determine and evaluate the audit program risks and opportunity as per ISO 1911 and also introduces the concept of materiality and how to determine the materiality of a system. So looking at the audit approach based on risks. So there are a couple of um different audit risks That we can determine. First of all, we have the inherent risks. So the inherent risks really refer to the risks that despite that an internal control mechanism is active in the organization, a significant defect occurs in the management system. These defects are related to the industrial sector in which the oddity operates. Secondly, we have the control risk. A control risk refers to risks that have a that a significant defect will not be detected or prevented by the organization's internal control mechanism. These risks are obviously higher, according to auditors, in organizations that have ill-defined processes, and where those processes are mainly manual. In contrast, automated processes will have a lower risk of failure. If they are well configured. And lastly, you have a detection risk. Detection risk refers to a risk that a significant defect could not be detected. even by the auditor. In order to minimize such risks, auditors apply the audit principles based on risks. And we will go about talk about that in the later slides, or on materiality. Now, if we look at ISO 1911, that ISO standard gives us an explanation on risk. So risk is really an effect of uncertainty. So an effect is a deviation of what is expected, and that can be both positive or negative. And uncertainty is basically a state, even partially. Of deficiency of information related to understanding or knowledge of an event, its consequences, and its likelihood. So risks are often characterized by a reference to a potential event or consequences or even a combination by those. So understanding what risk is is obvious very important if you want to use an audit approach based on risk. Now If you look at an audit approach based on risk, we of course need to have a look at a couple of things. And there can be risks associated with a couple of things. There are risks and opportunity related to the context of the audity, so the organization that you're auditing, that can be associated with an audit program, and that can affect The achievement of the objectives of the audit. So there are a couple of things that need to be taken into consideration So there can be risks associated with the planning. For example, a failure to set relevant audit objectives and to determine the extent, the duration, location, or even a schedule of the audit. There can be risks associated with the resources. For example, you don't get enough time, the resources are not available, you didn't receive training to set up the audit program, or you don't know how to conduct an audit. There can be a risk associated with the audit team, selecting the right people, because you, for example, don't have people with the right competences to conduct an audit. There can be risks associated with communication. That there are ineffective communication controls. You don't have effective communication channels. Think about You're sending like 20 emails and there isn't a response coming back and perhaps the email address was wrong. So there might be issues with that. There might be risks associated with implementation So um an ineffective coordination of audits within the audit program or not considering information security and confidentiality There might be risks associated with the control of documented information. So might be the case that people don't know what information that is necessary. You can't process audit records to demonstrate the audit program effectiveness. So there might be risks associated with that. There might be is risks with monitoring, review and improving the audit program, so that there might be an issue with reviewing of ineffective monitoring of the audit program outcomes And of course, there might be risks with the availability and the cooperation of the auditee or the availability of evidence that has been sampled. So if you want to have an a sample done and you can't access the information or the information cannot be shown that obviously will pose a risk. So when looking at opportunities for improving that audit program, you can of course think about a couple of things. Firstly you can think about Having multiple audits in a single visit. You can minimize time and distance to traveling to another site. You might think about matching the competences of the audit team so that you have people that have a higher competence accompanied with somebody with who is less experienced and has less competence and you might also think in aligning audit dates with the availability of the audit key step which is uh usually the right way uh to go. So an auditor should um act as part of an assignment uh of an individual audit The risks and opportunities of the organization can be included. The core objectives for such an audit are I give assurance on the credibility of the risks and opportunities that uh were tracked in the identification process. So really understanding okay where are the risks coming from and what are the inputs that the organization uses um so that might be checking if there are external and internal uh issues the strategic uh direction of the organization did they get um input from interested parties, um are there potential sources like environmental aspects that have been taken into consideration. So really looking at the process if it's a valid process Secondly, an auditor should also check if the assurance that the risks that have been determined that they are managed in a correct way and also review how the organization addresses um its determined risks and uh opportunity. An audit of an organization's approach To the determination of risks and opportunities should not be performed as a standalone activity. So any review of your risk assessment process and the treatment should be implicit throughout the whole audit of a management system. Um especially when interviewing top management. What happens a lot of course is that um the risk assessment Is conducted by an ISMS manager and representatives of the organization, and that top management is isn't really involved. However, it's good practice to refer back to the risk management process because all of the controls should uh or most of the controls should be implemented based on risk. So looking at the risk assessment and understanding where the risks are coming from is a good practice to have that throughout the whole So the treatment, the including and the acceptance of a risk and what the organization determines, is of course based on judgment of the audit. If we look at mat reality, so um if you look at the uh definition of mat reality uh um in order to limit audit risks and obtain reasonable assurance The auditor must place emphasis on the processes deemed material to the oddity. So another word for material is of course critical. So you look at the critical processes of the oddity Information is of course considered material or critical if its omission or erroneous handling of statement can influence the decisions of the interested party. So the term materiality comes from accounting. It's not something that comes out of the world of information security, but it comes out of the financial world. Financial auditors usually measure materiality in monetary terms since what they audit is also measured in money. So it's normal that they measure that in monetary terms. term. So materiality really depends on the nature of the information and the seriousness of the error with within that particular circumstances of its emission or which something would go wrong. So, based on the oddity, the auditor, it's up to the auditor to really estimate the materiality threshold from which the interested parties could change their decisions concerning the oddity. So for example, if you would have an inventory loss of fifty thousand dollar undeclared or not detected by the auditor It would be non-material if the organization would make 10 billion US dollars revenue per year, but it would be material if that same organization would only make one million in revenue. So it's really based on What does the organization do? What is the impact? What are the interested parties to determine that materiality threshold? So that's really up to the auditor to determine that. Now, when determining the materiality of a system, there are of course a couple of factors that need to be considered First of all, you look at the cost of the process. What is the cost involved in material, software, potential licenses, or a combination of those? You look at the cost of the operation, like personnel, third-party general fees, combination of these again. What would be the potential cost of errors or non-conformities What are the resources that you need to conduct the process, of course? What are the conditions of service level agreements and costs of potential penalties? And what are the penalties in case of failure to conform legal, regulatory, and contractual obligations? So it's really um the combination of these six factors that make up that materiality threshold. So it's it's not something that an auditor does like on a P Sheet of paper to really come up with a calculated uh estimate, but it's something that based on um the experience of the auditor, based on uh understanding the context of the organization That auditors determine that materiality of a system. So materiality is of course very important when a process is really vital in achieving that organization mission. So In in determining or evaluating that materiality, the auditor should really consider what is the general level of error that is acceptable by management, but also what is acceptable by the certification body. So it's it's it's a combination of three things and what is acceptable by management, what is acceptable by the auditor and by the certification body. It might be the case I haven't seen it a lot though, but it might be the case that an organization decides that they are okay with a certain level of error, while um with common sense you would say, well, you're saying that because you want to get um through the audit in an easy way. So then you need to have a discussion about that. Or the possibility that small errors or small weaknesses would accumulate to um a materiality So evaluation of that materiality is really a question of professional judgment. So it's really based on the experience, the the context of the organization. So the auditor must really look at the general effect on the organization Now, when do you come up with that materiality of an audit? Well it's actually done throughout each step of the organization. So first of all, you have a couple of contact points with your odity. So you have usually your initial contact with the organization where you determine basically the duration of the audit based on inherent risks to the organization So that is where you check, okay, what is the sector that the organization is part of, what is laws and regulations, what are the number of workstations, what is the complexity of the sector system, how many employees do they have? So based on the inherent risks on the context of the organization, you make a first assessment of that In your stage one audit you will have a look at what are the key processes. So you will have a look at um your management system as such. So based on that You will have a look on okay, what are the processes that are now more material than others? So which are the ones that you really want to dive into in a stage two? So making that assumption on based on the initial contact, then checking that in the stage one will give input to your stage two audit where you will adjust the plan based on the materiality of Each process and asset. So basically, these three phases help you by determining the materiality and coming up with a detailed audit plan that will have a focus more on processes that have a higher materiality. So auditors um try to get basically a reasonable assurance that um yeah the audited management system is um free of uh erroneous material um representation and non-conformity. So the problem or the challenge with ISO twenty seven thousand one audits is that auditors are not able to obtain that absolute assurance that the audit conclusions reflect the reality because we always take samples so it's not a 100% uh check So in a ISO 27001 auditors, um auditors should be able to obtain that reasonable assurance That the ISMS as a whole conforms to the requirements as a standard, and it it's not the goal to achieve that assurance that each process is effective and in compliance with the standard requirements. course. So um there are limits of course uh to what an auditor can detect uh based on false material representation You cannot see you only have a limited set of time, so it might be that material might be false, that is not correctly. You cannot always see that there are issues in the internal processes. And you can also affect that several audit evidence is persuasive rather than conclusive. So there are limits of what you can see in an inter or in an uh in an audit based on ISO 27000 So in conclusion, the main types of audit risks are inherent control risks and detection risks An audit approach based on risks, consider the risks and opportunity of the audit that are related to the context of the audity. So you always look at the context of the organization. The main factors to consider when determining the materiality of a system include cost of operation, cost of the process, potential cost of errors or nonconformities, the resources needed for the process Conditions of service level agreements and penalties related to legal non-compliance. Materiality is evaluated at each step of the audit, meaning the initial contact, phase one and phase two audit And auditors cannot obtain absolute assurance that the audit conclusions reflect the reality. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S10.1-Initiation-of-the-audit-process.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S10.1-Initiation-of-the-audit-process.md index 0dffef4..5ff76e8 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S10.1-Initiation-of-the-audit-process.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S10.1-Initiation-of-the-audit-process.md @@ -12,6 +12,8 @@ status: active ## Abstract +This session introduces the PECB AMS II audit methodology and its six phases: initiation, stage one audit, preparation for stage two, stage two audit, audit conclusions, and beyond the initial audit. The session focuses on phase one, covering how to accept an audit mandate, what an audit offer contains, and how to appoint an audit team leader. The roles and responsibilities of the audit team leader are described, along with criteria for selecting team members including competence, language, cultural awareness, conflict of interest, and technical expertise. Valid reasons for requesting replacement of an auditor are also discussed. + ## Transcription Section 10 aims to provide information on receiving an audit offer, appointing the audit team leader and other audit team members, determining, of course, the audit feasibility, accepting the audit establishing contact with the auditee and defining the audit schedule. So this is really the kickoff of the audit. So let's have a look So PECB has developed a methodology developed for auditing a management system. It's known as the accepted auditing methodology for management systems and standards. In short, it's AMS2. This methodology has been developed based on best audit practices and on ISO 1911 guidelines, and it also meets the requirements of ISO 17021-1. So the AMS II consists basically out of six phases. It's very similar to a normal audit cycle. So the six phases are the initiation of the audit process. Then we go to the stage one audit. Step 3 is the preparation for stage 2 audit. Step 4 is stage 2 audit itself. Step 5 are the audit conclusions. And step 6 is beyond the initial audit. So each phase within the AMS II has three to five steps, which are further divided in separate activities. The methodology also consists of two supporting processes which are communication during the audit and management of audit risks. During the training course these steps will be presented and illustrated in a chronological order The activities in each step. So each phase has two to five steps, and in those steps there are a multitude of activities that need to happen. We will not dive deep into the activities because they depend on the specific context of the audit. So the appointment of an audit team leader, for example, will depend on whether the certification auditor has a qualified auditor or not. And these steps involved then a series of activities such as a job interview, signing of the contract, which we will not go deeper into So on the slide, you see the six different phases with the activities included there. And you see, as a supporting process, is of course the communication during the audit and management of the audit risks. So, for this section, we will dive into phase one, which is initiation of the audit process, and we will talk a little bit about the five different steps that need to be taken there. So, first of all, you need to accept an audit mandate, and the certification body needs to accept the audit mandate and the certified auditor as well, and you need to appoint an audit team. So prior to accepting that audit mandate, the auditor receives an offer from the certification body. So that's of course a little bit dependent. on how the qualified auditor is appointed. Is it an employee? Is it a full-time employee? The engagement in audit is already part of the employee contract, so there might not be an official offer or an official mandate. The same goes goes when a certification body works with self-employed auditors and they have like a contract which is uh an open-ended contract um then you don't have that specific of offer either. So the process of accepting the audit mandate helps of course in avoiding any misunderstanding that might arise during the audits. And the official audit offer then offers as the yeah as a contract between the auditor and the certification uh body um and it's best that it's formally signed. So if I look at my experience as an external audit I don't get um specific offers per audit. I have an an open-ended contract as being self-employed And we agreed on the number of days that I would do audits. And as long as the days have not been fulfilled, the calendars are checked and there's also of course a check of on the independency. and then the audit company just uh completes um the planning in my calendar so but it will be different from certification body to certification body Now looking at the audit offer, what is usually included in an audit offer? Of course the audit scope um the audit objective and the criteria. The duration of the audit and will it be ten days, will it be twenty days, will it be only three days Potential audit team members, the responsibilities of the audit team members, what are the limits of the audit engagement And um of course uh almost also very important uh the auditor's payment is also very important, of course. Um so the auditor and the certification body should agree on that uh audit offer and on the terms of the offer mandate. So just to ensure that there is no misconfusion, there's no discussion afterwards. So on the following slide you see um an example of an audit offer where you see Basically, name of the auditor that they state that there is an um an audit that needs to be happening against the ISO 2701. You see there is a line on Your responsibility will be to ensure that the organization has implemented and continually maintains and improves in signing the offer as well as the attached terms and conditions. You agree to those and you will perform the audit in uh name of the certification body. You see the duration it will last 16 days which is already a pretty long audit And the audit scope covers the organization's headquarters, including the data processing centers and seven offices. And the other team members will collectively have the necessary skills and expertise to conduct it. And the payment details will be specified. in an uh a separate document. So it really entails everything that you need to know before engaging in an audit for you as an auditor. Now, um appointing an audit team leader is of course very important. Before each audit, the certification body should appoint only one audit team leader. That person is a is responsible. For conducting the audit until its completion. So the audit team leader is the one who uh drafts up in the end the non-conformities, who comes with the conclusion he's and responsible. So um very important here on the terminology and the term audit team leader is not um the same as certified lead auditor. Although uh there might be a lot of team members on the audit team that are also lead auditor, but the team leader is basically the one that leads um the audit who has um the duties and has certain duties and responsibilities And everybody involved in the audit team should also agree, of course, on the authority of that audit team leader. If you have misconception on what the audit leader is supposed to be doing, you get a lot of frustration. So the audit team leader is responsible for a lot of things. He needs to he or she needs to plan the audit. He needs to think about potential audit risks and he needs to think about how he's how he's going to address them. He or she is also responsible for undertaking the communication with the audit team. He needs to manage the audit team. He needs to assign the responsibilities to each team member. Here she also needs to solve any conflicts within the audit team or conflicts with the audit team. Here she is also responsible for drafting and reporting the audit conclusions. And he or she needs to uh prepare the uh audit report as well. So um there are a lot of responsibilities that come with the audit uh team leader. How it usually happens is that the team leader is basically responsible for everything and you have in an audit regular touch basis during the audit to check whatever goes wrong or what non-conformities that you have have encountered during the audit Of course, you also want to select an audit team. Any successful audit will be dependent on the audits, the auditors that you choose, the competence that they have. um the expertise that they have uh with the industry. So um when you decide on uh the size and the competences of an audit team um you need to take into consideration a couple of things First of all, you need to have a look at what is the audit mission and what are the audit objectives, what is the scope, what is the location. So you Um you also need to ensure because everything um needs to be paid by the audity, so you have to have a look at okay where is the the audit happening uh Do I have auditors close by? Do we need to fly them over? So that will be uh one part to think about. You also need to think about what are the required competences of the audit team And do we um need any specific expertise um to communicate with the oddity? Um is there technical knowledge necessary? Uh what language is the audit uh in Is there any um social or particular cultural characteristics that we need to take care of? Um for example, I can imagine if you go and audit in Saudi Arabia, it might not be the best thing to send uh a woman or perhaps it is or and the same goes for Israel for example. So you want to think uh about any social and particular cultural characteristics And you want to have a look at each individual team member. Is there a conflict of interest? Are the auditors obviously available? What is the specific expertise as well? So Um if you just pick and choose without taking these things in consideration, that will have an impact on the effectiveness and the efficiency of the audit, of course. So it might also be the case that you don't have any specific technical knowledge in the audit team and that it's still required then you can add technical experts um or translators um to uh the audit team just uh to help them um yeah perform the audit and when you use of course translators or interpreters uh they should not um yeah affect the audit as such as so they're just there uh to basically translate whatever needs to be done So when selecting um the audit team, um you there is a difference, of course, um in what you uh should be looking at. So um the individuals that manage the audit program, and the so the the lead auditor. needs to appoint those members. It usually is done together with the certification body, but you need to take into account competences needed to perform in line with the objectives to perform that individual audit. So of course you need to have a look at the overall competence of the audit team. So you need to have a look at okay what is the competence needed as I already explained And you also need to select those other team members so that you have all relevant uh knowledge in there. So you need to have a look, and depending on the size and complexity of the audit, of course, you need to think about okay, what is the overall competence that we need? What is the complexity of the audit? Is it a combined audit? Are you doing multiple management systems? What are the audit methods that you're going to use? Can everybody act in an impartial and objective way? How are people working together? How are they able to communicate with the external parties? What is the complexity of the processes? What is the language? But when looking at the audit competences, uh each auditor mainly needs to be able to communicate in a good way. They need to be able to work together. although usually uh auditors um are used to working in solitude. Uh you don't always have an audit team. Um but if you have an audit team you need to be able to work together well. You need to have good communication skills because you also need to communicate of course with your customers. You need to know the risk-based approach to auditing. You also need to of course understand the standards, the audit standards, the procedures In ISO 27001, you of course need to understand what requirements of 27001 are, and you also need to understand organizations main business processes. So you need to have a basic knowledge on whatever the organization is doing. At least one audit team member should have knowledge of the industry in which the Audity operates Knowledge of the Odity's language, of course, expertise in each domain to be audited, and some knowledge about legal and other requirements that the auditee is subject to So it is very important that uh you take that into consideration. Of course, um not everybody uh will have all uh the knowledge and that's not really necessary. You can add as I already s stated. Technical experts. You can also add auditors in training, but they're not supposed to be working alone, so they always need to participate under the direction and guidance of an auditor. So it's very important that everybody knows what their role is in the audit process, and you need to ensure that you have the necessary skills and competence available. Usually, at least that's my experience, this is checked beforehand, also in the initial stage, to understand what is the specific need that the organization has. Now, an audit client or an audit tee has the right to request a replacement of an audit team leader, of course. You need to have valid reasons. So, what usually happens is that the certification body provides with the names of at least the lead auditor but also the team members And an certification body can also present with a resume or some background information to the certification to the auditee. um to give them enough time to do an analysis if that's happened. Now I haven't seen that happening a lot. I we usually provide with the names um but an RDT Can say I I don't want to have that person um on the team, I don't want it, but there needs to be a valid reason of course. A valid reason can be a couple of things. It might be that there is a conflict of interest. That might be a real one. For example, the auditor has previously worked for the Odity, or a perceived conflict of interest. For example, the auditor has worked for a competitor and uh the audit doesn't want uh the auditor um to see their internal processes as well. Um the fact that an auditor has previously displayed uh unprofessional conduct might be a good uh reason. It might also be the case case that in certain industries, some sectors like um aviation, um anything that has to do with defense, nucle nuclear power, those kind of things It can be the case that an auditee requests the auditors or members of the audit team to hold a security clearance or a background check because you need to do that from out of legislation sometimes. So it might be the case that that is requested as well. So it is of course very important that you communicate the reasons that a customer or an oddity asks you to remove somebody from the audit team to communicate that as well. So um as I already said uh you don't have if you don't have the clearance you cannot go and audit. Um I know uh um unprofessional conduct um conflict of interest, all good reasons um b by which an um an audit um yeah an auditee can refuse to have you Sometimes you also have like um yeah it doesn't click yeah sometimes you you just don't have the glue that sticks you together. That might also be a reason um for an auditee or even from an auditor um to ask a replacement if you feel that you it's not comfortable, it's not working, if you get frustrated from one another, you should take that into account. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S10.2-Initiation-of-the-audit-process.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S10.2-Initiation-of-the-audit-process.md index 45057fd..8172fbe 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S10.2-Initiation-of-the-audit-process.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S10.2-Initiation-of-the-audit-process.md @@ -12,6 +12,8 @@ status: active ## Abstract +This session covers audit feasibility assessment and the determination of audit duration and scope. Feasibility depends on access to information, auditee cooperation, available time, team competence, and cultural factors. The ISO 27006 employee-count table for determining audit days is explained, ranging from five days for small organizations to over 28 days for large ones. Audit objectives per ISO 17021-1 must confirm ISMS conformity, effectiveness, and identification of improvement areas. The distinction between ISMS scope and audit scope is clarified, and the session explains how scope changes during an audit should be documented and communicated to the certification body. + ## Transcription When you're appointed as a lead auditor, you first of all need to determine the audit feasibility. The audit feasibility is very important because it gives you the reasonable assurance or the reasonable confidence that the audit objectives can be achieved. So how do you now come to that determination of feasibility? So you need a couple of things that you need to consider. So first of all, you need to check, okay, what is the information that we need to plan the audit? Do you receive the necessary information to really plan and conduct the information? Do you have everything available? Secondly, you also need to check okay what is a corporation from the audites part. You need to have as an audit team full access to the information related to the ISMS. So for example, if an Audit refuses to give you access to, for example, firewall configurations, claiming that the information is too sensitive, it would be impossible to check the control. So it is recommended, of course, you usually have a confidentiality agreement. It might also be the case that sometimes you can do background checks. I haven't I I ha only have a couple of uh customers where I need to do a full uh security clearance, but that's based on legislation. In all other um areas and some countries it's not even allowed To do a full um criminal records um background checks. Usually the confidentiality agreement is enough. But you can also state that sensitive information can only be accessed on site and when somebody from the audity uh team is uh represented. Um you also want to check um to the proposed length um of the audit. Uh if um sometimes you get into a situation where you think okay I don't have enough time uh to perform the audits. So you need to check that as well. So for example at the ISO 2706 on which certification bodies need to be certified requires a maximum of five-day audit, of which three needs to be held on site. In a research and development company, in the pharmaceutical sector sector, it would not make sense um and it should not be uh accepted. So depending on um how big the organization is, the complexity of the processes, you need to check do I have um enough time do I have um enough time to check if everything is implemented accordingly. Of course you also need to have a look at the competence of the audit The audit team leader needs to be sure that everybody is part of the audit team has the right competences, has the right interpersonal skills to feel comfortable to conduct the audit. And then lastly, you also need to have a look at the cultural aspects. Do you have an issue with the language, with the social background? That might also be an issue, of course. Again, I want to reiterate here, resources also include adequate access. As an auditor, you need to have full access to whatever you want to check. Now how long should an audit last? It's not something that certification bodies um can come up uh with um out of the blue in the ISO 27006. There are tables that help you with deciding how long an audit should last. So that also means that if you compare audit firms as certification bodies with each other Um it's um you won't see a difference in audit days. Uh usually the audit days are the same, price will be different. um reputation will be different um but um basically there is a table that is used and a certification body is allowed um to use um a couple of um indicators like complexity of systems, um outsourcing of uh systems Um is it a combination audit that will give them extra parameters to either uh reduce or increase the number of days? But In the in the basis, the table that is shown on the slide gives you an indication on the number of days. So number of employees, if we look at the ISO 27001 column, which is the third one If you're an organization between one or ten FTEs, you will receive a five-day audit, of which three days will usually be on site. From 11 to 15, it goes up to six. If you're 176 to 275, it will be 14 days. And it goes up all the way to 10,700 where an auditor comes and lives with you for a month. So what usually happens when you have like uh days like 28 or 10 um you usually um get uh because that it's that is per person. So usually uh the people um get divided so that you don't have four weeks the same person in the company, but you get like two or three or four audit uh auditors that visit your company So um the basic thing here is that certification bodies um need to give uh enough time to auditors to complete the audit. So the time available will depend on a couple of things. So you have the basic table, but then certification bodies also look at what is the scope of the management system, what is the complexity. What is the field? For example, in a ho in a healthcare sector, it might be a different complexity. Are there multiple sites that need to be audited? Um what is uh the complexity of the technology? Are you using one technology stack or are you using multiple uh technology stacks? What are um outsourcing uh services? Um what are any regulations? Um Um or loss that needs to happen. So as I stated, at the minimum time for an audit is five days per person. So that means that usually you have like half a day that you use for uh planning and auditing. You have one day that you do the phase one or the stage one which is the documentation audit. You will have three days to do an on-site audit and then half a day to do the drafting of uh the final process. So um that means that an auditor performing an audit um on their own um must in five days conduct everything so do the opening and the closing meeting, they do need to do the interviews, they need check the documentation. So that becomes uh that's a pretty challenging task. Um so um the auditor must use time wisely and that's why they only uh focus on key processes. So you won't be able to see everything. So that's the reason why you need to focus on the key processes and the critical systems that you want to audit. Now looking at the audit objectives, they need to be stated by the certification body So usually a certification body uh creates um um audit objectives for ISO 27001 audits that might be different from a stage one and a stage two, but the audit objectives are there to verify. If the ISMS conforms to the requirements of the standard. Also to check if the ISMS is effective in meeting their intended results. And it's to check if the organization can reach their information security objectives. based on their own criteria. So having those audit objectives in place is your first step of course to start your audit. Now looking at the audit objectives, ISO 17021-1, class nine dot one dot one dot too gives a little bit more information about that. So the audit objectives really need to describe what is accomplished by an audit and needs to include a couple of things. So there are four things that need to be included. So first of all, needs to include that there is a determination of the conformity of the client's management system or parts of it with the audit criteria There needs to be a determination of the ability of the management system to ensure that the client meets all statutory, regulatory, and contractual requirements There needs to be a determination of the effectiveness of the management system to ensure that the client can reasonably expect to achieve the specified objectives. And of course, there needs to be, as applicable, an identification of areas for improvement to the management system. So that's usually what is stated in the audit objectives. If you look at an audit report That's usually stated on the first page. Besides that, the audit scope will need to be determined. Also, ISO 17021 Uh gives there some uh insight. The audit scope will describe what are the boundaries of the audit and what is the extent, what is the the boundary like what are the number of sites, what are the organizational units What are activities and processes to be audit? So the audit scope is something different than the scope of the management system. So the ISMS scope is probably more broader Then the audit scope. It of course the audit scope needs to be consistent with the audit program and also with the audit objectives But it doesn't necessarily include all of the organizations processes and products which may be covered by the ISMS. So if we look at an example, it might be that in a bank, for example, that for auditing the overall activities of a bank that has like a head office, four processing centers um a couple of regional offices and uh a multitude of branches um that for the audit scope we would all only um visit the head office One data processing center and only five regional office and twenty-five branches, for example So that would mean that you will not would not need to visit all the sites and all the branches because that would be become very expensive And that would also mean that it would take a lot of time to do that. So the audit scope is not necessarily the same as the ISMS scope It's usually a little bit um uh smaller than the ISMS scope, but it needs to be in line with the audit program and the audit objectives We'll have a look at the audit scope. So it might also be so you he will he or she will look with the audit tee at the audit scope and to see if there need to be any changes made when they're on site. So it might be that you determine an audit scope and you come on site, you d conduct a couple of interviews and you come to the conclusion that basically the audit scope is not completely correct And then the other team leader needs to have a discussion with the client. So what might that, for example, be? For example, the ISMS scope wasn't really clear at the beginning of the process and while doing the interviews it becomes more clear. There are recent changes in technology that have not been communicated. There have been an acquisition that has not been communicated. Or there might be something happening, for example, like a fire that yeah. And forces you to change the audit scope. Whenever that happens, those changes need to be documented in a clear way. And of course, the certification body also needs to be informed So there are a couple of things that then can happen if you uh if uh the auditor and the auditee don't agree on the change of the audit scope, there are two possibilities. Either continue with the audit as in the initial scope or state that you stop the audit and that you withdraw with the audit because it's impossible to complete the audit. So there are two things that you can do uh in that instance. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S10.3-Initiation-of-the-audit-process.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S10.3-Initiation-of-the-audit-process.md index 5139849..352fdc6 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S10.3-Initiation-of-the-audit-process.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S10.3-Initiation-of-the-audit-process.md @@ -12,6 +12,8 @@ status: active ## Abstract +This session covers defining audit criteria, establishing the certification agreement, and the initial contact with the auditee. Audit criteria in an ISMS audit consist of ISO 27001 clauses 4-10 and the organization's own ISMS requirements, including policies, procedures, and controls. The session discusses challenges when auditing small organizations, where segregation of duties and documentation sophistication may be limited. The certification agreement formalizes audit dates, objectives, scope, criteria, and responsibilities. The session also explains the content of the engagement letter, initial contact with the auditee, and how the audit schedule should be structured and shared in advance. + ## Transcription When looking at an audit, you need to define the audit criteria. So in management systems, the audit criteria are really the requirements of the standard against which the auditee wishes to obtain certification. coupled with other requirements that the audit T has determined. So in an ISMS conformity assessment audit, the following audit criteria are used as a reference against which conformity is determined. So, first of all the requirements of ISO 27000 as defined in clauses 4 until 10 And then on top of that, the relevant ISMS requirements that the organization has set for itself. So that can be expressed in processes, procedures, controls, relevant policies, and so forth. So that will be used of course with whatever is being audited. So the audit criteria is really an essential part of the auditor because that is the checkbox or the reference check that the auditor will do to determine the conformity. If a non-conformity is being declared, it is always based on specific audit criteria So sp all any other additional criteria, audit criteria may come out of internal policies that you put, any laws of regulations, contracts that you've put. But mainly clauses 4 and 10 and then every other control that the organization has deemed part of the ISMS. Now when you perform audits in small organizations that sometimes poses a challenge. Um so That also means that um sometimes uh auditors um are used to auditing big organizations, so uh we tend to be used to very sophisticated management system or um very sophisticated record management systems. While in small organizations that is often not the case and it's not even preferable or desirable because it will overc um uh complicate uh things So in small organizations it's also d often the case that one person at the segregation of duties is a little bit more difficult in those small organizations. So it might be that um owners or managers uh control all the decision making processes but also intervene personally from time of time So what we also see happen a lot is that all the or that at least in small organizations the owners or the managers are not fully aware of their responsibilities and those of auditors. So it it it's very important to have that clearly state. Stated before the audit, the only thing that you also need to consider there is that if you're working with an audit team that might pose a challenge because you cannot um yeah you're you're talking to the same people and people cannot duplicate um so you need to take into consideration that um yeah you have a limited set of people you can talk to Documentation can be less sophisticated and of course the manager takes a very uh prominent uh role in that. The certification body will agree in the end on the terms and conditions of the audit. It will be agreed upon in a formalized certification agreement. It's in best interest that both parties sign this to understand or to avoid possible misunderstandings And the certification agreement documents and confirms the acceptance of the audit, also the audit dates, audit objectives, criteria, and scope. So it's a very important um document because it really has that objective uh of the certification agreement that is the clear communication of responsibilities also to the top management How is that usually done? It's usually just a contract like everything else, which states very clearly what will be done. Sometimes I see it also for the three-year cycle, so it's dependent from certification body to certification So, what is included in the certification agreement? The certification agreement generally includes the audit objectives, the audit scope, the audit criteria, but also the responsibilities of the audit stop management, ensuring that they are present when the audit happens. It also stipulates the unrestricted access to information and other resources. It also has usually an agreement concerning the planning and the conduct of the audit and of course the basis of the fees and other types of invoicing, how it is calculated, what is included in audit time, what is not included in audit time. So a certification body should only accept the audit, of course, um if they've also done a check um to the auditee um to check if um the audit has is uh the check of the integrity, the reputation, and those kind of things. You might also think about including Um for example, uh if you have any technical experts that need to attend um the audit, you might also uh think About that, you can also think about reference to other agreements. But usually the certification body has like a template for that where everything is included Now looking at the audit mandate, so there are a couple of steps that need to be undertaken in accepting an audit mandate So first of all, the certification body looks at all information regarding previous annual reports. Of course, you're going to check as a certification body Is the Odity able to pay all their fees? Will it be uh is it a financial strong organization? Secondly, you will ask information about the integrity of the potential Auditee You, if possible, want to check with previous auditors if there are any inconsistencies in audit procedures and you would also check if there would be any violation of um applicable regulatory uh requirements if you would accept uh the audit. So those are uh the things that you uh need to do Now the audite usually contacts the certification body uh themselves because they're looking uh for an auditor. But prior to the initial contact with the Audite, the audit team leader will prepare an engagement letter and send it to the Auditee. So the engagement letter um is basically um a a letter that states hey I'm your uh lead auditor I'll be coming uh to visit you um these are the dates um perhaps he can he or she can ask to have uh um a call to just get acquainted before you um end up on their doorstep on the day of the audit. So that might be uh the thing. So uh the really that initial contact is really to get a better understanding about um the oddity about the customer to understand how um do they want to communicate You want to introduce the team members as well. You want to check that the audit schedule is still okay, that they don't have any wrong dates in their calendar. Potentially you can also ask access to the documented information. Um you also want to check depending how the organization is set up, uh where do you need to park your car, how do I need to access the building, those kind of things. And if there are any observers or any other, for example, auditors in training, if you bring them along You might introduce that as well. So it's really a first contact with the auditee to get acquainted and to inform them about everything that will happen in that audit The audit schedule is of course important both for the audit team as for the audit tee because there need to be people available. So the audit schedule is basically the list of actions that will be done during the audit and link to that uh when it will be happening. So what usually happens I usually uh make an Excel spreadsheet, I divide it in the hours and I tell them um Yeah, what process or what team that I want to talk and which controls or uh clauses I will be discussing about. So um the audit schedule needs to reflect basically the importance of the activities. It's crucial uh to prepare that time uh that schedule based on the time that you have available while of course optimizing the effectiveness and efficiency um of the audit. So to be to have an efficient audit you need to provide the audit schedule uh before you start with uh the audit and before you arrive on the um audit. Usually certification bodies have like internal processes as well that uh state that you need to provide the internal audit schedule or the audit scheduled to the customer six weeks in advance, for example, in order to give the auditee enough time to indicate which resources should be available if people are on holiday that they can be uh backed up by somebody else, but also indicate if something wouldn't be possible so that you still have enough time to change the audit schedule. So again, a pretty um long section. Um so before let me summarize a little bit um before accepting the audit mandate, the auditor receives an offer from the certification body The process of accepting the audit mandate helps in avoiding any misunderstanding that may arise during the audit. An audit offer generally includes the audit objective, the scope, the criteria and the duration of the audit, but also the team members if they're already known and the responsibility of each team member, but also the limits of the audit engagement and the auditors' payment. For each audit, and also in the case of joint audits, the certification body appoints one audit team leader. There can only be one audit team leader who is responsible for conducting the audit until its completion. In management system audits, the audit criteria are comprised of the requirements of the standard against which the Auditee wishes to obtain certification and any other requirements that the Auditee might determine. The certification body and the auditee must agree on the terms and conditions of the audit, and the audit objectives must be defined and the audit scope must be validated before the audit starts. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S11.1-Stage-1-audit.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S11.1-Stage-1-audit.md index 975483c..430a0e8 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S11.1-Stage-1-audit.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S11.1-Stage-1-audit.md @@ -12,6 +12,8 @@ status: active ## Abstract +This session explains the objectives and steps of a stage one audit, which focuses on the design rather than the effectiveness of the ISMS. The stage one audit, typically conducted two to four weeks before stage two, involves reviewing documented information, assessing site-specific conditions, and evaluating whether the organization understands the standard's requirements. On-site activities include familiarizing with the location, meeting personnel, observing technology in use, and planning for stage two. The session also explains how to evaluate documented information across three criteria: content completeness, format consistency (version numbers, author, approval), and document management procedures. + ## Transcription So in section 11 we will be uh discussing the objectives and the steps of a stage one audit. We will go over the steps in detail. In addition, this section includes also information on how to prepare and to conduct the on-site activities and among other things how you should review documented information and their types. So let's dive into it. Let's have a look what the objectives of a stage one audit are. As you all know, an ISO 27001 audit by a certified body is separated into two stages. Stage one and a stage two. So during the stage one audit, the auditor does not yet verify the effectiveness of the management system in place but it's design. So basically the auditor will only check the effectiveness of the management system during the stage two on-site audit to validate whether the documented processes exist and are effective and also comply with the standard requirements. So what is the stage one audit then about? So first of all, the auditor will have uh a look and will review the audities management system documented information. That's why it's also um often referred to as a documentation audit. So it really the auditor really looks at what has the organization documented. The auditor will also check for any site-specific conditions that the audit D has put in place. During that stage one audit, the auditor will also review the re or the uh the oddity's understanding of the standard requirements. He or she will gather information regarding the scope of the management system and also have already a look at the preparation for the stage two audit. So um it's really to get an understanding on how many sites need to be visited. What are the resources that need to be in place for the stage two audit in order to really get insight on a good planning for that stage two audit? And finally, the auditor will also check if an internal audit and a management review have been executed, have they been performed and planned in the way as is necessary for the standard Stage one audit steps. The stage one ideally takes time in between two or four weeks before the stage two audit. It depends a little bit on what the organization requires as well. Sometimes even a stage one and a stage two can be performed separately, but usually there is two to four weeks in between the stage one and the stage two audit. A stage one audit should not be too far from the stage two audit either. So usually it doesn't go over the 12 weeks mark and that's really the the the biggest time lap that can between can be between a stage one and a stage two audit um and that's done because uh you don't want any uh changes uh man happening in your management system Of course, that the design that you've reviewed is not necessarily reflected in a stage two anymore. So it should also be conducted far enough apart so that you have time to prepare, of course the on-site audit plan, but also to give the organization some time to work on areas of concern that has been identified during the stage one Usually 30% of the total audit time is spent on stage one audits. Um, and um usually I I prefer to do the stage one audit on site because you get a good feeling on what um yeah the audite's organization look like but um a part of the um stage one can also be performed remotely but it it is um a common practice that you do it on site To get that feeling of the organization. However, the review of the documented information of course can be done either at the audit site or remotely. So both are an option there. So, when looking at the approach at the audit program management, we're at phase two in the stage one audit. As you can see, there are three activities that need to be performed there. So we need to prepare for the on-site activities. We need to conduct the on-site activities and of course we need to document the output of the stage one audit. Looking at the preparation of the on-site activities. So The reason uh for having that um preparation there is of course to ensure that the objectives of stage one can be met and the client will be informed about um any on-site activities that will be happening during uh stage one. So first of all, the the audit team should carry out a general review of the documented information that the organization has in place. So what will they be looking at? They will be looking at the information security policy, obviously, any operational procedures, an asset inventory. Awareness or training sessions, previous audit reports. There is also a general review should be conducted to evaluate whether the documented information is current Signed and dated and of course consistent. So all the documentations should be updated, should have an owner, and so forth And this helps, of course, to give uh the auditor a systematic and structured approach when uh he goes through the audit. So as I stated previously, in determining the interval between phase one and phase two, you need to take into account that you need to give some time to the organization to resolve any areas of concern And yeah, it might also be that you decide to postpone the stage two audit based on the areas of concerns that you have identified in your stage one. So if that happens, of course, it might be that you need to redo parts of your stage one audit, but when that happens, the client will obviously be informed. Usually the interval is also determined not only on the areas of concern that you might have found in the audit, but it's also associated with the availability of auditors, of course, to take on the audit. So you've conducted, you have set down a planning, you did the review of the documentation. What are you going to do when you're on site? So you're going to do in general four steps or four things. First of all, you will um have a look at the location and site-specific conditions of the audit. Um so the auditor uh should make himself familiar with the location in order to assess better at the risks that are related to the specific conditions of the oddity. Also you should also get as an auditor information on security rules regarding hygiene, health and safety in the workplace. understanding that if there is any use of personal protective equipment when necessary. You also want to understand that if you wanna uh if you are conducting a stage two, you also want to understand if that's necessary as well for you when you're conducting this Stage two. Secondly, you want to make contact with the personnel of the Odity. So it's the first um instance. Well, basically, it's the second time that you have contact, and the first time you uh Send the auditee uh an email or a confirmation letter that you will be coming along. But this time you're on site, you're having contact with a lot of different people within the organization So that moment in time is really necessary to understand that people know about, that they are involved of the scope and the objectives of the audit. In addition to the presentation of the audit team, it will give you also a great opportunity to see if everybody has been well prepared, if they have the right motivation. And you can also already get a little bit of a feeling on how the organization is structured, what is the culture within the organization. So it will give you a good feel about the organization. You will also be observing the technologies that your audity is using. So during the internal the first stage audit, you will not go into the very uh detail of the technologies that are used. But you will be able to observe already based on the documented information, based on the interviews that we're having, you get a little bit more used, you get a little bit more familiar about the technologies that the Odity is using And in general, you will also observe the operation of the ISMS. And that will help you as an auditor to better evaluate the risks. To the specific context of the audity. It will be helpful to prepare any audit plan and any test plan for your stage two audit, obviously. So during that stage one audit, um there are a couple of things that you uh need to validate. So uh you need to validate um Mainly the scope of the management system and the audit. You want to understand what are the legal constraints, what are regulatory and contractual requirements. You also want to uh talk to top management to ensure that they understand what their responsibility is. You want to have a touch point with key interested parties and you want to do the stage two uh audit planning So during that stage one audit, you will obviously not talk to as many people as you will do in a stage two. So you will have some interviews with key interested parties. So the goal of the objective of those interviews is not really to collect evidence like you would do in a stage two audit, but it's more to validate the compliance of the management system with the standard requirements and to understand basically to get insight in the context of the organization and how that management system responds to them So usually uh what happens, and usually you talk to two to three people and you talk to the person who's responsible to the ISMS because they can give you an explanation how the management system has been set up You always talk to somebody from top management to understand their reasoning behind wanting to obtain a certificate. You want to understand if they um really get uh a grasp of their responsibility and usually um you also talk to the internal auditor to to to check if uh internal audits have been uh performed Of course, if you have an uh a stage one audit that goes over a couple of days, that sometimes happens when you have a huge organization, then you will of course have interviews with other people like HR, like an information security manager, or perhaps somebody who's responsible for the physical security, uh, also to get a better understanding of how things are being arranged within the organization. A very important part of that stage one audit is the review of the documented information. So, documented information, if we look at ISO 1911, class 6. 3. 1 gives a little bit more information. So it states the relevant management system, documented information of the audity should be reviewed in order to get gather information. to understand the audite's operations and to prepare audit activities and applicable audit work documents, for example, on processes And functions, and it will also establish an overview of the extent of the documented information to determine possible conformity to the audit criteria and detect possible areas as concerned, such as deficiencies, omissions, and conflicts. So three things that you basically add the documented uh read the review of the documented information will review in three main things. First of all, you get a general understanding of the function of the management system. You understand how each process is integrated with each other, how you best audit it. It's good to have an overview of that general process overview. You will be able to do an evaluation of the management system design as well as the related processes and controls Um so to check if they are compliant with the standard and of course you will um be able to check if the internal audit and the management re review have been conducted. So uh those are really important um points that need to uh be checked and of course while while reviewing that documentation The auditor checks if the documentation is complete, if it's up to date, if it has been approved, uh, if it's consistent across all the documentation. to see if there are references to other uh policy documents or other processes that it is in line with whatever has been discussed. So, what are now the criteria for evaluating that documented information? So, first of all, three criteria that needs to be followed. So, it's the content of the documented information. the format and the procedure of the of managing the documented information. So let's have a little bit of a detailed look. So content of the documented information, of course an auditor needs to check that the document contains the information that is required by the respective clause of the standard. Obviously that's the purpose of the document. However, the documents may contain only the minimum information required, not everything that the standard specifies. The criteria for the auditor are not the best industry practices, but the minimum requirements specified in the standard. So the standard is leading, so whatever is Written in the standard that the organization shall document should be in the document. However, the organization is free to add any additional information where it deems applicable. Secondly, we look at the format of the documented information. So the auditor must ensure that each piece of the documented information is conform and standardized in terms of format. So there needs to be an identification of the author, uh the production data, there should be a version number, perhaps the approval. Sometimes I also see data classification, the process that it links to. Very important there is when determining in 7. 5 in the clause that the organization determines what the process is for the documented information and that is of course what you want to follow but at a minimum you want to see of course the title a version number the author and the approval Thirdly, you wanna check the um to check if there is a procedure for managing the documented information. And you wanna check if that is in line with the requirements of the standard, and you wanna see that there is a process in place. that documents get reviewed and updated \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S11.2-Stage-1-audit.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S11.2-Stage-1-audit.md index a6b4e3d..41413d9 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S11.2-Stage-1-audit.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S11.2-Stage-1-audit.md @@ -12,6 +12,8 @@ status: active ## Abstract +This session covers the four levels of documentation reviewed during a stage one audit: strategic documents (scope, policy, objectives), risk management documentation, process and procedure descriptions answering who/what/when/where/why/how, and records serving as evidence of conformity. The session explains how to verify the internal audit program and reports, including checking auditor competence, audit plan coverage, and follow-up on findings. Electronic document management is also addressed, covering access arrangements, retention policies, backup, and IT resource adequacy. The stage one audit output documents areas of concern that could become nonconformities in stage two, giving the auditee time to address gaps. + ## Transcription Now, what type of documents need to be audited? So it's um there are um actually four levels of documentation that can be audited So on a first level, which is also called the strategic level, which is anything that has to do with the governance framework. So the ISMS scope The objectives, the policy, any other strategic documentation, that is basically where you want to start first as an auditor because it will give you the general overview And you basically go uh you dive deeper into detail um along the way. So after level one you go to level two uh two, which is um information that is um yeah basically related to risk management so it is the documented information on all the processes and the controls. So it really describes the why, what, how, when, by who. So it gives you that description of the process. At third level, you go to the individual processes and procedures where you check from okay how in detail are procedures being performed. And then on a third fourth level It's really the records where you um have any supporting documentation, the evidence of conformity happens uh there. So basically um starting with the governance uh framework, looking into the risk assessment then looking at all the different processes and procedures, and then checking for the evidence. That's basically the the strategic approach or the structured approach that an auditor should take to really see the um the linkages between the documentation uh within an organization. The auditor must validate, of course, that the documented information includes records that demonstrate the audite's management commitment. To the establishment implementation, operation, monitoring, and of course the continual review update as well. So that means that the strategic documents need to have um a couple of um central things in there. And it's all related to whatever decisions have been taken, any approvals that need to be taken. So the ISMS scope is of course something that the management team has been involved with. So you look at that You look at the information security policy, it's also a policy that top management needs to create and needs to sign and communicate to the organization. So you want to have a look at that Risk management at a risk acceptance and the risk evaluation criteria is something that stopped needs to sign off on. So you want to ensure that you have a look at those as well. the resources um uh that are um meant to implement the ISMS so people, money, uh consultants, you wanna uh check that and of course The management review and the internal audit program are uh two documents, two uh elements that uh should not be forgotten to verify if the management system is in place. So second step is of course after the risk assessment, so it's basically the third step, you want to verify the processes and the procedure So the processes and procedures need to give you information on what is happening in the organization. So basically they need to give you an answer to the five Y's and the One H. So Who, what, when, where, why, how. So that means, and you see an example written out on the slide. So that means that you need to, in some way or another, need to Detail that in the organization, but you can do that in different formats. The standard doesn't tell you that you need to use a physio diagram to do that. So you can use that in basic text formats, you can use an Excel spreadsheet, you can use Visio. So you can use whatever you have available in the organization and what is used in the organization to work with to create these processes and procedures. The auditor must also verify if the documented information related to the internal audit demonstrates that the auditee has implemented a planned and structured approach. um towards the audit program and that it meets the requirements of the ISO 2701. So the auditor will um We'll have a look at a couple of things. So um first of all, um the auditor wants to see any documented information related to that internal audit program. So Based on the ISO 27001 requirements, an organization needs to have an internal audit program available which really defines what is the frequency that you will do an audit What are the methods? What are the responsibilities? What are how does reporting work? So that must be sufficiently documented to have evidence basically of that implementation. So you need to have something written down The auditor will also look at files of internal auditor. With files meaning that checking that the internal auditor has the correct competences to execute the internal audit So that might be a resume, that might be a training plan or an annual evaluation. So anything that can attest to the competence that is required to perform their mission. The auditor will have a look at the internal audit plan to check that the audit plan covers all the ISMS activities That the internal audit program has detailed out that they are planned for the duration of the certification. So in this case that's three years. So it's best practice that it is conducted for three years. Of course, will the auditor also look at the internal audit procedure to see that there is any documented information available that gives information to the internal auditors on how they need to perform audits and that it's done in the same way? They will have a look at the report, and that's the very important document. So they will have a review of the internal audit report so that to see what has been found in the internal review. So at before going to a certification audit, you should have at least one internal report. So one internal audit report should be available. And it is of course best practice to have done the internal audit for the full scope Of the ISO 27001 or at least the full scope where you're implementing it for. Documentation of the audit follow-up activities Of course, if there were any non-conformities, observations, areas for improvement, they should be documented in a good way. There should be a follow-up plan or action plans. So the auditor will also have a look at those to see if you've done anything With the findings out of the internal report. So the internal audit is a very important document, a very important process that will be verified during the stage one. During the stage one audit, the auditor will also determine to what degree an auditee uses electronic documented information. So you should reach an agreement on how an auditor will get access to that documentation. So it might be that you give the auditor access and some instances you get a guest access. To go through the document management system. Sometimes you need as an auditor a little bit more explanation. So what needs to happen is that an audite gives you, of course, all the explanation um the not too many permission rights as so viewing rights um and of course give you detailed information on how you can uh walk through the documented information management system So of course, um auditors for an ISO 27001 should be competent in the use of IT um infrastructure and development trends. So, you need to have as an auditor a minimal practical understanding of general trends, of course, in technology development Auditors should pay uh in particular uh attention to development, technological developments in their respective area and how these innovations might be used in their work. So being up to date in any document management system or an electronic document management system uh is something that you would probably um do best in in gaining some access. And most commonly used is of course uh SharePoint uh confluences of these worlds uh but um asking some explanation is good uh thing to do. Of course you want to review that electronic uh documentation and so um it will depend on of course if The audity is able to make that information available either through a web-based application or through email transmission, but it will also be dependent on technical and security factors. So the audit approach here is of course dependent. And so during an on-site audit, the auditor's responsibility will be basically to oversee the physical location of the audited process. So in case when a document management system is applied, the amount of time required to confirm the evidence in order to validate that the requirements are being met may be dedicated to a computer workstation where the document is stored and which may not be located near the actual process. The actual auditing time at the physical location may then be reduced, where you can spend your time in reviewing the documentation in another part. So that is of course very important In using an electronic document documented information, of course, you also need to have a look at um yeah what is the format that the organization uh uses it. Is it plain text Is it HTML or the PDFs or their Excel Excel? So there needs to be suitable measures in place to protect those electronic documents as well, because it's much easier to change an electronic file than it is in an in uh in a paper-based file so you need to have a process in place or you need to check as an auditor if there is a process in place for the uh the review, the publication, the distribution, and the disposal of that document management uh system. So having um having a look at that electronic documentation um either separate in a separate document review sometimes we do that as well and that we spent one full day to review all the documented information and that might be done off site because you can access uh somebody's SharePoint from uh from a remote location. So that is uh basically uh what you uh should do. Lastly, of course, when you um evaluate uh the audities controls of the retention of that storage media, so you should also check okay what what is the time uh what are the retention periods that documents stay in the organization, um how what do they do with archived documents? Um how is backup uh done? How do we ensure that there is enough storage capacity? Um so It might be uh that um and because there is a lot of um where used to be everything used to be uh written down on paper nowadays A lot of electronic documentation is available. So the role of IT becomes more and more critical. So um in relation to that electronic document management system, an auditor should also check If an organization has allocated enough resources, enough IT resources, so that means both people and infrastructure to make sure that the system operates effectively and without interruption. So, and that also goes to looking at the competences of the people that are working with that. So that electronic document management system is becoming more and more important in every organization Of course, after you've done the full stage one audit, you need to create stage one audit output. So that a stage one audit report is usually shorter than a stage two audit report. And an auditor should at least document observations that run can result in nonconformities during the on-site audit. Means that you can write down as an auditor areas of concern That could be classified as a non-conformity during a stage two. So stage one doesn't necessarily need to meet requirements of a full audit report So in in um any case and when there are major nonconformities detected during that documentation audit The organization or the auditee should make time available to do the modifications to the management system and submit the correct documentation also to the auditor to ensure that you are ready before the stage two So it might happen that there are some big gaps that need to be closed, and then an auditor will ask you to either send the documentation or to set up a Teams call or some remote meeting. To check if you've closed the gap in order to successfully succeed with the stage two. So, in summary, the purpose of a stage one audit is really to review the overall design of the ISMS. The main activities undertaken during an on-site visit on a stage one audit are the evaluation of the auditee's site-specific conditions. Contact establishment with the personnel of the Audity and the observation of the technologies used and the operation of the ISMS in general. The main objectives of reviewing documented information are to get a general understanding of the function of the management system. To evaluate the management system design as well as the related processes and controls, and of course to verify if the internal audits and the management reviews have been conducted Strategic documents should include the ISMS scope and the ISMS policy, the risk evaluation criteria, the resources for the ISMS operation, the management review, and the internal audit program. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S12.1-Preparing-for-stage-2-audit.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S12.1-Preparing-for-stage-2-audit.md index 941b352..9bced3a 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S12.1-Preparing-for-stage-2-audit.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S12.1-Preparing-for-stage-2-audit.md @@ -12,6 +12,8 @@ status: active ## Abstract +This session covers preparation for the stage two audit, including planning, work assignment, and use of technical experts. The stage two audit evaluates ISMS implementation and effectiveness, verifying conformity with ISO 27001, operational controls, and the organization's ability to manage the ISMS. An audit plan must be established prior to stage two, agreed upon by all parties, and adapted based on audit risks and conditions. Work assignments should align with team member competence, and the audit team leader should brief team members clearly and avoid micromanaging. Technical experts must be agreed upon in advance, act in support of rather than as auditors, and communicate findings only through the audit team leader. + ## Transcription Hello everyone, thank you for joining me. This is section 12, preparing for a stage two audit. We're going to talk about setting the audit objectives, planning the audit, assigning work to the audit team, preparing audit test plans, and preparing documente information for the audit. So in this section, we're to discuss the preparations for the stage two audit, including the steps for planning the on-site audit, assigning work to internal people or internal audit people. And preparing the audit test plans and documented information. It's also an assumption that if you don't know what stage one is, then you should re-review that section before you continue down into stage two But I will uh elaborate a little bit more in relation to stage one during this process. So here's our uh uh preparations for stage two. We're gonna plan the stage two audit We're going to assign work to the audit team. We're going to prepare audit test plans, and then we're going to prepare the documented information for the stage two audit itself. So the stage two audit objectives is to evaluate the information security management system. And what when we evaluate, we want to make sure that uh we meet some requirements or the auditee does That we want to make sure they conform to the requirements at 27,001. And when it's conforming, that means truly conforming. So there's no non-conformities And if there is something that they're not going to conform to, then they have to explain exactly why. It's not applicable. We also want to make sure it's effectively implemented. And then we also want to make sure that uh this we're enabling the organization to reach its in information security objectives. So the purpose of the stage two audit is to evaluate the implementation, including effectiveness of the client's or auditee's management system. The stage two audits shall take place at the site of the of the client. And now you should understand with the pandemic, a lot of audits were done remotely, all of them. Uh and that's that's totally acceptable, uh it seems nowadays that uh if there's no on-site activities. However, if it is on-site, it shall include Auditing of at least the following information and evidence about conformity of all requirements to the applicable management system standards or other normative documents like policy standards procedures And again, you're going to do this whether it's on site or not. There'll be performance monitoring, understanding Like how many people took uh computer security awareness training, how many people passed the phishing exercises, all that good stuff. Also the ability for the client to manage the ISMS Can they manage it or can they or did they just have the ability to implement it but with no actual management? So it's important to understand that once uh the ISMS is implemented, They ha they have to manage it, they also have to prove that they can manage it. So that would be the operational control of uh processes and so on. So 3. 1 plan the stage two audit. This is out of 17021-1, clause 9. 2. 3. 1. The certification body shall ensure that an audit plan is established prior to each audit identified in the audit program in order to provide the basis for agreement regarding the conduct and scheduling of the audit activities. So the audit plan will facilitate the flow and coordination of on-site activities during the stage two audit itself. The audit team leader then will prepare an audit plan that serves as a basis for the agreement between the certification body, the audit team, the auditee, with respect on the the stage two portion of the audit. And again, Stage two generally involves uh interviews. Sometimes it's on site, but uh there's gonna be a lot of interviews, but it all it could a lot of it could be remote. The audit plan should be reviewed and confirmed by the certification body and auditee before starting the stage two audit. It's actually very important to understand that for a variety of different reasons. Almost any framework that you are going to be an auditor in, that statement is going to be a requirement across all of them. Whether it's 27,001 or 42,001. Any objections by the auditee should be resolved between the auditee and the auditeur or audit team leader In order to revise the audit plan to where it's uh easier for the auditee to accept. There any revised audit plan should be agreed upon all the parties and communicated to the certification body before starting uh the stage two portion. It's important that proper scheduling, proper awareness proper communication uh to make sure that stage two audit uh goes pretty smoothly. The audit plan itself, 1901, clause 3. 6 That is the description of the activities and arrangements for an audit. So the audit plan must be adapted based on the audit risks that were identified And the particular conditions of the audit. So, for example, if it's a multi-site audit, it's an integrated audit or a combined audit, duration of audit, audit scope. Who's going to be involved, get interviewed, all sorts of different risks that could come into play. The audit team leader should ensure that the audit plan is sufficiently flexible to allow for modifications. In fact, if you're going to be an audit team leader, you should plan on incorporating flexibility because I can promise you your plan is going to change. That will be something that comes into play. So preparing for the audit plan, the audit plan shall be appropriate to the objectives and scope of the audit. The audit plan shall at least include or refer to the following objectives, criteria, scope, including identification of the organizational and functional units or processes that are getting audited. the dates and sites uh for on-site activity uh and so on but now if it's not on-site there should be certainly dates and times for uh uh virtual meetings, virtual interviews like over Zoom or or something. Expected duration of the on-site audit activities Roles and responsibilities of the audit team members and accompanying persons such as observers or interpreters So it's super important to understand and as the auditee, you definitely want to make sure that you have a good plan on when people are going to show up on site. A lot of different reasons aside from the standpoint of efficiency of the audit itself, but also from safety of human life. You want to know how many visitors you have on site if there's an issue of some sort So the audit planning steps confirm if the certification body on behalf of which the audit is being conducted has a designated template for this purpose. In most cases, certification bodies have all the templates you need. You just have to be provided them. And no certification body is the same as any other certification body Plan the audit activities by focusing on the processes and controls of the organization, not the clauses of 27001. So uh you don't have to follow in relation to auditing, you don't have to follow the clauses uh chronologically in order. What you should do is figure out what does the company, the auditee, do figure out how you can uh inspect those uh that activity and align them with the clauses. Involve or consult the auditee where possible Incorporate the outputs of the stage one audit as well as part of the audit planning. And again, the stage one audit, that's the first 50% of the overall audit In the stage one audit, uh you'll be asked, or as auditor, you will ask for administrative controls like policy standards, procedures, statement of applicability, uh things that can be emailed as evidence like computer security awareness training records um and so on all right 3. 2 assigned work to audit team this is out of 17021-1 clause 9. 2. 2. 1. 5. The audit team leader in consultation with the audit team shall assign to each team member responsibility for auditing specific processes. Functions, sites, areas, or activities. Such assignments shall take into account the need for competence and the effective and efficient use of the audit team, as well as different roles and responsibilities of auditors. or auditors and training or technical experts. So again, as it said in other some other sections, don't uh assign work to an uh somebody on the audit team that is not competent enough to perform that work. And it's absolutely acceptable to have uh technical experts. If you're going to have auditors in training, then you should realistically ensure that they have some sort of oversight by an actual certified auditor. Changes to work assignments may be made as the audit pro uh as the audit progresses to ensure the achievement of audit objectives. I have seen cases where say it's a three-person audit team Uh two people are faster than the third one, and then the work assignment from the third one starts to get offloaded to the other two people. in order to uh uh just uh be more efficient and and save uh you know time. So in order to make sure that work assignments Are allocated properly, the audit team leader should obviously we talked about need for competence. Make sure that people are fully competent to perform whatever work assignment is assigned to them. We also want to make sure that the team leaders uh fully brief the team members on what uh needs to happen. So don't say, for example, if you're a team leader, hey Bob, I need you to go do this, but not explain exactly what this is. It may also be a good idea to say, hey Bob, I need you to go check the antivirus on uh you know these five computers um and then make sure that bob back briefs bob the auditor back briefs the uh team leader on on what he has to do. Yes, I understand. I'm gonna go check the antivirus on these five computers. So we want to clarify and validate responsibility for uh work assignments, things like that. Now in relation to uh managing the actual team itself, um if they're certified people uh and they're on the audit team, then they should know what to do. It should be very little micromanaging involved. So you you really realistically want to avoid micromanaging your audit team. Give them they're certified in auditing, so give them the flexibility of doing their job. Having said that, at the end of the day, you're most likely or you should have a meeting with everybody on the audit team just to make sure everybody's on the same page There's no surprises or no obstacles or anything. But definitely avoid micromanaging. Using technical experts 17021 clause 9. 2. 2. 2. 2. Technical expert steering and audit is uh is absolutely acceptable. It just needs to be agreed upon by the certification body and the actual client uh prior to them showing up. So a technical expert does not act as an auditor on the in the audit team. They help to come up with uh evidence or provide an opinion, but they're not actual auditors. Technical experts can provide advice to the audit team for the preparation or planning of an audit, but they're still not auditors. So the audit team leader should evaluate the professional competencies of everybody on the team, as well as the professional competencies of the technical expert themselves. So this could be in evaluating professional certifications, memberships in some sort of professional body uh experience based on you know past experiences that uh the the expert may have objectivity uh ensuring that they are not in a compromise position because they are uh Auditing or supporting an audit team that is working with an auditee that possibly the technical expert has helped before, and so on. So we want to make sure that it's very objective. If the auditor is skeptical about the competencies or objectivity of the expert, then they really need to discuss their concerns with the certification body. And find another solution or find an um a possible solution. Audit findings or comments made by the technical expert should be communicated to the auditee only through the audit team uh leader or other members of the audit team. Uh we don't want the technical experts to make comments directly to the uh oddity because that could skew some of the answers or skew the perception or skew the professionalism and ethics of the overall uh environment. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S12.2-Preparing-for-stage-2-audit.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S12.2-Preparing-for-stage-2-audit.md index a60e759..514ddd3 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S12.2-Preparing-for-stage-2-audit.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S12.2-Preparing-for-stage-2-audit.md @@ -12,6 +12,8 @@ status: active ## Abstract +This session covers the role of guides during the audit, preparation of audit test plans, and documented information requirements for stage two. Guides facilitate access, logistics, health and safety, and scheduling, but auditors should be mindful that guides may relay information to the auditee. Audit test plans use procedures including observation, interviews, document review, and technical verification. Documented information for the audit may include checklists, sampling details, and interview guides, and must be protected as confidential and retained as the audit team's property. Checklists are beneficial for structure but should not intimidate auditees or substitute for proper planning. + ## Transcription The responsibilities of a guide. So this is 17021-1. Uh clause 9. 2. 2. 2. 3 Each auditor shall be accompanied by a guide unless otherwise agreed to by the audit team leader and the client. Guides are assigned to the audit team to facilitate the audit. The audit team shall ensure that guides do not influence or interfere in the audit process or outcome of the audit. So, guides help facilitate audit activities, maintaining logistics, ensuring that health and safety policies are observed, witnessing the audit process on behalf of the auditee. As somebody who's done audits, I really enjoy having a guide from the auditee being there and available because they cut through what I call the red tape They uh they make it easier to accomplish the audit itself. They can make people available that you normally wouldn't have access to. They can get you into areas that uh you normally wouldn't get into All sorts of different things. So I'm a big fan of using a guide at every possible opportunity. They can also do scheduling They'll uh they'll basically be your personal assistant to schedule uh audit activities uh while either virtually or on site or or whatever. But it's also important to understand that as auditors or people on an audit team, those companies that you're auditing, they're responsible for your well-being, your welfare while you're there. So it's important if you're going to audit somebody that the auditee know how many people are showing up, where are they going to be at, what are they going to do, uh, and so on. There might be a case where it's uh it's an industrial environment and uh The uh guide is gonna make sure that everybody puts a hard hat on or safety glasses or or something. But there's also the case that What if there's a fire in the building and the and the guide is there? The guide would be responsible for making sure that the audit team got out safely. Then there's also witnessing the audit process on behalf of the auditee. This is certainly true. Um, and I have seen situations where the guide basically acted as uh off-the-record surveillance for the auditee. And as comments were made around the guide, then the guide would run off and tell the auditee, hey, this is what Carl said. This is what John said, and so on. So if you're gonna have private conversations about the oddity itself, then just make sure that the guide is not there. Because you don't want to influence, you don't want to make a comment that the guide hears, gives to the auditee that could possibly influence the auditee in a wrong direction Or put the audity at risk. So unless there's something absolutely critical, just keep it to yourself and understand that everything you say around a guide is probably going to go back to the oddity within a few minutes. All right, preparing audit test plans. Following the development of the audit plan, the audit team prepares the test plans. Test plans involve the use of several audit procedures such as observation, interviews, documented, information review, analysis, and technical verification. Since the audit team cannot validate all the elements of the management system, the processes and systems to be tested will be selected based on their materiality. Audit test plans will be explained in detail in the following sections after this after this one. Knowledge of auditing techniques is a prerequisite for understanding the means of creating effective audit test plans. All right, prepare the documented information for a stage two audit. This is out of 1901 or 6. 3. 4. Audit team members should collect and review the information relevant to their audit assignments And prepare documented information for the audit using any appropriate media. Again, media could be paper, could be digital, could be anything All right, so the documented for the audit can include, but not limited to physical or digital checklists, audit sampling details. or audiovisual information. Audit team members should prepare the work documents that will serve as audit records. This could be interview guides, meeting records, checklists, sampling results, and so on. The audit team must maintain their work documents until the end of the audit. Afterwards, the documents should be archived or destroyed. As I said in a previous section a lot of audit certific certification bodies once once they've evaluated the material and agree that certification should be awarded then they they actually destroy uh any any sensitive documents or or notes from the audit team It's important to ensure that protection of all work documents during the audit because they may contain confidential information of the auditee. It's also important to understand that work documents That are created by the audit team are the property of the audit team, not the client. So if if I take personal notes or I work with uh uh other people on my audit team But we're just documenting our observations or things like that. That is not the property of the client. So the client cannot demand that that information get turned over. Principles of maintaining audit work documents, so consistency and standardization, accuracy and timeliness clarity and conciseness, completeness, authorship and review, and then confidentiality. So working backwards, confidentiality is obviously keeping whatever you write or your thoughts of anything written down as secret. Authorship and review. So there's going to be people creating work documents, but there should be reviews and collaboration on those work documents as well If we're going to create a uh start creating a final audit report, then we definitely want to have some sort of review. Completeness, make sure every single thing that is relevant to the control or anything else is absolutely all there that people don't read it and go, what does this mean? Uh because you've skipped the step in in uh explaining it. Which again goes to clarity and conciseness. We don't want to write a bunch of stuff in our work documents that are confusing to understand that some other team member can't figure out what we're talking about. Accuracy and timeliness. So audit work documents should reflect the planned tests and results in an accurate manner. Documents about the timing of the work carried out should be provided And then consistency and standardization. So auditors should maintain consistent writing by using standard formats in Work documents. Again, the certification bodies are most likely going to have templates and you just have to fill in the details, fill in the gaps. But if we have consistency and standardization, it's going to be easier to understand and review the documented information itself. So continuity will be promoted when an auditor takes over a work that has been initiated by another auditor because it's consistent in exactly using the same template All right, checklists. There are pros and cons. So the advantages of checklists help keep objectives in mind. It creates a structured and standardized audit approach. Helps guide the auditors, it saves time during the audit and facilitates record keeping. But there's also some downsides to this It can appear to become a rigid frame. So less flexibility. And remember I I indicated in another section that uh while you may have a plan and everybody agrees to the plan, you should also uh be very flexible in relation to the fact that the plan may change uh you know later into later on in the actual once the audit started. Disadvantages of checklists, it should not be used as a substitute for audit planning Subject can be too limited or maladapted to identify the important processes or controls. And it can intimidate those being audited. I've actually seen this before where uh people get intimidated. They feel like they're being interrogated or uh being interviewed by the police or something. Um so we we just want to make sure that we're not intimidating the auditees. They're under a lot of stress as it is. With what they're doing, what they have to do, how much money they pay just to have people there. So we don't want to create a situation where they're intimidated or feel that way. And you can understand that uh in relation to checklists, some of the items could simply be out of scope, so you might not even do them, even though you have a checklist. Implementation of a documentation standard. The team leaders responsible for establishing a standardized documentation procedure. Most of the time, uh there that will be provided to you by the certification body itself. So the documentation standard usually involves guidance on the following aspects: language to be used, which In a lot of cases it's going to be English, but uh make sure you're aware of your countries and your certification bodies requirements Media to be used. So are you going to use some sort of audit software? Are you going to use audit templates? How are you going to do it? Are you going to just use a sheet of paper? Use of abbreviations. Again, not only use of abbreviations, but making sure that the auditor's version of an abbreviation is consistent with the auditee's version of what that same abbreviation means. And then documentation of audit evidence. Alright, and this is the section 12 summary. So the purpose of stage two audit is to evaluate the implementation and effectiveness of the auditease ISMS. The audit plan should be reviewed and confirmed by the certification body and audited before the stage two audit is initiated. A key factor in ensuring a successful audit is the selection of competent and professional individuals to be part of the audit team. The involvement of technical experts can help in filling any potential gaps in the audit team members' knowledge or qualifications. And lastly, the audit team leader is responsible for establishing a standardized documentation procedure. Much like the other ones, there is a quiz for this section. So be sure and do that on your own. I will see you in the next one. Bye. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S13.1-Stage-2-audit.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S13.1-Stage-2-audit.md index cc91b31..f119ff2 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S13.1-Stage-2-audit.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S13.1-Stage-2-audit.md @@ -12,6 +12,8 @@ status: active ## Abstract +This session covers the stage two audit, which evaluates the effective implementation of the ISMS against ISO 27001 requirements. Stage two focuses on risk assessment consistency, control implementation, top management commitment, performance monitoring, and traceability of policies to evidence. The session explains the opening meeting, which must be formal with mandatory attendance logged as evidence. The audit team leader conducts the meeting, introduces participants, confirms objectives, scope, criteria, audit methods, communication channels, and logistics, and sets expectations for findings handling and the closing meeting. Stage two only proceeds when sufficient documentation from stage one is confirmed as compliant. + ## Transcription Hello there. Thank you for joining me. This is section 13, stage two audit for the ISO 27001 Lead Auditor course. In this section, we're going to talk about conducting the opening meeting, collecting information, conducting audit tests. Determining audit findings and nonconformity reports, and then performing a quality review So this section is going to elaborate on the elements of the stage two audit, including the opening meeting, the collection of information, the audit test, and quality review. Stage 2 audit, this is out of 27006-1 clause 9. 3. 2. 2. So, based on the findings documented in the stage one audit report, the certification body shall develop an audit plan for the conduct of stage two. In addition to evaluating the effective implementation of the ISMS, The objective of stage two is to confirm that the client adheres to its own policies, objectives, and procedures. To do this, the audit uh shall focus on uh various aspects of the client's uh environment that we'll talk about in a minute. So again, if you don't remember stage one, that's basically where the auditor asks the client or the auditee for various pieces of information like policies. standards, procedures, objectives, statement of applicability, training records for computer security awareness training, and so on And they evaluate all of that information, all that material, all that evidence to make sure it's sufficient in compliance with 27,001. And if it is in compliance then stage two is possible. However, if material is delivered or provided to the auditor uh for stage one and it's not in compliance or they just simply don't have it, then the odds of a stage two even happening are are pretty small. There has to be, in order to do a stage two, there has to be the material to justify the stage two And uh if there is no material, then it's it's not really in the best interest of anybody to do a stage two that's going to guarantee a fail. So to do this, the audit shall focus on the client's assessment of information security related risks. The audit shall also ensure that the assessments produce consistent, valid, and comparable results if repeated. So again, from the standpoint of risks, we can qualify risks, we can quantify risks. I like quantifying risks because I can put a number to it. And if you quantify it, then you can do math. You can figure out equations, percentages, and so on. Qualifying risks That has to do with like a high, medium, and low, and that's really the perspective of whoever's reading. Determination of controls based on the information security risk assessment and risk treatment processes Information security performance and the effectiveness of the ISMS, evaluating these against the information security objectives Correspondence between the determined controls, the statement of applicability, the results of the information security risk assessments, and the risk treatment process and information security policy and objectives. They are also going to care about top management leadership and commitment to the information security objectives. So this could be done in a variety of different ways, but top management support is absolutely critical. For an ISMS to function as well as passing. Implementation of controls taking into account the external and internal controls and its related risks and the organization's monitoring. Measurement and analysis of information security processes and controls to determine whether controls declared as being implemented are actually implemented and effective as a whole So again, just because the uh the auditee says that a control is being implemented, that doesn't mean it's actually being implemented. That's really up to the auditor to also agree. Programs, processes, and procedures, records, internal audits, and reviews of the ISMS effectiveness to ensure that these are traceable to top management decisions And information security policy and objectives. So again, once they have a policy, they have uh of various types, uh, they they have to be able to show that those policies are being um are being followed and that there's evidence to show that the the whatever activities that the company is doing can be directly connected to a policy as well as ensuring that top management is aware of those uh policies and the ISMS in general, and that they have some sort of decision-making uh evidence of some sort of decision-making Process that supports the ISMS in general. So audit program management. So in the stage two audit, we'll conduct the opening meeting, we'll collect information, conduct audit tests. Determine audit findings, draft nonconformity reports, and conduct a quality review. So conducting the opening meeting. So out of 17021-1, clause 9. 4. 2 A formal opening meeting shall be held with the client's management and where appropriate those responsible for the functions or processes to be audited. So who is going to be in this meeting? The audit team, uh, key persons involved in the ISMS and the clients management. What Introduction of the audit team and the audit activities to be taken. Where in a suitable environment. It could be in a conference room. It could be over Zoom A lot of places are doing all this stuff by hybrid. When first day on the audit site before the collection of information So the other standpoint in relation to who is important, who is actually going to conduct the opening meeting, who's responsible for that? Well, if you're thinking team leader, you're correct. The audit team leader is the person who conducts the opening and closing meetings in the audit. So the purpose of the opening meeting, usually conducted by the audit team leader, is to provide a short explanation of how the audit activities will be undertaken. In relation to the what introduction of the audit team, it's very popular to have each person stand up or just briefly introduce yourself or themselves, but it's also possible that the team leader will just do all of that. So during certification audits, the meetings are expected to be formal, attendance is mandatory, and and has to be retained as evidence. So there will be a uh an attendance log of who is in the meeting. Um depending on Depending on the environment, you may get permission to record the meeting if it's over like a Zoom type environment, but there may also not, depending on the client The opening meeting is considered as a unique and effective way of establishing good relationships between the audit team and the audit tee. And should be arranged in a way that allows interaction. So the Oddity answers all potential questions without hesitation One other person that I think should be brought into any any type of meeting is definitely going to be the guide. Um you while you may have the the audite and the client's management uh involved in the opening meeting It's certainly important that the audit team, if there is going to be a guide involved, that the audit team know who that guide is. And it's always best to do that right from the very beginning. Alright, conducting the opening meeting, this is the actual meeting itself. And this is a um just a suggested agenda. That doesn't mean you actually have to do it this way The following is usually included in the opening meeting agenda. Introduction of the audit team members. So obviously we're going to start with a team leader, then each person on the audit team um briefly discuss the team members, what they do, how long have they worked for the company, uh, you know, it could be a variety of different things. Number two, confirmation of the audit objectives, scope, and criteria. Three, confirmation of the audit plan and logistics. And again, probably around there, you're going to want to make sure that there's a guide that has been identified. From the auditee. Number four, introduction of audit methods and procedures to be followed. Determination of communication channels between the audit team and the auditee. Number six, information on the availability of resources. Seven, confidentiality of information and health and safety matters. Again, uh having a guide there that can make sure that the auditors or audit team is uh not going to be in danger is is going to be uh important. Information on how to deal with potential audit findings. Information on audit findings, feedback, including complaints or appeals, and then information on the closing meeting So this is basically this meeting is going to go through the entire life cycle of the stage two audit and try to alleviate any potential pain points before they become a pain point. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S13.2-Stage-2-audit.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S13.2-Stage-2-audit.md index 88e2d67..394aeca 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S13.2-Stage-2-audit.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S13.2-Stage-2-audit.md @@ -12,6 +12,8 @@ status: active ## Abstract +This session covers information collection, audit testing, and the determination of audit findings during the stage two audit. Information sources include observations, records, system configurations, interviews, and databases. The audit process is iterative: auditors collect information, conduct tests using observation, document review, interviews, analysis, and technical verification, then corroborate evidence types. Audit findings must be supported by evidence and evaluated against ISO 27001 audit criteria. The audit team should meet at the start and end of each day to synchronize findings. A quality review of all findings is conducted before drawing audit conclusions, and any disagreements within the team must be resolved by the audit team leader. + ## Transcription So we're going to collect information as well. So we're going to have sources of information of a variety of different locations or uh where s where information could be sourced from. So observations, we talked about that. That's when the auditor absolutely abs personally observes. uh something. We can have records, whether they be written on paper or digital, system configurations, like reviewing firewall configuration logs or something like that. Other documents could be um could be anything. Maybe it's contracts with a with a uh a vendor, uh indicators of some sort using uh possibly um Uh the only thing I can think of right now would be like a security information event monitoring, which could give an indicator of uh of a log or possibly some sort of other analytical uh aspect Interviews with people. And again, understand that verbal uh evidence is the least reliable in relation to evidence. And then databases and websites, if we're going to uh look at databases or maybe internal or external websites. And again, in a previous section, we talked as it relates to databases. We talked about structured and unstructured databases. So structured databases would be SQL, for example. Unstructured would be like MongoDB. And then for large, very large data sets, we talked about artificial intelligence and machine learning in another uh section. All right, specific elements of the ISMS audit. This is out of 27006-1, clause 9. 4. 2. The certification body audit team shall require the client to demonstrate that the assessment of information security related risks is relevant and adequate for the ISMS operation within the ISMS scope. So in a previous section I briefly talked about qualifying and quantifying risks. Again, qualifying risks means you're Using a high, medium, and low kind of scale, whereas quantifying risks means you're using actual numbers. So nine out of ten we're or ninety percent. So that doesn't mean that you can't use or an oddity can't use qualifying uh uh qualification as a as a method. It's certainly Acceptable. It's just that it may be better to encourage them to not do that. But anyways, however they're doing information security risk and how it's relevant to the ISMS, that's still your job to make sure that they can adequately demonstrate uh uh you know this process. We also want to establish whether the client's procedures For the identification, examination, and evaluation of information security-related risks and the results of their implementation are consistent with the client's policy, objectives, and targets The certification body shall also establish whether the procedures employed in risk assessment are sound and properly implemented. So again, a lot of this goes into the knowledge and competence of the uh audit team themselves to determine if If it is actually sound and properly implemented, as opposed to what the client believes it is So 4. 3 conduct audit tests. So number one, collection of information. During the audit, the audit team continuously collects information that will serve as audit evidence. Number two, audit tests with appropriate procedures. To gather audit evidence, the auditor performs tests by using a series of procedures such as observation Documented information review, interviews themselves, analysis, and technical verification. Then we also have corroboration and evaluation of evidence To establish sound audit findings, an auditor systematically looks for evidence. So we don't stop looking for evidence just because we feel like it's uh completed, uh we may not look as hard, but if we find evidence that's directly related to something else, then we still need to ask questions. In a broad sense, the auditor's work mainly consists of collecting information, conducting tests, and corroborating the various types of evidences uh with each other as well as with the um the control the requirements in 27001 so the activities of you know one two and three there uh illustrate that there's that the whole process is really iterative in nature. So it's a circular, it starts over and over and over. We're always uh qualifying uh the data Meaning that in relation to the iterative part, that the auditors switch back and forth between those steps in order to make sure that the audit's done appropriately So conducting tests can be one of the most important steps in the audit itself, both in terms of importance and duration. So testing could include interviews with personnel involved in the processes and top management to make sure they're aligned. Equally in relation to what they think is going on. Examination of documented, paper information, electronic data to make sure it's consistent. Examination of procedures An examination of procedures could be not only a review of the procedure itself if it's if it's electronic, but if you're on site, you could even say something like, Demonstrate to me how you back up systems and then just literally observe it. And you can say that you observed it personally You can also do a site walkthrough, which could be some sort of physical security audit, as well as evaluating the other physical-related security controls and other administrative controls. Like uh do you have to check in as a guest? Are are you escorted everywhere? Were you given a badge once you uh checked in? So 4. 4 determine audit findings, draft nonconformity reports, and conduct a quality review. So this is 19011, clause 6. 4. 8 Audit evidence should be evaluated against the audit criteria in order to determine audit findings. Audit findings can indicate conformity or non-conformity with audit criteria. And when specified by the audit plan, the individual audit findings should include conformity and good practices along with their supporting evidence, opportunities for improvement, and any recommendations to the auditee. So determining the audit findings is a significant part of any audit. During this stage, auditors can evaluate the evidence gathered during That portion of the audit against the criteria, and then uh and then make a determination. Equally important is the need to accompany the audit findings with their supporting evidence So when the audit is performed by several auditors, the audit team members should meet at relevant stages during the audit to review findings. The audit team leader should strive to resolve any differences in opinion relating to evidence or audit findings within the audit team. So in relation to uh meeting uh regularly, I guess I w I always suggest that uh you have a meeting at the beginning of the day so you sync up on what you're gonna do during the day and at the end of the day you have another meeting to go over what you went over uh during the day. That way everybody's on the same sheet of music, everybody's on the same page. Just understand that the the initial, the meeting in the morning and the meeting afternoon, that should be very private. Only team members should be in that, so no guides from the auditee. You should also understand uh resolve any diff the audit team leader resolving any differences and opinion uh within the audit team. There may be people in the audit team that just simply have more experience than other people and may have a difference of opinion. Realistically, if somebody with more experience has the actual evidence to prove their point, then they're most Probably most likely right. Um but the audit team leader needs to figure that out. The uh it's also important that the audit team leader uh maintain um control of the audit team themselves. Uh I've seen audit team members get in arguments with each other about about something. And it's realistically most of the time it's just one person's opinion, it's different, and they have to deal with it. Quality review. The quality review of audit findings will ensure that the audit conclusions are reliable and valid. So we have our audit findings, they roll into quality review, and then from there we have audit conclusion. The quality review, the audit findings will be explained in detail in other sections. But there should be a quality review. Also, in relation to uh quality review, uh if if it's possible uh having the entire team uh aware of that what the findings are and and uh there's no disagreements on what the findings are. It's always good to have the opinions of other people as a part of quality review. And this could be in a variety of different forms. Not just the belief that there's a finding, but also how uh word products are created And this is the summary for section 13. So in the beginning of the on-site audit, it's recommended to hold an opening meeting. It's not recommended, you must do an must hold an opening meeting with the representatives of the auditee and the person responsible for the operations or processes to be audited. Remember, it doesn't have to be on site. With the pandemic, a lot of people, actually everybody because of the pandemic, we're all doing uh remote. audits for stage two. That doesn't mean that you won't have a stage two audit that's on site. It's just that it's very popular not to do on-site audits now The following activities are included in the opening meeting, introduction, introducing the audit team, confirming the audit plan, briefly explaining how audit activities will be conducted. Confirming the communication channels and identifying potential audit problems or obstacles. The auditor has the right to require access from the auditee to all sources of information related available in order to adequately evaluate the procedures and their conformity to the applicable requirements. So as an auditor, get whatever information you need in order to validate one way or the other if requirements are being met. If a uh if a oddity uh says they're not going to give you something but you deem it to be um relevant Then first off, you need to understand there's a lot of trust placed in you by the auditive, but you also need to understand that could be uh something that requires you to reach out to uh the certification body to basically say they're not giving me all the evidence I need. I know it's there, uh, but I can't see it. They're refusing to give it to me and and maybe discuss with them about a path forward Because that could be a case where logistical changes on audit teams happen. Audit evidence should be evaluated against the audit criteria in order to determine audit findings The quality review of audit findings will ensure that audit conclusions are reliable and valid. And of course, there's a quiz here, but this is a recording, so you'll have to do that on your own time. So go to the quizzes worksheet within the uh uh the material and take care of that quiz. Thank you very much \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S14.1-Communication-during-the-audit.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S14.1-Communication-during-the-audit.md index 442b769..20d8740 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S14.1-Communication-during-the-audit.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S14.1-Communication-during-the-audit.md @@ -12,6 +12,8 @@ status: active ## Abstract +This session covers communication during an audit, including professional behavior on-site, daily team meetings, managing the auditee relationship, and conflict resolution. Key communication principles include using plain language, seeking feedback from interviewees, and aligning on communication channels in advance. The audit team leader should hold morning and evening meetings to synchronize team findings and address emerging problems early. Conflict scenarios with the auditee, including internal organizational disputes, unsuccessful interviews, antagonism, and wasted time, are discussed alongside conflict within the audit team, such as differences of opinion, work attitude, and personal conflicts, all of which are the lead auditor's responsibility to manage. + ## Transcription Okay, so in this section we're going to explore the concept of communication during an audit. We're going to have a look at a few different things, including things to think about when conducting on-site visits, how we communicate both within the audit team and to the auditee during an audit. We'll have a look at different audit team meetings that are important. And we'll also explore the issue of conflict management, both conflict within an audit team potentially, and potential conflict between the auditee and the audit team and how we Try and address some of that. We'll also consider cultural aspects, which is an important part of audit planning and execution, and also how we handle the communication with top management, another vital part of the audit process So let's address the first point here, behavior during on-site visits. I appreciate you're all professional people and some of these things might come across as being sort of relatively sort of obvious things to say in terms of professionalism, there are a few things to to think about. Of course, we want to make sure that if we're involved in an audit, you know, conducting an audit on site, that we do conduct ourselves professionally, you know, making sure we know and follow any rules and policies that the organization might have, particularly around things like health and safety and so forth, making sure of course turning up on time, following the audit plan, you know, just demonstrating that all-round professionalism And that also comes sort of in dress code as well. And part of that is understanding, let's say, the expectations of the auditee in this case. But the big one for me out of all of these is the being a role model so to speak. What we mean by that is the old practicing what you preach, so to speak. So believe it or not, I have seen audit situations before where auditors who are auditing information security come on site and do things like leaving the laptop unattended unlocked or leaving notes on the desk. or using removable media and things like that. The last thing we want to do is be expecting the organization to behave one way whilst doing completely the opposite. really set a good tone. So if anything, I would say that is probably one of the most important points, as well as you know the obvious stuff of being polite and courtes and so forth. Now during an audit there is many ways in which we exchange uh information whether that be between ourselves as an audit team or between us as the audit team and and us as the lead auditors and the auditee And communication can be done in multiple ways, whether that's verbal, in writing, and so forth. And there are a few important points to take into account. account. And one of those is when we're planning an audit we should think about the ways in which we're going to exchange information, particularly with the auditee. So some things I try and agree in advance of any audit is how will I keep the auditee appraised of what's going on? So usually I would recommend at the end of every day, for example, having a summary meeting with the auditee. to explain how well the audit schedule is going. You know, are we on plan? Are there any concerns? If there are any potential non-conformities or issues and communicating those to them. We should agree in advance as well about how things like that are communicated. Also, what if we run into problems during the audit? Whether that be conflicts, which I'll come to a little bit later on, or any other concerns that we might have, how do we report those and in what form? So it's important to think those things through because we want as smooth as possible. interaction. So let's think about the different types of communication that would be valid in an audit setting, starting with verbal communication. Well that's going to form the vast majority of the audit because ultimately as an auditor or a lead auditor or an audit team we're always going to be talking to the auditor. Getting this right is a great way of building those professional relationships. It's a good way of immediately transferring and sharing information. Rather than me emailing somebody and asking for a response, you know, being able to interview somebody and ask them directly about how something works. And of course it's feedback, we can give feedback as we go. Now the only point I would make about verbal communication is from an evidence point of view, verbal evidence is considered the weakest form of audit evidence. In other words, you know, if somebody says to me, you know, yes, we have the following process in place for anti-malware management, for example. That alone is a starting point. That alone is not evidence in that case. In other words, I'd want to then see the process if that makes sense. sense. So it is important that we um we address that. Now one of the things that's really important I find from experience of doing audits Is making sure that the audite is on the same page as you in terms of understanding. What I mean by that is you may well be the information security expert and an expert on ISO 2701. So maybe some of the technical jargon like clause numbers or technical jargon about a particular area of security might be second nature to you It might not necessarily be second nature to the person you're interviewing. So it's always important whenever we're having an interview or we're exchanging information with the audience. Just to make sure we we're speaking in the right level. And if we're using specialised terminology that we explain it the best way we can. We don't want essentially a misinterpretation. If I ask a question and the person I'm asking misunderstands me. So we recommend as much as possible to use plain language, avoiding technical jargon. Now I appreciate if you're in a conversation with a network engineer or a you know a software developer at that point fine you might need to get into more technical discussion but certainly at uh those higher levels thinking very carefully about the term we use. I tend to avoid when I'm actually talking to auditees quoting clause number or control numbers from the standard. For example, I did an audit recently we talked about threat intelligence. And rather than me just saying tell me about threat intelligence, I just kind of explained what we meant by threat intelligence and then allowed the audite to give some feedback Feedback. It can be useful during an audit as well if there's anything complex to present to think about using things like visual aids. So for example, when I'm explaining the certification process Rather than just verbally explaining the steps, I uh I do use the diagrams. Okay, this is step one, this is how we progress to stage two, this is what a re- when a recertification audit happens, for example, we walk them through the process and It is also a good idea as an auditor to constantly seek feedback about whether of course you're being understood, whether you're clear. So sometimes if I'm in a conversation with somebody, I'll say you know one of my bad traits or good traits depending on your view is I'll often say things like does that make sense um you know is that clear uh and I'm not doing that to sort of vindicate myself it's almost let's just make sure um because if it if if i'm not making sense or i'm not clear enough then it's down to me to then re rephrase the way I'm asking questions. Essentially I want the auditee to feel as comfortable as possible, familiar as possible with what we're asking so we can get the best quality answers and Go in the right direction. Now speaking of communication, one thing that a lead auditor really needs to think about is managing their audit team effectively and managing the audit end-to-end. Because ultimately, as a lead auditor, it is you who is responsible for the overall audit conclusion and the report back to the auditee. So this needs to be very well managed. So we recommend if you've got an audit team to have every day two meetings, even if they're small, a morning meeting with your audit. team before the audit starts, maybe 15 to 30 minutes, to talk to the team about what's expected for that day, to discuss any potential challenges or problems that might come up um and so that we prepared. What I don't want to happen is to start the day and have auditors in the team maybe not clear for example about what's ex Or you know, have somebody worrying about a potential problem and they haven't told us about it. So this is the opportunity. Equally at the end of every day, what I always suggest is again with your audit team, 15 to 30 minutes. to get the team round the table or online and to discuss any issues encountered in the day. You know, did the team members who are working on your behalf, did they manage to cover everything? Did they run into any problems? Are there any conflicts or issues? Do they have adequate evidence or a bit of a quality review of any audited items? So for example on a recent audit I had an auditor in the team who during the day had identified something that was potentially a non-conformity, but because in this context I'm the lead auditor that's come from me in this case as the lead auditor. So at that evening meeting the auditor took me through what he believed to be a minor non-conformity, explained why, you know, we both looked at the evidence. And uh in this case agreed that you know his view was correct. And at that point, I then know I can take that to the audite and present it. Um equally, if any of your auditors have run into any trouble, problems, you know, gone off track with the um. The agenda, these are things that can come up because as a lead auditor I want to capture problems early. I don't want to be getting at the end of the audit and find out there's been various problems that I wasn't aware of So make sure you bake them into your audit plan. Now what these meetings and discussions might reveal is potential conflict. And there is two types of potential conflict that can occur in audits and it is down to the lead auditor to deal with these. And these are conflicts with the auditee and conflicts within the audit team. So let me deal with conflicts with the auditee. First of all. So there is a possibility, and I'll go through each one of different scenarios that could crop up. So in some organizations, there can be internal conflict between people Or teams within the organization. And the point here is: as an auditor, I'm not there to referee or indeed to take sides in this case. And I can think of a prime example when I was interviewing a particular um person it was a well it's a CISO it was actually a security team within the organization uh and this security team was still doing a lot of hands-on network management And I I simply asked the question, which was a legitimate question, well how come this is under your team's remit and these you know these firewalls and other devices are not being managed by the you know the the IT team? And then this person basically went into a bit of a uh uh a rant you might want to call it about how incompetent the other the IT team was and how they didn't have capability and one thing or another and how certain individuals should be fired basically and things like this. Now at this point, um it is not my place as an auditor to start commenting on that. I've got to be very careful Obviously the last thing you want to do is show signs of agreement here because the last thing you want to do is create the impression that you're taking a side. You've got to try and manage that. Now in that case, because I I I just kind of changed the subject a little bit, it's okay. Right, I understand, you know, these devices are controlled by you. So now let's go into how that's done without sort of taking it any further. Um so trying to be as neutral as possible is the important point here, no matter what your personal opinion might be. Other situations that can crop up, unsuccessful interviews. So an unsuccessful interview, maybe you've got some time scheduled with somebody and the interview maybe goes off topic, for example, or maybe the person in front of you isn't kind of the right person to answer. those questions. So there's a couple of things. Usually at the start of an interview I'll ask the person I'm interviewing just to describe a little bit about their role. And part of that is to make sure have I got the right expert in front of me? So let's say I want to speak to somebody about network security and maybe I want to Have a deep conversation about that, have I got the right individual in front of me? Because there's very little point in plowing on with the interview, asking questions that the person may be unable to answer because it's not their role or their area of experience. expertise. So you can usually avoid that if you plan properly. Also if you've got an interview which may be going off topic a little bit, you know, the person's talking about something else sort of, you know. tr you're wasting a little bit of time and so forth. It's down to you just to bring it back on track. Now it doesn't mean you have to be unfriendly if the person, let's say, starts talking about the uh you know what they watched on TV last night or the weather or something like that that of course you can manage a bit of that kind of talk but if it's something to go much deeper I'll say something like that's interesting perhaps we can catch up on that over the break or something and bring the the the the interview back on track That's different to deliberate what I would call antagonism or lack of cooperation. So this is a situation where the person you're interviewing, the audite, maybe sort of for whatever reason against being audited or may even be deliberately difficult. Now I'm pleased to say that despite mentioning it in here, that's a rare occurrence. I find most auditees ideal With quite professional and willing to share ideas with you and so forth. But it can happen. And I had a case, prime example of this, was I was interviewing a HR manager because, of course, there are requirements. people controls and I remember interviewing this HR manager and I introduced myself, I explained why I was there and you could see he was obviously very busy and he said to me at this point he said to me I don't understand why I'm here. This this topic's got nothing to do with me. You know, we have an IT team, we implement things like firewall and antivirus and all of this, and we're really good at security, so why am I spending my time in a meeting with you. Quite antagonistic at this this point. And so of course I tried to be as polite as possible. I said, I understand what you're saying. I said, and you're absolutely right. You know, you do have these controls in place but part of the standard also covers uh things like recruitment and managing starters and levers and so forth. That's why we have this session And he wasn't overly convinced and more or less told me, long stuff, long story short, that I was wasting his time. Now at this point, I'm not going to get into a heated argument with this individual. What I actually did is okay, I can see you're busy. Thank you for your time. I'll probably stop that here and move on to something else. Then what I did after the interview is if you have a situation like that or an unsuccessful of you you've got to tell what we call your audity contact. Not because I want to get this person into some kind of trouble or cause any more friction But I've got to explain this because I can't just say, well, the interview didn't go very well and I don't have the evidence, let's move on. What I did was I fed back to my contact at the audit Just look, I've attempted to have a meeting with this particular HR manager. They seem extremely busy. Um, I'm not sure they're too keen to take part in this. Um, can we resolve this? Now that might be by Bringing that person back. In this case they put me on to somebody else in the HR department who I spent some time with and we resolved it. Reporting these things back to the audity as well. Again, it's not about making trouble But it's about a principle in auditing called fair presentation. You know, uh if I just keep that quiet and don't say anything, uh that could cause problems later in the audit. Also, we could get situations of what we call wasted time. You know, what happens if you turn up for an interview and that person isn't there, for example, they don't turn up on time or something along those lines. Well again you can't just leave it. Again you need to speak to your auditee. Maybe the reason somebody's not there if there's a like an emergency situation I can actually observe them dealing with the real-world problem. But whatever happens, any cases like that, we need to reschedule. Similarly, imagine that you've gone for a lunch break and it's taken a bit longer than planned for every We can't just say, oh well, we've lost that working time. It's down to you as a lead auditor to address those problems. And I am pleased to say that despite presenting those, they are uh You know, fairly rare, but you have to be prepared for them. The other type of conflict that you could see potentially is conflict between auditors in the audit team Again, it's down to the lead auditor to have the management skills to deal with this. And some of these I would argue are more likely than others. So the first one, difference of opinion, that's certainly very possible You know, I know some really excellent auditors who would fight like cat and dog over certain things because as we'll establish, for example, determining if something's, let's say, a minor non-conformity or a major non-conformity. Can sometimes be more of an art than a science and comes down to a level of professional opinion. So as a lead auditor, ultimately you've got to oversee that. Now that doesn't mean you need to be arrogant and say, I'm the lead auditor, therefore I know everything. and I'll make the final decision. I do try and listen to people and listen to different opinions, but at some point the lead auditor has to say, okay, based on what I understand, this is the position we're we're going to take. So we try to be inclusive and manage that as best we can. The others I hope are less likely but should be mentioned. Difference in work methods I would imagine should be very unlikely because when you work for a certification body, the certification body usually sets the work methods. They'll lay out the procedures that should be followed. followed, the audit templates that should be used, etc. So it'd be very unlikely that I'm finding auditors arguing over work methods. But again, making sure before the audit starts everybody in the audit team has been properly Trained has access to the right information and is happy with what we're asking them to do is part of that. Personal conflict, well, really I would argue personal conflict between individuals can happen in any workplace. specifically in an audit team and speaking of somebody who in the past was a line manager who had to manage a team I recognize a little bit of this. Again, a bit like the dispute with an auditee. I'm not there to referee personal conflict. It is up to you as the lead auditor to potentially manage that. If there is real conflict, do we separate people. Worst case we could you know remove people from the audit team. I don't advise that unless things are really extreme. But again is about recognizing and managing that situation. If two people really don't get along when let's not put them on the same part of the audit for example And work attitude is a similar thing. Now what I would say about work attitude is when you work for a certification body, whether you're a lead auditor or a co-auditor reporting into a lead auditor auditor, your work performance is actually regularly reviewed. So I think any auditor who really was demonstrating a problem here, this would be hopefully route it out fairly early on but what I would say is it's down to the lead auditor to manage this and I do remember speaking to somebody who was a lead auditor so I was a consultant in this case My client was audited by basically a small audit team and I spoke to the lead auditor who I knew very well after the audit. And he said basically said to me, don't ever work with person X. And he actually named this individual, which I didn't think it was overly professional, but anyway, named this individual, don't ever work with M And I said, what was the problem? He said, well basically, he said, he didn't um write up the audit notes, he didn't finish parts of the audit report, and basically this lead auditor said to me, I had to stay up until three o'clock in the morning writing up his section. Now ultimately that staying up till three in the morning writing his section Was the right thing to do because the lead auditor takes ultimately responsibility. But the lead auditor will also, when they review the performance of that auditor, will hopefully feed that back. But again, I'd like to think those situations are very rare. So whilst we do need to talk about conflict in here, I don't want to frighten anybody into thinking that this is a hostile environment or anything, but yeah, let's be prepared, let's be willing to handle those situations. when they occur and a lot of them don't necessarily come from what somebody like me would say on a training course a lot of this you're actually going to learn through real-world practice real world experience \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S14.2-Communication-during-the-audit.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S14.2-Communication-during-the-audit.md index c4ee830..b0c9e43 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S14.2-Communication-during-the-audit.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S14.2-Communication-during-the-audit.md @@ -12,6 +12,8 @@ status: active ## Abstract +This session covers cultural awareness in auditing and effective communication with top management. Cultural awareness involves understanding local norms, avoiding divisive topics, using plain language, and selecting locally familiar auditors where possible. Communication with top management requires using appropriate business language rather than technical ISO terminology, preparing well, keeping a professional distance, and asking questions that reveal commitment and buy-in without testing technical expertise. Key topics to explore with top management include their role in supporting the ISMS, resource provision, involvement in management reviews, understanding of objectives, and how they gain assurance that adequate security controls are in place. + ## Transcription So one of these things we need to think about in an audit when we're communicating is what we're we call cultural awareness. Now when you first hear that title you might think of uh you know audits which might be multinational you're working in different countries and territories and that's certainly relevant, but even in working in different industries potentially there can be what we call cultural aspects And what we want to make sure of is that we avoid during an audit any misunderstandings or any particular issues. So it is a good idea for auditors if they're going into a different environment to sort of familiarize themselves with that culture. So putting international stuff to one side, just as a simple example, I went in my previous career from working in a financial organization at one point which had a very you know specific as I say working culture to doing some work for a construction company very very different kind of environment with you know different norms and uh different sort of behaviors almost. And of course indeed if you are doing an audit that might um where you might be liaising with people from different parts of the world there may be you know diff different um cultural things in terms of how to be polite or how to behave and so forth. And my job here isn't to teach you about all the different world cultures and how to adapt to them But it's in put two things are particularly important. One is whatever your particular view or perspective that as auditors we have to mean absolutely Absolutely unbiased in the end an audit is a fact-based exercise. So whatever the work culture, whatever your uh feelings are about that, ultimately we're still looking for evidence and facts. And the second thing is when we're thinking about language, especially if we are working in places where you know the people we speak speaking to are you know dealing with us in their second or non-native language, then we've got to be very careful again again about how we explain things to come across clearly to make sure that we're interpreting things correctly that we're getting back as well. So it's just about being prepared a little bit before you engage. And there is some practical advice on the cultural aspects. Usually when a certification body looks to do an audit, particularly one that might be multinational, then this should be looked at in what we call the feasibility study. So the feasibility study will look at the potential problems, the potential uh issues depending on the environment. So that should be sort of thought about in advance. So none of these things should be a surprise by the time we come to conduct the audit. And therefore, of course, it might sound like common sense, but often a certification body will of course try and select an auditor that's familiar with local language or customs and perhaps have a local auditor. And maybe a good example I can give of that. So I work as what we call a co-auditor, so not a lead auditor for a particular organisation. So this organisation is headquartered in the US It has a UK operation and an operation in India. And in this case, what happens is the lead auditor is based in the US because that's where the headquarters of this organization are is. I'm involved to look at the UK division and then there's a local auditor in India who looks at the the division there. And that's quite a deliberate strategic decision, of course, both from a cost point of view, less travel, but also from that familiarity point of view. Not all of us are operating places Where we're quite familiar with the local language, the customs, and it just makes the whole process a lot more smooth if that's possible. Um now, of course, that's not always possible, and if you are in an environment where you're uh you know in a different culture, a different place. Of course it's a good idea for the auditor to try and adapt, you know, learn about that culture, as long as it's not in any way whatsoever interfering with your objective. and your ultimate audit conclusions. And whilst this comment I'm about to make probably comes across as common sense, you know, avoiding as much as you can discussions about topics like religion and politics is highly advisable. Those two topics of course are very easy ways of causing potential divisions. So we always try and steer clear of those at all costs Now one particular important aspect of communication in an audit is dealing with top management. So we've already identified that in the standard there's a number of requirements for top management management to do various things. So this means at some point in the audit you as an auditor are going to engage with top management. Now before we talk about engaging with top management The fact of the matter is there are many different types of senior management and leaders in organization. And the psychologist Kurt Lewin refers to three of them here. Just to mention those, so you get some kind of leaders in organizations who you might call the autocratic leaders. So that is to say uh a leader that pretty much makes the decisions, is very authoritative, is very clearly in charge, you know, you you you're either with that leader or you're not kind of a leadership style. You have those who are much more laid back or at least say the laissez-faire approach where they will kind of uh take a less uh direct role and sort of trust their employees if you like to um you know deliver good value and so forth and those that you might call visionary leaders or democratic leaders those who will still lead but look to bring people with them on the journey a great example remember of that long time ago when I worked with a a bank and we had a new manager come into this particular bank and he sort of set forth his vision about the the future but he was really quite um inspiring if you like and he he would be a prime example in my book of one those democratic leaders. Now you might be wondering why are we talking about this in a lead auditor course? And the answer to that is I'm not here to teach you management styles. Ultimately, in real life, you learn these by working with people in these positions. You get to see the different styles and attitudes. But the point is the more familiar you are with the way in which different senior management operate, the easier it becomes as an auditor to be able to sort of interact and communicate with them. Those senior leaders. So let's think about an actual audit where you would be interviewing top management. We'll get into what you're going to interview them about in just a moment, but first of all, there are some basic principles. We are going to spend time with top management in order to validate commitment. Ultimately, we look at clause five. That's what talks about leadership. and commitment. We're going to see whether top management are fulfilling their various responsibilities according to ISO 27001. Now we use this term that the auditors should use use appropriate business language. What we mean by appropriate business language is phrasing questions and interacting with top management in a manner that they can understand. So I'm not going to go into an interview with top management and start quoting clauses from the standard or using your technical jargon. I'm going to make sure I frame the questions in the right way. And I'll get into some good questions to ask of top management in just a second. But there are a few things to say before I do that When you interact with top management, you might have a limited time frame to do so because top management often are very busy. And the other thing is the credibility of the audit essentially depends on your impression. There's often a saying that you can basically blow credibility very quickly. People make judgments very quickly about uh uh individuals. So what does this mean? If I want to come across as credible, to have a good interaction, I've got to be as prepared as possible. Being prepared in terms of being clear about the kind of questions I want to ask kind of things I want to focus on. Being prepared in terms of understanding things about the organization structure, maybe doing a bit of research about the organization so you know you come across again as credibly in that meeting. Using as we've just said a moment appropriate language. So for example, let's say I want to ask about or gauge whether the top management understand risk. So rather than talking technical risk language, I could just say, so in general in your position, what do you see as the most significant security risk or what what gives you the most cause for concern. Or let's say I was interested in gauging whether they understood objectives, I could say, what value do you think having this management system brings to your business? How is it helping you fulfill your business objective? objectives. There's very straightforward questions like that tied to their objectives and what they're aiming to do. Now where we say keeping a professional distance, what we mean by that is not that we need to be robots or run-friendly, but remember that this is an audit and therefore you know we've just got to be professional. We've got to make sure top management are aware of the amount of time that we need need. Now that should be factored into the audit plan so it shouldn't be a surprise but usually when I start the discussion you know I'll kind of say according to our schedule we've got 30 minutes here these are the things I'll like to cover does that work for you because you know top management are very busy people they won't be too happy with you if you kind of keep them there beyond the time slot um you know so you don't want to do that. And it is a good idea to summarize and confirm the answers. So in other words, let's say your top management have told you about their strategic objectives of Okay, so if I understand you correctly, the key issues of concern are A, B, C, and D. And the reason I want to do that is I don't want to misquote anybody. There'd be nothing worse than reporting back and then especially top management level people Saying, well, that's not what I meant, or you've misunderstood me. I'd rather clarify that during the meeting. So what are the main topics that you're going to discuss with top management in such a meeting. And we've got sort of eight points that are mentioned here. But again, I wouldn't ask them necessarily in this order or use the language that's here. I'd ask various questions around it. So if we talk about leadership and commitment, rather than saying, please can you tell me how you're committed to an ISMS, I might say, can you tell me a little bit about your role in supporting the ISMS? of things do you do? How do you support those people who are running the ISMS? You could ask, you know If the organization needs to fund its security efforts, can you tell me a little bit about how that works? Does that need to come to you? Do you have any oversight on things like spending or investment, for example If we're talking about objectives, point number two, rather than saying tell me what your security objectives are, what I would say is so as I understand it, you've got the following business objective objectives, how does these how does the information security management system help you fulfill those objectives? I wouldn't ask them directly about how they fulfill their requirements under 27001 because they might not know, but I could go on to ask, well what involvement do they have in the security strategy? Do they take part in things like management reviews? What sort of decisions would need to come to them for sign-off? How do they, one of the big questions I like to ask is, so how do you, in your position, have an assurance That the right security controls and processes are in place. You know, do you get briefed on that? Do you have any information? Um, you know, uh, and those kind of things. Uh, you could ask them about roles and responsibilities, so you could say, okay. So who do you see as being responsible for security in your organization? So those kind of areas, if we cover those off well, and we ask the right kind of questions, you can soon gauge in a meeting like this whether there is real sort of top management commitment and buy-in. Now in the end, depending on the the attitude and views of senior management you might get better quality or less quality answers depending on who you talk to but in the end what I'm looking for can I see that top management are providing adequate resources are supporting policy and are taking part in things like management reviews and risk reviews. I'm not testing top management security expertise or technical knowledge It's much more about their buy-in and involvement and are they providing the right sort of tone and direction? And that's what we hope to gain from that kind of meeting. So in summary then, what we've talked about is basically verbal communication in an audit. What we've said is that for any audit we will prepare properly, we will ensure we do our research so that we come up across as professional at all times. We'll always follow the idea of being open and transparent with communication, that in the event of conflicts, whilst not intervening in conflicts, we'll do our best to manage those situations. Obviously report concerns if we have them, remember the principle of fair presentation. We'll always take the effort to understand the culture of the organisation to avoid any misunderstandings make sure we're using language that is non-technical, appropriate for the audience, again so we have a good experience. What we want to make sure of is both us as auditors and the auditees have a positive experience and that what we can extract from these interactions is information to make fair, you know, unbiased judgments on the conformity with ISO 27001 \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S15.1-Audit-procedures.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S15.1-Audit-procedures.md index 4d94d8f..ce97a4e 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S15.1-Audit-procedures.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S15.1-Audit-procedures.md @@ -12,6 +12,8 @@ status: active ## Abstract +This session introduces audit procedures for collecting, reviewing, and analysing evidence. The overall audit process is described: collecting evidence from information sources using procedures, evaluating it against audit criteria, forming findings, and reaching overall audit conclusions. Interview types are covered in depth, including general versus detailed interviews, and individual versus group interviews. Key principles include avoiding leading questions, taking notes, corroborating information across sources, explaining confidentiality, and using open-ended questions. Group interview dynamics such as the bandwagon effect and potential disagreements between interviewees are also discussed, along with differences between in-person and remote interviewing. + ## Transcription Okay, so in this part of the course we're going to explore the concept of audit procedures So audit procedures are activities that we can follow as auditors in order to collect, review and analyse evidence. So we're going to have a look at a few different evidence collection procedures such as carrying out interviews, document reviews, physical observations. We'll also have a good look at analysis and sampling techniques and how we can use those as well as technical verification. And then we'll also look at evidence analysis techniques such as corroboration, evaluation. and so forth. And we'll have a look at something that's become more and more relevant as time's gone by, which is the auditing of what we call virtual activities or virtual locations. And we'll see the considerations to take into account. Those situations as well. So the figure or the diagram we've got here is from ISO 19011, and this gives an overview of the audit process. And what it basically summarizes is the high-level steps in an audit. So let's just talk about some of those and how they relate to what we're about to present. So as an auditor, what are you doing? In reality, you're looking at the audit criteria, the requirements of a standard or requirements of policy or wherever it is you're auditing an organization against And you're going out and you're looking for information, sources of information that you're going to collect using different procedures, some of the procedures we're about to talk about, like sampling, like interviewing. etc. And this information that you gather we would call that audit evidence. And what we're going to do with that evidence depending on how much of it we collect and how we've collected it, is we're going to evaluate that against the criteria. In other words, against the requirements of the standard in this case. to make a judgment, a finding. In other words, a finding is do we think the requirements of the standard are met or not? There's more nuance to that, but at a high level that's what a finding is. And of course, overall, once we've got a series of findings, so let's say I've looked at ISO 2701 and I've got findings for clauses four to ten. and findings for the controls in Annex A, we'd re I'd review that with the team as a collective to come up with what we call an audit conclusion. Now usually in a certification audit that will be a conclusion about whether or not to recommend for certification. There are some other options there as well, but ultimately that's the audit process end to end. So this part of the course we're going to focus on how we gather, review and evaluate the evidence. So we'll talk about the findings and conclusions in later sections, but for now we want to focus on the evidence gathering and review techniques. Now there is something important to say which we'll be digging into a little bit further as we progress through this section, and that is the types of evidence gathering we do can depend on a couple of things whether or not there needs to be human interaction or not. So for example, some evidence gathering techniques of course will involve direct human interaction. I'm interviewing people, you know, doing a document review with the auditee, you know, carrying out sampling, for example, I'm certainly going to need to be interacting with people. Some stuff though doesn't necessarily involve direct human interaction. If I'm doing an offline document review, for example, or completing paperwork or doing stuff statistical analysis of a sample I've already collected. So of course we'd think about that. And we'd also think about the location. Do we need to perform this activity on-site, in person with people, or remotely. And it is now possible to conduct some parts or possibly all parts of an audit remotely And we'll come on to that at the end of this section and talk about some of the issues about conducting remote audits and also some of the circumstances under which we might decide to operate remotely. versus on site. But for now, whether we're on site or acting remotely, we can talk generally about some of these procedures. So what we're going to talk about here are three things. Evidence collection procedures. So these are procedures we will follow to obtain evidence. Evidence collection tools, so in other words techniques and different tools we can use such as sampling and technical verification and then what we do with our evidence when we essentially collect it like corroboration and evaluation and we'll take you through all of these with some examples about how and when you may want to consider using these in an audit context So the first place I want to start is with interviews. Throughout an audit, we'll spend a lot of time doing interviews. interviews, interviewing the audities, employees, possibly third parties, like suppliers and people like this who may be working with the organization. to gather evidence. Now obviously an interview will be a verbal exercise, but then as I'll explain shortly we'd follow that up. Now there are a few basic points I think most people would be um familiar with hopefully already about having an efficient interview. And this stands whatever interview you're doing and whoever you're interviewing and that is we want to make sure when we ask questions we avoid what we call leading questions. or influencing questions. What I mean by that is the kind of questions that lead people to an answer that they think they should give. So let me give an example Let's say I'm asking somebody about their backup procedures and I say to them, okay, let's talk about your backup procedures. Most organisations do incremental backups every day and then a full backup every week. Is that what you do here? If I say something like that, that's a lead. leading question but whether whether or not the organisation does what I've just said I've kind of led that person to believe that that might be the answer I want to hear. So I don't want to ask it that way I'd be far better off asking, okay, can you describe to me your approach to backup? And then of course we can we can do a little bit more digging depending on the answer that I hear We also need to take notes. That goes without saying, unfortunately, at least I can speak from my own memory. I'm not going to remember everything that was discussed in an interview. So we certainly want to take any notes quickly. And it's a good idea to what we call corroborate information. Corroborate information means verify it from multiple sources. So if one person's told me something in an interview, I might want to go and check that fact with another person in another interview. check that fact against documentation. And the purpose here isn't about catching people out or anything like that, but it's about validating have I understood things correctly. Because obviously one person's perspective on something may be different to another and we need to get beyond perspectives but essentially to the facts as best we can. So with that in mind and some of those principles in mind Let's just think about the types of interview that we could have in an audit. And we say there are two: general and detailed. So general interviews are usually where we would look at sort of the the more tactical level or even the more strategic level to understand how a process works. So the example given in here is about interviewing top managers management which is a good one. Another example I could give, let's say I want to understand HR processes, but before I get into the detail, for example, about how HR do a background check, for example example, I might want to have a high-level meeting with the let's say HR manager for example just to get an understanding about the general HR processes in the organisation. And then at some point I might want what's called a detailed interview. So a detailed interview is where we have an interview with a specialist in a given area to sort of dig deeper in that particular topic. So sticking with HR, if I sit down with a HR manager or administrator and I say, right, we are going to have an interview specifically focusing on the approach to background checking. That would be a detailed interview or if I said I'm going to sit down with a software developer to discuss the software development lifecycle in detail. I'm doing sort of a deep dive in a given area. So of course, usually you'll start with general interviews and then when you have the basic understanding the detailed interview would follow. Now when we think about conducting interviews, we could have interviews with individuals, one-on-one, or interviews with groups But let's stick with individual interviews for now. So the purpose of an individual interview is really you can spend time with a single person who will often be a subject matter expert hopefully in the area where we can really go looking for for detailed information on a specific topic. And one of the benefits of doing individual interviews, it's often possible to read body language Often body language can tell you whether a person is comfortable or not or um you know uh how they come across. Now obviously I can't use body language as evidence, I can't write in my report this person had bad body language but it can sort of help you you know understand uh uh the confidence if you like and whether you might want to explore elsewhere for further evidence. If there are sensitive elements of a discussion discussion you can possibly have those in an individual interview. What I mean is there may be things that people are willing to say in an individual interview that they might not feel confident to say in a group setting. So with that being said, one of the things that's important is when we have an interview with somebody, we always explain the confidentiality principle. Now I've got to be clear on how this works. The confidentiality principle doesn't mean that this is a secret interview. Any interview that takes part as part of an audit, the fact that the interview happened Who it happened with and when will be reported that is that is described in the audit notes. So it's not the fact that the interview is happening that is confidential where it is the content of that. We as auditors are not going to record an interview or quote people as saying things without agreement if that may So in other words, somebody, you know, if somebody does say something you know negative about their colleague or about the organization, you know, unless there's a reason that that is that is relevant, that's certainly not going to be repeated out. side of the interview and usually at the start of an interview we'll explain that to the uh to the interviewee. Also the beauty of individual interviews is you can adjust your questions accordingly. So you're not going to just stick to a rigid checklist you can adjust so depending on let's say the backup question depending on the answer I hear then of course I'll reframe my next question accordingly so you can be quite flexible with them. Now one of the challenges though is unfortunately with the best will in the world it's going to be difficult to individually interview all of the time. you don't necessarily have enough time. So for certain topics, it would make sense perhaps to have a group interview where you've got a number of subject matter experts or people together. Now there is a challenge as I'll get to in a moment with what we call group dynamics. But before I get to that It is a good idea with a group interview if you can do it, if there's more than one auditor, to perhaps have a couple of auditors there, one maybe doing the questioning, another for the notes. If you're able to do that. And ideally, you don't want to group more than five people because then it becomes very hard to manage. But with regards to group dynamics, there's a couple of things to talk about There is what I would call the bandwagon effect or strong leader effect. What I mean by that is let's imagine I'm interviewing a group, let's say there's four people in that group, they're all doing a similar job, and I ask a question. Let's say let's stick with the backup thing. Let's imagine these four people are administrators and I say okay can somebody take me through the approach to backup? And let's imagine one person takes the lead and they explain the answer. It could be that everybody else, because of the bandwagon effect, even if what's being said isn't entirely accurate, kind of nod, so to speak, and go along with that strong leader. And so you can sometimes get a false sense of reality through that sort of group think idea. The other potential problem which I have encountered one time is disagreements amongst the group and having to manage the dynamics of that. I remember auditing an organization at one point and they had four system administrators. This time my question was about the leavers process. So can you take me through how you ensure when somebody leaves that their access is adequately displayed? disabled and removed. One person gave me their answer and then somebody else said, you're working on an out-of-date process. That's not how we do things anymore. And somebody else chipped in with a different version of events and suddenly we had this argument going on in the room. Which one I had to manage, but two I kind of drew the conclusion that certainly there's either an inconsistent process or a lack of awareness of that process because clearly you know everybody is on a different page with this. But generally, whether you're interviewing a group or interviewing individuals, there are some uh important points to be made. And Annex A17 in ISO 19011, the guidance document for auditors, says a few things. And I'm just going to call out some of them that I think are particular Particularly important. The first one is as well as verifying that I am interviewing the right person, often when you kick off an interview, it's a good idea to say, can you tell me a little bit about your role and your background? Just because let's imagine I want to interview somebody about firewall management. I want to make sure before I ask perhaps technically related questions, I've got the right person in front of me. We also want to try and make interviewees feel at their ease. So you want to be doing the interviews, of course, during working hours in a place that's comfortable. Comfortable for them. And when I say I want the audit e to be at their ease, this is just about explaining what we're doing and what we're not doing. So I always make it clear: look, this is part of an ISMS audit. I'm looking at processes here and trying to understand processes. I always tell people I'm never commenting on anybody's performance. I'm not auditing the individual or commenting on them. I remember doing a one interview where I met with a person in HR and she kept saying to me after answering the question, she's obviously quite nervous, oh, was that the right answer? And I kept saying that there isn't a right and wrong answer. I'm just trying to get an understanding of how things work. Please don't worry. This is not about you or your role. This is just understanding about what goes on in the organisation. So you do your best to try and put people at their ease. Now of course you're going to take notes. Again that can be quite intimidating to people. So I often explain at the start, look I am going to type up some notes, I'll write things as I go along. Please be assured it's not I'm not quoting you, I'm just capturing notes for my own memory after the event. Are you okay with that? Again explaining that. that. Asking the open-ended questions we've talked about already. These are all important points. Now one thing ISO 19011 does allude to In interviewing. Interviewing in person can be very different to interviewing online. Because when you're interviewing in person in the room, things like body language and tone, etc. , it's often a lot easier to pick up than perhaps it is over a Zoom or a teams meeting and we'll talk about that a bit later on when we talk about remote um you know remote audit \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S15.2-Audit-procedures.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S15.2-Audit-procedures.md index 14fe105..94dd5e2 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S15.2-Audit-procedures.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S15.2-Audit-procedures.md @@ -12,6 +12,8 @@ status: active ## Abstract +This session covers interview preparation, execution, and common challenges during audit interviews. Preparation includes defining objectives, selecting appropriate interviewees, and preparing work documents. Open-ended questions such as show me, tell me, and explain are recommended over closed or leading questions. During the interview, auditors should ask for specific evidence, confirm understanding, and note distinctions between what organizations are doing versus what they intend to do. The session also addresses common problems including unusual responses, auditee attempts to restrict interviewees, guide interference, and unavailability of key personnel, explaining how auditors should manage each situation professionally. + ## Transcription So for any interview of course the key is in the preparation. It makes absolute sense as an auditor to make sure you have time in your agenda to define the objectives of the interview. You know what's the purpose here? Is this a technical deep dive into a topic that I really need to understand? Is this meant to just be a high-level demo and overview of something What are the topics I want to cover? Now I don't need to write out my questions rigidly because the you know we have to have some dynamism in the conversation but what is it I want to cover? Let's make sure I have a look at the in put maybe put an interview plan together. Of course I'm going to select interviewees based on what they do. Now usually this happens anyway as part of the audit planning So usually when I put an audit plan together that'll be circulated well in advance and I'll ask people, I'll say, okay, for this slot, I need to speak to the expert on that. uh you you know on your firewall or on this this lot I need to speak to somebody who does security architecture wherever it might be. Of course we'll have an appointment in our plan that should be there already so everybody should know when we're going to meet And preparing the work documents, this is something we'll walk through later in the course, but a work document is where you record the outcome of these activities. you record what interview you did and you record the salient points, the points that might be relevant in terms of evidence. So let's imagine you are doing an interview, you're about to start the interview, the best way to start is from the common courtesy point of view, thanking the person. for being there. If there is more than just yourself doing the auditor introduction, um I was just thinking of an audit I was doing literally the week week before this uh training delivery and I met so many new people um I almost went into robot mode a little bit with my introductions because every person I had to explain I'm uh where I'm from, uh what the audit was about, but it was important to do that each and every time so that every person who came in understood why we were there. comfortable with it. And we explain the scope and purpose. We describe the points about how the interview will be conducted and we ask the auditee or the interviewee have they got any questions about the process before we start? Is there anything they're concerned about that they want to clean And then we can kick the audit off or the interview off by asking that person to describe their role in the ISMS. Now as we've already said, we don't want to use guided questions. I think I've clarified that bit on already what we say is the best type of audit questions are the open-ended ones you know who what where and when or the best one I like is show me or tell me or explain to me Because if I say, you know, please would you explain your approach to conducting backups, I can leave the the uh the interviewee to really give me a description description um and just sit back and listen. In fact actually the less questions I'm asking in a way the better. Whereas if you're asking things like closed-ended questions, it would just be very difficult to conduct an interview. If I said to the auditee instead, do you have a backup policy? Yes. Do you do backups every day? Yes. I'd say you can imagine that's a pretty painful interview. And you probably won't get to the root of the importance content so open-ended policies far better so as I say the the open-ended ones are always the uh you know the best value so to speak A few other important principles to think about. In the end, if we want real evidence, we do need to ask for specifics. The danger is with some of these topics we can talk in a very general sense, you know, if we're taught, especially with technical topics. topics, you know, people talk quite broadly. So when I say ask for specifics, I say, okay, so you've described generally the principles of background So with system X, Y, and Z, which is in scope, can you specifically tell me how you do that here and actually try and dig into some detail? The more specific evidence I've got, the more likely it is to be relevant and useful. I also want to confirm that information. So again, so just to confirm you've told me A, B, C, and D. I want to make sure I've not misunderstood anything. everything. And paying attention to the meaning of words, what we mean by that is, you know, is somebody if somebody says, well we should be doing ABC That's very different to saying we are doing ABC, for example. So I although it might sound a bit pedantic, I do challenge those kind of things. things again I'm not catching people out right and say okay you've told me you should be doing those things so does that mean you are or it's something you plan to do um that's important to find out And there's a mention here of the familiarity or trust threat, which we'll have gone over in the sort of audit principles. It's important of course to be friendly and approachable during these interviews. I'm not certainly against that in any way. But of course there is a threat in an interview if we let's say have very close trust. or you know that person very, very well, that that can be a threat to independence to some degree. So you've always got to remember, you know, no matter how well you may get on or have a good relationship with that individual, to still be asking the right questions. and challenging where need to. Now equally when we bring an interview to an end, it's a good idea before we end it, of course, within the timeframe, that we ensure have we covered all the questions that we wanted to ask. Give a summary back to the interviewee circuit. The main things we discussed were my feeling is this and be honest. If they have told you something which could could potentially be a non-conformity keyword potentially. I will I will explain that. I'll say, look, I'm having a bit of a problem here. I had an interview recently um where the the audity kind of openly said that there were some controls that they didn't have in place and I was just frank enough with them to say okay Okay, I appreciate you've explained this. This could potentially be a non-conformity in this area because. And the reason I did that wasn't to say, haha, I found a problem. So give them the opportunity to respond. Not to frighten anybody, but let them think about have they missed something? Could they refer me to somebody else? Do they have an opinion on that? So I can then think about the bigger picture. So be honest in that case. If you've agreed during the interview for the auditee to provide more information, like they've said to you, well yes, we have a document on that topic, I'll send it to you, or I'll give you this evidence. Let's recap that at the end. So if I understand you rightly, you're going to send me, you know, the backup policy and the procedure document. Also, you allow the interviewee the option to ask you more questions Questions and of course the courtesy thing, thanking them for their time and their cooperation. Now, before we finish on interviews, there can be potential problems that occur during interviews that might to be tackled that you just need to be prepared for and aware of. Some of these are more frequent than others, but let's briefly look at those. You might hear what you call the unusual or unlikely statement What we mean by that is, as an auditor with experience, when you ask a question on a certain topic, you're quite used to the kind of answers you would get. An unusual or unlikely statement is just something that might take you by surprise So I had a case with one audity and this is the honest truth when I tell it. I asked this system administrator about patch management and vulnerability management and I said, you know, can you tell me a little bit about the way you approach patch management and he said to me oh well that's something we look at when we've got nothing else better to do because that's you don't expect that kind of response response and uh the first thing there is to say okay have i have i explained myself properly um you know can i rephrase it i said okay i said so just so i've got you clear i said what i mean here is that you know with the software on your estate, usually you would review every so often and ensure that any vendor software patches are applied. Do you have like a process for that? And he basically reiterated the same answer saying, well, basically in the end he said they didn't have a proper process for doing it. But it was just that the initial sort of almost flippant response caught me by surprise. So let's just make sure you you um you've got that right. If the auditee wants to pick interviewees that can be a problem. Now just to be clear, obviously when I'm planning an audit I don't know the names of all the people in the organization, so you know often I am saying, okay, I need to speak to the firewall engineer or I need to speak to the security architect, etc. So they will often not pick the employees but they'll tell me who those people are But if there's any reason why the RT is restricting who I can speak to, you know, let's say I want to speak to the expert on security testing. but for some reason they're not there and and everybody else they're putting in front of me doesn't have that knowledge, then it is down to me to deal with that. We do need to go back to the RDT and say, look, it's important that aspect speak to this person or somebody in this role. Remember that when an auditee enters into a contract or an audit client enters into a contract with a certification body, they are making a commitment to allow these interviews to take place. place. So I've never really encountered that. I've encountered situations where I've had audities and might not be the right ones because there was a misunderstanding. Well then we can clarify and deal with that. Interference of guides. So a guide is a person usually appointed by the auditee who usually coordinates the audit. especially on site the guide might be there present during interviews they might be there to help you you know move from room to room in the building or if it's an online um interview facilitate discussions and that's what they're there for. What they're not there to do is interfere with the audit process. And what I mean by that is if I'm interviewing somebody and the guide keeps jumping in and answering questions on the person on behalf of the person I'm interviewing or putting pressure on the interviewee, this would be a potential problem. And again, I have to admit that this is not something I've encountered too too much. But if that was to happen, your first thing is to have a pleasant word with that guide. Just to say, look, I appreciate your help. I know you trent help, but I do need to speak to that. the person directs, I need to get their perspective. If it was such a serious problem, you would have the right to ask the guide not to be present As I say, I've never had to go that far before, but remember as a lead auditor you can and should, where necessary, you know, use the terms and conditions of the audit This case. And if an interviewee is unavailable, we've mentioned this previously already, if you turn up when they're not there, for example, then of course it might be an opportunity to watch that person in action, you know, if they're responding to um an emergency or dealing with a problem you might actually see the real world way in which to deal with it but otherwise we've just got to make sure we readjust the plan we can't simply say well because that person wasn't available at 10 o'clock on Tuesday We've just wrote off that interview. It's down to us as lead auditors to readjust. So these are quite a few things that are important about interviews. One of the most important and regularly used information. Collection procedure \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S15.3-Audit-procedures.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S15.3-Audit-procedures.md index 52a84cc..94b841d 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S15.3-Audit-procedures.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S15.3-Audit-procedures.md @@ -12,6 +12,8 @@ status: active ## Abstract +This session covers document review, physical observation, and sampling as audit evidence collection procedures. Document review focuses on content relevance, version currency, and consistency with verbal evidence. Physical observation allows auditors to witness controls firsthand, including general building tours and detailed demonstrations of specific tasks such as backup testing or access control procedures. Photography requires explicit permission. Sampling is introduced as a means of drawing conclusions about a population by examining a representative subset. Judgment-based versus statistical sampling are contrasted, and multi-site sampling considerations for organizations with multiple locations are explained. + ## Transcription So in addition to conducting interviews and talking to people people. Another common evidence collection procedure of course is to review the documentation of the organisation. And I realise this has been discussed to some degree in the discussion about the stage one audit But just as sort of a of a recap here, we want to review all kinds of documentation from strategic documents like policies and procedures right down to actual records that might be there demonstrating that process is being followed and my main focus in here of course is the content that's the primary thing you know is the document what what is it telling me and does what the document tells me does that marry up for example to what I've been advised in some of these interviews. So let's say somebody verbally described to me the process let's say for background checking new employees, then I could re I could read the relevant procedure and say does it does this match up? Is there a you know mismatch or Is it consistent? I would still be looking at things like format and structure and also document management as well. You know, am I looking at the latest version? Does it look like this document's been subject? to any kind of review or quality control. So all the points that you covered in the discussion on the stage one audit would remain valid here as well. Now, as well as interviewing people and reviewing documents, one of the best in my opinion ways of really knowing what's going on in an organization is the concept of observation. So the audit procedure of observation is exactly that, as an auditor actually witnessing first hand for yourself without interfering in anything, various procedures. And that key term there without interfering is important. You know, we are not there as auditors to interrupt the business in any way. So what do I mean by observation? Well there are things we could ask to see. If there's software updates going on people could show me that happening If somebody is testing whether backup media has worked or not, they could potentially show me how they do the test. I could witness people logging into system. systems to see what access controls they've got or for physical audits, you know, going doing a physical on-site audit, looking at physical security you know, walking around the perimeter of the building, you know, experiencing the entry controls and seeing firsthand what's there are all types of observation. Now there are two types of observation just like there are two types of interview. We have the general observation and the detailed. So general of course is where you're looking at things. at a high level. So if for example I went to an office or a data centre and did a general tour to look at the facilities to understand what was there to observe some of the common physical security controls, you might say that's a general observation. If we are talking about a detailed observation, this is where we might want to see a specific task. In the example here it talks about the auditor witnessing the test of backup media. That's certainly a good detailed observation. An example there I can give, probably one of the most interesting ones. At one point I did an audit of a contact centre. So this contact centre had call centre operators taking telephone calls and dealing with customer inquiries, and that included processing credit card data. And so at the time, because they didn't have an automated system There was a requirement for the contact centre operator to stop the call and pause the recording when the credit card number was coming in. stop those numbers being recorded. As an auditor, what the organisation allowed me to do with authority, with non-disclosure agreements in place, etc. was basically sit with some of those contact centre employees and sort of witness how they did it and get them to just show me when they're handling a call the various screens they use how they log in etc And that gave me a really good appreciation and understanding of the technology and the processes and of course the security controls. that they had in place. All very good evidence to support what they'd told me verbally and what they'd stated in some of their documents. So when in order to carry out observations, when you see things, witness things, have things demonstrated to you, of course we've got to record these, especially if we are going to use those observations. as evidence. And the main way we do this is by taking notes. In fact, that's possibly in most cases the only way. So if I think to an audit I did recently, I did a physical security tour of the building and for each requirement of A7 in that case, I basically wrote the following. I said site two are conducted on X day at X time. The following controls on the perimeter of the building were observed such as, and then I talk about the vehicle barrier or the entry control or wherever it might be so written notes essentially photocopying documents might be one of those in reality uh I've never had the need to actually photocopy a document or take anything away. If there was a reason for doing so, then it is vitally important that you have the written permission and authority of the auditor. to do that. Similarly where it talks about taking photos, videos or audio. Now we've said quite rightly that that's not preferable. It's not preferable for several reasons. Some organizations have restrictions about media like that being on site, especially data centres and places like that, often you're not allowed to take recording equipment. in in the first place. Secondly, even if you are, there's the privacy question, you know, if you're shooting videos or taking pictures. If there's a real need to do so, then again, that's where we require permission. Now the only time I can think of really doing this in terms of taking photographs is when I've done audits that save networks and we've seen network comms cabinets that have been left open or you know badly cabled or something something like that. Sometimes it's easier to say there's a picture of what we've seen rather than sort of writing about it if you like. Sometimes the picture is more impactful, but again there has to be a reason for doing that and we have to have the authority to do so. So we can interview people, we can review documents, we can physically go and observe things or ask people to demonstrate things to us. Another thing we can do is analysis or sampling as it's sometimes called. And I just want to talk you through in this part a little bit about that procedure and things that you might want to understand. So there are controls and clauses within the standard where it's going to be very difficult to see everything everywhere. And therefore, you might, as an auditor, need to make a judgment On essentially a certain part of that process. So we say that analysis is studying a whole by studying its parts or taking a sample that's representative and then making a judgment. off the back of that sample. So we need to first to understand this talk about some principles and terminologies in the world of statistical analysis to be able to explain this. So we have four things, a population, a unit, a variable and a sample. So let's take an example. So the population basically is the set of people, objects, things that you want to see. The unit is each and every item of that population. The variable is the thing that we want to study, the thing that we want to look at. And the sample, of course, is the percentage or the group that we select in order to look for that variable. So we've got the example written in the slide here as an example. An auditor looks at 30 computers in a facility containing 500. So the 30 computers that auditor takes is a sample, the 500 is the population, and each computer is a unit. And in this case, the auditor is trying to validate that that computer has a proper A serial number and up-to-date anti-malware protection. So they're the two variables that that auditor's looking for. So in this high-level theoretical example, what the auditor is going to do when he or she's looked at those 30 computers. Is draw a conclusion. So even though they've not checked all 500, they've checked a certain amount. Now we'll debate about whether that sample size is a good or a bad one shortly, but all this is illustrating is that is what a sample. essentially is and there are controls in ISO 27001 that lend themselves very well to that kind of sampling. So things like competence and awareness In a large organisation, it's unlikely that I'm going to be able to interview all employees about their security awareness. I'm certainly going to have to take a sample. it's unlikely I'm going to be able to check all training records, so a sample would make sense. If we think about asset management in a large organization, let's say the the assets have to have some kind of characteristic like let's say laptops have to have whole disk encryption or you know have a serial number um attached to them like that example again I might take a sample Responding to security incidents. If the organizations have had several security incidents, I might want to analyse so many and so on. Protection against malware, I might not be able to check the malware signatures everywhere, but I might be able to take enough of a sample to draw a view, a conclusion if you like. Access control is another, let's say it's a requirement to be authorised to have access to a certain system. But you know you've got several thousand employees. I won't be able to look at every authorization, but maybe I can take so many to see and feel confident that those authorizations Are taking place. So there are places where we can do sampling. And what we intend to do here, based on the principles of ISO 17021, which are the guidelines for certification bodies. is take you through the things we need to think about when it comes to sampling in an ISO 27001 audit So as a recap, the reason we do this is because we cannot verify everything. And we're not looking to verify everything. What we want as auditors is a reasonable assurance that certain requirements are being made. met. So we're going to take a sample, but we have to look at sampling methods because so far that example you saw was very straightforward. It's a good one to explain what sampling is, but there are different types of sampling depending on statistics. statistical challenges and so forth. So before we talk about statistical sampling, there is another type of sampling that sometimes happens on audits which I have mixed feelings about but we do need to mention and this is called judgment-based sample So judgment-based sampling is where an auditor relies on their knowledge or skills or experience to choose a sample of things to look at. Now, I always say in an audit, especially management system audit, professional judgment is perfectly acceptable and is indeed a good thing You need to apply a level of professional judgment. The difficulty maybe with applying it in sampling is potentially it could lead to bias or confirmation of bias. So let me just give you a trivial example. Let's imagine I would like to look at the security of, let's say, user endpoint devices, maybe like smartphones and laptops and so forth. forth and according to your policy you know these devices should be locked down and controlled and so forth but based on my experience I know that sometimes, let's say, top management might not necessarily apply those controls, might be a bit more flexible in those controls. So I decide to take a sample of devices from the senior management population. Well, in one hand I'm using my professional judgment because I know that might be an area problem, but on the other, I could be accused potentially of not taking a representative sample of the whole organization, you know, maybe targeting a specific group or deliberately looking for non-conformity. So we've got to balance that. If you are going to use judgment-based sample do make sure as in insofar as possible that you've made a fair decision and you can justify that decision So the alternative to that is, as ITO 1911 points out, to look at what we call statistical sampling. And shortly we'll have a look at some of those statistical sampling methods and we'll look at the pros and cons of each. But before we do, there are things that can affect sampling that are important. Context size, nature and complexity of the organization, all of those that are valid. On certain audits, you know, if there's a complex environment, it might not be as simple as the example you just saw a moment ago. You know, taking 30 machines out of 500 and looking at them. Maybe all those machines have different variables. You know, maybe some of them are handling different types of data. So we may need to think about a sample that's representative of the landscape. The competency of the audit team makes a big difference. Do we have auditors who are capable of doing statistical-based sampling The time, you know, there is something we talk about in sampling, especially in internal audit, which is called the confidence level. And the confidence level grows to some degree the larger your sample size or the more areas it covers. But of course you have time limitations in an audit, so that can affect the type of sample you might be looking at looking at um and also how we deal with undesirable effects so there are some things to think about here Now another aspect of sampling before we go on to the different types in a management system audit is what we call multi-site sampling. So what do we mean by this? Well let's imagine the organization that's being certified or going through a certification audit has multiple locations. So I can think of one I work with right now. They've got Approximately 10 offices across the globe. Now when we do our initial audit, it's unlikely that we would visit all 10 locations. We may take a sample, we may look at certain geographical locations and that's what we call multi-site sampling. Now it's not necessarily about the amount of sites that we visit, but it's about the right mix to decide whether the management system is effective. So let me give you an example. This organization I'm speaking about has one large headquarters Another um location that does a lot of software development and then quite a lot of what we call small branch offices that are similar in style and nature in terms of what they deliver. So it makes sense that we will spend a lot of our time at the headquarters, at this development site, and then we'll take a sample of some of those branch offices. enough hopefully to have a reasonable assurance that the management system is working effectively. But we don't ignore the other branch offices. is in the audit following the surveillance audit then we look to visit those as well. But it's not necessarily about the number of places we've been, it's more about having that balance right \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S15.4-Audit-procedures.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S15.4-Audit-procedures.md index c5fb8f7..28aa121 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S15.4-Audit-procedures.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S15.4-Audit-procedures.md @@ -12,6 +12,8 @@ status: active ## Abstract +This session provides a detailed walkthrough of statistical sampling in ISMS audits. It covers seven steps for defining sampling: establishing what constitutes an error, assessing sampling risks, defining the population and its characteristics, selecting a sampling method, determining sample size, evaluating results, and documenting the process. Four sampling methods are explained: random, systematic, stratified, and block selection, each with worked examples using access control and change management scenarios. The IT Governance Institute sampling table is referenced as a practical minimum-size guide. The session emphasizes that sample results must be combined with other evidence before reaching audit conclusions. + ## Transcription So we need to make sure though as auditors if we're going to do sampling and we're going to base an audit finding off the back of a sample that we can demonstrate that we've done what might be called adequate sampling Sadly, however, ISO 17021, ISO 19011 does not say adequate sampling looks like this. Here's the number. Now if you work in other audit fields like financial auditing, for example, often there are precise formulas that you're required to follow. Things like stop-go sampling, things like um confidence and coefficient levels and so forth. I'm not going to go into these here, not because we don't want to talk about them, but they're less relevant in a management system audit context. But if you're doing wider information system auditing as part of a financial audit, this may be something you want to explore. What I'm going to present here is the the different types of sampling method and the sampling process. So we're going to sort of walk you through this. So we've got seven steps in terms of defining what qualifies as an error right through to documenting the sample process. So we're going to step you through these seven pieces step by step to explain the key points here. So the first thing we want to do when we think about it sampling is Define what we might consider an error. In other words, something that might affect the audit objectives. That's your first step. So if we see this example here, so it says the following. An error in sampling is an ISMS audit could occur if the auditor selects a sample of employees for verifying conformity to clause 7. 3 on awareness, but the sample is not representative of the workforce. So in other words, if I pick somebody out who's not actually doing the same job as somebody else, for example, you know that could be potentially an error or I pick somebody out who's not an actual employee but maybe who's a freelancer or something like that we might get the wrong picture. So we would define what could potentially be an error in this case before we start. We also want to think about the potential risks. What's the chance of perhaps not seeing the full picture, picking on the wrong areas and so forth? Now this is important and a big potential risk is in areas where you don't understand the landscape very well. So let's take a hypothetical scenario Let's imagine I want to look at the security arrangements, maybe let's say authentication, for an for applications. And I simply pick on a number of software applications that your organization uses. Now if I don't understand the fact that some of them have differences, I could run into a problem But what I mean by that is let's imagine there are some software applications that deal with highly sensitive information and some that deal with commercial information. They may have different security settings because of the kind of data they handle. If I don't know the difference between those and I just pick random uh applications, I might get the wrong idea. I might end up picking purely those that have handle sensitive information and not seeing that the others don't have the same controls in place. So I need to consider these potential risks before we start Another thing we need to be clear, and this leads into a similar thing, is to define the sample population. So we know what a population is in general, but over what period of time? So for example, let's say that I want to audit whether or not new users being added to a system are properly authorized Should be clear about which system I'm talking about, how many users are we talking about, over what period of time do I want to look at this evidence so we can clearly say in writing this is what the population looks like like. All changes to the ISMS performed in the last six months are part of the population. We're very clear about where that population starts and stops. But we need to understand, as per my point a moment ago, the characteristics of that population. So let's go back to my example of checking whether people have been authorized to have access to a particular system. Now it's not quite as simple as saying, well, there's a thousand people who've been granted access over the last year so I'll just have a look at so many because maybe some people have been granted administrator access, maybe some people are super users and maybe some some people are standard users Obviously, I'm keeping this example very simple, but the point is they then would all have different characteristics. So I probably then need to change my sample to fit that. So let's just say Keep it a bit simpler and this is very simplistic but but it hopefully gets the point across. Let's imagine there are a hundred users 10 of them are administrators, 10 of them are super users, and the other 80 are normal users. Okay, well if I'm going to choose a sample then based on those characteristics I want my sample to be representative of that. In other words, 80% of my sample should be focused on normal user accounts 10% of my sample should be focused on administrator accounts and 10% of my sample focused on superuser accounts. In other words, if I understand the characteristics of the the population I can have a sample that represents that population because if I don't I could get a very skewed view of reality So with that in mind, we have a little workflow here talking about selecting the sampling method. And depending on your view, you can follow this thro So we get this first question, do we intend to extrapolate the results? In other words, learn more from the results that we get And then of course we can be asked what type of extrapolation we can do. So when we say yes, often this works in the field of monetary audits or financial audits In our case, many of our approaches will be looking for specific cases, you know, looking for specific. security controls in place. So mainly in this selection we're often going for what's called monetary unit sampling Which is not necessarily about money, just to be clear, but what we call random sampling. So I think the best way to explain this is to have an exploration of the sampling methods and their their benefits, their purposes. So what I'll do here is I'm just going to run you through a few different sampling methods with an example of each and you can think about how you might apply this in an ISMS audit. So let's take the first, random. Okay, so very simple to explain, maybe harder to do in reality, but let's go back to my example of access control. And let's imagine we have a hundred users who have been granted access to an application. And I simply say, let's run a random selection. Let's just say I want to look at 10 of those just for the sake of argument. And I just say right I'll have any 10 from that pool of 100 using some kind of random number generator Or something like that. So total selection based on chance. I'm not interfering with uh which uh user forms I take a look at. So statistically quite reliable, but It may not be representative of the population if I don't think about some of the other characteristics, but it's the easiest to understand I could consider a systematic sample. So let's say there's a 100 users and I want to look at say 10 of them and I say okay give me A user from the first block of 10, a user from the second block, you know, 11 to 20, a user from the third block. So in other words, I'm selecting certain samples at certain intervals It is systematic because we're following a pre-described system to maybe try and get examples from across the sample There's still some randomness in that because I'm not saying give me number two, give me number eight, give me number twelve, etc. But I'm saying within this range I'll take some n However, if we have the situation like the one I explained earlier where of these hundred users, you know, ten of them are administrators, ten of them are super users, and the rest normal users, for example. and I want to select a sample that is representative of the population, that's where we call this stratified selection So that's where I want to make sure each subset is represented. So I want to see the administrator group, I want to see the superuser group and the normal use normal group. It could lead to false conclusions if I get my numbers wrong. So if I don't know for example that 10% of those users are administrators I could overly select users from the administrator group, for example, and get the wrong view of reality. So there is a risk of false conclusions unless you are fully familiar with the population and select a population that's representative. Another thing you could consider in a case like this is what's called block selection. Now this really isn't ideal because it's not really representative. This could be in an environment where you really don't understand it to some degree the population. So let's say, let's take a different example. Let's imagine I walk into a physical data center and there's various network communication capabilities. containing cabling and I want to look at cabling security and not knowing the differences between these I just say I'm going to go and look at that group over there And I'm going to base whatever I see based on that group. I've selected a block. That, you know, in in an environment where it might be difficult to understand what's happening, that can be useful but it may not necessarily be representative. So I think these are some of the the key points to consider. So to be clear these are the different types There's no right or wrong. ISO does not say you must use any of these, but you must be able to justify that when you put your ideas forward. So what we haven't talked about though is determining the sample size. This is something on a course like this I'm always being asked, well how many items should I take? Now unfortunately I can't give you a gold number. I can't say well every time you go in do 10% or 20% etc etc. It will vary. It does depend on the peculiarities of the ISMS audit and things like the audit objectives, the size of the population, which of those sampling methods you're going to choose to use maturity of processes, all of these things and the most important one arguably, the willing or the level of risk the audit team is willing to to accept. What do I mean by that? The level of risk related to errors or detection risk. Remember detection risk is the risk of not being able to detect something. So the smaller the sample size, usually the greater the chance of of course not picking up on anomalies or issues. So this will also depend on what we agreed up front with the audit in terms of materiality Now, obviously it wouldn't be very satisfactory of me to say to you, well, ISO 17021 and ISO 19011 have nothing to say about sample size, so let's move on. I don't think many People would be satisfied with that. So, to answer that question, what we have done is referred you here to a sampling table that was designed by the IT Governance Institute So the IT Governance Institute have given some quite good guidance on this. And what they're saying is depending on what you're auditing and the frequency According to their statistical analysis, these are the minimum keyword their minimum number of selections we should consider. So if I look at the top one where I'm seeing, let's say I'm going to audit some change management. and let's just say there's a change being made every day for the last year. I'm going to look at least at 25. Now that's the IT governance Institute's minimum recommendation, we may use more if we need to have a greater confidence. And I'll come back to that in just a moment. So let's imagine you're the auditor, you have selected a sample, you've chosen your method, you've chosen the size, you then evaluate the results Now, that doesn't mean we decide simply by looking at the results that something's conformant or not. We would record the results and make a decision On what to do with them. Now, usually in a classroom-based course, I'd usually fire a question at the audience and the question goes along this line. What I tell people is: imagine I've done The audit, let's say the uh example at the beginning of this section. And I've looked at those 30 computers out of the thousand, I think it was that they mentioned or 500. And let's imagine that 29 out of 30 all have up-to-date anti-malware signatures and a proper label on them, but one of them doesn't. I always ask the class What would you do? Would you consider that to be 29 out of 30 is good? We're conformant, that's a good result. Would you say, well, you found one that isn't? that's a non-conformity or would you take a different route? And what I tell people is two things. Number one, you can't just say it's conformant or it's not based on that. You've got to look at the context You know, what does the implications of one machine, let's say, missing their anti-malware signature mean in reality? How serious would that be when I look at the bigger picture And what I could do as well as answering that question, if you've got time, you could potentially expand your sample a little bit. So if I expand it a bit, is it still one? That's not got an up-to-date signature, which might imply an anomaly. Or actually am I discovering more? And statistic statistically, if I'm discovering more, that would point to a wider problem. So this is why we don't make a snap judgment. Based on a sample, but we do try and evaluate those results. And it is important as an auditor in your audit working papers to document that process, laying out Um in the audit report what sampling method you used, what the population was, what the sample size was uh in terms of the statistical percentage. percentage. Any nuances you took into account, so the reasoning and any any um if you like if you've applied a stratified method, what the stratified groups were, for example. what confidence you have in this overall. Now this is why I would say we'd never just rely on a sample anyway. We combine sample results with other evidence. But it's important to point this out because ultimately when we're deciding what to say to an auditee, you know, you're conformant, you're not conformant. etc then I've got to be able to explain my logic so we do have just to summarize this a good example of a systematic Sampling exercise using that table that you saw earlier from the IT Governance Institute. And here's the example that we're talking about. Let's imagine I'm an auditor and I'm wanting to look at so many change requests. To see if they've been authorised properly, been through the proper process of review and risk assessment. And there's been 400 of those in the year. So according to the IT governance table I should be looking at least 25. I might decide to look at more if I want a bigger confidence level but we'll start with 25. So I take the 400 divided by 25 that gives me this number 60 So what we're saying here is I'm going to choose one item every 16th step. But I'm not just going to go number 16, number 32, number 48, etc. I might start with a random number, so the fifth. 16 items on would be 21, another 16 items on would be 37 and so forth. So in other words, this is a systematic sample uh example if you look back at that table. Now this is only an example. This is not us advocating that that's how you do every sample, but hopefully it gives a good worked example here. So hopefully that's given us a good overview of what sampling is about. I realise statistics it can be a complex topic. There could be more to it than this, but this should give you a very good starting point. to be able to select samples in an ISMS audit that you have confidence in. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S15.5-Audit-procedures.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S15.5-Audit-procedures.md index 2aa06c2..47c9247 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S15.5-Audit-procedures.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S15.5-Audit-procedures.md @@ -12,6 +12,8 @@ status: active ## Abstract +This session covers technical verification, corroboration of evidence, and virtual audit considerations. Technical verification involves reviewing configurations, observing demonstrated controls, or reviewing scan outputs, but auditors must never perform hands-on testing themselves. Computer-assisted audit techniques (CAAT) are mentioned for organizations using them internally. Corroboration means cross-checking evidence from multiple sources including interviews, documentation, observations, and third-party reports to build confidence in findings. The session concludes with guidance on virtual audits, including agreeing on technology platforms, testing connectivity in advance, planning for outages, and determining when a remote versus on-site audit is appropriate. + ## Transcription Okay, so another uh technique that we can use in audits to look at evidence is something called technical verification. So this is where as an auditor you might want to actually validate the effectiveness of a technical process or control Because as much as you can read about technology in documents and you can talk about it in theory with people and so forth, sometimes you really want to see the technology Technology firsthand. So examples of technical verification might be analyzing configurations. So if somebody tells me, for example, that they filter certain traffic on their firewall at the perimeter of their network, well let's have a look at the config of that firewall and see what it's allowing in and out. If somebody tells me that they've implemented group policy in Microsoft to lock down the use of removable media then perhaps we can look at that group policy setting or even test with permission of course that that um access is uh uh being properly controlled. Things like viewing whether a backup can be restored, things like looking at vulnerability scans, etc. Now I must stress absolutely here, no matter what technical skills you may have as an auditor, auditors in an ISMS audit will never perform a hands-on test. So I remember an audit I went to at one point and I asked this person, there was an on-site server at the time, and I said, Can you tell me a little bit about um backups? Can you maybe show me the backup software and the backup schedule etc. And this person handed the mouse to me and said uh yeah you just you just look at what you want and even though I knew where to go and I knew how to use the uh software in question I actually said back to them I said look I said I can't do that I need you to show me or somebody else to show me and that's simply down to the fact that as an auditor if you do do anything hands-on yourself then there is a potential liability risk So the example I gave a moment ago there about um you know testing removable media, um what I'd be doing is looking at maybe the group policy and maybe asking an administrator to to uh to show me if they do have removal and show me the error message that props up when you plug it in or the fact that it doesn't work or whatever but that would be done by the auditee not by me But we can use technical verification to really get a good understanding and I I do like this as a particular piece of in evidence because for me you know we can talk all we want about security controls unless I kind of see them usually that's the real you might say proof in the pudding so to speak that what's being talked about, written about, is implemented technically speaking. Now there is a reference here to technical verification through the topic of scanning And depending on your background, you might be familiar with scanning, like vulnerability scanning. So some of you might have used vulnerability scanner tools like Nessus or OpenVAS, Qualis, these kinds of kind of things. Now usually in an audit we would not do this. So certainly in a penetration test or vulnerability assessment for sure. In an ISMS audit I certainly wouldn't be running scanning tools. The organization might, and they may be able to demonstrate to me the tools they use. Now there's also reference here to something called CATS or computer-assisted audit techniques So computer-assisted audit techniques are tools that can look for certain things. They can look for, let's say, user accounts that haven't been used. used for a period of time, accounts that have been locked or they can do data quality tests to see whether data in a database has missing information or duplicates etc. And I do see cats being used a lot in things like internal audit activities. Again, it's very, very rare that you as an external auditor would be used. using such a tool. So the message here is certainly we can ask the organization to show us the tools that they're using and even demonstrate them to us but we're not going to do that hands on on testing. The main thing for me is technical verification is about reviewing configs. Show me, demonstrate, let's see that evidence first hand. Now, let's imagine you've been out as an auditor and you've been gathering all this information, you've been interviewing people, you've been reviewing documents, you've looked at technical configs and done samples To get a reasonable level of assurance we have to undertake a technique regularly called corroboration. So you may have heard of this term before. And corroboration is about basically getting your information from multiple sources and making sure those pieces of information are set. essentially marry up. So we can do corroboration in a number of ways. We could ask several people the same type of question and see whether we're getting the same answers. Now the idea here isn't to, again, catch people out. It is about do those answers make sense? Are they consistent? We can of course compare interview responses and verbal information with documented information. So if you've explained a procedure to me, does that marry up with what we're saying in documents? We can compare the documented information or the notes we've been taking from interviews with direct observations. So we might have been told how a process works, but do we see something different when we see somebody applying it in in reality. And again, that might be a problem or not a problem that we're trying to corroborate. Or validating or maybe getting evidence from external sources So a good example of that might be on an audit recently the organization told me that they'd addressed a number of vulnerabilities on one of their pieces of infrastructure and they discovered these vulnerabilities through a pen test and so we looked at the pen test report produced by a third party This organization had done some remediation and there was another pen test report showing that that remediation had indeed been completed separately. So not only did I have the verbal assurance that this was going on. I also had then written assurance, but written assurance from a confirmative third party source. that corroboration give me a greater confidence that indeed those processes were happening, those issues were indeed being addressed. So that's what corroboration can do for us. Now we also need to evaluate the results of this evidence. What we're asking ourselves here is do we have enough evidence, enough evidence of a quality and a quantity to have what we call a reasonable assurance. So earlier in the course we talked about the idea of relevant information and the reliability, in other words, is the evidence speaking for itself? Who's collected the evidence? How recent is the evidence? what type of internal control systems the organization have. These all influence your thinking here. What you're trying to answer at this point as a lead auditor is based on the requirements of the standard, the audit criteria, do I have enough evidence that's relevant, reliable enough to make a judgment? Whether the judgment is that the organization is conformant or not, or something else, I need to be able to pull that together. What I've got to ask myself here in this phase is if I In my report, say to an auditee, this is my finding, can I, and anybody challenges me on that, can I then back that up? Can I say I'm basing that on this evidence? here and that's the biggest question. Unfortunately there is no scientific formula or mathematical number. A lot of this is down to your professional judgment and asking yourself Can I, for want of a better description, defend what I'm presenting? Now, one thing we said at the start of this section Is that we might be in a situation where we will audit what we call virtual activities or locations. So let me explain what we mean by that So, as we've seen the emergence of cloud technologies and the ability to work remotely, we're now finding, of course, more and more organizations don't necessarily have a lot of information or infrastructure physically on site. So I can think of a software development company I've audited recently. They're completely cloud-based, so there's no servers or infrastructure in an office somewhere that I can go and take a look at. at. And the individuals actually all work from home, so they don't necessarily have a physical building that they go to work to in every day. And in that case, we would consider their organization, at least part of it, to be what we call a virtual location. Now in ISO 27001 auditing when an organization applies to be certified, that's some of the information that the certification body will gather is details of the location, what's there, what's actually going on and so forth. So we are allowed in auditing where it's genuinely what we call a virtual location or remote site to conduct a virtual audit. And there are some guidance in ISO 19011 for conducting what we call virtual audits that we need to take into account. and things that we need to plan and agree in advance. So firstly if we're going to do an online virtual audit, the audit team should all be in agreement on the kind of technology we're going to use the kind of devices and software we're going to use. We'd want to of course agree that with the audit. So if we agree that we're going to use Microsoft Teams as our platform for talking to each other You know, let's agree on that. Let's make sure we're happy that we can use that particular platform. We'd need to agree in advance on things like how will you share documents with us and make sure that we're all using the same compatible software. We'd want to make sure in advance of such a virtual audit that the audit team and the auditee are doing some kind of technical tests to verify that things will work. I don't want to be turning up on the first day of the audit finding I can't connect or have a connectivity problem. We also need to think very carefully about contingency plan. I've been there before. What happens if you have a power cut or a network outage during the audit? You know, have you got a backup plan in this case? Do we need to put extra audit time in the agenda to deal with potential technical issues? These are all important factors that you wouldn't have necessarily encountered. in a face-to-face audit. Now ultimately, as I've said, we've got to think about those things on making sure both parties are comfortable. And ultimately the decision as to whether an audit will be done remotely, on site or a combination of the two will depend on circumstances. So like that example of organization I've told you about, because there is no physical location really other than a registered office, it makes perfect sense to do a virtual you load it. Whereas on with another organization I've worked with recently who are doing they don't necessarily have on-premise infrastructure but they're doing work at an office every day and they still have some paper-based information for them we will do some of the audit on site because we still need to go and look personally at the physical security environment. So it is a level of protection professional judgment do remember that we've got to get that balance right for if we're going to go online that we do do that testing make sure we're all comfortable with the approach in this case So in summary then what we've looked at in this section are the different procedures to collect evidence, interviews, document reviews. um sampling, observations, technical verification. These are all ways in order to get hold of and look at evidence. And then we talked about the fact that we would corroborate different pieces of evidence evidence and make a judgment as to whether we have enough relevant and reliable evidence in order to make a judgment on conformity. It is important that all those audit tests are thoroughly planned. Considered and later in the course we will look at audit test procedures. And of course, we need to think carefully now in the ever-changing world of cloud and remote working, how and when we audit remote sites. and ensuring that when we do that we are properly prepared so that we still have a positive audit experience and can still gather all the evidence that we may need in this \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S16.1-Creating-audit-test-plans.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S16.1-Creating-audit-test-plans.md index 3868d60..d6cf7fa 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S16.1-Creating-audit-test-plans.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S16.1-Creating-audit-test-plans.md @@ -15,6 +15,8 @@ status: active ## Abstract +This session provides practical guidance on creating audit test plans with worked examples across eight ISO 27001 requirements. For each requirement, the session shows which combination of audit procedures applies: observation, documented information review, interviews, analysis, and technical verification. Requirements covered include clause 4.1 (organizational context), clause 4.2 (interested parties), clause 7.5.3 (document control), and Annex A controls including supplier agreements (A5.20), backup (A8.13), identity management (A5.16), technical vulnerability management (A8.8), and information security event reporting (A6.8). The examples demonstrate how to tailor the mix of audit procedures to each requirement's nature and materiality. + ## Transcription -Section 16 gives some general recommendations that auditors should consider when creating audit test plan. Additionally, we will also give various examples of other test plans applied to the context of ISO 2701. Audit test plans. So of course you need to prepare, uh we will give some uh general recommendations. Uh an auditor should develop audit test plans By selecting the most suitable and valid ones to verify whether the audit T complies with the standard requirements and the audit criteria. It is best practice, of course, to use a combination of audit test plans. Where you should use a test plan to verify if an audit complies with the standard requirement and the audit criteria, especially when the first one isn't interested. Verbal evidence is usually considered as insufficient evidence. That being said, supporting evidence is required. So I usually say I don't believe anything that you say uh jokingly. I I want to see evidence of for most of the things. So just having a verbal interview is not enough. The auditor should ensure that sufficient audit test plans have been prepared. And the quantity of the required audit test plans will, of course, depend on the materiality of the processes being audited, as well as the reliability and sufficiency of the evidence. When creating test plans, an auditor should also try to group audit plans intended for a particular requirement of the standard in order to avoid disruption of the audities. Operations. Now, when an auditor visits the same audit team multiple times, the test planch should be modified as well, of course. That enables the auditor to conform the audit test performed on previous audits. So, in the following slides, we will introduce six examples of the test plans. So, in order to collect sufficient and reliable evidence, the auditor can basically combine different audit procedures. So, first of all, you can conduct an observation, you can conduct documented information interview, you can do interviews, you can do analysis, and you can also go over a technical verification So we will dive a little bit deeper into the examples and give some more explanation on those test plans So the first example is to check the so we're looking at clause 4. 1, which is understanding the organization and the uh context. So the audit criteria is basically what is stated within the standard. So the organization shall determine internal and external issues That are relevant to its purpose and that affect its ability to achieve the intended outcome of the information security management system. The organization shall determine whether climate change is a relevant issue. So if you then look at the test plans that has been or the other test plans that have been associated with here, so observation has been deemed not applicable. There will be a documented information review so it states there you should review the documented evidence of the processes so will you will have a look at is there a SWOT is there a PESL analysis is there anything done You will also verify if the organization has taken into account climate change and you will also have a look at does the organization does a regular review of that analysis. On the interview aspect, the uh auditor can um to have a chat with uh members of the management team. Um you can also have chats with cross-functional teams to um check how strategic Strategic planning happens, what risk assessments are, how they consider the organization's context in managing information security. You can do a technical verification. In this case, you can have a look at the tools and the methods that have been used to analyze, like the SWOT or a PESEL. But also to have a look if there is anything with climate change on how these issues influence the organization's strategic and operational planning. And lastly, you can do an analysis where you can have a look at the selection of documented information that show how the organization has considered its internal and external context. in setting information security objectives. And that could, for example, include an evaluation of how climate change is considered a relevant issue The second example is in relation to understanding the needs and expectations of the interested parties. So again, audit criteria is what's is stated in clause 402 of the ISO 2701. So I I read out loud the organizations shall determine the interested parties that are relevant to the information. Information security management system. We'll evaluate the relevant requirements of these interested parties and which of these requirements will be addressed through the information security management system. Relevant interested parties can have requirements related to climate change. So the climate change aspect comes back again So you can consider in this example we've considered uh three other test plans. So observation and technical verification will not be done. There will be a documented uh information review done to check what the approach was to come to the um needs and expectations of interested parties. Um you should look for climate change There will be an interview conducted with people that are responsible for understanding the organization's context, engagement with interested parties. So that might be somebody from management to understand, okay, how did you come about these needs and expectations and how have they been addressed? Again, is climate change a thing? And of course the auditor can also do an analysis of selected evidence, how the organization ISMS addresses those requirements and to check if the document information is reflecting those considerations and how the organization is feeding that back to the interested parties. Example three is about control of documented information. In this case, we will look at 7. 5. 3. So the audit criteria is documented information required by the information security management system. And by this document shall be controlled to ensure that A it's available and suitable for use where and when it's needed, B, it's adequately protected, for example, from loss of confidentiality, improper use, loss of integrity. For the control of documented information, the organization shall address the following activities as applicable: the distribution, access, retrieval, and use Storage and preservation, including the preservation of legibility and control of changes and retention and dispositions So it's a lot that we want to check here. So all the different audit test plans will be included here. So as an observation, the auditor should observe How an organization ensures that protection of documented information and if the actions are consistent with policies and procedures. Auditor will do a review of the policy on documenting information management if there is a policy, but also at the procedures, lifecycle management to check if the organization has documented anything. You can do an interview with members of top management, related to the policies, of course, and to personnel responsible for the documented information management and archiving. and to see if they adhere to the policy and procedure that has been set up. You can do a technical um uh verification where you can validate the electronic structure for classifying and storing documented information and to see if the protection mechanism is working and of course you can also do an analysis to see if the documented information that you review that it follows the format and the guidelines as is set in the policy. procedure. Example four, related to addressing information security within supplier agreements. This is in relation to Annex A520, where the audit criteria is relevant information security requirements shall be established and agreed with each supplier based on the type of supplier relationship. So basically, observational technical verification has been deemed not applicable. However, for an internal audit, you can also ask that person to be uh in the meeting where the organization establishes those information security requirements. The auditor can also have a look at the policies that you've uh put out to work with suppliers, but also standard agreements, clauses on information. Information security, performance reports, SLAs, internal reports, and that can all be part of the documentation review. You can also, of course, conduct an interview both with top management To understand how they came up with the requirements, but also to a procurement manager, for example, or somebody else who's responsible for dealing with suppliers to understand how they apply this. And you can also select the sample of documented information to see if everything is already included in all the documents and uh that the organization follow its own policies. Example five is about information backup, which goes to Annex A8 13. Backup copies of information, software, and systems shall be maintained and shall regularly be tested in accordance with the agreed topic-specific policy on backup So again we will be performing all the audit test plans so you can observe how the backup procedure is performed and the locations where copies are kept. So I usually ask them to If possible, do a backup during the audit so you can follow it. You want to see the labeling, the physical and the environmental security, so you want to follow up that You can review the policy where you can check is there a definition of the required backup levels? Is there backup criteria? Is there anything about encryption, for example? Is there a link with the business? Business continuity plan. Has the organization established procedures on how to do backup and restore of backup? Do they do dry runs? Are there any records available? You can do an interview, of course, with the operations manager to understand how it works, to explain the strategy. You can do a technical configuration where you can verify backup system configurations. And security mechanisms like encryption, where you can ask to do a restore of an archived file, and you can select a sample to verify if the entries have been well documented in the backup. So you can do a lot of things. Example six is about identity management, which relates to annex A516. The full life cycle of identities shall be managed Again, we will complete all the audit test plans so you can do an observation to see how user identities are established and how the configuration process works You can in the documented information review any policy that there is about identity and access management, but also the review and approval of user identities. you there might be user access review rights, so there might be different documentation available. You can conduct an interview with an help desk manager, for example, to confirm The features covered by identity and access management policy and to check if the help desk follows those. You can do a technical verification where you verify the configuration and operation of system I used for activating new identities. And you can do an analysis where you select a sample of users and you validate if they have unique identities when accessing the information. the organization's information and if the identity and access management policy has been properly followed. Example seven is about management of technical vulnerabilities, and which relates to Annex A8. 8, where the audit criteria are information about technical vulnerabilities Of information systems in use shall be obtained, the organization's exposure to such vulnerabilities shall be evaluated and appropriate measures shall be taken. Again, all the other test plans will be followed or can be followed and you can observe a technician performing activities related to the management of vulnerabilities. So you can have a look at intrusion test or vulnerability scanning and you can have a look at those. You can do a documented information review where you can check if there is a procedure around vulnerability management, if there is an um An asset inventory of computer material. If you have a list of potential vulnerabilities, you might see if there is a distribution list of software publishers. related to vulnerabilities you can check if the organization is subscribed to certain newsletters. There are a couple of things that you can review there. You can uh interview the information security manager to determine whether the procedure for the management of technical vulnerabilities has been established. And of course, you should also interview You can do a technical verification to see if the latest version, for example, on a system is installed and how vulnerabilities are treated. And you can also select a sample of technical vulnerabilities to see if they were treated in accordance with whatever is written in the procedure. To see if the organization follows their own procedures. The last example is example eight, which is related to information security event reporting. related to Annex A6. 8, the organization shall provide a mechanism for personnel to report observed or suspected information security events through appropriate channels in a timely manner. Again, all other test plans will be followed. As an observation, you can, for example, observe how somebody reports an information security. uh event of course when it occurs during the audit. If not you can ask of course um somebody uh randomly if there would be an information Security event, what is it what you would do? You can review the information security event procedure and information security incident management policy. You can review those documents. You should interview the information security manager or an help desk manager to confirm that the process and procedures are followed You can do a technical verification of the configuration of automated alerts embedded in information systems and test their effectiveness. And you should also do an analysis of security events where you can check if they were treated according to whatever has been written in the procedure. So you should check if there is a root cause analysis lesson. Slurred and so on \ No newline at end of file +Section 16 gives some general recommendations that auditors should consider when creating audit test plan. Additionally, we will also give various examples of other test plans applied to the context of ISO 27001. Audit test plans. So of course you need to prepare, uh we will give some uh general recommendations. Uh an auditor should develop audit test plans By selecting the most suitable and valid ones to verify whether the audit T complies with the standard requirements and the audit criteria. It is best practice, of course, to use a combination of audit test plans. Where you should use a test plan to verify if an audit complies with the standard requirement and the audit criteria, especially when the first one isn't interested. Verbal evidence is usually considered as insufficient evidence. That being said, supporting evidence is required. So I usually say I don't believe anything that you say uh jokingly. I I want to see evidence of for most of the things. So just having a verbal interview is not enough. The auditor should ensure that sufficient audit test plans have been prepared. And the quantity of the required audit test plans will, of course, depend on the materiality of the processes being audited, as well as the reliability and sufficiency of the evidence. When creating test plans, an auditor should also try to group audit plans intended for a particular requirement of the standard in order to avoid disruption of the audities. Operations. Now, when an auditor visits the same audit team multiple times, the test planch should be modified as well, of course. That enables the auditor to conform the audit test performed on previous audits. So, in the following slides, we will introduce six examples of the test plans. So, in order to collect sufficient and reliable evidence, the auditor can basically combine different audit procedures. So, first of all, you can conduct an observation, you can conduct documented information interview, you can do interviews, you can do analysis, and you can also go over a technical verification So we will dive a little bit deeper into the examples and give some more explanation on those test plans So the first example is to check the so we're looking at clause 4. 1, which is understanding the organization and the uh context. So the audit criteria is basically what is stated within the standard. So the organization shall determine internal and external issues That are relevant to its purpose and that affect its ability to achieve the intended outcome of the information security management system. The organization shall determine whether climate change is a relevant issue. So if you then look at the test plans that has been or the other test plans that have been associated with here, so observation has been deemed not applicable. There will be a documented information review so it states there you should review the documented evidence of the processes so will you will have a look at is there a SWOT is there a PESL analysis is there anything done You will also verify if the organization has taken into account climate change and you will also have a look at does the organization does a regular review of that analysis. On the interview aspect, the uh auditor can um to have a chat with uh members of the management team. Um you can also have chats with cross-functional teams to um check how strategic Strategic planning happens, what risk assessments are, how they consider the organization's context in managing information security. You can do a technical verification. In this case, you can have a look at the tools and the methods that have been used to analyze, like the SWOT or a PESEL. But also to have a look if there is anything with climate change on how these issues influence the organization's strategic and operational planning. And lastly, you can do an analysis where you can have a look at the selection of documented information that show how the organization has considered its internal and external context. in setting information security objectives. And that could, for example, include an evaluation of how climate change is considered a relevant issue The second example is in relation to understanding the needs and expectations of the interested parties. So again, audit criteria is what's is stated in clause 402 of the ISO 2701. So I I read out loud the organizations shall determine the interested parties that are relevant to the information. Information security management system. We'll evaluate the relevant requirements of these interested parties and which of these requirements will be addressed through the information security management system. Relevant interested parties can have requirements related to climate change. So the climate change aspect comes back again So you can consider in this example we've considered uh three other test plans. So observation and technical verification will not be done. There will be a documented uh information review done to check what the approach was to come to the um needs and expectations of interested parties. Um you should look for climate change There will be an interview conducted with people that are responsible for understanding the organization's context, engagement with interested parties. So that might be somebody from management to understand, okay, how did you come about these needs and expectations and how have they been addressed? Again, is climate change a thing? And of course the auditor can also do an analysis of selected evidence, how the organization ISMS addresses those requirements and to check if the document information is reflecting those considerations and how the organization is feeding that back to the interested parties. Example three is about control of documented information. In this case, we will look at 7. 5. 3. So the audit criteria is documented information required by the information security management system. And by this document shall be controlled to ensure that A it's available and suitable for use where and when it's needed, B, it's adequately protected, for example, from loss of confidentiality, improper use, loss of integrity. For the control of documented information, the organization shall address the following activities as applicable: the distribution, access, retrieval, and use Storage and preservation, including the preservation of legibility and control of changes and retention and dispositions So it's a lot that we want to check here. So all the different audit test plans will be included here. So as an observation, the auditor should observe How an organization ensures that protection of documented information and if the actions are consistent with policies and procedures. Auditor will do a review of the policy on documenting information management if there is a policy, but also at the procedures, lifecycle management to check if the organization has documented anything. You can do an interview with members of top management, related to the policies, of course, and to personnel responsible for the documented information management and archiving. and to see if they adhere to the policy and procedure that has been set up. You can do a technical um uh verification where you can validate the electronic structure for classifying and storing documented information and to see if the protection mechanism is working and of course you can also do an analysis to see if the documented information that you review that it follows the format and the guidelines as is set in the policy. procedure. Example four, related to addressing information security within supplier agreements. This is in relation to Annex A520, where the audit criteria is relevant information security requirements shall be established and agreed with each supplier based on the type of supplier relationship. So basically, observational technical verification has been deemed not applicable. However, for an internal audit, you can also ask that person to be uh in the meeting where the organization establishes those information security requirements. The auditor can also have a look at the policies that you've uh put out to work with suppliers, but also standard agreements, clauses on information. Information security, performance reports, SLAs, internal reports, and that can all be part of the documentation review. You can also, of course, conduct an interview both with top management To understand how they came up with the requirements, but also to a procurement manager, for example, or somebody else who's responsible for dealing with suppliers to understand how they apply this. And you can also select the sample of documented information to see if everything is already included in all the documents and uh that the organization follow its own policies. Example five is about information backup, which goes to Annex A8 13. Backup copies of information, software, and systems shall be maintained and shall regularly be tested in accordance with the agreed topic-specific policy on backup So again we will be performing all the audit test plans so you can observe how the backup procedure is performed and the locations where copies are kept. So I usually ask them to If possible, do a backup during the audit so you can follow it. You want to see the labeling, the physical and the environmental security, so you want to follow up that You can review the policy where you can check is there a definition of the required backup levels? Is there backup criteria? Is there anything about encryption, for example? Is there a link with the business? Business continuity plan. Has the organization established procedures on how to do backup and restore of backup? Do they do dry runs? Are there any records available? You can do an interview, of course, with the operations manager to understand how it works, to explain the strategy. You can do a technical configuration where you can verify backup system configurations. And security mechanisms like encryption, where you can ask to do a restore of an archived file, and you can select a sample to verify if the entries have been well documented in the backup. So you can do a lot of things. Example six is about identity management, which relates to annex A516. The full life cycle of identities shall be managed Again, we will complete all the audit test plans so you can do an observation to see how user identities are established and how the configuration process works You can in the documented information review any policy that there is about identity and access management, but also the review and approval of user identities. you there might be user access review rights, so there might be different documentation available. You can conduct an interview with an help desk manager, for example, to confirm The features covered by identity and access management policy and to check if the help desk follows those. You can do a technical verification where you verify the configuration and operation of system I used for activating new identities. And you can do an analysis where you select a sample of users and you validate if they have unique identities when accessing the information. the organization's information and if the identity and access management policy has been properly followed. Example seven is about management of technical vulnerabilities, and which relates to Annex A8. 8, where the audit criteria are information about technical vulnerabilities Of information systems in use shall be obtained, the organization's exposure to such vulnerabilities shall be evaluated and appropriate measures shall be taken. Again, all the other test plans will be followed or can be followed and you can observe a technician performing activities related to the management of vulnerabilities. So you can have a look at intrusion test or vulnerability scanning and you can have a look at those. You can do a documented information review where you can check if there is a procedure around vulnerability management, if there is an um An asset inventory of computer material. If you have a list of potential vulnerabilities, you might see if there is a distribution list of software publishers. related to vulnerabilities you can check if the organization is subscribed to certain newsletters. There are a couple of things that you can review there. You can uh interview the information security manager to determine whether the procedure for the management of technical vulnerabilities has been established. And of course, you should also interview You can do a technical verification to see if the latest version, for example, on a system is installed and how vulnerabilities are treated. And you can also select a sample of technical vulnerabilities to see if they were treated in accordance with whatever is written in the procedure. To see if the organization follows their own procedures. The last example is example eight, which is related to information security event reporting. related to Annex A6. 8, the organization shall provide a mechanism for personnel to report observed or suspected information security events through appropriate channels in a timely manner. Again, all other test plans will be followed. As an observation, you can, for example, observe how somebody reports an information security. uh event of course when it occurs during the audit. If not you can ask of course um somebody uh randomly if there would be an information Security event, what is it what you would do? You can review the information security event procedure and information security incident management policy. You can review those documents. You should interview the information security manager or an help desk manager to confirm that the process and procedures are followed You can do a technical verification of the configuration of automated alerts embedded in information systems and test their effectiveness. And you should also do an analysis of security events where you can check if they were treated according to whatever has been written in the procedure. So you should check if there is a root cause analysis lesson. Slurred and so on \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S16.2-Creating-audit-test-plans.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S16.2-Creating-audit-test-plans.md index d21d6d9..7e7e3a8 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S16.2-Creating-audit-test-plans.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S16.2-Creating-audit-test-plans.md @@ -30,6 +30,8 @@ status: active ## Abstract +This session provides guidance from ISO 27007 on auditing specific ISMS requirements. Audit evidence types and practices are outlined for clauses 4.1 (organizational context, including the new climate change requirement), 4.2 (interested parties), 4.3 (ISMS scope and statement of applicability), and requirements related to ISMS operation, information security policy, resources, management review, and nonconformity management. For each area, the session explains what audit evidence to seek, what the auditor should confirm, and how to combine documented information, interviews, observations, and analysis to validate conformity. + ## Transcription So annex a dot one of the twenty-seven thousand seven ISO standard gives guidance on auditing an ISM. So that 2707 ISO standard provides generic guidance on how organizations should be audited that claim conformance to the ISO 27001. So this the guidance that is given in the ISO 2707 is um independent of the size of the organization or the industry that it in so the guidance is very uh generic and of course the guidance can also be used both for internal and external auditors So again, we will dive deeper and we will have another couple of slides where we dive deeper into that guidance for auditing in ISMS. So in the ISO 2707, there are a couple of tables that you need to understand. So when looking at auditing and understanding the organization and its context. you will get um a referral to the subclauses. So in the ISO standard it ref refers back to clauses Um six dot uh one nine point three. Um you have the twenty-seven thousand uh definition, uh external context, information security Internal context management system. And then you will have a look at okay, what is the audit practice guide and what is the audit evidence So you will basically have a look at how that evidence can be obtained through documented information or other information on important issues that affect positive or negatively the ISMS. You can have Information on the organization, the purpose, the intended outcomes. You can also look at environmental characteristics or conditions, the climate changes, they're of course important. You can have a look at what is the culture, what are the policies, do you see trends in risk assessment and so forth So you want to have a look as or you should confirm if the organization has a high-level understanding on um yeah the the effects that uh or the internal and external um effects on the organization. And you should also um understand uh you need to check if the organization knows what those external internal issues Issues are that are relevant for its purpose and that affect its ability to achieve the attended outcome of the management system. So looking at the risk assessment, looking at the SWOT analysis, looking at confidentiality and integrity, though what they need to confirm that the organization has a good insight. uh on important topics for the organization um uh you want to see uh how do how does that affect the management system. When you want to address climate change within the requirements of clause 4. 1, this is a new requirement. Organizations shall determine whether climate change is a relevant issue. With all my customers, this is a challenge. People find it a very difficult requirement. So to audit this new requirement, you should think about a couple of things. You need to see if they if an organization has included climate change in the assessment of internal and external. Issues. We also want to check in the risk assessment if there are any risks related to climate change. And you also want to see if there is anything in the strategic direction that takes into account climate change. There also might be stakeholders that are requiring it. So looking at the risk assessments Strategic meetings, stuff like that. So you want to get a little bit insight in that context as well. Understanding needs and expectations of interested parties. Goes to clauses 4. 1 and 4. 3. Um linked to the 27,000 definition is an interested party. Um so you want to audit their uh evidence of the interested parties, you want to check uh what interested parties Have been included. Are there customers? Do you have authorities in there? Do you have suppliers? Neighborhood neighbors, members of the organization, and others working on the behalf of the organization. So you should be able as an auditor to confirm that the organization has a high level understanding of the needs and expectations of the relevant interested parties. So there are a lot of things that you can include, of course, there. And again dependent on the organization, you might include authorities or regulatory agencies, licenses. obligations, communication, and that might be very different per organization. Interested parties can of course have different interests which can be completely aligned. Disaligned, opposed to the business objective. So that needs to become clear out of that stakeholder analysis as well When addressing climate change in this requirement, the clause 4. 2, where relevant interested parties can have requirements to the climate change. uh you can consider uh the following uh are there um expectations um of relevant interested parties concerning that climate change And evaluate of those customer requirements, Li regulatory obligations, or other external parties expectations include climate change related measures. So you that might be the case. I see more and more that in tendering um in questions that that customers ask. um that um environment climate change uh becomes uh a growing uh thing so uh there might be the case that there is Uh something that can be reflected there. So you also want to verify if there are ISMS objectives or controls that reflect any newer changing expectations related to that climate change And you also want to verify that the organization has a method to regularly verify and update understanding of interested parties. So You should look for any climate change requirements related from parrot companies, customers, suppliers, and so forth. When auditing climate change issues that might influence the organization's ISMS, auditors should consider the following. Is climate change a thing within the organization? Has it been identified? And is it aligned with whatever applicable statutory, regulatory, or contractual requirements that were? So you should check if an organization has assessed that potential for climate change. both to the physical and digital infrastructure and the implications on information security. So if climate change has been deemed a relevant issue, the organ the auditor should also check If the organization has considered its broader business applications all the way down the supply chain, uh how uh could it directly and indirectly impact the information? Information security and auditors may need to examine how the organization manages data protection and cybersecurity during climate-induced incidents, such as extreme weather events, for example, that could lead to data breaches. When determining the scope of the information security management system as related to clauses 4. 1 and 4. 2, the audit evidence can be gained through documented evidence information or other information of the scope of the organization management system, the scope of an organization certification, statement of applicability can also help, of course Um so you should um confirm that the organization establishes both physical, informational, legal, and organizational boundaries to which the ISMS Is applied so that there is a good understanding if it's applicable for the whole organization or for a business unit. So understanding that context of the organization uh and again the requirements of the interested parties um and the interfaces and dependencies between activities performed by the organization uh should be considered when establishing uh the scope Auditors should also have a look at the information security risk assessment and risk treatment so that it reflects the activities um that are included in that scope and that's um as as as defined in that scope and they should also verify that um one statement of applicability And that all controls determined in the risk management process are also included in the statement of applicability. And of course, controls that are the necessary controls referred to in ISO 27001 are not necessarily all the NXA controls. So they might also include sector-specific controls that are not part of the NXA. control. If there are any interfaces or any outsourcing activities that should also be clear. It needs to be clear where the overlap sits within the organization and how that is managed. For example, if you have a sharing of facilities of IT systems and stuff like that, you should be able to determine that in the scope as well. need to ensure as an auditor that the documentation of the scope is of course created in line with whatever you've identified in your procedure for documented inference. When looking at an information security management system and that goes to a couple of controls, s 6. 1. 1. 2. 3, but also 81, 82, and 8. 3 You should find uh information or evidence in the documented information um towards the processes that are included in the management system. and how is there an operational planning linked to those processes? Do you have a structured approach? Do you also include your outsourcing outsourced processes? How do you verify those What are the processes for risk management, risk treatment? How do you execute those? And what is the process to achieve information security risks? So the auditor should confirm that the organization creates um necessary but sufficient set of processes and controls in order to uh meet conformance of ISO 20. 27,001 and also check that there are interrelating systems and so forth. So the auditor should confirm that the organization In however it's set up with the capacity with the processes with the authority to decide how it will fulfill the ISMS requirements, including the level of detail and extent to which it will integrate the ISMS requirements. In its business. When auditing the policy, which is related to 6. 2 and 7. 4, the audit evidence can obviously be obtained by looking at the information security policy, but also to the information. Information security objectives. So auditors should confirm that the information security policy specifies the high-level organizational commitments as required by the standard, taking into account the organization's purpose. The information security policy is either used to frame or build the information security objectives that the organization sets for itself or are stated explicitly as part of the information. security policy and that there is also documented information of that information security policy and that this is controlled in line with the information security document management procedure. So in addition, you also need to check that the information security policy is communicated internally but also externally to other interested parties. when that is necessary. So those are the the most important things that you need to consider when auditing the security policy. When auditing resources, that goes back to clauses 5. 1, 6. 2, 7. 2, audit evidence can be gathered through documented information um to check if um if you have established something around um the implementation of the isms or the Implementation, the operation and the controls, but also um something around the maintaining and the continually improving of the IS SMS. So auditors should there really look for is the organization ready both to anticipate but also to allocate resources. Needed to both establish and implement uh the ISMS but also to maintain and to continually improve it. So resources here can really include your people Of course, uh specialized skill, money, uh technology. Um, so it might be uh a whole set of things that you can uh check for, and you might, for example, uh check a budget sheet to see if there is any allocation of money into the budget. Sheet. When auditing a management review, there's go uh related to a lot of subclauses, so 4. 1, 4. 2, 8. 1. 2, 8. 1. 3, 9. 1, 9. 2, 10. 1, and 10. 2 So you can of course find a lot of information. You want to check if the reviews are done in a planned interval, so you want to check agendas or stuff like that. You want to check the status from the previous management review meeting. You want to see that there are changes in internal and external issues. You want to see that the organization has had a look at that. You want to get insight on feedback of that information security performance. So you want to see trends or measures in relation to non-conformities and corrective actions. You want to see some monitoring and measurements results, audit results, but also the fulfillment of information Information security objectives. You want to check that the organization has done something with the feedback from interested parties. You want to see an overview of the risk assessment and the status of the risk treatment plan. And you want to see some opportunity. For improvement. So the auditor, you should as an auditor check with the management that you've that they've done the management review and that they have a schedule of that and that they have addressed all the topics that are required by the standard. So you should check that everybody off-top management has been involved through that, and you should also check if the management has formed some kind of a conclusion. And so what is listed in the audit evidence? What are decisions moving forward? How does the management think about the ISMS? So there are a couple of things that need to be considered Then lastly, some guidance on auditing non-conformities and corrective actions. Clauses 7. 5, 8. 1, and 10. 2 are related to that. So audit evidence can be obtained through documented information or other information about what is the nature of nonconformities and any subsequent actions taken, what were the results of the corrective actions How were those results monitored and measured? How was the audit program and the audit results? You can have a look at those. You should have a look at the management review to see what any non-conformity And corrective actions came out of that. And if the non-conformities have been discussed in the management review, any requirements from interested parties that have an impact and changes to the ISMS brought by corrective action. So, what you basically want to audit or what you want to confirm is that the organization responds in a correct way to non-conformities and that they undertake the actions that are necessary. So you need to take the actions, you want to see that they've done a root cause analysis, you want to do see an impact analysis, and you also want to see that an organization checks the effectiveness of the corrective measures that they have implemented. So this was a pretty long section on how to conduct or how to create audit test plans and also how you could audit a couple of the clauses. So First of all, the auditor should develop audit test plans to verify whether the auditee complies with the requirements of the standard and the audit criteria. An auditor can also combine different audit procedures in order to collect sufficient and reliable evidence. And we have of course presented several examples of audit test plans Which consisted of a combination of the following audit procedures. So we always spoke about observation, documented information, review, interviews, analysis, or technical verification. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S17.1-Drafting-audit-findings-and-nonconformity-reports.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S17.1-Drafting-audit-findings-and-nonconformity-reports.md index 75f4bc1..5c433c2 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S17.1-Drafting-audit-findings-and-nonconformity-reports.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S17.1-Drafting-audit-findings-and-nonconformity-reports.md @@ -12,6 +12,8 @@ status: active ## Abstract +This session explains how to draft audit findings and nonconformity reports. Audit findings differ from audit evidence: findings are the auditor's evaluation of evidence against audit criteria. Findings can indicate conformity, nonconformity, good practices, or opportunities for improvement. The session distinguishes between minor nonconformities (partial fulfillment with limited impact on ISMS effectiveness) and major nonconformities (complete failure that raises significant doubts about ISMS capability, typically requiring a special audit before certification). Observations and anomalies are also explained, with worked examples for each finding type across clauses 5.2, 7.5.3, and Annex A controls. + ## Transcription Section 17 will provide you information that will help you gain knowledge on the process of drafting and documenting audit findings and non-conformity reports. So apart from being one of the most important elements of the audit, and most companies are only really concerned about the audit findings, but audit findings are also the determining factor in drawing the audit. And they comprise all information relevant to the observation of a potential deficiency or effectiveness of the process. Auditors are obliged to pay careful consideration to the documentation of audit findings. This also helps them in decision making and whether a report is an issue in writing or to just just discuss it by the audit or to simply omit it. Audit findings is not the same as audit evidence. Audit evidence is factual. where an audit finding is um the product of the evaluation of an auditor, which is by definition subjective. So the auditor's observation of a change management procedure can indicate whether such a procedure complies with the requirements of The standard and the specific requirements of an audit by example. So the audit criteria is also the results of an evaluation of the collected audit evidence is always against the audit criteria. So it should indicate conformity or non-conformity. And audit findings can of course also lead to the identification of risks, opportunities for improvement, or of course also recording of good practice. If the audit criteria are selected from statutory requirements or regulatory requirements, and the audit finding is termed compliance or non-compliance. So non-conformities should be recorded, and non-conformities can be graded depending on the context of the organization and the risk. The grading can be quantitative, for example, from one to five. and qualitative, minor or major. They should be reviewed with the audit T in order to obtain acknowledgement that the audit evidence is accurate and that the nonconformities are understood. When there is any diverging opinion, you should undertake as an auditor all attempts to resolve that. And if you can't resolve it, it should be recorded in the audit report. So it should not be the case that an auditee is surprised by the findings that you have. You should communicate them with them. And of course, if you're working with an audit team You also need to come together with your other team to get agreement on the different uh findings that you have. So when we look at the annex A18. 1 from um the ISO 1911, there are a couple of things that is stated there um with regard to the audit finding. So of course Um you should look at the following things. It's a it can be a follow-up on previous audit records or conclusions You of course look at the requirements of the audit client. You look at accuracy, sufficiency, and appropriateness of objective evidence to support the audit finding. If you don't have enough evidence, you can't write it. You have to look at the extent to which planned audit activities are realized and planned results are achieved. You need to look at findings exceeding normal practice or opportunities for improvement. You also need to indicate the sample size. and the categorization of the audit findings, so major or minor basically. During an audit it's also possible of course to identify findings related to multiple criteria Where an auditor identifies a finding linked to one criterion on a combined audit, the auditor should consider the possible impact on the corresponding or similar criteria of the other management system. So depending on the arrangements with the audit client, the auditor may either raise separate findings for each criterion or one single finding combining the reference to multiple criteria. Now requirements can of course originate from several sources. So audit findings, you can either have a conformity or a non-conformity as stated in the ISO 9000 Nonconformity is a non-fulfillment of a requirement, and a conformity is then the fulfillment of a requirement. So those requirements can come from several sources. They can be specified in the standard But it can also be part of a requirement internal to the organization. It may be a part of a law or legislation, or it may be part of a signed contract with a client or a partner. So uh uh there are a couple of instances that can lead to a non-conformity, of course. Uh documented information is not adequate A process or a control is absent or does not fulfill its function, or the process or the control does not provide the extended output. So then we make a difference between a minor and a major nonconformity. So let's start with a minor nonconformity. If you look at the definition, minor nonconformity is the partial fulfillment of a requirement. So a minor nonconformity raises certain doubts about the ISMS ability to help an organization achieve this information security objectives and meet the requirements of the ISO 27001 standard It presents basically a minor risk, but not one to be ignored to the organization's interested parties. So but it basically does not affect the capability of the management system to achieve its attendant results. So it is a minor nonconformity. There are certain doubts, but it does not have an effect on the capability of the management system to achieve the intended results. So that is a minor nonconformity So some examples of non-conformities. For example, let's have a look. Some inconsistencies with the risk assessment report were observed. Or you have a few employees who have certain information security roles but they did not receive adequate training You have a couple of procedures that have not been reviewed or updated when it was supposed to be happening. Some of the non-conformities from a previous audit were not closed as planned and there was no justification provided. A planned changes related to the ISMS were not communicated, so there might be a different type of thing. So now how you um need to document them, like for example, uh this the the description of the detected nonconformities. Of course you you don't write like it's stated on the slide here as some inconsistencies with the risk assessment report and you need to uh describe it a little bit better. So you could, for example, uh describe the organization has implemented procedures to ensure compliance with the use of proprietary products. However, the Adobe Illustrator software is installed in 46 workstations despite the fact that the organization has only 40 user license And the audit criteria then would be that the organization shall implement appropriate procedures to protect intellectual property rights, which is control A532 If we then look at, for example, clause 5. 2 at the top management shall establish the information Security policy, then a description could be. The organization has defined and communicated the information security policy that includes a framework to set objectives and has outlined a general orientation and action principles Concerning information security. The policy takes into account the requirements related to business characteristics as well as the legal, regulatory, and contractual requirements. However, there is no reference to the continual improvement of the ISMS, which is a standard uh part of it. When looking at um clause 7. 5. Three, for example, which is documented information required by the information security management system and by this document shall be controlled to ensure it's available and suitable for use. where and when it's needed and it's adequately protected um against loss of confidentiality and property use and loss of uh integrity. a detected nonconformity could uh be something like this. The organization has implemented and maintains a document management system for its ISMS However, there is no documented information related to the ISMS that specifies the location of the official versions of the currently operating security Procedures. So that might be some examples of minor nonconformities. When looking to major nonconformities, is the non-fulfillment of a requirement or a total failure of its effectiveness? So a major nonconformity raises significant doubts about the ability of the ISMS to achieve the information security objectives and meet the requirements of ISO 27001. and uh presents an unacceptable level of risk to the organization's interested parties. So that really affects a major nonconformity really affects the capability of the management system to achieve its intended uh result. So you have a certain control not in place while it should be in place You have a couple of minor nonconformities that are associated with the same requirement that could also lead up to a major nonconformity. So what happens it usually leads to postponement of the certification and usually it also leads to a new audit, which is then called a special audit So what needs to happen then is that the audit T is required to complete a response to the major non-conformity within a certain period. And so prior to be putting forward for certification, all major nonconformities need to be resolved to move forward in that process. So again, what could be a couple of examples? Um, and I'll dive a little bit in the right description then. So there might be lack of commitment from top management, there might be lack of competence of people in charge of managing the ISMS. There might be lack of corrective actions to address recurring incidents, requirements not addressed properly, or lack of evidence of internal audit activity. So if we then look at how it would be officially described in an in a report and an audit report, if we then look at, for example, NXA8. 1 which is about information stored on, processed by or accessible via user endpoint devices shall be protected. So a description of a non-conformity could be The organization's personnel are not all aware of the policy and security measures for acceptable use of mobile devices. Might be a non-conformity. If you look at clause 7. 2b, the organization shall ensure that these persons are competent. So this is about a lack of competence. Possible description could be the organization has established an internal audit program with suitable audit procedures. Last year's audit activities were carried out by an intern, so recent graduate, with no experience or qualification in management systems. System audits, that's also an issue. Description SO if you look at the organ uh seven uh class six dot one dot 2E, the organization shall define and apply an information security risk assessment process that evaluates the information security risks A possible detected non-conformity could be the organization has developed a risk assessment methodology adapted to the ISMS. However, it does not allow the organization to effectively evaluate information security risks. So you have a risk assessment process, but it doesn't help with managing or evaluating information security risks. And then the third thing that an audit can find, or an audit finding that can be written, is an observation. So an observation is basically a situation Or an element observed during the audit that may be subject to improvement without necessarily being a non-conformity. So observations are often followed by recommendations to improve the efficiency of the management system, but the auditee is not obligated to implement the corrective actions for the auditor's observations. So observations are usually documented throughout the audit report because some of them may constitute weaknesses in the management system. So you want to follow up on such weaknesses as auditor during the upcoming audit. So you also want to check not only do you follow up on major and minor nonconformities But in a follow-up audit, you also want to check. We had a couple of observations. What did you do with the observations? Did you take them in consideration? What did you think about it? So you should document that properly. So there are two things that you can do. Usually it is included that an observation is included in the audit report. Um but um yeah it's not per se necessarily you can do it in the audit report or in the general attention points or general observations. It's a little bit dependent on how the template of the certification body uh works but observations um can basically not influence the conclusion of your audit and then we still have something like which is Called an anomaly. An anomaly is a deviation from a requirement or from the target set by the organization, but it still remains within the organization's established and acceptable levels. Um anomalies are also documented in your audit report, but um or in the working papers or on the notes that you uh make, but they're usually not included in the audit report, while an observation is included in the So to give an example of an uh anomaly, an organization with 100 employees has decided that 90% of the employees must attend an awareness session. In the first three months of employment. If the auditor finds that five employees have not attended the session within the three months, the auditor will consider the finding as conforming to the organization's requirement. At a five documented cases represent anomalies, deviation from the organization's requirement, but the overall process is considered effective. On the contrary, if um an auditor finds out that 15 employees um have failed to attend the awareness, they should report this as a non-conformity because the number of anomalies is beyond the acceptable threshold as uh set by the organization 10%. So if the organization would have put the threshold of 20%, then of course it would still be an anomaly. So that's really dependent on what the organization has set for itself. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S17.2-Drafting-audit-findings-and-nonconformity-reports.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S17.2-Drafting-audit-findings-and-nonconformity-reports.md index d667824..11b1e05 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S17.2-Drafting-audit-findings-and-nonconformity-reports.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S17.2-Drafting-audit-findings-and-nonconformity-reports.md @@ -12,6 +12,8 @@ status: active ## Abstract +This session covers the process of documenting nonconformities and completing the audit findings review before the closing meeting. The distinction between minor and major nonconformities requires professional judgment based on organizational context, and the threshold is not fixed or universal. Nonconformity reports must clearly state the audit criteria, describe the observed nonconformity with supporting evidence, and identify the type. A worked example of a nonconformity report is provided for Annex A5.9 (asset inventory). The session also emphasizes that the auditor's role is to verify conformity rather than find nonconformities, and that benefit of the doubt applies when evidence is absent. + ## Transcription So the uh auditor of course needs to document um the audit findings, so you need to evaluate the evidence against the audit uh findings So before the closing meeting, the audit team must discuss the completion of audit findings review and other relevant information that they've collected during the audit. So they need to consider the specific context of the audity. They should evaluate the evidence against the audit criteria. They also need to check the validity of the evidence and if it's sufficient in relation to the audit objectives. Now, very difficult, and the boundary between a minor nonconformity and a major nonconformity is not always easy to define. We can of course agree that if a finding to be conform, if an auditor observes that one transaction in thousand did not meet the requirements, but similarly we can agree that a finding indicates a major nonconformity if 800 transactions in 1000 do not adhere. But nevertheless, it's not always a clear distinction between major and minor nonconformities Because you it's not always very easy to determine. So the specific context of the audit T and other relevant aspects are taken to into consideration when making such a distinction. So most certification bodies provide you with some kind of a checklist where an auditor needs to take a box to say if there is evidence, is there is a procedure, is there is a process where you can basically state if there is a conformity or a non-conformity. So the threshold between the types of audit findings is neither arbitrarily set nor applicable to all audit findings. It is set by the auditor and based on a very specific context of the audity. So that might even be that for one audit client it may be a major one and for another one it may be Maybe a minor one, depending on the judgment of the external auditor. The statement of nonconformity is, of course, the most significant part of documenting a nonconformity. As I stated, a statement is the output of the audit and it does also the input for corrective actions to be taken by the audit. So it needs to be written in a very clearly uh way and it should not be uh mistaken for audit findings and it should also not be a rephrasing or a restatement of that um uh issue. So the nonconformity needs to be written very clearly, it needs to be easily understood because the Audity will use that as an as an improvement action, and it might be the case that people who will work with the nonconformity uh weren't part of the audit. So it needs to be very clear uh what is meant with it and and if it's poorly communicated, poorly written, it will uh make things different Equally important, nonconformity should be recorded and documented systematically by providing traceability and easy-to-follow progress reviews and evidence for the completion and effectiveness of corrective action. So, auditors usually use a non-conformity report form, something like that, by means of recording the non-conformities. And usually audities get that document sent where you get a description of the non-conformity. with a decision with okay this is evidenced by. So if you drive draft a non-conformity report there are a couple of things that you need to keep in the back of your mind So if an audit finding indicates a nonconformity, you need to document it in a non-conformity report and it basically includes three items. First of all, you need to describe The requirement for which the non-conformity was detected, which is basically the audit criteria. Secondly, you need to describe the observed non-conformity. including the evidence supporting the findings and you need to write the type of nonconformity as it a major or a minor nonconformity So, this is for most auditors one of the more difficult things to do to really write it in a correct way So it might be as simple as writing the description of the observation and referring it back to the respective standards requirement. But it is very important that it's very specific in order to avoid any potential misunderstanding. So again, I've already stated it. It's possible to identify findings related to multiple criteria. So it depends a little bit on the arrangement with the audit T, but you can either create separate findings for each criterion. or create one single finding where you include the reference on multiple uh criteria. So this is basically such a non-conformity report. This is an example. So And here you see basically the number of the non-conformity, also always very easy for clients to follow up. You have the name of the client, the file number. The relation to the process that you have audited, the link to the controller class number, in this case it's annex A5. 9. The site was Montreal and the audit criteria is basically what is written in Annex A5. 9 and information an inventory of information and other associated assets including owners shall be developed and maintained. So Then the description of the observed nonconformity. In a sample of 25 assets analyzed originating from the asset list, only five of them were correctly identified. You have the name of the auditor, the date when it happened, an indication of major and or minor, and acknowledgement by the auditive representative that the person is Okay with the non-conformity. So you can also add in this case this is evidenced by usually you add documentation or the name of the asset list that is associated with your findings. So you need to fill it with enough evidence where you can also conform it and to communicate it to your client as well The benefits of the doubts. So an auditor cannot raise a non-conformity if they do not have an identified non-fulfillment of a requirement. So by default, the benefit of the doubt um applies in all cases. So an organization is considered to be conform to the requirements of ISO 2701 as long as there is no evidence to prove the opposite. So the processes, controls, and divisions that the auditor did not have time to check will be considered conform. So auditors should use their work documents to plan the auditing of those parts in future surveillance audits. So that also means that the role of an auditor is not um to find non-conformities. I see that a lot with auditors that I work with. That auditors want to find non-conformity. The purpose of an audit is to verify conformity. So you need to have an open look, you need you want to be curious, you're not there to find Nonconformities. You don't have a KPI on the number of nonconformities you find per customer. So if there is no evidence of the nonconformity, there is no nonconformity. If there is evidence of a non-conformity, you need to document So that's basically a very important thing to raise. Your role is not to find non-conformities, but to verify conformity. So, as a summary, audit findings are results of the evaluation of the collected audit evidence against audit criteria. A minor nonconformity is the partial fulfillment of a requirement, but does not bring a risk To the total capability of the ISMS. A major non-conformity is the non-fulfillment of a requirement or a total failure of its effectiveness. An observation is then a situation or an element observed during the audit that may be subject to improvement without necessarily being a non-conformity. An anomaly is a deviation from a requirement or from the target set by the organization, but that still remains within the organization's established and acceptable levels. Nonconformities should be documented in the nonconformity report, and the nonconformity report specifies the audit criteria, the nonconformity type, major or minor, and the description of the observed nonconformity. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S18-Audit-documentation-and-quality-review.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S18-Audit-documentation-and-quality-review.md index 61c09c4..282d553 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S18-Audit-documentation-and-quality-review.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S18-Audit-documentation-and-quality-review.md @@ -13,6 +13,8 @@ status: active ## Abstract +This session covers audit work documents and the quality review process. Work documents support audit evidence, document findings, and provide traceability; they are the property of the certification body, not the auditee. Example work document templates are shown for physical security controls, including fields for clause reference, audit procedure, notes, documentary references, interviewee details, and conformity status. Audit records encompass all documented information gathered during the audit. The quality review process involves peer review by the audit team leader and another auditor to verify that evidence is relevant, reliable, and sufficient, and that findings are logically supported. Common mistakes encountered during quality review are catalogued. + ## Transcription Hi there, thank you for joining me. This is section 18 for ISO 27001 lead auditor. We're going to talk about audit documentation and quality review. And as a part of that, we'll be talking about work documents and quality review. So this section is going to discuss the purpose of work documents and what auditors should include inside them. In addition, the importance of the quality review is also discussed in this section, how quality review helps the audit team to comply with the audit procedures. What potential mistakes can be encountered during the quality review, which should be avoided by auditors, and lastly, how to document the quality review itself. So work documents. Work documents serve as a the ability to support audit evidence Proof of the audit or proof to the audit quality and adherence or reference for future audits. So work documents should include Uh facts only. So the auditor should document only sufficient evidence to support the audit findings, but only facts. Now if those facts are observed because you did not have digital or written or any other form of evidence, but you personally observed it, then you can write observed, then whatever it is. Be written, these work documents should be written professionally and comprehensibly. Notes should be written concisely so that other auditors can understand what is written and why it was written and what was said. Thus, the auditor can use abbreviations and write in point form as long as the form is standardized and the terminology is known to auditors So be consistent in your terminology, which should not be too difficult amongst auditors. Identify the weak points Work documents sh must enable the rapid identification of any weak points in the audited management system and the arguments supporting the audit findings. So work documents are critical for the audit process because they allow you to record your thoughts, your findings, your observations. But we also need to understand that we we're going to point things out very quickly. Now, I don't know if it's in this section or not, but I'll bring it up right now. Work documents are the property of the certifying body. not the audit. They are a product that's created by the auditor, the audit team on behalf of the certifying body. So they belong to the certifying body, not the auditee. So here's an example of a work document. And the reason I say example is because there is no real requirement for templates. But most certifying bodies will have some templates that they're going to want you to follow, and each certifying body's template is going to be different. They could have more information, less information. They could have branding or logos or whatever. Just go with the flow with whatever the certifying body says. So uh you should be expected as an auditor, you should be expected to follow some sort of internally developed template So in cases like that, you must follow the template developed by the certifying body because that is part of their process on certification and using templates is a part of that If there's no work document template, the responsibility of developing one falls on the audit team leader. So ideally, again, from the efficiency standpoint, certifying bodies should have a whole bunch of templates and all you have to do is is use them. However, if if there is no template, again the team leader creates one. And the whole concept behind the template is that it's a standard document across the entire audit team So let's talk about this example. So here we have a clause, top left clause control. It looks like physical security perimeters. We talk about what needs to be, you know, the notes in the clause, security perimeters shall be defined and used to protect areas that contain information and other associated assets. Then we have the audit procedure. How are we going to review and look at the physical security perimeters? One of the options in the middle, observe the external environment, reception, alarm system, and so on. Who is the owner of the control? And then what's the audit notes? So in this case, equipment theft is the principal risk identified. uh at the entrance, the reception desk, and the inspection report confirms that the building meets the building code and and so on. There's also other evidence that could be added in there. There's documentary references like interior and exterior plan, risk analysis report, and so on. from different areas. We could have interviews, uh, that who are we going to talk to, what date and time we talk to them. Now for me, uh From my standpoint as an auditor, when I interview people, I don't use titles, I use their actual name, and I don't use just the date. I use the the date and the time as well as the time zone. You don't want to have a be in a position where security manager, you investigated or talked to this person on November 7th of 2022. Well, what time? When did you do that? Where did you do that? Was it online? Was it in person? And so on. Then we have conformity. C is means it's uh conforms with the requirement, and NC means it's non-conformity. It doesn't require Or it doesn't conform with the requirement. You could also have a date and signature if you chose to In some cases, I've seen people use initials. In some cases, I've seen them not do anything at all in relation to dating signature, but it can happen. Here's another example. Again, physical entry, Annex A 7. 2, secure area, same, basically the same thing. How are they going to audit that? They talk about verify lists of employees and their access rights. Again, owner of the control and so on. And then there's the notes from the auditor. So not really anything special in relation to templates. And again, we have documentary references, persons interviewed. And again, from my standpoint, I always use a real name uh a date and a time and a time zone that I did the uh interview. As well as in this in this example we have a non-conformity And it looks like it's nonconformity number one. So if there was another nonconformity, it would be nonconformity number two. And then there's also Dayton signatures of the meetings. So again, looking at example one. And going back to example two, uh there's no real firm template that has to be used. Uh there's no real requirement for any particular template. So if the certifying body has a template, use that, yeah You must uh use that. If the certifying body doesn't have a template, then uh the team leader creates one and it it works out. But It can really really be anything so long as it's consistent across the whole audit and everybody on the team understands that. So audit records archive. Audit records usually contain number one audit agreement So that's why there's going to be an audit in the first place. Uh audit plan, org chart for the uh audit T. Work papers and checklists used during the audit, interview and observation notes Correspondence, interview questionnaires, number eight, audit test plans, number nine, audit tests and their results, and then the evaluation of those results So that's in the archives. So audit documentation should clearly state the type of the document, how it was created or changed, and the person who not only reviewed it, but who created it. So who created it, who reviewed it? We want to protect the confidentiality of any information at all stages of the audit Especially when evidence is shared. Again, confidentiality is important unless it's a mandated reporting event. But if it's not legal, if you're not legally required to report something, then you have a confidentiality agreement. We want to make uh or prevent any potential changes to or unapproved changes to the uh the audit documentation We also want to protect it not only from the uh outside unapproved people, but possibly other people in the auditee environment. Remember, work documents are not the property of the auditee. They are the property of the of the certifying body. So, audit records represent the entire documented information gathered during the audit. Drafts, copies, previous versions, or other similar documents are not generally kept as records With the exception of the actual product that is created by the auditors or audit team, other documents like policy standards, procedures, screenshots. Things like that that are provided by the auditee to the audit team or the auditor are generally destroyed after there is a resolution or a firm understanding of what's going to happen in relation to the audit. So if it's a certifying audit and any evidence that's provided to the audit team that's not generated by the audit team themselves. It's it's not uncommon for the auditee to ask for those documents back or uh some sort of attestation that they were destroyed. And from the certifying body standpoint If they have the information and they don't need it anymore, then uh it's totally uh it's not under unreasonable to think that they're going to destroy it as well, whether the oddity wants to or not. So quality review. Work documents are the first audit evidence that get reviewed. So peer quality review enables all the audit team members to ensure compliance with audit procedures It's important to understand that quality review is performed by an experienced auditor. I'd also suggest that quality review, even though there may be a more experienced auditor on the team but everybody on the team get a chance to perform quality review. So reviewing of the work documents is necessary for ensuring that the audit procedures were appropriate, reliable, and used properly. The auditors have sufficient evidence or information to support their conclusions. And the audit findings and conclusions are logical and objective So, as a part of the peer quality review, peer quality is certainly a key element in generating high-quality work documents. And remember that certifying bodies as a part of competence, one of their options to make sure that people are performing high-quality work is to review audit reports or work documents or other things. Each auditor's work documents must be reviewed by the audit team leader. Documents of the audit team leader must be reviewed by another auditor. So we can't audit ourselves For solo audits, the review is done by another auditor mandated by the certification body. I've never been on a solo audit. I've only been in audits with Audit teams and generally the smallest one was only three people. The audit team leader must verify if the audit team members have followed best audit practices and established procedures. The audit evidence gathered is relevant, reliable, and sufficient. The established audit findings are based on strong evidence And any problems that were encountered during the audit were resolved. So, as a part of the quality review, the following is a list of potential mistakes that auditors usually encounter during Quality review. So number one, the template that contains information about previous clients was used. Yes, seen that before. Where you open up a template where a new client and a previous client stuff is already in there Auditors to uh forget to enter the information related to the person interviewed. Again, when you interview people, uh name, uh date, time, time zone, write down what their job is. Make sure you take adequate records. Auditors forgot to close notes and provide information related to it, like name, name, date, and reviewer. The information that auditors gathered was inconsistent. And information on the audited clauses could not be found. Like did they audit a particular clause but did not document it Uh I've seen that uh before where they legitimately interviewed, they legitimately saw the evidence, they just didn't write it down. uh to prove uh that they actually did it. So something we learned in the military is if it's not written down, it never happened. So make sure you write things down. All right, number six here, the evidence gathered was neither relevant nor reliable. So in this case, auditors did not document sufficient evidence to support the audit findings. You have to always make sure you have sufficient evidence. And then it's accurate. The sampling approach was wrong and not documented properly, so auditors did not clearly document or justify that the chosen sampling methodology. In relation to sampling, if you're going to request sampling because you have a large data set of some sort If you're not going to specify to the auditee exactly how you want the sampling done and you're going to leave it up to them, you should also probably ask for another So for example, if I had a thousand users in a database and I said to the auditee, I want you to provide uh ten percent of those thousand people so I can review them. So that's a hundred, hundred people, hundred users. How they came up with those hundred users would be important. Are they picking those hundred users because they know they're going to pass? Or is it the first hundred? Or is it every 10 person that they created the 100 users out of? So you want to document how sampling actually occurs There were errors in the samples section, so did not follow the selection rules during the evidence collection. For example, the audite selected and provided the list of persons to interview or prepared the sampling themselves. That's exactly what I just kind of described. Inconsistencies and nomenclature. So again, it's super important that everybody stay on the same page in relation to wording and terminology. Document the quality review. So here we have some examples. Note number one, clause 752, creating and updating. Comments of the reviewer, looks like they marked some things out, answers of the prepare, whatever the change was has been implemented. So you can see that there's multiple areas uh where uh notes were entered, uh comments were made, and then there were um Responses from the prepare. So number two, uh the evidence collected is not related to the control objective of physical entry, and then there's a red line. The evidence the objective of the control is to verify that the perimeter enters through a physical access control point, not the existence of the perimeter. So the first black line, the evidence collected is not related to the Control objective, the preparer says, in my opinion, the presence of a two-meter security wire fence demonstrates the existence of a security perimeter. And the reviewer responds by saying The existence of the perimeter is not the objective of the control to verify physical access control point So then the preparer responds by saying, okay, I added a note on the need for additional evidence. So there's a little back and forth between the reviewer and the preparer in this case, and that's not uncommon at all. So be aware of that. But again, there's there's not really a template that needs to be followed to do this. Just understand that every time you create a document, if somebody reviews it. and disagrees or whatever, then uh there needs to be some sort of resolution before you submit it. Alright, and this is the summary for section 18. Auditors must create and keep work documents during the audit in order to support audit evidence, to serve as reference for future audits, and to serve as proof to the audit quality. Work documents must be written concisely and professionally and must include facts. Audit records represent the entire documented information generated During the audit, drafts copies, previous versions, or other similar documents, and are not generally kept as records. Peer quality review is a key element in generating high-quality work documents And the documents of the audit team members are reviewed by the audit team leader whose work documents are reviewed by another auditor. So again, just like previous sections, there's a quiz with this one, quiz 17. So open up the quizzes worksheet and uh Take that quiz, and with that I'll see you all. See you on the next one. Thank you. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S19.1-Closing-of-the-audit.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S19.1-Closing-of-the-audit.md index 68c8db5..309366c 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S19.1-Closing-of-the-audit.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S19.1-Closing-of-the-audit.md @@ -12,6 +12,8 @@ status: active ## Abstract +This session covers the closing phase of the stage two audit, including determining audit conclusions, conducting the closing meeting, and making a certification recommendation. Four possible recommendation outcomes are described: full certification, certification conditional on corrective action without a revisit, certification conditional on corrective action with a revisit, and an unfavorable recommendation. The session explains how audit conclusions differ from audit findings and must be based on evidence and criteria, not assumptions. The closing meeting agenda and required elements per ISO 17021-1 are detailed, including presenting nonconformities, handling questions, and explaining the appeal process and corrective action timeframes. + ## Transcription Hi there, thank you for joining me. This is section 19 for ISO IEC 27001 Lead Auditor. This is closing of the audit. So we've done stage one, stage two And now we're closing the audit itself. In this section, we're going to talk about the steps of closing the audit, which includes determining the audit conclusions. discussing the audit conclusions, conducting closing meetings, preparing and distributing audit report, and completing the audit. So as you can see, and then we're also going to talk about making the certification decision and then Finally closing the audit. Alright, as a part of the audit conclusions, uh we're gonna determine and agree on audit conclusions. draft the audit conclusions, conduct the closing meeting, prepare and distribute the audit report, and then make a uh the certification decision. And when I say the make the certification decision, that's not the auditor. uh to do that. That's the certifying body. The auditor makes a rec a recommendation for certification. So uh there is an exchange of information for closing the audit. The following are some of the summaries of the information that gets exchanged after evaluating the evidence gathered during the audit, the audit team. uh presents their findings and observations, including nonconformities to the auditee. The auditee accepts the audit findings provided, but if they don't, then they uh provide additional information to justify that. But they're generally in most cases they're going to accept uh your findings because they're actually the ones who provided evidence. That created you, uh, that gave you the opportunity to have those findings. All right, then the audit team uh presents the audit conclusions to the audit T. And issues a favorable or unfavorable certification recommendation to the certifying body. Then they present the uh the findings and everything else, uh the audit conclusions to the Auditee's management. The Auditee accepts the audit conclusions and the certification recommendation. Or they don't, and then they uh they appeal. Uh but then there is a closing meeting of the and the closing of the stage two audit report or the creation of the stage two audit report It's sent off to the auditee where if they agree, then awesome. If they don't agree, then they can appeal. They also may be required to have some sort of action plan. in order to uh remediate any nonconformity that was uh a finding by the audit team. It's it's important to understand there is an appeal process that the auditee can uh choose to use if they chose to. Um it's that doesn't mean that you're wrong as the auditor or they're right as the auditee But uh occasionally uh appeals do happen. The auditee does not have to absolutely accept your findings or your report just because it's you creating it So if there is a nonconformity, then there are action plans that will be required to be created by the audit. They submit the action plans to the audit team and hopefully start right away. The auditee then implements corrective and preventative measures to hopefully fix whatever whatever problem there was. And then assuming they get certified by the certifying body, then they'll have that. And then later on down the line, there'll be what's known as a surveillance audit. Okay, so I'm going to talk about surveillance audit real fast A surveillance audit after the certifying body says yes, the audit T is uh certified. Uh In a year, there's what's known as a surveillance audit, which is a it's still an audit, still follows the same process, but it's uh less intense than a certifying audit. All right, determine and agree on audit conclusions. We're going to uh talk about that now. Uh this is 19011 clause 6. 4. 9. 1, the audit team should confer prior to the closing meeting in order to review the audit findings and any other appropriate information collected during the audit against the audit objectives. Also, agree on the audit conclusions, taking into account the uncertainty inherent in the audit process. Prepare recommendation if specified by the audit plan and discuss audit follow-up as applicable. Once we've had that meeting, there's going to be a certification recommendation. When concluding the audit, the auditor must issue one of the four following Recommendations related to certification. Number one, recommendation for certification. That's the one that everybody wants. Recommendation for certification conditional upon the filing of corrective action plans. without a prior visit. So that means that the auditor found something that needed to be fixed. They're okay with recommending for certification But there must be a corrective action plan of some sort that does not require a prior visit. So that that could mean that the corrective action plan involves some sort of technical uh evidence that could simply be emailed. Uh or possibly if there's an internal auditor uh team inside the auditee environment That the uh internal audit team is uh trusted enough to provide uh assurance that the corrective action plan was accomplished. There's also recommendation for certification conditional upon the filing of corrective action plan with a prior visit. Much like number two, this is where same thing, except for they have to show up and see it personally And then there's also unfavorable recommendation for certification. This is the one that the clients don't want. Because this means they're not going to get it. They're also not going to get a refund on their money. So ideally if a client's fully prepared, uh best case scenario is you get a number one recommendation for certification. Uh occasionally you might get a recommendation for uh certification upon the filing of corrective action plan. Uh but I personally have never run across uh corrective action plans required uh as well as a another visit. All right, discussing audit conclusions. So prior to the closing meeting and submission of the final audit report It's important that the audit team discuss the audit findings with the auditee's management so that any oversight or misunderstandings are avoided. Here's another one. So the management is not caught by surprise. You don't want to surprise management in relation to findings. The management is given an opportunity to answer certain questions and provide new evidence. The audit conclusions are corroborated with the auditee's management. The implementation of corrective actions as soon as possible is encouraged. So discussing audit conclusions is really being very polite and professional in relation to the interaction between the audit team and the audit tee. If there is a possible finding of some sort, making them aware in advance is certainly an opportunity to relieve a lot of stress. As well as uh possibly uncover issues that were not previously fully understood. So, for example, let's say you uh you audited uh auditee for some control It doesn't matter what the control is, and they just gave you bad evidence because they didn't understand what you're asking for. And then you you you know judged that to be a non-conformity and you brought brought it up to the management or or the auditee's uh team and they said, Oh, uh my gosh, we uh were totally wrong in what you we thought you were asking for. Are you asking for this and if that's what you're looking for? then maybe that gets gives the uh the uh auditee a little bit uh flexibility. But again, from the audit conclusion standpoint, you never want to surprise them uh the oddities. You never want to surprise them with uh situations that uh they're just not aware of. It's it's not going to be a good uh pleasant conversation. So the audit team must ensure that the audit report contains evidence that's accurate and that the audit conclusions are easily understood by the auditee's management So again, write your audit, write your reports, your findings, and so on to the audience that you're presenting it to. Not overly technical, but uh straight to the point and direct. So hence the discussion between the audit team and the audit team prior to the submission of the final audit report is important to avoid any potential misunderstandings. Lots of reliable communication. So possible reactions from the auditee. They accept the conclusions. They submit new facts. That's possibly because they didn't understand or they did not provide enough evidence Or maybe it's just an inexperienced auditor. They look for solutions. How can they employ compensating controls that can solve the problem? They negotiate the conclusions, deny the facts, or adopt a hostile approach saying that the auditors they don't know what they're doing or maybe uh they're totally wrong, uh things like that. And then also certainly possible, seek to assign blame to a person. Now they're not going to be able to blame the auditors unless the auditor or the audit team was a gross negligence. uh as you know from the stages of negligence of uh gross negligence or fraud but the reality of it is is they may uh the audite may attempt to blame internal people internal to the auditee's team just because that's their the culture of that company. So we want to draft the audit conclusions. So audit conclusions must be drafted and reported. Auditors should draft the audit conclusions based on evidence that is examined. And its adequacy is evaluated in terms of quality and quantity. The auditor must draft the audit conclusions based on evidence and facts, not on assumptions. The auditor must also consider in the audit conclusions any revisions that resulted from the closing meeting or other discussions. The auditor must draft the audit conclusion against the audit criteria, and this should be pointed out in the audit report. So audit conclusions are not a summary of the audit findings but a conclusion based on the audit criteria. So 5. 3 conduct the closing meeting. So this is out of 17021-1 clause 9. 4. 7. 1 So a formal closing meeting where attendance shall be recorded shall be held with the client's management and, where appropriate, those responsible for the functions or processes audited So who? Audit team, members of the audites management. So basically everybody on both sides that were involved in the audit. What? We're going to present the audit conclusions and the certification recommendation. And again, clients want to hear that you're going to recommend certification. Where in a conference room, and again, this could be over Zoom, that's very popular now, when on the the last day of the on-site audit. So the closing meeting agenda, here's an example, the attendance list, we're going to take attendance acknowledgements. You could The team leader is going to thank people for being there. Thank you for your help. Thank you for your uh, you know, making this efficient and easy. and so on. Then we'll recap uh audit objectives and scope. Then we'll recap or present for the first time official findings relating to the audit and the conclusions. Presentation of any nonconformities if there are any limitations of the audit, questions and answers, and then there's an audit follow-up. Now, in relation to presentation of non-conformities, uh again Certifying bodies are going to have a template for everything. So I I use a I literally use the PECB template for documenting non-conformities because it works great. So if you're going to present non-conformities, understand the audience that you're presenting to. How you present it could be very simple or it could be very complex, but we want to definitely understand the audience that is that is uh participating. Also under questions and answers, you should expect as a on the audit team, you should expect numerous questions So be prepared to answer all of it. They'll ask you what's next, when are we going to do a surveillance audit? Are you going to do the surveillance audit? Uh if there's anything involving a corrective action plan, they're most likely going to say, how long do we have? Do we have to Do we have to do it within the time period that you're saying we have to do it? Can we do it next year? All sorts of different things that can come up. So be ready for that. And just kind of go with the flow, be very professional and responsive. So other topics to address in the closing meeting out of 17021-1 clause 9. 4. 7. 2? So the closing meeting shall also include the following elements where the degree of detail shall be consistent with the familiarity of the client with the audit process. Advising the client that the audit evidence obtained was based on a sample of the information, thereby introducing the element of uncertainty. The method and timeframe of reporting, including any grading of audit findings, the certification body's process for handling non-conformities including any consequences relating to the status of the client certification, the timeframe for the client to present a plan for correction and corrective action for any nonconformities identified during the audit. The certification body's post audit activities, and information about the complaint and appeal handling process So uh if we talk about this a little bit more, remember just speak unless they're you're gonna recommend certification right off the bat They don't have to accept your your findings as as fact and accept it. They can go through an appeal process or a complaint process if they feel justified to do so. There could be a case where a client may go through the appeal process just because they can't handle that they didn't pass. So there's that. Uh but the other thing that's comes up that I've seen a lot is the time frame for the client to present a plan for correction or corrective action. For any nonconformities. Most clients, they're not very receptive to the fact that they have to fix something within 30 days. And they'll they'll most likely say Well, this is really going to impact our revenue, our business. It's going to disrupt our business, things like that. And that may be that may be true, but the reality of it is that If it takes forever to implement a corrective action plan, then essentially the entire environment could have possibly changed during that time. And it would be not very realistic for you to recommend certification six months after the fact because the other areas of the environment may have changed So it's there's there could be some risk there. So again, time frames for correction, uh things like that, that's that's something that uh comes up a lot. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S19.2-Closing-of-the-audit.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S19.2-Closing-of-the-audit.md index ccfd0bf..9a4fed8 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S19.2-Closing-of-the-audit.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S19.2-Closing-of-the-audit.md @@ -12,6 +12,8 @@ status: active ## Abstract +This session covers audit report preparation, distribution, the certification decision, and audit completion. The audit team leader is responsible for the audit report content, which must be clear, accurate, and sufficient to support the certification decision. Required contents per ISO 17021-1 are enumerated, including audit criteria, scope, team members, findings, nonconformities, and a sampling disclaimer. The certification decision is made by the certification body, not the auditor. Distribution should be controlled to maintain confidentiality. The session also explains how audit completion is handled, how lessons learned are captured, and describes the structure and public nature of ISO 27001 certificates, including the three-year certification cycle. + ## Transcription All right, prepare and distribute the audit report. The audit team leader must be responsible for the preparation and the content of the report The audit report must be clear or must provide a clear, accurate, concise, and complete representation of the audit. The audit report must be recorded in writing The certification body maintains ownership of the audit report. So again, the audit report is not the uh property of the auditee. Neither is the work products, neither are the work products. The only thing that remains a property of the auditee is the actual evidence that is provided by the auditee. So we do need to make sure that we are clear, concise, and we've had every bit of evidence and explanation that is needed in the audit report is included in the audit report. Contents of the audit report 17021-1 clause 9. 4. 8. 2. The audit team leader shall ensure that the audit report is prepared and shall be responsible for its content. The audit report shall provide an accurate, concise, and clear record of the audit to enable an informed certification decision to be made and shall include or refer to the following Identification of the certification body, the name and address of the client and the client's representative. The type of audit. So is is an initial surveillance or recertification or is it a special audit of some sort? The audit criteria, the audit objectives, the audit scope, particularly identification of the organizational or functional units. Or processes audited and the time of the audit. Any deviation from the audit plan and their reasons Any significant issues impacting on the audit program, identification of the audit team leader, team members, and any accompanying persons. Contents of the audit report. I do want to add one other thing. Generally, the certifying body is still going to have some sort of template that Jill follows. So it's not like you're going to have to create this on your own. If you're working with certificate certification body, then just ask them, do you have a template for the audit report? And it's provided they do, then generally you just have to fill in the blanks Fill in the paragraphs. So continuing on with the uh audit report, uh the dates and places where audit activities occurred, whether it's on-site, off site. uh virtual or over the phone, just like literally verbal over the phone, where it's conducted. Audit findings, relevance to evidence to evidence and conclusions. Consistent with the requirements of the type of audit. Significant changes, if any, that affect the management system of the client since the last audit took place. Any unresolved issues if identified, where applicable, whether the audit is combined, joint, or integrated. And again, remember that a combined audit is when you have more than one framework being audited at the same time. So in a previous section, we used ISO 27001 and 9001 at the same time. So auditing two different frameworks and so on. There's also joint audits working with another audit team. A disclaimer statement indicating that auditing is based on a sampling process of the available information. Recommendation of the audit team. And again, remember recommendation for certification are what the auditees are going to be looking for. The next one that's kind of less of a hassle is recommendation for certification provided There is a correct action plan provided that is and does not require on-site visit again. The audited client is effectively controlling the use of the certification documents and marks if applicable Verification of effectiveness of taking corrective actions regarding previously identified nonconformities, again, if applicable. Alright, then we have contents of the audit report. The audit report shall provide the following information or reference to it: an account of the audit of the client's information security risk analysis. Any information security control sets used by the organization for comparison purposes as required by could be legal, regulatory, contractual The audit report shall be sufficiently detailed to facilitate and support the certification decision. It shall contain the significant audit trails followed and audit methodologies utilized And a reference to the version of the statement of applicability and where applicable, any useful comparison with the results of previous certification audits of the client. All right, distributing the audit report. So this is 1901, clause six dot five. The audit report should be issued within an agreed period of time. If it's delayed, the reason should be communicated to the auditee and the individuals Managing the audit program. The audit report should be dated, reviewed, and accepted as appropriate in accordance with the audit program. The audit report should then be distributed to relevant interested parties defined in the audit program or audit plan. When distributing the audit report, appropriate measures to ensure confidentiality should be considered So what uh what we do, what we personally do, when we have a uh uh uh An audit report that we're going to distribute, we only distribute the audit reports to one person, and that's the contract holder that required the audit in the first place So whoever that person is, they're the person that the audit report is distributed to and it's only distributed through uh like DocuSign. uh some some electronic something that requires an electronic signature saying they've accepted it. We do this because if we distribute it to only one person and it goes anywhere else after that one person That's the responsibility of that one individual. Plus, we have a record that says, you know, January 1st, 2025, we gave John uh this audit report, here's his electronic signature indicating acceptance. The other thing about the audit report, if there's non-conformities in there, uh Each nonconformity, because it's electronic signature, each nonconformity can be attested as being received by that signature holder, by the contract holder. So that last one there where it says when distributing the audit report, appropriate measures to ensure confidentiality should be considered Again, we just send it to one person, the contract holder, and if they send it to other people, then it's on their shoulders for confidentiality. We don't have to worry about it. We don't even share in even internally, we don't share uh audit reports uh even with other internal people. So 5. 5 make the certification decision. The certification body must make the certification decision based on an evaluation of the results and conclusions of the audit. Any other relevant information, for example, public information or client comments on the audit report. So auditors that take part in the audit itself never take part in the certification decision. So you can't uh you can't make a recommendation for certification and then make the decision for certification at the same time So the information provided by the audit team to the certifying body for the certification decision shall include at a minimum the audit report, comments, nonconformities, where applicable, corrective, corrective action plans, and so on. uh all sorts of other things that are in there that um help the certifying body make a decision one way or the other. Generally, if the auditors recommend certification, the certifying body is most likely going to accept that recommendation. There may be a few cases where there's not enough evidence or the audit report was not written uh clear enough that the certifying body could not make a decision one way or the other. And they asked for clarification uh from the auditor Then there's completing the audit clause 6. 6 out of 1911. The audit is completed when all planned audit activities have been carried out or as otherwise agreed with the audit client. Such as there could be an unexpected situation that prevents the audit from being completed according to the audit plan. Who knows? Maybe somebody you know uh went on vacation, got sick, had a had a baby Uh and there maybe that person was critical to being interviewed or performing a demonstrating a process. There's all sorts of different things that could happen. Documented information pertaining to the audit should be retained or disposed of by agreement between the participating parties and in accordance with audit program and applicable requirements. As I indicated before, uh other uh entities when they uh have information after the audit report and certification decision has made. If there's nothing critical, then information is simply destroyed. Lessons learned from the audit can identify risks and opportunities for the audit program and the auditee. So there could be methods by simply having the audit, whether they pass or fail, to identify room for growth and how to mature. And again, remember that unless you're granted permission or it's required by law, do not disclose anything in relation to the audit, audit activities, or even who you talk to as a part of the interview. Alright, closing the audit aspects to take into account when closing the audit, first off is the format. The evaluation form should be brief. questions concise the time required to complete this form should not exceed 20 minutes. So that's realistically a how did we do? An evaluation of the auditors. Delay the evaluation form must be completed following the end of the audit mandate. Then there's also report and follow-up evaluations, compilation of the audit evaluation results. Should be sent to the audit team. Again, how did we do? Could we do better? Were we not clear enough? Were we not competent enough The evaluation by the auditee is a significant source of information for improving the audit practices of the audit team and the audit team members The evaluation of the auditors and the audit team leader should be recorded and retained by the certification body to provide a basis for the annual assessment. of each auditor. Remember each certifying body is required to ensure the competence of each auditor. So this is one way they can do that. It makes life easy for them. All right, uh closing the audit. The certificate that is issued by the certification body contains the following information: the name and geographical location of the auditee Date and expiration of the certificate. In most cases, it's going to be three years. Unique identification code, that's basically the serial number for the certificate itself, and that serial number is associated. To the auditee from by the certifying body. The standard against which the auditee is certified, so like 9001, 27,001, and so on. ISMS scope Name and address of the certification body. And it's important to understand because a lot of people don't, that for example, ISO 27001, 9001, that information is public. It's doesn't require non-disclosure to send somebody a copy of your 27,001 or 9001. So if you're um If you're in this course, then obviously you're going to be a lead auditor. And if as a part of that You know, if you're going to help companies get ready for audit or something like that, then uh if you suspect that a vendor of a client is uh ISO 27001, There are various online databases that you can look up companies, but you can also just ask them and say, can you send me a copy? If they uh say no you need a non-disclosure to get a copy of the 27001 certificate, then that should give you an indication that they truly don't understand 27,001. There is also a new uh database, worldwide database that's coming out. I can't remember the name of it right now, but uh there is a new worldwide database coming out where all certifying bodies are going to be required to put uh all of their certifications for for uh auditees in that one centralized database uh to make it easier to do the research Here's an example of a certificate. It looks like that. So XYZ uh strangely looks like the PECB fonts. Is uh offering a certificate to ACE Corporation for 27,001. The old version, 2013 That's what it looks like. So it's the certificate's valid for three years before this validity of the certificate ends. The organization has to be recertified. In between the initial certification and the recertification, there's also going to be what's known as surveillance audits. And a surveillance audit is an audit of a smaller nature, but just as critical. The following are a few examples of scopes as declared by certified organizations. The ISMS scope covers the protection against external and environmental threats. The ISMS scope covers the protection of confidential information. The ISMS scope covers the monitoring of outsource system development The ISMS scope covers the detection, prevention, and recovery control to protect against malware. So in that certificate, I think it's really small, but in that certificate where below ACE Corporation that would be uh where you'd have the scope declared. But it'll be on that certificate somewhere or another All right, this is the summary of section 19. The audit team should confer before the closing meeting to review the audit findings. Agree on the audit conclusions and prepare recommendations and discuss the audit follow-up activities. Recommendations relating to certifications include the recommendation for certification, the recommendation for certification, Conditional upon filing corrective actions plans without a prior visit, then the same thing but with a prior visit. And the unfavorable recommendation for certification. When discussing audit conclusions, possible reactions include accepting the conclusion, submitting new facts, or at least wanting to submit new facts. Looking for solutions that can make your nonconformities go away, negotiating the conclusions, denying the facts, or adopting a hostile approach Or seeking to assign blame to a person. There's a variety of different things that could happen. I personally have never been involved with a situation where seeking to assign blame or denying facts or adopting a hostile uh approach. I have seen negotiating, but the reality of it is is there's not really a negotiation. They're either doing it or they're not. And they're either compliant or they're not. The audit report must provide a clear, accurate, concise, and complete representation of the audit, be recorded in writing, and be compiled by the audit team leader Aspects that should be considered when closing the audit are format, delay, and reporting and follow-up evaluations. And much like other summaries, other sections, there is a quiz, so go to your quizzes worksheet and uh Give it a shot. And with that, I want to thank you for your time. I will see you on the next one. See you. Bye \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S20-Evaluation-of-action-plans-by-the-auditor.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S20-Evaluation-of-action-plans-by-the-auditor.md index c34afc1..140861e 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S20-Evaluation-of-action-plans-by-the-auditor.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S20-Evaluation-of-action-plans-by-the-auditor.md @@ -12,6 +12,8 @@ status: active ## Abstract +This session explains how action plans are submitted and evaluated following audit nonconformities. Each nonconformity requires a separate action plan containing a description of the nonconformity, a root cause analysis, and specific corrections and corrective actions with realistic timelines. Action plans are typically due within 10 to 60 days depending on the certification body; failure to submit results in an unfavorable certification recommendation. A worked example is provided for a nonconformity related to information security continuity (A5.29). The auditor's role is to evaluate whether submitted action plans adequately address root causes and are realistic given organizational context and available resources. + ## Transcription Section 20 discusses the submission of action plans and what the auditee should consider including in them. In addition, there are some guidelines as provided for auditors when evaluating those action plans. So if you have found a major or a minor nonconformity, the oddity needs to submit. An action plan. So there needs to be a couple of things in that action plan. So you need to of course describe the detected non-conformity The audity also needs to analyze the root cause of the detected nonconformity and the specific corrections and corrective actions taken or plan to be taken to treat the detected non-conformities within a defined period. So there are a couple of things. Root cause analysis, what was the reason? But you also need to think about corrections and corrective actions and the time period in which You need to implement it. So an action plan must be submitted for each nonconformity separately. So not one general action plan for all non-conformities together So if the audit's management um following the analysis and the root cause decides to accept the risk. Instead of implementing a corrective action, it must also justify the decision and document it appropriately. Action plans usually need to be submitted within a specific time frame and it also is dependent from certification body to certification body. Usually there's a deadline between 10 to 60 days If the action plan is not received within that specified time period, the audit will obviously not be recommended for certification. So looking at the content of that action plan, so there need to be a couple of things in there. So it's not necessary to submit a very detailed action plan and like cost involved firm selected project plan. So it's only a general statement uh regarding the actions that need to be taken. However, it needs to be a realistic action plan with timelines that are realistic. uh but also uh cost etc uh being included there as well. So if you need a s uh extensive budget you need to take that into account that you will probably not be able to implement the solution in uh in two months for example. So action plans can of course include the correction of the nonconformity. You uh should add a completion period. Um you want to add uh sometimes the obtainment of verifiable results so that it's Easy for the auditor to check if the results have been achieved, as well as the elimination of root causes. So on the following slide, you see an example of such an action plan. You see, it's very uh high level. So you get the number of the non-conformity, which is the same number if that you get from your auditor. Uh, the process that has been uh discussed is the information Security during disruption, which was clause A5. 29, and the first part you get from the auditor. The description of the non-conformity: there is no procedure in place to ensure the required level of continuity for information. security during an adverse situation such as a crisis or a disaster. This one you usually also get from your auditor because they need To describe it as well in their audit report. And then the root cause and the action plan is something that you need to come up with or that the organization needs to come up with. So the root cause in this case, the organization determined that there is a lack of personnel and management awareness. about the information security awareness and a decided on an action plan being the names of the persons to be contacted in case of a crisis or disaster must be listed in the information security continuity plan that will be done immediately and the procedures to contact these persons must be documented and communicated So uh an auditor receives obviously um the action plans uh back. Um so the auditor then needs To reassess or evaluate the project's plan, and that's based on their experience and knowledge, if the action plan that was submitted is appropriate and will address the root cause of the non-conform. So, first of all, the LDT must inform the auditor about the completion status of the corrections and the corrective actions. So usually you get that timeline you need To send the action plan back and the auditor receives it, then the auditor takes some time to have a look at the root cause analysis, the timelines, the corrective actions. And then, of course, it's very important to remember, depending on the number of non-conformities. that an audit has resulted in. Not all the corrections and corrective actions have to be implemented immediately. So as an auditor, it is also not a right expectation to think that everything will happen at the same time. So um every improvement basically requires the necessary resources and time for the implementations. So you can decide as an organization and you You should do that as um to um prioritize basically the action plans, um especially those that require investment. Sometimes you need to wait for the next budget round. So um the auditor also needs To check based on the timelines and the context of the IDT of the action plans are realistic So short summary, action plans must describe the detected nonconformities, the root causes of the detected nonconformities, and the specific corrections taken or planned to be taken. If action plans are not submitted within the specified deadline, the audit is not recommended for certification, and the auditor should also evaluate if the action plans are appropriate and address the root causes of the non-conformity. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S21.1-Beyond-the-initial-audit.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S21.1-Beyond-the-initial-audit.md index 315cc59..e07092c 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S21.1-Beyond-the-initial-audit.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S21.1-Beyond-the-initial-audit.md @@ -12,6 +12,8 @@ status: active ## Abstract +This session covers the activities that follow the initial certification audit: follow-up audits, surveillance audits, and recertification planning. Follow-up audits for major nonconformities are typically conducted four to twelve weeks after the initial audit and focus on verifying corrective action effectiveness. Minor nonconformities are usually tracked through surveillance audits or internal audits. Surveillance audits are mandatory once per calendar year (except recertification year) and must occur within 12 months of certification. Mandatory surveillance audit topics include management review, internal audit, action plan review, objective achievement, continual improvement, operational planning, and use of certification marks. + ## Transcription Section twenty-one provides information about what will happen during surveillance audits and recertification audits. So when we look at the audit program management, we have arrived at the last phase, which is six beyond the initial audit. So there are three activities or three tasks that need to happen then So, first of all, you need to conduct audit follow-up activities, you need to conduct surveillance audits, and of course, you need to plan and conduct recertification audits. So let's take a deeper dive First of all, based on the audit conclusions, of course, an auditor might need to conduct an audit follow-up before the audit T is recommended for certification. So during that audit follow-up, an auditor evaluates again the effectiveness of all the corrections and corrective actions. So that usually happens when a major nonconformity has been uh written during uh the stage two of an audit. So that follow-up uh activity uh should also of course be uh planned carefully um and in detail just in the same way as you've done in a stage one and in a stage two. So during that stage two audit, you will have a look at the non-conformity report that the auditee has submitted and you will check if the implementation was successfully. So usually the audit follow-up is conducted between four to twelve weeks after the initial audit, so that the auditee is really giving time to implement the corrective actions. And the conduct is of the audit is usually done within a day. It might even be shorter, depending on what it actually is So that audit follow-up, and one thing to remember is when you have a major uh non-conformity, usually a special audit or an audit follow-up uh will be uh scheduled So again, we will be reviewing there, of course, the effectiveness of the implementation. And of course, again, the clients shall be informed of the result of the review. and uh the verification so you will also um be informed if there is such a follow-up audit and after that follow-up audit you will also get the feedback or you need to give the feedback to the client that um he that the client will be um uh Proposed for certification. So an alternative to audit follow-up can also be, of course, an internal audit and a surveillance audit So when it's a minor nonconformity or observations, usually no audit follow-up is being scheduled, but there can be other means where you can do it. So for a minor nonconformity, uh usually the auditor will not perform uh a special audit. Uh we will then follow up um during a surveillance audit um or you can also follow those up uh through the internal audit. So what I see uh happening a lot is that When you have a minor non-conformity, we will follow it as an external audit in the surveillance audit to check if it has implemented. But organizations usually do their effectiveness check So they they implement the corrections and the corrective actions and they ask the internal audit to check the effectiveness. So that way you have a double check. So uh as stated it can be part of an upcoming uh surveillance audit. You can ask an internal audit team to look at that And sometimes we can also do an audit, we can also do a remote audit, of course, to check if the non-conformity has been solved. Nonconformities are usually individual in nature and uh a number of activities and methods can be used. to determine of the effectiveness has been taken. So before taking the decision to close a non-conformity, you should review That the corrections have been implemented, the corrective actions have been done, and a root cause analysis has been conducted. So has that been done? Um if as stated in the 1721 ISO standard certification body shall develop its surveillance activities so that representative areas and functions covered by the scope of the management system are monitored on a regular basis and take into account changes to its certified client and its management system. So an auditee must inform in all cases the certification body if there are any changes that have an impact on uh the management. system that might be uh an increase or a decrease in the number of employees, acquisitions, downsizing, mergers, all those kind of things need to be um needs the certification uh to be informed of So a surveillance audit issue is shorter than the stage one and stage two audit um and not the whole ISO standard will be checked. It will only be certain parts of the standard. But an auditor will also come on site to check certain requirements with respect to the standard. So of course other surveillance activities may of course also include a you more certification bodies ask questions to the certified uh clients to see if there were any complaints um to see how they uh use promotional material uh so to see what statements that they use. They want to ask if there were any uh changes in the organization They request certified clients to provide certain elements of documented information. So depending on the certification body, there might be more or less information that needs to be provided. Surveillance audits are on-site audits, but are not necessarily full system audits. So they are planned together with other surveillance activities so that the certification body can maintain That confidence that the client certified management system continues to fulfill requirements between recertification audits. So there are a couple of things that are mandatory to check during a surveillance audit. So what are those things? So the internal audit and the management review need to be checked during every surveillance audit You also need to have a look at the review of actions taken on nonconformities identified during the previous audit. You need to check any sort of complaints that the customer had. The effectiveness of the management system with regard to achieving the certified client's objectives and it tended intended results. So you want to have a look at the ISMS objectives. You want to have a look at continual improvement. You want to have a look at operational planning, review of any changes, and of course the use of marks and any other reference to certification. So surveillance audits need to be conducted once per calendar year, except in the recertification year The date for the first surveillance audit following the initial certification cannot be more than 12 months from the first certification decision date. So you really need to be careful When to schedule that surveillance audit. Usually when you do a stage two audit, you already plan the surveillance audit for the upcoming year. So if it's necessary to adjust the frequency of surveillance audit to accommodate factors such as seasons or management system certifications of a limited duration. So then you need to talk to your certification. bodies. So the main elements to audit during a surveillance audit are of course the management review and the internal audit of course Um the change management, uh any action plans, um the use of certification um reference and marks. That's something that we always check as something that organizations tend to forget as well, that they cannot use the ISO logo that is on the website of the ISO um of the website from ISO but you need to use the logo that you get from your certification. So the main goal of a surveillance audit is really to verify if the management system is continually maintained and it's also getting improvements uh implemented. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S21.2-Beyond-the-initial-audit.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S21.2-Beyond-the-initial-audit.md index 2527c2c..4c6be70 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S21.2-Beyond-the-initial-audit.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S21.2-Beyond-the-initial-audit.md @@ -12,6 +12,8 @@ status: active ## Abstract +This session covers the recertification audit and special certification lifecycle scenarios. The recertification audit, conducted three months before certificate expiry, reviews the entire management system and previous surveillance audit findings for trends. The full three-year certification cycle comprises the initial audit, two surveillance audits, and recertification. Special cases including scope extensions, certificate suspension (for failure to comply, misuse of trademarks, or refusal to implement corrective actions), withdrawal, voluntary suspension, and transfer between certification bodies are explained. Rules for the use of certification trademarks and logos are also covered, emphasizing that ISO products cannot be product-certified. + ## Transcription The recertification audit now is in the third year. So the purpose of a recertification audit is really to confirm the continuate uh conformity and effectiveness of the management system as a whole and its continued relevance and applicability for the scope of certification. So a recertification audit will be planned and conducted to evaluate that continued fulfillment and other normative documents, and this shall be planned and conducted in due time to enable for a timely renewal. before the certificate expiry date. So a recertification audit will also look at um all the other surveillance audits. So If you do a re-certification audit, you also need to review any comments, any non-conformities of previous surveillance audits to see if there is a trend that can be spotted. For example, if people um didn't pick up nonconformities or the same non-conformities is coming back year after year. So you need to include that as well. It might be that you need to do a stage one audit, but that is only the case when there have been significant changes in the management system within the organization or the context. Now that can occur uh in at any time um and the sir uh certification body then needs to perform a special audit. Um it might be uh a stage uh two-stage uh audit. It depends on what the magnitude of the change is. of course. So again during a recertification audit um almost all clauses and controls are being reviewed again So, the effectiveness of the management system in the entirety of the internal and external changes is being reviewed. You want to see again that demonstrated commitment to maintain the effectiveness and the improvement of the management system. And of course, in regard to achieving the objectives, the ISMS objectives, and the intended results Again, for any major nonconformity, the certification body will also give a timeline to give back the non-conformity report and to have actions performed. Of course When planning that re-certification audit, you need to take into account. So, usually, what happens with most of the certification body is that they plan the recertification audit Three months before the certificate reaches its end date, so that an organization still has sufficient time to mitigate and to solve all nonconformities. When recertification activities are successfully completed, the expiry date of the new certification can be based on the expiry date of the existing certification. So the issue date will then be on the new certificate shall be on or even after the recertification. Decision. If you do not have an organization has not completed the recertification audit, or the certification body was unable to verify the implementation of the corrections for any major nonconformity Prior for the expiry date of the certification, the recertification shall not be recommended and the validity of the certification shall not be extended. So of course the client will be then be informed. So if the certification has been expired, a certification body Can restore the certification within six months provided that any outstanding recertification activities have been completed. So If your certificate is expired, but you still need one or two months to complete any major nonconformity and you do it within the six month time frame, you can still restore the certificate If you go over those six months, a stage two audit shall be conducted again. So a normal stage two audit like you've done in the initial certification will be done So the effective date on the certificate shall then be on or after the recertification decision, and the expiry date shall then be based on a prior certification. Cycle. So the certification body is the body that makes the decisions, of course, based on the result of the re-certification audit, as well as the review Of previous years or complaints that have been received. So it might be the case that your recertification audit was successful, but that you had a number of complaints on which the uh research the uh uh certification body decides um not uh to uh uh prolong your certificate. I've never seen that happening but it might be uh the case case. So a management system certification is valid for three-year, of course, conditional upon completion of surveillance audits. So you need to do the surveillance audits So that means that a full certification cycle includes an initial certification, two surveillance audits, and a recertification audit. Sometimes you can also do a pre-audit, which is always optional, where you do kind of a gap analysis. It's done at least three months before the certification audit. It's really to prepare you before the audit. plan is contains the audit information, the audit scope, audit objectives as we've discussed. The audit in year zero is the stage one and the stage uh two audit and non-conformities should be closed at least three months. after the audit conclusions have been uh presented and then you will get your initial certification after you've submitted. your non-conformity reports and it has been approved. Normally it is issued within two weeks after the audit has been successfully closed. Then you go into two years of surveillance audit, so year surveillance audit one should not be conducted longer than 12 months from the initial certification audit. Surveillance audit 2 should not be conducted longer than 12 months from the surveillance audit, and then you have the recertification. That should be conducted within two months before the triinal certification expiration. My experience is that most certification bodies find the two months a little bit too short, so they usually go for three months. But you cannot go closer than two months before the recertification date. There are a couple of special cases. So the first one is extensions So you can do a scope extension. So that might be because you decided to start with a smaller scope and that you then for a first certification and then you want to extend the scope or you do a merger or something like that. An extension of the scope can be conducted during the surveillance audit. And if an extension certification is not granted, the audit does not lose the current certificate. So that is very important. You can also suspend uh your certificate can be suspended off or withdrawn. So that only happens in a couple of instances. as something really needs to um have gone wrong then and Audit T can have its its uh certificate withdrawn when the certified management system has constantly Or severely fail to comply with the certification requirements, including requirements related to effectiveness of the management system And the certification body must make any certification suspension public. So what can that be? It can be when an um an auditee does not want to do the surveillance audit within uh the twelve months uh following um the stage two audit. So if you uh are not willing to do the surveillance audit your certificate will be withdrawn If the audit does not have enough resources to meet the requirement, if the certification body determines that, it can be withdrawn. If you get excessive, if the certification body gets Excessive or serious complaints by interested parties that might also lead to a withdrawal. If an auditee refuses to implement corrective actions Uh in response to the nonconformities during the period required. So if you don't get your nonconformity report back. If the audite misuses the trademark of the certification If the Odity has failed to correct the willful misuse of the trademark of the certification or accreditation body within a month, The Odity used and applied the certificate out of its scope. So you say that you're ISO 27001 certified for everything. Well, that's not the case. The information that has been provided during the audit was misleading. Or yeah, you can of course also request voluntarily the suspension. Uh if you don't pay your certification body, that might also lead to withdrawal or to suspension. So um having your certificate suspended if you take things seriously, um it's it's pretty difficult to have that happening But of course you need to uh take it seriously. You can also transfer your registration from one certification body to another certification Body even if you've signed a long-term agreement. So if you're not happy with your certification body, you can decide to move from one uh to another. So what needs to happen then? You of course need to create a request for transfer. You need to provide your last audit report to the new certification body. Also your last corrective action plan and of course a copy of the valid certification registration needs to happen as well It might also happen that the certification body needs to conduct audits on a short notice or unannounced because there were complaints or there were changes. So basically what will happen then is that the certification body will inform the client in advance to inform them about the audit and under which conditions the audit will be happening And of course, the certification body will need to have then a little bit of additional care in assignment of the audit team because there wasn't a lot of opportunity to object to the audit team members. Audit or certification bodies need to have a policy and a documented procedure available for suspension, withdrawal, or reduction of the scope and shall specify the subsequent actions by the certification body. And uh of course um yeah a certification body needs to adhere to uh ISO standards as well. Um so um under uh suspension when uh Certification body decides to suspend a certification, the certification becomes temporarily invalid The certification body will also restore the suspended certification if the issue that has resulted in the suspension has been resolved. If it uh will not be resolved uh within the time frame that is uh set forward, um it will result in a withdrawal or in a reduction of scope. Now, use of trademarks. I've already talked a little bit about that. Certified ADT is authorized to publicly display its certification and to use it for marketing purposes. However, the certification cannot be displayed directly on a product or in such a way that it would lead to belief that the product is certified. You cannot certify a product to ISO 27001. The certification body will provide the auditi with a logo that can be used. So the unauthorized use of ISO trademarks could mislead um would create false impressions or cause confusion. So ISO trademarks are not allowed to be used with the intention to express the certification of a product, a person or organization, since ISO does not perform certification. So using a logo or an ISO trademark is not allowed. So you get the logo that you're or the trademark that you're allowed to use. use um you get it in a certain color coding and you're not allowed to um yeah change that color coding or to make any other changes to the trademark. You need to use the trademark that you have received So, in summary, the main objective of the re-certification audit is to confirm the continued conformity and the effectiveness of the management system. Surveillance audits shall be conducted at least once a year, except in recertification years. The recertification audit aims to ensure that the management system is still implemented and being continually improved. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S22.1-Managing-an-internal-audit-program.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S22.1-Managing-an-internal-audit-program.md index 228aa34..37a51ea 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S22.1-Managing-an-internal-audit-program.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S22.1-Managing-an-internal-audit-program.md @@ -12,6 +12,8 @@ status: active ## Abstract +This session covers managing an internal audit program using ISO 19011 clause 5 as the framework. Key differences between internal and external audit are explained: internal auditors have organizational familiarity, can provide advisory recommendations, offer more flexibility through ongoing monitoring, and assess both effectiveness and efficiency. Setting up an internal audit function requires an audit charter defining purpose, scope, roles, access authority, and independence arrangements. Eight areas internal auditors should examine within an ISMS are identified: objectives, governance, risk management, process controls, ISMS performance, measurement, technical control testing, and coordination with external audit. + ## Transcription Okay, so in this section we're going to have a look at the concept of managing an internal audit programme. So throughout the course now you've actually covered a lot of aspects of being an auditor and conducting audits, but we've delivered that very much from an external audit perspective. And as I was saying earlier in the course, all of the skills that you've learnt on this course can be used in internal audit as well. But we just want to spend a bit of time focusing on the internal audit program and how you could build one using a lot of what you've learned so far. So we'll have a talk about managing an audit programme based on the guidance in ISO 19011. We'll also have a look at the role of the internal audit function and how it might differ from external audit. And then we'll have a think about what do you actually need to have in order to set up this internal audit function. So what sort of resources do we need to think about? How do we deal with records? How do internal auditors follow up on things like non-conformities? And how do we validate over time that that internal audit program is getting better and delivering value? So the starting point to this is to highlight a diagram that comes in ISO 19011 entitled Managing an Audit Program. And this does a really good job of splitting two different things. So ISO 19011 remember is the guidance for performing management system audits And it's split into two, well, several parts, but two parts that are important for this discussion, clause five and clause six. So clause 5 focuses on not carrying out an actual audit, but it focuses on what we call the audit program. So an audit program means a set of ongoing activities to do continuous regular audits. So if we look at clause 5, it says following a plan to check up cycle logic will establish some programme objectives. So what's the purpose of your internal audit programme? Is it purely to audit compliance with ISO 27001 Or is it to assess security in more depth? Does it go beyond information security and into other topics? You would define that when setting up your objectives. What's the purpose? What's this program trying to achieve? Like everything else in ISO thinking, we would look at what are the risks and opportunities to the audit program. If we're going to establish an internal audit program, Are there any risks that could derail that program? Does it bring any opportunities with it? And when we establish and implement it, I'll get on to the implementing in just a moment. obviously over time will monitor how well that program is working. You know, are the audits happening as frequently as they should be? Are they to the quality that we expect? Are they uncovering the kind of Opportunities for improvement, for example, that we're looking for, and over time we'll adjust the program. Now, if I go back to 5. 5, implementing the program, and you see this line going into clause 6 This is because in an audit program we do many audits and clause six is basically related to doing an individual audit. So what we're saying is when we implement an audit program Let's say we do one of several audits in an audit programme. Each audit would follow a set of procedures. Each audit would have a proper initiation process, a set of prepared activities. a set of procedures that are followed which would result in an audit report being issued at the end and so we go through the cycle again. And the idea of a good quality audit program is each and every one of those audits as executed would be following a standardized approach based on the rules and objectives of the audit program. And of course each individual audit should be reviewed at the end, so reviewed for quality, for example. So maybe If we've got an internal audit function, the audit manager or somebody like that might be reviewing each audit to say was it completed well? What's the the feedback that we get from the auditee and that would feed into do we need to change the audit program as a whole. So this is an important point. Now I'll be talking about both of these things in this section Now one thing that's important to call out is really the difference between internal and external audit. So a lot of what you've covered so far has focused on external audit. So actually I'm going to start there and talk about that and then tell you what I think is different about internal audits. So we know with an external audit it is completely independent of the audit. If you bring in a certification body, they're a completely separate entity and therefore completely independent. In an internal audit, the auditors are independent or should be independent of the work they are assessing, but they're not necessarily independent of your organization, because they're internal auditors, they're part of your organization So that means we get a slightly different perspective. With an external audit, you get a completely different view. With internal audit though, the benefit is that those internal auditors, while uh Whilst being familiar with the organization, that's not necessarily a bad thing because they may be able to spot more opportunities for efficiency and so forth. An external audit and a certification audit considers what we call the effectiveness of the ISMS. So they're basically checking Are the requirements of the standard being met? Not necessarily how efficient you are as an organization. Whereas an internal auditor, because they may be more familiar with your organization than an external auditor, can also look at efficiency and say, well not only are you meeting the requirements or not, but could we do it better based on our understanding of the organization? An external auditor from a certification body does not have an advisory role. As we've spoken about previously, they can give Very very general recommendations, but an external auditor cannot recommend what you do. So I as an external auditor could not say, for example, you know, use this methodology for conducting your risk assessment and set it up like this. Because that could be a conflict of interest. I'm basically potentially then going to be auditing my own advice. Whereas an internal auditor can provide advice and guidance. Providing they're not actually doing the work, but they can certainly make more detailed recommendations. They are freer to do so External audits as well are all planned. They happen on a schedule that's pre-advertised. We all agree when the external audit is going to take place. And one of my colleagues put it like that. He said that the external auditor always gets to see the polished version. That's because most organisations, rightly so, prepare for their audit. Whereas with an internal audit, because you've got resource there all the time, we can do things like ongoing audit that don't necessarily need to be put in the diary to happen in three, six months time. And therefore, an internal auditor might get a better picture of the real world over a longer period of time. Now the reason to present this is not to pitch one against the other. I'm not trying to claim that internal audit is better than external or vice versa. They complement each other External audit has limitations for reasons, partially because of those accreditation rules, the strict rules that certification bodies need to operate in. They still bring plenty of benefit, but they need to go hand in hand with internal audit. So let's think about internal audit and setting up an internal audit sort of function or service. What we recommend is that an organization should put together an audit charter. An internal audit charter, the the idea of a charter is essentially an agreement between top management and the rest of the organisation. So an internal audit charter may lay out some of the key principles about internal audit in order to make sure it can run independently, impartially, with a level of authority. So what are the kind of things I'd expect to see in a good internal audit charter? Firstly, the formal definition and purpose of internal audit So why are we setting up an internal audit function? What's its aims? What's its purpose? Equally what's its scope? So is this internal audit function there purely to look at conformity with ISO standards? or with other things, you know, so in some organizations, internal audit does many other things such as you know investigating potential um problems in the organization, you know, assessing compliance with many different laws, regulations and standards. So in this organization, let's make sure the clear the purpose and the scope is clear. We want to make sure that the roles and responsibilities of those auditors are absolutely clear. What's the service that they're providing? And I do use that word service as a genuine word here. I've heard some people s make remarks like, oh, the internal audit's the company police department or something like this. Well, you know, you people may perceive that as the case, but ultimately I would argue that internal audit is a service. They're out there to help. identify opportunities for improvement to help the organization progress in the right direction. And two very important points. Formal definition of the internal auditors access authorisation. What this means is, is what authority do internal auditors have to ask for information, to ask to see things, to meet people and so forth. Now we're not saying that they need to have formal authority to just demand anything anytime. I'm not saying it's an internal auditor can turn up at three o'clock in the morning and knock on somebody's door and demand immediate access to something. But there needs to be a certain level of authority to allow those internal auditors to perform their job. You can't just withhold information and bring example from them. And we also need to lay out in this charter how these auditors will be independent. So that might be about where they report or sit in the organization. So in some organisations we might have an audit committee that reports into the board directly and those auditors report into that committee But whatever we want to do, we want to make sure they're not sitting in a place where they could be pressurized. Let's say for example I'm doing an audit on a function involving my line manager, well that could be a huge threat to independence if there's a chance I'm gonna be lent upon, let's say, to not report everything and so forth. So we avoid that by making sure we lay out the independence requirements in the audit charter. So, what is the role of the internal audit function from our perspective when we're thinking about something like an ISMS? Well, I would say the role covers three different things. It is there to help the organization check the effectiveness and the efficiency of their operations. In other words, the controls that are implemented, the processes that are implemented, internal auditors can validate Are they working as expected? Are they meeting minimum requirements? And not just that, but are we operating in the most efficient way possible? Are we achieving the results in the best way possible? Internal auditors, of course, can also go out from a security point of view and validate whether the security controls we're implementing are effective. In other words, are they really protecting our assets? If we've said, for example, we're putting multi-factor authentication in place and other controls, auditors can actually test those things Validate whether they're working correctly and doing their job. And also, audits can focus on how well we might be complying with laws, regulations, any contractual obligations. So those requirements can form the basis of various audits that are conducted in that audit program So going back to my point I made a moment ago about services, these are services that auditors are bringing to the organization. Now, how big the audit program will be, how many auditors we need, what they'll focus on, will of course vary depending on the size of the organization, the structure, and so forth. So in a small organization, an internal audit of an ISMS might literally be one audit of the entire ISMS per year because that This makes sense. In a larger organization, we might have a series of audits over a period of time. So there's one organization I can think of right now who has an ISMS And they have usually about two audits per month, each looking at different control areas from the standard. And some are looked at more frequently than others in further depth because of their criticality So again, there's no right or wrong way of building an internal audit program, but we want to make sure we have enough assurance, especially when we think about some of the requirements that might need to be met. So let's think about internal audit and the things that internal audit might look at, especially when auditing an ISMS. And I would say there's eight key areas here to think about. So from a an audit point of view you would expect that objectives are reviewed. So what I'm trying to say here is Auditors can conduct audits at a very high strategic level right through to a low technical level. So really when we think about an ISMS, I'd expect my audit team to be looking at the ISMS's objectives. Are those objectives fit for purpose Do they align with business objectives? Are they suitably thought through and planned? Are they being changed when they need to be changed? The auditors can look at the governance structure. You know, have we got the right reporting lines, the right oversight of information security risk? Are top management getting actively involved where they need to? Are risk owners making risk-based decisions? Auditors could review the risk management process. Are risk assessments happening when they should be? Are findings being acted upon Are the risk assessments being done rigorous enough? Is the risk method we're using suitable and fit for purpose? And as well as looking at that aspect, of course the auditors can then, as I like to call it, look under the hood and look at processes and controls. Are those pr let's let's take for arguments' sake the incident management process. They could review those that process. They could look at how effective it is. Are incidents being reported, responded to on time. uh analyzed properly and so forth so they can get under the hood and look at how well or not certain processes are working. They could look at the whole ISMS end-to-end, you know, uh is the ISMS improving over time. Are management reviews taking place? They could look at measurement. Are we actually gathering the right measurements? Are we monitoring our KPIs properly? Are we learning from our monitoring and making changes? And of course the other thing I would add to this, testing controls. I don't necessarily mean testing as in hands-on penetration testing, but I mean testing as in checking controls from a technical point of view. Are those security controls fit for purpose? So each and every audit might not cover all of these points I'm alluding to here. They might, you know, one audit might look at governance. Another one might examine a particular set of processes, but over time you you know the internal audit are having a good check of all these areas. Now the eighth one on here, which I do want to mention a little bit about is coordination with external audit. So let me try and elaborate on this a little bit. So I remember one of the very first certification audits I did for a certification body. And at the time I went to interview a particular department manager. And during this interview he said to me, look, I'm not being difficult. But this is the third time this year I've had an auditor in front of me asking me exactly the same questions, uh, and yet XYZ XYZ department's never been visited in the last, you know. X number of months, etc. What's happening here? And it was a perfectly legitimate question. And basically what was happening there was there was a lack of coordination between internal audit and us at the time, the the body I worked for, the external um certification body. And so what one of the things that was agreed after that as a piece of feedback based on that remark and other stuff is we basically agreed at the start of every year that us, the certification body, would meet with internal audit and we would discuss the objectives for the year ahead and therefore try and coordinate a little better. Now remember external audit still needs to check that internal audit is working effectively, so that doesn't mean we won't look in the same areas in some cases But we wanted to avoid too much duplicate or triplicate auditing. So point eight is about having a good relationship. And what I say is as an external auditor, if you've got confidence that the organization's got a good well-founded internal audit programme, then you can build that relationship and work quite closely together. Because in the end, both sets of auditors really are or should be focusing on the best interest of the organization. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S22.2-Managing-an-internal-audit-program.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S22.2-Managing-an-internal-audit-program.md index 56c11c7..f62684e 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S22.2-Managing-an-internal-audit-program.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S22.2-Managing-an-internal-audit-program.md @@ -13,6 +13,8 @@ status: active ## Abstract +This session covers the operational aspects of building and managing an internal audit program. Topics include the internal audit charter's access and independence provisions, long-term and short-term audit planning aligned to risk and the three-year certification cycle, and the concept of continual internal audit using automated tooling for ongoing monitoring. Resource requirements are discussed including personnel competence (both audit methodology and subject matter expertise), tools, procedures, and logistics. The session also addresses audit records management, following up on nonconformities, and periodic review of the audit program itself to drive quality improvement and demonstrate value to the organization. + ## Transcription So we mentioned a little earlier that we would have this document called an internal audit charter that would basically lay out a number of uh commitments to the internal audit process. And two of those, which are particularly important principles, are the first one, access to resource and collaboration. What this means is As an internal auditor, if I need to carry out my audit, I should be free, within appropriate boundaries, to be able to interview the people I need to interview. Have access to the data that I need to have access to, to be able to review evidence, you know, look at systems and so forth without unfair restriction. And this is what we mean about the access authority. So the internal audit charter should lay out what permissions internal auditors have. what can be done if for whatever reason you know internal auditors are prevented from performing their role. So as I said a little bit earlier on, this is not about giving internal audit has access to anything they want at any time, but it's about having that reasonable balance in place. The independence bit we already mentioned as well when we talked about the internal audit charter This is laying down clearly where those internal auditors report and how we can have an assurance that they're free from undue influence. you know, or any sort of unfair situations. We might back this up as well with some kind of code of ethics that all internal auditors are required to follow or sign up to to have a again a greater assurance. What we want to make sure of is that an auditor is free to give an honest evidence-based opinion on what they see Now when we think about internal audit, of course like any auditing it's a good idea to have some clear plans in place. And we suggest that there should be long-term and short-term plans. So I said earlier on that an audit program is not just carry out an audit and that's it. Usually we carry out a series of audits over a period of time. So for the long-term planning we might have a three-year plan and the reason I say a three-year plan is usually organizations are certified for a period of three years So assuming the organization in question is going through that certification cycle, we could have a three-year plan which says generally these are the areas that we're going to look at. So you might say you know next year in quarter one we're going to do a detailed review of network security. In quarter two we're going to focus on application security or whatever it might might be as being important. And then of course in the shorter term the plans that we have will be much more detailed. So for example, right now I have an internal audit client that I work for, and we've said that the next audit on the long-term plan is network security. And now we have a very specific agenda of exactly what we're going to look at, the devices we're going to examine, the particular topics we're going to examine. in more detail. So we'd expect to see a clear set of planning. Now usually the audit manager or whoever's heading up the internal audit function would put this together not just on their own, but of course by working with key stakeholders in the organisation. So that planning should be based on risk. You're thinking about what are the most critical areas of the ISMS Because usually the most critical areas are the ones we want to visit more frequently as part of internal audit. Now there might be a concept that you might have heard about before called continual internal audit. Now what we mean by continual internal audit is not Auditors continually sitting in front of people interviewing them in a traditional audit sense. What we mean is establishment of tooling and technologies that will allow auditors to have continuous access to data. So for example, when I think about the health service, they had an example of that where the internal audit function was always able to review and run reports on the patient databases to identify data quality issues. That was a a simple example of continual audit. They didn't have to book an appointment And schedule a time to conduct their audit, they had the ability to execute that test at any time over a period of time And some of the benefits of having tooling like that is an auditor can more easily detect non-conformities early, so rather than waiting till the date of the audit and then discovering a problem. We can get an early heads up if an auditor's looking at data and evidence regularly and saying there's something not quite right here. It also can remove some of the manual tasks in an audit. So in the example I gave there The auditors don't need to come along, do a manual data extract, manually sift through the data to find the problems. They already have access and tools that can allow them to easily query the dataset. And this means for specific controls that auditors are looking at, they can continually monitor them over a period of time and possibly look at a large dataset. So many benefits of doing continual internal audit, but we can't hide from the fact that this is not quite as simple as I might be making it out to be. It can be difficult and expensive to implement insofar that the tooling that allows those auditors to conduct those tasks often requires significant investment. investment, not just investment in terms of finances but in terms of time. Because we've got to be clear if we're going to do continual auditing like that, what are the specific data sets that specific things that those auditors actually need to look for and technically how can we grant access to the data. There's also a risk that it may produce what we call a false sense of security. And the reason I say that is if we think or people in the organization think Well, the internal audit team are constantly monitoring this particular control. There might be sort of a an attitude, a little bit of Well, we don't need to worry about it because if there's anything wrong with it, these auditors will spot it. So let's say the internal audit function we're constantly reviewing backup logs to detect whether backups are successful or not. Is there a danger, and I pose that as a question rather than a statement, is there a danger that those involved in implementing that control be a bit more relaxed? because they think the error will be spotted. So it could lead to a false sense of security. And if the auditors are overwhelmed with information and have too much, there is a risk that we don't actually see those deviations. So a lot of people will try and sell the idea of continual audit. I would say it's not a silver bullet But in particular areas where there might be an important thing to look at, like that data quality example, internal audit, continual internal audit can be very beneficial. Now, when we think about building an internal audit program, depending on the size of the organization, just like building an ISMS, we need to think thoroughly about the resource requirements for making this happen. Implementing an effective internal audit programme does have a financial cost, whether that's the financial cost of hiring auditors, training auditors. buying the software and tools that they need to use and certainly that might change as we expand or change over time. One of the biggest challenges of course is making sure we have competent personnel. And when we speak about competence, that's kind of twofold. There's the competence to conduct audits which is understanding audit principles and techniques. Then there's the subject matter competence. Now this is something I would like to highlight here. And this is not a criticism of anybody in particular at all but sometimes what I've seen in some organisations is they'll have an internal audit function that might focus on things like risk, operational risk processes, etc. And those auditors go off to conduct information security audits, but don't necessarily have the technical background to identify key problems. And then that's another way we get into a false sense of security because you get reports saying things are okay and so forth. So it's not just audit competence but subject matter competence that is important here as well We also need to think about tooling. So are we going to give the auditors audit software? We talked earlier in the course about statistical analysis, so there might be need for tools that calculate sample sizes and so forth. And another thing that's important, we want auditors to operate in a consistent, repeatable way. So we need very clear, defined audit policies and procedures. So if I was, let's say your organization was setting up an internal audit program and I was joining you as an internal auditor, what do you expect in terms of the way we'll plan audits, in terms of the way we'll do sampling? How am I meant to complete my report? All of these things should be clear in your procedures. And the logistics part may be relevant if these audits involve on-site audits. especially if you're you know geographically dispersed, how will you get the auditors to and from where they need to be? Is there any logistical planning that might need to be taken into account Now another important aspect as well that we need to think carefully of is when audits happen, what we get out the back of audits is not just a report, but we get audit records. So audit records include the report itself, but of course any evidence that was gathered, any correspondence between the auditors and the auditee. any data that they've taken for sampling and so forth, these are all things that prove that the audit happened and are often used to prove that the audit happened to a certain level of quality But we do need to have then in our audit program our records management program agreeing, for example How that those records should be kept and where, how long they should be kept for, how they should be protected from a security point of view. So speaking as an external auditor, for example, if I go out and conduct an audit, and let's say I use my laptop and gather notes, when I'm finished, I basically am required to upload all of those to a portal that belongs to the certification body. I'm also required to confirm in writing that I've erased anything that I shouldn't have from my local device. That's part of their records management and security policy. For internal audit we'd need to set something in motion as well. And the reason we want good quality audit records is let's imagine a new auditor comes along next year to do a follow-up audit Well they need to be able to see the evidence and details of what's happened on previous audits Now earlier in the course we looked at following up on non-conformities, but we looked at that from a certification body point of view For external audit. Well, the truth is it's not a lot different for internal audit. If in an internal audit we discover non-conformities, it's still a requirement of the standard, as you know, in clause 10. 2 To ensure that corrective action is taken, a root cause analysis is done. What we're expecting here then is from an internal audit point of view, we have a clear procedure about following up on corrections and corrective actions. Now the difference between internal and external audit Is in external audit there are very specific time frames that must be followed, like three months for a major nonconformity We don't have to follow that exact timeframe for internal audit, so we can set a shorter or longer time frame as we expect, but we do expect to see. That internal auditors will follow up on non-conformities will encourage the organization to close those non-conformities out and we'll seek evidence to see that the root cause analysis has been done and corrective actions have been applied. Ideally we w what we want to see is these things being done before the external audit. So for me, as an external auditor, I always feel very comfortable, well uh uh or comfortable at least, if I see an internal audit's been done and non-conformity has been detected, but the organization's acted on it before the external audit, as long as that acting obviously is you're based on a sound root cause analysis that gives me a confidence that the internal audit process is indeed working properly and that they're not just producing, let's just say, reports that aren't followed up on. This is a an important point. I do remember at one point being an auditor for an organization three years in a row. And uh honestly I could have gone back three years in a row. Uh this wasn't a certification audit by the way, but it's a sort of semi-external audit. But in this audit I could have gone back three years in a row and really just change the date on the audit report because nothing was being acted upon. That's exactly what we want to avoid by having that proactive follow-up and the commitment from top management that follow-up is acted upon. Now, like anything else, if we set about building a good all-round internal audit program Just like building an ISMS, we would expect that that program is reviewed at certain periods in time. Now in this case, it's those who are managing that program. So that might be a lead auditor or an internal audit program manager. And the kind of things they might want to review at periodic intervals is things like, are the audits that we're scheduling being carried out? Are they being carried out to the level of quality required and meeting the objectives? How are the audit team members performing? So when we get feedback from the audit tee, is that positive feedback? And when we look at the work that the auditors are producing, You know, is it meeting the minimum quality standards? Does it look rigorous enough? Are those auditors following procedures correctly? You know, is there an opportunity to improve their skill set? What sort of feedback are we getting from the auditees in terms of interaction? Do they find the results from these audits useful? Do they enjoy the audit experience? Now you might raise your eyebrow at that. uh who enjoys an audit experience but what I mean is um are the auditees seeing value in this they're not just seeing the audit as a sort of a box ticking exercise Are we getting when we're raising findings enough evidence? Is the tooling working, the procedures working? All of these things, what we're trying to do is find out. And this is not about looking for problems, this is about learning how we can improve that process. So ultimately we have an internal audit process that's effective and value adding, and that's what we're really looking for So in summary, we've had a look at the internal audit process. We can use ISO 19011 to build an effective internal audit process. Internal audits are absolutely fundamental to the successful running of an ISMS and all the principles and skills that you've learnt through this course you can apply in an internal audit context. But we do need to have support for effective internal audit and therefore we need an internal audit charter laying out the independence of auditors, their independence requirements giving them the authority to perform their job effectively. And we do need to make sure that those auditors are competent, properly supported. and that we look to drive continual improvement overall. And if we get this right, then really the external audit is another set of eyes, but getting a good internal audit function working means we can have a real confidence that over time we can improve our security posture and capability and improve and further develop our ISMS. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S23.1-Closing-of-the-training-course.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S23.1-Closing-of-the-training-course.md index 6c143e2..4a0f5e3 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S23.1-Closing-of-the-training-course.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S23.1-Closing-of-the-training-course.md @@ -12,6 +12,8 @@ status: active ## Abstract +This session covers the PECB certification scheme, exam format, and post-exam certification process. Candidates who pass the lead auditor exam can apply for certification at a level matching their experience, ranging from provisional auditor to senior lead auditor. The exam consists of 80 multiple-choice questions over three hours, is open-book (official courseware, personal notes, and the ISO 27001 standard are permitted), and requires a 70% pass mark with no penalty for wrong answers. Exam software allows flagging and revisiting questions. A free retake is available if unsuccessful. Course completion also earns a CPD-accredited attestation certificate. + ## Transcription Alright, so in this section where we have entitled it closing of the training course, this is really the final part of the lead auditor. Course where we're going to take you through a number of things, including the PCB certification scheme. That's the scheme that you will follow in order to become a lead auditor. Talk a little bit about the course certificates. the PCB certification process and exam, and then we'll also introduce you to some other useful PCB services and courses that can certainly support the content that you've learned here in the Lead Auditor. So first of all, we just want to take a look at the PCB ISO 27001 certification scheme. So in this case you'll be taking the lead auditor exam and when you pass that exam, as we'll get into in a moment, you'll be invited to apply for the lead auditor certification. So what we can see here is the PCB ISO 27001 certification scheme related to the lead auditor exam. So you're going to take the lead auditor exam and when you pass that examination then you'll have the option to apply for certification. Now depending on your experience and background you'll apply for a level of certification that's proportionate to your background. So this is not to do with the exam results. This is to do with your experience. So for example, if you're brand new to this so you don't have any working experience in the field of information security, then in this case you would apply for something called the provisional auditor. So 27001 provisional auditor certification. If on the other hand, let's say that you meet this requirement of having five years working experience with two years in information security management and approximately 300 hours of audit experience then you'd be able to apply for the lead auditor certification and so on and so forth as you can see see in the table. Now with regards to the number of hours, basically what this is about is when people become auditors, usually they'll keep an audit log saying you know what audit they did and how long that took Now if you've not performed audits for certification bodies before you might not necessarily have a log, but you can certainly think about your previous experience and the amount of time Approximately that you've spent in the field of audit based on the fact that a typical day is usually seven or eight hours. Also, in order to obtain the certification, you would need to sign the PCB Code of Ethics Now, for anybody who doesn't sort of immediately apply for lead auditor or senior lead auditor, it is worth noting that you can certify at one level and upgrade when you obtain the experience. So let's say You obtain ISO 27001 Auditor because maybe you only have one year in information security management and then you obtain two years, then you can log back into your PCB account and apply to upgrade without having to go through the training or exam again. Now, regardless of your exam result and what certification you apply for for completing this particular training course, you are entitled to obtain what's called an attestation of course completion certificate. So that's separate from the official certification, which is basically accredited by the CPD Association, and CPD stands for For continuing professional development. So this means if you hold other professional certifications which require you to do ongoing education in the field of information security, you can use your attendance at this course. or use of this course in order to claim the requisite number of CPD points. But let me step you through the PCB certification process from the exam right through to maintaining your lead auditor certification and all the steps along the way. So first of all, let's talk a little bit about the examination for this particular course. So as part of the e-learning course package, you should have received an email from PCB Inviting you to we're including an exam voucher, inviting you to register for, as and when you want to, the online exam. Now basically the PCB exams platform allows you to take the exam online from anywhere. We've included in the material here a link to the exam rules and policies which will lay out all the technical requirements and rules about conducting an exam from home. For example, the fact that you'll need a machine with a working webcam, microphone, that other than the official material you're allowed to bring the exam, which I'll come to in a moment, that the rest of your desk, for example, is clear and so forth. So I do recommend before sitting the exam, having a look at those exam rules and policies. So let's talk a little bit about this exam. So this particular exam, lead auditor, is an 80 question, 80 Multi-choice exam done over a period of three hours, that's if you're taking the exam in your native language. If you're taking it in another language, as in a second language. then you can get up to 30 minutes extra and you'll pick this up as part of the application process. Now in these 80 questions, they're all multi-choice. with three potential answers to the question and you choose the one best answer for each question. Some questions will be what we call scenario-based questions So that is to say there'll be a scenario and then you may be asked some questions about the scenario you've just read. Now as you work through the exam, you mark the answers to each question in the exam software You can go back and forth, so you can go back to previous questions. It's not an adaptive exam. Like an adaptive exam is one which asks you a different question depending on your previous answer. So that's not the case. So you can go back and forth And also as you work your way through the exam questions, if you're unsure on the answer and you want to revisit it later, you can tick a box that says flag this question. In the exam software on the right hand side of your screen will be a list of 80 bubbles And as you do the questions, they'll be lit up in red, amber or green. Red means you haven't attempted the question. Green means you've given an answer but you've not flagged it as a concern. And amber means you've flagged it. So the idea is as you work your way through the questions and you come to the end, before ending the exam, you can basically go back through those questions you flagged. So from a time management point of view, it could be worth running through the questions and using your remaining time to revisit those questions that you're unsure about. Now the exam will only end when you hit the end exam button or you run out of time. Now if you hit the end exam button, please don't worry, the exam will not end and be marked until you confirm it, so you will get a warning saying you've you've pressed end exam, are you sure you want to end the exam? If you run out of time it will basically mark your exam based on the number of questions that you've answered. Now a couple of other important points to mention. There is no penalty for an incorrect answer. So worst case scenario you can make the best judgment call if you like. The other thing to tell you as well is this is an open book exam. What that means is officially during the exam you can look at the official courseware, that's the courseware provided to you by PCB Any notes you've made during the course and an access to the ISO 27001 standards. Those are the things you're allowed to have with you, as well as a dictionary. What's important to mention about this in my experience of doing these exams is you probably won't get chance in terms of time to look up every single answer in the material. So what I would say is take a look in the material as and when you need to so you can use your time effectively. Now in terms of my point here about the open book side of things You can look at the material on your screen because in the exam app there's a button in the corner that says View My Courseware. So if you hit the View My Courseware button can look at it electronically. If you prefer to print the courseware at home and have a printed binder on your desk, that's equally allowable as well. One thing to point out, the ISO 27001 standard is not accessible in the exam app, and that's for copyright reasons because ISO of course is a separate organization with very strict copyright rules So if you want to refer to the ISO standard itself during the exam, I would recommend bringing a copy with you. When you complete the exam. . on your screen you will get the result pretty much straight away so it will say it will mark it pretty quickly and then it will say hopefully congratulations you've passed . And there's a couple of things to mention about this. There is no grading in the exam. Essentially there's a pass or fail, and that's based on scoring 70% or higher in the exam. That's what the Pass mark is 70% overall. Now if you're successful, you'll see the message of course on your screen and later on you will receive an email from PCB confirming that and inviting you to apply for your certification with an email including something called an exam number which is an important number that you're going to use in your application process If you're unsuccessful, the good news is that all PCB courses do come with a second retake free of charge. What you would do in that circumstance is reach out to your training provider. whoever you obtained this e-learning course from. And providing that you're within 12 months of the initial issuing of the voucher, then your training provider will provide you a second voucher free of charge. charge so everybody gets the chance uh two chances to take the exam successfully. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S23.2-Closing-of-the-training-course.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S23.2-Closing-of-the-training-course.md index 7bb6b2d..5e90276 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S23.2-Closing-of-the-training-course.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S23.2-Closing-of-the-training-course.md @@ -12,6 +12,8 @@ status: active ## Abstract +This session explains the PECB certification application process, continuing professional development (CPD) requirements, and related training offerings. After passing the exam, candidates apply online with professional experience details and two referees who verify their background. Valid experience includes internal, second, and third-party audits, gap analyses, and risk assessment activities. Certification levels from provisional auditor to senior lead auditor require different experience thresholds. Annual CPD requirements range from 20 to 60 hours depending on certification level. The session also introduces PECB Skills (15-minute learning capsules), the PECB Store, and related courses including the ISO 27001 Lead Implementer and ISO 27005 Lead Risk Manager. + ## Transcription So let's imagine you've passed the exam, you've received your email, and now you want to apply to become a lead auditor. Well what happens here is you'll be invited via email to apply. It's a very straightforward process. You basically log on to your PCB account. That's the account that you used when setting up this training. It's the same username and password. And you basically fill in what is essentially an online form where you'll confirm your contact details and then provide some information about your professional experience. Now this is structured very similar to an online job application form. And when we ask about professional experience, just to be clear, we do not need anybody to divulge company secrets and so forth. I remember on one training course somebody said, I can't fill that in because everything I do at work is classified. Well we don't need to know anything about classified or top secret projects or anything like this We just need a summary. So if you said, you know, I'm an information security manager at Organization X, my typical duties over the last five years have included. you're conducting risk assessments, scheduling audits, whatever might that might be, that's what you would describe in your application form. And the question might be, well, how do you verify this as PCB? Well we asked you at the end of your application form to provide the detail of two referees Referees are individuals who PCB will contact to verify the claimed experience in your application. Referees can be people like uh line managers so your existing manager or supervisor for example previous line managers um if you're self-employed or freelance that could be These people like customers or fellow security professionals who've known you long enough to be able to give you that reference. In other words, people who are in a position to know your experience and are willing to verify you. Now what counts as valid experience according to PCB certification scheme? Well you can see this in this slide here. the professional experience records and we've listed these out to be audit experience and then valid activities within an audit. Now we realise that not everybody who's applying for this certification has worked for a certifying body. However, that's fine because we accept other types of audits. So if you've done internal audits, or second or third party audits, or you performed gap analysis which has a similar skill set or risk assessment activity. these will all be considered to be valid. And then in terms of audit activities, things like planning audits, preparing work documents. actually carrying out aspects of the audits like interviewing people, documenting non-conformities, managing audit programs, all of the things you see on this list are valid experience. If at the point of application you are unsure whether your experience is suitable or not, you can reach out to the PCB certification team online. you will find that extremely helpful and they'll certainly steer you in the right direction and provide you the advice that you need. So when you submit your application The first thing that will happen before PCB examine your application is your two references that I was referring to earlier will then receive emails inviting them to respond. And what is being verified is the work experience that you've claimed in your application and I guess your background So usually the referee will see receive a fairly straightforward questionnaire where they'll be asked things like how long have they known you? Could they verify the experience that's claimed and so forth? It is important to have a conversation with your referees, make sure they're happy first to act as your referees and for them to be aware that this application will be coming. Because PCB will not process the application itself until your referees have responded. You can log into your application at any time and see the status as to whether the referees have responded. But once the referees have responded, PCB will review your application. If there is any issues in terms of missing information or anything like that, please be assured. with the they're not they're not going to just remove your application. They will the certification team will come back to you and explain uh what else is needed if there's any gaps to be plugged But once this is satisfactorily completed, PCB will then reach out to you and basically issue you with your certificate. You'll be able to download your actual certificate from your PCB online account and there is a function on the PCB website where any employer or customer using the unique reference number of your certificate can verify it. Also, there is what's called a credly badge available, so you'll be able to download those so you can advertise your skills on platforms like LinkedIn and so on. so forth and it's only when you obtain that formal certification can you say I am a PCB ISO 27001 lead auditor So let's imagine you've done everything, you've passed your exam, you've got your certification, what happens next? So the good news is you'd be certified as a lead auditor for a period of three years. But there are some requirements that need to be followed in order to keep hold and maintain that certificate. And those are mainly around continuing professional development We want to make sure that our auditors and our professionals are continuing to learn and develop over time. And we'll have a look at in a moment at the amount of what we call CPD hours that you'll need to do each uh each year but basically every year you'd be invited to log on to your PCB platform to submit CPD information. Now just to be clear CPDs can be earned through training and this doesn't have to be PCB training specifically. So let's say you went off and did another course related to information security and let's just say that course was 20 hours that would be 20 CPDs. You can earn CPDs through academic study as well and you can claim a certain percentage through your work experience And other things like voluntary work. So for example, for me I I occasionally do some lectures for my local university, not as a commercial thing, but just as a support things so I can claim a little bit of time for preparing and delivering those. Attending PCB and other webinars and seminars, as long as those are educational in nature, those are also places where you can earn CPDs There is also requirement to pay an annual maintenance fee, and again PCB will inform you about that and invite you to settle. That each year and you agree every year to continue to adhere to the PCB Code of Ethics So when we think about the CPD requirements, we have the table here that lists these out. So the CPD requirements will vary depending on the level you have Essentially obtained. So if you're at auditor level, we require uh 20 CPD hours per year, so 60 over three years, 30 at the lead level, and 60 at the senior lead level. So basically each year, as I've said, you'd be invited to log in and submit that information. Now for me what I do myself, given that I hold a number of certifications, is I have a basically a spreadsheet And every time I do something like attending a course, attending a seminar, doing anything that would earn CPD points I basically record in that spreadsheet for the year, the date, the activity, who I did that activity with, and I also keep in a folder any evidence of that, so any attendance certificates or completion of exams, etc. And the reason for that is when you go on the PCB website and submit this information, you can submit supporting evidence. And it's important to point out that anything that you submit here PCB as a professional certification body can ask to see the evidence. It is important that you keep accurate records here. And if you do that during the year, for me, it makes life so much easier when you come to do the online submit. of CPDs, it should be a very short and straightforward process. So with all of that in mind, let's imagine you've got your lead auditor, you're maintaining it, everything's really good. What about the future? What about um where you go from here and I just wanted to take the opportunity to introduce you to a couple of other things that might be interesting from a PCB perspective. So although you have learned in this course all the skills of being a lead auditor, let's imagine that you're kind of doing this job for real, so to speak. and you're invited to go and perform an audit in a specific environment and you want to get familiar with a particular skill or activity. Let's say for example you're going to review privacy impact assessments. Let's just say for this example that's something that's new to you. So you might want to learn about how to do that, but but not necessarily want to go on a full-blown course to do it. Well that's where the new online learning platform called PCB Skills can be very useful. So PCB Skills is an online learning platform where you can study what's called capsules which are 15 minutes long. uh to teach you a very specific skill in an area of information security, privacy, AI, basically digital trust. If you do four of those capsules, that counts as one hour and essentially you have completed what's called a module. For every module you complete, you can earn a CPD certificate. to maintaining your certification. At the moment there's over 500 videos in PCB skills and basically What Ups is it's a good way of having access to rich content to continue your learning after this course. So as you work your way through through the content in PCB Skills, as I've said, for each hour you can earn one CPD credit and if you do an entire um set of competencies you can s essentially obtain what's called an essentials certificate. You will find in the skills platform for 27,001 audit uh skills for every single requirement in ISO 27001. So what you've learnt here you can drill a lot more deeper into in these skills capsules As well as PCB skills, of course you might want to have access to things like standards, toolkits, books and so forth, and that's where the PCB store can help you. So I would always encourage you if you're looking for anything like that. To take a look at the PCB store online. And lastly, here, although you've completed a lead auditor, you might be interested in other ISO 27001 related training So there is what we call the ISO 27001 Lead Implementer course. Lead implementer, of course, is teaching you how to approach the building, design and implementation of an ISMS. So looking at it from the the other perspective and a lot of our professionals do both lead implement and lead auditor to get the full picture And if you're interested in learning more about risk, which we talked about during this course, there is also the ISO 2705 Lead Risk Manager, which really focuses on into the risk management process, how to conduct an effective risk management and tells the complete story end-to-end in this case. So these are all other things you can consider, but I hope this has been useful and really given you a good overview of how to go forward to take the exam, to become a lead auditor, and all the things you can consider afterwards So I'd just like to take the opportunity to thank you for engaging in this lead auditor course. I certainly hope it's been useful. We wish you the very best in the exam and your career going forward. \ No newline at end of file