Vault restructure
This commit is contained in:
parent
d45797d121
commit
ff77508bd1
1433 changed files with 415450 additions and 1201 deletions
Binary file not shown.
|
After Width: | Height: | Size: 81 KiB |
|
|
@ -0,0 +1,11 @@
|
|||
---
|
||||
tags:
|
||||
- iso27002/2022
|
||||
- audit
|
||||
---
|
||||
[QuickRecorder](https://lihaoyun6.github.io/quickrecorder/), A Lightweight, Powerful and Open-Source screen recorder for macOS
|
||||
|
||||
# Section 1: Training course objectives and structure
|
||||
|
||||
An auditor’s competence consists of Knowledge, Skill and Behaviour
|
||||
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
# Section 5: Overview of ISO 27001 requirements
|
||||
|
||||
Part 1: Context and Leadership
|
||||
- [Clause 4: Context of the organization](PECB%2027001%20LA%20S05%20E01a%20-%20Context%20of%20the%20organization.md)
|
||||
- [Clause 5: Leadership](PECB%2027001%20LA%20S05%20E01b%20-%20Leadership.md)
|
||||
|
||||
Part 2: Planning
|
||||
- [Clause 6.1: Actions to address risks and opportunities](PECB%2027001%20LA%20S05%20E02a%20-%20Risk%20assessment%20and%20analysis.md)
|
||||
- [Clause 6.2 Information security objectives and planning to achieve them](PECB%2027001%20LA%20S05%20E02b%20-%20Objectives%20and%20planning.md)
|
||||
- [Clause 6.3: Planning of changes](PECB%2027001%20LA%20S05%20E02c%20-%20Planning%20of%20changes.md)
|
||||
|
||||
Part 3: Treatment
|
||||
- [Clause 6.1.3: Information security risk treatment](PECB%2027001%20LA%20S05%20E03a%20-%20Risk%20treatment.md)
|
||||
|
||||
Part 4: Support – building blocks of the ISMS
|
||||
- [Clause 7.1: Resources](PECB%2027001%20LA%20S05%20E04%20-%20Support%20-%20building%20blocks%20of%20the%20ISMS.md#Resources)
|
||||
- [Clause 7.2: Competence](PECB%2027001%20LA%20S05%20E04%20-%20Support%20-%20building%20blocks%20of%20the%20ISMS.md#Competence)
|
||||
- [Clause 7.3: Awareness](PECB%2027001%20LA%20S05%20E04%20-%20Support%20-%20building%20blocks%20of%20the%20ISMS.md#Awareness)
|
||||
- [Clause 7.4: Communication](PECB%2027001%20LA%20S05%20E04%20-%20Support%20-%20building%20blocks%20of%20the%20ISMS.md#Communication)
|
||||
- [Clause 7.5: Documented information](PECB%2027001%20LA%20S05%20E04%20-%20Support%20-%20building%20blocks%20of%20the%20ISMS.md#Documented%20information)
|
||||
|
||||
Part 5: Operation
|
||||
- [Clause 8: Operation](PECB%2027001%20LA%20S05%20E05a%20-%20Operation.md)
|
||||
- [Clause 9: Performance evaluation](PECB%2027001%20LA%20S05%20E05b%20-%20Performance%20evaluation.md)
|
||||
- [Clause 10: Improvement](PECB%2027001%20LA%20S05%20E05c%20-%20Improvement.md)
|
||||
|
||||
|
|
@ -0,0 +1,49 @@
|
|||
## Clause 4: Context of the organization
|
||||
|
||||
[Clause 4.1](../../../MoCs/ISO_27001_2022_4.1_MoC%20Understanding%20the%20organization%20and%20its%20context.md), **Understanding the organization and its context**, is all about making sure the organisation understands itself, in order to build a fit for purpose ISMS, tailored to the needs of the organisation.
|
||||
|
||||
We distinguish between internal context and external context.
|
||||
|
||||
Internal context is about how the organization is structured, who makes decisions, what's the governance and oversight look like, what's the capability and maturity of the organization, etc.
|
||||
|
||||
External context is about what's happening in the outside world, 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 customers, etc.
|
||||
|
||||
[Clause 4.2](../../../MoCs/ISO_27001_2022_4.2_MoC%20Understanding%20the%20needs%20and%20expectations%20of%20interested%20parties.md) expands on that by treating the **needs and expectations of interested parties**, or stakeholders.
|
||||
|
||||
Interested parties in an ISMS can be both internal and external. External interested parties are entities such as customers, regulators, business partners, suppliers, trade unions, etc.
|
||||
|
||||
Internal interested parties are people like senior management, systems users, and organizational units like differen teams and departments.
|
||||
|
||||
The needs and requirements of all these parties should be examined when building an ISMS.
|
||||
|
||||
For instance, if you have a contract with a customer with the obligation to report a major incident involving their data within one business day, the ISMS must provide the necessary capabilities to do so.
|
||||
|
||||
[Clause 4.3](../../../MoCs/ISO_27001_2022_4.3_MoC%20Determining%20the%20scope%20of%20the%20information%20security%20management%20system.md) is about **Determining the scope of the ISMS**. An ISMS doesn't necessarily have to be implemented in the entire organization: its scope can be limited to certain organizational units, specific systems, or business processes.
|
||||
The scope, however, should be credible given the results of Clause 4.1 and 4.2: the organization should be able to logically explain the scope they've chosen.
|
||||
|
||||
[Clause 4.4](../../../MoCs/ISO_27001_2022_4.4_MoC%20Information%20security%20management%20system.md) then, states the requirement to have a fully functioning ISMS. This can of course only be fullfilled after all the other clauses and relevant controls are implemented.
|
||||
|
||||
**More about the the organization in its context ([4.1](../../../MoCs/ISO_27001_2022_4.1_MoC%20Understanding%20the%20organization%20and%20its%20context.md))**
|
||||
Every organization has a mission, or its reason for being. This is often worded in something like a mission statement.
|
||||
Organizations also have objectives, expressed in strategy notes, long term goals, high level planning, ambition statements and reports. These can be about launching new products, improving process efficiency or improving quality of service.
|
||||
|
||||
This is relevant because an organization implementing ISO 27001 must formulate an information security policy and its objectives. These need to be in line with the organisational goals. If the organization is looking to enter a certain market, which is heavily regulated or where clients enforce strict security regimes, the ISMS must be built to deal with that.
|
||||
|
||||
The security strategy should be focused on building security capabilities aligned with the organization's strategic goals, not just on getting ISO 27001 certified.
|
||||
|
||||
**More about the stakeholders ([4.2](../../../MoCs/ISO_27001_2022_4.2_MoC%20Understanding%20the%20needs%20and%20expectations%20of%20interested%20parties.md))**
|
||||
The implementation of an ISMS may affect many interested parties. Internal stakeholders like management, system users and employees may be required to take actions or will experience the consequences of security controls. External stakeholders like regulators may need to be briefed or made aware that this is being implemented. For this it's important to identify the stakeholders and their requirements.
|
||||
|
||||
These requirements might be explicit, like the aforementioned customer that requires major incidents to be reported within one business day. They may also be implied, like the expectation of the general public that you will safeguard the data they hand you and abide to relevant laws and regulations.
|
||||
|
||||
It's therefore also important that an organisation identifies their legal, regulatory and contractual obligations.
|
||||
|
||||
**More about the scope of the ISMS ([4.3](../../../MoCs/ISO_27001_2022_4.3_MoC%20Determining%20the%20scope%20of%20the%20information%20security%20management%20system.md))**
|
||||
According to this clause, when determining the scope 3 aspects must be taken into account:
|
||||
a) the external and internal issues from 4.1
|
||||
b) the stakeholder requirements from 4.2, and:
|
||||
c) internal and external interfaces and dependencies between organizational activities.
|
||||
|
||||
A relevant example is an organization using SaaS software provided by external organizations. Typically, the technology and the activities of the cloud service provider itself will be out of scope for the ISMS, but the responsibilities and processes for overseeing and managing the service delivery òf that provider *will* be in scope.
|
||||
|
||||
It is important that the scope of the ISMS, including the argumentation for it, is available as documented information.
|
||||
|
|
@ -0,0 +1,36 @@
|
|||
## Clause 5: Leadership
|
||||
|
||||
Clause 5 has three subclauses: Leadership and commitment, Policy, and Organizational roles responsibilities, and authorities.
|
||||
|
||||
The point of [Clause 5.1](../../../MoCs/ISO_27001_2022_5.1_MoC%20Leadership%20and%20commitment.md) is that there is support and commitment from an organization's senior leadership ('top management') to run and operate an ISMS in the long term. They should be overseeing and supporting the implementation of an ISMS.
|
||||
Who top management are will depend on the type of organization we're dealing with and the scope of the ISMS. In general top management will have titles like director, C-level executives, etc.
|
||||
But if the scope of the ISMS is limited to for instance a national subsidiary of an international firm, top management might be the Country Director. In a small company it might be the owner.
|
||||
|
||||
The involvement expected of top management is making sure that we not only have the necessary resources to implement the ISMS, but to run and operate it in the long term as well. These may be financial, technological and human resources.
|
||||
|
||||
Top management also has to make sure that people in the organization are aware that information security and implementing the ISMS is actually a top management concern, and not just the IT department's concern.
|
||||
They should be proactively reviewing the management system, driving continual improvement.
|
||||
|
||||
We will see that again in Clause 9.3 with the Management review.
|
||||
|
||||
### Clause 5.2: Policy
|
||||
[Clause 5.2: Policy](../../../MoCs/ISO_27001_2022_5.2_MoC%20Policy.md)
|
||||
|
||||
An important way for top management to show their commitment is by establishing an information security policy. A policy, according to ISO, is 'the formal intent and direction as expressed by an organisation's top management'.
|
||||
|
||||
The information security policy must match the purpose of the organization.
|
||||
|
||||
The policy should include, or reference, the security objectives, include a commitment to continual improvement, and a commitment of satisfying applicable requirements (legal, regulatory, and contractual).
|
||||
|
||||
This is usually a fairly short document, available to everyone in the organization, that sets the tone and direction with regards to information security, including tangible commitments, like appropriate training, risk treatment, effectiveness monitoring, etc.
|
||||
|
||||
Later on there will be other, more detailed topic specific policies, like cryptography, network security, and application security. This is treated in Annex A.
|
||||
|
||||
### Clause 5.3: Organizational roles, responsibilities and authorities
|
||||
[Clause 5.3](../../../MoCs/ISO_27001_2022_5.3_MoC%20Organizational%20roles,%20responsibilities%20and%20authorities.md)
|
||||
|
||||
To argue that the top management is committed, and to have an effective ISMS, people need to be appointed to actually run and operate the ISMS, and be formally authorised to do so. That means assigning responsibilities for activities like risk assessments, policy creation, incident handling or conducting internal audits.
|
||||
|
||||
People need to report on the performance of the ISMS and conformity to the standard (ISO 27001) to top management, so they can't just allocate roles and be done with it.
|
||||
|
||||
The standard does not give instructions on specific job titles and responsibilities, as they will be different for every organization.
|
||||
|
|
@ -0,0 +1,114 @@
|
|||
## Clause 6.1: Actions to address risks and opportunities
|
||||
|
||||
[Clause 6.1.1](../../../MoCs/ISO_27001_2022_6.1.1_MoC%20General.md) ('General') isn't about information security risks specifically, it's about the ISMS, and risks *to* the ISMS.
|
||||
|
||||
Clause 6.1.1 says that when planning the ISMS, the organization shall consider the issues referred to in [4.1](../OST/27001/EN/c-4.1-Understanding-the-organization-and-its-context.md) (Context) and the requirements referred to in [4.2](../../../iso27diy-corp/Corpus/Standards/ISO-27001-OST/ISO27001-EN-2022/ISO_27001_2022_OT%204.2%20Understanding%20the%20needs%20and%20expectations%20of%20interested%20parties.md) (Needs and expectations of interested parties), 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 when we're thinking about establishing an ISMS, what are the situations or events that could have a negative effect on the ability of the ISMS to work as expected. Examples are resource shortages, or lack of appropriate support from management.
|
||||
|
||||
On the flip site, there may be opportunities to gain benefits from the ISMS beyond it's primary purpose, information security. For example, having a certified ISMS may increase commercial opportunities, or the detailed risk analysis that is part of the ISMS, may may identify opportunities to improve efficiency in certain processes, or remove duplication, etc.
|
||||
|
||||
Clause 6.1.1 wants us to focus on those particular risks and opportunities.
|
||||
|
||||
Clause 6.1.2, on the other hand, *is* about information security risks.
|
||||
|
||||
## Clause 6.1.2: Information security risk assessment
|
||||
|
||||
Where [Clause 6.1.1](../../../MoCs/ISO_27001_2022_6.1.1_MoC%20General.md) is about risks to the *ISMS*, [Clause 6.1.2](../../../MoCs/ISO_27001_2022_6.1.2_MoC%20Information%20security%20risk%20assessment.md), on the other hand, is about risks to the *security of information*.
|
||||
|
||||
Clause 6.1.2 states that the organization shall define and apply an information security **risk assessment process** that does a number of things, starting with the establishment, and following maintenance, of **risk criteria**. You may think of this as setting rules for the organization, to understand what information security risks *are*.
|
||||
|
||||
### Risk Criteria
|
||||
|
||||
The first step in this is setting **risk acceptance criteria**: when a risk is identified, how do we decide it it's acceptable to the organization? If the organization already has some general rules or criteria for dealing with risks, you can use that as a starting point.
|
||||
|
||||
It's also required that we set criteria for *performing* risk assessments, so that we know when we need to do it, for instance: yearly, and/or at the start of a new project, after a major incident, etc.
|
||||
|
||||
The answers to these questions need to be part of a documented risk assessment process.
|
||||
|
||||
This risk assessment process should ensure repeatable results – we'll get back to that a little bit later.
|
||||
|
||||
A very important thing to bring up early, is **risk ownership**. We need to be clear about who the risk owner will be, even before we start identifying risks. Because as soon as we identify them, decisions need to be made on what to do with them. Risk owners are individuals in the organization with a level of authority and trust to make these risk decisions. It's impractical for several reasons to have a discussion of risk ownership after the fact.
|
||||
|
||||
As an auditor I expect to see a clearly defined and understandable risk assessment process, and evidence for its execution, by maybe getting somebody to take me through risk assessments that have been performed.
|
||||
|
||||
Although Clause 6.1.2 tells you what should be considered when doing risk assessments, it does not tell you *how* to conduct a risk assessment. It doesn't tell you to use a risk calculation scale of 1 to 10, or high, medium and low, or using some other kind of formula, and neither does the ISO 27002 implementation guidance, of the [ISO 27005](../ISO%2027005.md) (Guidance on managing information security risks).
|
||||
|
||||
What it *does* tell us, is that we need to have an agreed way of conducting risk assessments, and that we need predefined risk acceptance criteria.
|
||||
|
||||
A good way to start is sitting down with management to create an 'Impact Table' with different levels of impact. If the possible damage reaches a certain level, there will be set consequences. You may call this **risk escalation criteria**. So for instance if a risk could result in the loss of money beyond a certain amount, and the likelihood of that happening is above a certain level, the information security committee cannot mark it as acceptable, and it needs to come to the board for review.
|
||||
|
||||
These are the kind of conversations that an organization should be having to define these criteria and identify the overall level of acceptable risk when it comes to information security.
|
||||
|
||||
The level of acceptable risk is also called **risk appetite**, and it will vary depending on the organization. A government entity, for example, may be looking for stability and doesn't want to take any unnecessary risks, and a such will have a low risk appetite, whereas a venture capitalist looking for rapid growth may have a much higher risk appetite, because thy believe innovating and taking risks are necessary for growth.
|
||||
|
||||
As an auditor it's important you're able to understand if they have defined these things and why, and does it have the appropriate support from top management.
|
||||
|
||||
### Comparable and reproducible results
|
||||
|
||||
Clause 6.1.2b says that the organization must ensure that risk assessments generate "consistent, valid and comparable results".
|
||||
|
||||
This means that the results of a repeated risk assessment must be reproducible, independent of the situation and the person conducting the assessment. This is done by having (and following) a defined risk assessment methodology.
|
||||
|
||||
|
||||
**Defining a Risk Assessment Approach**
|
||||
|
||||
|
||||
|
||||
There are many methodologies available – some are very simple and some of them very complex and detail orientated. It's also possible to design your own methodology. So how can an organization settle on one that makes sense?
|
||||
|
||||
First thing is, it must be compatible with the requirements of 27001, which means it should consider threat, vulnerability, impact and likelihood, and the three tenants of security (Confidentiality, Integrity, Availability).
|
||||
|
||||
Also, the terms used (the vocabulary) needs to be defined, so that when refers to the concept of threat, for example, it must be clear to all what is meant by that.
|
||||
|
||||
|
||||
**Selecting a Risk Assessment Methodology**
|
||||
|
||||
|
||||
|
||||
Number 5 in this diagram, ease of use and pragmatism of the method, means the method must match the organization at the time of application. A large government department with low risk appetite and plenty of resources, might spend 50 days or more assessing the risks of a single system, because it justifies the type of system and the information it's trying to protect. A small startup with no previous experience in formal risk assessment, may choose to start with a simple to use spreadsheet.
|
||||
|
||||
So the method you pick must be fit for purpose and suitable for the organization. This also comes back in point 3 (available tooling), point 4 (documentation and competencies) and point 6 (costs of utilization).
|
||||
|
||||
Costs of utilization can be broken down in the time needed, need to bring in specialists, etc.
|
||||
|
||||
Well known methods of risk analysis include:
|
||||
|
||||
- [OCTAVE](../../CISSP/CISSP_OSG8_D1_C1_1.10.md#OCTAVE) from Carnegie Mellon University
|
||||
- MEHARI, mostly used in Europe
|
||||
- EBIOS, now maintained by ANSSI France
|
||||
- IRAM from the Information Security Forum
|
||||
|
||||
OCTAVE S and and Allegro are targeted at smaller organizations.
|
||||
|
||||
The risk management method chosen should follow the stages that are laid out in ISO 27005: Guidance on managing information security risks.
|
||||
|
||||
### Risk identification in ISO 27005
|
||||
The first step in Risk Management, according to ISO 27005, is risk identification.
|
||||
|
||||
|
||||
*Risk identification according to ISO 27005, clause 7.2.1. This relates to [ISO 27001:2022, 6.1.2 c1](../OST/27001/EN/c-6.1.2-Information-security-risk-assessment.md).*
|
||||
|
||||
This is done by identifying potential scenarios, without yet looking at likelihood or impact. It's usually a team effort with people from a given part of the organization, and apart from risk owners may involve domain experts, subject experts, and a facilitator.
|
||||
|
||||
The two main approaches are Asset Based and Event Based risk identification.
|
||||
|
||||
In **event based risk identification** we talk about specific events in general. Let's take ransomware as an example. We can talk about a possible ransomware event and how that might play out in our organization.
|
||||
In an **asset based** approach we focus on specific assets (like software systems), and examine their potential vulnerabilities and threats.
|
||||
|
||||
While the event based approach gives you a good organizational overview by clarifying the impact in different organizational environments, the asset based approach gives you more specific details. In general a combination of these two methods is best, especially for critical assets.
|
||||
|
||||
In the identification phase it's best to postpone arguments about the likeliness of specific scenario's happening, to the next phase: risk analysis and evaluation.
|
||||
|
||||
### Risk analysis and evaluation in ISO 27005
|
||||
In risk analysis we look at the potential consequences of risk scenario's playing out, and the likelihood of them.
|
||||
|
||||
Likelihood can be established by looking at previous historical data, either in our own organization or in others. If that information is not available, you can look at vulnerabilities and how easy it is to exploit them. Do they require a lot of insider knowledge or technical expertise, and a determined and motivated threat actor to exploit them, or is exploitation trivial? How motivated and capable are our threat sources? For instance, may I be targeted by state actors or organized crime groups?
|
||||
|
||||
These are indicators of the likelihood of risks materializing. You can answer these questions if you've done a proper threat analysis (see [Control 5.7](../../../MoCs/ISO_27002_2022_5.7_MoC%20Threat%20intelligence.md)).
|
||||
|
||||
As an auditor you will be looking at if the organization calculates likelihoods and consequences, does it have a proper system for doing so, is it evaluation risks by looking at a combination of likelihood and consequence (probability x impact), and making decisions about risk treatment and priorities based on that.
|
||||
|
||||
Apart from ISO 27005, other standards like the NIST SP 800-30 and the TRA (The Harmonized Threat and Risk Assessment from the Canadian Government) offer guidance for conduction information security risk assessments.
|
||||
|
||||
Risk treatment comes into play when risk owners decide that risks are unacceptable and action needs to be taken. We'll shortly see that the risk owner is the one who should be approving the risk treatment plan and validating that risk treatment is taking place.
|
||||
|
|
@ -0,0 +1,17 @@
|
|||
## Clause 6.2: Objectives and planning
|
||||
|
||||
[Clause 6.2](../../../MoCs/ISO_27001_2022_6.2_MoC%20Information%20security%20objectives%20and%20planning%20to%20achieve%20them.md) demands that organizations should have information security objectives. These may be derived from the risk assessment from 6.1, from commercial objectives, from legal and regulatory compliance, or based on some other ambition or necessity.
|
||||
|
||||
The information security objectives the organization identifies shall:
|
||||
- be consistent with information security policy ([C5.1](../../../MoCs/ISO_27001_2022_5.1_MoC%20Leadership%20and%20commitment.md), [A5.1](../archive/iso27DIY%20mk%20I/ISO_27002_2022_5.1_MoC%20Policies%20for%20information%20security.md))
|
||||
- results from the risk assessment ([6.1.2](../../../MoCs/ISO_27001_2022_6.1.2_MoC%20Information%20security%20risk%20assessment.md)) and risk treatment ([6.1.3e](../../../MoCs/ISO_27001_2022_6.1.3_MoC%20Information%20security%20risk%20treatment.md))
|
||||
- take into account applicable information security requirements ([4.2](../../../MoCs/ISO_27001_2022_4.2_MoC%20Understanding%20the%20needs%20and%20expectations%20of%20interested%20parties.md), needs and expectations of interested parties),
|
||||
- be measurable (if practicable, see below)
|
||||
|
||||
... and these objectives shall be communicated and updated the objectives 'as appropriate'.
|
||||
|
||||
So the objectives formulated will be based on an understanding of the organization and its context ([4.1](../../../MoCs/ISO_27001_2022_4.1_MoC%20Understanding%20the%20organization%20and%20its%20context.md)), an understanding of the needs and expectations of interested parties ([4.2](../../../MoCs/ISO_27001_2022_4.2_MoC%20Understanding%20the%20needs%20and%20expectations%20of%20interested%20parties.md)), an understanding of the risks ([6.1](../../../MoCs/ISO_27001_2022_6.1_MoC%20Actions%20to%20address%20risks%20and%20opportunities.md)), and the discussions we've had with our management.
|
||||
|
||||
Some security objectives might be very high level and long term, like ensuring ongoing legal and regulatory compliance, or short-term and much more measurable objectives, like improving incident response time.
|
||||
|
||||
The organization must also have clear plans to achieve these objectives, because the underlying purpose of having an ISMS is: to allow the organization to achieve its objectives.
|
||||
|
|
@ -0,0 +1,3 @@
|
|||
## Clause 6.3: Planning of changes
|
||||
|
||||
This says nothing more than if the organization detects a need for changes to the ISMS, they must be carried out in a planned manner.
|
||||
|
|
@ -0,0 +1,53 @@
|
|||
## Clause 6.1.3: Information security risk treatment
|
||||
|
||||
[Clause 6.1.3](../../../MoCs/ISO_27001_2022_6.1.3_MoC%20Information%20security%20risk%20treatment.md) describes the treatment of information security risks.
|
||||
This is about choosing risk treatment options, and determining which controls we might implement to respond to a risk.
|
||||
|
||||
We can do that by selecting controls from Annex A, culminating in the Statement of Applicability[^2] (6.1.3d).
|
||||
Another important output of the risk treatment process is the Risk Treatment Plan (6.1.3e).
|
||||
|
||||
It's important that the risk owner gives his approval for the risk treatment plan, accepts the residual risk – that's the risk that's going to be left after the treatment has took place (6.1.3f). The risk owner's approval is vitally important: as an auditor you need to see that the risk owner was involved, and ultimately made that final decision.
|
||||
|
||||
### Risk treatment options
|
||||
|
||||
These are the risk treatment options:
|
||||
|
||||
1. Risk modification
|
||||
2. Risk avoidance
|
||||
3. Risk sharing
|
||||
4. Risk retention
|
||||
|
||||
|
||||
**Risk modification** means changing the circumstances around a risk, by implementing controls to reduce the *vulnerability* to threats, reduce the *likelihood* of a risk materializing, or the *impact* of a risk *when* it materializes.
|
||||
|
||||
Examples are implementing network segregation and firewalls to reduce the vulnerability and the likelihood, and disk encryption on laptops to reduce the potential impact of a laptop being stolen.
|
||||
|
||||
The reason ISO speaks of modification instead of reduction is that in theory, we could choose to increase the risk. Suppose a security control is so effective that it has lowered the risk far below the risk tolerance level, but we need to spend a lot of time and money to implement it. The organization could then decide to remove or weaken the control, just as long as the risk is still managed.
|
||||
|
||||
**Risk avoidance** is where we take a decision to avoid the risk scenario partly or wholly. Examples are to stop accepting card payments from a particular territory we see a lot of fraud, not using a particular type of technology, or not taking your devices across certain geographical borders.
|
||||
|
||||
**Risk sharing** is when two organizations share the burden of a risk. Examples are outsourcing to a party with more expertise in a certain area, like a provider of network services or a payment services provider.
|
||||
This was previously called risk transfer, but this term was dropped because you actually can't pass a risk to somebody else: as an organization you remain accountable to regulators and clients in case of a security breach, even if you outsourced the asset or the process (with due diligence) where the breach occurred.
|
||||
|
||||
**Risk retention** means accepting a risk *for now*. This may be needed when the other treatment options are impractical, not affordable, technically not feasible, or unavailable. Retention is allowed providing that it's done as part of a proper process in line with your risk management process, and it's not just the default go-to option.
|
||||
|
||||
### Risk modification by implementing controls
|
||||
|
||||
Clause 8.3 of [ISO 27005](../ISO%2027005.md), the guidance document on risk management[^1], says that we shall select controls in order to address risks. These can be preventative, detective or corrective in nature.
|
||||
|
||||
Which controls will be implemented by the organization, is specified in the Statement of Applicability (6.1.3d).
|
||||
|
||||
In the SoA the organization can't just say they've included a control because "you know we're just ticking a box".
|
||||
|
||||
|
||||
For controls deemed not applicable by the organization, the auditor will want to know how you came to that conclusion. The simplest reasons for not including a control is because they don't have the business process it applies to (like software development or working from home), the proces is declared out of scope, or the control is at odds with a law or a regulation.
|
||||
|
||||
The controls in Annex A are often described in just one or two sentences. You must look at ISO 27002 for guidance on the implementation of a control.
|
||||
|
||||
|
||||
|
||||
---
|
||||
## Footnotes
|
||||
|
||||
[^1]: There's also a [Clause 8.3](../../../MoCs/ISO_27001_2022_8.3_MoC%20Information%20security%20risk%20treatment.md) Information security risk treatment in ISO 27001. It's very short: The organization shall implement the information security risk treatment plan, and it shall retain documented information on the treatments' results.
|
||||
[^2]: See also [About the Statement of Applicability](../../../💡Drafts%20and%20Ideas/ISMS/About%20the%20Statement%20of%20Applicability.md).
|
||||
|
|
@ -0,0 +1,91 @@
|
|||
# Clause 7: Support
|
||||
|
||||
Clause 7 covers five distinct areas, from resources to documented information. These are **the building blocks of the management system**. These need to be in place to make the management system work effectively:
|
||||
|
||||
- Resources (7.1)
|
||||
- Competence (7.2)
|
||||
- Awareness (7.3)
|
||||
- Communication (7.4)
|
||||
- Documented information (7.5)
|
||||
## Resources
|
||||
|
||||
The first is Resources ([Clause 7.1](../../../MoCs/ISO_27001_2022_7.1_MoC%20Resources.md)). This clause says the organization shall determine and provide the resources needed for the establishment, implementation, maintenance and continual improvement of the ISMS. These resources can be human (people), financial (budget), tools and technologies, and physical workspace (if relevant).
|
||||
|
||||
As an auditor you're looking for evidence of proper planning to have the right resources in place at the right time. This planning should have a reasonable time horizon (let's say for the coming 12 months) or at least line up with the planning in other area's of the organization.
|
||||
|
||||
## Competence
|
||||
|
||||
When dealing with human resources[^1], they should not only be available, but competent as well according to Clause 7.2.
|
||||
[Clause 7.2](../../../MoCs/ISO_27001_2022_7.2_MoC%20Competence.md) states that competence should be established on the basis of education, training or experience, and that the organization should take actions to ensure adequate competence where this is not the case.
|
||||
|
||||
So if the organization establishes roles and responsibilities for security[^1], they must also define the skill sets needed to fulfill those roles.
|
||||
|
||||
This will affect business processes beyond the domain of information security, for instance hiring strategy, screening, onboarding programs, and training[^2].
|
||||
|
||||
Clause 7.2 also says that this applies to 'persons doing work under its control' that affects security performance, so this could be permanent staff, temporary staff and insourced personnel.
|
||||
|
||||
[^1]: There's also a link with [Clause 5.3](../../../MoCs/ISO_27001_2022_5.3_MoC%20Organizational%20roles,%20responsibilities%20and%20authorities.md): Organizational roles, responsibilities and authorities.
|
||||
[^2]: See [A 6.1](../../../MoCs/ISO_27002_2022_6.1_MoC%20Screening.md) Screening, [A 6.3](../../../MoCs/ISO_27002_2022_6.3_MoC%20Information%20security%20awareness,%20education%20and%20training.md) Awareness, education and training
|
||||
|
||||
## Awareness
|
||||
|
||||
[Clause 7.3](../../../MoCs/ISO_27001_2022_7.3_MoC%20Awareness.md), Awareness, again applies to persons doing work under the organization's control: employees, freelancers, contractors and even suppliers.
|
||||
These persons 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[^3].
|
||||
|
||||
This is often tackled by having a broad awareness programme for both new longer term employees, with initiatives like e-learning, awareness training sessions, etc. But what we're looking for is efforts to really drive the right security behaviors, like building a strong security culture where people think about security being a normal part of their duties instead of a separate organizational discipline. For that you can look at training records, or interview a sample of employees on, for instance, what they recall of their training.
|
||||
|
||||
[^3]: See [A 6.4](../../../MoCs/ISO_27002_2022_6.4_MoC%20Disciplinary%20process.md) Disciplinary process
|
||||
|
||||
## Communication
|
||||
|
||||
Communication is the topic of [Clause 7.4](../../../MoCs/ISO_27001_2022_7.4_MoC%20Communication.md).
|
||||
|
||||
You cannot run an effective management system without having regular communication with the interested parties (who have been identified under [|Clause 4.2](../../../MoCs/ISO_27001_2022_4.2_MoC%20Understanding%20the%20needs%20and%20expectations%20of%20interested%20parties.md)). Like for instance the customers, whose confidence you need, the management, to ensure ongoing buy-in, or the users, to encourage the right behaviors.
|
||||
|
||||
This requires a plan describing what will be communicated, to whom, when and how often, in what kind of language, and through what methods or channels.
|
||||
|
||||
As an auditor you will look for that plan, examples of communication, and evidence of establishing the impact or effectiveness of the communication.
|
||||
|
||||
The communication should not be one way, so how does the organization manage questions about security, or feedback on the training methods? Are these used to improve the communication about security?
|
||||
|
||||
## Documented information
|
||||
|
||||
The point of creating documentation is that it helps the organization in **doing things well** and doing them **in a consistent manner**.
|
||||
|
||||
There's two kinds of documentation required by [Clause 7.5.1](../../../MoCs/ISO_27001_2022_7.5_MoC%20Documented%20information.md): what is literally mentioned in the standard itself (a), and what the organization has determined necessary to run the ISMS effectively(b).
|
||||
|
||||
What is literally mentioned is documentation like the scope statement, the information security policy, the risk management process, the statement of applicability, the resource requirements, and planning – [4.3](../../../MoCs/ISO_27001_2022_4.3_MoC%20Determining%20the%20scope%20of%20the%20information%20security%20management%20system.md), [5.2](../../../MoCs/ISO_27001_2022_5.2_MoC%20Policy.md), [6.1](../../../MoCs/ISO_27001_2022_6.1_MoC%20Actions%20to%20address%20risks%20and%20opportunities.md), [6.1.3d](../../../MoCs/ISO_27001_2022_6.1_MoC%20Actions%20to%20address%20risks%20and%20opportunities.md), [7.1](../../../MoCs/ISO_27001_2022_7.1_MoC%20Resources.md), and [6.2](../../../MoCs/ISO_27001_2022_6.2_MoC%20Information%20security%20objectives%20and%20planning%20to%20achieve%20them.md), respectively. These can be identified in the standard with the word 'Shall'.
|
||||
|
||||
Do not step into the trap of 7.5.1b by thinking you need to have a document for every clause and control in the 27001. The keyword is effectiveness.
|
||||
|
||||
If you have a complex task in a complex environment with possibly high security risks, it's important that this task is consistently performed in detail. In that case you need a detailed document with step-by-step instructions. For simpler, lower risk tasks that will be performed by competent staff, the documentation may be quite sparse.
|
||||
|
||||
Other aspects that have an effect on the necessity of documentation are the size of a company (smaller is usually less) and the frequency of events the documentation describes (like a written Leavers procedure for a small organization that has had very few leavers in the past 10 years). In those cases written documentation may not be required, but the auditor may raise an opportunity for improvement.
|
||||
|
||||
As an auditor you need to think about proportionality and added value.
|
||||
|
||||
#### Managing the document life cycle
|
||||
There need to be rules on how to manage the life cycle of documentation in the ISMS.
|
||||
|
||||
These are rules about:
|
||||
- the identification of documents: Is it a policy? Is it a procedure?
|
||||
- the use of metadata (e.g. date, author, or reference number) and titles
|
||||
- who should be able to create and update documentation (levels of authorization)
|
||||
- review and approval of documentation
|
||||
- version control
|
||||
- their classification and security level
|
||||
- access and handling, especially for sensitive information
|
||||
- sharing and distribution, making sure people can find relevant documentation
|
||||
- archiving and disposal
|
||||
|
||||
(related: [C 5.3](../../../MoCs/ISO_27001_2022_5.3_MoC%20Organizational%20roles,%20responsibilities%20and%20authorities.md), [A 5.10](../../../MoCs/ISO_27002_2022_5.10_MoC%20Acceptable%20use%20of%20information%20and%20other%20associated%20assets.md), [A 5.12](../../../MoCs/ISO_27002_2022_5.12_MoC%20Classification%20of%20information.md), [A 5.13](../../../MoCs/ISO_27002_2022_5.13_MoC%20Labelling%20of%20information.md), [A 5.15](../../../MoCs/ISO_27002_2022_5.15_MoC%20Access%20control.md), [A 5.18](../../../MoCs/ISO_27002_2022_5.18_MoC%20Access%20rights.md), [ A 8.10](../../../MoCs/ISO_27002_2022_8.10_MoC%20Information%20deletion.md))
|
||||
|
||||
To check if documents are being used adequately, you can look at if people actually referring to them, and are behaving according to the contents of the documents. This can be discovered through things like monitoring and metrics, or the internal audit process[^4].
|
||||
|
||||
If documents are archived, it's important to know how the archives are protected. For the disposal of documents, the method may very depending on the sensitivity of the information.
|
||||
|
||||
An organization should have a document management policy that addresses all of these points.
|
||||
|
||||
If the organization already has another management system in place, like ISO 9001, they will probably already have these processes in place, and they can reuse them for ISO 27001, as all ISO management systems have the same demands here.
|
||||
|
||||
[^4]:Related: [C 9.1](../../../MoCs/ISO_27001_2022_9.1_MoC%20Monitoring,%20measurement,%20analysis%20and%20evaluation.md), [C 9.2](../../../MoCs/ISO_27001_2022_9.2_MoC%20Internal%20audit.md), [A 8.16](../../../MoCs/ISO_27002_2022_8.16_MoC%20Monitoring%20activities.md)
|
||||
|
|
@ -0,0 +1,29 @@
|
|||
# Clause 8: Operation
|
||||
|
||||
Clause 8, Operation, has three parts to it:
|
||||
|
||||
- [Operational planning and control](../../../MoCs/ISO_27001_2022_8.1_MoC%20Operational%20planning%20and%20control.md)
|
||||
- [Information security risk assessment](../../../MoCs/ISO_27001_2022_8.2_MoC%20Information%20security%20risk%20assessment.md)
|
||||
- [Information security risk treatment](../../../MoCs/ISO_27001_2022_8.3_MoC%20Information%20security%20risk%20treatment.md)
|
||||
|
||||
## Clause 8.1: Operational Planning and Control
|
||||
|
||||
So let's have a look at [Clause 8.1](../../../MoCs/ISO_27001_2022_8.1_MoC%20Operational%20planning%20and%20control.md) Operational Planning and Control.
|
||||
|
||||
In Clause 6, part of the Plan phase, we looked at information security assessment and risk treatment, and the outcomes where a risk assessment *process*, a risk treatment plan, and a list of the controls we'd implement in the form of a statement of applicability (clauses [6.1.2](../../../MoCs/ISO_27001_2022_6.1.2_MoC%20Information%20security%20risk%20assessment.md) and [6.1.3](../../../MoCs/ISO_27001_2022_6.1.3_MoC%20Information%20security%20risk%20treatment.md)).
|
||||
|
||||
Clause 8 is part of the Do phase, and describes how we will execute the actions from Clause 6, to confirm that the risk assessments are actually being carried out and that the risk treatment plans and controls are actually being implemented. This is the subject of Clause 8.1.
|
||||
|
||||
These controls and processes should be implemented effectively and be sustainable over time, which requires planning and clear criteria for success.
|
||||
|
||||
As an example, consider the decision of an organization to implement log management software to capture system logs and monitor for suspicious activity.
|
||||
They would need to identify the functional requirements of the software, the kind of events and logs they want to process, necessary capacity, etc.
|
||||
They would need to think about how they will fit it into the organization, like establishing a process for reviewing the logs, resource requirements, acquiring the necessary skills, how it will integrate with the incident management process of the organization, who to involve and how to communicate it to the rest of the organization, and so on.
|
||||
|
||||
Even if the organization decides to outsource the process, it still needs to be managed. We still need to make sure the solution meets certain requirements with regards to information security and service delivery[^1].
|
||||
|
||||
This is what's meant by operational planning and control.
|
||||
|
||||
|
||||
|
||||
[^1]: The ISO 37500 offers guidance on outsourcing.
|
||||
|
|
@ -0,0 +1,42 @@
|
|||
# Clause 9: Performance evaluation
|
||||
|
||||
Clause 9 handles Performance evaluation. It consists of 3 parts:
|
||||
- [Monitoring, measurement, analysis and evaluation](../../../MoCs/ISO_27001_2022_9.1_MoC%20Monitoring,%20measurement,%20analysis%20and%20evaluation.md)
|
||||
- [Internal audit](../../../MoCs/ISO_27001_2022_9.2_MoC%20Internal%20audit.md)
|
||||
- [Management review](../../../MoCs/ISO_27001_2022_9.3_MoC%20Management%20review.md)
|
||||
|
||||
Looking at clause 9.1, Monitoring, measurement, analysis and evaluation, the organization needs to decide what parts of the ISMS they would like to monitor on a regular basis, so that the performance can be evaluated.
|
||||
|
||||
Monitoring and measuring involves:
|
||||
- setting objectives for measuring and monitoring:
|
||||
- selecting what to measure (which attributes)
|
||||
- establishing performance indicators and targets (how to recognize succes)
|
||||
- evaluating if the objectives are achieved.
|
||||
|
||||
It's important to note that an organization is *not* expected to monitor, measure, analyse and evaluate each and every item of clause 4 to 10 and the Annex.
|
||||
|
||||
As the standard itself doesn't prescribe *what* to monitor, your best choice is taking the security objectives as a starting point. So what and how will the organization measure and check whether those objectives (from [6.2](../../../MoCs/ISO_27001_2022_6.2_MoC%20Information%20security%20objectives%20and%20planning%20to%20achieve%20them.md)) are being fulfilled.
|
||||
|
||||
Other focus points may be controls that are implemented to deal with significant risks (from [6.1.2](../../../MoCs/ISO_27001_2022_6.1.2_MoC%20Information%20security%20risk%20assessment.md)), and legal and regulatory compliance.
|
||||
|
||||
Besides identifying what to monitor, the organization must determine how frequently those measurements will take place, who will be taking them, and which actions will be taken in response.
|
||||
|
||||
The standard also doesn't tell us what targets we should have for indication success. So the organization needs to set them for themselves, or deduce them from contractual obligations, legal obligations, or from obligations under the standards (from [Clause 4.2](../../../MoCs/ISO_27001_2022_4.2_MoC%20Understanding%20the%20needs%20and%20expectations%20of%20interested%20parties.md)).
|
||||
|
||||
An organization can also have their own KPIs (key performance indicators). When designing and implementing the ISMS, it's advisable to identify early on what those key performance indicators are.
|
||||
|
||||
As an auditor you want to see that the organization is checking those things regularly.
|
||||
|
||||
## Internal audits
|
||||
|
||||
The purpose of internal audits ([Clause 9.2](../../../MoCs/ISO_27001_2022_9.2_MoC%20Internal%20audit.md)) is to validate whether the ISMS confirms to the ISO 27001 standard, and whether it's working effectively: is it effectively implemented, maintained, does it help the organization to fulfill its objectives, etc.
|
||||
|
||||
Clause 9.2.2b demands the **independence** of the audit process, which in practice means the auditors must be independent of the work they're assessing, and be able to make honest observations based on the evidence they see. The organization must also validate that internal auditors have the necessary **competence** to perform an audit ([Clause 7.2](../../../MoCs/ISO_27001_2022_7.2_MoC%20Competence.md)).
|
||||
|
||||
The auditor must also check if there's an **audit program** in place, and that the internal audit is not just a one-off effort. So that means a series of planned audits over a period of time. There might be a yearly overall audit, or audits focussing on certain area's over time, or audits that focus more deeply into particularly critical areas (high risk or core business processes)
|
||||
|
||||
### Management Review
|
||||
The management review ([Clause 9.3](../../../MoCs/ISO_27001_2022_9.3_MoC%20Management%20review.md)) is meant to give top management the opportunity to see what is happening with the management system. This doesn't have to be a meeting called "management review", but it needs to happen at regular intervals. The person overseeing the ISMS is usually the person that calls and facilitates the review.
|
||||
|
||||
The agenda for the meeting is given in Clause 9.3.2. It's important that the meeting is focussed on the **strategic aspects** of the ISMS: does it align with the objectives and requirements of the organization, does the scope need to be changed, etc. – in other words, judging the ISMS's suitability, adequacy and effectiveness), and that **decisions** can be made on those aspects.
|
||||
|
||||
|
|
@ -0,0 +1,28 @@
|
|||
# Clause 10: Improvement
|
||||
Where Clause 9 is concerned with establishing the effectiveness and conformity of the ISMS, Clause 10 looks at the actions the organizations must take in response to the findings. Clause [Clause 10.1](../../../MoCs/ISO_27001_2022_10.1_MoC%20Continual%20improvement.md) states the requirement of continual improvement and [Clause 10.2](../../../MoCs/ISO_27001_2022_10.2_MoC%20Nonconformity%20and%20corrective%20action.md) Nonconformity and corrective action.
|
||||
|
||||
In case of an initial audit it may be hard for the organization to show proof of improvements being in place following the first management reviews, but they could point at how they're going to measure, what mechanisms they've got in place to respond, what improvements they have planned for the near future, and how they are going to track progress.
|
||||
|
||||
## Nonconformity and corrective action
|
||||
|
||||
[Clause 10.2](../../../MoCs/ISO_27001_2022_10.2_MoC%20Nonconformity%20and%20corrective%20action.md) talks about Nonconformity and corrective action.
|
||||
|
||||
A non-conformity is the non-fulfillment of a requirement, either of the standard or the organization's own requirements, and the organization is required to react to that.
|
||||
|
||||
There's a distinction to be made between a correction, which is repairing the consequences of a problem, and a corrective action, which is finding the root cause and the situation that allowed this problem to arise, and creating a plan to address the causes and preventing the problem from reoccurring (called a Corrective Action Plan or CAP).
|
||||
|
||||
For example: an organization finds that a number of devices has not had software patches installed for over 6 months. Applying these patches as soon as possible is advised, but this a correction. A corrective action is finding the problems in the patching process and repairing them, improving the relevant monitoring process and clarifying the responsibilities.
|
||||
|
||||
As an auditor you will be looking for described non-conformities, a root cause analysis process, reports of root cause analyses having been conducted.
|
||||
|
||||
### Corrective action process
|
||||
|
||||
The corrective action process should include the following steps:
|
||||
|
||||
1. **Identification and documentation** of the nonconformity: The persons responsible define and document the nonconformity and analyze its impacts on the organization.
|
||||
2. **Analysis of the root causes**: The persons responsible determine the source of the nonconformity and analyze the root causes.
|
||||
3. **Evaluation of solutions**: The persons responsible develop a list of possible corrective actions and evaluate different action plans. At this stage, if the problem is significant or if the likelihood of reoccurrence is high, temporary corrective actions can be taken.
|
||||
4. **Selection of solutions**: The persons responsible select one or more corrective actions to correct the situation and determine the improvement objectives. The selected solution must correct the problem and should also be able to avoid its reoccurrence.
|
||||
5. **Implementation of corrective actions**: The persons responsible implement the corrective action plan that as approved and document all the actions described in the plan.
|
||||
6. **Follow-up on corrective actions**: The persons responsible check whether the new corrective processes are in place and effective.
|
||||
7. **Review of corrective actions**: The persons responsible periodically evaluate whether the objectives are being accomplished based on the defined corrective actions and whether those actions remain effective over time.
|
||||
|
|
@ -0,0 +1,19 @@
|
|||
# Section 6: Fundamental audit concepts and principles
|
||||
|
||||
[Part 1: What is an audit?](PECB%2027001%20LA%20S06%20E01%20-%20What%20is%20an%20audit.md)
|
||||
[Part 2: Audit principles](PECB%2027001%20LA%20S06%20E02%20-%20Audit%20principles.md)
|
||||
[Part 3: Threats to independence](PECB%2027001%20LA%20S06%20E03.md)
|
||||
|
||||
Involved parties
|
||||
|
||||
Audit objectives and criteria
|
||||
|
||||
Combined audit
|
||||
|
||||
Principles of auditing
|
||||
|
||||
Competence and evaluation of auditors
|
||||
|
||||
---
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,87 @@
|
|||
# What is an audit?
|
||||
|
||||
ISO 19011 clause 3.1 defines an audit as a systematic, independent, and documented process for obtaining objective evidence and evaluating it, again objectively, to determine the extent to which the audit criteria are fulfilled.
|
||||
|
||||
It's an assessment by an auditor on the evidence and the facts that a company is trying to present to that auditor.
|
||||
|
||||
There are financial audits, administrative audits, IT systems audits, and information security audits, which is the subject of ISO 27001.
|
||||
|
||||
Relevant standards for auditing are:
|
||||
- ISO 19011, which provides guidance on managing audit programs
|
||||
- ISO 17021-1, which contains requirements for bodies providing audits and certification of management systems, so that they can prove competence, consistency, impartiality, and ensure credible certification
|
||||
- ISO 27006-1, requirements for ISMS auditing and certification services
|
||||
- ISO 27007, guidance on managing an ISMS audit program (against the requirements of ISO 27001)
|
||||
|
||||
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.
|
||||
|
||||
## Types of audits
|
||||
|
||||
The first party audit is when the organization audits its own processes, either by an internal audit team or by outsourcing it to a trusted external entity.
|
||||
|
||||
A second party audit is where the organization is being audited by a customer (in which case the organization is the auditee), or where the organization audits its vendors (also known as vendor due diligence).
|
||||
|
||||
A third-party audit is when an organization is audited by a completely independent organization, without any a priori knowledge of the organization or previous audits (certifying bodies perform these kind of audits).
|
||||
|
||||
In a combined audit more than one framework or more than one standard are audited at the same time.
|
||||
|
||||
In the United States, for example, it's very common to do 27001 and SOC 2 together. For combined audits it's especially important to check for competency of the auditor.
|
||||
|
||||
## Involved parties
|
||||
|
||||
According to ISO 19011, clauses 3.12 - 3.15, and ISO 17021-1, clauses 3.8, 3.9, and 3.16.
|
||||
|
||||
**Audit client**, or auditee: the organization or person requesting an audit.
|
||||
|
||||
**Auditee**: the organization as a whole, or parts thereof, being audited.
|
||||
|
||||
**Auditor**: the person who conducts an audit.
|
||||
|
||||
**Audit team**: one or more persons conducting an audit, if needed supported by technical experts.
|
||||
(as an auditor, you're not required to know every single thing for every possible concept of every single framework that's out there).
|
||||
|
||||
**Observer**: a person who accompanies the audit team but does not audit.
|
||||
|
||||
**Guide**: a person appointed by the client to assist the audit team. Often a person that has direct access to people or areas of the auditee environment, that allows for faster access to get things done.
|
||||
|
||||
## Vocabulary
|
||||
|
||||
**Shall**: required
|
||||
**Should**: highly suggested
|
||||
**May**: facultative, voluntary
|
||||
**Can**: a possibility or capability.
|
||||
|
||||
Even though an element is required ('shall'), it may not always be applicable, like physical security for a company without physical offices locations.
|
||||
|
||||
So again, from the standpoint of shall, should, may, can, it is very important that you understand 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. In those circumstances, there needs to an explanation of why it's not applicable.
|
||||
|
||||
**Applicable**: Relevant; appropriate; possible to apply
|
||||
|
||||
**Appropriate**: Suitable (for, to)
|
||||
|
||||
**Authority**: power to command or give a decision.
|
||||
|
||||
**Competence**: Ability to apply knowledge and skills to achieve the intended results
|
||||
|
||||
**Conformity**: fulfillment of a requirement, meeting the requirements and its guidelines
|
||||
|
||||
**Continual improvement**: the recurring activity to enhance performance
|
||||
|
||||
**Corrective action**: action to remediate or mitigate a possible non-conformity and to prevent recurrence
|
||||
|
||||
**Documented information**: Information required to be controlled and maintained by an organization and the medium on which it is contained
|
||||
|
||||
**Determine**: Appraise or analyze quantitatively; find out
|
||||
|
||||
**Identify:** Find out; mark or label; show; to reference something without ambiguity
|
||||
|
||||
**Interested parties**: Person or organization that can affect, be affected by, or perceive itself to be affected by a decision or activity
|
||||
|
||||
**Maintain**: Enable to continue
|
||||
|
||||
**Nonconformity**: Nonfulfillment of a requirement
|
||||
|
||||
**Organization**: Company, corporation, firm, enterprise, authority or institution, person or persons or part or combination thereof, whether incorporated or not, public or private, that has its own functions and administration – in most cases the auditee
|
||||
|
||||
**Retain**: Keep
|
||||
|
||||
**Top management**: Person or group of people who directs and controls an organization at the highest level
|
||||
|
|
@ -0,0 +1,39 @@
|
|||
# Audit principles
|
||||
|
||||
Audit principles are defined in ISO 19011, Clause 4. Adherence to these principles is important to provide audit conclusions that are relevant and sufficient, and to enable different auditors to reach similar conclusions in similar circumstances.
|
||||
|
||||
These principles are: integrity, fair presentation, due professional care, confidentiality, independence, evidence-based approach, and risk-based approach.
|
||||
|
||||
|
||||
**Integrity** is the core principle of professional behaviour.
|
||||
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, 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
|
||||
- report truthfully and accurately.
|
||||
|
||||
This last obligation means your report should explicate how you performed the audit, who you interfaced with, and at what date and time, the evidence provided to you, etc.
|
||||
|
||||
You should also report on significant obstacles encountered during the audit, and unresolved diverging opinions between the audit team and the auditee.
|
||||
|
||||
The communication should be truthful, accurate, objective, timely, clear, and complete. No ambiguity.
|
||||
|
||||
## Due professional care
|
||||
Due professional care is addressed in ISO 19011 clause 4c.
|
||||
|
||||
Because of the importance of their task and the confidence placed in them by the audit client and other interested parties, the auditor should take care that this trust isn't violated.
|
||||
|
||||
This means that 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, should be considered beforehand.
|
||||
|
||||
The auditor must exercise **professional judgment** by applying relevant training, knowledge, and experience to make informed decisions in various situations during an audit, while maintaining their independence and objectivity and adopt an attitude of skepticism to reach the audit objectives.
|
||||
|
||||
**Professional skepticism** is 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. You should not ever take the word of the auditee as fact – you must look for evidence to support their claims of whatever they're trying to tell you. Always ask for proof. Be on the lookout for evidence that could contradict or question the reliability and validity of the documented information received.
|
||||
|
||||
If an auditor encounters exceptional circumstances, such as **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. For example, if during an audit you encounter evidence or suspect issues that could involve national security or child pornography, that's an illegal act that requires reporting to law enforcement. So you need to understand the laws of the countries you're going to be auditing in, and from the country you reside in when auditing remotely.
|
||||
|
||||
**Confidentiality**. Auditors should exercise discretion in the use and protection of information acquired in the course of their duties. This information should not be used inappropriately or for personal gain by the auditor or the audit client or in a manner detrimental to the legitimate interests of the auditee.
|
||||
As an auditor, in most cases you will be required to sign a non-disclosure of some sort, by the audit client or the auditee, and by the certifying body you're working under (as per ISO 17021-1, clauses 8.4.1).
|
||||
|
||||
Confidentiality requirements are further explicated in ISO 17021-1, clauses 8.4.3, 8.4.6 and 8.4.7.
|
||||
Information about a particular certified client or individual shall not be disclosed to a third party without written consent, except as required by law. The certification body shall have processes, equipment and facilities that ensure the secure handling of confidential information, and the auditors must be aware of these.
|
||||
|
|
@ -0,0 +1,475 @@
|
|||
# Threats to independence
|
||||
|
||||
The auditor must have independence in relation to the auditee, the persons responsible for its information security management, and the users.
|
||||
The independent auditors are not going to report directly to management, the independent auditor is not the auditee or one of the users.
|
||||
|
||||
ISO 17021-1 clauses 4.2.4 and 5.2.11 mention several threats to impartiality: self-interest, self-review, familiarity or trust, and intimidation. If any of these are present, the certification body must take action.
|
||||
|
||||
**Self-interest** is the case in which a person or body acts in its own interest. This may happen, for instance, if the auditor owns stock in the company their auditing.
|
||||
|
||||
**Self-review** simply means that you can't audit yourself.
|
||||
|
||||
**Intimidation** is obvious.
|
||||
|
||||
**Familiarity or trust** comes into place when the auditor is almost part of the team that's being audited.
|
||||
|
||||
As an auditor you can't accept **gifts**, because they may be considered a bribe.
|
||||
|
||||
Auditors may not provide **consulting services** for the auditee, meaning they cannot contribute to the design, implementation, or the maintenance of a management system for the auditee, for two years prior to certification of the auditee.
|
||||
|
||||
---
|
||||
|
||||
|
||||
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 specific solutions.
|
||||
|
||||
|
||||
|
||||
So 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 auditee is suggested to go talk to a third party to maybe help them 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 uh the auditor which is generally going to be a contracted individual or possibly a contracted company and then you're you're going to 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 I'm helping a company, XYZ company, get ready for an audit and then maybe their audit company that's going to come in and do the certification on this XYZ company, they say, hey Carl, we really want you to show up and be an auditor for us because 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, it's actually a longer than two years.
|
||||
|
||||
|
||||
|
||||
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, that there's no connection anymore.
|
||||
|
||||
|
||||
|
||||
So the implication of this clause, 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 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 could look like a conflict of interest 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 tarnished.
|
||||
|
||||
|
||||
|
||||
And it very rapidly will go around the audit world that your integrity is not to be trusted.
|
||||
|
||||
|
||||
|
||||
5.2.13, certification bodies 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 have more information or you have a past with this company or something like that, you have to disclose it before you actually do anything.
|
||||
|
||||
|
||||
|
||||
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. 19,011 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, if we ask a company, 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, show us the database settings that show us what level 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 an interviewee or auditee tell you because they, in some cases, in most cases they're wrong or in some cases they'll just tell you what they're expecting you to hear.
|
||||
|
||||
|
||||
|
||||
Negligence of auditors.
|
||||
|
||||
|
||||
|
||||
There's different four levels of responsibility in case of torturous acts.
|
||||
|
||||
|
||||
|
||||
Now, you may go, what does torturous acts mean?
|
||||
|
||||
|
||||
|
||||
Torturous 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 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 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 in one area, more like 98 or 95 or 80% success in that particular area that 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 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 the auditor themselves, including administrative actions like termination or just basically being banned from working with that certifying body.
|
||||
|
||||
|
||||
|
||||
Now, in cases of ordinary negligence, if there were cases of ordinary negligence, that could be just additional training or it could be just maybe somebody's observing the 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 reports that is being sent to the certifying body in order to deceive the 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 you're accused of fraud and actually found to have been fraudulent as an auditor, you might as well just plan on not being an auditor anymore 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 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 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.
|
||||
|
||||
|
||||
|
||||
Same thing with information security.
|
||||
|
||||
|
||||
|
||||
If you're going to hire an auditor to perform information security, you may want to 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 criminal action that could have happened, but also from the standpoint of what's their knowledge.
|
||||
|
||||
|
||||
|
||||
If they say that they are a former network engineer, then they should be able to prove that and a background check should possibly, depending on how you're doing it, 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 an adequate background check for your contractors, your auditors, whether the contractors are employees to make sure they're living up to the name that they say they are.
|
||||
|
||||
|
||||
|
||||
We can also have the sign, the auditors sign a code of ethics on company policy, company actions, code of conduct, things like that on ethics or surrounding auditing.
|
||||
|
||||
|
||||
|
||||
Possibly you could make the auditors that you're 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 being an auditor or awareness around things 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 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 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.
|
||||
|
|
@ -0,0 +1,34 @@
|
|||
---
|
||||
tags:
|
||||
- iso27002/2022
|
||||
- audit
|
||||
- type/MoC
|
||||
---
|
||||
https://mypecb.com/content/e-learnings/571
|
||||
# Overview of PECB LA course
|
||||
|
||||
| Section | Title |
|
||||
| ---------- | ---------------------------------------------------------------------------------------------------------------------------- |
|
||||
| Section 1 | [Training course objectives and structure](PECB%2027001%20LA%20S01%20-%20Course%20objectives%20and%20structure.md) (1 video) |
|
||||
| Section 2 | [[PECB 27001 LA S02\|Introduction to management systems and ISO/IEC 27000 family of standards]] (3 videos) |
|
||||
| Section 3 | [[PECB 27001 LA S03\|Certification process]] (1 video) |
|
||||
| Section 4 | [[PECB 27001 LA S04\|Fundamental concepts and principles of information security]] (3 videos) |
|
||||
| Section 5 | [Overview of ISO/IEC 27001 requirements](PECB%2027001%20LA%20S05%20-%20MoC%20Overview%20of%20requirements.md) (5 videos) |
|
||||
| Section 6 | [Fundamental audit concepts and principles](PECB%2027001%20LA%20S06%20-%20MoC%20Audit%20fundamentals.md) (6 videos) |
|
||||
| Section 7 | [[PECB 27001 LA S07\|The impact of trends and technology in auditing]] (2 videos) |
|
||||
| Section 8 | [Evidence-based auditing](PECB%2027001%20LA%20S08.md) (2 videos) |
|
||||
| Section 9 | [[PECB 27001 LA S09\|Risk-based audit]] (1 video) |
|
||||
| Section 10 | [Initiation of the audit process](PECB%2027001%20LA%20S10.md) (3 videos) |
|
||||
| Section 11 | [[PECB 27001 LA S11\|Stage 1 audit]] (2 videos) |
|
||||
| Section 12 | [[PECB 27001 LA S12\|Preparing for stage 2 audit]] (2 videos) |
|
||||
| Section 13 | [[PECB 27001 LA S13\|Stage 2 audit]] (2 videos) |
|
||||
| Section 14 | [[PECB 27001 LA S14\|Communication during the audit]] (2 videos) |
|
||||
| Section 15 | [[PECB 27001 LA S15\|Audit procedures]] (5 videos) |
|
||||
| Section 16 | [[PECB 27001 LA S16\|Creating audit test plans]] (2 videos) |
|
||||
| Section 17 | [[PECB 27001 LA S17\|Drafting audit findings and nonconformity reports]] (2 videos) |
|
||||
| Section 18 | [[PECB 27001 LA S18\|Audit documentation and quality review]] (1 video) |
|
||||
| Section 19 | [[PECB 27001 LA S19\|Closing of the audit]] (2 videos) |
|
||||
| Section 20 | [[PECB 27001 LA S20\|Evaluation of action plans by the auditor]] (1 video) |
|
||||
| Section 21 | [[PECB 27001 LA S21\|Beyond the initial audit]] (2 videos) |
|
||||
| Section 22 | [[PECB 27001 LA S22\|Managing an internal audit program]] (2 videos) |
|
||||
| Section 23 | [[PECB 27001 LA S23\|Closing of the training course]] (2 videos) |
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 156 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 135 KiB |
Loading…
Add table
Add a link
Reference in a new issue