diff --git a/.kilo/plans/1777714595174-misty-tiger.md b/.kilo/plans/1777714595174-misty-tiger.md new file mode 100644 index 0000000..fb0ae8d --- /dev/null +++ b/.kilo/plans/1777714595174-misty-tiger.md @@ -0,0 +1,55 @@ +# Plan to Remove Markdown Tables After First Header in Specified .md Files + +## Goal +Remove the markdown table that appears after the first markdown header (## X.Y Title) in 35 specific .md files located in the directory `/Users/rico/src/iso27diy-corp/Corpus/Standards/ISO27x/OST/27002/EN`. These files contain ISO 27002 control descriptions and have a summary table listing Control type, Information security properties, etc., which needs to be removed. + +## Analysis +- **Affected Files**: Identified 35 .md files containing the table starting with `| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains |`. +- **Table Structure**: The table consists of 2-4 lines: + - Header row starting with `| Control type` + - Separator row + - Data row + - Optionally, an empty row +- **Location**: The table appears immediately after the first `##` header (e.g., `## 8.1 User endpoint devices`) and before the `**Control**` section. +- **Pattern**: All affected files follow the pattern where the table ends just before `**Control**`. + +## Approach +Use a Bash script with `sed` to remove the table lines from each affected file. The `sed` command will delete lines from the start of the table (`| Control type`) up to but not including `**Control**`. + +### Script +Create and run the following Bash script in the target directory: + +```bash +#!/bin/bash + +# Change to the target directory +cd /Users/rico/src/iso27diy-corp/Corpus/Standards/ISO27x/OST/27002/EN || exit 1 + +# Loop through all .md files +for file in *.md; do + # Check if the file contains the table + if grep -q "| Control type" "$file"; then + # Remove the table lines: from "| Control type" to just before "**Control**" + sed -i '/^| Control type /,/^\*\*Control$/ { /^\*\*Control$/ !d }' "$file" + echo "Processed $file" + fi +done + +echo "Table removal complete." +``` + +### Steps to Execute +1. **Navigate to Directory**: Change to `/Users/rico/src/iso27diy-corp/Corpus/Standards/ISO27x/OST/27002/EN`. +2. **Backup (Optional)**: Consider backing up the directory before running the script. +3. **Run Script**: Execute the script to process all files. +4. **Verify**: After running, check a few files (e.g., `a-8.1-User-endpoint-devices.md`, `a-5.15-Access-control.md`) to ensure the table is removed and the `**Control**` section remains intact. + +## Risks and Considerations +- **Accuracy**: The `sed` command is designed to precisely target the table based on the observed patterns. If any file has unexpected formatting, manual review may be needed. +- **No Impact on Non-Affected Files**: Files without the table will remain unchanged. +- **Reversibility**: If needed, restore from backup or use version control (assuming the directory is in a git repo). + +## Expected Outcome +- Tables removed from 35 files. +- Content before and after the table (including `**Control**` and subsequent sections) preserved. +- No changes to other .md files in the directory. \ No newline at end of file diff --git a/Corpus/Information security concepts MoC.md b/Corpus/Information security concepts MoC.md new file mode 100644 index 0000000..578f8cd --- /dev/null +++ b/Corpus/Information security concepts MoC.md @@ -0,0 +1,75 @@ +--- +Related: + - "[ISO\\_27002\\_OT 3 Terms, definitions and abbreviated terms](Standards/ISO27x/OST/27002/EN/a-3-Terms-definitions-and-abbreviated%20terms.md)" + - https://csiac.org/databases/acronyms/ +tags: + - type/MoC +--- +[Assets](🎇%20Sparks/Assets.md) + [NIST Asset Types](📚️%20Literature%20notes/NIST%20Asset%20Types.md) + [Asset lifecycle](📚️%20Literature%20notes/Asset%20lifecycle.md) + [Asset ownership](🎇%20Sparks/Asset%20ownership.md) + [[Asset ownership DEL]] + [Assets, Vulnerabilities, Threats, Risks](📚️%20Literature%20notes/Assets,%20Vulnerabilities,%20Threats,%20Risks.md) +[Assets, Vulnerabilities, Threats, Risks](🎇%20Sparks/Assets,%20Vulnerabilities,%20Threats,%20Risks.md) +[Attack Surface Analysis](📚️%20Literature%20notes/Attack%20Surface%20Analysis.md) +[Authentication](Standards/ISO27x/Authentication.md) + [Multi-factor authentication](🎇%20Sparks/Multi-factor%20authentication.md) (MFA) + [Passwordless Authentication](🎇%20Sparks/Passwordless%20Authentication.md) + [Risk-Based Authentication](🎇%20Sparks/Risk-Based%20Authentication.md) + [Single Sign On (SSO)](📚️%20Literature%20notes/Single%20Sign%20On%20(SSO).md) + [Tokens](🎇%20Sparks/Tokens.md) +[Authorization](Standards/ISO27x/Authorization.md) + [Access Control](🎇%20Sparks/Access%20Control.md) +[Awareness](🎇%20Sparks/Awareness.md) +[BCP_Bedrijfscontinuïteitsplanning](📚️%20Literature%20notes/BCP_Bedrijfscontinuïteitsplanning.md) + [Business Impact Analysis (BIA)](🎇%20Sparks/Business%20Impact%20Analysis%20(BIA).md) + [Disaster Recovery Planning](🎇%20Sparks/Disaster%20Recovery%20Planning.md) +[Change management MoC](MoCs/Change%20management%20MoC.md) +[Classification](🎇%20Sparks/Classification.md) +[Compliance](🎇%20Sparks/Compliance.md) +[Data Breach](💡Permanent%20ideas/Data%20Breach.md) +[Data Governance](📚️%20Literature%20notes/Data%20Governance.md) +Frameworks + [ISO 27k family](../../iso27DIY-gis/reference/Examples/ISO%2027k%20family.md) + [NIST articles list](Standards/NIST/NIST%20articles%20list.md) +[Governance](🎇%20Sparks/Governance.md) +[[Hardening]] +[Identity and Access Management (IAM)](💡Drafts%20and%20Ideas/Identity%20and%20Access%20Management%20(IAM).md) + [Identification](💡Drafts%20and%20Ideas/Identification.md) + [Authentication](Standards/ISO27x/Authentication.md) + [Authorization](Standards/ISO27x/Authorization.md) +Impact + [Change management MoC](MoCs/Change%20management%20MoC.md) + [Impact of Disruption](💡Drafts%20and%20Ideas/Impact%20of%20Disruption.md) +[Incidents](🎇%20Sparks/Incidents.md) +[Maturity Models](📚️%20Literature%20notes/Maturity%20Models.md) +[Metrics](📚️%20Literature%20notes/InfoSec%20Metrics.md) +[Operational Technology](💡Drafts%20and%20Ideas/Operational%20Technology.md) or OT Security +[Policies](📚️%20Literature%20notes/Policies.md) +[[Posture Management]] +[Ransomware](🎇%20Sparks/Ransomware.md) +[Risks](🎇%20Sparks/Risks.md) + [Risk analysis](🎇%20Sparks/Risk%20analysis.md) + [Risk appetite](💡Drafts%20and%20Ideas/Risk%20appetite.md) + [Risk inventories](🎇%20Sparks/Risk%20inventories.md) + [Risk management](🎇%20Sparks/Risk%20management.md) + [Risk ownership](🎇%20Sparks/Risk%20ownership.md) + [Risk ownership](🎇%20Sparks/Risk%20ownership.md) + [Risk prioritization](🎇%20Sparks/Risk%20prioritization.md) + [Risk tolerance](🎇%20Sparks/Risk%20tolerance.md) + [Risk treatment](🎇%20Sparks/Risk%20treatment.md) + [Risks vs Threats vs Vulnerabilities](🎇%20Sparks/Risks%20vs%20Threats%20vs%20Vulnerabilities.md) +[Roles and Responsibilities](🎇%20Sparks/Roles%20and%20Responsibilities.md) +[Threat](📚️%20Literature%20notes/Threat.md) + [Threat Intelligence](🎇%20Sparks/Threat%20Intelligence.md) + [Security Threat Modeling](📚️%20Literature%20notes/Security%20Threat%20Modeling.md) + [Privacy Threat Modeling](📚️%20Literature%20notes/Privacy%20Threat%20Modeling.md) + [AI Threat Modeling](🎇%20Sparks/AI%20Threat%20Modeling.md) + [Threat Catalogues](📚️%20Literature%20notes/Threat%20Catalogues.md) +[Vendor security MoC](🎇%20Sparks/Vendor%20security%20MoC.md) or Supply chain security +[Vulnerability](💡Drafts%20and%20Ideas/Vulnerability.md) + [Bug bounty program](🎇%20Sparks/Bug%20bounty%20program.md) +[Zero Trust](📚️%20Literature%20notes/Zero%20Trust.md) + + diff --git a/Corpus/MoCs/iso27DIY-MoC.md b/Corpus/MoCs/iso27DIY-MoC.md index a0ac301..c0a1910 100644 --- a/Corpus/MoCs/iso27DIY-MoC.md +++ b/Corpus/MoCs/iso27DIY-MoC.md @@ -22,7 +22,7 @@ tags: ## Method [Samenhang tussen producten](../🎇%20Sparks/Samenhang%20tussen%20producten.md) -[ISO 27001 2023 Processen en Artefacten](../Standards/ISO27x/OST/27001/NL/ISO%2027001%202023%20Processen%20en%20Artefacten.md) +[ISO 27001 2023 Processen en Artefacten](../Standards/ISO27x/OST/ISO%2027001%202023%20Processen%20en%20Artefacten.md) [Advised Documents for ISO 27001](../iso27DIY-gis/reference/Advised%20Documents%20for%20ISO%2027001.md) [Examples of Proof for auditors](../🎇%20Sparks/Examples%20of%20Proof%20for%20auditors.md) [About ISO27DIY Policy Cards](../💡Permanent%20ideas/About%20ISO27DIY%20Policy%20Cards.md) diff --git a/Corpus/Standards/ISO27x/ISO 27001_2022_EN.docx b/Corpus/Standards/ISO27x/ISO 27001_2022_EN.docx new file mode 100644 index 0000000..aaf8e9e Binary files /dev/null and b/Corpus/Standards/ISO27x/ISO 27001_2022_EN.docx differ diff --git a/Corpus/Standards/ISO27x/ISO 27002_2022_EN_complete.md b/Corpus/Standards/ISO27x/ISO 27002_2022_EN_complete.md new file mode 100644 index 0000000..3d7fc26 --- /dev/null +++ b/Corpus/Standards/ISO27x/ISO 27002_2022_EN_complete.md @@ -0,0 +1,12725 @@ + +# 0. Introduction + +## 0.1 Background and context + +This document is designed for organizations of all types and sizes. It is to be used as a reference for determining and implementing controls for information security risk treatment in an information security management system (ISMS) based on ISO/IEC 27001. It can also be used as a guidance document for organizations determining and implementing commonly accepted information security controls. Furthermore, this document is intended for use in developing industry and organization- specific information security management guidelines, taking into consideration their specific information security risk environment(s). Organizational or environment-specific controls other than those included in this document can be determined through risk assessment as necessary. + +Organizations of all types and sizes (including public and private sector, commercial and non-profit) create, collect, process, store, transmit and dispose of information in many forms, including electronic, physical and verbal (e.g. conversations and presentations). + +The value of information goes beyond written words, numbers and images: knowledge, concepts, ideas and brands are examples of intangible forms of information. In an interconnected world, information and other associated assets deserve or require protection against various risk sources, whether natural, accidental or deliberate. + +Information security is achieved by implementing a suitable set of controls, including policies, rules, processes, procedures, organizational structures and software and hardware functions. To meet its specific security and business objectives, the organization should define, implement, monitor, review and improve these controls where necessary. An ISMS such as that specified in ISO/IEC 27001 takes a holistic, coordinated view of the organization’s information security risks in order to determine and implement a comprehensive suite of information security controls within the overall framework of a coherent management system. + +Many information systems, including their management and operations, have not been designed to be secure in terms of an ISMS as specified in ISO/IEC 27001 and this document. The level of security that can be achieved only through technological measures is limited and should be supported by appropriate management activities and organizational processes. Identifying which controls should be in place requires careful planning and attention to detail while carrying out risk treatment. + +A successful ISMS requires support from all personnel in the organization. It can also require participation from other interested parties, such as shareholders or suppliers. Advice from subject matter experts can also be needed. + +A suitable, adequate and effective information security management system provides assurance to the organization’s management and other interested parties that their information and other associated assets are kept reasonably secure and protected against threats and harm, thereby enabling the organization to achieve the stated business objectives. + +## 0.2 Information security requirements + +It is essential that an organization determines its information security requirements. There are three main sources of information security requirements: + +a\) the assessment of risks to the organization, taking into account the organization’s overall business strategy and objectives. This can be facilitated or supported through an information security- specific risk assessment. This should result in the determination of the controls necessary to ensure that the residual risk to the organization meets its risk acceptance criteria; + +b\) the legal, statutory, regulatory and contractual requirements that an organization and its interested parties (trading partners, service providers, etc.) have to comply with and their socio- cultural environment; + +c\) the set of principles, objectives and business requirements for all the steps of the life cycle of information that an organization has developed to support its operations. + +## 0.3 Controls + +A control is defined as a measure that modifies or maintains risk. Some of the controls in this document are controls that modify risk, while others maintain risk. An information security policy, for example, can only maintain risk, whereas compliance with the information security policy can modify risk. Moreover, some controls describe the same generic measure in different risk contexts. This document provides a generic mixture of organizational, people, physical and technological information security controls derived from internationally recognized best practices. + +## 0.4 Determining controls + +Determining controls is dependent on the organization’s decisions following a risk assessment, with a clearly defined scope. Decisions related to identified risks should be based on the criteria for risk acceptance, risk treatment options and the risk management approach applied by the organization. The determination of controls should also take into consideration all relevant national and international legislation and regulations. Control determination also depends on the manner in which controls interact with one another to provide defence in depth. + +The organization can design controls as required or identify them from any source. In specifying such controls, the organization should consider the resources and investment needed to implement and operate a control against the business value realized. See ISO/IEC TR 27016 for guidance on decisions regarding the investment in an ISMS and the economic consequences of these decisions in the context of competing requirements for resources. + +There should be a balance between the resources deployed for implementing controls and the potential resulting business impact from security incidents in the absence of those controls. The results of a risk assessment should help guide and determine the appropriate management action, priorities for managing information security risks and for implementing controls determined necessary to protect against these risks. + +Some of the controls in this document can be considered as guiding principles for information security management and as being applicable for most organizations. More information about determining controls and other risk treatment options can be found in ISO/IEC 27005. + +## 0.5 Developing organization-specific guidelines + +This document can be regarded as a starting point for developing organization-specific guidelines. Not all of the controls and guidance in this document can be applicable to all organizations. Additional controls and guidelines not included in this document can also be required to address the specific needs of the organization and the risks that have been identified. When documents are developed containing additional guidelines or controls, it can be useful to include cross-references to clauses in this document for future reference. + +## 0.6 Life cycle considerations + +Information has a life cycle, from creation to disposal. The value of, and risks to, information can vary throughout this life cycle (e.g. unauthorized disclosure or theft of a company’s financial accounts is not significant after they have been published, but integrity remains critical) therefore, information security remains important to some extent at all stages. + +Information systems and other assets relevant to information security have life cycles within which they are conceived, specified, designed, developed, tested, implemented, used, maintained and eventually retired from service and disposed of. Information security should be considered at every stage. New system development projects and changes to existing systems provide opportunities to improve security controls while taking into account the organization’s risks and lessons learned from incidents. + +## 0.7 Related International Standards + +While this document offers guidance on a broad range of information security controls that are commonly applied in many different organizations, other documents in the ISO/IEC 27000 family provide complementary advice or requirements on other aspects of the overall process of managing information security. + +Refer to ISO/IEC 27000 for a general introduction to both ISMS and the family of documents. ISO/IEC 27000 provides a glossary, defining most of the terms used throughout the ISO/IEC 27000 family of documents, and describes the scope and objectives for each member of the family. + +There are sector-specific standards that have additional controls which aim at addressing specific areas (e.g. ISO/IEC 27017 for cloud services, ISO/IEC 27701 for privacy, ISO/IEC 27019 for energy, ISO/IEC 27011 for telecommunications organizations and ISO 27799 for health). Such standards are included in the Bibliography and some of them are referenced in the guidance and other information sections in Clauses 5-8. + +# 1 Scope + +This document provides a reference set of generic information security controls including implementation guidance. This document is designed to be used by organizations: + +a\) within the context of an information security management system (ISMS) based on ISO/IEC 27001; + +b\) for implementing information security controls based on internationally recognized best practices; + +c\) for developing organization-specific information security management guidelines. + +# 2 Normative references + +There are no normative references in this document. + +# 3 Terms, definitions and abbreviated terms + +## 3.1 Terms and definitions + +For the purposes of this document, the following terms and definitions apply. + +ISO and IEC maintain terminology databases for use in standardization at the following addresses: — ISO Online browsing platform: available at https://www.iso.org/obp + +— IEC Electropedia: available at https://www.electropedia.org/ + +### 3.1.1 + +**access control** + +means to ensure that physical and logical access to *assets* (3.1.2) is authorized and restricted based on business and information security requirements + +### 3.1.2 + +**asset** + +anything that has value to the organization + +Note 1 to entry: In the context of information security, two kinds of assets can be distinguished: + +— the primary assets: — information; + +— business *processes* (3.1.27) and activities; + +— the supporting assets (on which the primary assets rely) of all types, for example: — hardware; + +— software; — network; + +— *personnel* (3.1.20); + +— site; + + + + + +— organization’s structure. + +### 3.1.3 attack + +successful or unsuccessful unauthorized attempt to destroy, alter, disable, gain access to an *asset* (3.1.2) or any attempt to expose, steal, or make unauthorized use of an *asset* (3.1.2) + +### 3.1.4 authentication +provision of assurance that a claimed characteristic of an *entity* (3.1.11) is correct + +### 3.1.5 authenticity +property that an *entity* (3.1.11) is what it claims to be + +### 3.1.6 chain of custody +demonstrable possession, movement, handling and location of material from one point in time until another + +Note 1 to entry: Material includes information and other associated *assets* (3.1.2) in the context of ISO/IEC 27002. + +\[SOURCE: ISO/IEC 27050-1:2019, 3.1, modified — “Note 1 to entry” added\] + +### 3.1.7 confidential information +information that is not intended to be made available or disclosed to unauthorized individuals, *entities* (3.1.11) or *processes* (3.1.27) + +### 3.1.8 control +measure that maintains and/or modifies risk + +Note 1 to entry: Controls include, but are not limited to, any *process* (3.1.27), *policy* (3.1.24), device, practice or other conditions and/or actions which maintain and/or modify risk. + +Note 2 to entry: Controls may not always exert the intended or assumed modifying effect. + +\[SOURCE: ISO 31000:2018, 3.8\] + +### 3.1.9 disruption +incident, whether anticipated or unanticipated, that causes an unplanned, negative deviation from the expected delivery of products and services according to an organization’s objectives + +\[SOURCE: ISO 22301:2019, 3.10\] + +### 3.1.10 endpoint device +network connected information and communication technology (ICT) hardware device + +Note 1 to entry: Endpoint device can refer to desktop computers, laptops, smart phones, tablets, thin clients, printers or other specialized hardware including smart meters and Internet of things (IoT) devices. + +### 3.1.11 entity +item relevant for the purpose of operation of a domain that has recognizably distinct existence + +Note 1 to entry: An entity can have a physical or a logical embodiment. +EXAMPLE A person, an organization, a device, a group of such items, a human subscriber to a telecom service, a SIM card, a passport, a network interface card, a software application, a service or a website. + +\[SOURCE: ISO/IEC 24760-1:2019, 3.1.1\] + +### 3.1.12 information processing facility +any information processing system, service or infrastructure, or the physical location housing it \[SOURCE: ISO/IEC 27000:2018, 3.27, modified — "facilities" has been replaced with facility.\] ### 3.1.13 information security breach +compromise of information security that leads to the undesired destruction, loss, alteration, disclosure of, or access to, protected information transmitted, stored or otherwise processed + +### 3.1.14 information security event +occurrence indicating a possible *information security breach* (3.1.13) or failure of *controls* (3.1.8) + +\[SOURCE: ISO/IEC 27035-1:2016, 3.3, modified — “breach of information security” has been replaced with “information security breach”\] + +### 3.1.15 information security incident +one or multiple related and identified *information security events* (3.1.14) that can harm an organization’s *assets* (3.1.2) or compromise its operations + +\[SOURCE: ISO/IEC 27035-1:2016, 3.4\] + +### 3.1.16 information security incident management +exercise of a consistent and effective approach to the handling of *information security incidents* (3.1.15) \[SOURCE: ISO/IEC 27035-1:2016, 3.5\] + +### 3.1.17 information system +set of applications, services, information technology *assets* (3.1.2), or other information-handling components + +\[SOURCE: ISO/IEC 27000:2018, 3.35\] + +### 3.1.18 interested partystakeholder + +person or organization that can affect, be affected by, or perceive itself to be affected by a decision or activity + +\[SOURCE: ISO/IEC 27000:2018, 3.37\] + +### 3.1.19 non-repudiation +ability to prove the occurrence of a claimed event or action and its originating *entities* (3.1.11) + +### 3.1.20 personnel +persons doing work under the organization’s direction + +Note 1 to entry: The concept of personnel includes the organization’s members, such as the governing body, top management, employees, temporary staff, contractors and volunteers. + +### 3.1.21 personally identifiable information +**PII** + +any information that (a) can be used to establish a link between the information and the natural person to whom such informa tion relates, or (b) is or can be directly or indirectly linked to a natural person. + +Note 1 to entry: The “natural person” in the definition is the *PII principal* (3.1.22). To determine whether a PII principal is identifiable, account should be taken of all the means which can reasonably be used by the privacy stakeholder holding the data, or by any other party, to establish the link between the set of PII and the natural person. + +\[SOURCE: ISO/IEC 29100:2011/Amd.1:2018, 2.9\] + +### 3.1.22 PII principal +natural person to whom the *personally identifiable information (PII)* (3.1.21) relates + +Note 1 to entry: Depending on the jurisdiction and the particular data protection and privacy legislation, the synonym “data subject” can also be used instead of the term “PII principal”. + +\[SOURCE: ISO/IEC 29100:2011, 2.11\] + +### 3.1.23 PII processor +privacy stakeholder that processes *personally identifiable information (PII)* (3.1.21) on behalf of and in accordance with the instructions of a PII controller + +\[SOURCE: ISO/IEC 29100:2011, 2.12\] + +### 3.1.24 policy +intentions and direction of an organization, as formally expressed by its top management \[SOURCE: ISO/IEC 27000:2018, 3.53\] + +### 3.1.25 privacy impact assessment PIA +overall *process* (3.1.27) of identifying, analysing, evaluating, consulting, communicating and planning the treatment of potential privacy impacts with regard to the processing of *personally identifiable information (PII)* (3.1.21), framed within an organization’s broader risk management framework + +\[SOURCE: ISO/IEC 29134:2017, 3.7, modified — Note 1 to entry removed.\] + +### 3.1.26 procedure +specified way to carry out an activity or a *process* (3.1.27) + +\[SOURCE: ISO 30000:2009, 3.12\] + +### 3.1.27 process +set of interrelated or interacting activities that uses or transforms inputs to deliver a result + +\[SOURCE: ISO 9000:2015, 3.4.1, modified— Notes to entry removed.\] + +### 3.1.28 record +information created, received and maintained as evidence and as an *asset* (3.1.2) by an organization or person, in pursuit of legal obligations or in the transaction of business + +Note 1 to entry: Legal obligations in this context include all legal, statutory, regulatory and contractual requirements. + +\[SOURCE: ISO 15489-1:2016, 3.14, modified— “Note 1 to entry” added.\] + +### 3.1.29 recovery point objective +**RPO** + +point in time to which data are to be recovered after a *disruption* (3.1.9) has occurred \[SOURCE: ISO/IEC 27031:2011, 3.12, modified — "must" replaced by "are to be".\] ### 3.1.30 recovery time objective RTO +period of time within which minimum levels of services and/or products and the supporting systems, applications, or functions are to be recovered after a *disruption* (3.1.9) has occurred + +\[SOURCE: ISO/IEC 27031:2011, 3.13, modified — "must" replaced by "are to be".\] + +### 3.1.31 reliability +property of consistent intended behaviour and results + +### 3.1.32 rule +accepted principle or instruction that states the organization’s expectations on what is required to be done, what is allowed or not allowed + +Note 1 to entry: Rules can be formally expressed in *topic-specific policies* (3.1.35) and in other types of documents. + +### 3.1.33 sensitive information +information that needs to be protected from unavailability, unauthorized access, modification or public disclosure because of potential adverse effects on an individual, organization, national security or public safety + +### 3.1.34 threat +potential cause of an unwanted incident, which can result in harm to a system or organization \[SOURCE: ISO/IEC 27000:2018, 3.74\] + +### 3.1.35 topic-specific policy +intentions and direction on a specific subject or topic, as formally expressed by the appropriate level of management + +Note 1 to entry: Topic-specific policies can formally express *rules* (3.1.32) or organization standards. Note 2 to entry: Some organizations use other terms for these topic-specific policies. + +Note 3 to entry: The topic-specific policies referred to in this document are related to information security. + +EXAMPLE Topic-specific policy on *access control* (3.1.1), topic-specific policy on clear desk and clear screen. + +### 3.1.36 user +*interested party* (3.1.18) with access to the organization’s *information systems* (3.1.17) + +EXAMPLE *Personnel* (3.1.20), customers, suppliers. + + +### 3.1.37 user endpoint device +*endpoint device* (3.1.10) used by users to access information processing services + +Note 1 to entry: User endpoint device can refer to desktop computers, laptops, smart phones, tablets, thin clients, etc. + +### 3.1.38 vulnerability +weakness of an *asset* (3.1.2) or *control* (3.1.8) that can be exploited by one or more *threats* (3.1.34) \[SOURCE: ISO/IEC 27000:2018, 3.77\] + +## 3.2 Abbreviated terms + +ABAC attribute-based access control + +ACL access control list + +BIA business impact analysis + +BYOD bring your own device + +CAPTCHA completely automated public Turing test to tell computers and humans apart + +CPU central processing unit + +DAC discretionary access control + +DNS domain name system + +GPS global positioning system + +IAM identity and access management + +ICT information and communication technology + +ID identifier + +IDE integrated development environment + +IDS intrusion detection system + +IoT internet of things + +IP internet protocol + +IPS intrusion prevention system + +IT information technology + +ISMS information security management system + +MAC mandatory access control + +NTP network time protocol + +PIA privacy impact assessment + +PII personally identifiable information + +PIN per sonal identification number + +PKI public key infrastructure + +PTP precision time protocol + +RBAC role-based access control + +RPO recovery point objective + +RTO recovery time objective + +SAST static application security testing + +SD secure digital + +SDN software-defined networking + +SD-WAN software-defined wide area networking + +SIEM security information and event management + +SMS short message service + +SQL structured query language + +SSO single sign on + +SWID software identification + +UEBA user and entity behaviour analytics + +UPS uninterruptible power supply + +URL uniform resource locator + +USB universal serial bus + +VM virtual machine + +VPN virtual private network + +WiFi wireless fidelity + +# 4 Structure of this document + +## 4.1 Clauses + +This document is structured as follows: + +a\) Organizational controls (Clause 5) + +b\) People controls (Clause 6) + +c\) Physical controls (Clause 7) + +d\) Technological controls (Clause 8) + +There are 2 informative annexes: + +— Annex A— Using attributes +— Annex B— Correspondence with ISO/IEC 27002:2013 + +Annex A explains how an organization can use attributes (see 4.2) to create its own views based on the control attributes defined in this document or of its own creation. + +Annex B shows the correspondence between the controls in this edition of ISO/IEC 27002 and the previous 2013 edition. + +## 4.2 Themes and attributes + +The categorization of controls given in Clauses 5to 8are referred to as themes. + +Controls are categorized as: + +a\) people, if they concern individual people; + +b\) physical, if they concern physical objects; + +c\) technological, if they concern technology; + +d\) otherwise they are categorized as organizational. + +The organization can use attributes to create different views which are different categorizations of controls as seen from a different perspective to the themes. Attributes can be used to filter, sort or present controls in different views for different audiences. Annex Aexplains how this can be achieved and provides an example of a view. + +By way of example, each control in this document has been associated with five attributes with corresponding attribute values (preceded by "#" to make them searchable), as follows: + +a\) Control type + +Control type is an attribute to view controls from the perspective of when and how the control modifies the risk with regard to the occurrence of an information security incident. Attribute values consist of Preventive (the control that is intended to prevent the occurrence of an information security incident), Detective (the control acts when an information security incident occurs) and Corrective (the control acts after an information security incident occurs). + +b\) Information security properties + +Information security properties is an attribute to view controls from the perspective of which characteristic of information the control will contribute to preserving. Attribute values consist of Confidentiality, Integrity and Availability. + +c\) Cybersecurity concepts + +Cybersecurity concepts is an attribute to view controls from the perspective of the association of controls to cybersecurity concepts defined in the cybersecurity framework described in ISO/IEC TS 27110. Attribute values consist of Identify, Protect, Detect, Respond and Recover. + +d\) Operational capabilities + +Operational capabilities is an attribute to view controls from the practitioner’s perspective of information security capabilities. Attribute values consist of Governance, Asset_management, Information_protection, Human_resource_security, Physical_security, System_and_network\_ security, Application_security, Secure_configuration, Identity_and_access_management, + +Threat_and_vulnerability_management, Continuity, Supplier_relationships_security, Legal_and\_ compliance, Information_security_event_management and Information_security_assurance. + + + + + +e\) Security domains + + +Security domains is an attribute to view controls from the perspective of four information security + +domains: “Governance and Ecosystem” includes “Information System Security Governance & + +Risk Management” and “Ecosystem cybersecurity management” (including internal and external stakeholders); “Protection” includes “IT Security Architecture”, “IT Security Administration”, “Identity and access management”, “IT Security Maintenance” and “Physical and environmental security”; “Defence” includes “Detection” and “Computer Security Incident Management”; “Resilience” includes “Continuity of operations” and “Crisis management”. Attribute values consist of Governance_and_Ecosystem, Protection, Defence and Resilience. + +The attributes given in this document are selected because they are considered generic enough to be used by different types of organizations. Organizations can choose to disregard one or more of the attributes given in this document. They can also create attributes of their own (with the corresponding attribute values) to create their own organizational views. Clause A.2includes examples of such attributes. + +## 4.3 Control layout + +The layout for each control contains the following: — **Control title:** Short name of the control; + +— **Attribute table**: A table shows the value(s) of each attribute for the given control; + +— **Control:** What the control is; + +— **Purpose**: Why the control should be implemented; — **Guidance:** How the control should be implemented; + +— **Other information:** Explanatory text or references to other related documents. + +Subheadings are used in the guidance text for some controls to aid readability where guidance is lengthy and addresses multiple topics. Such headings are not necessarily used in all guidance text. Subheadings are underlined. + +# 5 Organizational controls + +## 5.1 Policies for information security + +| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | +| :--------------- | :---------------------------------- | :------------------------- | :--------------------------- | :---------------------------------------- | +| #Preventive | #Confidentiality #Integrity #Availability | #Identify | #Governance | #Governance_and_Ecosystem #Resilience | + +**Control** + +Information security policy and topic-specific policies should be defined, approved by management, published, communicated to and acknowledged by relevant personnel and relevant interested parties, and reviewed at planned intervals and if significant changes occur. + +**Purpose** + +To ensure continuing suitability, adequacy, effectiveness of management direction and support for information security in accordance with business, legal, statutory, regulatory and contractual requirements. + +**Guidance** + +At the highest level, the organization should define an “information security policy” which is approved by top management and which sets out the organization’s approach to managing its information security. + +The in formation security policy should take into consideration requirements derived from: + +a\) business strategy and requirements; + +b\) regulations, legislation and contracts; + +c\) the current and projected information security risks and threats. The information security policy should contain statements concerning: + +a\) definition of information security; + +b\) information security objectives or the framework for setting information security objectives; + +c\) principles to guide all activities relating to information security; + +d\) commitment to satisfy applicable requirements related to information security; + +e\) commitment to continual improvement of the information security management system; + +f\) assignment of responsibilities for information security management to defined roles; + +g\) procedures for handling exemptions and exceptions. + +Top management should approve any changes to the information security policy. + +At a lower level, the information security policy should be supported by topic-specific policies as needed, to further mandate the implementation of information security controls. Topic-specific policies are typically structured to address the needs of certain target groups within an organization or to cover certain security areas. Topic-specific policies should be aligned with and complementary to the information security policy of the organization. + +Examples of such topics include: + +a\) access control; + +b\) physical and environmental security; + +c\) asset management; + +d\) information transfer; + +e\) secure configuration and handling of user endpoint devices; + +f\) networking security; + +g\) information security incident management; + +h\) backup; + +i\) cryptography and key management; + +j\) information classification and handling; + +k\) management of technical vulnerabilities; l) secure development. + +The responsibility for the development, review and approval of the topic-specific policies should be allocated to relevant personnel based on their appropriate level of authority and technical competency. The review should include assessing opportunities for improvement of the organization’s information security policy and topic-specific policies and managing informa tion security in response to changes to: + +a\) the organization’s business strategy; + +b\) the organization’s technical environment; + +c\) regulations, statutes, legislation and contracts; + +d\) information security risks; + +e\) the current and projected information security threat environment; + +f\) lessons learned from information security events and incidents. + +The review of information security policy and topic-specific policies should take the results of management reviews and audits into account. Review and update of other related policies should be considered when one policy is changed to maintain consistency. + +The information security policy and topic-specific policies should be communicated to relevant personnel and interested parties in a form that is relevant, accessible and understandable to the intended reader. Recipients of the policies should be required to acknowledge they understand and agree to comply with the policies where applicable. The organization can determine the formats and names of these policy documents that meet the organization’s needs. In some organizations, the information security policy and topic-specific policies can be in a single document. The organization can name these topic-specific policies as standards, directives, policies or others. + +If the information security policy or any topic-specific policy is distributed outside the organization, care should be taken not to improperly disclose confidential information. + +Table 1 illustrates the differences between information security policy and topic-specific policy. + +**Table 1 — Differences between information security policy and topic-specific policy** + +| | **Information security policy** | **Topic-specific policy** | +| ------------------ | :------------------------------ | :------------------------------ | +| **Level of detail** | General or high-level | Specific and detailed | +| **Documented and formally approved by** | Top management | Appropriate level of management | + +**Other information** + +Topic-specific policies can vary across organizations. + +## 5.2 Information security roles and responsibilities + +| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | +| :--------------- | :---------------------------------- | :------------------------- | :--------------------------- | :---------------------------------------- | +| #Preventive | #Confidentiality #Integrity #Availability | #Identify | #Governance | #Governance_and_Ecosys- tem #Protection #Resilience | + +**Control** + +Information security roles and responsibilities should be defined and allocated according to the organization needs. + +**Purpose** + +To establish a defined, approved and understood structure for the implementation, operation and management of information security within the organization. + +**Guidance** + +Allocation of information security roles and responsibilities should be done in accordance with the information security policy and topic-specific policies (see 5.1). The organization should define and manage responsibilities for: + +a\) protection of information and other associated assets; + +b\) carrying out specific information security processes; + +c\) information security risk management activities and in particular acceptance of residual risks (e.g. + +to risk owners); + +d\) all personnel using an organization’s information and other associated assets. + +These responsibilities should be supplemented, where necessary, with more detailed guidance for specific sites and information processing facilities. Individuals with allocated information security responsibilities can assign security tasks to others. However, they remain accountable and should determine that any delegated tasks have been correctly performed. + +Each security area for which individuals are responsible should be defined, documented and communicated. Authorization levels should be defined and documented. Individuals who take on a specific information security role should be competent in the knowledge and skills required by the role and should be supported to keep up to date with developments related to the role and required in order to fulfil the responsibilities of the role. + +**Other information** + +Many organizations appoint an information security manager to take overall responsibility for the development and implementation of information security and to support the identification of risks and mitigating controls. + +However, responsibility for resourcing and implementing the controls often remains with individual managers. One common practice is to appoint an owner for each asset who then becomes responsible for its day-to-day protection. + +Depending on the size and resourcing of an organization, information security can be covered by dedicated roles or duties carried out in addition to existing roles. + +## 5.3 Segregation of duties + +| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | +| :--------------- | :---------------------------------- | :------------------------- | :-------------------------------- | :-------------------------- | +| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Governance #Identity_and_ac- cess_management | #Governance_and_Ecosystem | + +**Control** + +Conflicting duties and conflicting areas of responsibility should be segregated. **Purpose** + +To reduce the risk of fraud, error and bypassing of information security controls. + +**Guidance** + +Segregation of duties and areas of responsibility aims to separate conflicting duties between different individuals in order to prev ent one individual from executing potential conflicting duties on their own. + +The organization should determine which duties and areas of responsibility need to be segregated. The following are examples of activities that can require segregation: + +a\) initiating, approving and executing a change; + +b\) requesting, approving and implementing access rights; + +c\) designing, implementing and reviewing code; + +d\) developing software and administering production systems; + +e\) using and administering applications; + +f\) using applications and administering databases; + +g\) designing, auditing and assuring information security controls. + +The possibility of collusion should be considered in designing the segregation controls. Small organizations can find segregation of duties difficult to achieve, but the principle should be applied as far as is possible and practicable. Whenever it is difficult to segregate, other controls should be considered, such as monitoring of activities, audit trails and management supervision. + +Care should be taken when using role-based access control systems to ensure that persons are not granted conflicting roles. When there is a large number of roles, the organization should consider using automated tools to identify conflicts and facilitate their removal. Roles should be carefully defined and provisioned to minimize access problems if a role is removed or reassigned. + +**Other information** No other information. + +## 5.4 Management responsibilities + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +| ------------ | ------------------------------ | --------------------- | ----------------------- | --------------- | +| #Preventive | #Confidentiality #Integrity #Availability | #Identify | #Governance | #Governance_and_Ecosystem | + +**Control** + +Management should require all personnel to apply information security in accordance with the established information security policy, topic-specific policies and procedures of the organization. + +**Purpose** + +To ensure management understand their role in information security and undertake actions aiming to ensure all personnel are aware of and fulfil their information security responsibilities. + +**Guidance** + +Management should demonstrate support of the information security policy, topic-specific policies, procedures and information security controls. + +Management responsibilities should include ensuring that personnel: + +a\) are properly briefed on their information security roles and responsibilities prior to being granted + +access to the organization’s information and other associated assets; + + + + + + + +b\) are provided with guidelines which state the information security expectations of their role within + +the org anization; + +c\) are mandated to fulfil the information security policy and topic-specific policies of the organization; + +d\) achieve a level of awareness of information security relevant to their roles and responsibilities + +within the organization (see 6.3); + +e\) compliance with the terms and conditions of employment, contract or agreement, including the + +organization’s information security policy and appropriate methods of working; + +f\) continue to have the appropriate information security skills and qualifications through ongoing + +professional education; + +g\) where practicable, are provided with a confidential channel for reporting violations of information security policy, topic-specific policies or procedures for information security (“whistleblowing”). This can allow for anonymous reporting, or have provisions to ensure that knowledge of the identity of the reporter is known only to those who need to deal with such reports; + +h\) are provided with adequate resources and project planning time for implementing the organization’s + +security-related processes and controls. + +**Other information** No other information. + +## 5.5 Contact with authorities + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +|-------------------|----------------------------------------|----------------------------------|-------------------------|-------------------------| +| #Preventive #Corrective | #Confidentiality #Integrity #Availability | #Identify #Protect #Respond #Recover | #Governance | #Defence #Resilience | + +**Control** + +The organization should establish and maintain contact with relevant authorities. **Purpose** + +To ensure appropriate flow of information takes place with respect to information security between the organization and relevant legal, regulatory and supervisory authorities. + +**Guidance** + +The organization should specify when and by whom authorities (e.g. law enforcement, regulatory bodies, supervisory authorities) should be contacted and how identified information security incidents should be reported in a timely manner. + +Contacts with authorities should also be used to facilitate the understanding about the current and upcoming expectations of these authorities (e.g. applicable information security regulations). + +**Other information** + +Organizations under attack can request authorities to take action against the attack source. + +Maintaining such contacts can be a requirement to support information security incident management (see 5.24to 5.28) or the contingency planning and business continuity processes (see 5.29and 5.30). Contacts with regulatory bodies are also useful to anticipate and prepare for upcoming changes in relevant laws or regulations that affect the organization. Contacts with other authorities include utilities, emergency services, electricity suppliers and health and safety \[e.g. fire departments (in connect ion with business continuity), telecommunication providers (in connection with line routing and availability) and water suppliers (in connection with cooling facilities for equipment)\]. + +## 5.6 Contact with special interest groups + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +|-------------------|----------------------------------------|----------------------------------|-------------------------|-------------------------| +| #Preventive #Corrective | #Confidentiality #Integrity #Availability | #Identify #Protect #Respond #Recover | #Governance | #Defence #Resilience | + +**Control** + +The organization should establish and maintain contact with special interest groups or other specialist security forums and professional associations. + +**Purpose** + +To ensure appropriate flow of information takes place with respect to information security. + +**Guidance** + +Membership of special interest groups or forums should be considered as a means to: + +a\) improve knowledge about best practices and stay up to date with relevant security information; + +b\) ensure the understanding of the information security environment is current; + +c\) receive early warnings of alerts, advisories and patches pertaining to attacks and vulnerabilities; + +d\) gain access to specialist information security advice; + +e\) share and exchange information about new technologies, products, services, threats or vulnerabilities; + +f\) provide suitable liaison points when dealing with information security incidents (see 5.24to 5.28). + +**Other information** + +No other information. + +## 5.7 Threat intelligence + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +|-------------------|----------------------------------------|----------------------------------|-------------------------|-------------------------| +| #Preventive #Detective #Corrective | #Confidentiality #Integrity #Availability | #Identify #Detect #Respond | #Threat_and_vulnerability_management | #Defence #Resilience | + +**Control** + +Information relating to information security threats should be collected and analysed to produce threat intelligence. + +**Purpose** + +To provide awareness of the organization’s threat environment so that the appropriate mitigation actions can be taken. + +**Guidance** + +Information about existing or emerging threats is collected and analysed in order to: + +a\) facilitate informed actions to prevent the threats from causing harm to the organization; + +b\) reduce the impact of such threats. + +Threat intelligence can be divided into three layers, which should all be considered: + +a\) strategic threat intelligence: exchange of high-level information about the changing threat landscape (e.g. types of attackers or types of attacks); + +b\) tactical threat intelligence: information about attacker methodologies, tools and technologies involved; + +c\) operational threat intelligence: details about specific attacks, including technical indicators. + +Threat intelligence should be: + +a\) relevant (i.e. related to the protection of the organization); + +b\) insightful (i.e. providing the organization with an accurate and detailed understanding of the threat landscape); + +c\) contextual, to provide situational awareness (i.e. adding context to the information based on the time of events, where they occur, previous experiences and prevalence in similar organizations); + +d\) actionable (i.e. the organization can act on information quickly and effectively). Threat intelligence activities should include: + +a\) establishing objectives for threat intelligence production; + +b\) identifying, vetting and selecting internal and external information sources that are necessary and appropriate to provide information required for the production of threat intelligence; + +c\) collecting information from selected sources, which can be internal and external; + +d\) processing information collected to prepare it for analysis (e.g. by translating, formatting or corroborating information); + +e\) analysing information to understand how it relates and is meaningful to the organization; + +f\) communicating and sharing it to relevant individuals in a format that can be understood. Threat intelligence should be analysed and later used: + +a\) by implementing processes to include information gathered from threat intelligence sources into the organization’s information security risk management processes; + +b\) as additional input to technical preventive and detective controls like firewalls, intrusion detection system, or anti malware solutions; + +c\) as input to the information security test processes and techniques. + +The organization should share threat intelligence with other organizations on a mutual basis in order to improve overall threat intelligence. + +**Other information** + +Organizations can use threat intelligence to prevent, detect, or respond to threats. Organizations can produce threat intelligence, but more typically receive and make use of threat intelligence produced by other sources. + +Threat intelligence is often provided by independent providers or advisors, government agencies or collaborative threat intelligence groups. + +The effectiveness of controls such as 5.25, 8.7, 8.16or 8.23, depends on the quality of available threat intelligence. + +## 5.8 Information security in project management + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +|-------------------|----------------------------------------|----------------------------------|-------------------------|-------------------------| +| #Preventive | #Confidentiality #Integrity #Availability | #Identify #Protect | #Governance | #Governance_and_Ecosystem #Protection| + +**Control** + +Information security should be integrated into project management. + +**Purpose** + +To ensure information security risks related to projects and deliverables are effectively addressed in project management throughout the project life cycle. + +**Guidance** + +Information security should be integrated into project management to ensure information security risks are addressed as part of the project management. This can be applied to any type of project regardless of its complexity, size, duration, discipline or application area (e.g. a project for a core business process, ICT, facility management or other supporting processes). + +The project management in use should require that: + +a\) information security risks are assessed and treated at an early stage and periodically as part of + +project risks throughout the project life cycle; + +b\) information security requirements \[e.g. application security requirements (8.26), requirements for complying with intellectual property rights (5.32), etc.\] are addressed in the early stages of projects; + +c\) information security risks associated with the execution of projects, such as security of internal + +and external communication aspects are considered and treated throughout the project life cycle; + +d\) progress on information security risk treatment is reviewed and effectiveness of the treatment is + +evaluated and tested. + +The appropriateness of the information security considerations and activities should be followed up at predefined stages by suitable persons or governance bodies, such as the project steering committee. + +Responsibilities and authorities for information security relevant to the project should be defined and allocated to specified roles. + +Information security requirements for products or services to be delivered by the project should be determined using various methods, including deriving compliance requirements from information security policy, topic-specific policies and regulations. Further information security requirements can be derived from activities such as threat modelling, incident reviews, use of vulnerability thresholds or contingency planning, thus ensuring that the architecture and design of information systems are protected against known threats based on the operational environment. + +Information security requirements should be determined for all types of projects, not only ICT development projects. The following should also be considered when determining these requirements: + +a\) what information is involved (information determination), what are the corresponding information security needs (classification; see 5.12) and the potential negative business impact which can result from lack of adequate security; + +b\) the required protection needs of information and other associated assets involved, particularly in + +terms of confidentiality, integrity and availability; + +c\) the level of confidence or assurance required towards the claimed identity of entities in order to + +derive the authentication requirements; + +d\) access provisioning and authorization processes, for customers and other potential business users as well as for privileged or technical users such as relevant project members, potential operation staff or external suppliers; + +e\) informing users of their duties and responsibilities; + +f\) requirements derived from business processes, such as transaction logging and monitoring, non- + +repudiation requirements; + +g\) requirements mandated by other information security controls (e.g. interfaces to logging and + +monitoring or data leakage detection systems); + +h\) compliance with the legal, statutory, regulatory and contractual environment in which the + +organization operates; + +i\) level of confidence or assurance required for third parties to meet the organization’s information + +security policy and topic-specific policies including relevant security clauses in any agreements or contracts. + +**Other information** + +The project development approach, such as waterfall life cycle or agile life cycle, should support information security in a structured way that can be adapted to suit the assessed severity of the information security risks, based on the character of the project. Early consideration of information security requirements for the product or service (e.g. at the planning and design stages), can lead to more effective and cost-efficient solutions for quality and information security. ISO 21500 and ISO 21502 provide guidance on concepts and processes of project management that are important for the performance of projects. + +ISO/IEC 27005 provides guidance on the use of risk management processes to identify controls to meet information security requirements. + +## 5.9 Inventory of information and other associated assets + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +|--------------|----------------------------------------|-----------------------|-------------------------|-----------------------------------| +| #Preventive | #Confidentiality #Integrity #Availability | #Identify | #Asset_management | #Governance_and_Ecosystem #Protection | + +**Control** + +An inventory of information and other associated assets, including owners, should be developed and maintained. + +**Purpose** + +To identify the organization’s information and other associated assets in order to preserve their information security and assign appropriate ownership. + +**Guidance** + +Inventory + +The organization should identify its information and other associated assets and determine their importance in terms of information security. Documentation should be maintained in dedicated or existing inventories as appropriate. + +The inventory of information and other associated assets should be accurate, up to date, consistent and aligned with other inventories. Options for ensuring accuracy of an inventory of information and other associated assets include: + +a\) conducting regular reviews of identified information and other associated assets against the asset inventory; + +b\) automatically enforcing an inventory update in the process of installing, changing or removing an asset. + +The location of an asset should be included in the inventory as appropriate. + +The inventory does not need to be a single list of information and other associated assets. Considering that the inventory should be maintained by the relevant functions, it can be seen as a set of dynamic inventories, such as inventories for information assets, hardware, software, virtual machines (VMs), facilities, personnel, competence, capabilities and records. + +Each asset should be classified in accordance with the classification of the information (see 5.12) associated to that asset. + +The granularity of the inventory of information and other associated assets should be at a level appropriate for the needs of the organization. Sometimes specific instances of assets in the information life cycle are not feasible to be documented due to the nature of the asset. An example of a short-lived asset is a VM instance whose life cycle can be of short duration. + +Ownership + +For the identified information and other associated assets, ownership of the asset should be assigned to an individual or a group and the classification should be identified (see 5.12, 5.13). A process to ensure timely assignment of asset ownership should be implemented. Ownership should be assigned when assets are created or when assets are transferred to the organization. Asset ownership should be reassigned as necessary when current asset owners leave or change job roles. + +Owner duties + +The asset owner should be responsible for the proper management of an asset over the whole asset life cycle, ensuring that: + +a\) information and other associated assets are inventoried; + +b\) information and other associated assets are appropriately classified and protected; + +c\) the classification is reviewed periodically; + +d\) components supporting technology assets are listed and linked, such as database, storage, software components and sub-components; + +e\) requirements for the acceptable use of information and other associated assets (see 5.10) are established; + +f\) access restrictions correspond with the classification and that they are effective and are reviewed periodically; + +g\) information and other associated assets, when deleted or disposed, are handled in a secure manner and removed from the inventory; + +h\) they are involved in the identification and management of risks associated with their asset(s); + +i\) the y support personnel who have the roles and responsibilities of managing their information. + +**Other information** + +Inventories of information and other associated assets are often necessary to ensure the effective protection of information and can be required for other purposes, such as health and safety, insurance or financial reasons. Inventories of information and other associated assets also support risk management, audit activities, vulnerability management, incident response and recovery planning. + +Tasks and responsibilities can be delegated (e.g. to a custodian looking after the assets on a daily basis), but the person or group who delegated them remains accountable. + +It can be useful to designate groups of information and other associated assets which act together to provide a particular service. In this case, the owner of this service is accountable for the delivery of the service, including the operation of its assets. + +See ISO/IEC 19770-1 for additional information on information technology (IT) asset management. See ISO 55001 for additional information on asset management. + +## 5.10 Acceptable use of information and other associated assets + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +|--------------|----------------------------------------|-----------------------|-----------------------------------------|-----------------------------------| +| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Asset_management #Information_protection | #Governance_and_Ecosystem #Protection | + +**Control** + +Rules for the acceptable use and procedures for handling information and other associated assets should be identified, documented and implemented. + +**Purpose** + +To ensure information and other associated assets are appropriately protected, used and handled. + +**Guidance** + +Personnel and external party users using or having access to the organization’s information and other associated assets should be made aware of the information security requirements for protecting and handling the organization’s information and other associated assets. They should be responsible for their use of any information processing facilities. + +The organization should establish a topic-specific policy on the acceptable use of information and other associated assets and communicate it to anyone who uses or handles information and other associated assets. The topic-specific policy on acceptable use should provide clear direction on how individuals are expected to use information and other associated assets. The topic-specific policy should state: + +a\) expected and unacceptable behaviours of individuals from an information security perspective; + +b\) permitted and prohibited use of information and other associated assets; + +c\) monitoring activities being performed by the organization. + +Acceptable use procedures should be drawn up for the full information life cycle in accordance with its classification (see 5.12) and determined risks. The following items should be considered: + +a\) access restrictions supporting the protection requirements for each level of classification; + +b\) maintenance of a record of the authorized users of information and other associated assets; + +c\) protection of temporary or permanent copies of information to a level consistent with the protection of the original information; + +d\) storage of assets associated with information in accordance with manufacturers’ specifications (see 7.8); + +e\) clear marking of all copies of storage media (electronic or physical) for the attention of the authorized recipient (see 7.10); + +f\) authorization of disposal of information and other associated assets and supported deletion method(s) (see 8.10). + +**Other information** + +It can be the case that the assets concerned do not directly belong to the organization, such as public cloud services. The use of such third-party assets and any assets of the organization associated with such external assets (e.g. information, software) should be identified as applicable and controlled, for example, through agreements with cloud service providers. Care should also be taken when a collaborative working environment is used. + +## 5.11 Return of assets + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +|--------------|----------------------------------------|-----------------------|-------------------------|--------------------| +| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Asset_management | #Protection | + +**Control** + +Personnel and other interested parties as appropriate should return all the organization’s assets in their possession upon change or termination of their employment, contract or agreement. + +**Purpose** + +To protect the organization’s assets as part of the process of changing or terminating employment, contract or agreement. + +**Guidance** + +The change or termination process should be formalized to include the return of all previously issued physical and electronic assets owned by or entrusted to the organization. + +In cases where personnel and other interested parties purchase the organization’s equipment or use their own personal equipment, procedures should be followed to ensure that all relevant information is traced and transferred to the organization and securely deleted from the equipment (see 7.14). + +In cases where personnel and other interested parties have knowledge that is important to ongoing operations, that information should be documented and transferred to the organization. + +During the notice period and thereafter, the organization should prevent unauthorized copying of relevant information (e.g. intellectual property) by personnel under notice of termination. + +The organization should clearly identify and document all information and other associated assets to be returned which can include: + +a\) user endpoint devices; + +b\) portable storage devices; + +c\) specialist equipment; + +d\) authentication hardware (e.g. mechanical keys, physical tokens and smartcards) for information systems, sites and physical archives; + +e\) physical copies of information. + +**Other information** + +It can be difficult to return information held on assets which are not owned by the organization. In such cases, it is necessary to restrict the use of information using other information security controls such as access rights management (5.18) or use of cryptography (8.24). + +## 5.12 Classification of information + + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +|--------------|----------------------------------------|-----------------------|-------------------------|-----------------------------------| +| #Preventive | #Confidentiality #Integrity #Availability | #Identify | #Information_protection | #Protection #Defence | + +**Control** + +Information should be classified according to the information security needs of the organization based on confidentiality, integrity, availability and relevant interested party requirements. + +**Purpose** + +To ensure identification and understanding of protection needs of information in accordance with its importance to the organization. + +**Guidance** + +The organization should establish a topic-specific policy on information classification and communicate it to all relevant interested parties. + +The organization should take into account requirements for confidentiality, integrity and availability in the classification scheme. + +Classifications and associated protective controls for information should take account of business needs for sharing or restricting information, for protecting integrity of information and for assuring availability, as well as legal requirements concerning the confidentiality, integrity or availability of the information. Assets other than information can also be classified in compliance with classification of information, which is stored in, processed by or otherwise handled or protected by the asset. + +Owners of information should be accountable for their classification. + +The classification scheme should include conventions for classification and criteria for review of the classification over time. Results of classification should be updated in accordance with changes of the value, sensitivity and criticality of information through their life cycle. + +The scheme should be aligned to the topic-specific policy on access control (see 5.1) and should be able to address specific business needs of the organization. + +The classification can be determined by the level of impact that the information's compromise would have for the organization. Each level defined in the scheme should be given a name that makes sense in the context of the classification scheme’s application. + +The scheme should be consistent across the whole organization and included in its procedures so that everyone classifies information and applicable other associated assets in the same way. In this manner, everyone has a common understanding of protection requirements and applies appropriate protection. + +The classification scheme used within the organization can be different from the schemes used by other organizations, even if the names for levels are similar. In addition, information moving between organizations can vary in classification depending on its context in each organization, even if their classification schemes are identical. Therefore, agreements with other organizations that include information sharing should include procedures to identify the classification of that information and to interpret the classification levels from other organizations. Correspondence between different schemes can be determined by looking for equivalence in the associated handling and protection methods. + +**Other information** + +Classification provides people who deal with information with a concise indication of how to handle and protect it. Creating groups of information with similar protection needs and specifying information security procedures that apply to all the information in each group facilitates this. This approach reduces the need for case-by-case risk assessment and custom design of controls. + +Information can cease to be sensitive or critical after a certain period of time. For example, when the information has been made public, it no longer has confidentiality requirements but can still require protection for its integrity and availability properties. These aspects should be taken into account, as over-classification can lead to the implementation of unnecessary controls resulting in additional expense or, on the contrary, under-classification can lead to insufficient controls to protect the information from compromise. + +As an example, an information confidentiality classification scheme can be based on four levels as follows: + +a\) disclosure causes no harm; + +b\) disclosure causes minor reputational damage or minor operational impact; + +c\) disclosure has a significant short-term impact on operations or business objectives; + +d\) disclosure has a serious impact on long term business objectives or puts the survival of the organization at risk. + +## 5.13 Labelling of information + +**Control** + +An appropriate set of procedures for information labelling should be developed and implemented in accordance with the information classification scheme adopted by the organization. + +**Purpose** + +To facilitate the communication of classification of information and support automation of information processing and management. + +**Guidance** + +Procedures for information labelling should cover information and other associated assets in all formats. The labelling should reflect the classification scheme established in 5.12. The labels should be easily recognizable. The procedures should give guidance on where and how labels are attached in consideration of how the information is accessed or the assets are handled depending on the types of storage media. The procedures can define: + +a\) cases where labelling is omitted (e.g. labelling of non-confidential information to reduce workloads); + +b\) how to label information sent by or stored on electronic or physical means, or any other format; + +c\) how to handle cases where labelling is not possible (e.g. due to technical restrictions). Examples of labelling techniques include: + +a\) physical labels; + +b\) headers and footers; + +c\) metadata; + +d\) watermarking; + +e\) rubber-stamps. + +Digital information should utilize metadata in order to identify, manage and control information, especially with regard to confidentiality. Metadata should also enable efficient and correct searching for information. Metadata should facilitate systems to interact and make decisions based on the associated classification labels. + +The procedures should describe how to attach metadata to information, what labels to use and how data should be handled, in line with the organization’s information model and ICT architecture. + +Relevant additional metadata should be added by systems when they process information depending on its information security properties. + +Personnel and other interested parties should be made aware of labelling procedures. All personnel should be provided with the necessary training to ensure that information is correctly labelled and handled accordingly. + +Output from systems containing information that is classified as being sensitive or critical should carry an appropriate classification label. + +**Other information** + +Labelling of classified information is a key requirement for information sharing. + +Other useful metadata that can be attached to the information is which organizational process created the information and at what time. + +Labelling of information and other associated assets can sometimes have negative effects. Classified assets can be easier to identify by malicious actors for potential misuse. + +Some systems do not label individual files or database records with their classification but protect all information at the highest level of classification of any of the information that it contains or is permitted to contain. It is usual in such systems to determine and then label information when it is exported. + +## 5.14 Information transfer + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +|--------------|----------------------------------------|-----------------------|-----------------------------------------|--------------------| +| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Asset_management #Information_protection | #Protection | + +**Control** + +Information transfer rules, procedures, or agreements should be in place for all types of transfer facilities within the organization and between the organization and other parties. + +**Purpose** + +To maintain the security of information transferred within an organization and with any external interested party. + +**Guidance** + +General + +The organization should establish and communicate a topic-specific policy on information transfer to all relevant interested parties. Rules, procedures and agreements to protect information in transit should reflect the classification of the information involved. Where information is transferred between the organization and third parties, transfer agreements (including recipient authentication) should be established and maintained to protect information in all forms in transit (see 5.10). + +Information transfer can happen through electronic transfer, physical storage media transfer and verbal transfer. + +For all types of information transfer, rules, procedures and agreements should include: + +a\) controls designed to protect transferred information from interception, unauthorized access, copying, modification, misrouting, destruction and denial of service, including levels of access control commensurate with the classification of the information involved and any special controls that are required to protect sensitive information, such as use of cryptographic techniques (see 8.24); + +b\) controls to ensure traceability and non-repudiation, including maintaining a chain of custody for information while in transit; + +c\) identification of appropriate contacts related to the transfer including information owners, risk owners, security officers and information custodians, as applicable; + +d\) responsibilities and liabilities in the event of information security incidents, such as loss of physical storage media or data; + +e\) use of an agreed labelling system for sensitive or critical information, ensuring that the meaning of the labels is immediately understood and that the information is appropriately protected (see 5.13); + +f\) reliability and availability of the transfer service; + +g\) the topic-specific policy or guidelines on acceptable use of information transfer facilities (see 5.10); + +h\) retention and disposal guidelines for all business records, including messages; + +NOTE Local legislation and regulations can exist regarding retention and disposal of business records. + +i\) the consideration of any other relevant legal, statutory, regulatory and contractual requirements (see 5.31, 5.32, 5.33, 5.34) related to transfer of information (e.g. requirements for electronic signatures). + +Electronic transfer + +Rules, procedures and agreements should also consider the following items when using electronic communication facilities for information transfer: + +a\) detection of and protection against malware that can be transmitted through the use of electronic communications (see 8.7); + +b\) protection of communicated sensitive electronic information that is in the form of an attachment; + +c\) prevention against sending documents and messages in communications to the wrong address or number; + +d\) obtaining approval prior to using external public services such as instant messaging, social networking, file sharing or cloud storage; + +e\) stronger levels of authentication when transferring information via publicly accessible networks; + +f\) restrictions associated with electronic communication facilities (e.g. preventing automatic forwarding of electronic mail to external mail addresses); + +g\) advising personnel and other interested parties not to send short message service (SMS) or instant messages with critical information since these can be read in public places (and therefore by unauthorized persons) or stored in devices not adequately protected; + +h\) advising personnel and other interested parties about the problems of using fax machines or services, namely: + +1\) unauthorized access to built-in message stores to retrieve messages; + +2\) deliberate or accidental programming of machines to send messages to specific numbers. + +Physical storage media transfer + +When transferring physical storage media (including paper), rules, procedures and agreements should also include: + +a\) responsibilities for controlling and notifying transmission, dispatch and receipt; + +b\) ensuring correct addressing and transportation of the message; + +c\) packaging that protects the contents from any physical damage likely to arise during transit and in accordance with any manufacturers’ specifications, for example protecting against any environmental factors that can reduce the effectiveness of restoring storage media such as exposure to heat, moisture or electromagnetic fields; using minimum technical standards for packaging and transmission (e.g. the use of opaque envelopes); + +d\) a list of authorized reliable couriers agreed by management; + +e\) courier identification standards; + +f\) depending on the classification level of the information in the storage media to be transported, use tamper evident or tamper-resistant controls (e.g. bags, containers); + +g\) procedures to verify the identification of couriers; + +h\) approved list of third parties providing transportation or courier services depending on the classification of the information; + +i\) keeping logs for identifying the content of the storage media, the protection applied as well as recording the list of authorised recipients, the times of transfer to the transit custodians and receipt at the destination. + +Verbal transfer + +To protect verbal transfer of information, personnel and other interested parties should be reminded that they should: + +a\) not have confidential verbal conversations in public places or over insecure communication channels since these can be overheard by unauthorized persons; + +b\) not leave messages containing confidential information on answering machines or voice messages since these can be replayed by unauthorized persons, stored on communal systems or stored incorrectly as a result of misdialling; + +c\) be screened to the appropriate level to listen to the conversation; + +d\) ensure that appropriate room controls are implemented (e.g. sound-proofing, closed door); + +e\) begin any sensitive conversations with a disclaimer so those present know the classification level and any handling requirements of what they are about to hear. + +**Other information** +No other information. + +## 5.15 Access control + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +|--------------|----------------------------------------|-----------------------|-----------------------------------------|--------------------| +| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Identity_and_access_management | #Protection | + +**Control** + +Rules to control physical and logical access to information and other associated assets should be established and implemented based on business and information security requirements. + +**Purpose** + +To ensure authorized access and to prevent unauthorized access to information and other associated assets. + +**Guidance** + +Owners of information and other associated assets should determine information security and business requirements related to access control. A topic-specific policy on access control should be defined which takes account of these requirements and should be communicated to all relevant interested parties. + +These requirements and the topic-specific policy should consider the following: + +a\) determining which entities require which type of access to the information and other associated assets; + +b\) security of applications (see 8.26); + +c\) physical access, which needs to be supported by appropriate physical entry controls (see 7.2, 7.3, 7.4); + +d\) information dissemination and authorization (e.g. the need-to-know principle) and information security levels and classification of information (see 5.10, 5.12, 5.13); + +e\) restrictions to privileged access (see 8.2); + +f\) segregation of duties (see 5.3); + +g\) relevant legislation, regulations and any contractual obligations regarding limitation of access to data or services (see 5.31, 5.32, 5.33, 5.34, 8.3); + +h\) segregation of access control functions (e.g. access request, access authorization, access administration); + +i\) formal authorization of access requests (see 5.16and 5.18); + +j\) the management of access rights (see 5.18); + +k\) logging (see 8.15). + +Access control rules should be implemented by defining and mapping appropriate access rights and restrictions to the relevant entities (see 5.16). An entity can represent a human user as well as a technical or logical item (e.g. a machine, device or a service). To simplify the access control management, specific roles can be assigned to entity groups. + +The following should be taken into account when defining and implementing access control rules: + +a\) consistency between the access rights and information classification; + +b\) consistency between the access rights and the physical perimeter security needs and requirements; + +c\) considering all types of available connections in distributed environments so entities are only provided with access to information and other associated assets, including networks and network services, that they are authorized to use; + +d\) considering how elements or factors relevant to dynamic access control can be reflected. + +**Other information** + +There are often overarching principles used in the context of access control. Two of the most frequently used principles are: + +a\) need-to-know: an entity is only granted access to the information which that entity requires in order to perform its tasks (different tasks or roles mean different need-to-know information and hence different access profiles); + +b\) need-to-use: an entity is only assigned access to information technology infrastructure where a clear need is present. + +Care should be taken when specifying access control rules to consider: + +a\) establishing rules based on the premise of least privilege, “Everything is generally forbidden unless expressly permitted”, rather than the weaker rule, “Everything is generally permitted unless expressly forbidden”; + +b\) changes in information labels (see 5.13) that are initiated automatically by information processing facilities and those initiated at the discretion of a user; + +c\) changes in user permissions that are initiated automatically by the information system and those initiated by an administrator; + +d\) when to define and regularly review the approval. + +Access control rules should be supported by documented procedures (see 5.16, 5.17, 5.18, 8.2, 8.3, 8.4, 8.5, 8.18) and defined responsibilities (see 5.2, 5.17). + +There are several ways to implement access control, such as MAC (mandatory access control), DAC (discretionary access control), RBAC (role-based access control) and ABAC (attribute-based access control). + +Access control rules can also contain dynamic elements (e.g. a function that evaluates past accesses or specific environment values). Access control rules can be implemented in different granularity, ranging from covering whole networks or systems to specific data fields and can also consider properties such as user location or the type of network connection that is used for access. These principles and how granular access control is defined can have a significant cost impact. Stronger rules and more granularity typically lead to higher cost. Business requirements and risk considerations should be used to define which access control rules are applied and which granularity is required. + +## 5.16 Identity management + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +|--------------|----------------------------------------|-----------------------|-----------------------------------------|--------------------| +| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Identity_and_access_management | #Protection | + +**Control** + +The full life cycle of identities should be managed. + +**Purpose** + +To allow for the unique identification of individuals and systems accessing the organization’s information and other associated assets and to enable appropriate assignment of access rights. + +**Guidance** + +The processes used in the context of identity management should ensure that: + +a\) for identities assigned to persons, a specific identity is only linked to a single person to be able to hold the person accountable for actions performed with this specific identity; + +b\) identities assigned to multiple persons (e.g. shared identities) are only permitted where they are necessary for business or operational reasons and are subject to dedicated approval and documentation; + +c\) identities assigned to non-human entities are subject to appropriately segregated approval and independent ongoing oversight; + +d\) identities are disabled or removed in a timely fashion if they are no longer required (e.g. if their associated entities are deleted or no longer used, or if the person linked to an identity has left the organization or changed the role); + +e\) in a specific domain, a single identity is mapped to a single entity, \[i.e. mapping of multiple identities + +to the same entity within the same context (duplicate identities) is avoided\]; + +f\) records of all significant events concerning the use and management of user identities and of authentication information are kept. + +The organization should have a supporting process in place to handle changes to information related to user identities. These processes can include re-verification of trusted documents related to a person. + +When using identities provided or issued by third parties (e.g. social media credentials), the organization should ensure the third-party identities provide the required trust level and any associated risks are known and sufficiently treated. This can include controls related to the third parties (see 5.19) as well as controls related to associated authentication information (see 5.17). + +**Other information** + +Providing or revoking access to information and other associated assets is usually a multi-step procedure: + +a\) confirming the business requirements for an identity to be established; + +b\) verifying the identity of an entity before allocating them a logical identity; + +c\) establishing an identity; + +d\) configuring and activating the identity. This also includes configuration and initial setup of related authentication services; + +e\) providing or revoking specific access rights to the identity, based on appropriate authorization or entitle ment decisions (see 5.18). + +## 5.17 Authentication information + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +|--------------|----------------------------------------|-----------------------|-----------------------------------------|--------------------| +| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Identity_and_access_management | #Protection | + +**Control** + +Allocation and management of authentication information should be controlled by a management process, including advising personnel on the appropriate handling of authentication information. + +**Purpose** + +To ensure proper entity authentication and prevent failures of authentication processes. + +**Guidance** + +Allocation of authentication information + +The allocation and management process should ensure that: + +a\) personal passwords or personal identification numbers (PINs) generated automatically during enrolment processes as temporary secret authentication information are non-guessable and unique for each person, and that users are required to change them after the first use; + +b\) procedures are established to verify the identity of a user prior to providing new, replacement or temporary authentication information; + +c\) authentication information, including temporary authentication information, is transmitted to users in a secure manner (e.g. over an authenticated and protected channel) and the use of unprotected (clear text) electronic mail messages for this purpose is avoided; + +d\) users acknowledge receipt of authentication information; + +e\) default authentication information as predefined or provided by vendors is changed immediately following installation of systems or software; + +f\) records of significant events concerning allocation and management of authentication information are kept and their confidentiality is granted, and that the record-keeping method is approved (e.g. by using an approved password vault tool). + +User responsibilities + +Any person having access to or using authentication information should be advised to ensure that: + +a\) secret authentication information such as passwords are kept confidential. Personal secret authentication information is not to be shared with anyone. Secret authentication information used in the context of identities linked to multiple users or linked to non-personal entities are solely shared with authorized persons; + +b\) affected or compromised authentication information is changed immediately upon notification of or any other indication of a compromise; + +c\) when passwords are used as authentication information, strong passwords according to best practice recommendations are selected, for example: + +1\) passwords are not based on anything somebody else can easily guess or obtain using person-related information (e.g. names, telephone numbers and dates of birth); + +2\) passwords are not based on dictionary words or combinations thereof; + +3\) use easy to remember passphrases and try to include alphanumerical and special characters; + +4\) passwords have a minimum length; + +d\) the same passwords are not used across distinct services and systems; + +e\) the obligation to follow these rules is also included in terms and conditions of employment (see 6.2). + +Password management system + +When passwords are used as authentication information, the password management system should: + +a\) allow users to select and change their own passwords and include a confirmation procedure to address input errors; + +b\) enforce strong passwords according to good practice recommendations \[see c) of "User responsibilities\]; + +c\) force users to change their passwords at first login; + +d\) enforce password changes as necessary, for example after a security incident, or upon termination or change of employment when a user has known passwords for identities that remain active (e.g. shared identities); + +e\) prevent re-use of previous passwords; + +f\) prevent the use of commonly-used passwords and compromised usernames, password combinations from hacked systems; + +g\) not display passwords on the screen when being entered; + +h\) store and transmit passwords in protected form. + +Password encryption and hashing should be performed according to approved cryptographic techniques for passwords (see 8.24). + +**Other information** + +Passwords or passphrases are a commonly used type of authentication information and are a common means of verifying a user’s identity. Other types of authentication information are cryptographic keys, data stored on hardware tokens (e.g. smart cards) that produce authentication codes and biometric data such as iris scans or fingerprints. Additional information can be found in the ISO/IEC 24760 series. + +Requiring frequent change of passwords can be problematic because users can get annoyed by the frequent changes, forget new passwords, note them down in unsafe places, or choose unsafe passwords. Provision of single sign on (SSO) or other authentication management tools (e.g. password vaults) reduces the amount of authentication information that users are required to protect and can thereby increase the effectiveness of this control. However, these tools can also increase the impact of disclosure of authentication information. + +Some applications require user passwords to be assigned by an independent authority. In such cases, a), c\) and d) of "Password management system" do not apply. + + +## 5.18 Access rights + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +|--------------|----------------------------------------|-----------------------|-------------------------------|--------------------| +| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Identity_and_access_management | #Protection | + +**Control** + +Access rights to information and other associated assets should be provisioned, reviewed, modified and removed in accordance with the organization’s topic-specific policy on and rules for access control. + +**Purpose** + +To ensure access to information and other associated assets is defined and authorized according to the business requirements. + +**Guidance** + +Provision and revocation of access rights + +The provisioning process for assigning or revoking physical and logical access rights granted to an entity’s authenticated identity should include: + +a\) obtaining authorization from the owner of the information and other associated assets for the use of the information and other associated assets (see 5.9). Separate approval for access rights by management can also be appropriate; + +b\) considering the business requirements and the organization’s topic-specific policy and rules on access control; + +c\) considering segregation of duties, including segregating the roles of approval and implementation of the access rights and separation of conflicting roles; + +d\) ensuring access rights are removed when someone does not need to access the information and other associated assets, in particular ensuring access rights of users who have left the organization are removed in a timely fashion; + +e\) considering giving temporary access rights for a limited time period and revoking them at the expiration date, in particular for temporary personnel or temporary access required by personnel; + +f\) verifying that the level of access granted is in accordance with the topic-specific policies on access control (see 5.15) and is consistent with other information security requirements such as segregation of duties (see 5.3); + +g\) ensuring that access rights are activated (e.g. by service providers) only after authorization procedures are successfully completed; + +h\) maintaining a central record of access rights granted to a user identifier (ID, logical or physical) to access information and other associated assets; + +i\) modifying access rights of users who have changed roles or jobs; + +j\) removing or adjusting physical and logical access rights, which can be done by removal, revocation or replacement of keys, authentication information, identification cards or subscriptions; + +k\) maintaining a record of changes to users’ logical and physical access rights. + +Review of access rights + +Regular reviews of physical and logical access rights should consider the following: + +a\) users’ access rights after any change within the same organization (e.g. job change, promotion, demotion) or termination of employment (see 6.1to 6.5); + +b\) authorizations for privileged access rights. + +Consideration before change or termination of employment + +A user’s access rights to information and other associated assets should be reviewed and adjusted or removed before any change or termination of employment based on the evaluation of risk factors such as: + +a\) whether the termination or change is initiated by the user or by management and the reason for termination; + +b\) the current responsibilities of the user; + +c\) the value of the assets currently accessible. + +**Other information** + +Consideration should be given to establishing user access roles based on business requirements that summarize a number of access rights into typical user access profiles. Access requests and reviews of access rights are easier managed at the level of such roles than at the level of particular rights. + +Consideration should be given to including clauses in personnel contracts and service contracts that specify sanctions if unauthorized access is attempted by personnel (see 5.20, 6.2, 6.4, 6.6). + +In cases of management-initiated termination, disgruntled personnel or external party users can deliberately corrupt information or sabotage information processing facilities. In cases of persons resigning or being dismissed, they can be tempted to collect information for future use. + +Cloning is an efficient way for organizations to assign access to users. However, it should be done with care based on distinct roles identified by the organization rather than just cloning an identity with all associated access rights. Cloning has an inherent risk of resulting in excessive access rights to information and other associated assets. + +## 5.19 Information security in supplier relationships** + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +|--------------|-------------------------------------------|------------------------|-----------------------------------------|----------------------------------------------| +| #Preventive | #Confidentiality #Integrity #Availability | #Identify | #Supplier_relationships_security | #Governance_and_Ecosystem #Protection | + +**Control** + +Processes and procedures should be defined and implemented to manage the information security risks associated with the use of supplier’s products or services. + +**Purpose** + +To maintain an agreed level of information security in supplier relationships. + +**Guidance** + +The organization should establish and communicate a topic-specific policy on supplier relationships to all relevant interested parties. + +The organization should identify and implement processes and procedures to address security risks associated with the use of products and services provided by suppliers. This should also apply to the organization’s use of resources of cloud service providers. These processes and procedures should include those to be implemented by the organization, as well as those the organization requires the supplier to implement for the commencement of use of a supplier’s products or services or for the termination of use of a supplier’s products and services, such as: + +a\) identifying and documenting the types of suppliers (e.g. ICT services, logistics, utilities, financial services, ICT infrastructure components) which can affect the confidentiality, integrity and availability of the organization's information; + +b\) establishing how to evaluate and select suppliers according to the sensitivity of information, products and services (e.g. with market analysis, customer references, review of documents, on- site assessments, certifications); + +c\) evaluating and selecting supplier’s products or services that have adequate information security controls and reviewing them; in particular, accuracy and completeness of controls implemented by the supplier that ensure integrity of the supplier’s information and information processing and hence the organization’s information security; + +d\) defining the organization’s information, ICT services and the physical infrastructure that suppliers can access, monitor, control or use; + +e\) defining the types of ICT infrastructure components and services provided by suppliers which can affect the confidentiality, integrity and availability of the organization's information; + +f\) assessing and managing the information security risks associated with: + +1\) the suppliers’ use of the organization’s information and other associated assets, including risks originating from potential malicious supplier personnel; + +2\) malfunctioning or vulnerabilities of the products (including software components and sub-components used in these products) or services provided by the suppliers; + +g\) monitoring compliance with established information security requirements for each type of supplier and type of access, including third-party review and product validation; + +h\) mitigating non-compliance of a supplier, whether this was detected through monitoring or by other means; + +i\) handling incidents and contingencies associated with supplier products and services including responsibilities of both the organization and suppliers; + +j\) resilience and, if necessary, recovery and contingency measures to ensure the availability of the supplier’s information and information processing and hence the availability of the organization’s information; + +k\) awareness and training for the organization’s personnel interacting with supplier personnel regarding appropriate rules of engagement, topic-specific policies, processes and procedures and behaviour based on the type of supplier and the level of supplier access to the organization’s systems and information; + +l\) managing the necessary transfer of information, other associated assets and anything else that needs to be changed and ensuring that information security is maintained throughout the transfer period; + +m\) requirements to ensure a secure termination of the supplier relationship, including: + +1\) de-provisioning of access rights; + +2\) information handling; + +3\) determining ownership of intellectual property developed during the engagement; + +4\) information portability in case of change of supplier or insourcing; + +6\) records management; + +7\) return of assets; + +8\) secure disposal of information and other associated assets; + +9\) ongoing confidentiality requirements; + +n\) level of personnel security and physical security expected from supplier's personnel and facilities. + +The procedures for continuing information processing in the event that the supplier becomes unable to supply its products or services (e.g. because of an incident, because the supplier is no longer in business, or no longer provides some components due to technology advancements) should be considered to avoid any delay in arranging replacement products or services (e.g. identifying an alternative supplier in advance or always using alternative suppliers). + +**Other information** + +In cases where it is not possible for an organization to place requirements on a supplier, the organization should: + +a\) consider the guidance given in this control in making decisions about choosing a supplier and its product or service; + +b\) implement compensating controls as necessary based on a risk assessment. + +Information can be put at risk by suppliers with inadequate information security management. Controls should be determined and applied to manage the supplier's access to information and other associated assets. For example, if there is a special need for confidentiality of the information, non-disclosure agreements or cryptographic techniques can be used. Another example is personal data protection risks when the supplier agreement involves transfer of, or access to, information across borders. The organization needs to be aware that the legal or contractual responsibility for protecting information remains with the organization. + +Risks can also be caused by inadequate controls of ICT infrastructure components or services provided by suppliers. Malfunctioning or vulnerable components or services can cause information security breaches in the organization or to another entity (e.g. they can cause malware infection, attacks or other harm on entities other than the organization). + +See ISO/IEC 27036-2 for more detail. + +## 5.20 Addressing information security within supplier agreements + + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +|--------------|----------------------------------------|-----------------------|-----------------------------------------|--------------------| +| #Preventive | #Confidentiality #Integrity #Availability | #Identify | #Supplier_relationships_security | #Governance_and_Ecosystem #Protection | + +**Control** + +Relevant information security requirements should be established and agreed with each supplier based on the type of supplier relationship. + +**Purpose** + +To maintain an agreed level of information security in supplier relationships. + +**Guidance** + +Supplier agreements should be established and documented to ensure that there is clear understanding between the organization and the supplier regarding both parties’ obligations to fulfil relevant information security requirements. + +The following terms can be considered for inclusion in the agreements in order to satisfy the identified information security requirements: + +a\) description of the information to be provided or accessed and methods of providing or accessing the information; + +b\) classification of information according to the organization’s classification scheme (see [[5.10]], [[5.12]], [[5.13]]) + +c\) mapping between the organization’s own classification scheme and the classification scheme of the supplier; + +d\) legal, statutory, regulatory and contractual requirements, including data protection, handling of personally identifiable information (PII), intellectual property rights and copyright and a description of how it will be ensured that they are met; + +e\) obligation of each contractual party to implement an agreed set of controls, including access control, performance review, monitoring, reporting and auditing, and the supplier’s obligations to comply with the organization’s information security requirements; + +f\) rules of acceptable use of information and other associated assets, including unacceptable use if necessary; + +g\) procedures or conditions for authorization and removal of the authorization for the use of the organization’s information and other associated assets by supplier personnel (e.g. through an explicit list of supplier personnel authorized to use the organization’s information and other associated assets); + +h\) information security requirements regarding the supplier’s ICT infrastructure; in particular, minimum information security requirements for each type of information and type of access to serve as the basis for individual supplier agreements based on the organization’s business needs and risk criteria; + +i\) indemnities and remediation for failure of contractor to meet requirements; + +j\) incident management requirements and procedures (especially notification and collaboration during incident remediation); + +k\) training and awareness requirements for specific procedures and information security requirements (e.g. for incident response, authorization procedures); + +l\) relevant provisions for sub-contracting, including the controls that need to be implemented, such as agreement on the use of sub-suppliers (e.g. requiring to have them under the same obligations of the supplier, requiring to have a list of sub-suppliers and notification before any change); + +m\) relevant contacts, including a contact person for information security issues; + +n\) any screening requirements, where legally permissible, for the supplier’s personnel, including responsibilities for conducting the screening and notification procedures if screening has not been completed or if the results give cause for doubt or concern; + +o\) the evidence and assurance mechanisms of third-party attestations for relevant information security requirements related to the supplier processes and an independent report on effectiveness of controls; + +p\) right to audit the supplier processes and controls related to the agreement; + +q\) supplier’s obligation to periodically deliver a report on the effectiveness of controls and agreement on timely correction of relevant issues raised in the report; + +r\) defect resolution and conflict resolution processes; + +s\) providing backup aligned with the organization’s needs (in terms of frequency and type and storage location); + +t\) ensuring the availability of an alternate facility (i.e. disaster recovery site) not subject to the same threats as the primary facility and considerations for fall back controls (alternate controls) in the event primary controls fail; + +u\) having a change management process that ensures advance notification to the organization and the possibility for the organization of not accepting changes; + +v\) physical security controls commensurate with the information classification; + +w\) information transfer controls to protect the information during physical transfer or logical transmission; + +x\) termination clauses upon conclusion of the agreement including records management, return of assets, secure disposal of information and other associated assets, and any ongoing confidentiality obligations; + +y\) provision of a method of securely destroying the organization’s information stored by the supplier as soon as it is no longer required; + +z\) ensuring, at the end of the contract, handover support to another supplier or to the organization itself. + +The organization should establish and maintain a register of agreements with external parties (e.g. contracts, memorandum of understanding, information-sharing agreements) to keep track of where their information is going. The organization should also regularly review, validate and update their agreements with external parties to ensure they are still required and fit for purpose with relevant information security clauses. + +**Other information** + +The agreements can vary considerably for different organizations and among the different types of suppliers. Therefore, care should be taken to include all relevant requirements for addressing information security risks. + +For details on supplier agreements, see ISO/IEC 27036 series. For cloud service agreements, see ISO/IEC 19086 series. + +## 5.21 Managing information security in the ICT supply chain + +**Control** + +Processes and procedures should be defined and implemented to manage the information security risks associated with the ICT products and services supply chain. + +**Purpose** + +To maintain an agreed level of information security in supplier relationships. + +**Guidance** + +The following topics should be considered to address information security within ICT supply chain security in addition to the general information security requirements for supplier relationships: + +a\) defining information security requirements to apply to ICT product or service acquisition; + +b\) requiring that ICT services suppliers propagate the organization’s security requirements throughout the supply chain if they sub-contract for parts of the ICT service provided to the organization; + +c\) requiring that ICT products suppliers propagate appropriate security practices throughout the supply chain if these products include components purchased or acquired from other suppliers or other entities (e.g. sub-contracted software developers and hardware component providers); + +d\) requesting that ICT products suppliers provide information describing the software components used in products; + +e\) requesting that ICT products suppliers provide information describing the implemented security functions of their product and the configuration required for its secure operation; + +f\) implementing a monitoring process and acceptable methods for validating that delivered ICT products and services comply with stated security requirements. Examples of such supplier review methods can include penetration testing and proof or validation of third-party attestations for the supplier’s information security operations; + +g\) implementing a process for identifying and documenting product or service components that are critical for maintaining functionality and therefore require increased attention, scrutiny and further follow up required when built outside of the organization especially if the supplier outsources aspects of product or service components to other suppliers; + +h\) obtaining assurance that critical components and their origin can be traced throughout the supply chain; + +i\) obtaining assurance that the delivered ICT products are functioning as expected without any unexpected or unwanted features; + +j\) implementing processes to ensure that components from suppliers are genuine and unaltered from their specification. Example measures include anti-tamper labels, cryptographic hash verifications or digital signatures. Monitoring for out of specification performance can be an indicator of tampering or counterfeits. Prevention and detection of tampering should be implemented during multiple stages in the system development life cycle, including design, development, integration, operations and maintenance; + +k\) obtaining assurance that ICT products achieve required security levels, for example, through formal certification or an evaluation scheme such as the Common Criteria Recognition Arrangement; + +l\) defining rules for sharing of information regarding the supply chain and any potential issues and compromises among the organization and suppliers; + +m\) implementing specific processes for managing ICT component life cycle and availability and associated security risks. This includes managing the risks of components no longer being available due to suppliers no longer being in business or suppliers no longer providing these components due to technology advancements. Identification of an alternative supplier and the process to transfer software and competence to the alternative supplier should be considered. + +**Other information** + +The specific ICT supply chain risk management practices are built on top of general information security, quality, project management and system engineering practices but do not replace them. + +Organizations are advised to work with suppliers to understand the ICT supply chain and any matters that have an important effect on the products and services being provided. The organization can influence ICT supply chain information security practices by making clear in agreements with their suppliers the matters that should be addressed by other suppliers in the ICT supply chain. + +ICT should be acquired from reputable sources. The reliability of software and hardware is a matter of quality control. While it is generally not possible for an organization to inspect the quality control systems of its vendors, it can make reliable judgments based on the reputation of the vendor. + +ICT supply chain as addressed here includes cloud services. + +Examples of ICT supply chains are: + +a\) cloud services provisioning, where the cloud service provider relies on the software developers, telecommunication service providers, hardware providers; + +b\) IoT, where the service involves the device manufacturers, the cloud service providers (e.g. the IoT platform operators), the developers for mobile and web applications, the vendor of software libraries; + +c\) hosting services, where the provider relies on external service desks including first, second and third support levels. + +## 5.22 Monitoring, review and change management of supplier services + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +|--------------|----------------------------------------|-----------------------|-----------------------------------------|--------------------| +| #Preventive | #Confidentiality #Integrity #Availability | #Identify | #Supplier_relationships_security | #Governance_and_Ecosystem #Protection #Defence #Information_security_assurance | + +**Control** + +The organization should regularly monitor, review, evaluate and manage change in supplier information security practices and service delivery. + +**Purpose** + +To maintain an agreed level of information security and service delivery in line with supplier agreements. + +**Guidance** + +Monitoring, review and change management of supplier services should ensure the information security terms and conditions of the agreements are complied with, information security incidents and problems are managed properly and changes in supplier services or business status do not affect service delivery. + +This should involve a process to manage the relationship between the organization and the supplier to: + +a\) monitor service performance levels to verify compliance with the agreements; + +b\) monitor changes made by suppliers including: + +1\) enhancements to the current services offered; + +2\) development of any new applications and systems; + +3\) modifications or updates of the supplier’s policies and procedures; + +4\) new or changed controls to resolve information security incidents and to improve information security; + +c\) monitor changes in supplier services including: + +1\) changes and enhancement to networks; + +2\) use of new technologies; + +3\) adoption of new products or newer versions or releases; + +4\) new development tools and environments; + +5\) changes to physical location of service facilities; + +6\) change of sub-suppliers; + +7\) sub-contracting to another supplier; + +d\) review service reports produced by the supplier and arrange regular progress meetings as required by the agreements; + +e\) conduct audits of suppliers and sub-suppliers, in conjunction with review of independent auditor’s reports, if available and follow-up on issues identified; + +f\) provide information about information security incidents and review this information as required by the agreements and any supporting guidelines and procedures; + +g\) review supplier audit trails and records of information security events, operational problems, failures, tracing of faults and disruptions related to the service delivered; + +h\) respond to and manage any identified information security events or incidents; + +i\) identify information security vulnerabilities and manage them; + +j\) review information security aspects of the supplier’s relationships with its own suppliers; + +k\) ensure that the supplier maintains sufficient service capability together with workable plans designed to ensure that agreed service continuity levels are maintained following major service failures or disaster (see [[5.29]], [[5.30]], [[5.35]], [[5.36]], [[8.14]]; + +l\) ensure that suppliers assign responsibilities for reviewing compliance and enforcing the requirements of the agreements; + +m\) evaluate regularly that the suppliers maintain adequate information security levels. + +The responsibility for managing supplier relationships should be assigned to a designated individual or team. Sufficient technical skills and resources should be made available to monitor that the requirements of the agreement, in particular the information security requirements, are being met. Appropriate actions should be taken when deficiencies in the service delivery are observed. + +**Other information** + +See ISO/IEC 27036-3 for more detail. + +## 5.23 Information security for use of cloud services + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +|--------------|----------------------------------------|-----------------------|-----------------------------------------|--------------------| +| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Supplier_relationships_security | #Governance_and_Ecosystem #Protection | + +**Control** + +Processes for acquisition, use, management and exit from cloud services should be established in accordance with the organization’s information security requirements. + +**Purpose** + +To specify and manage information security for the use of cloud services. + +**Guidance** + +The organization should establish and communicate topic-specific policy on the use of cloud services to all relevant interested parties. + +The organization should define and communicate how it intends to manage information security risks associated with the use of cloud services. It can be an extension or part of the existing approach for how an organization manages services provided by external parties (see 5.21and 5.22). + +The use of cloud services can involve shared responsibility for information security and collaborative effort between the cloud service provider and the organization acting as the cloud service customer. It is essential that the responsibilities for both the cloud service provider and the organization, acting as the cloud service customer, are defined and implemented appropriately. + +The organization should define: + +a\) all relevant information security requirements associated with the use of the cloud services; + +b\) cloud service selection criteria and scope of cloud service usage; + +c\) roles and responsibilities related to the use and management of cloud services; + +d\) which information security controls are managed by the cloud service provider and which are managed by the organization as the cloud service customer; + +e\) how to obtain and utilize information security capabilities provided by the cloud service provider; + +f\) how to obtain assurance on information security controls implemented by cloud service providers; + +g\) how to manage controls, interfaces and changes in services when an organization uses multiple cloud services, particularly from different cloud service providers; + +h\) procedures for handling information security incidents that occur in relation to the use of cloud services; + +i\) its approach for monitoring, reviewing and evaluating the ongoing use of cloud services to manage information security risks; + +j\) how to change or stop the use of cloud services including exit strategies for cloud services. + +Cloud service agreements are often pre-defined and not open to negotiation. For all cloud services, the organization should review cloud service agreements with the cloud service provider(s). A cloud service agreement should address the confidentiality, integrity, availability and information handling requirements of the organization, with appropriate cloud service level objectives and cloud service qualitative objectives. The organization should also undertake relevant risk assessments to identify the risks associated with using the cloud service. Any residual risks connected to the use of the cloud service should be clearly identified and accepted by the appropriate management of the organization. + +An agreement between the cloud service provider and the organization, acting as the cloud service customer, should include the following provisions for the protection of the organization’s data and availability of services: + +a\) providing solutions based on industry accepted standards for architecture and infrastructure; + +b\) managing access controls of the cloud service to meet the requirements of the organization; + +c\) implementing malware monitoring and protection solutions; + +d\) processing and storing the organization’s sensitive information in approved locations (e.g. particular country or region) or within or subject to a particular jurisdiction; + +e\) providing dedicated support in the event of an information security incident in the cloud service environment; + +f\) ensuring that the organization’s information security requirements are met in the event of cloud services being further sub-contracted to an external supplier (or prohibiting cloud services from being sub-contracted); + +g\) supporting the organization in gathering digital evidence, taking into consideration laws and regulations for digital evidence across different jurisdictions; + +h\) providing appropriate support and availability of services for an appropriate time frame when the organization wants to exit from the cloud service; + +i\) providing required backup of data and configuration information and securely managing backups as applicable, based on the capabilities of the cloud service provider used by the organization, acting as the cloud service customer; + +j\) providing and returning information such as configuration files, source code and data that are owned by the organization, acting as the cloud service customer, when requested during the service provision or at termination of service. + +The organization, acting as the cloud service customer, should consider whether the agreement should require cloud service providers to provide advance notification prior to any substantive customer impacting changes being made to the way the service is delivered to the organization, including: + +a\) changes to the technical infrastructure (e.g. relocation, reconfiguration, or changes in hardware or software) that affect or change the cloud service offering; + +b\) processing or storing information in a new geographical or legal jurisdiction; + +c\) use of peer cloud service providers or other sub-contractors (including changing existing or using new parties). + +The organization using cloud services should maintain close contact with its cloud service providers. These contacts enable mutual exchange of information about information security for the use of the cloud services including a mechanism for both cloud service provider and the organization, acting as the cloud service customer, to monitor each service characteristic and report failures to the commitments contained in the agreements. + +**Other information** + +This control considers cloud security from the perspective of the cloud service customer. + +Additional information relating to cloud services can be found in ISO/IEC 17788, ISO/IEC 17789 and ISO/IEC 22123-1. Specifics related to cloud portability in support of exit strategies can be found in ISO/IEC 19941. Specifics related to information security and public cloud services are described in ISO/IEC 27017. Specifics related to PII protection in public clouds acting as PII processor are described in ISO/ IEC 27018. Supplier relationships for cloud services are covered by ISO/IEC 27036-4 and cloud service agreements and their contents are dealt with in the ISO/IEC 19086 series, with security and privacy specifically covered by ISO/IEC 19086-4. + +## 5.24 Information security incident management planning and preparation + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +|--------------|----------------------------------------|-----------------------|-----------------------------------------|--------------------| +| #Corrective | #Confidentiality #Integrity #Availability | #Respond #Recover | #Governance #Information_security_event_management | #Governance_and_Ecosystem #Protection | + +**Control** + +The organization should plan and prepare for managing information security incidents by defining, establishing and communicating information security incident management processes, roles and responsibilities. + +**Purpose** + +To ensure quick, effective, consistent and orderly response to information security incidents, including communication on information security events. + +**Guidance** + +Roles and responsibilities + +The organization should establish appropriate information security incident management processes. Roles and responsibilities to carry out the incident management procedures should be determined and effectively communicated to the relevant internal and external interested parties. + +The following should be considered: + +a\) establishing a common method for reporting information security events including point of contact (see 6.8); + +b\) establishing an incident management process to provide the organization with capability for managing information security incidents including administration, documentation, detection, triage, prioritization, analysis, communication and coordinating interested parties; + +c\) establishing an incident response process to provide the organization with capability for assessing, responding to and learning from information security incidents; + +d\) only allowing competent personnel to handle the issues related to information security incidents within the organization. Such personnel should be provided with procedure documentation and periodic training; + +e\) establishing a process to identify required training, certification and ongoing professional development for incident response personnel. + +Incident management procedures + +The objectives for information security incident management should be agreed with management and it should be ensured that those responsible for information security incident management understand the organization’s priorities for handling information security incidents including resolution time frame based on potential consequences and severity. Incident management procedures should be implemented to meet these objectives and priorities. + +Management should ensure that an information security incident management plan is created considering different scenarios and procedures are developed and implemented for the following activities: + +a\) evaluation of information security events according to criteria for what constitutes an information security incident; + +b\) monitoring (see 8.15 and 8.16), detecting (see 8.16), classifying (see 5.25), analysing and reporting (see 6.8) of information security events and incidents (by human or automatic means); + +c\) managing information security incidents to conclusion, including response and escalation (see 5.26), according to the type and the category of the incident, possible activation of crisis management and activation of continuity plans, controlled recovery from an incident and communication to internal and external interested parties; + +d\) coordination with internal and external interested parties such as authorities, external interest groups and forums, suppliers and clients (see 5.5and 5.6); + +e\) logging incident management activities; + +f\) handling of evidence (see 5.28); + +g\) root cause analysis or post-mortem procedures; + +h\) identification of lessons learned and any improvements to the incident management procedures or information security controls in general that are required. + +Reporting procedures + +Reporting procedures should include: + +a\) actions to be taken in case of an information security event (e.g. noting all pertinent details immediately such as malfunction occurring and messages on screen, immediately reporting to the point of contact and only taking coordinated actions); + +b\) use of incident forms to support personnel to perform all necessary actions when reporting information security incidents; + +c\) suitable feedback processes to ensure that those persons reporting information security events are notified, to the extent possible, of outcomes after the issue has been addressed and closed; + +d\) creation of incident reports. + +Any external requirements on reporting of incidents to relevant interested parties within the defined time frame (e.g. breach notification requirements to regulators) should be considered when implementing incident management procedures. + +**Other information** + +Information security incidents can transcend organizational and national boundaries. To respond to such incidents, it is beneficial to coordinate response and share information about these incidents with external organizations as appropriate. + +Detailed guidance on information security incident management is provided in the ISO/IEC 27035 series. + +## 5.25 Assessment and decision on information security events + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +| ------------ | ---------------------------------------- | --------------------- | ------------------------------- | ------------------ | +| #Detective | #Confidentiality #Integrity #Availability | #Detect #Respond | #Information_security_event_management | #Defence | + +**Control** + +The organization should assess information security events and decide if they are to be categorized as information security inciden ts. + +**Purpose** + +To ensure effective categorization and prioritization of information security events. + +**Guidance** + +A categorization and prioritization scheme of information security incidents should be agreed for the identification of the consequences and priority of an incident. The scheme should include the criteria to categorize events as information security incidents. The point of contact should assess each information security event using the agreed scheme. + +Personnel responsible for coordinating and responding to information security incidents should perform the assessment and make a decision on information security events. + +Results of the assessment and decision should be recorded in detail for the purpose of future reference and verification. + +**Other information** + +The ISO/IEC 27035 series provides further guidance on incident management. + +## 5.26 Response to information security incidents + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +| ------------ | ---------------------------------------- | --------------------- | ------------------------------- | ------------------ | +| #Corrective | #Confidentiality #Integrity #Availability | #Respond #Recover | #Information_security_event_management | #Defence | + +**Control** + +Information security incidents should be responded to in accordance with the documented procedures. + +**Purpose** + +To ensure efficient and effective response to information security incidents. +**Guidance** + +The organization should establish and communicate procedures on information security incident response to all relevant interested parties. + +Information security incidents should be responded to by a designated team with the required competency (see 5.24). + +The response should include the following: + +a\) containing, if the consequences of the incident can spread, the systems affected by the incident; + +b\) collecting evidence (see 5.28) as soon as possible after the occurrence; + +c\) escalation, as required including crisis management activities and possibly invoking business continuity plans (see 5.29and 5.30); + +d\) ensuring that all involved response activities are properly logged for later analysis; + +e\) communicating the existence of the information security incident or any relevant details thereof to all relevant internal and external interested parties following the need-to-know principle; + +f\) coordinating with internal and external parties such as authorities, external interest groups and forums, suppliers and clients to improve response effectiveness and help to minimize consequences for other organizations; + +g\) on ce the incident has been successfully addressed, formally closing and recording it; + +h\) conducting information security forensic analysis, as required (see 5.28); + +i\) performing post-incident analysis to identify root cause. Ensure it is documented and communicated according to defined procedures (see 5.27); + +j\) identifying and managing information security vulnerabilities and weaknesses including those related to controls which have caused, contributed to or failed to prevent the incident. + +**Other information** + +The ISO/IEC 27035 series provides further guidance on incident management. + +## 5.27 Learning from information security incidents + + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +| ------------ | ---------------------------------------- | --------------------- | ------------------------------- | ------------------ | +| #Preventive | #Confidentiality #Integrity #Availability | #Identify #Protect | #Information_security_event_management | #Defence | + +**Control** + +Knowledge gained from information security incidents should be used to strengthen and improve the information security controls. + +**Purpose** + +To reduce the likelihood or consequences of future incidents. **Guidance** + +The organization should establish procedures to quantify and monitor the types, volumes and costs of information security incidents. + +The information gained from the evaluation of information security incidents should be used to: + +a\) enhance the incident management plan including incident scenarios and procedures (see 5.24); + +b\) identify recurring or serious incidents and their causes to update the organization’s information security risk assessment and determine and implement necessary additional controls to reduce the likelihood or consequences of future similar incidents. Mechanisms to enable that include collecting, quantifying and monitoring information about incident types, volumes and costs; + +c\) enhance user awareness and training (see 6.3) by providing examples of what can happen, how to + +respond to such incidents and how to avoid them in the future. + +**Other information** + +The ISO/IEC 27035 series provides further guidance. + + + +## 5.28 Collection of evidence + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +| ------------ | ---------------------------------------- | --------------------- | ------------------------------- | ------------------ | +| #Corrective | #Confidentiality #Integrity #Availability | #Detect #Respond | #Information_security_event_management | #Defence | + +**Control** + +The organization should establish and implement procedures for the identification, collection, acquisition and preservation of evidence related to information security events. + +**Purpose** + +To ensure a consistent and effective management of evidence related to information security incidents for the purposes of disciplinary and legal actions. + +**Guidance** + +Internal procedures should be developed and followed when dealing with evidence related to information security events for the purposes of disciplinary and legal actions. The requirements of different jurisdictions should be considered to maximize chances of admission across the relevant jurisdictions. + +In general, these procedures for the management of evidence should provide instructions for the identification, collection, acquisition and preservation of evidence in accordance with different types of storage media, devices and status of devices (i.e. powered on or off). Evidence typically needs to be collected in a manner that is admissible in the appropriate national courts of law or another disciplinary forum. It should be possible to show that: + +a\) records are complete and have not been tampered with in any way; + +b\) copies of electronic evidence are probably identical to the originals; + +c\) any information system from which evidence has been gathered was operating correctly at the time the evidence was recorded. + +Where available, certification or other relevant means of qualification of personnel and tools should be sought, so as to strengthen the value of the preserved evidence. + +Digital evidence can transcend organizational or jurisdictional boundaries. In such cases, it should be ensured that the organization is entitled to collect the required information as digital evidence. + +**Other information** + +When an information security event is first detected, it is not always obvious whether or not the event will result in court action. Therefore, the danger exists that necessary evidence is destroyed intentionally or accidentally before the seriousness of the incident is realized. It is advisable to involve legal advice or law enforcement early in any contemplated legal action and take advice on the evidence required. + +ISO/IEC 27037 provides definitions and guidelines for identification, collection, acquisition and preservation of digital evidence. + +The ISO/IEC 27050 series deals with electronic discovery, which involves the processing of electronically stored information as evidence. + +## 5.29 Information security during disruption + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +| ------------ | ---------------------------------------- | --------------------- | ------------------------------- | ------------------ | +| #Preventive #Corrective | #Confidentiality #Integrity #Availability | #Protect #Respond | #Continuity | #Protection #Resilience | + + +**Control** + +The organization should plan how to maintain information security at an appropriate level during disruption. + +**Purpose** + +To protect information and other associated assets during disruption. + +**Guidance** + +The organization should determine its requirements for adapting information security controls during disruption. Information security requirements should be included in the business continuity management processes. + +Plans should be developed, implemented, tested, reviewed and evaluated to maintain or restore the security of information of critical business processes following interruption or failure. Security of information should be restored at the required level and in the required time frames. + +The organization should implement and maintain: + +a\) information security controls, supporting systems and tools within business continuity and ICT continuity plans; + +b\) processes to maintain existing information security controls during disruption; + +c\) compensating controls for information security controls that cannot be maintained during disruption. + +**Other information** + +In the context of business continuity and ICT continuity planning, it can be necessary to adapt the information security requirements depending on the type of disruption, compared to normal operational conditions. As part of the business impact analysis and risk assessment performed within business continuity management, the consequences of loss of confidentiality and integrity of information should be considered and prioritized in addition to the need for maintaining availability. + +Information on business continuity management systems can be found in ISO 22301 and ISO 22313. Further guidance on business impact analysis (BIA) can be found in ISO/TS 22317. + +## 5.30 ICT readiness for business continuity + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +| ------------ | ---------------------------------------- | --------------------- | ------------------------------- | ------------------ | +| #Corrective | #Availability | #Respond | #Continuity | #Resilience | + +**Control** + +ICT readiness should be planned, implemented, maintained and tested based on business continuity objectives and ICT continuity requirements. + +**Purpose** + +To ensure the availability of the organization’s information and other associated assets during disruption. + +**Guidance** + +ICT readiness for business continuity is an important component in business continuity management and information security management to ensure that the organization’s objectives can continue to be met during disruption. + +The ICT continuity requirements are the outcome of the business impact analysis (BIA). The BIA process should use impact types and criteria to assess the impacts over time resulting from the disruption of business activities that deliver products and services. The magnitude and duration of the resulting impact should be used to identify prioritized activities which should be assigned a recovery time objective (RTO). The BIA should then determine which resources are needed to support prioritized activities. An RTO should also be specified for these resources. A subset of these resources should include ICT services. + +The BIA involving ICT services can be expanded to define performance and capacity requirements of ICT systems and recovery point objectives (RPO) of information required to support activities during disruption. + +Based on the outputs from the BIA and risk assessment involving ICT services, the organization should identify and select ICT continuity strategies that consider options for before, during and after disruption. The business continuity strategies can comprise one or more solutions. Based on the strategies, plans should be developed, implemented and tested to meet the required availability level of ICT services and in the required time frames following interruption to, or failure of, critical processes. + +The organization should ensure that: + +a\) an adequate organizational structure is in place to prepare for, mitigate and respond to a disruption supported by personnel with the necessary responsibility, authority and competence; + +b\) ICT continuity plans, including response and recovery procedures detailing how the organization is planning to manage an ICT service disruption, are: + +1\) regularly evaluated through exercises and tests; + +2\) approved by management; + +c\) ICT continuity plans include the following ICT continuity information: + +1\) performance and capacity specifications to meet the business continuity requirements and objectives as specified in the BIA; + +2\) RTO of each prioritized ICT service and the procedures for restoring those components; + +3\) RPO of the prioritized ICT resources defined as information and the procedures for restoring the information. + +**Other information** + +Managing ICT continuity forms a key part of business continuity requirements concerning availability to be able to: + +a\) respond and recover from disruption to ICT services regardless of the cause; + +b\) ensure continuity of prioritized activities are supported by the required ICT services; + +c\) respond before a disruption to ICT services occurs, and upon detection of at least one incident that can result in a disruption to ICT services. + +Further guidance on ICT readiness for business continuity can be found in ISO/IEC 27031. + +Further guidance on business continuity management systems can be found in ISO 22301 and ISO 22313. Further guidance on BIA can be found in ISO/TS 22317. + +## 5.31 Legal, statutory, regulatory and contractual requirements + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +| ------------ | ---------------------------------------- | --------------------- | ------------------------- | -------------------------------------- | +| #Preventive | #Confidentiality #Integrity #Availability | #Identify | #Legal_and_compliance | #Governance_and_Ecosystem #Protection | + +**Control** + +Legal, statutory, regulatory and contractual requirements relevant to information security and the organization’s approach to meet these requirements should be identified, documented and kept up to date. + +**Purpose** + +To ensure compliance with legal, statutory, regulatory and contractual requirements related to information security. + +**Guidance** + +General + +External requirements including legal, statutory, regulatory or contractual requirements should be taken into consideration when: + +a\) developing information security policies and procedures; + +b\) designing, implementing or changing information security controls; + +c\) classifying information and other associated assets as part of the process for setting information security requirements for internal needs or for supplier agreements; + +d\) performing information security risk assessments and determining information security risk treatment activities; + +e\) determining processes along with related roles and responsibilities relating to information security; + +f\) determining suppliers’ contractual requirements relevant to the organization and the scope of supply of products and services. + +Legislation and regulations + +The organization should: + +a\) identify all legislation and regulations relevant to the organization’s information security in order + +to be aware of the requirements for their type of business; + +b\) take into consideration compliance in all relevant countries, if the organization: + +— conducts business in other countries; + +— uses products and services from other countries where laws and regulations can affect the organization; + +— transfers information across jurisdictional borders where laws and regulations can affect the organization; + +c\) review the identified legislation and regulation regularly in order to keep up to date with the changes and identify new legislation; + +d\) define and document the specific processes and individual responsibilities to meet these requirements. + +Cryptography + +Cryptography is an area that often has specific legal requirements. Compliance with the relevant agreements, laws and regulations relating to the following items should be taken into consideration: + +a\) restrictions on import or export of computer hardware and software for performing cryptographic functions; + +b\) restrictions on import or export of computer hardware and software which is designed to have cryptographic functions added to it; + +c\) restrictions on the usage of cryptography; + +d\) mandatory or discretionary methods of access by the countries’ authorities to encrypted information; + +e\) validity of digital signatures, seals and certificates. + +It is recommended to seek legal advice when ensuring compliance with relevant legislation and regulations, especially when encrypted information or cryptography tools are moved across jurisdictional borders. + +Contracts + +Contractual requirements related to information security should include those stated in: + +a\) contracts with clients; + +b\) contracts with suppliers (see 5.20); + +c\) insurance contracts. **Other information** + +No other information. + +## 5.32 Intellectual property rights + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +| ------------ | ---------------------------------------- | --------------------- | ------------------------- | -------------------------------------- | +| #Preventive | #Confidentiality #Integrity #Availability | #Identify | #Legal_and_compliance | #Governance_and_Ecosystem | + +**Control** + +The organization should implement appropriate procedures to protect intellectual property rights. + +**Purpose** + +To ensure compliance with legal, statutory, regulatory and contractual requirements related to intellectual property rights and use of proprietary products. + +The following guidelines should be considered to protect any material that can be considered intellectual property: + +a\) defining and communicating a topic-specific policy on protection of intellectual property rights; + +b\) publishing procedures for intellectual property rights compliance that define compliant use of software and information products; + +c\) acquiring software only through known and reputable sources, to ensure that copyright is not infringed upon; + +d\) maintaining appropriate asset registers and identifying all assets with requirements to protect intellectual property rights; + +e\) maintaining proof and evidence of ownership of licences, manuals, etc.; + +f\) ensuring that any maximum number of users or resources \[e.g. central processing units (CPUs)\] permitted within the licence is not exceeded; + +g\) carrying out reviews to ensure that only authorized software and licensed products are installed; + +h\) providing procedures for maintaining appropriate licence conditions; + +i\) providing procedures for disposing of or transferring software to others; + +j\) complying with terms and conditions for software and information obtained from public networks and outside sources; + +k\) not duplicating, converting to another format or extracting from commercial recordings (video, audio) other than permitted by copyright law or the applicable licences; + +l\) not copying, in full or in part, standards (e.g. ISO/IEC International Standards), books, articles, reports or other documents, other than permitted by copyright law or the applicable licences. + +**Other information** + +Intellectual property rights include software or document copyright, design rights, trademarks, patents and source code licences. + +Proprietary software products are usually supplied under a licence agreement that specifies licence terms and conditions, for example, limiting the use of the products to specified machines or limiting copying to the creation of backup copies only. See the ISO/IEC 19770 series for details about IT asset management. + +Data can be acquired from outside sources. It is generally the case that such data is obtained under the terms of a data sharing agreement or similar legal instrument. Such data sharing agreements should make it clear what processing is permitted for the acquired data. It is also advisable that the provenance of the data is clearly stated. See ISO/IEC 23751:—1) for details about data sharing agreements. + +Legal, statutory, regulatory and contractual requirements can place restrictions on the copying of proprietary material. In particular, they can require that only material that is developed by the organization or that is licensed or provided by the developer to the organization, can be used. Copyright infringement can lead to legal action, which can involve fines and criminal proceedings. + +Aside from the organization needing to comply with its obligations towards third party intellectual property rights, the risks of personnel and third parties failing to uphold the organization’s own intellectual property rights should also be managed. + +1\) Under preparation. Stage at the time of publication: ISO/IEC PRF 23751:2022. + +## 5.33 Protection of records + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +| ------------ | ---------------------------------------- | --------------------- | ------------------------- | -------------------------------------- | +| #Preventive | #Confidentiality #Integrity #Availability | #Identify #Protect | #Legal_and_compliance #Asset_management #Information_protection | #Defence | + +**Control** + +Records should be protected from loss, destruction, falsification, unauthorized access and unauthorized release. + +**Purpose** + +To ensure compliance with legal, statutory, regulatory and contractual requirements, as well as community or societal expectations related to the protection and availability of records. + +**Guidance** + +The organization should take the following steps to protect the authenticity, reliability, integrity and usability of records, as their business context and requirements for their management change over time: + +a\) issue guidelines on the storage, handling chain of custody and disposal of records, which includes prevention of manipulation of records. These guidelines should be aligned with the organization’s topic-specific policy on records management and other records requirements; + +b\) draw up a retention schedule defining records and the period of time for which they should be + +retained. + +The system of storage and handling should ensure identification of records and of their retention period taking into consideration national or regional legislation or regulations, as well as community or societal expectations, if applicable. This system should permit appropriate destruction of records after that period if they are not needed by the organization. + +When deciding on protection of specific organizational records, their corresponding information security classification, based on the organization’s classification scheme, should be considered. Records should be categorized into record types (e.g. accounting records, business transaction records, personnel records, legal records), each with details of retention periods and type of allowable storage media which can be physical or electronic. + +Data storage systems should be chosen such that required records can be retrieved in an acceptable time frame and format, depending on the requirements to be fulfilled. + +Where electronic storage media are chosen, procedures to ensure the ability to access records (both storage media and format readability) throughout the retention period should be established to safeguard against loss due to future technology change. Any related cryptographic keys and programs associated with encrypted archives or digital signatures, should also be retained to enable decryption of the records for the length of time the records are retained (see 8.24). + +Storage and handling procedures should be implemented in accordance with recommendations provided by manufacturers of storage media. Consideration should be given to the possibility of deterioration of media used for storage of records. + +**Other information** + +Records document individual events or transactions or can form aggregations that have been designed to document work processes, activities or functions. They are both evidence of business activity and information assets. Any set of information, regardless of its structure or form, can be managed as a record. This includes information in the form of a document, a collection of data or other types of digital or analogue information which are created, captured and managed in the course of business. + +In the management of records, metadata is data describing the context, content and structure of records, as well as their management over time. Metadata is an essential component of any record. + +It can be necessary to retain some records securely to meet legal, statutory, regulatory or contractual requirements, as well as to support essential business activities. National law or regulation can set the time period and data content for information retention. Further information about records management can be found in ISO 15489. + +## 5.34 Privacy and protection of PII + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +| ------------ | ---------------------------------------- | --------------------- | ------------------------- | -------------------------------------- | +| #Preventive | #Confidentiality #Integrity #Availability | #Identify #Protect | #Information_protection #Legal_and_compliance | #Protection | + +**Control** + +The organization should identify and meet the requirements regarding the preservation of privacy and protection of PII according to applicable laws and regulations and contractual requirements. + +**Purpose** + +To ensure compliance with legal, statutory, regulatory and contractual requirements related to the information security aspects of the protection of PII. + +**Guidance** + +The organization should establish and communicate a topic-specific policy on privacy and protection of PII to all relevant interested parties. + +The organization should develop and implement procedures for the preservation of privacy and protection of PII. These procedures should be communicated to all relevant interested parties involved in the processing of personally identifiable information. + +Compliance with these procedures and all relevant legislation and regulations concerning the preservation of privacy and protection of PII requires appropriate roles, responsibilities and controls. Often this is best achieved by the appointment of a person responsible, such as a privacy officer, who should provide guidance to personnel, service providers and other interested parties on their individual responsibilities and the specific procedures that should be followed. + +Responsibility for handling PII should be dealt with taking into consideration relevant legislation and regulations. + +Appropriate technical and organizational measures to protect PII should be implemented. + +**Other information** + +A number of countries have introduced legislation placing controls on the collection, processing, transmission and deletion of PII. Depending on the respective national legislation, such controls can impose duties on those collecting, processing and disseminating PII and can also restrict the authority to transfer PII to other countries. + +ISO/IEC 29100 provides a high-level framework for the protection of PII within ICT systems. Further information on privacy information management systems can be found in ISO/IEC 27701. Specific information regarding privacy information management for public clouds acting as PII processors can be found in ISO/IEC 27018. + +ISO/IEC 29134 provides guidelines for privacy impact assessment (PIA) and gives an example of the structure and content of a PIA report. Compared with ISO/IEC 27005, this is focused on PII processing and relevant to those organizations that process PII. This can help identify privacy risks and possible mitigations to reduce these risks to acceptable levels. + +## 5.35 Independent review of information security + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +| ------------ | ---------------------------------------- | --------------------- | ------------------------- | -------------------------------------- | +| #Preventive #Corrective | #Confidentiality #Integrity #Availability | #Identify #Protect | #Information_security_assurance | #Governance_and_Ecosystem | + +**Control** + +The organization’s approach to managing information security and its implementation including people, processes and technologies should be reviewed independently at planned intervals, or when significant changes occur. + +**Purpose** + +To ensure the continuing suitability, adequacy and effectiveness of the organization’s approach to managing information security. + +**Guidance** + +The organization should have processes to conduct independent reviews. + +Management should plan and initiate periodic independent reviews. The reviews should include assessing opportunities for improvement and the need for changes to the approach to information security, including the information security policy, topic-specific policies and other controls. + +Such reviews should be carried out by individuals independent of the area under review (e.g. the internal audit function, an independent manager or an external party organization specializing in such reviews). Individuals carrying out these reviews should have the appropriate competence. The person conducting the reviews should not be in the line of authority to ensure they have the independence to make an assessment. + +The results of the independent reviews should be reported to the management who initiated the reviews and, if appropriate, to top management. These records should be maintained. + +If the independent reviews identify that the organization’s approach and implementation to managing information security is inadequate \[e.g. documented objectives and requirements are not met or are not compliant with the direction for information security stated in the information security policy and topic-specific policies (see 5.1)\], management should initiate corrective actions. + +In addition to the periodic independent reviews, the organization should consider conducting independent reviews when: + +a\) laws and regulations which affect the organization change; + +b\) significant incidents occur; + +c\) the organization starts a new business or changes a current business; + +d\) the organization starts to use a new product or service, or changes the use of a current product or service; + +e\) the organization changes the information security controls and procedures significantly. + +ISO/IEC 27007 and ISO/IEC TS 27008 provide guidance for carrying out independent reviews. + +## 5.36 Compliance with policies, rules and standards for information security + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +| ------------ | ---------------------------------------- | --------------------- | ------------------------- | -------------------------------------- | +| #Preventive | #Confidentiality #Integrity #Availability | #Identify #Protect | #Legal_and_compliance #Information_security_assurance | #Governance_and_Ecosystem | + +**Control** + +Compliance with the organization’s information security policy, topic-specific policies, rules and standards should be regularly reviewed. + +**Purpose** + +To ensure that information security is implemented and operated in accordance with the organization’s information security policy, topic-specific policies, rules and standards. + +**Guidance** + +Managers, service, product or information owners should identify how to review that information security requirements defined in the information security policy, topic-specific policies, rules, standards and other applicable regulations are met. Automatic measurement and reporting tools should be considered for efficient regular review. + +If any non-compliance is found as a result of the review, managers should: + +a\) identify the causes of the non-compliance; + +b\) evaluate the need for corrective actions to achieve compliance; + +c\) implement appropriate corrective actions; + +d\) review corrective actions taken to verify its effectiveness and identify any deficiencies or weaknesses. + +Results of reviews and corrective actions carried out by managers, service, product or information owners should be recorded and these records should be maintained. Managers should report the results to the persons carrying out independent reviews (see 5.35) when an independent review takes place in the area of their responsibility. + +Corrective actions should be completed in a timely manner as appropriate to the risk. If not completed by the next scheduled review, progress should at least be addressed at that review. + +**Other information** + +Operational monitoring of system use is covered in 8.15, 8.16, 8.17. + +## 5.37 Documented operating procedures + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +|-------------------------|------------------------------------------|-----------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------| +| #Preventive #Corrective | #Confidentiality #Integrity #Availability | #Protect #Recover | #Asset_management #Physical_security #System_and_network_security #Application_security #Secure_configuration #Identity_and_access_management #Threat_and_vulnerability_management #Continuity #Information_security_event_management | #Governance_and_Ecosystem #Protection #Defence | + +**Control** + +Operating procedures for information processing facilities should be documented and made available to personnel who need them. + +**Purpose** + +To ensure the correct and secure operation of information processing facilities. + +**Guidance** + +Documented procedures should be prepared for the organization’s operational activities associated with information security, for example: + +a\) when the activity needs to be performed in the same way by many people; + +b\) when the activity is performed rarely and when next performed the procedure is likely to have been forgotten; + +c\) when the activity is new and presents a risk if not performed correctly; + +d\) prior to handing over the activity to new personnel. The operating procedures should specify: + +a\) the responsible individuals; + +b\) the secure installation and configuration of systems; + +c\) processing and handling of information, both automated and manual; + +d\) backup (see 8.13) and resilience; + +e\) scheduling requirements, including interdependencies with other systems; + +f\) instructions for handling errors or other exceptional conditions \[e.g. restrictions on the use of + +utility programs (see 8.18)\], which can arise during job execution; + +g\) support and escalation contacts including external support contacts in the event of unexpected + +operational or technical difficulties; + +h\) storage media handling instructions (see 7.10and 7.14); + +i\) system restart and recovery procedures for use in the event of system failure; + +j\) the management of audit trail and system log information (see 8.15and 8.17) and video monitoring systems (see 7.4); + +k\) monitoring procedures such as capacity, performance and security (see 8.6 and 8.16); + +l\) maintenance instructions. + +Documented operating procedures should be reviewed and updated when needed. Changes to documented operating procedures should be authorized. Where technically feasible, information systems should be managed consistently, using the same procedures, tools and utilities. + +**Other information** +No other information. + +# 6 People controls + +## 6.1 Screening + +| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | +|------------------|------------------------------------|---------------------------|-------------------------------|---------------------------| +| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Human_resource_security | #Governance_and_Ecosystem | + +**Control** + +Background verification checks on all candidates to become personnel should be carried out prior to joining the organization and on an ongoing basis taking into consideration applicable laws, regulations and ethics and be proportional to the business requirements, the classification of the information to be accessed and the perceived risks. + +**Purpose** + +To ensure all personnel are eligible and suitable for the roles for which they are considered and remain eligible and suitable during their employment. + +**Guidance** + +A screening process should be performed for all personnel including full-time, part-time and temporary staff. Where these individuals are contracted through suppliers of services, screening requirements should be included in the contractual agreements between the organization and the suppliers. + +Information on all candidates being considered for positions within the organization should be collected and handled taking into consideration any appropriate legislation existing in the relevant jurisdiction. In some jurisdictions, the organization can be legally required to inform the candidates beforehand about the screening activities. + +Verification should take into consideration all relevant privacy, PII protection and employment-based legislation and should, where permitted, include the following: + +a\) availability of satisfactory references (e.g. business and personal references); + +b\) a verification (for completeness and accuracy) of the applicant’s curriculum vitae; + +c\) confirmation of claimed academic and professional qualifications; + +d\) independent identity verification (e.g. passport or other acceptable document issued by appropriate authorities); + +e\) more detailed verification, such as credit review or review of criminal records if the candidate takes on a critical role. + +When an individual is hired for a specific information security role, the organization should make sure the candidate: + +a\) has the necessary competence to perform the security role; + +b\) can be trusted to take on the role, especially if the role is critical for the organization. + +Where a job, either on initial appointment or on promotion, involves the person having access to information processing facilities and, in particular, if these involve handling confidential information (e.g. financial information, personal information or health care information) the organization should also consider further, more detailed verifications. + +Procedures should define criteria and limitations for verification reviews (e.g. who is eligible to screen people and how, when and why verification reviews are carried out). + +In situations where verification cannot be completed in a timely manner, mitigating controls should be implemented until the review has been finished, for example: + +a\) delayed onboarding; + +b\) delayed deployment of corporate assets; + +c\) onboarding with reduced access; + +d\) termination of employment. + +Verification checks should be repeated periodically to confirm ongoing suitability of personnel, depending on the criticality of a person’s role. + +**Other information** No other information. + +## 6.2 Terms and conditions of employment + +| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | +|------------------|------------------------------------|---------------------------|------------------------------|----------------------| +| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Human_resource_security | #Governance_and_Ecosystem | + +**Control** + +The employment contractual agreements should state the personnel’s and the organization’s responsibilities for information security. + +**Purpose** + +To ensure personnel understand their information security responsibilities for the roles for which they are considered. + +**Guidance** + +The contractual obligations for personnel should take into consideration the organization’s information security policy and relevant topic-specific policies. In addition, the following points can be clarified and stated: + +a\) confidentiality or non-disclosure agreements that personnel who are given access to confidential information should sign prior to being given access to information and other associated assets (see 6.6); + +b\) legal responsibilities and rights \[e.g. regarding copyright laws or data protection legislation (see 5.32 and 5.34)\]; + +c\) responsibilities for the classification of information and management of the organization’s information and other associated assets, information processing facilities and information services handled by the personnel (see 5.9to 5.13); + +d\) responsibilities for the handling of information received from interested parties; + +e\) actions to be taken if personnel disregard the organization’s security requirements (see 6.4). + +Information security roles and responsibilities should be communicated to candidates during the pre- employment process. + +The organization should ensure that personnel agree to terms and conditions concerning information security. These terms and conditions should be appropriate to the nature and extent of access they will have to the organization’s assets associated with information systems and services. The terms and conditions concerning information security should be reviewed when laws, regulations, the information security policy or topic-specific policies change. + +Where appropriate, responsibilities contained within the terms and conditions of employment should continue for a defined period after the end of the employment (see 6.5). + +**Other information** + +A code of conduct can be used to state personnel’s information security responsibilities regarding confidentiality, PII protection, ethics, appropriate use of the organization’s information and other associated assets, as well as reputable practices expected by the organization. + +An external party, with which supplier personnel are associated, can be required to enter into contractual agreements on behalf of the contracted individual. + +If the organization is not a legal entity and does not have employees, the equivalent of contractual agreement and terms and conditions can be considered in line with the guidance of this control. + +## 6.3 Information security awareness, education and training + +| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | +|------------------|-----------------------------------------|---------------------------|-----------------------------|-----------------------------| +| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Human_resource_security | #Governance_and_Ecosystem | + +**Control** +Personnel of the organization and relevant interested parties should receive appropriate information security awareness, education and training and regular updates of the organization's information security policy, topic-specific policies and procedures, as relevant for their job function. + +**Purpose** +To ensure personnel and relevant interested parties are aware of and fulfil their information security responsibilities. + +**Guidance** + +General + +An information security awareness, education and training programme should be established in line with the organization’s information security policy, topic-specific policies and relevant procedures on information security, taking into consideration the organization’s information to be protected and the information security controls that have been implemented to protect the information. + +Information security awareness, education and training should take place periodically. Initial awareness, education and training can apply to new personnel and to those who transfer to new positions or roles with substantially different information security requirements. + +Personnel’s understanding should be assessed at the end of an awareness, education or training activity to test knowledge transfer and the effectiveness of the awareness, education and training programme. + +Awareness + +An information security awareness programme should aim to make personnel aware of their responsibilities for information security and the means by which those responsibilities are discharged. + +The awareness programme should be planned taking into consideration the roles of personnel in the organization, including internal and external personnel (e.g. external consultants, supplier personnel). The activities in the awareness programme should be scheduled over time, preferably regularly, so that the activities are repeated and cover new personnel. It should also be built on lessons learnt from information security incidents. + +The awareness programme should include a number of awareness-raising activities via appropriate physical or virtual channels such as campaigns, booklets, posters, newsletters, websites, information sessions, briefings, e-learning modules and e-mails. + +Information security awareness should cover general aspects such as: + +a\) management’s commitment to information security throughout the organization; + +b\) familiarity and compliance needs concerning applicable information security rules and obligations, taking into account information security policy and topic-specific policies, standards, laws, statutes, regulations, contracts and agreements; + +c\) personal accountability for one’s own actions and inactions, and general responsibilities towards securing or protecting information belonging to the organization and interested parties; + +d\) basic information security procedures \[e.g. information security event reporting (6.8)\] and baseline controls \[e.g. password security (5.17)\]; + +e\) contact points and resources for additional information and advice on information security matters, including further information security awareness materials. + +Education and training + +The organization should identify, prepare and implement an appropriate training plan for technical teams whose roles require specific skill sets and expertise. Technical teams should have the skills for configuring and maintaining the required security level for devices, systems, applications and services. If there are missing skills, the organization should take action and acquire them. + +The education and training programme should consider different forms \[e.g. lectures or self-studies, being mentored by expert staff or consultants (on-the-job training), rotating staff members to follow different activities, recruiting already skilled people and hiring consultants\]. It can use different means of delivery including classroom-based, distance learning, web-based, self-paced and others. Technical personnel should keep their knowledge up to date by subscribing to newsletters and magazines or by attending conferences and events aimed at technical and professional improvement. + +**Other information** +When composing an awareness programme, it is important not only to focus on the ’what’ and ’how’, but also the ’why’, when possible. It is important that personnel understand the aim of information security and the potential effect, positive and negativ e, on the organization of their own behaviour. + +Information security awareness, education and training can be part of, or conducted in collaboration with, other activities, for exa mple general information management, ICT, security, privacy or safety training. + +## 6.4 Disciplinary process + +| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | +|----------------------------|-----------------------------------------|---------------------------|-------------------------------|-----------------------------| +| #Preventive #Corrective | #Confidentiality #Integrity #Availability | #Protect #Respond | #Human_resource_security | #Governance_and_Ecosystem | + +**Control** + +A disciplinary process should be formalized and communicated to take actions against personnel and other relevant interested parties who have committed an information security policy violation. + +**Purpose** + +To ensure personnel and other relevant interested parties understand the consequences of information security policy violation, to deter and appropriately deal with personnel and other relevant interested parties who committed the violation. + +**Guidance** + +The disciplinary process should not be initiated without prior verification that an information security policy violation has occurred (see 5.28). + +The formal disciplinary process should provide for a graduated response that takes into consideration factors such as: + +a\) the nature (who, what, when, how) and gravity of the breach and its consequences; + +b\) whether the offence was intentional (malicious) or unintentional (accidental); + +c\) whether or not this is a first or repeated offence; + +d\) whether or not the violator was properly trained. + +The response should take into consideration relevant legal, statutory, regulatory contractual and business requirements as well as other factors as required. The disciplinary process should also be used as a deterrent to prevent personnel and other relevant interested parties from violating the information security policy, topic-specific policies and procedures for information security. Deliberate information security policy violations can require immediate actions. + +**Other information** + +Where possible, the identity of individuals subject to disciplinary action should be protected in line with applicable requirements. + +When individuals demonstrate excellent behaviour with regard to information security, they can be rewarded to promote information security and encourage good behaviour. + + +## 6.5 Responsibilities after termination or change of employment + +| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | +|------------------|-----------------------------------------|---------------------------|---------------------------------------------|------------------------------| +| #Preventive | #Confidentiality #Integrity #Availability | + +**Control** + +Information security responsibilities and duties that remain valid after termination or change of employment should be defined, enforced and communicated to relevant personnel and other interested parties. + +**Purpose** + +To protect the organization’s interests as part of the process of changing or terminating employment or contracts. + +**Guidance** + +The process for managing termination or change of employment should define which information security responsibilities and duties should remain valid after termination or change. This can include confidentiality of information, intellectual property and other knowledge obtained, as well as responsibilities contained within any other confidentiality agreement (see 6.6). Responsibilities and duties still valid after termination of employment or contract should be contained in the individual’s terms and conditions of employment (see 6.2), contract or agreement. Other contracts or agreements that continue for a defined period after the end of the individual’s employment can also contain information security responsibilities. + +Changes of responsibility or employment should be managed as the termination of the current responsibility or employment combined with the initiation of the new responsibility or employment. + +Information security roles and responsibilities held by any individual who leaves or changes job roles should be identified and transferred to another individual. + +A process should be established for the communication of the changes and of operating procedures to personnel, other interested parties and relevant contact persons (e.g. to customers and suppliers). + +The process for the termination or change of employment should also be applied to external personnel (i.e. suppliers) when a termination occurs of personnel, the contract or the job with the organization, or when there is a change of the job within the organization. + +**Other information** + +In many organizations, the human resources function is generally responsible for the overall termination process and works together with the supervising manager of the person transitioning to manage the information security aspects of the relevant procedures. In the case of personnel provided through an external party (e.g. through a supplier), this termination process is undertaken by the external party in accordance with the contract between the organization and the external party. + +## 6.6 Confidentiality or non-disclosure agreements + +| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | +|------------------|------------------------------------|---------------------------|-------------------------------------------------------------|-------------------------------| +| #Preventive | #Confidentiality | #Protect | #Human_resource_security #Information_protection #Supplier_relationships | #Governance_and_Ecosystem | + +**Control** +Confidentiality or non-disclosure agreements reflecting the organization’s needs for the protection of information should be identified, documented, regularly reviewed and signed by personnel and other relevant interested parties. + +**Purpose** + +To maintain confidentiality of information accessible by personnel or external parties. + +**Guidance** + +Confidentiality or non-disclosure agreements should address the requirement to protect confidential information using legally enforceable terms. Confidentiality or non-disclosure agreements are applicable to interested parties and personnel of the organization. Based on an organization’s information security requirements, the terms in the agreements should be determined by taking into consideration the type of information that will be handled, its classification level, its use and the permissible access by the other party. To identify requirements for confidentiality or non-disclosure agreements, the following elements should be considered: + +a\) a definition of the information to be protected (e.g. confidential information); + +b\) the expected duration of an agreement, including cases where it can be necessary to maintain confidentiality indefinitely or until the information becomes publicly available; + +c\) the required actions when an agreement is terminated; + +d\) the responsibilities and actions of signatories to avoid unauthorized information disclosure; + +e\) the ownership of information, trade secrets and intellectual property, and how this relates to the protection of confidential information; + +f\) the permitted use of confidential information and rights of the signatory to use the information; + +g\) the right to audit and monitor activities that involve confidential information for highly sensitive circumstances; + +h\) the process for notification and reporting of unauthorized disclosure or confidential information leakage; + +i\) the terms for information to be returned or destroyed at agreement termination; + +j\) the expected actions to be taken in the case of non-compliance with the agreement. + +The organization should take into consideration the compliance with confidentiality and non-disclosure agreements for the jurisdiction to which they apply (see 5.31, 5.32, 5.33, 5.34). + +Requirements for confidentiality and non-disclosure agreements should be reviewed periodically and when changes occur that influence these requirements. + +**Other information** + +Confidentiality and non-disclosure agreements protect the organization's information and inform signatories of their responsibility to protect, use and disclose information in a responsible and authorized manner. + + +## 6.7 Remote working + +| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | +|------------------|-----------------------------------------|---------------------------|--------------------------------------------------------------------------------|---------------------| +| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Asset_management #Information_protection #Physical_security #System_and_network_security | #Protection | + +**Control** + +Security measures should be implemented when personnel are working remotely to protect information accessed, processed or stored outside the organization’s premises. + +**Purpose** + +To ensure the security of information when personnel are working remotely. + +**Guidance** + +Remote working occurs whenever personnel of the organization work from a location outside of the organization’s premises, accessing information whether in hardcopy or electronically via ICT equipment. Remote working environments include those referred to as “teleworking”, “telecommuting”, “flexible workplace”, “virtual work environments" and “remote maintenance”. + +NOTE It is possible that not all the recommendations in this guidance can be applied due to local legislation and regulations in different jurisdictions. + +Organizations allowing remote working activities should issue a topic-specific policy on remote working that defines the relevant conditions and restrictions. Where deemed applicable, the following matters should be considered: + +a\) the existing or proposed physical security of the remote working site, taking into account the physical security of the location and the local environment, including the different jurisdictions where personnel are located; + +b\) rules and security mechanisms for the remote physical environment such as lockable filing cabinets, secure transportation between locations and rules for remote access, clear desk, printing and disposal of information and other associated assets, and information security event reporting (see 6.8); + +c\) the expected physical remote working environments; + +d\) the communications security requirements, taking into account the need for remote access to the organization’s systems, the sensitivity of the information to be accessed and passed over the communication link and the sensitivity of the systems and applications; + +e\) the use of remote access such as virtual desktop access that supports processing and storage of information on privately owned equipment; + +f\) the threat of unauthorized access to information or resources from other persons at the remote working site (e.g. family and friends); + +g\) the threat of unauthorized access to information or resources from other persons in public places; + +h\) the use of home networks and public networks, and requirements or restrictions on the configuration of wireless network services; + +i\) use of security measures, such as firewalls and protection against malware; + +j\) secure mechanisms for deploying and initializing systems remotely; + +k\) sec ure mechanisms for authentication and enablement of access privileges taking into consideration the vulnerability of single-factor authentication mechanisms where remote access to the organization’s network is allowed. + +The guidelines and measures to be considered should include: + +a\) the provision of suitable equipment and storage furniture for the remote working activities, where the use of privately-owned equipment that is not under the control of the organization is not allowed; + +b\) a definition of the work permitted, the classification of information that can be held and the internal systems and services that the remote worker is authorized to access; + +c\) the provision of training for those working remotely and those providing support. This should include how to conduct business in a secure manner while working remotely; + +d\) the provision of suitable communication equipment, including methods for securing remote access, such as requirements on device screen locks and inactivity timers; the enabling of device location tracking; installation of remote wipe capabilities; + +e\) physical security; + +f\) rules and guidance on family and visitor access to equipment and information; + +g\) the provision of hardware and software support and maintenance; + +h\) the provision of insurance; + +i\) the procedures for backup and business continuity; + +j\) audit and security monitoring; + +k\) revocation of authority and access rights and the return of equipment when the remote working activities are terminated. + +**Other information** No other information. + +## 6.8 Information security event reporting + +| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | +|------------------|-----------------------------------------|---------------------------|---------------------------------------------|---------------------| +| #Detective | #Confidentiality #Integrity #Availability | #Detect | #Information_security_event_management | #Defence | + +**Control** + +The organization should provide a mechanism for personnel to report observed or suspected information security events through appropriate channels in a timely manner. + +**Purpose** + +To support timely, consistent and effective reporting of information security events that can be identified by personnel. + +**Guidance** + +All personnel and users should be made aware of their responsibility to report information security events as quickly as possible in order to prevent or minimize the effect of information security incidents. + +They should also be aware of the procedure for reporting information security events and the point of contact to which the events should be reported. The reporting mechanism should be as easy, accessible and available as possible. Information security events include incidents, breaches and vulnerabilities. + +Situations to be considered for information security event reporting include: + +a\) ineffective information security controls; + +b\) breach of information confidentiality, integrity or availability expectations; + +c\) human errors; + +d\) non-compliance with the information security policy, topic-specific policies or applicable standards; + +e\) breaches of physical security measures; + +f\) system changes that have not gone through the change management process; + +g\) malfunctions or other anomalous system behaviour of software or hardware; + +h\) access violations; + +i\) vulnerabilities; + +j\) suspected malware infection. + +Personnel and users should be advised not to attempt to prove suspected information security vulnerabilities. Testing vulnerabilities can be interpreted as a potential misuse of the system and can also cause damage to the information system or service, and it can corrupt or obscure digital evidence. Ultimately, this can result in legal liability for the individual performing the testing. + +**Other information** + +See the ISO/IEC 27035 series for additional information. + +# 7 Physical controls + +## 7.1 Physical security perimeters + +| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | +|------------------|-----------------------------------------|---------------------------|-----------------------------------|---------------------| +| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Physical_security | + +**Control** + +Security perimeters should be defined and used to protect areas that contain information and other associated assets. + +**Purpose** + +To prevent unauthorized physical access, damage and interference to the organization’s information and other associated assets. + +**Guidance** + +The following guidelines should be considered and implemented where appropriate for physical security perimeters: + +a\) defining security perimeters and the siting and strength of each of the perimeters in accordance with the information security requirements related to the assets within the perimeter; + +b\) having physically sound perimeters for a building or site containing information processing facilities (i.e. there should be no gaps in the perimeter or areas where a break-in can easily occur). The exterior roofs, walls, ceilings and flooring of the sit e should be of solid construction and all external doors should be suitably protected against unauthorized access with control mechanisms (e.g. bars, alarms, locks). Doors and windows should be locked when unattended and external protection should be considered for windows, particularly at ground level; ventilation points should also be considered; + +c\) alarming, monitoring and testing all fire doors on a security perimeter in conjunction with the walls to establish the required level of resistance in accordance with suitable standards. They should operate in a failsafe manner. + +**Other information** + +Physical protection can be achieved by creating one or more physical barriers around the organization’s premises and information processing facilities. + +A secure area can be a lockable office or several rooms surrounded by a continuous internal physical security barrier. Additional barriers and perimeters to control physical access can be necessary between areas with different security requirements inside the security perimeter. The organization should consider having physical security measures that can be strengthened during increased threat situations. + +## 7.2 Physical entry + +| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | +|------------------|-----------------------------------------|---------------------------|-----------------------------------------------------|---------------------| +| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Physical_security #Identity_and_Access + +**Control** + +Secure areas should be protected by appropriate entry controls and access points. + +**Purpose** + +To ensure only authorized physical access to the organization’s information and other associated assets occurs. + +**Guidance** + +General + +Access points such as delivery and loading areas and other points where unauthorized persons can enter the premises should be controlled and, if possible, isolated from information processing facilities to avoid unauthorized access. + +The following guidelines should be considered: + +a\) restricting access to sites and buildings to authorized personnel only. The process for the management of access rights to physical areas should include the provision, periodical review, update and revocation of authorizations (see 5.18); + +b\) securely maintaining and monitoring a physical logbook or electronic audit trail of all access and protecting all logs (see 5.33) and sensitive authentication information; + +c\) establishing and implementing a process and technical mechanisms for the management of access to areas where information is processed or stored. Authentication mechanisms include the use of access cards, biometrics or two-factor authentication such as an access card and secret PIN. Double security doors should be considered for access to sensitive areas; + +d\) setting up a reception area monitored by personnel, or other means to control physical access to the site or building; + +e\) inspecting and examining personal belongings of personnel and interested parties upon entry and exit; + +NOTE Local legislation and regulations can exist regarding the possibility of inspecting personal belongings. + +f\) requiring all personnel and interested parties to wear some form of visible identification and to immediately notify security personnel if they encounter unescorted visitors and anyone not wearing visible identification. Easily distinguishable badges should be considered to better identify permanent employees, suppliers and visitors; + +g\) granting supplier personnel restricted access to secure areas or information processing facilities only when required. This access should be authorized and monitored; + +h\) giving special attention to physical access security in the case of buildings holding assets for multiple organizations; + +i\) designing physical security measures so that they can be strengthened when the likelihood of physical incidents increases; + +j\) securing other entry points such as emergency exits from unauthorized access; + +k\) setting up a key management process to ensure the management of the physical keys or authentication information (e.g. lock codes, combination locks to offices, rooms and facilities such as key cabinets) and to ensure a log book or annual key audit and that access to physical keys or authentication information is controlled (see 5.17for further guidance on authentication information). + +Visitors + +The following guidelines should be considered: + +a\) authenticating the identity of visitors by an appropriate means; + +b\) recording the date and time of entry and departure of visitors; + +c\) only granting access for visitors for specific, authorized purposes and with instructions on the security requirements of the area and on emergency procedures; + +d\) supervising all visitors, unless an explicit exception is granted. Delivery and loading areas and incoming material + +The following guidelines should be considered: + +a\) restricting access to delivery and loading areas from outside of the building to identified and authorized personnel; + +b\) designing the delivery and loading areas so that deliveries can be loaded and unloaded without delivery personnel gaining unauthorized access to other parts of the building; + +c\) securing the external doors of delivery and loading areas when doors to restricted areas are opened; + +d\) inspecting and examining incoming deliveries for explosives, chemicals or other hazardous materials before they are moved from delivery and loading areas; + +e\) registering incoming deliveries in accordance with asset management procedures (see 5.9 and 7.10) on entry to the site; + +f\) physically segregating incoming and outgoing shipments, where possible; + +g\) inspecting incoming deliveries for evidence of tampering on the way. If tampering is discovered, it should be immediately reported to security personnel. + +**Other information** +No other information. + +## 7.3 Securing offices, rooms and facilities + +| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | +|------------------|-----------------------------------------|---------------------------|--------------------------------------|---------------------| +| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Physical_security
#Asset_management | #Protection | + +**Control** + +Physical security for offices, rooms and facilities should be designed and implemented. **Purpose** + +To prevent unauthorized physical access, damage and interference to the organization’s information and other associated assets in offices, rooms and facilities. + +**Guidance** + +The following guidelines should be considered to secure offices, rooms and facilities: + +a\) siting critical facilities to avoid access by the public; + +b\) where applicable, ensuring buildings are unobtrusive and give minimum indication of their purpose, with no obvious signs, outside or inside the building, identifying the presence of information processing activities; + +c\) configuring facilities to prevent confidential information or activities from being visible and audible from the outside. Electromagnetic shielding should also be considered as appropriate; + +d\) not making directories, internal telephone books and online accessible maps identifying locations of confidential information processing facilities readily available to any unauthorized person. + +**Other information** +No other information. + +## 7.4 Physical security monitoring + +| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | +|----------------------------|-----------------------------------------|---------------------------|-----------------------------|---------------------------| +| #Preventive #Detective | #Confidentiality #Integrity #Availability | #Protect #Detect | #Physical_security | #Protection #Defence | + +**Control** + +Premises should be continuously monitored for unauthorized physical access. + +**Purpose** + +To detect and deter unauthorized physical access. + +**Guidance** + +Physical premises should be monitored by surveillance systems, which can include guards, intruder alarms, video monitoring systems such as closed-circuit television and physical security information management software either managed internally or by a monitoring service provider. + +Access to buildings that house critical systems should be continuously monitored to detect unauthorized access or suspicious behaviour by: + +a\) installing video monitoring systems such as closed-circuit television to view and record access to sensitive areas within and outside an organization’s premises; + +b\) installing, according to relevant applicable standards, and periodically testing contact, sound or motion detectors to trigger an intruder alarm such as: + +1\) installing contact detectors that trigger an alarm when a contact is made or broken in any place where a contact can be made or broken (such as windows and doors and underneath objects) to be used as a panic alarm; + +2\) motion detectors based on infra-red technology which trigger an alarm when an object passes through their field of view; + +3\) installing sensors sensitive to the sound of breaking glass which can be used to trigger an alarm to alert security personnel; + +c\) using those alarms to cover all external doors and accessible windows. Unoccupied areas should be alarmed at all times; cover should also be provided for other areas (e.g. computer or communications rooms). + +The design of monitoring systems should be kept confidential because disclosure can facilitate undetected break-ins. + +Monitoring systems should be protected from unauthorized access in order to prevent surveillance information, such as video feeds, from being accessed by unauthorized persons or systems being disabled remotely. + +The alarm system control panel should be placed in an alarmed zone and, for safety alarms, in a place that allows an easy exit route for the person who sets the alarm. The control panel and the detectors should have tamperproof mechanisms. The system should regularly be tested to ensure that it is working as intended, particularly if its components are battery powered. + +Any monitoring and recording mechanism should be used taking into consideration local laws and regulations including data protection and PII protection legislation, especially regarding the monitoring of personnel and recorded video retention periods. + +**Other information** +No other information. + +## 7.5 Protecting against physical and environmental threats + +| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | +|------------------|-----------------------------------------|---------------------------|-----------------------------|----------------------| +| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Physical_security | #Protection | + +**Control** + +Protection against physical and environmental threats, such as natural disasters and other intentional or unintentional physical threats to infrastructure should be designed and implemented. + +**Purpose** + +To prevent or reduce the consequences of events originating from physical and environmental threats. **Guidance** + +Risk as sessments to identify the potential consequences of physical and environmental threats should be performed prior to beginning critical operations at a physical site, and at regular intervals. Necessary safeguards should be implemented and changes to threats should be monitored. Specialist advice should be obtained on how to manage risks arising from physical and environ mental threats such as fire, flood, earthquake, explosion, civil unrest, toxic waste, environmental emissions and other forms of natural disaster or disaster caused by human beings. + +Physical premises location and construction should take account of: + +a\) local topography, such as appropriate elevation, bodies of water and tectonic fault lines; + +b\) urban threats, such as locations with a high profile for attracting political unrest, criminal activity or terrorist attacks. + +Based on risk assessment results, relevant physical and environmental threats should be identified and appropriate controls considered in the following contexts as examples: + +a\) fire: installing and configuring systems able to detect fires at an early stage to send alarms or trigger fire suppression systems in order to prevent fire damage to storage media and to related information processing systems. Fire suppression should be performed using the most appropriate substance with regard to the surrounding environment (e.g. gas in confined spaces); + +b\) flooding: installing systems able to detect flooding at an early stage under the floors of areas containing storage media or information processing systems. Water pumps or equivalent means should be readily made available in case flooding occurs; + +c\) electrical surges: adopting systems able to protect both server and client information systems against electrical surges or similar events to minimize the consequences of such events; + +d\) explosives and weapons: performing random inspections for the presence of explosives or weapons on personnel, vehicles or goods entering sensitive information processing facilities. + +**Other information** + +Safes or other forms of secure storage facilities can protect information stored therein against disasters such as a fire, earthquake, flood or explosion. + +Organizations can consider the concepts of crime prevention through environmental design when designing the controls to secure their environment and reduce urban threats. For example, instead of using bollards, statues or water features can serve as both a feature and a physical barrier. + +## 7.6 Working in secure areas + +| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | +|------------------|-----------------------------------------|---------------------------|-----------------------------|----------------------| +| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Physical_security | #Protection | + +**Control** + +Security measures for working in secure areas should be designed and implemented. +**Purpose** + +To protect information and other associated assets in secure areas from damage and unauthorized interference by personnel working in these areas. + +**Guidance** + +The security measures for working in secure areas should apply to all personnel and cover all activities taking place in the secure area. + +The following guidelines should be considered: + +a\) making personnel aware only of the existence of, or activities within, a secure area on a need-to-know basis; + +b\) avoiding unsupervised work in secure areas both for safety reasons and to reduce chances for malicious activities; + +c\) physically locking and periodically inspecting vacant secure areas; + +d\) not allowing photographic, video, audio or other recording equipment, such as cameras in user endpoint devices, unless authorized; + +e\) appropriately controlling the carrying and use of user endpoint devices in secure areas; + +f\) posting emergency procedures in a readily visible or accessible manner. + +**Other information** +No other information. + +## 7.7 Clear desk and clear screen + +| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | +|------------------|------------------------------------|---------------------------|-----------------------------|----------------------| +| #Preventive | #Confidentiality | #Protect | #Physical_security | #Protection | +**Control** + +Clear desk rules for papers and removable storage media and clear screen rules for information processing facilities should be defined and appropriately enforced. + +**Purpose** + +To reduce the risks of unauthorized access, loss of and damage to information on desks, screens and in other accessible locations during and outside normal working hours. + +**Guidance** + +The organization should establish and communicate a topic-specific policy on clear desk and clear screen to all relevant interested parties. + +The following guidelines should be considered: + +a\) locking away sensitive or critical business information (e.g. on paper or on electronic storage media) (ideally in a safe, cabinet or other form of security furniture) when not required, especially when the office is vacated; + +b\) protecting user endpoint devices by key locks or other security means when not in use or unattended; + +c\) leaving user endpoint devices logged off or protected with a screen and keyboard locking mechanism controlled by a user authentication mechanism when unattended. All computers and systems should be configured with a timeout or automatic logout feature ; + +d\) making the originator collect outputs from printers or multi-function devices immediately. The use of printers with an authent ication function, so the originators are the only ones who can get their printouts and only when standing next to the printer; + +e\) securely storing documents and removable storage media containing sensitive information and, when no longer required, discarding them using secure disposal mechanisms; + +f\) establishing and communicating rules and guidance for the configuration of pop-ups on screens (e.g. turning off the new email and messaging pop-ups, if possible, during presentations, screen sharing or in a public area); + +g\) clearing sensitive or critical information on whiteboards and other types of display when no longer required. + +The organization should have procedures in place when vacating facilities including conducting a final sweep prior to leaving to ensure the organization’s assets are not left behind (e.g. documents fallen behind drawers or furniture). + +**Other information** +No other information. + +## 7.8 Equipment siting and protection + +| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | +|------------------|-----------------------------------------|---------------------------|----------------------------------------|---------------------| +| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Physical_security #Asset_management | #Protection | + +**Control** + +Equipment should be sited securely and protected. + +**Purpose** + +To reduce the risks from physical and environmental threats, and from unauthorized access and damage. + +**Guidance** + +The following guidelines should be considered to protect equipment: + +a\) siting equipment to minimize unnecessary access into work areas and to avoid unauthorized access; + +b\) carefully positioning information processing facilities handling sensitive data to reduce the risk of information being viewed by unauthorized persons during their use; + +c\) adopting controls to minimize the risk of potential physical and environmental threats \[e.g. theft, fire, explosives, smoke, water (or water supply failure), dust, vibration, chemical effects, electrical supply interference, communications interference, electromagnetic radiation and vandalism\]; + +d\) establishing guidelines for eating, drinking and smoking in proximity to information processing facilities; + +e\) monitoring environmental conditions, such as temperature and humidity, for conditions which can adversely affect the operation of information processing facilities; + +f\) applying lightning protection to all buildings and fitting lightning protection filters to all incoming power and communications lines; + +g\) considering the use of special protection methods, such as keyboard membranes, for equipment in industrial environments; + +h\) protecting equipment processing confidential information to minimize the risk of information leakage due to electromagnetic emanation; + +i\) physically separating information processing facilities managed by the organization from those not managed by the organization. + +**Other information** +No other information. + +## 7.9 Security of assets off-premises + +| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | +|------------------|-----------------------------------------|---------------------------|----------------------------------------|---------------------| +| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Physical_security #Asset_management | #Protection | +**Control** + +Off-site assets should be protected. **Purpose** + +To prevent loss, damage, theft or compromise of off-site devices and interruption to the organization’s operations. + +**Guidance** + +Any device used outside the organization’s premises which stores or processes information (e.g. mobile device), including devices owned by the organization and devices owned privately and used on behalf of the organization \[bring your own device (BYOD)\] needs protection. The use of these devices should be authorized by management. + +The following guidelines should be considered for the protection of devices which store or process information outside the organization’s premises: + +a\) not leaving equipment and storage media taken off premises unattended in public and unsecured places; + +b\) observing manufacturers’ instructions for protecting equipment at all times (e.g. protection against exposure to strong electromagnetic fields, water, heat, humidity, dust); + +c\) when off-premises equipment is transferred among different individuals or interested parties, maintaining a log that defines the chain of custody for the equipment including at least names and organizations of those who are responsible for the equipment. Information that does not need to be transferred with the asset should be securely deleted before the transfer; + +d\) where necessary and practical, requiring authorization for equipment and media to be removed from the organization’s premises and keeping a record of such removals in order to maintain an audit trail (see 5.14); + +e\) protecting against viewing information on a device (e.g. mobile or laptop) on public transport, and the risks associated with shoulder surfing; + +f\) implementing location tracking and ability for remote wiping of devices. + +Permanent installation of equipment outside the organization’s premises \[such as antennas and automated teller machines (ATMs)\] can be subject to higher risk of damage, theft or eavesdropping. These risks can vary considerably between locations and should be taken into account in determining the most appropriate measures. The following guidelines should be considered when siting this equipment outside of the organization’s premises: + +a\) physical security monitoring (see 7.4); + +b\) protecting against physical and environmental threats (see 7.5); + +c\) physical access and tamper proofing controls; + +d\) logical access controls. + +**Other information** + +More information about other aspects of protecting information storing and processing equipment and user endpoint devices can be found in 8.1and 6.7. + +## 7.10 Storage media + +| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | +|------------------|-----------------------------------------|---------------------------|---------------------------------------------|---------------------| +| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Physical_security #Asset_management | #Protection | + +**Control** + +Storage media should be managed through their life cycle of acquisition, use, transportation and disposal in accordance with the organization’s classification scheme and handling requirements. + +**Purpose** + +To ensure only authorized disclosure, modification, removal or destruction of information on storage media. + +**Guidance** + +Removable storage media + +The following guidelines for the management of removable storage media should be considered: + +a\) establishing a topic-specific policy on the management of removable storage media and communicating such topic-specific policy to anyone who uses or handles removable storage media; + +b\) where necessary and practical, requiring authorization for storage media to be removed from the organization and keeping a record of such removals in order to maintain an audit trail; + +c\) storing all storage media in a safe, secure environment according to their information classification and protecting them against environmental threats (such as heat, moisture, humidity, electronic field or ageing), in accordance with manufacturers’ specifications; + +d\) if information confidentiality or integrity are important considerations, using cryptographic techniques to protect information on removable storage media; + +e\) to mitigate the risk of storage media degrading while stored information is still needed, transferring the information to fresh storage media before becoming unreadable; + +f\) storing multiple copies of valuable information on separate storage media to further reduce the risk of coincidental information damage or loss; + +g\) considering the registration of removable storage media to limit the chance for information loss; + +h\) only enabling removable storage media ports \[e.g. secure digital (SD) card slots and universal serial bus (USB) ports\] if there is an organizational reason for their use; + +i\) where there is a need to use removable storage media, monitoring the transfer of information to such storage media; + +j\) information can be vulnerable to unauthorized access, misuse or corruption during physical transport, for instance when sending storage media via the postal service or via courier. + +In this control, media includes paper documents. When transferring physical storage media, apply security measures in 5.14. + +Secure reuse or disposal + +Procedures for the secure reuse or disposal of storage media should be established to minimize the risk of confidential information leakage to unauthorized persons. The procedures for secure reuse or disposal of storage media containing confidential information should be proportional to the sensitivity of that information. The following items should be considered: + +a\) if storage media containing confidential information need to be reused within the organization, securely deleting data or formatting the storage media before reuse (see 8.10); + +b\) disposing of storage media containing confidential information securely when not needed anymore (e.g. by destroying, shredding or securely deleting the content); + +c\) having procedures in place to identify the items that can require secure disposal; + +d\) many organizations offer collection and disposal services for storage media. Care should be taken in selecting a suitable external party supplier with adequate controls and experience; + +e\) logging the disposal of sensitive items in order to maintain an audit trail; + +f\) when accumulating storage media for disposal, giving consideration to the aggregation effect, which can cause a large quantity of non-sensitive information to become sensitive. + +A risk assessment should be performed on damaged devices containing sensitive data to determine whether the items should be physically destroyed rather than sent for repair or discarded (see 7.14). + +**Other information** +When confidential information on storage media is not encrypted, additional physical protection of the storage media should be considered. + +## 7.11 Supporting utilities + +| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | +|-----------------------|------------------------------------|---------------------------|-----------------------------|----------------------| +| #Preventive
#Detective | #Integrity
#Availability | #Protect #Detect | #Physical_security | #Protection | + +**Control** + +Information processing facilities should be protected from power failures and other disruptions caused by failures in supporting utilities. + +**Purpose** + +To prevent loss, damage or compromise of information and other associated assets, or interruption to the organization’s operations due to failure and disruption of supporting utilities. + +**Guidance** + +Organizations depend on utilities (e.g. electricity, telecommunications, water supply, gas, sewage, ventilation and air conditioning) to support their information processing facilities. Therefore, the organization should: + +a\) ensure equipment supporting the utilities is configured, operated and maintained in accordance with the relevant manufacturer’s specifications; + +b\) ensure utilities are appraised regularly for their capacity to meet business growth and interactions with other supporting utilities; + +c\) ensure equipment supporting the utilities is inspected and tested regularly to ensure their proper functioning; + +d\) if necessary, raise alarms to detect utilities malfunctions; + +e\) if necessary, ensure utilities have multiple feeds with diverse physical routing; + +f\) ensure equipment supporting the utilities is on a separate network from the information processing facilities if connected to a network; + +g\) ensure equipment supporting the utilities is connected to the internet only when needed and only in a secure manner. + +Emergency lighting and communications should be provided. Emergency switches and valves to cut off power, water, gas or other utilities should be located near emergency exits or equipment rooms. Emergency contact details should be recorded and available to personnel in the event of an outage. + +**Other information** + +Additional redundancy for network connectivity can be obtained by means of multiple routes from more than one utility provider. + +## 7.12 Cabling security + +| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | +|------------------|------------------------------------|---------------------------|-----------------------------|----------------------| +| #Preventive | #Confidentiality #Availability | #Protect | #Physical_security | #Protection | + +**Control** + +Cables carrying power, data or supporting information services should be protected from interception, interference or damage. + +**Purpose** + +To prevent loss, damage, theft or compromise of information and other associated assets and interruption to the organization’s operations related to power and communications cabling. + +**Guidance** + +The following guidelines for cabling security should be considered: + +a\) power and telecommunications lines into information processing facilities being underground where possible, or subject to adequate alternative protection, such as floor cable protector and utility pole; if cables are underground, protecting them from accidental cuts (e.g. with armoured conduits or signals of presence); + +b\) segregating power cables from communications cables to prevent interference; + +c\) for sensitive or critical systems, further controls to consider include: + +1\) installation of armoured conduit and locked rooms or boxes and alarms at inspection and termination points; + +2\) use of electromagnetic shielding to protect the cables; + +3\) periodical technical sweeps and physical inspections to detect unauthorized devices being attached to the cables; + +4\) controlled access to patch panels and cable rooms (e.g. with mechanical keys or PINs); + +5\) use of fibre-optic cables; + +d\) labelling cables at each end with sufficient source and destination details to enable the physical identification and inspection of the cable. + +Specialist advice should be sought on how to manage risks arising from cabling incidents or malfunctions. + +**Other information** + +Sometimes power and telecommunications cabling are shared resources for more than one organization occupying co-located premises. + +## 7.13 Equipment maintenance + +| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | +|------------------|-----------------------------------------|---------------------------|----------------------------------------|---------------------------| +| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Physical_security #Asset_management | #Protection #Resilience | + +**Control** + +Equipment should be maintained correctly to ensure availability, integrity and confidentiality of information. + +**Purpose** + +To prevent loss, damage, theft or compromise of information and other associated assets and interruption to the organization’s operations caused by lack of maintenance. + +**Guidance** + +The following guidelines for equipment maintenance should be considered: + +a\) maintaining equipment in accordance with the supplier’s recommended service frequency and specifications; + +b\) implementing and monitoring of a maintenance programme by the organization; + +c\) only authorized maintenance personnel carrying out repairs and maintenance on equipment; + +d\) keeping records of all suspected or actual faults, and of all preventive and corrective maintenance; + +e\) implementing appropriate controls when equipment is scheduled for maintenance, taking into account whether this maintenance is performed by personnel on site or external to the organization; subjecting the maintenance personnel to a suitable confidentiality agreement; + +f\) supervising maintenance personnel when carrying out maintenance on site; + +g\) authorizing and controlling access for remote maintenance; + +h\) applying security measures for assets off-premises (see 7.9) if equipment containing information is taken off premises for maintenance; + +i\) complying with all maintenance requirements imposed by insurance; + +j\) before putting equipment back into operation after maintenance, inspecting it to ensure that the equipment has not been tampered with and is functioning properly; + +k\) applying measures for secure disposal or re-use of equipment (see 7.14) if it is determined that equipment is to be disposed of. + +**Other information** + +Equipment includes technical components of information processing facilities, uninterruptible power supply (UPS) and batteries, power generators, power alternators and converters, physical intrusion detection systems and alarms, smoke detectors, fire extinguishers, air conditioning and lifts. + +## 7.14 Secure disposal or re-use of equipment + +| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | +|------------------|------------------------------------|---------------------------|----------------------------------------|---------------------------| +| #Preventive | #Confidentiality | #Protect | #Physical_security #Asset_management | #Protection | + +**Control** + +Items of equipment containing storage media should be verified to ensure that any sensitive data and licensed software has been removed or securely overwritten prior to disposal or re-use. + +**Purpose** + +To prevent leakage of information from equipment to be disposed or re-used. **Guidance** + +Equipment should be verified to ensure whether or not storage media is contained prior to disposal or re-use. + +Storage media containing confidential or copyrighted information should be physically destroyed or the information should be destroyed, deleted or overwritten using techniques to make the original information non-retrievable rather than using the standard delete function. See 7.10for detailed guidance on secure disposal of storage media and 8.10for guidance on information deletion. + +Labels and markings identifying the organization or indicating the classification, owner, system or network, should be removed prior to disposal, including reselling or donating to charity. + +The organization should consider the removal of security controls such as access controls or surveillance equipment at the end of lease or when moving out of premises. This depends on factors such as: + +a\) its lease agreement to return the facility to original condition; + +b\) minimizing the risk of leaving systems with sensitive information on them for the next tenant (e.g. user access lists, video or image files); + +c\) the ability to reuse the controls at the next facility. + +**Other information** + +Damaged equipment containing storage media can require a risk assessment to determine whether the items should be physically destroyed rather than sent for repair or discarded. Information can be compromised through careless disposal or re-use of equipment. + +In addition to secure disk deletion, full-disk encryption reduces the risk of disclosure of confidential information when equipment is disposed of or redeployed, provided that: + +a\) the encryption process is sufficiently strong and covers the entire disk (including slack space, swap files); + +b\) the cryptographic keys are long enough to resist brute force attacks; + +c\) the cryptographic keys are themselves kept confidential (e.g. never stored on the same disk). For further advice on cryptography, see 8.24. + +Techniques for securely overwriting storage media differ according to the storage media technology and the classification level of the information on the storage media. Overwriting tools should be reviewed to make sure that they are applicable to the technology of the storage media. + +See ISO/IEC 27040 for detail on methods for sanitizing storage media. + +# 8 Technological controls + +## 8.1 User endpoint devices + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +| -------------- | ---------------------------------------- | --------------------- | ----------------------------------------- | --------------- | +| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Asset_management
#Information_protection | #Protection | + +**Control** +Information stored on, processed by or accessible via user endpoint devices should be protected. + +**Purpose** +To protect information against the risks introduced by using user endpoint devices. + +**Guidance** + +General + +The organization should establish a topic-specific policy on secure configuration and handling of user endpoint devices. The topic-specific policy should be communicated to all relevant personnel and consider the following: + +a\) the type of information and the classification level that the user endpoint devices can handle, process, store or support; + +b\) registration of user endpoint devices; + +c\) requirements for physical protection; + +d\) restriction of software installation (e.g. remotely controlled by system administrators); + +e\) requirements for user endpoint device software (including software versions) and for applying updates (e.g. active automatic updating); + +f\) rules for connection to information services, public networks or any other network off premises (e.g. requiring the use of personal firewall); + +g\) access controls; + +h\) storage device encryption; + +i\) protection against malware; + +j\) remote disabling, deletion or lockout; + +k\) backups; + +l\) usage of web services and web applications; + +m\) end user behaviour analytics (see 8.16); + +n\) the use of removable devices, including removable memory devices, and the possibility of disabling physical ports (e.g. USB ports); + +o\) the use of partitioning capabilities, if supported by the user endpoint device, which can securely separate the organization's information and other associated assets (e.g. software) from other information and other associated assets on the device. + +Consideration should be given as to whether certain information is so sensitive that it can only be accessed via user endpoint devices, but not stored on such devices. In such cases, additional technical safeguards can be required on the device. For example, ensuring that downloading files for offline working is disabled and that local storage such as SD card is disabled. + +As far as possible, the recommendations on this control should be enforced through configuration management (see 8.9) or automated tools. + +User responsibility + +All users should be made aware of the security requirements and procedures for protecting user endpoint devices, as well as of their responsibilities for implementing such security measures. Users should be advised to: + +a\) log-off active sessions and terminate services when no longer needed; + +b\) protect user endpoint devices from unauthorized use with a physical control (e.g. key lock or special locks) and logical control (e.g. password access) when not in use; not leave devices carrying important, sensitive or critical business information unattended; + +c\) use devices with special care in public places, open offices, meeting places and other unprotected areas (e.g. avoid reading confidential information if people can read from the back, use privacy screen filters); + +d\) physically protect user endpoint devices against theft (e.g. in cars and other forms of transport, hotel rooms, conference centres and meeting places). + +A specific procedure taking into account legal, statutory, regulatory, contractual (including insurance) and other security requirements of the organization should be established for cases of theft or loss of user endpoint devices. + +Use of personal devices + +Where the organization allows the use of personal devices (sometimes known as BYOD), in addition to the guidance given in this control, the following should be considered: + +a\) separation of personal and business use of the devices, including using software to support such separation and protect business data on a private device; + +b\) providing access to business information only after users have acknowledged their duties (physical protection, software updating, etc.), waiving ownership of business data, allowing remote wiping of data by the organization in case of theft or loss of the device or when no longer authorized to use the service. In such cases, PII protection legislation should be considered; + +c\) topic-specific policies and procedures to prevent disputes concerning rights to intellectual property developed on privately owned equipment; + +d\) access to privately owned equipment (to verify the security of the machine or during an investigation), which can be prevented by legislation; + +e\) software licensing agreements that are such that organizations can become liable for licensing for client software on user endpoint devices owned privately by personnel or external party users. + +Wireless connections + +The organization should establish procedures for: + +a\) the configuration of wireless connections on devices (e.g. disabling vulnerable protocols); + +b\) using wireless or wired connections with appropriate bandwidth in accordance with relevant topic-specific policies (e.g. because backups or software updates are needed). + +**Other information** + +Controls to protect information on user endpoint devices depend on whether the user endpoint device is used only inside of the organization's secured premises and network connections, or whether it is exposed to increased physical and network related threats outside of the organization. + +The wireless connections for user endpoint devices are similar to other types of network connections but have important differences that should be considered when identifying controls. In particular, back-up of information stored on user endpoint devices can sometimes fail because of limited network bandwidth or because user endpoint devices are not connected at the times when backups are scheduled. + +For some USB ports, such as USB-C, disabling the USB port is not possible because it is used for other purposes (e.g. power delivery and display output). + +## 8.2 Privileged access rights + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +| -------------- | ---------------------------------------- | --------------------- | ------------------------------- | --------------- | +| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Identity_and_access_management | #Protection | + +**Control** + +The allocation and use of privileged access rights should be restricted and managed. + +**Purpose** + +To ensure only authorized users, software components and services are provided with privileged access rights. + +**Guidance** + +The allocation of privileged access rights should be controlled through an authorization process in accordance with the relevant topic-specific policy on access control (see 5.15). The following should be considered: + +a\) identifying users who need privileged access rights for each system or process (e.g. operating systems, database management systems and applications); + +b\) allocating privileged access rights to users as needed and on an event-by-event basis in line with the topic-specific policy on access control (see 5.15) (i.e. only to individuals with the necessary competence to carry out activities that require privileged access and based on the minimum requirement for their functional roles); + +c\) maintaining an authorization process (i.e. determining who can approve privileged access rights, or not granting privileged access rights until the authorization process is complete) and a record of all privileges allocated; + +d\) defining and implementing requirements for expiry of privileged access rights; + +e\) taking measures to ensure that users are aware of their privileged access rights and when they are in privileged access mode. Possible measures include using specific user identities, user interface settings or even specific equipment; + +f\) authentication requirements for privileged access rights can be higher than the requirements for normal access rights. Re-authentication or authentication step-up can be necessary before doing work with privileged access rights; + +g\) regularly, and after any organizational change, reviewing users working with privileged access rights in order to verify if their duties, roles, responsibilities and competence still qualify them for working with privileged access rights (see 5.18); + +h\) establishing specific rules in order to avoid the use of generic administration user IDs (such as “root”), depending on systems’ configuration capabilities. Managing and protecting authentication information of such identities (see 5.17); + +i\) granting temporary privileged access just for the time window necessary to implement approved changes or activities (e.g. for maintenance activities or some critical changes), rather than permanently granting privileged access rights. This is often referred as break glass procedure, and often automated by privilege access management technologies; + +j\) logging all privileged access to systems for audit purposes; + +k\) not sharing or linking identities with privileged access rights to multiple persons, assigning each person a separate identity which allows assigning specific privileged access rights. Identities can be grouped (e.g. by defining an administrator group) in order to simplify the management of privileged access rights; + +l\) only using identities with privileged access rights for undertaking administrative tasks and not for day-to-day general tasks \[i.e. checking email, accessing the web (users should have a separate normal network identity for these activities)\]. + +**Other information** + +Privileged access rights are access rights provided to an identity, a role or a process that allows the performance of activities that typical users or processes cannot perform. System administrator roles typically require privileged access rights. + +Inappropriate use of system administrator privileges (any feature or facility of an information system that enables the user to override system or application controls) is a major contributory factor to failures or breaches of systems. + +More information related to access management and the secure management of access to information and information and communications technologies resources can be found in ISO/IEC 29146. + +## 8.3 Information access restriction + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +| -------------- | ---------------------------------------- | --------------------- | ------------------------------- | --------------- | +| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Identity_and_access_management | #Protection | + +**Control** +Access to information and other associated assets should be restricted in accordance with the established topic-specific policy on access control. + +**Purpose** +To ensure only authorized access and to prevent unauthorized access to information and other associated assets. + +**Guidance** +Access to information and other associated assets should be restricted in accordance with the established topic-specific policies. The following should be considered in order to support access restriction requirements: + +a\) not allowing access to sensitive information by unknown user identities or anonymously. Public or anonymous access should only be granted to storage locations that do not contain any sensitive information; + +b\) providing configuration mechanisms to control access to information in systems, applications and services; + +c\) controlling which data can be accessed by a particular user; + +d\) controlling which identities or group of identities have which access, such as read, write, delete and execute; + +e\) providing physical or logical access controls for the isolation of sensitive applications, application data, or systems. + +Further, dynamic access management techniques and processes to protect sensitive information that has high value to the organization should be considered when the organization: + +a\) needs granular control over who can access such information during what period and in what way; + +b\) wants to share such information with people outside the organization and maintain control over who can access it; + +c\) wants to dynamically manage, in real-time, the use and distribution of such information; + +d\) wants to protect such information against unauthorized changes, copying and distribution (including printing); + +e\) wants to monitor the use of the information; + +f\) wants to record any changes to such information that take place in case a future investigation is required. + +Dynamic access management techniques should protect information throughout its life cycle (i.e. creation, processing, storage, transmission and disposal), including: + +a\) establishing rules on the management of dynamic access based on specific use cases considering: + +1\) granting access permissions based on identity, device, location or application; + +2\) leveraging the classification scheme in order to determine what information needs to be protected with dynamic access management techniques; + +b\) establishing operational, monitoring and reporting processes and supporting technical infrastructure. + +Dynamic access management systems should protect information by: + +a\) requiring authentication, appropriate credentials or a certificate to access information; + +b\) restricting access, for example to a specified time frame (e.g. after a given date or until a particular date); + +c\) using encryption to protect information; + +d\) defining the printing permissions for the information; + +e\) recording who accesses the information and how the information is used; + +f\) raising alerts if attempts to misuse the information are detected. + +**Other information** + +Dynamic access management techniques and other dynamic information protection technologies can support the protection of information even when data is shared beyond the originating organization, where traditional access controls cannot be enforced. It can be applied to documents, emails or other files containing information to limit who can access the content and in what way. It can be at a granular level and be adapted over the life cycle of the information. + +Dynamic access management techniques do not replace classical access management \[e.g. using access control lists (ACLs)\], but can add more factors for conditionality, real-time evaluation, just-in-time data reduction and other enhancements that can be useful for the most sensitive information. It offers a way to control access outside the organization’s environment. Incident response can be supported by dynamic access management techniques as permissions can be modified or revoked at any time. + +Additional information on a framework for access management is provided in ISO/IEC 29146. + +## 8.4 Access to source code + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +| -------------- | ---------------------------------------- | --------------------- | ------------------------------------------------------------- | --------------- | +| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Identity_and_access_management #Application_security #Secure_configuration | #Protection | + +**Control** +Read and write access to source code, development tools and software libraries should be appropriately managed. + +**Purpose** +To prevent the introduction of unauthorized functionality, avoid unintentional or malicious changes and to maintain the confidentiality of valuable intellectual property. + +**Guidance** +Access to source code and associated items (such as designs, specifications, verification plans and validation plans) and development tools (e.g. compilers, builders, integration tools, test platforms and environments) should be strictly controlled. + +For source code, this can be achieved by controlling central storage of such code, preferably in source code management system. + +Read access and write access to source code can differ based on the personnel’s role. For example, read access to source code can be broadly provided inside the organization, but write access to source code is only made available to privileged personnel or designated owners. Where code components are used by several developers within an organization, read access to a centralized code repository should be implemented. Furthermore, if open-source code or third-party code components are used inside an organization, read access to such external code repositories can be broadly provide d. However, write access should still be restricted. + +The following guidelines should be considered to control access to program source libraries in order to reduce the potential for corruption of computer programs: + +a\) managing the access to program source code and the program source libraries according to established procedures; + +b\) granting read and write access to source code based on business needs and managed to address risks of alteration or misuse and according to established procedures; + +c\) updating of source code and associated items and granting of access to source code in accordance with change control procedures (see 8.32) and only performing it after appropriate authorization has been received; + +d\) not granting developers direct access to the source code repository, but through developer tools that control activities and authorizations on the source code; + +e\) holding program listings in a secure environment, where read and write access should be appropriately managed and assigned; + +f\) maintaining an audit log of all accesses and of all changes to source code. + +If the program source code is intended to be published, additional controls to provide assurance on its integrity (e.g. digital signature) should be considered. + +**Other information** + +If access to source code is not properly controlled, source code can be modified or some data in the development environment (e.g. copies of production data, configuration details) can be retrieved by unauthorized persons. + +## 8.5 Secure authentication + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +| ------------ | ---------------------------------------- | --------------------- | ------------------------------- | --------------- | +| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Identity_and_access_management | #Protection | + +**Control** + +Secure authentication technologies and procedures should be implemented based on information access restrictions and the topic-specific policy on access control. + +**Purpose** + +To ensure a user or an entity is securely authenticated, when access to systems, applications and services is granted. + +**Guidance** + +A suitable authentication technique should be chosen to substantiate the claimed identity of a user, software, messages and other entities. + +The strength of authentication should be appropriate for the classification of the information to be accessed. Where strong authentication and identity verification is required, authentication methods alternative to passwords, such as digital certificates, smart cards, tokens or biometric means, should be used. + +Authentication information should be accompanied by additional authentication factors for accessing critical information systems (also known as multi-factor authentication). Using a combination of multiple authentication factors, such as what you know, what you have and what you are, reduces the possibilities for unauthorized accesses. Multi-factor authentication can be combine d with other techniques to require additional factors under specific circumstances, based on predefined rules and patterns, such as access from an unusual location, from an unusual device or at an unusual time. + +Biometric authentication information should be invalidated if it is ever compromised. Biometric authentication can be unavailable depending on the conditions of use (e.g. moisture or aging). To prepare for these issues, biometric authentication should be accompanied with at least one alternative authentication technique. + +The procedure for logging into a system or application should be designed to minimize the risk of unauthorized access. Log-on procedures and technologies should be implemented considering the following: + +a\) not displaying sensitive system or application information until the log-on process has been successfully completed in order to avoid providing an unauthorized user with any unnecessary assistance; + +b\) displaying a general notice warning that the system or the application or the service should only be accessed by authorized users; + +c\) not providing help messages during the log-on procedure that would aid an unauthorized user (e.g. if an error condition arises, the system should not indicate which part of the data is correct or incorrect); + +d\) validating the log-on information only on completion of all input data; + +e\) protecting against brute force log-on attempts on usernames and passwords \[e.g. using completely automated public Turing test to tell computers and humans apart (CAPTCHA), requiring password reset after a predefined number of failed attempts or blocking the user after a maximum number of errors\]; + +f\) logging unsuccessful and successful attempts; + +g\) raising a security event if a potential attempted or successful breach of log-on controls is detected (e.g. sending an alert to the user and the organization’s system administrators when a certain number of wrong password attempts has been reached); + +h\) displaying or sending the following information on a separate channel on completion of a successful log-on: +1\) date and time of the previous successful log-on; +2\) details of any unsuccessful log-on attempts since the last successful log-on; +i\) not displaying a password in clear text when it is being entered; in some cases, it can be required to de-activate this functionality in order to facilitate user log-on (e.g. for accessibility reasons or to avoid blocking users because of repeated errors); +j\) not transmitting passwords in clear text over a network to avoid being captured by a network "sniffer” program; +k\) terminating inactive sessions after a defined period of inactivity, especially in high risk locations such as public or external areas outside the organization’s security management or on user endpoint devices; +l\) restricting connection duration times to provide additional security for high-risk applications and reduce the window of opportunity for unauthorized access. + +**Other information** + +Additional information on entity authentication assurance can be found is ISO/IEC 29115. + +## 8.6 Capacity management + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +|----------------------|-------------------------------------|----------------------------|-------------------------|---------------------------------| +| #Preventive #Detective | #Integrity #Availability | #Identify #Protect #Detect | #Continuity | #Governance_and_Ecosystem #Protection | + +**Control** + +The use of resources should be monitored and adjusted in line with current and expected capacity requirements. + +**Purpose** + +To ensure the required capacity of information processing facilities, human resources, offices and other facilities. + +**Guidance** + +Capacity requirements for information processing facilities, human resources, offices and other facilities should be identified, taking into account the business criticality of the concerned systems and processes. + +System tuning and monitoring should be applied to ensure and, where necessary, improve the availability and efficiency of systems. + +The organization should perform stress-tests of systems and services to confirm that sufficient system capacity is available to meet peak performance requirements. + +Detective controls should be put in place to indicate problems in due time. + +Projections of future capacity requirements should take account of new business and system requirements and current and projected trends in the organization’s information processing capabilities. + +Particular attention should be paid to any resources with long procurement lead times or high costs. Therefore, managers, service or product owners should monitor the utilization of key system resources. + +Managers should use capacity information to identify and avoid potential resource limitations and dependency on key personnel which can present a threat to system security or services and plan appropriate action. + +Providing sufficient capacity can be achieved by increasing capacity or by reducing demand. The following should be considered to increase capacity: + +a\) hiring new personnel; + +b\) obtaining new facilities or space; + +c\) acquiring more powerful processing systems, memory and storage; + +d\) making use of cloud computing, which has inherent characteristics that directly address issues of capacity. Cloud computing has elasticity and scalability which enable on-demand rapid expansion and reduction in resources available to particular applications and services. + +The following should be considered to reduce demand on the organization’s resources: + +a\) deletion of obsolete data (disk space); + +b\) disposal of hardcopy records that have met their retention period (free up shelving space); + +c\) decommissioning of applications, systems, databases or environments; + +d\) optimizing batch processes and schedules; + +e\) optimizing application code or database queries; + +f\) denying or restricting bandwidth for resource-consuming services if these are not critical (e.g. video streaming). + +A documented capacity management plan should be considered for mission critical systems. + +**Other information** + +For more detail on the elasticity and scalability of cloud computing, see ISO/IEC TS 23167. + +## 8.7 Protection against malware + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +|-------------------------------|-------------------------------------|----------------------------|-----------------------------------------|----------------------------| +| #Preventive #Detective #Corrective | #Confidentiality #Integrity #Availability | #Protect #Detect | #System_and_network_security #Information_protection | #Protection #Defence | + +**Control** +Protection against malware should be implemented and supported by appropriate user awareness. + +**Purpose** +To ensure information and other associated assets are protected against malware. + +**Guidance** + +Protection against malware should be based on malware detection and repair software, information security awareness, appropriate system access and change management controls. Use of malware detection and repair software alone is not usually adequate. The following guidance should be considered: + +a\) implementing rules and controls that prevent or detect the use of unauthorized software \[e.g. application allowlisting (i.e. using a list providing allowed applications)\] (see 8.19and 8.32); + +b\) implementing controls that prevent or detect the use of known or suspected malicious websites (e.g. blocklisting); + +c\) reducing vulnerabilities that can be exploited by malware \[e.g. through technical vulnerability management (see 8.8and 8.19)\]; + +d\) conducting regular automated validation of the software and data content of systems, especially for systems supporting critical business processes; investigating the presence of any unapproved files or unauthorized amendments; + +e\) establishing protective measures against risks associated with obtaining files and software either from or via external networks or on any other medium; + +f\) installing and regularly updating malware detection and repair software to scan computers and electronic storage media. Carrying out regular scans that include: +1\) scanning any data received over networks or via any form of electronic storage media, for malware before use; +2\) scanning email and instant messaging attachments and downloads for malware before use. Carrying out this scan at different places (e.g. at email servers, desktop computers) and when entering the network of the organization; +3\) scanning webpages for malware when accessed; + +g\) determining the placement and configuration of malware detection and repair tools based on risk assessment outcomes and considering: +1\) defence in depth principles where they would be most effective. For example, this can lead to malware detection in a network gateway (in various application protocols such as email, file transfer and web) as well as user endpoint devices and servers; +2\) the evasive techniques of attackers (e.g. the use of encrypted files) to deliver malware or the use of encryption protocols to transmit malware; + +h\) taking care to protect against the introduction of malware during maintenance and emergency procedures, which can bypass normal controls against malware; + +i\) implementing a process to authorize temporarily or permanently disable some or all measures against malware, including exception approval authorities, documented justification and review date. This can be necessary when the protection against malware causes disruption to normal operations; + +j\) preparing appropriate business continuity plans for recovering from malware attacks, including all necessary data and software backup (including both online and offline backup) and recovery measures (see 8.13); + +k\) isolating environments where catastrophic consequences can occur; + +l\) defining procedures and responsibilities to deal with protection against malware on systems, including training in their use, reporting and recovering from malware attacks; + +m\) providing awareness or training (see 6.3) to all users on how to identify and potentially mitigate the receipt, sending or installation of malware infected emails, files or programs \[the information collected in n) and o) can be used to ensure awareness and training are kept up-to-date\]; + +n\) implementing procedures to regularly collect information about new malware, such as subscribing to mailing lists or reviewing relevant websites; + +o\) verifying that information relating to malware, such as warning bulletins, comes from qualified and reputable sources (e.g. reliable internet sites or suppliers of malware detection software) and is accurate and informative. + +**Other information** + +It is not always possible to install software that protects against malware on some systems (e.g. some industrial control systems). Some forms of malware infect computer operating systems and computer firmware such that common malware controls cannot clean the system and a full reimaging of the operating system software and sometimes the computer firmware is necessary to return to a secure state. + +## 8.8 Management of technical vulnerabilities + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +| -------------- | ---------------------------------------- | --------------------- | ------------------------------- | ------------------------------- | +| #Preventive | #Confidentiality #Integrity #Availability | #Identify #Protect | #Threat_and_vulnerability_management | #Governance_and_Ecosystem #Protection #Defence | + +**Control** + +Information about technical vulnerabilities of information systems in use should be obtained, the organization’s exposure to such vulnerabilities should be evaluated and appropriate measures should be taken. + +**Purpose** + +To prevent exploitation of technical vulnerabilities. + +**Guidance** + +Identifying technical vulnerabilities + +The organization should have an accurate inventory of assets (see 5.9to 5.14) as a prerequisite for effective technical vulnerability management; the inventory should include the software vendor, software name, version numbers, current state of deployment (e.g. what software is installed on what systems) and the person(s) within the organization responsible for the software. + +To identify technical vulnerabilities, the organization should consider: + +a\) defining and establishing the roles and responsibilities associated with technical vulnerability management, including vulnerability monitoring, vulnerability risk assessment, updating, asset tracking and any coordination responsibilities required; + +b\) for software and other technologies (based on the asset inventory list, see 5.9), identifying information resources that will be used for identifying relevant technical vulnerabilities and maintaining awareness about them. Updating the list of information resources based on changes in the inventory or when other new or useful resources are found; + +c\) requiring suppliers of information system (including their components) to ensure vulnerability reporting, handling and disclosure, including the requirements in applicable contracts (see 5.20); + +d\) using vulnerability scanning tools suitable for the technologies in use to identify vulnerabilities and to verify whether the patching of vulnerabilities was successful; + +e\) conducting planned, documented and repeatable penetration tests or vulnerability assessments by competent and authorized persons to support the identification of vulnerabilities. Exercising caution as such activities can lead to a compromise of the security of the system; + +f\) tracking the usage of third-party libraries and source code for vulnerabilities. This should be included in secure coding (see 8.28). + +The organization should develop procedures and capabilities to: + +a\) detect the existence of vulnerabilities in its products and services including any external component used in these; + +b\) receive vulnerability reports from internal or external sources. + +The organization should provide a public point of contact as part of a topic-specific policy on vulnerability disclosure so that researchers and others are able to report issues. The organization should establish vulnerability reporting procedures, online reporting forms and making use of appropriate threat intelligence or information sharing forums. The organization should also consider bug bounty programs where rewards are offered as an incentive to assist organizations in identifying vulnerabilities in order to appropriately remediate them. The organization should also share information with competent industry bodies or other interested parties. + +Evaluating technical vulnerabilities + +To evaluate identified technical vulnerabilities, the following guidance should be considered: + +a\) analyse and verify reports to determine what response and remediation activity is needed; + +b\) once a potential technical vulnerability has been identified, identifying the associated risks and the actions to be taken. Such actions can involve updating vulnerable systems or applying other controls. + +Taking appropriate measures to address technical vulnerabilities + +A software update management process should be implemented to ensure the most up-to-date approved patches and application updates are installed for all authorized software. If changes are necessary, the original software should be retained and the changes applied to a designated copy. All changes should be fully tested and documented, so that they can be reapplied, if necessary, to future software upgrades. If required, the modifications should be tested and validated by an independent evaluation body. + +The following guidance should be considered to address technical vulnerabilities: + +a\) taking appropriate and timely action in response to the identification of potential technical vulnerabilities; defining a timeline to react to notifications of potentially relevant technical vulnerabilities; + +b\) depending on how urgently a technical vulnerability needs to be addressed, carrying out the action according to the controls related to change management (see 8.32) or by following information security incident response procedures (see 5.26); + +c\) only using updates from legitimate sources (which can be internal or external to the organization); + +d\) testing and evaluating updates before they are installed to ensure they are effective and do not result in side effects that cannot be tolerated \[i.e. if an update is available, assessing the risks associated with installing the update (the risks posed by the vulnerability should be compared with the risk of installing the update)\]; + +e\) addressing systems at high risk first; + +f\) develop remediation (typically software updates or patches); + +g\) test to confirm if the remediation or mitigation is effective; + +h\) provide mechanisms to verify the authenticity of remediation; + +i\) if no update is available or the update cannot be installed, considering other controls, such as: + +1\) applying any workaround suggested by the software vendor or other relevant sources; + +2\) turning off services or capabilities related to the vulnerability; + +3\) adapting or adding access controls (e.g. firewalls) at network borders (see 8.20to 8.22); + +4\) shielding vulnerable systems, devices or applications from attack through deployment of suitable traffic filters (sometimes called virtual patching); + +5\) increasing monitoring to detect actual attacks; + +6\) raising awareness of the vulnerability. + + +For acquired software, if the vendors regularly release information about security updates for their software and provide a facility to install such updates automatically, the organization should decide whether to use the automatic update or not. + +Other considerations + +An audit log should be kept for all steps undertaken in technical vulnerability management. + +The technical vulnerability management process should be regularly monitored and evaluated in order to ensure its effectiveness and efficiency. + +An effective technical vulnerability management process should be aligned with incident management activities, to communicate data on vulnerabilities to the incident response function and provide technical procedures to be carried out in case an incident occurs. + +Where the organization uses a cloud service supplied by a third-party cloud service provider, technical vulnerability management of cloud service provider resources should be ensured by the cloud service provider. The cloud service provider’s responsibilities for technical vulnerability management should be part of the cloud service agreement and this should include processes for reporting the cloud service provider's actions relating to technical vulnerabilities (see 5.23). For some cloud services, there are respective responsibilities for the cloud service provider and the cloud service customer. For example, the cloud service customer is responsible for vulnerability management of its own assets used for the cloud services. + +**Other information** + +Technical vulnerability management can be viewed as a sub-function of change management and as such can take advantage of the change management processes and procedures (see 8.32). + +There is a possibility that an update does not address the problem adequately and has negative side effects. Also, in some cases, uninstalling an update cannot be easily achieved once the update has been applied. + +If adequate testing of the updates is not possible (e.g. because of costs or lack of resources) a delay in updating can be considered to evaluate the associated risks, based on the experience reported by other users. The use of ISO/IEC 27031 can be beneficial. + +Where software patches or updates are produced, the organization can consider providing an automated update process where these updates are installed on affected systems or products without the need for intervention by the customer or the user. If an automated update process is offered, it can allow the customer or user to choose an option to turn off the automatic update or control the timing of the installation of the update. + +Where the vendor provides an automated update process and the updates can be installed on affected systems or products without the need for intervention, the organization determines if it applies the automated process or not. One reason for not electing for automated update is to retain control over when the update is performed. For example, a software used for a business operation cannot be updated until the operation has completed. + +A weakness with vulnerability scanning is that it is possible it does not fully account for defence in depth: two countermeasures that are always invoked in sequence can have vulnerabilities that are masked by strengths in the other. The composite countermeasure is not vulnerable, whereas a vulnerability scanner can report that both components are vulnerable. The organization should therefore take care in reviewing and acting on vulnerability reports. + +Many organizations supply software, systems, products and services not only within the organization but also to interested parties such as customers, partners or other users. These software, systems, products and services can have information security vulnerabilities that affect the security of users. + +Organizations can release remediation and disclose information about vulnerabilities to users (typically through a public advisory) and provide appropriate information for software vulnerability database services. + +For mor e information relating to the management of technical vulnerabilities when using cloud computing, see the ISO/IEC 19086 series and ISO/IEC 27017. + +ISO/IEC 29147 provides detailed information on receiving vulnerability reports and publishing vulnerability advisories. ISO/IEC 30111 provides detailed information about handling and resolving reported vulnerabilities. + +## 8.9 Configuration management + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +|------------------|------------------------------------------|-----------------------|------------------------------|--------------------| +| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Secure_configuration | #Protection | + +**Control** +Configurations, including security configurations, of hardware, software, services and networks should be established, documented, implemented, monitored and reviewed. + +**Purpose** +To ensure hardware, software, services and networks function correctly with required security settings, and configuration is not altered by unauthorized or incorrect changes. + +**Guidance** + +General + +The organization should define and implement processes and tools to enforce the defined configurations (including security configurations) for hardware, software, services (e.g. cloud services) and networks, for newly installed systems as well as for operational systems over their lifetime. + +Roles, responsibilities and procedures should be in place to ensure satisfactory control of all configuration changes. + +Standard templates + +Standard templates for the secure configuration of hardware, software, services and networks should be defined: + +a\) using publicly available guidance (e.g. pre-defined templates from vendors and from independent security organizations); + +b\) considering the level of protection needed in order to determine a sufficient level of security; + +c\) supporting the organization’s information security policy, topic-specific policies, standards and other security requirements; + +d\) considering the feasibility and applicability of security configurations in the organization’s context. + +The templates should be reviewed periodically and updated when new threats or vulnerabilities need to be addressed, or when new software or hardware versions are introduced. + +The following should be considered for establishing standard templates for the secure configuration of hardware, software, services and networks: + +a\) minimizing the number of identities with privileged or administrator level access rights; + +b\) disabling unnecessary, unused or insecure identities; + +c\) disabling or restricting unnecessary functions and services; + +d\) restricting access to powerful utility programs and host parameter settings; + +e\) synchronizing clocks; + +f\) changing vendor default authentication information such as default passwords immediately after installation and reviewing other important default security-related parameters; + +g\) invoking time-out facilities that automatically log off computing devices after a predetermined period of inactivity; + +h\) verifying that licence requirements have been met (see 5.32). Managing configurations + +Established configurations of hardware, software, services and networks should be recorded and a log should be maintained of all configuration changes. These records should be securely stored. This can be achieved in various ways, such as configuration databases or configuration templates. + +Changes to configurations should follow the change management process (see 8.32). + +Configuration records can contain as relevant: + +a\) up-to-date owner or point of contact information for the asset; + +b\) date of the last change of configuration; + +c\) version of configuration template; + +d\) relation to configurations of other assets. Monitoring configurations + +Configurations should be monitored with a comprehensive set of system management tools (e.g. maintenance utilities, remote support, enterprise management tools, backup and restore software) and should be reviewed on a regular basis to verify configuration settings, evaluate password strengths and assess activities performed. Actual configurations can be compared with the defined target templates. Any deviations should be addressed, either by automatic enforcement of the defined target configuration or by manual analysis of the deviation followed by corrective actions. + +**Other information** + +Documentation for systems often records details about the configuration of both hardware and software. + +System hardening is a typical part of configuration management. + +Configuration management can be integrated with asset management processes and associated tooling. + +Automation is usually more effective to manage security configuration (e.g. using infrastructure as code). + +Configuration templates and targets can be confidential information and should be protected from unauthorized access accordingly. + +## 8.10 Information deletion + +| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | +|------------------|------------------------------------|---------------------------|---------------------------------------------|---------------------------------------| +| #Preventive | #Confidentiality | #Protect | #Information_protection #Legal_and_compliance | #Protection | + +**Control** + +Information stored in information systems, devices or in any other storage media should be deleted when no longer required. + +**Purpose** + +To prevent unnecessary exposure of sensitive information and to comply with legal, statutory, regulatory and contractual requirements for information deletion. + +**Guidance** + +General + +Sensitive information should not be kept for longer than it is required to reduce the risk of undesirable disclosure. + +When deleting information on systems, applications and services, the following should be considered: + +a\) selecting a deletion method (e.g. electronic overwriting or cryptographic erasure) in accordance + +with business requirements and taking into consideration relevant laws and regulations; + +b\) recording the results of deletion as evidence; + +c\) when using service suppliers of information deletion, obtaining evidence of information deletion from them. + +Where third parties store the organization’s information on its behalf, the organization should consider the inclusion of requirements on information deletion into the third-party agreements to enforce it during and upon termination of such services. + +Deletion methods + +In accordance with the organization’s topic-specific policy on data retention and taking into consideration relevant legislation and regulations, sensitive information should be deleted when no longer required, by: + +a\) configuring systems to securely destroy information when no longer required (e.g. after a defined period subject to the topic-specific policy on data retention or by subject access request); + +b\) deleting obsolete versions, copies and temporary files wherever they are located; + +c\) using approved, secure deletion software to permanently delete information to help ensure information cannot be recovered by using specialist recovery or forensic tools; + +d\) using approved, certified providers of secure disposal services; + +e\) using disposal mechanisms appropriate for the type of storage media being disposed of (e.g. degaussing hard disk drives and other magnetic storage media). + +Where cloud services are used, the organization should verify if the deletion method provided by the cloud service provider is acceptable, and if it is the case, the organization should use it, or request that the cloud service provider delete the information. These deletion processes should be automated in accordance with topic-specific policies, when available and applicable. Depending on the sensitivity of information deleted, logs can track or verify that these deletion processes have happened. + +To avoid the unintentional exposure of sensitive information when equipment is being sent back to vendors, sensitive information should be protected by removing auxiliary storages (e.g. hard disk drives) and memory before equipment leaves the organization’s premises. + +Considering that the secure deletion of some devices (e.g. smartphones) can only be achieved through destruction or using the functions embedded in these devices (e.g. “restore factory settings”), the organization should choose the appropriate method according to the classification of information handled by such devices. + +Control measures described in 7.14 should be applied to physically destroy the storage device and simultaneously delete the information it contains. + +An official record of information deletion is useful when analysing the cause of a possible information leakage event. + +**Other information** + +Information on user data deletion in cloud services can be found in ISO/IEC 27017. Information on deletion of PII can be found in ISO/IEC 27555. + +## 8.11 Data masking + +| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | +|------------------|------------------------------------|---------------------------|---------------------------------|------------------------------| +| #Preventive | #Confidentiality | #Protect | #Information_protection | #Protection | + +**Control** + +Data masking should be used in accordance with the organization’s topic-specific policy on access control and other related topic-specific policies, and business requirements, taking applicable legislation into consideration. + +**Purpose** + +To limit the exposure of sensitive data including PII, and to comply with legal, statutory, regulatory and contractual requirements. + +**Guidance** + +Where the protection of sensitive data (e.g. PII) is a concern, the organization should consider hiding such data by using techniques such as data masking, pseudonymization or anonymization. + +Pseudonymization or anonymization techniques can hide PII, disguise the true identity of PII principals or other sensitive information, and disconnect the link between PII and the identity of the PII principal or the link between other sensitive information. + +When using pseudonymization or anonymization techniques, it should be verified that data has been adequately pseudonymized or anonymized. Data anonymization should consider all the elements of the sensitive information to be effective. As an example, if not considered properly, a person can be identified even if the data that can directly identify that person is anonymised, by the presence of further data which allows the person to be identified indirectly. + +Additional techniques for data masking include: + +a\) encryption (requiring authorized users to have a key); + +b\) nulling or deleting characters (preventing unauthorized users from seeing full messages); + +c\) varying numbers and dates; + +d\) substitution (changing one value for another to hide sensitive data); + +e\) replacing values with their hash. + +The following should be considered when implementing data masking techniques: + +a\) not granting all users access to all data, therefore designing queries and masks in order to show only the minimum required data to the user; + +b\) there are cases where some data should not be visible to the user for some records out of a set of data; in this case, designing and implementing a mechanism for obfuscation of data (e.g. if a patient does not want hospital staff to be able to see all of their records, even in case of emergency, then the hospital staff are presented with partially obfuscated data and data can only be accessed by staff with specific roles if it contains useful information for appropriate treatment); + +c\) when data are obfuscated, giving the PII principal the possibility to require that users cannot see if the data are obfuscated (obfuscation of the obfuscation; this is used in health facilities, for example if the patient does not want personnel to see that sensitive information such as pregnancies or results of blood exams has been obfuscated); + +d\) any legal or regulatory requirements (e.g. requiring the masking of payment cards' information during processing or storage). + +The following should be considered when using data masking, pseudonymization or anonymization: + +a\) level of strength of data masking, pseudonymization or anonymization according to the usage of the processed data; + +b\) access controls to the processed data; + +c\) agreements or restrictions on usage of the processed data; + +d\) prohibiting collating the processed data with other information in order to identify the PII principal; + +e\) keeping track of providing and receiving the processed data. + +**Other information** + +Anonymization irreversibly alters PII in such a way that the PII principal can no longer be identified directly or indirectly. + +Pseudonymization replaces the identifying information with an alias. Knowledge of the algorithm (sometimes referred to as the “additional information”) used to perform the pseudonymization allows for at least some form of identification of the PII principal. Such “additional information” should therefore be kept separate and protected. + +While pseudonymization is therefore weaker than anonymization, pseudonymized datasets can be more useful in statistical research. + +Data masking is a set of techniques to conceal, substitute or obfuscate sensitive data items. Data masking can be static (when data items are masked in the original database), dynamic (using automation and rules to secure data in real-time) or on-the-fly (with data masked in an application’s memory). + +Hash functions can be used in order to anonymize PII. In order to prevent enumeration attacks, they should always be combined with a salt function. + +PII in resource identifiers and their attributes \[e.g. file names, uniform resource locators (URLs)\] should be either avoided or appropriately anonymized. + +Additional controls concerning the protection of PII in public clouds are given in ISO/IEC 27018. + +Additional information on de-identification techniques is available in ISO/IEC 20889. + +## 8.12 Data leakage prevention + +| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | +|--------------------------|------------------------------------|---------------------------|-------------------------------|---------------------------| +| #Preventive #Detective| #Confidentiality | #Protect #Detect | #Information_protection | #Protection #Defence | + +**Control** + +Data leakage prevention measures should be applied to systems, networks and any other devices that process, store or transmit sensitive information. + +**Purpose** + +To detect and prevent the unauthorized disclosure and extraction of information by individuals or systems. + +**Guidance** + +The organization should consider the following to reduce the risk of data leakage: + +a\) identifying and classifying information to protect against leakage (e.g. personal information, pricing models and product designs); + +b\) monitoring channels of data leakage (e.g. email, file transfers, mobile devices and portable storage devices); + +c\) acting to prevent information from leaking (e.g. quarantine emails containing sensitive information). + +Data leakage prevention tools should be used to: + +a\) identify and monitor sensitive information at risk of unauthorized disclosure (e.g. in unstructured data on a user’s system); + +b\) detect the disclosure of sensitive information (e.g. when information is uploaded to untrusted third-party cloud services or sent via email); + +c\) block user actions or network transmissions that expose sensitive information (e.g. preventing the copying of database entries into a spreadsheet). + +The organization should determine if it is necessary to restrict a user’s ability to copy and paste or upload data to services, devices and storage media outside of the organization. If that is the case, the organization should implement technology such as data leakage prevention tools or the configuration of existing tools that allow users to view and manipulate data held remotely but prevent copy and paste outside of the organization’s control. + +If data export is required, the data owner should be allowed to approve the export and hold users accountable for their actions. + +Taking screenshots or photographs of the screen should be addressed through terms and conditions of use, training and auditing. + +Where data is backed up, care should be taken to ensure sensitive information is protected using measures such as encryption, access control and physical protection of the storage media holding the backup. + +Data leakage prevention should also be considered to protect against the intelligence actions of an adversary from obtaining confidential or secret information (geopolitical, human, financial, commercial, scientific or any other) which can be of interest for espionage or can be critical for the community. The data le akage prevention actions should be oriented to confuse the adversary’s decisions for example by replacing authentic information with false information, either as an independent action or as response to the adversary’s intelligence actions. Examples of these kinds of actions are reverse social engineering or the use of honeypots to attract attackers. + +**Other information** + +Data leakage prevention tools are designed to identify data, monitor data usage and movement, and take actions to prevent data from leaking (e.g. alerting users to their risky behaviour and blocking the transfer of data to portable storage devices). + +Data leakage prevention inherently involves monitoring personnel’s communications and online activities, and by extension external party messages, which raises legal concerns that should be considered prior to deploying data leakage prevention tools. There is a variety of legislation relating to privacy, data protection, employment, interception of data and telecommunications that is applicable to monitoring and data processing in the context of data leakage prevention. + +Data leakage prevention can be supported by standard security controls, such as topic-specific policies on access control and secure document management (see >5.12and >5.15>). + +## 8.13 Information backup + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +| ------------ | ------------------------------ | --------------------- | ----------------------- | --------------- | +| #Corrective | #Integrity #Availability | #Recover | #Continuity | #Protection | +**Control** + +Backup copies of information, software and systems should be maintained and regularly tested in accordance with the agreed topic-specific policy on backup. + +**Purpose** + +To enable recovery from loss of data or systems. + +**Guidance** + +A topic-specific policy on backup should be established to address the organization’s data retention and information security requirements. + +Adequate backup facilities should be provided to ensure that all essential information and software can be recovered following an incident or failure or loss of storage media. + +Plans should be developed and implemented for how the organization will back up information, software and systems, to address the topic-specific policy on backup. + +When designing a backup plan, the following items should be taken into consideration: + +a\) producing accurate and complete records of the backup copies and documented restoration procedures; + +b\) reflecting the business requirements of the organization (e.g. the recovery point objective, see >5.30>), the security requirements of the information involved and the criticality of the information to the continued operation of the organization in the extent (e.g. full or differential backup) and frequency of backups; + +c\) storing the backups in a safe and secure remote location, at a sufficient distance to escape any damage from a disaster at the main site; + +d\) giving backup information an appropriate level of physical and environmental protection (see >Clause 7and >8.1>) consistent with the standards applied at the main site; + +e\) regularly testing backup media to ensure that they can be relied on for emergency use when necessary. Testing the ability to restore backed-up data onto a test system, not by overwriting the original storage media in case the backup or restoration process fails and causes irreparable data damage or loss; + +f\) protecting backups by means of encryption according to the identified risks (e.g. in situations where confidentiality is of importance); + +g\) taking care to ensure that inadvertent data loss is detected before backup is taken. + +Operational procedures should monitor the execution of backups and address failures of scheduled backups to ensure completeness of backups according to the topic-specific policy on backups. + +Backup measures for individual systems and services should be regularly tested to ensure that they meet the objectives of incident response and business continuity plans (see 5.30). This should be combined with a test of the restoration procedures and checked against the restoration time required by the business continuity plan. In the case of critical systems and services, backup measures should cover all systems information, applications and data necessary to recover the complete system in the event of a disaster. + +When the organization uses a cloud service, backup copies of the organization’s information, applications and systems in the cloud service environment should be taken. The organization should determine if and how requirements for backup are fulfilled when using the information backup service provided as part of the cloud service. + +The retention period for essential business information should be determined, taking into account any requirement for retention of archive copies. The organization should consider the deletion of information (see 8.10) in storage media used for backup once the information’s retention period expires and should take into consideration legislation and regulations. + +**Other information** + +For further information on storage security including retention consideration, see ISO/IEC 27040. + +## 8.14 Redundancy of information processing facilities + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +| ------------ | ------------------------------ | --------------------- | ---------------------------------- | --------------------- | +| #Preventive | #Availability | #Protect | #Continuity #Asset_management | #Protection #Resilience | + +**Control** +Information processing facilities should be implemented with redundancy sufficient to meet availability requirements. + +**Purpose** +To ensure the continuous operation of information processing facilities. + +**Guidance** + +The organization should identify requirements for the availability of business services and information systems. The organization should design and implement systems architecture with appropriate redundancy to meet these requirements. + +Redundancy can be introduced by duplicating information processing facilities in part or in their entirety (i.e. spare components or having two of everything). The organization should plan and implement procedures for the activation of the redundant components and processing facilities. The procedures should establish if the redundant components and processing activities are always activated, or in case of emergency, automatically or manually activated. The redundant components and information processing facilities should ensure the same security level as the primary ones. + +Mechanisms should be in place to alert the organization to any failure in the information processing facilities, enable executing the planned procedure and allow continued availability while the information processing facilities are repaired or replaced. + +The organization should consider the following when implementing redundant systems: + +a\) contracting with two or more suppliers of network and critical information processing facilities such as internet service providers; + +b\) using redundant networks; + +c\) using two geographically separate data centres with mirrored systems; + +d\) using physically redundant power supplies or sources; + +e\) using multiple parallel instances of software components, with automatic load balancing between them (between instances in the same data centre or in different data centres); + +f\) having duplicated components in systems (e.g. CPU, hard disks, memories) or in networks (e.g. firewalls, routers, switches). + +Where applicable, preferably in production mode, redundant information systems should be tested to ensure the failover from one component to another component works as intended. + +**Other information** + +There is a strong relationship between redundancy and ICT readiness for business continuity (see 5.30) especially if short recovery times are required. Many of the redundancy measures can be part of the ICT continuity strategies and solutions. + +The implementation of redundancies can introduce risks to the integrity (e.g. processes of copying data to duplicated components can introduce errors) or confidentiality (e.g. weak security control of duplicated components can lead to compromise) of information and information systems, which need to be considered when designing information systems. + +Redundancy in information processing facilities does not usually address application unavailability due to faults within an application. + +With the use of public cloud computing, it is possible to have multiple live versions of information processing facilities, existing in multiple separate physical locations with automatic failover and load balancing between them. + +Some of the technologies and techniques for providing redundancy and automatic fail-over in the context of cloud services are discussed in ISO/IEC TS 23167. + +## 8.15 Logging + +| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | +|------------------|------------------------------------|---------------------------|----------------------------------------|---------------------------| +| #Detective | #Confidentiality #Integrity #Availability | #Detect | #Information_security_event_management | #Protection #Defence | + +**Control** +Logs that record activities, exceptions, faults and other relevant events should be produced, stored, protected and analysed. + +**Purpose** +To record events, generate evidence, ensure the integrity of log information, prevent against unauthorized access, identify information security events that can lead to an information security incident and to support investigations. + +**Guidance** + +General + +The organization should determine the purpose for which logs are created, what data is collected and logged, and any log-specific requirements for protecting and handling the log data. This should be documented in a topic-specific policy on logging. + +Event logs should include for each event, as applicable: + +a\) user IDs; + +b\) system activities; + +c\) dates, times and details of relevant events (e.g. log-on and log-off); + +d\) device identity, system identifier and location; + +e\) network addresses and protocols. + +The following events should be considered for logging: + +a\) successful and rejected system access attempts; + +b\) successful and rejected data and other resource access attempts; + +c\) changes to system configuration; + +d\) use of privileges; + +e\) use of utility programs and applications; + +f\) files accessed and the type of access, including deletion of important data files; + +g\) alarms raised by the access control system; + +h\) activation and de-activation of security systems, such as anti-virus systems and intrusion detection systems; + +i\) creation, modification or deletion of identities; + +j\) transactions executed by users in applications. In some cases, the applications are a service or product provided or run by a third party. + +It is important for all systems to have synchronized time sources (see 8.17) as this allows for correlation of logs between systems for analysis, alerting and investigation of an incident. + +Protection of logs + +Users, including those with privileged access rights, should not have permission to delete or de-activate logs of their own activities. They can potentially manipulate the logs on information processing facilities under their direct control. Therefore, it is necessary to protect and review the logs to maintain accountability for the privileged users. + +Controls should aim to protect against unauthorized changes to log information and operational problems with the logging facility including: + +a\) alterations to the message types that are recorded; + +b\) log files being edited or deleted; + +c\) failure to record events or over-writing of past recorded events if the storage media holding a log file is exceeded. + +For protection of logs, the use of the following techniques should be considered: cryptographic hashing, recording in an append-only and read-only file, recording in a public transparency file. + +Some audit logs can be required to be archived because of requirements on data retention or requirements to collect and retain evidence (see 5.28). + +Where the organization needs to send system or application logs to a vendor to assist with debugging or troubleshooting errors, logs should be de-identified where possible using data masking techniques (see 8.11) for information such as usernames, internet protocol (IP) addresses, hostnames or organization name, before sending to the vendor. + +Event logs can contain sensitive data and personally identifiable information. Appropriate privacy protection measures should be taken (see 5.34). + +Log analysis + +Log analysis should cover the analysis and interpretation of information security events, to help identify unusual activity or anomalous behaviour, which can represent indicators of compromise. + +Analysis of events should be performed by taking into account: + +a\) the necessary skills for the experts performing the analysis; + +b\) determining the procedure of log analysis; + +c\) the required attributes of each security-related event; + +d\) exceptions identified through the use of predetermined rules \[e.g. security information and event management (SIEM) or firewall rules, and intrusion detection systems (IDSs) or malware signatures\]; + +e\) known behaviour patterns and standard network traffic compared to anomalous activity and behaviour \[user and entity behaviour analytics (UEBA)\]; + +f\) results of trend or pattern analysis (e.g. as a result of using data analytics, big data techniques and specialized analysis tools); + +g\) available threat intelligence. + +Log analysis should be supported by specific monitoring activities to help identify and analyse anomalous behaviour, which includes: + +a\) reviewing successful and unsuccessful attempts to access protected resources \[e.g. domain name system (DNS) servers, web portals and file shares\]; + +b\) checking DNS logs to identify outbound network connections to malicious servers, such as those associated with botnet command and control servers; + +c\) examining usage reports from service providers (e.g. invoices or service reports) for unusual activity within systems and networks (e.g. by reviewing patterns of activity); + +d\) including event logs of physical monitoring such as entrance and exit to ensure more accurate detection and incident analysis; + +e\) correlating logs to enable efficient and highly accurate analysis. + +Suspected and actual information security incidents should be identified (e.g. malware infection or probing of firewalls) and be subject to further investigation (e.g. as part of an information security incident management process, see >5.25>). + +**Other information** + +System logs often contain a large volume of information, much of which is extraneous to information security monitoring. To help i dentify significant events for information security monitoring purposes, the use of suitable utility programs or audit tools to perform file interrogation can be considered. + +Event logging sets the foundation for automated monitoring systems (see 8.16) which are capable of generating consolidated reports and alerts on system security. + +A SIEM tool or equivalent service can be used to store, correlate, normalize and analyse log information**,** and to generate alerts. SIEMs tend to require careful configuration to optimize their benefits. Configurations to consider include identification and selection of appropriate log sources, tuning and testing of rules and development of use cases. + +Public transparency files for the recording of logs are used, for example, in certificate transparency systems. Such files can provide an additional detection mechanism useful for guarding against log tampering. + +In cloud environments, log management responsibilities can be shared between the cloud service customer and the cloud service provider. Responsibilities vary depending on the type of cloud service being used. Further guidance can be found in ISO/IEC 27017. + +## 8.16 Monitoring activities + +| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | +|------------------|------------------------------------|---------------------------|----------------------------------------|---------------------------| +| #Detective #Corrective | #Confidentiality #Integrity #Availability | #Detect #Respond | #Information_security_event_management | #Defence | + +**Control** + +Networks, systems and applications should be monitored for anomalous behaviour and appropriate actions taken to evaluate potential information security incidents. + +**Purpose** + +To detect anomalous behaviour and potential information security incidents. + +**Guidance** + +The monitoring scope and level should be determined in accordance with business and information security requirements and taking into consideration relevant laws and regulations. Monitoring records should be maintained for defined retention periods. + +The following should be considered for inclusion within the monitoring system: + +a\) outbound and inbound network, system and application traffic; + +b\) access to systems, servers, networking equipment, monitoring system, critical applications, etc.; + +c\) critical or admin level system and network configuration files; + +d\) logs from security tools \[e.g. antivirus, IDS, intrusion prevention system (IPS), web filters, firewalls, data leakage prevention\]; + +e\) event logs relating to system and network activity; + +f\) checking that the code being executed is authorized to run in the system and that it has not been tampered with (e.g. by recompilation to add additional unwanted code); + +g\) use of the resources (e.g. CPU, hard disks, memory, bandwidth) and their performance. + +The organization should establish a baseline of normal behaviour and monitor against this baseline for anomalies. When establishing a baseline, the following should be considered: + +a\) reviewing utilization of systems at normal and peak periods; + +b\) usual time of access, location of access, frequency of access for each user or group of users. + +The monitoring system should be configured against the established baseline to identify anomalous behaviour, such as: + +a\) unplanned termination of processes or applications; + +b\) activity typically associated with malware or traffic originating from known malicious IP addresses or network domains (e.g. those associated with botnet command and control servers); + +c\) known attack characteristics (e.g. denial of service and buffer overflows); + +d\) unusual system behaviour (e.g. keystroke logging, process injection and deviations in use of standard protocols); + +e\) bottlenecks and overloads (e.g. network queuing, latency levels and network jitter); + +f\) unauthorized access (actual or attempted) to systems or information; + +g\) unauthorized scanning of business applications, systems and networks; + +h\) successful and unsuccessful attempts to access protected resources (e.g. DNS servers, web portals and file systems); + +i\) unusual user and system behaviour in relation to expected behaviour. + +Continuous monitoring via a monitoring tool should be used. Monitoring should be done in real time or in periodic intervals, subject to organizational need and capabilities. Monitoring tools should include the ability to handle large amounts of data, adapt to a constantly changing threat landscape, and allow for real-time notification. The tools should also be able to recognize specific signatures and data or network or application behaviour patterns. + +Automated monitoring software should be configured to generate alerts (e.g. via management consoles, email messages or instant messaging systems) based on predefined thresholds. The alerting system should be tuned and trained on the organization’s baseline to minimize false positives. Personnel should be dedicated to respond to alerts and should be properly trained to accurately interpret potential incidents. There should be redundant systems and processes in place to receive and respond to alert notifications. + +Abnormal events should be communicated to relevant parties in order to improve the following activities: auditing, security evaluation, vulnerability scanning and monitoring (see 5.25). Procedures should be in place to respond to positive indicators from the monitoring system in a timely manner, in order to minimize the effect of adverse events (see 5.26) on information security. Procedures should also be established to identify and address false positives including tuning the monitoring software to reduce the number of future false positives. + +**Other information** + +Security monitoring can be enhanced by: + +a\) leveraging threat intelligence systems (see 5.7); + +b\) leveraging machine learning and artificial intelligence capabilities; + +c\) using blocklists or allowlists; + +d\) undertaking a range of technical security assessments (e.g. vulnerability assessments, penetration testing, cyber-attack simulations and cyber response exercises), and using the results of these assessments to help determine baselines or acceptable behaviour; + +e\) using performance monitoring systems to help establish and detect anomalous behaviour; + +f\) leveraging logs in combination with monitoring systems. + +Monitoring activities are often conducted using specialist software, such as intrusion detection systems. These can be configured to a baseline of normal, acceptable and expected system and network activities. + +Monitoring for anomalous communications helps in the identification of botnets (i.e. set of devices under the malicious control of the botnet owner, usually used for mounting distributed denial of service attacks on other computers of other organizations). If the computer is being controlled by an external device, there is a communication between the infected device and the controller. The organization should therefore employ technologies to monitor for anomalous communications and take such action as necessary. + +## 8.17 Clock synchronization + +| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | +|------------------|------------------------------------|---------------------------|----------------------------------------|---------------------------| +| #Detective | #Integrity | #Protect #Detect | #Information_security_event_management | #Protection #Defence | + + +**Control** + +The clocks of information processing systems used by the organization should be synchronized to approved time sources. + +**Purpose** + +To enable the correlation and analysis of security-related events and other recorded data, and to support investigations into information security incidents. + +**Guidance** + +External and internal requirements for time representation, reliable synchronization and accuracy should be documented and implemented. Such requirements can be from legal, statutory, regulatory, contractual, standards and internal monitoring needs. A standard reference time for use within the organization should be defined and considered for all systems, including building management systems, entry and exit systems and others that can be used to aid investigations. + +A clock linked to a radio time broadcast from a national atomic clock or global positioning system (GPS) should be used as the reference clock for logging systems; a consistent, trusted date and time source to ensure accurate time-stamps. Protocols such as network time protocol (NTP) or precision time protocol (PTP) should be used to keep all networked systems in synchronization with a reference clock. + +The organization can use two external time sources at the same time in order to improve the reliability of external clocks, and appropriately manage any variance. + +Clock synchronization can be difficult when using multiple cloud services or when using both cloud and on-premises services. In this case, the clock of each service should be monitored and the difference recorded in order to mitigate risks arising from discrepancies. + +**Other information** + +The correct setting of computer clocks is important to ensure the accuracy of event logs, which can be required for investi gations or as evidence in legal and disciplinary cases. Inaccurate audit logs can hinder such investigations and damage the credibility of such evidence. + +## 8.18 Use of privileged utility programs + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +| ------------ | ---------------------------------------- | --------------------- | ---------------------------------------------------------- | ------------------ | +| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #System_and_network_security #Secure_configuration #Application_security | #Protection | + +**Control** + +The use of utility programs that can be capable of overriding system and application controls should be restricted and tightly controlled. + +**Purpose** + +To ensure the use of utility programs does not harm system and application controls for information security. + +**Guidance** + +The following guidelines for the use of utility programs that can be capable of overriding system and application controls should be considered: + +a\) limitation of the use of utility programs to the minimum practical number of trusted, authorized users (see 8.2); + +b\) use of identification, authentication and authorization procedures for utility programs, including unique identification of the person who uses the utility program; + +c\) defining and documenting of authorization levels for utility programs; + +d\) authorization for ad hoc use of utility programs; + +e\) not making utility programs available to users who have access to applications on systems where segregation of duties is required; + +f\) removing or disabling all unnecessary utility programs; + +g\) at a minimum, logical segregation of utility programs from application software. Where practical, segregating network communications for such programs from application traffic; + +h\) limitation of the availability of utility programs (e.g. for the duration of an authorized change); + +i\) logging of all use of utility programs. + +**Other information** + +Most information systems have one or more utility programs that can be capable of overriding system and application controls, for example diagnostics, patching, antivirus, disk defragmenters, debuggers, backup and network tools. + +## 8.19 Installation of software on operational systems + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +| ------------ | ---------------------------------------- | --------------------- | ----------------------------------------------- | ------------------ | +| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Secure_configuration #Application_security | #Protection | + +**Control** + +Procedures and measures should be implemented to securely manage software installation on operational systems. + +**Purpose** + +To ensure the integrity of operational systems and prevent exploitation of technical vulnerabilities. + +**Guidance** + +The following guidelines should be considered to securely manage changes and installation of software on operational systems: + +a\) performing updates of operational software only by trained administrators upon appropriate management authorization (see 8.5); + +b\) ensuring that only approved executable code and no development code or compilers is installed on operational systems; + +c\) only installing and updating software after extensive and successful testing (see >8.29and >8.31>); + +d\) updating all corresponding program source libraries; + +e\) using a configuration control system to keep control of all operational software as well as the system documentation; + +f\) defining a rollback strategy before changes are implemented; + +g\) maintaining an audit log of all updates to operational software; + +h\) archiving old versions of software, together with all required information and parameters, procedures, configuration details and supporting software as a contingency measure, and for as long as the software is required to read or process archived data. + +Any decision to upgrade to a new release should take into account the business requirements for the change and the security of the release (e.g. the introduction of new information security functionality or the number and severity of information security vulnerabilities affecting the current version). Software patches should be applied when they can help to remove or reduce information security vulnerabilities (see >8.8and >8.19>). + +Computer software can rely on externally supplied software and packages (e.g. software programs using modules which are hosted on external sites), which should be monitored and controlled to avoid unauthorized changes, because they can introduce information security vulnerabilities. + +Vendor supplied software used in operational systems should be maintained at a level supported by the supplier. Over time, software vendors will cease to support older versions of software. The organization should consider the risks of relying on unsupported software. Open source software used in operational systems should be maintained to the latest appropriate release of the software. Over time, open source code can cease to be maintained but is still available in an open source software repository. The organization should also consider the risks of relying on unmaintained open source software when used in operational systems. + +When suppliers are involved in installing or updating software, physical or logical access should only be given when necessary and with appropriate authorization. The supplier’s activities should be monitored (see 5.22). + +The organization should define and enforce strict rules on which types of software users can install. + +The principle of least privilege should be applied to software installation on operational systems. The organization should identify what types of software installations are permitted (e.g. updates and security patches to existing software) and what types of installations are prohibited (e.g. software that is only for personal use and software whose pedigree with regard to being potentially malicious is unknown or suspect). These privileges should be granted based on the roles of the users concerned. + +**Other information** +No other information. + +## 8.20 Networks security + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +|-------------------|------------------------------------------|-----------------------|----------------------------------|--------------------| +| #Preventive #Detective | #Confidentiality #Integrity #Availability | #Protect #Detect | #System_and_network_security | #Protection | + +**Control** + +Networks and network devices should be secured, managed and controlled to protect information in systems and applications. + +**Purpose** + +To protect information in networks and its supporting information processing facilities from compromise via the network. + +**Guidance** + +Controls should be implemented to ensure the security of information in networks and to protect connected services from unauthorized access. In particular, the following items should be considered: + +a\) the type and classification level of information that the network can support; + +b\) establishing responsibilities and procedures for the management of networking equipment and devices; + +c\) maintaining up to date documentation including network diagrams and configuration files of devices (e.g. routers, switches); + +d\) separating operational responsibility for networks from ICT system operations where appropriate (see 5.3); + +e\) establishing controls to safeguard the confidentiality and integrity of data passing over public networks, third-party networks or over wireless networks and to protect the connected systems and applications (see >5.22>, >8.24>, >5.14and >6.6>). Additional controls can also be required to maintain the availability of the network services and computers connected to the network; + +f\) appropriately logging and monitoring to enable recording and detection of actions that can affect, or are relevant to, information security (see >8.16and >8.15>); + +g\) closely coordinating network management activities both to optimize the service to the organization and to ensure that controls are consistently applied across the information processing infrastructure; + +h\) authenticating systems on the network; + +i\) res tricting and filtering systems connection to the network (e.g. using firewalls); + +j\) detecting, restricting and authenticating the connection of equipment and devices to the network; + +k\) hardening of network devices; + +l\) segregating network administration channels from other network traffic; + +m\) temporarily isolating critical subnetworks (e.g. with drawbridges) if the network is under attack; + +n\) disabling vulnerable network protocols. + +The organization should ensure that appropriate security controls are applied to the use of virtualized networks. Virtualized networks also cover software-defined networking (SDN, SD-WAN). Virtualized networks can be desirable from a security viewpoint, since they can permit logical separation of communication taking place over physical networks, particularly for systems and applications that are implemented using distributed computing. + +**Other information** + +Additional information on network security can be found in the ISO/IEC 27033 series. More information concerning virtualized networks can be found in ISO/IEC TS 23167. + +## 8.21 Security of network services + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +| -------------- | ---------------------------------------- | --------------------- | ---------------------------------- | ------------------ | +| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #System_and_network_security | #Protection | + +**Control** +Security mechanisms, service levels and service requirements of network services should be identified, implemented and monitored. + +**Purpose** +To ensure security in the use of network services. + +**Guidance** +The security measures necessary for particular services, such as security features, service levels and service requirements, should be identified and implemented (by internal or external network service providers). The organization should ensure that network service providers implement these measures. + +The ability of the network service provider to manage agreed services in a secure way should be determined and regularly monitored. The right to audit should be agreed between the organization and the provider. The organization should also consider third-party attestations provided by service providers to demonstrate they maintain appropriate security measures. + +Rules on the use of networks and network services should be formulated and implemented to cover: + +a\) the networks and network services which are allowed to be accessed; + +b\) authentication requirements for accessing various network services; + +c\) authorization procedures for determining who is allowed to access which networks and networked services; + +d\) net work management and technological controls and procedures to protect access to network connections and network services; + +e\) the means used to access networks and network services \[e.g. use of virtual private network (VPN) or wireless network\]; + +f\) time, location and other attributes of the user at the time of the access; + +g\) monitoring of the use of network services. + +The following security features of network services should be considered: + +a\) technology applied for security of network services, such as authentication, encryption and network connection controls; + +b\) technical parameters required for secured connection with the network services in accordance with the security and network connection rules; + +c\) caching (e.g. in a content delivery network) and its parameters that allow users to choose the use of caching in accordance with performance, availability and confidentiality requirements; + +d\) procedures for the network service usage to restrict access to network services or applications, where necessary. + +**Other information** + +Network services include the provision of connections, private network services and managed network security solutions such as firewalls and intrusion detection systems. These services can range from simple unmanaged bandwidth to complex value-added offerings. + +More guidance on a framework for access management is given in ISO/IEC 29146. + +## 8.22 Segregation of networks + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +| -------------- | ---------------------------------------- | --------------------- | ---------------------------------- | ------------------ | +| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #System_and_network_security | #Protection | + +**Control** + +Groups of information services, users and information systems should be segregated in the organization’s networks. + +**Purpose** + +To split the network in security boundaries and to control traffic between them based on business needs. + +**Guidance** + +The organization should consider managing the security of large networks by dividing them into separate network domains and separating them from the public network (i.e. internet). The domains can be chosen based on levels of trust, criticality and sensitivity (e.g. public access domain, desktop domain, server domain, low- and high-risk systems), along organizational units (e.g. human resources, finance, marketing) or some combination (e.g. server domain connecting to multiple organizational units). The segregation can be done using either physically different networks or by using different logical networks. + +The perimeter of each domain should be well-defined. If access between network domains is allowed, it should be controlled at the perimeter using a gateway (e.g. firewall, filtering router). The criteria for segregation of networks into domains, and the access allowed through the gateways, should be based on an assessment of the security requirements of each domain. The assessment should be in accordance with the topic-specific policy on access control (see 5.15), access requirements, value and classification of information processed and take account of the relative cost and performance impact of incorporating suitable gateway technology. + +Wireless networks require special treatment due to the poorly-defined network perimeter. Radio coverage adjustment should be considered for segregation of wireless networks. For sensitive environments, consideration should be made to treat all wireless access as external connections and to segregate this access from internal networks until the access has passed through a gateway in accordance with network controls (see 8.20) before granting access to internal systems. Wireless access network for guests should be segregated from those for personnel if personnel only use controlled user endpoint devices compliant to the organization’s topic-specific policies. WiFi for guests should have at least the same restrictions as WiFi for personnel, in order to discourage the use of guest WiFi by personnel. + +**Other information** + +Networks often extend beyond organizational boundaries, as business partnerships are formed that require the interconnection or sharing of information processing and networking facilities. Such extensions can increase the risk of unauthorized access to the organization’s information systems that use the network, some of which require protection from other network users because of their sensitivity or criticality. + +## 8.23 Web filtering + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +| -------------- | ---------------------------------------- | --------------------- | -------------------------------- | ------------------ | +| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #System_and_network_security | #Protection | + +**Control** +Access to external websites should be managed to reduce exposure to malicious content. + +**Purpose** +To protect systems from being compromised by malware and to prevent access to unauthorized web resources. + +**Guidance** +The organization should reduce the risks of its personnel accessing websites that contain illegal information or are known to contain viruses or phishing material. A technique for achieving this works by blocking the IP address or domain of the website(s) concerned. Some browsers and anti-malware technologies do this automatically or can be configured to do so. + +The organization should identify the types of websites to which personnel should or should not have access. The organization should consider blocking access to the following types of websites: + +a\) websites that have an information upload function unless permitted for valid business reasons; + +b\) known or suspected malicious websites (e.g. those distributing malware or phishing contents); + +c\) command and control servers; + +d\) malicious website acquired from threat intelligence (see 5.7); + +e\) websites sharing illegal content. + +Prior to deploying this control, the organization should establish rules for safe and appropriate use of online resources, including any restriction to undesirable or inappropriate websites and web-based applications. The rules should be kept up-to-date. + +Training should be given to personnel on the secure and appropriate use of online resources including access to the web. The training should include the organization’s rules, contact point for raising security concerns, and exception process when restricted web resources need to be accessed for legitimate business reasons. Training should also be given to personnel to ensure that they do not overrule any browser advisory that reports that a website is not secure but allows the user to proceed. + +**Other information** + +Web filtering can include a range of techniques including signatures, heuristics, list of acceptable websites or domains, list of prohibited websites or domains and bespoke configuration to help prevent malicious software and other malicious activity from attacking the organization’s network and systems. + +## 8.24 Use of cryptography + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +| -------------- | ---------------------------------------- | --------------------- | ------------------------- | --------------- | +| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Secure_configuration | #Protection | + +**Control** + +Rules for the effective use of cryptography, including cryptographic key management, should be defined and implemented. + +**Purpose** + +To ensure proper and effective use of cryptography to protect the confidentiality, authenticity or integrity of information according to business and information security requirements, and taking into consideration legal, statutory, regulatory and contractual requirements related to cryptography. + +**Guidance** + +General + +When using cryptography, the following should be considered: + +a\) the topic-specific policy on cryptography defined by the organization, including the general principles for the protection of information. A topic-specific policy on the use of cryptography is necessary to maximize the benefits and minimize the risks of using cryptographic techniques and to avoid inappropriate or incorrect use; + +b\) identifying the required level of protection and the classification of the information andconsequently establishing the type, strength and quality of the cryptographic algorithms required; + +c\) the use of cryptography for protection of information held on mobile user endpoint devices or storage media and transmitted over networks to such devices or storage media; + +d\) the approach to key management, including methods to deal with the generation and protection of cryptographic keys and the recovery of encrypted information in the case of lost, compromised or damaged keys; + +e\) roles and responsibilities for: + + 1\) the implementation of the rules for the effective use of cryptography; + 2\) the key management, including key generation (see 8.24); + +f\) the standards to be adopted, as well as cryptographic algorithms, cipher strength, cryptographic solutions and usage practices that are approved or required for use in the organization; + +g\) the impact of using encrypted information on controls that rely on content inspection (e.g. malware detection or content filtering). + +When implementing the organization’s rules for effective use of cryptography, the regulations and national restrictions that can apply to the use of cryptographic techniques in different parts of the world should be taken into consideration as well as the issues of trans-border flow of encrypted information (see 5.31). + +The contents of service level agreements or contracts with external suppliers of cryptographic services (e.g. with a certification authority) should cover issues of liability, reliability of services and response times for the provision of services (see 5.22). + + +Key management + +Appropriate key management requires secure processes for generating, storing, archiving, retrieving, distributing, retiring and destroying cryptographic keys. + +A key management system should be based on an agreed set of standards, procedures and secure methods for: + +a\) generating keys for different cryptographic systems and different applications; + +b\) issuing and obtaining public key certificates; + +c\) distributing keys to intended entities, including how to activate keys when received; + +d\) storing keys, including how authorized users obtain access to keys; + +e\) changing or updating keys including rules on when to change keys and how this will be done; + +f\) dealing with compromised keys; + +g\) revoking keys including how to withdraw or deactivate keys \[e.g. when keys have been compromised or when a user leaves an organization (in which case keys should also be archived)\]; + +h\) recovering keys that are lost or corrupted; + +i\) backing up or archiving keys; + +j\) destroying keys; + +k\) logging and auditing of key management related activities; + +l\) setting activation and deactivation dates for keys so that the keys can only be used for the period of time according to the organization's rules on key management; + +m\) handling legal requests for access to cryptographic keys (e.g. encrypted information can be required to be made available in an unencrypted form as evidence in a court case). + +All cryptographic keys should be protected against modification and loss. In addition, secret and private keys need protection against unauthorized use as well as disclosure. Equipment used to generate, store and archive keys should be physically protected. + +In addition to integrity, for many use cases, the authenticity of public keys should also be considered. + + +**Other information** + +The authenticity of public keys is usually addressed by public key management processes using certificate authorities and public key certificates, but it is also possible to address it by using technologies such as applying manual processes for small number keys. + +Cryptography can be used to achieve different information security objectives, for example: + +a\) confidentiality: using encryption of information to protect sensitive or critical information, either stored or transmitted; + +b\) integrity or authenticity: using digital signatures or message authentication codes to verify the authenticity or integrity of stored or transmitted sensitive or critical information. Using algorithms for the purpose of file integrity checking; + +c\) non-repudiation: using cryptographic techniques to provide evidence of the occurrence or non-occurrence of an event or action; + +d\) authentication: using cryptographic techniques to authenticate users and other system entities requesting access to or transacting with system users, entities and resources. + +The ISO/IEC 11770 series provides further information on key management. + +## 8.25 Secure development life cycle + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +| -------------- | ---------------------------------------- | --------------------- | ----------------------------------------------------- | --------------- | +| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Application_security #System_and_network_security | #Protection | + +**Control** +Rules for the secure development of software and systems should be established and applied. + +**Purpose** +To ensure information security is designed and implemented within the secure development life cycle of software and systems. + +**Guidance** + +Secure development is a requirement to build up a secure service, architecture, software and system. To achieve this, the following aspects should be considered: + +a\) separation of development, test and production environments (see 8.31); + +b\) guidance on the security in the software development life cycle: + +1\) security in the software development methodology (see >8.28and >8.27>); + +2\) secure coding guidelines for each programming language used (see 8.28); + +c\) security requirements in the specification and design phase (see 5.8); + +d\) security checkpoints in projects (see 5.8); + +e\) system and security testing, such as regression testing, code scan and penetration tests (see 8.29); + +f\) secure repositories for source code and configuration (see >8.4and >8.9>); + +g\) security in the version control (see 8.32); + +h\) required application security knowledge and training (see 8.28); + +i\) dev elopers’ capability for preventing, finding and fixing vulnerabilities (see 8.28); + +j\) licensing requirements and alternatives to ensure cost-effective solutions while avoiding future licensing issues (see 5.32). + +If development is outsourced, the organization should obtain assurance that the supplier complies with the organization’s rules for secure development (see 8.30). + +**Other information** + +Development can also take place inside applications, such as office applications, scripting, browsers and databases. + +## 8.26 Application security requirements** + + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +| -------------- | ---------------------------------------- | --------------------- | ----------------------------------------------------- | --------------- | +| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Application_security #System_and_network_security | #Protection #defence | + +**Control** + +Information security requirements should be identified, specified and approved when developing or acquiring applications. + +**Purpose** + +To ensure all information security requirements are identified and addressed when developing or acquiring applications. + +**Guidance** + +General + +Application security requirements should be identified and specified. These requirements are usually determined through a risk assessment. The requirements should be developed with the support of information security specialists. + +Application security requirements can cover a wide range of topics, depending on the purpose of the application. + +Application security requirements should include, as applicable: + +a\) level of trust in identity of entities \[e.g. through authentication (see >5.17>, >8.2and >8.5>)\]; + +b\) identifying the type of information and classification level to be processed by the application; + +c\) need for segregation of access and level of access to data and functions in the application; + +d\) resilience against malicious attacks or unintentional disruptions \[e.g. protection against buffer overflow or structured query language (SQL) injections\]; + +e\) legal, statutory and regulatory requirements in the jurisdiction where the transaction is generated, processed, completed or stored; + +f\) need for privacy associated with all parties involved; + +g\) the protection requirements of any confidential information; + +h\) protection of data while being processed, in transit and at rest; + +i\) need to securely encrypt communications between all involved parties; + +j\) input controls, including integrity checks and input validation; + +k\) automated controls (e.g. approval limits or dual approvals); + +l\) output controls, also considering who can access outputs and its authorization; + +m\) restrictions around content of "free-text" fields, as these can lead to uncontrolled storage of confidential data (e.g. personal data); + +n\) requirements derived from the business process, such as transaction logging and monitoring, nonrepudiation requirements; + +o\) requirements mandated by other security controls (e.g. interfaces to logging and monitoring or data leakage detection systems); p) error message handling. + +Transactional services + +Additionally, for applications offering transactional services between the organization and a partner, the following should be considered when identifying information security requirements: + +a\) the level of trust each party requires in each other’s claimed identity; + +b\) the level of trust required in the integrity of information exchanged or processed and the mechanisms for identification of lack of integrity (e.g. cyclic redundancy check, hashing, digital signatures); + +c\) authorization processes associated with who can approve contents of, issue or sign key transactional documents; + +d\) confidentiality, integrity, proof of dispatch and receipt of key documents and the non-repudiation (e.g. contracts associated with tendering and contract processes); + +e\) the confidentiality and integrity of any transactions (e.g. orders, delivery address details and confirmation of receipts); + +f\) requirements on how long to maintain a transaction confidential; + +g\) insurance and other contractual requirements. + +Electronic ordering and payment applications + +Additionally, for applications involving electronic ordering and payment, the following should be considered: + +a\) requirements for maintaining the confidentiality and integrity of order information; + +b\) the degree of verification appropriate to verify payment information supplied by a customer; + +c\) avoidance of loss or duplication of transaction information; + +d\) storing transaction details outside of any publicly accessible environment (e.g. on a storage platform existing on the organizational intranet, and not retained and exposed on electronic storage media directly accessible from the internet); + +e\) where a trusted authority is used (e.g. for the purposes of issuing and maintaining digital signatures or digital certificates) security is integrated and embedded throughout the entire end- to-end certificate or signature management process. + +Several of the above considerations can be addressed by the application of cryptography (see [[8.24]]), taking into consideration legal requirements (see [[5.31]], [[5.36]], especially see [[5.31]] for cryptography legislation). + +**Other information** + +Applications accessible via networks are subject to a range of network related threats, such as fraudulent activities, contract disputes or disclosure of information to the public; incomplete transmission, mis- routing, unauthorized message alteration, duplication or replay. Therefore, detailed risk assessments and careful determination of controls are indispensable. Controls required often include cryptographic methods for authentication and securing data transfer. + + +## 8.27 Secure system architecture and engineering principles + + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +| -------------- | ---------------------------------------- | --------------------- | ----------------------------------------------------- | --------------- | +| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Application_security #System_and_network_security | #Protection | + +**Control** + +Principles for engineering secure systems should be established, documented, maintained and applied to any information system development activities. + +**Purpose** + +To ensure information systems are securely designed, implemented and operated within the development life cycle. + +**Guidance** + +Security engineering principles should be established, documented and applied to information system engineering activities. Security should be designed into all architecture layers (business, data, applications and technology). New technology should be analysed for security risks and the design should be reviewed against known attack patterns. + +Secure engineering principles provide guidance on user authentication techniques, secure session control and data validation and sanitisation. + +Secure system engineering principles should include analysis of: + +a\) the full range of security controls required to protect information and systems against identified threats; +b\) the capabilities of security controls to prevent, detect or respond to security events; +c\) specific security controls required by particular business processes (e.g. encryption of sensitive information, integrity checking and digitally signing information); +d\) where and how security controls are to be applied (e.g. by integrating with a security architecture and the technical infrastructure); +e\) how individual security controls (manual and automated) work together to produce an integrated set of controls. + +Security engineering principles should take account of: + +a\) the need to integrate with a security architecture; +b\) tec hnical security infrastructure \[e.g. public key infrastructure (PKI), identity and access management (IAM), data leakage prevention and dynamic access management\]; +c\) capability of the organization to develop and support the chosen technology; +d\) cost, time and complexity of meeting security requirements; +e\) current good practices. + +Secure system engineering should involve: + +a\) the use of security architecture principles, such as “security by design”, “defence in depth”, “security by default”, “default deny”, “fail securely”, “distrust input from external applications”, “security in deployment”, “assume breach”, "least privilege", “usability and manageability” and “least functionality”; +b\) a security-oriented design review to help identify information security vulnerabilities, ensure security controls are specified and meet security requirements; +c\) documentation and formal acknowledgement of security controls that do not fully meet requirements (e.g. due to overriding safety requirements); +d\) hardening of systems. + +The organization should consider "zero trust" principles such as: + +a\) assuming the organization’s information systems are already breached and thus not be reliant on network perimeter security alone; +b\) employing a “never trust and always verify” approach for access to information systems; +c\) ensuring that requests to information systems are encrypted end-to-end; +d\) verifying each request to an information system as if it originated from an open, external network, even if these requests originated internal to the organization (i.e. not automatically trusting anything inside or outside its perimeters); +e\) using "least privilege" and dynamic access control techniques (see >5.15>, >5.18and >8.2>). This includes authenticating and authorizing requests for information or to systems based on contextual information such as authentication information (see 5.17), user identities (see 5.16), data about the user endpoint device, and data classification (see 5.12); +f\) always authenticating requesters and always validating authorization requests to information systems based on information including authentication information (see 5.17) and user identities (>5.16>), data about the user endpoint device, and data classification (see 5.12), for example enforcing strong authentication (e.g. multi-factor, see >8.5>). + +The established security engineering principles should be applied, where applicable, to outsourced development of information systems through the contracts and other binding agreements between the organization and the supplier to whom the organization outsources. The organization should ensure that suppliers’ security engineering practices align with the organization’s needs. + +The security engineering principles and the established engineering procedures should be regularly reviewed to ensure that they are effectively contributing to enhanced standards of security within the engineering process. They should also be regularly reviewed to ensure that they remain up-to- date in terms of combatting any new potential threats and in remaining applicable to advances in the technologies and solutions being applied. + + +**Other information** + +Secure engineering principles can be applied to the design or configuration of a range of techniques, such as: + +— fault tolerance and other resilience techniques; +— segregation (e.g. through virtualization or containerization); +— tamper resistance. + +Secure virtualization techniques can be used to prevent interference between applications running on the same physical device. If a virtual instance of an application is compromised by an attacker, only that instance is affected. The attack has no effect on any other application or data. + +Tamper resistance techniques can be used to detect tampering of information containers, whether physical (e.g. a burglar alarm) or logical (e.g. a data file). A characteristic of such techniques is that there is a record of the attempt to tamper with the container. In addition, the control can prevent the successful extraction of data through its destruction (e.g. device memory can be deleted). + +## 8.28 Secure coding + +**Control** + +Secure coding principles should be applied to software development. **Purpose** + +To ensure software is written securely thereby reducing the number of potential information security vulnerabilities in the software. + +**Guidance** + +>General> + +The organization should establish organization-wide processes to provide good governance for secure coding. A minimum secure baseline should be established and applied. Additionally, such processes and governance should be extended to cover software components from third parties and open source software. + +The organization should monitor real world threats and up-to-date advice and information on software vulnerabilities to guide the organization’s secure coding principles through continual improvement and learning. This can help with ensuring effective secure coding practices are implemented to combat the fast-changing threat landscape. + +>Planning and before coding> + +Secure coding principles should be used both for new developments and in reuse scenarios. These principles should be applied to development activities both within the organization and for products and services supplied by the organization to others. Planning and prerequisites before coding should include: + +a\) organization-specific expectations and approved principles for secure coding to be used for both in-house and outsourced code developments; + +b\) common and historical coding practices and defects that lead to information security vulnerabilities; + +c\) configuring development tools, such as integrated development environments (IDE), to help enforce + +the creation of secure code; + +d\) following guidance issued by the providers of development tools and execution environments as + +applicable; + +e\) maintenance and use of updated development tools (e.g. compilers); + +f\) qualification of developers in writing secure code; + +g\) secure design and architecture, including threat modelling; + +h\) secure coding standards and where relevant mandating their use; + +i\) use of controlled environments for development. + +>During coding> + +Considerations during coding should include: + +a\) secure coding practices specific to the programming languages and techniques being used; + +b\) using secure programming techniques, such as pair programming, refactoring, peer review, + +security iterations and test-driven development; + +c\) using structured programming techniques; + +d\) documenting code and removing programming defects, which can allow information security + +vulnerabilities to be exploited; + +e\) prohibiting the use of insecure design techniques (e.g. the use of hard-coded passwords, unapproved + +code samples and unauthenticated web services). + +Testing should be conducted during and after development (see 8.29). Static application security testing (SAST) processes can identify security vulnerabilities in software. + +Before software is made operational, the following should be evaluated: + +a\) attack surface and the principle of least privilege; + +b\) conducting an analysis of the most common programming errors and documenting that these have + +been mitigated. + +>Review and maintenance> + +After code has been made operational: + +a\) updates should be securely packaged and deployed; + +b\) reported information security vulnerabilities should be handled (see 8.8); + +c\) errors and suspected attacks should be logged and logs regularly reviewed to make adjustments to + +the code as necessary; + +d\) source code should be protected against unauthorized access and tampering (e.g. by using configuration management tools, which typically provide features such as access control and version control). + +If using external tools and libraries, the organization should consider: + +a\) ensuring that external libraries are managed (e.g. by maintaining an inventory of libraries used and their versions) and regularly updated with release cycles; + +b\) selection, authorization and reuse of well-vetted components, particularly authentication and + +cryptog raphic components; + +c\) the licence, security and history of external components; + +d\) ensuring that software is maintainable, tracked and originates from proven, reputable sources; + +e\) sufficiently long-term availability of development resources and artefacts. + +Where a software package needs to be modified the following points should be considered: + +a\) the risk of built-in controls and integrity processes being compromised; + +b\) whether to obtain the consent of the vendor; + +c\) the possibility of obtaining the required changes from the vendor as standard program updates; + +d\) the impact if the organization becomes responsible for the future maintenance of the software as a + +result of changes; + +e\) compatibility with other software in use. + +**Other information** + +A guiding principle is to ensure security-relevant code is invoked when necessary and is tamper- resistant. Programs installed from compiled binary code also have these properties but only for data held within the application. For interpreted languages, the concept only works when the code is executed on a server that is otherwise inaccessible by the users and processes that use it, and that its data is held in a similarly protected database. For example, the interpreted code can be run on a cloud service where access to the code itself requires administrator privileges. Such administrator access should be protected by security mechanisms such as just-in-time administration principles and strong authentication. If the application owner can access scripts by direct remote access to the server, so in principle can an attacker. Webservers should be configured to prevent directory browsing in such cases. + +Application code is best designed on the assumption that it is always subject to attack, through error or malicious action. In addition, critical applications can be designed to be tolerant of internal faults. For example, the output from a complex algorithm can be checked to ensure that it lies within safe bounds before the data is used in an application such as a safety or financial critical application. The code that performs the boundary checks is simple and therefore much easier to prove correctness. + +Some web applications are susceptible to a variety of vulnerabilities that are introduced by poor design and coding, such as database injection and cross-site scripting attacks. In these attacks, requests can be manipulated to abuse the webserver functionality. + +More information on ICT security evaluation can be found in the ISO/IEC 15408 series. + + + +## 8.29 Security testing in development and acceptance + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +| -------------- | ---------------------------------------- | --------------------- | ----------------------------------------------------- | --------------- | +| #Preventive | #Confidentiality #Integrity #Availability | #Identify | #Application_security #Information_security_assurance #System_and_network_security | #Protection | + +**Control** +Security testing processes should be defined and implemented in the development life cycle. + +**Purpose** +To validate if information security requirements are met when applications or code are deployed to the production environment. + +**Guidance** +New information systems, upgrades and new versions should be thoroughly tested and verified during the development processes. Security testing should be an integral part of the testing for systems or components. + +Security testing should be conducted against a set of requirements, which can be expressed as functional or non-functional. Security testing should include testing of: + +a\) security functions \[e.g. user authentication (see 8.5), access restriction (see 8.3) and use of cryptography (see 8.24)\]; + +b\) secure coding (see 8.28); + +c\) secure configurations (see >8.9>, >8.20and >8.22>) including that of operating systems, firewalls and other security components. + +Test plans should be determined using a set of criteria. The extent of testing should be in proportion to the importance, nature of the system and the potential impact of the change being introduced. The test plan should include: + +a\) detailed schedule of activities and tests; + +b\) inputs and expected outputs under a range of conditions; + +c\) criteria to evaluate the results; + +d\) decision for further actions as necessary. + +The organization can leverage automated tools, such as code analysis tools or vulnerability scanners, and should verify the remediation of security related defects. + +For in-house developments, such tests should initially be performed by the development team. Independent acceptance testing should then be undertaken to ensure that the system works as expected and only as expected (see 5.8). The following should be considered: + +a\) performing code review activities as a relevant element for testing for security flaws, including unanticipated inputs and conditions; + +b\) performing vulnerability scanning to identify insecure configurations and system vulnerabilities; + +c\) performing penetration testing to identify insecure code and design. + +For outsourced development and purchasing components, an acquisition process should be followed. Contracts with the supplier should address the identified security requirements (see 5.20). Products and services should be evaluated against these criteria before acquisition. + +Testing should be performed in a test environment that matches the target production environment as closely as possible to ensure that the system does not introduce vulnerabilities to the organization’s environment and that the tests are reliable (see 8.31). + +**Other information** + +Multiple test environments can be established, which can be used for different kinds of testing (e.g. functional and performance testing). These different environments can be virtual, with individual configurations to simulate a variety of operating environments. + +Testing and monitoring of test environments, tools and technologies also needs to be considered to ensure effective testing. The same considerations apply to monitoring of the monitoring systems deployed in development, test and production settings. Judgeme nt is needed, guided by the sensitivity of the systems and data, to determine how many layers of meta-testing are useful. + +## 8.30 Outsourced development + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +| :--- | :--- | :--- | :--- | :--- | +| #Preventive #Detective | #Confidentiality
#Integrity #Availability | #Identify #Protect
#Detect | #System_and_network_security #Application_security #Supplier_relationships_security | #Governance_and_Ecosystem #Protection | + +**Control** + +The organization should direct, monitor and review the activities related to outsourced system development. + +**Purpose** + +To ensure information security measures required by the organization are implemented in outsourced system development. + +**Guidance** + +Where system development is outsourced, the organization should communicate and agree requirements and expectations, and continually monitor and review whether the delivery of outsourced work meets these expectations. The following points should be considered across the organization’s entire external supply chain: + +a\) licensing agreements, code ownership and intellectual property rights related to the outsourced content (see 5.32); + +b\) contractual requirements for secure design, coding and testing practices (see >8.25to >8.29>); + +c\) provision of the threat model to consider by external developers; + +d\) acceptance testing for the quality and accuracy of the deliverables (see 8.29); + +e\) provision of evidence that minimum acceptable levels of security and privacy capabilities are established (e.g. assurance reports); + +f\) provision of evidence that sufficient testing has been applied to guard against the presence of malicious content (both intentional and unintentional) upon delivery; + +g\) provision of evidence that sufficient testing has been applied to guard against the presence of known vulnerabilities; + +h\) escrow agreements for the software source code (e.g. if the supplier goes out of business); + +i\) contractual right to audit development processes and controls; + +j\) security requirements for the development environment (see 8.31); + +k\) taking consideration of applicable legislation (e.g. on protection of personal data). + +**Other information** + +Further information on supplier relationships can be found in the ISO/IEC 27036 series. + +## 8.31 Separation of development, test and production environments + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +| --- | --- | --- | --- | --- | +| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Application_security #System_and_network_security | #Protection | + +**Control** + +Development, testing and production environments should be separated and secured. + +**Purpose** + +To protect the production environment and data from compromise by development and test activities. + +**Guidance** + +The level of separation between production, testing and development environments that is necessary to prevent production problems should be identified and implemented. + +The following items should be considered: + +a\) adequately separating development and production systems and operating them in different domains (e.g. in separate virtual or physical environments); + +b\) defining, documenting and implementing rules and authorization for the deployment of software from development to production status; + +c\) testing changes to production systems and applications in a testing or staging environment prior to being applied to production systems (see 8.29); + +d\) not testing in production environments except in circumstances that have been defined and approved; + +e\) compilers, editors and other development tools or utility programs not being accessible from production systems when not required; + +f\) displaying appropriate environment identification labels in menus to reduce the risk of error; + +g\) not copying sensitive information into the development and testing system environments unless equivalent controls are provided for the development and testing systems. + +In all cases, development and testing environments should be protected considering: + +a\) patching and updating of all the development, integration and testing tools (including builders, integrators, compilers, configuration systems and libraries); + +b\) secure configuration of systems and software; + +c\) control of access to the environments; + +d\) monitoring of change to the environment and code stored therein; + +e\) secure monitoring of the environments; + +f\) taking backups of the environments. + +A single person should not have the ability to make changes to both development and production without prior review and approval. This can be achieved for example through segregation of access rights or through rules that are monitored. In exceptional situations, additional measures such as detailed logging and real-time monitoring should be implemented in order to detect and act on unauthorized changes. + +**Other information** +Without adequate measures and procedures, developers and testers having access to production systems can introduce significant risks (e.g. unwanted modification of files or system environment, system failure, running unauthorized and untested code in product ion systems, disclosure of confidential data, data integrity and availability issues). There is a need to maintain a known and stable environment in which to perform meaningful testing and to prevent inappropriate developer access to the production environment. + +Measures and procedures include carefully designed roles in conjunction with implementing segregation of duty requirements and having adequate monitoring processes in place. + +Development and testing personnel also pose a threat to the confidentiality of production information. Development and testing activities can cause unintended changes to software or information if they share the same computing environment. Separating development, testing and production environments is therefore desirable to reduce the risk of accidental change or unauthorized access to production software and business data (see >8.33for the protection of test information). + +In some cases, the distinction between development, test and production environments can be deliberately blurred and testing can be carried out in a development environment or through controlled rollouts to live users or servers (e.g. small population of pilot users). In some cases, product testing can occur through live use of the product inside the organization. Furthermore, to reduce downtime of live deployments, two identical production environments can be supported where only one is live at any one time. + +Supporting processes for the use of production data in development and testing environments (>8.33>) are necessary. + +Organizations can also consider the guidance provided in this section for training environments when conducting end user training. + +## 8.32 Change management + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +| -------------- | ---------------------------------------- | --------------------- | ----------------------------------------------------- | --------------- | +| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Application_security #System_and_network_security | #Protection | + +**Control** + +Changes to information processing facilities and information systems should be subject to change management procedures. + +**Purpose** + +To preserve information security when executing changes. + +**Guidance** + +Introduction of new systems and major changes to existing systems should follow agreed rules and a formal process of documentation, specification, testing, quality control and managed implementation. Management responsibilities and procedures should be in place to ensure satisfactory control of all changes. + +Change control procedures should be documented and enforced to ensure the confidentiality, integrity and availability of information in information processing facilities and information systems, for the entire system development life cycle from the early design stages through all subsequent maintenance efforts. + +Wherever practicable, change control procedures for ICT infrastructure and software should be integrated. + +The change control procedures should include: + +a\) planning and assessing the potential impact of changes considering all dependencies; + +b\) authorization of changes; + +c\) communicating changes to relevant interested parties; + +d\) tests and acceptance of tests for the changes (see 8.29); + +e\) implementation of changes including deployment plans; + +f\) emergency and contingency considerations including fall-back procedures; + +g\) maintaining records of changes that include all of the above; + +h\) ensuring that operating documentation (see 5.37) and user procedures are changed as necessary to remain appropriate; + +i\) ensuring that ICT continuity plans and response and recovery procedures (see 5.30) are changed as necessary to remain appropriate. + +**Other information** + +Inadequate control of changes to information processing facilities and information systems is a common cause of system or security failures. Changes to the production environment, especially when transferring software from development to operational environment, can impact on the integrity and availability of applications. + +Changing software can impact the production environment and vice versa. + +Good practice includes the testing of ICT components in an environment segregated from both the production and development environments (see 8.31). This provides a means of having control over new software and allowing additional protection of operational information that is used for testing purposes. This should include patches, service packs and other updates. + +Production environment includes operating systems, databases and middleware platforms. The control should be applied for changes of applications and infrastructures. + +## 8.33 Test information + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +| --- | --- | --- | --- | --- | +| #Preventive | #Confidentiality #Integrity | #Protect | #Information_protection | #Protection | + +**Control** +Test information should be appropriately selected, protected and managed. + +**Purpose** +To ensure relevance of testing and protection of operational information used for testing. + +**Guidance** +Test information should be selected to ensure the reliability of tests results and the confidentiality of the relevant operational information. Sensitive information (including personally identifiable information) should not be copied into the development and testing environments (see 8.31). + +The following guidelines should be applied to protect the copies of operational information, when used for testing purposes, whether the test environment is built in-house or on a cloud service: + +a\) applying the same access control procedures to test environments as those applied to operational environments; + +b\) having a separate authorization each time operational information is copied to a test environment; + +c\) logging the copying and use of operational information to provide an audit trail; + +d\) protecting sensitive information by removal or masking (see 8.11) if used for testing; + +e\) properly deleting (see 8.10) operational information from a test environment immediately after the testing is complete to prevent unauthorized use of test information. + +Test information should be securely stored (to prevent tampering, which can otherwise lead to invalid results) and only used for testing purposes. + +**Other information** + +System and acceptance testing can require substantial volumes of test information that are as close as possible to operational information. + +## 8.34 Protection of information systems during audit testing + +| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | +| --- | --- | --- | --- | --- | +| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #System_and_network_security #Information_protection | #Governance_and_Ecosystem #Protection | + +**Control** + +Audit tests and other assurance activities involving assessment of operational systems should be planned and agreed between the tester and appropriate management. + +**Purpose** + +To minimize the impact of audit and other assurance activities on operational systems and business processes. + +**Guidance** + +The following guidelines should be observed: + +a\) agreeing audit requests for access to systems and data with appropriate management; + +b\) agreeing and controlling the scope of technical audit tests; + +c\) limiting audit tests to read-only access to software and data. If read-only access is not available to obtain the necessary information, executing the test by an experienced administrator who has the necessary access rights on behalf of the auditor; + +d\) if access is granted, establishing and verifying the security requirements (e.g. antivirus and patching) of the devices used for accessing the systems (e.g. laptops or tablets) before allowing the access; + +e\) only allowing access other than read-only for isolated copies of system files, deleting them when the audit is completed, or giving them appropriate protection if there is an obligation to keep such files under audit documentation requirements; + +f\) identifying and agreeing on requests for special or additional processing, such as running audit tools; + +g\) running audit tests that can affect system availability outside business hours; + +h\) monitoring and logging all access for audit and test purposes. **Other information** + +Audit tests and other assurance activities can also happen on development and test systems, where such tests can impact for example the integrity of code or lead to disclosure of any sensitive information held in such environments. + + + +**A.1 General** + + + + + +**Annex A** + +(inform ative) + +**Using attributes** + +This annex provides a table to demonstrate the use of attributes as a way of creating different views of the controls. The five examples of attributes are (see 4.2): + +a\) Control types (#Preventive, \#Detective, \#Corrective) + +b\) Information security properties (#Confidentiality, \#Integrity, \#Availability) + +c\) Cybersecurity concepts (#Identify, \#Protect, \#Detect, \#Respond, \#Recover) + +d\) Operational capabilities (#Governance, \#Asset_management, \#Information_protection, \#Human\_ + +resource_security, \#Physical_security, \#System_and_network_security, \#Application_security, + +\#Secure_configuration, \#Identity_and_access_management, \#Threat_and_vulnerability\_ + +management, \#Continuity, \#Supplier_relationships_security, \#Legal_and_compliance, + +\#Information_security_event_management, \#Information_security_assurance) + +e\) Security domains (#Governance_and_Ecosystem, \#Protection, \#Defence, \#Resilience) >Table A.1contains a matrix of all controls in this document with their given attribute values. + +The filtering or sorting of the matrix can be achieved by using a tool such as a simple spreadsheet or a database, which can include more information like control text, guidance, organization-specific guidance or attributes (see >A.2>). + +**Table A.1 — Matrix of controls and attribute values** + + ++++++++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

ISO/

+

IEC 27002 control identifier

+
+

Control name

+
+

Control type

+
+

Information

+

security

+

properties

+
+

Cybersecurity

+

concepts

+
+

Operational

+

capabilities

+
+

Security

+

domains

+
+

5.1

+
+

Policies for information security

+
+

#Preventive

+
+

#Confidential- ity #Integrity #Availability

+
+

#Identify

+
+

#Governance

+
+

#Governance_ and_Ecosys- tem #Resil- ience

+
+

5.2

+
+

Information security roles and responsi- bilities

+
+

#Preventive

+
+

#Confidential- ity #Integrity #Availability

+
+

#Identify

+
+

#Governance

+
+

#Govern- ance_and_ Ecosystem #Protection #Resilience

+
+

5.3

+
+

Segregation of duties

+
+

#Preventive

+
+

#Confidential- ity #Integrity #Availability

+
+

#Protect

+
+

#Governance #Identity_and_ access_man- agement

+
+

#Governance_ and_Ecosys- tem

+
+

5.4

+
+

Management responsibili- ties

+
+

#Preventive

+
+

#Confidential- ity #Integrity #Availability

+
+

#Identify

+
+

#Governance

+
+

#Governance_ and_Ecosys- tem

+
+

5.5

+
+

Contact with authorities

+
+

#Preventive

+

#Corrective

+
+

#Confidential- ity #Integrity #Availability

+
+

#Identify #Pro- tect #Respond #Recover

+
+

#Governance

+
+

#Defence #Re- silience

+
+ + +**Table A.1** *(continued)* + + + ++++++++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

ISO/

+

IEC 27002 control identifier

+
+

Control name

+
+

Control type

+
+

Information

+

security

+

properties

+
+

Cybersecurity

+

concepts

+
+

Operational

+

capabilities

+
+

Security

+

domains

+
+

5.6

+
+

Contact with special inter- est groups

+
+

#Preventive

+

#Corrective

+
+

#Confidential- ity #Integrity #Availability

+
+

#Protect #Respond #Re- cover

+
+

#Governance

+
+

#Defence

+
+

5.7

+
+

Threat intelli- gence

+
+

#Preventive #Detective #Corrective

+
+

#Confidential- ity #Integrity #Availability

+
+

#Identify #De- tect #Respond

+
+

#Threat_and_ vulnerability_ management

+
+

#Defence #Re- silience

+
+

5.8

+
+

Information security in project man- agement

+
+

#Preventive

+
+

#Confidential- ity #Integrity #Availability

+
+

#Identify #Pro- tect

+
+

#Governance

+
+

#Governance_ and_Ecosys- tem #Protec- tion

+
+

5.9

+
+

Inventory of information and other associated assets

+
+

#Preventive

+
+

#Confidential- ity #Integrity #Availability

+
+

#Identify

+
+

#Asset_man- agement

+
+

#Governance_ and_Ecosys- tem #Protec- tion

+
+

5.10

+
+

Acceptable use of information and other associated assets

+
+

#Preventive

+
+

#Confidential- ity #Integrity #Availability

+
+

#Protect

+
+

#Asset_man- agement #Information_ protection

+
+

#Governance_ and_Ecosys- tem #Protec- tion

+
+

5.11

+
+

Return of assets

+
+

#Preventive

+
+

#Confidential- ity #Integrity #Availability

+
+

#Protect

+
+

#Asset_man- agement

+
+

#Protection

+
+

5.12

+
+

Classification

+

of information

+
+

#Preventive

+
+

#Confidential- ity #Integrity #Availability

+
+

#Identify

+
+

#Information_

+

protection

+
+

#Protection

+

#Defence

+
+

5.13

+
+

Labelling of information

+
+

#Preventive

+
+

#Confidential- ity #Integrity #Availability

+
+

#Protect

+
+

#Information_

+

protection

+
+

#Defence

+

#Protection

+
+

5.14

+
+

Information

+

transfer

+
+

#Preventive

+
+

#Confidential- ity #Integrity #Availability

+
+

#Protect

+
+

#Asset_man- agement #Information_ protection

+
+

#Protection

+
+

5.15

+
+

Access control

+
+

#Preventive

+
+

#Confidential- ity #Integrity #Availability

+
+

#Protect

+
+

#Identity_and_ access_man- agement

+
+

#Protection

+
+

5.16

+
+

Identity man- agement

+
+

#Preventive

+
+

#Confidential- ity #Integrity #Availability

+
+

#Protect

+
+

#Identity_and_ access_man- agement

+
+

#Protection

+
+

5.17

+
+

Authentication

+

information

+
+

#Preventive

+
+

#Confidential- ity #Integrity #Availability

+
+

#Protect

+
+

#Identity_and_ access_man- agement

+
+

#Protection

+
+

5.18

+
+

Access rights

+
+

#Preventive

+
+

#Confidential- ity #Integrity #Availability

+
+

#Protect

+
+

#Identity_and_ access_man- agement

+
+

#Protection

+
+

5.19

+
+

Information security in supplier rela- tionships

+
+

#Preventive

+
+

#Confidential- ity #Integrity #Availability

+
+

#Identify

+
+

#Supplier_re- lationships_se- curity

+
+

#Governance_ and_Ecosys- tem #Protec- tion

+
+ + + + + + + +**Table A.1** *(continued)* + + ++++++++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

ISO/

+

IEC 27002 control identifier

+
+

Control name

+
+

Control type

+
+

Information

+

security

+

properties

+
+

Cybersecurity

+

concepts

+
+

Operational

+

capabilities

+
+

Security

+

domains

+
+

5.20

+
+

Addressing information security with- in supplier agreements

+
+

#Preventive

+
+

#Confidential- ity #Integrity #Availability

+
+

#Identify

+
+

#Supplier_re- lationships_se- curity

+
+

#Governance_ and_Ecosys- tem #Protec- tion

+
+

5.21

+
+

Managing information security in

+

the ICT supply chain

+
+

#Preventive

+
+

#Confidential- ity #Integrity #Availability

+
+

#Identify

+
+

#Supplier_re- lationships_se- curity

+
+

#Governance_ and_Ecosys- tem #Protec- tion

+
+

5.22

+
+

Monitor- ing, review and change management of supplier services

+
+

#Preventive

+
+

#Confidential- ity #Integrity #Availability

+
+

#Identify

+
+

#Supplier_re- lationships_se- curity

+
+

#Governance_ and_Ecosys- tem #Protec- tion #Defence #Information_ security_as- surance

+
+

5.23

+
+

Information security for use of cloud services

+
+

#Preventive

+
+

#Confidential- ity #Integrity #Availability

+
+

#Protect

+
+

#Supplier_re- lationships_se- curity

+
+

#Governance_ and_Ecosys- tem #Protec- tion

+
+

5.24

+
+

Information security inci- dent manage- ment planning and prepara- tion

+
+

#Corrective

+
+

#Confidential- ity #Integrity #Availability

+
+

#Respond #Re- cover

+
+

#Governance #Informa- tion_securi- ty_event_man- agement

+
+

#Defence

+
+

5.25

+
+

Assessment and decision on informa- tion security events

+
+

#Detective

+
+

#Confidential- ity #Integrity #Availability

+
+

#Detect #Re- spond

+
+

#Informa- tion_securi- ty_event_man- agement

+
+

#Defence

+
+

5.26

+
+

Response to information security inci- dents

+
+

#Corrective

+
+

#Confidential- ity #Integrity #Availability

+
+

#Respond #Re- cover

+
+

#Informa- tion_securi- ty_event_man- agement

+
+

#Defence

+
+

5.27

+
+

Learning from information security inci- dents

+
+

#Preventive

+
+

#Confidential- ity #Integrity #Availability

+
+

#Identify #Pro- tect

+
+

#Informa- tion_securi- ty_event_man- agement

+
+

#Defence

+
+

5.28

+
+

Collection of evidence

+
+

#Corrective

+
+

#Confidential- ity #Integrity #Availability

+
+

#Detect #Re- spond

+
+

#Informa- tion_securi- ty_event_man- agement

+
+

#Defence

+
+

5.29

+
+

Information security dur- ing disruption

+
+

#Preventive

+

#Corrective

+
+

#Confidential- ity #Integrity #Availability

+
+

#Protect #Re- spond

+
+

#Continuity

+
+

#Protection

+

#Resilience

+
+

5.30

+
+

ICT readiness for business continuity

+
+

#Corrective

+
+

#Availability

+
+

#Respond

+
+

#Continuity

+
+

#Resilience

+
+ + +**Table A.1** *(continued)* + + + + ++++++++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

ISO/

+

IEC 27002 control identifier

+
+

Control name

+
+

Control type

+
+

Information

+

security

+

properties

+
+

Cybersecurity

+

concepts

+
+

Operational

+

capabilities

+
+

Security

+

domains

+
+

5.31

+
+

Legal, statuto- ry, regulatory and contrac- tual require- ments

+
+

#Preventive

+
+

#Confidential- ity #Integrity #Availability

+
+

#Identify

+
+

#Legal_and_

+

compliance

+
+

#Governance_ and_Ecosys- tem #Protec- tion

+
+

5.32

+
+

Intellectual property rights

+
+

#Preventive

+
+

#Confidential- ity #Integrity #Availability

+
+

#Identify

+
+

#Legal_and_

+

compliance

+
+

#Governance_ and_Ecosys- tem

+
+

5.33

+
+

Protection of records

+
+

#Preventive

+
+

#Confidential- ity #Integrity #Availability

+
+

#Identify #Pro- tect

+
+

#Legal_and_ compliance #Asset_man- agement #Information_ protection

+
+

#Defence

+
+

5.34

+
+

Privacy and protection of PII

+
+

#Preventive

+
+

#Confidential- ity #Integrity #Availability

+
+

#Identify #Pro- tect

+
+

#Information_ protection #Legal_and_ compliance

+
+

#Protection

+
+

5.35

+
+

Independent review of information security

+
+

#Preventive

+

#Corrective

+
+

#Confidential- ity #Integrity #Availability

+
+

#Identify #Pro- tect

+
+

#Information_ security_as- surance

+
+

#Governance_ and_Ecosys- tem

+
+

5.36

+
+

Compliance with policies, rules and standards for information security

+
+

#Preventive

+
+

#Confidential- ity #Integrity #Availability

+
+

#Identify #Pro- tect

+
+

#Legal_and_ compliance #Information_ security_as- surance

+
+

#Governance_ and_Ecosys- tem

+
+

5.37

+
+

Documented operating procedures

+
+

#Preventive

+

#Corrective

+
+

#Confidential- ity #Integrity #Availability

+
+

#Protect #Re- cover

+
+

#Asset_man- agement #Physi- cal_security #System_and_ network_secu- rity #Applica- tion_security #Secure_con- figuration #Identity_ and_access_ management #Threat_and_ vulnerability_ management #Continuity #Informa- tion_securi- ty_event_man- agement

+
+

#Governance_ and_Ecosys- tem #Protec- tion #Defence

+
+

6.1

+
+

Screening

+
+

#Preventive

+
+

#Confidential- ity #Integrity #Availability

+
+

#Protect

+
+

#Human_re- source_secu- rity

+
+

#Governance_ and_Ecosys- tem

+
+ + + + + + + +**Table A.1** *(continued)* + + ++++++++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

ISO/

+

IEC 27002 control identifier

+
+

Control name

+
+

Control type

+
+

Information

+

security

+

properties

+
+

Cybersecurity

+

concepts

+
+

Operational

+

capabilities

+
+

Security

+

domains

+
+

6.2

+
+

Terms and conditions of employment

+
+

#Preventive

+
+

#Confidential- ity #Integrity #Availability

+
+

#Protect

+
+

#Human_re- source_secu- rity

+
+

#Governance_ and_Ecosys- tem

+
+

6.3

+
+

Information security awareness, education and training

+
+

#Preventive

+
+

#Confidential- ity #Integrity #Availability

+
+

#Protect

+
+

#Human_re- source_secu- rity

+
+

#Governance_ and_Ecosys- tem

+
+

6.4

+
+

Disciplinary

+

process

+
+

#Preventive

+

#Corrective

+
+

#Confidential- ity #Integrity #Availability

+
+

#Protect #Re- spond

+
+

#Human_re- source_secu- rity

+
+

#Governance_ and_Ecosys- tem

+
+

6.5

+
+

Responsi- bilities after termination or change of employment

+
+

#Preventive

+
+

#Confidential- ity #Integrity #Availability

+
+

#Protect

+
+

#Human_re- source_secu- rity #Asset_ management

+
+

#Governance_ and_Ecosys- tem

+
+

6.6

+
+

Confiden- tiality or non-disclosure agreements

+
+

#Preventive

+
+

#Confidenti- ality

+
+

#Protect

+
+

#Human_re- source_secu- rity #Infor- mation_pro- tection #Supplier_re- lationships

+
+

#Governance_ and_Ecosys- tem

+
+

6.7

+
+

Remote work- ing

+
+

#Preventive

+
+

#Confidential- ity #Integrity #Availability

+
+

#Protect

+
+

#Asset_man- agement #Information_ protection #Physical_se- curity #Sys- tem_and_net- work_security

+
+

#Protection

+
+

6.8

+
+

Information security event reporting

+
+

#Detective

+
+

#Confidential- ity #Integrity #Availability

+
+

#Detect

+
+

#Informa- tion_securi- ty_event_man- agement

+
+

#Defence

+
+

7.1

+
+

Physical secu- rity perime- ters

+
+

#Preventive

+
+

#Confidential- ity #Integrity #Availability

+
+

#Protect

+
+

#Physical_se- curity

+
+

#Protection

+
+

7.2

+
+

Physical entry

+
+

#Preventive

+
+

#Confidential- ity #Integrity #Availability

+
+

#Protect

+
+

#Physical_se- curity #Iden- tity_and_Ac- cess_Manage- ment

+
+

#Protection

+
+

7.3

+
+

Securing offic- es, rooms and facilities

+
+

#Preventive

+
+

#Confidential- ity #Integrity #Availability

+
+

#Protect

+
+

#Physical_se- curity #Asset_ management

+
+

#Protection

+
+

7.4

+
+

Physical secu- rity monitor- ing

+
+

#Preventive

+

#Detective

+
+

#Confidential- ity #Integrity #Availability

+
+

#Protect #De- tect

+
+

#Physical_se- curity

+
+

#Protection

+

#Defence

+
+ + +**Table A.1** *(continued)* + + + + +++++++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

ISO/

+

IEC 27002 control identifier

+
+

Control name

+
+

Control type

+
+

Information

+

security

+

properties

+
+

Cybersecurity

+

concepts

+
+

Operational

+

capabilities

+
+

Security

+

domains

+
+

7.5

+
+

Protect- ing against

+

physical and environmental threats

+
+

#Preventive

+
+

#Confidential- ity #Integrity #Availability

+
+

#Protect

+
+

#Physical_se- curity

+
+

#Protection

+
+

7.6

+
+

Working in secure areas

+
+

#Preventive

+
+

#Confidential- ity #Integrity #Availability

+
+

#Protect

+
+

#Physical_se- curity

+
+

#Protection

+
+

7.7

+
+

Clear desk and clear screen

+
+

#Preventive

+
+

#Confidenti- ality

+
+

#Protect

+
+

#Physical_se- curity

+
+

#Protection

+
+

7.8

+
+

Equipment siting and protection

+
+

#Preventive

+
+

#Confidential- ity #Integrity #Availability

+
+

#Protect

+
+

#Physical_se- curity #Asset_ management

+
+

#Protection

+
+

7.9

+
+

Security of as- sets off-prem- ises

+
+

#Preventive

+
+

#Confidential- ity #Integrity #Availability

+
+

#Protect

+
+

#Physical_se- curity #Asset_ management

+
+

#Protection

+
+

7.10

+
+

Storage media

+
+

#Preventive

+
+

#Confidential- ity #Integrity #Availability

+
+

#Protect

+
+

#Physical_se- curity #Asset_ management

+
+

#Protection

+
+

7.11

+
+

Supporting

+

utilities

+
+

#Preventive

+

#Detective

+
+

#Integrity

+

#Availability

+
+

#Protect #De- tect

+
+

#Physical_se- curity

+
+

#Protection

+
+

7.12

+
+

Cabling secu- rity

+
+

#Preventive

+
+

#Confidenti- ality #Availa- bility

+
+

#Protect

+
+

#Physical_se- curity

+
+

#Protection

+
+

7.13

+
+

Equipment

+

maintenance

+
+

#Preventive

+
+

#Confidential- ity #Integrity #Availability

+
+

#Protect

+
+

#Physical_se- curity #Asset_ management

+
+

#Protection

+

#Resilience

+
+

7.14

+
+

Secure dispos- al or re-use of equipment

+
+

#Preventive

+
+

#Confidenti- ality

+
+

#Protect

+
+

#Physical_se- curity #Asset_ management

+
+

#Protection

+
+

8.1

+
+

User endpoint devices

+
+

#Preventive

+
+

#Confidential- ity #Integrity #Availability

+
+

#Protect

+
+

#Asset_man- agement #Information_ protection

+
+

#Protection

+
+

8.2

+
+

Privileged

+

access rights

+
+

#Preventive

+
+

#Confidential- ity #Integrity #Availability

+
+

#Protect

+
+

#Identity_and_ access_man- agement

+
+

#Protection

+
+

8.3

+
+

Information access restric- tion

+
+

#Preventive

+
+

#Confidential- ity #Integrity #Availability

+
+

#Protect

+
+

#Identity_and_ access_man- agement

+
+

#Protection

+
+

8.4

+
+

Access to source code

+
+

#Preventive

+
+

#Confidential- ity #Integrity #Availability

+
+

#Protect

+
+

#Identity_ and_access_ management #Applica- tion_security #Secure_con- figuration

+
+

#Protection

+
+

8.5

+
+

Secure authen- tication

+
+

#Preventive

+
+

#Confidential- ity #Integrity #Availability

+
+

#Protect

+
+

#Identity_and_ access_man- agement

+
+

#Protection

+
+ + + + + + + +**Table A.1** *(continued)* + + +++++++++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

ISO/

+

IEC 27002 control identifier

+
+

Control name

+
+

Control type

+
+

Information

+

security

+

properties

+
+

Cybersecurity

+

concepts

+
+

Operational

+

capabilities

+
+

Security

+

domains

+
+

8.6

+
+

Capacity man- agement

+
+

#Preventive

+

#Detective

+
+

#Integrity

+

#Availability

+
+

#Identify #Pro- tect #Detect

+
+

#Continuity

+
+

#Governance_ and_Ecosys- tem #Protec- tion

+
+

8.7

+
+

Protection against mal- ware

+
+

#Preventive #Detective #Corrective

+
+

#Confidential- ity #Integrity #Availability

+
+

#Protect #De- tect

+
+

#System_and_ network_secu- rity #Informa- tion_protec- tion

+
+

#Protection

+

#Defence

+
+

8.8

+
+

Management of technical vulnerabilities

+
+

#Preventive

+
+

#Confidential- ity #Integrity #Availability

+
+

#Identify #Pro- tect

+
+

#Threat_and_ vulnerability_ management

+
+

#Governance_ and_Ecosys- tem #Protec- tion #Defence

+
+

8.9

+
+

Configuration

+

management

+
+

#Preventive

+
+

#Confidential- ity #Integrity #Availability

+
+

#Protect

+
+

#Secure_con- figuration

+
+

#Protection

+
+

8.10

+
+

Information

+

deletion

+
+

#Preventive

+
+

#Confidenti- ality

+
+

#Protect

+
+

#Information_ protection #Legal_and_ compliance

+
+

#Protection

+
+

8.11

+
+

Data masking

+
+

#Preventive

+
+

#Confidenti- ality

+
+

#Protect

+
+

#Information_

+

protection

+
+

#Protection

+
+

8.12

+
+

Data leakage prevention

+
+

#Preventive

+

#Detective

+
+

#Confidenti- ality

+
+

#Protect #De- tect

+
+

#Information_

+

protection

+
+

#Protection

+

#Defence

+
+

8.13

+
+

Information

+

backup

+
+

#Corrective

+
+

#Integrity

+

#Availability

+
+

#Recover

+
+

#Continuity

+
+

#Protection

+
+

8.14

+
+

Redundancy of information processing facilities

+
+

#Preventive

+
+

#Availability

+
+

#Protect

+
+

#Continuity #Asset_man- agement

+
+

#Protection

+

#Resilience

+
+

8.15

+
+

Logging

+
+

#Detective

+
+

#Confidential- ity #Integrity #Availability

+
+

#Detect

+
+

#Informa- tion_securi- ty_event_man- agement

+
+

#Protection

+

#Defence

+
+

8.16

+
+

Monitoring

+

activities

+
+

#Detective

+

#Corrective

+
+

#Confidential- ity #Integrity #Availability

+
+

#Detect #Re- spond

+
+

#Informa- tion_securi- ty_event_man- agement

+
+

#Defence

+
+

8.17

+
+

Clock synchro- nization

+
+

#Detective

+
+

#Integrity

+
+

#Protect #De- tect

+
+

#Informa- tion_securi- ty_event_man- agement

+
+

#Protection

+

#Defence

+
+

8.18

+
+

Use of privi- leged utility programs

+
+

#Preventive

+
+

#Confidential- ity #Integrity #Availability

+
+

#Protect

+
+

#System_and_ network_secu- rity #Secure_ configuration #Application_ security

+
+

#Protection

+
+

8.19

+
+

Installation of software on operational systems

+
+

#Preventive

+
+

#Confidential- ity #Integrity #Availability

+
+

#Protect

+
+

#Secure_con- figuration #Application_ security

+
+

#Protection

+
+ + + + + + +**Table A.1** *(continued)* + + + + +++++++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

ISO/

+

IEC 27002 control identifier

+
+

Control name

+
+

Control type

+
+

Information

+

security

+

properties

+
+

Cybersecurity

+

concepts

+
+

Operational

+

capabilities

+
+

Security

+

domains

+
+

8.20

+
+

Networks

+

security

+
+

#Preventive

+

#Detective

+
+

#Confidential- ity #Integrity #Availability

+
+

#Protect #De- tect

+
+

#System_and_ network_secu- rity

+
+

#Protection

+
+

8.21

+
+

Security of network ser- vices

+
+

#Preventive

+
+

#Confidential- ity #Integrity #Availability

+
+

#Protect

+
+

#System_and_ network_secu- rity

+
+

#Protection

+
+

8.22

+
+

Segregation of networks

+
+

#Preventive

+
+

#Confidential- ity #Integrity #Availability

+
+

#Protect

+
+

#System_and_ network_secu- rity

+
+

#Protection

+
+

8.23

+
+

Web filtering

+
+

#Preventive

+
+

#Confidential- ity #Integrity #Availability

+
+

#Protect

+
+

#System_and_ network_secu- rity

+
+

#Protection

+
+

8.24

+
+

Use of cryp- tography

+
+

#Preventive

+
+

#Confidential- ity #Integrity #Availability

+
+

#Protect

+
+

#Secure_con- figuration

+
+

#Protection

+
+

8.25

+
+

Secure devel- opment life cycle

+
+

#Preventive

+
+

#Confidential- ity #Integrity #Availability

+
+

#Protect

+
+

#Applica- tion_security #System_and_ network_secu- rity

+
+

#Protection

+
+

8.26

+
+

Application security re- quirements

+
+

#Preventive

+
+

#Confidential- ity #Integrity #Availability

+
+

#Protect

+
+

#Applica- tion_security #System_and_ network_secu- rity

+
+

#Protection

+

#Defence

+
+

8.27

+
+

Secure system architecture and engineer- ing principles

+
+

#Preventive

+
+

#Confidential- ity #Integrity #Availability

+
+

#Protect

+
+

#Applica- tion_security #System_and_ network_secu- rity

+
+

#Protection

+
+

8.28

+
+

Secure coding

+
+

#Preventive

+
+

#Confidential- ity #Integrity #Availability

+
+

#Protect

+
+

#Applica- tion_security #System_and_ network_secu- rity

+
+

#Protection

+
+

8.29

+
+

Security testing in de- velopment and acceptance

+
+

#Preventive

+
+

#Confidential- ity #Integrity #Availability

+
+

#Identify

+
+

#Applica- tion_security #Informa- tion_securi- ty_assurance #System_and_ network_secu- rity

+
+

#Protection

+
+

8.30

+
+

Outsourced

+

development

+
+

#Preventive

+

#Detective

+
+

#Confidential- ity #Integrity #Availability

+
+

#Identify #Pro- tect #Detect

+
+

#System_and_ network_secu- rity #Applica- tion_security #Supplier_re- lationships_se- curity

+
+

#Governance_ and_Ecosys- tem #Protec- tion

+
+ + + + + + + +**Table A.1** *(continued)* + + ++++++++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

ISO/

+

IEC 27002 control identifier

+
+

Control name

+
+

Control type

+
+

Information

+

security

+

properties

+
+

Cybersecurity

+

concepts

+
+

Operational

+

capabilities

+
+

Security

+

domains

+
+

8.31

+
+

Separation

+

of develop- ment, test and production environments

+
+

#Preventive

+
+

#Confidential- ity #Integrity #Availability

+
+

#Protect

+
+

#Applica- tion_security #System_and_ network_secu- rity

+
+

#Protection

+
+

8.32

+
+

Change man- agement

+
+

#Preventive

+
+

#Confidential- ity #Integrity #Availability

+
+

#Protect

+
+

#Applica- tion_security #System_and_ network_secu- rity

+
+

#Protection

+
+

8.33

+
+

Test informa- tion

+
+

#Preventive

+
+

#Confidential- ity #Integrity

+
+

#Protect

+
+

#Information_

+

protection

+
+

#Protection

+
+

8.34

+
+

Protection of informa- tion systems during audit testing

+
+

#Preventive

+
+

#Confidential- ity #Integrity #Availability

+
+

#Protect

+
+

#System_and_ network_secu- rity #Informa- tion_protec- tion

+
+

#Governance_ and_Ecosys- tem #Protec- tion

+
+ +>Table A.2shows an example of how to create a view by filtering by a particular attribute value, in this case \#Corrective. + +**Table A.2 — View of \#Corrective controls** + + +++++++++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

ISO/

+

IEC 27002 control identifier

+
+

Control name

+
+

Control type

+
+

Information

+

security

+

properties

+
+

Cybersecurity

+

concepts

+
+

Operational

+

capabilities

+
+

Security

+

domains

+
+

5.5

+
+

Contact with authorities

+
+

#Preventive

+

#Corrective

+
+

#Confidential- ity #Integrity #Availability

+
+

#Identify #Pro- tect #Respond #Recover

+
+

#Governance

+
+

#Defence #Re- silience

+
+

5.6

+
+

Contact with special inter- est groups

+
+

#Preventive

+

#Corrective

+
+

#Confidential- ity #Integrity #Availability

+
+

#Protect #Respond #Re- cover

+
+

#Governance

+
+

#Defence

+
+

5.7

+
+

Threat intelli- gence

+
+

#Preventive #Detective #Corrective

+
+

#Confidential- ity #Integrity #Availability

+
+

#Identify #De- tect #Respond

+
+

#Threat_and_ vulnerability_ management

+
+

#Defence #Re- silience

+
+

5.24

+
+

Information security inci- dent manage- ment planning and prepara- tion

+
+

#Corrective

+
+

#Confidential- ity #Integrity #Availability

+
+

#Respond #Re- cover

+
+

#Governance #Informa- tion_securi- ty_event_man- agement

+
+

#Defence

+
+

5.26

+
+

Response to information security inci- dents

+
+

#Corrective

+
+

#Confidential- ity #Integrity #Availability

+
+

#Respond #Re- cover

+
+

#Informa- tion_securi- ty_event_man- agement

+
+

#Defence

+
+

5.28

+
+

Collection of evidence

+
+

#Corrective

+
+

#Confidential- ity #Integrity #Availability

+
+

#Detect #Re- spond

+
+

#Informa- tion_securi- ty_event_man- agement

+
+

#Defence

+
+

5.29

+
+

Information security dur- ing disruption

+
+

#Preventive

+

#Corrective

+
+

#Confidential- ity #Integrity #Availability

+
+

#Protect #Re- spond

+
+

#Continuity

+
+

#Protection

+

#Resilience

+
+ + + + + + +**Table A.2** *(continued)* + + + + + ++++++++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

ISO/

+

IEC 27002 control identifier

+
+

Control name

+
+

Control type

+
+

Information

+

security

+

properties

+
+

Cybersecurity

+

concepts

+
+

Operational

+

capabilities

+
+

Security

+

domains

+
+

5.30

+
+

ICT readiness for business continuity

+
+

#Corrective

+
+

#Availability

+
+

#Respond

+
+

#Continuity

+
+

#Resilience

+
+

5.35

+
+

Independent review of information security

+
+

#Preventive

+

#Corrective

+
+

#Confidential- ity #Integrity #Availability

+
+

#Identify #Pro- tect

+
+

#Information_ security_as- surance

+
+

#Governance_ and_Ecosys- tem

+
+

5.37

+
+

Documented operating procedures

+
+

#Preventive

+

#Corrective

+
+

#Confidential- ity #Integrity #Availability

+
+

#Protect #Re- cover

+
+

#Asset_man- agement #Physi- cal_security #System_and_ network_secu- rity #Applica- tion_security #Secure_con- figuration #Identity_ and_access_ management #Threat_and_ vulnerability_ management #Continuity #Informa- tion_securi- ty_event_man- agement

+
+

#Governance_ and_Ecosys- tem #Protec- tion #Defence

+
+

6.4

+
+

Disciplinary

+

process

+
+

#Preventive

+

#Corrective

+
+

#Confidential- ity #Integrity #Availability

+
+

#Protect #Re- spond

+
+

#Human_re- source_secu- rity

+
+

#Governance_ and_Ecosys- tem

+
+

8.7

+
+

Protection against mal- ware

+
+

#Preventive #Detective #Corrective

+
+

#Confidential- ity #Integrity #Availability

+
+

#Protect #De- tect

+
+

#System_and_ network_secu- rity #Informa- tion_protec- tion

+
+

#Protection

+

#Defence

+
+

8.13

+
+

Information

+

backup

+
+

#Corrective

+
+

#Integrity

+

#Availability

+
+

#Recover

+
+

#Continuity

+
+

#Protection

+
+

8.16

+
+

Monitoring

+

activities

+
+

#Detective

+

#Corrective

+
+

#Confidential- ity #Integrity #Availability

+
+

#Detect #Re- spond

+
+

#Informa- tion_securi- ty_event_man- agement

+
+

#Defence

+
+ +**A.2 Organizational views** + +Since attributes are used to create different views of controls, organizations can discard the examples of attributes proposed in this document and create their own attributes with different values to address specific needs in the organization. In addition, the values assigned to each attribute can differ between organizations since organizations can have different views on the use or applicability of the control or of the values associated to the attribute (when the values are specific to the context of the organization). The first step is to understand why an organizational-specific attribute is desirable. For example, if an organization has constructed its risk treatment plans \[see ISO/IEC 27001:2013, 6.1.3 e)\] based on events, it can wish to associate a risk scenario attribute to each control in this document. + + + + + + + +The benefit of such an attribute is to speed up the process of fulfilment of ISO/IEC 27001 requirement related to risk treatment, which is to compare the controls determined through the process of risk treatment (referred to as “necessary” control s), with those in ISO/IEC 27001:2013, Annex A (which are issued from in this document) to ensure that no necessary control has been overlooked. + +Once th e purpose and benefits are known, the next step is to determine the attribute values. For example, the organization might identify 9 events: + +1\) loss or theft of mobile device; + +2\) loss or theft from organization’s premises; + +3\) force majeure, vandalism and terrorism; + +4\) failure of software, hardware, power, internet and communications; + +5\) fraud; + +6\) hacking; + +7\) disclosure; + +8\) breach of the law; + +9\) social engineering. + +The second step can therefore be accomplished by assigning identifiers to each event (e.g. E1, E2, ., E9). + +The third step is to copy the control identifiers and control names from this document into a spreadsheet or database and associate the attribute values with each control, remembering that each control can have more than one attribute value. + +The final step is to sort the spreadsheet or query the database to extract the required information. Other examples of organizational attributes (and possible values) include: + +a\) maturity (values from the ISO/IEC 33000 series or other maturity models); + +b\) implementation state (to do, in progress, partially implemented, fully implemented); + +c\) priority (1, 2, 3, etc.); + +d\) organizational areas involved (security, ICT, human resources, top management, etc.); + +e\) events; + +f\) assets involved; + +e\) build and run, to differentiate controls used in the different steps of the service life cycle; + +g\) other frameworks the organization works with or can be transitioning from. + + + + + + + +**Annex B** + +(inform ative) + + + +**Correspondence of ISO/IEC 27002:2022 (this document) with **ISO/IEC 27002:2013** + +The purpose of this annex is to provide backwards compatibility with ISO/IEC 27002:2013 for organizations that are currently using that standard and now wish to transition to this edition. + +>Table B.1provides the correspondence of the controls specified in >Clauses 5to >8with those in ISO/IEC 27002:2013. + +**Table B.1 — Correspondence between controls in this document and controls in** + +**ISO/IEC 27002:2013** + + +++++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

ISO/

+

IEC 27002:2022 control identifier

+
+

ISO/IEC 27002:2013 control identifier

+
+

Control name

+
+

5.1

+
+

05.1.1, 05.1.2

+
+

Policies for information security

+
+

5.2

+
+

06.1.1

+
+

Information security roles and responsibilities

+
+

5.3

+
+

06.1.2

+
+

Segregation of duties

+
+

5.4

+
+

07.2.1

+
+

Management responsibilities

+
+

5.5

+
+

06.1.3

+
+

Contact with authorities

+
+

5.6

+
+

06.1.4

+
+

Contact with special interest groups

+
+

5.7

+
+

New

+
+

Threat intelligence

+
+

5.8

+
+

06.1.5, 14.1.1

+
+

Information security in project management

+
+

5.9

+
+

08.1.1, 08.1.2

+
+

Inventory of information and other associated assets

+
+

5.10

+
+

08.1.3, 08.2.3

+
+

Acceptable use of information and other associated assets

+
+

5.11

+
+

08.1.4

+
+

Return of assets

+
+

5.12

+
+

08.2.1

+
+

Classification of information

+
+

5.13

+
+

08.2.2

+
+

Labelling of information

+
+

5.14

+
+

13.2.1, 13.2.2, 13.2.3

+
+

Information transfer

+
+

5.15

+
+

09.1.1, 09.1.2

+
+

Access control

+
+

5.16

+
+

09.2.1

+
+

Identity management

+
+

5.17

+
+

09.2.4, 09.3.1, 09.4.3

+
+

Authentication information

+
+

5.18

+
+

09.2.2, 09.2.5, 09.2.6

+
+

Access rights

+
+

5.19

+
+

15.1.1

+
+

Information security in supplier relationships

+
+

5.20

+
+

15.1.2

+
+

Addressing information security within supplier agreements

+
+

5.21

+
+

15.1.3

+
+

Managing information security in the ICT supply chain

+
+

5.22

+
+

15.2.1, 15.2.2

+
+

Monitoring, review and change management of supplier services

+
+

5.23

+
+

New

+
+

Information security for use of cloud services

+
+

5.24

+
+

16.1.1

+
+

Information security incident management planning and preparation

+
+

5.25

+
+

16.1.4

+
+

Assessment and decision on information security events

+
+ + + + + + + +**Table B.1** *(continued)* + + ++++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

ISO/

+

IEC 27002:2022 control identifier

+
+

ISO/IEC 27002:2013 control identifier

+
+

Control name

+
+

5.26

+
+

16.1.5

+
+

Response to information security incidents

+
+

5.27

+
+

16.1.6

+
+

Learning from information security incidents

+
+

5.28

+
+

16.1.7

+
+

Collection of evidence

+
+

5.29

+
+

17.1.1, 17.1.2, 17.1.3

+
+

Information security during disruption

+
+

5.30

+
+

New

+
+

ICT readiness for business continuity

+
+

5.31

+
+

18.1.1, 18.1.5

+
+

Legal, statutory, regulatory and contractual requirements

+
+

5.32

+
+

18.1.2

+
+

Intellectual property rights

+
+

5.33

+
+

18.1.3

+
+

Protection of records

+
+

5.34

+
+

18.1.4

+
+

Privacy and protection of PII

+
+

5.35

+
+

18.2.1

+
+

Independent review of information security

+
+

5.36

+
+

18.2.2, 18.2.3

+
+

Compliance with policies, rules and standards for information security

+
+

5.37

+
+

12.1.1

+
+

Documented operating procedures

+
+

6.1

+
+

07.1.1

+
+

Screening

+
+

6.2

+
+

07.1.2

+
+

Terms and conditions of employment

+
+

6.3

+
+

07.2.2

+
+

Information security awareness, education and training

+
+

6.4

+
+

07.2.3

+
+

Disciplinary process

+
+

6.5

+
+

07.3.1

+
+

Responsibilities after termination or change of employment

+
+

6.6

+
+

13.2.4

+
+

Confidentiality or non-disclosure agreements

+
+

6.7

+
+

06.2.2

+
+

Remote working

+
+

6.8

+
+

16.1.2, 16.1.3

+
+

Information security event reporting

+
+

7.1

+
+

11.1.1

+
+

Physical security perimeters

+
+

7.2

+
+

11.1.2, 11.1.6

+
+

Physical entry

+
+

7.3

+
+

11.1.3

+
+

Securing offices, rooms and facilities

+
+

7.4

+
+

New

+
+

Physical security monitoring

+
+

7.5

+
+

11.1.4

+
+

Protecting against physical and environmental threats

+
+

7.6

+
+

11.1.5

+
+

Working in secure areas

+
+

7.7

+
+

11.2.9

+
+

Clear desk and clear screen

+
+

7.8

+
+

11.2.1

+
+

Equipment siting and protection

+
+

7.9

+
+

11.2.6

+
+

Security of assets off-premises

+
+

7.10

+
+

08.3.1, 08.3.2,

+

08.3.3, 11.2.5

+
+

Storage media

+
+

7.11

+
+

11.2.2

+
+

Supporting utilities

+
+

7.12

+
+

11.2.3

+
+

Cabling security

+
+

7.13

+
+

11.2.4

+
+

Equipment maintenance

+
+

7.14

+
+

11.2.7

+
+

Secure disposal or re-use of equipment

+
+

8.1

+
+

06.2.1, 11.2.8

+
+

User endpoint devices

+
+

8.2

+
+

09.2.3

+
+

Privileged access rights

+
+

8.3

+
+

09.4.1

+
+

Information access restriction

+
+

8.4

+
+

09.4.5

+
+

Access to source code

+
+

8.5

+
+

09.4.2

+
+

Secure authentication

+
+

8.6

+
+

12.1.3

+
+

Capacity management

+
+

8.7

+
+

12.2.1

+
+

Protection against malware

+
+ + +**Table B.1** *(continued)* + + + ++++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

ISO/

+

IEC 27002:2022 control identifier

+
+

ISO/IEC 27002:2013 control identifier

+
+

Control name

+
+

8.8

+
+

12.6.1, 18.2.3

+
+

Management of technical vulnerabilities

+
+

8.9

+
+

New

+
+

Configuration management

+
+

8.10

+
+

New

+
+

Information deletion

+
+

8.11

+
+

New

+
+

Data masking

+
+

8.12

+
+

New

+
+

Data leakage prevention

+
+

8.13

+
+

12.3.1

+
+

Information backup

+
+

8.14

+
+

17.2.1

+
+

Redundancy of information processing facilities

+
+

8.15

+
+

12.4.1, 12.4.2, 12.4.3

+
+

Logging

+
+

8.16

+
+

New

+
+

Monitoring activities

+
+

8.17

+
+

12.4.4

+
+

Clock synchronization

+
+

8.18

+
+

09.4.4

+
+

Use of privileged utility programs

+
+

8.19

+
+

12.5.1, 12.6.2

+
+

Installation of software on operational systems

+
+

8.20

+
+

13.1.1

+
+

Networks security

+
+

8.21

+
+

13.1.2

+
+

Security of network services

+
+

8.22

+
+

13.1.3

+
+

Segregation of networks

+
+

8.23

+
+

New

+
+

Web filtering

+
+

8.24

+
+

10.1.1, 10.1.2

+
+

Use of cryptography

+
+

8.25

+
+

14.2.1

+
+

Secure development life cycle

+
+

8.26

+
+

14.1.2, 14.1.3

+
+

Application security requirements

+
+

8.27

+
+

14.2.5

+
+

Secure system architecture and engineering principles

+
+

8.28

+
+

New

+
+

Secure coding

+
+

8.29

+
+

14.2.8, 14.2.9

+
+

Security testing in development and acceptance

+
+

8.30

+
+

14.2.7

+
+

Outsourced development

+
+

8.31

+
+

12.1.4, 14.2.6

+
+

Separation of development, test and production environments

+
+

8.32

+
+

12.1.2, 14.2.2,

+

14.2.3, 14.2.4

+
+

Change management

+
+

8.33

+
+

14.3.1

+
+

Test information

+
+

8.34

+
+

12.7.1

+
+

Protection of information systems during audit testing

+
+ +>Table B.2provides the correspondence of controls specified in ISO/IEC 27002:2013 with those in this document. + +**Table B.2 — Correspondence between controls in ISO/IEC 27002:2013 and controls in this** + +**document** + + ++++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

ISO/IEC 27002:2013 control identifier

+
+

ISO/

+

IEC 27002:2022 control identifier

+
+

Control name according to ISO/IEC 27002:2013

+
+

5

+
+

Information security policies

+
+

5.1

+
+

Management direction for information security

+
+

5.1.1

+
+

5.1

+
+

Policies for information security

+
+

5.1.2

+
+

5.1

+
+

Review of the policies for information security

+
+

6

+
+

Organization of information security

+
+ + + + + + + +**Table B.2** *(continued)* + + ++++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

ISO/IEC 27002:2013 control identifier

+
+

ISO/

+

IEC 27002:2022 control identifier

+
+

Control name according to ISO/IEC 27002:2013

+
+

6.1

+
+

Internal organization

+
+

6.1.1

+
+

5.2

+
+

Information security roles and responsibilities

+
+

6.1.2

+
+

5.3

+
+

Segregation of duties

+
+

6.1.3

+
+

5.5

+
+

Contact with authorities

+
+

6.1.4

+
+

5.6

+
+

Contact with special interest groups

+
+

6.1.5

+
+

5.8

+
+

Information security in project management

+
+

6.2

+
+

Mobile devices and teleworking

+
+

6.2.1

+
+

8.1

+
+

Mobile device policy

+
+

6.2.2

+
+

6.7

+
+

Teleworking

+
+

7

+
+

Human resource security

+
+

7.1

+
+

Prior to employment

+
+

7.1.1

+
+

6.1

+
+

Screening

+
+

7.1.2

+
+

6.2

+
+

Terms and conditions of employment

+
+

7.2

+
+

During employment

+
+

7.2.1

+
+

5.4

+
+

Management responsibilities

+
+

7.2.2

+
+

6.3

+
+

Information security awareness, education and training

+
+

7.2.3

+
+

6.4

+
+

Disciplinary process

+
+

7.3

+
+

Termination and change of employment

+
+

7.3.1

+
+

6.5

+
+

Termination or change of employment responsibilities

+
+

8

+
+

Asset management

+
+

8.1

+
+

Responsibility for assets

+
+

8.1.1

+
+

5.9

+
+

Inventory of assets

+
+

8.1.2

+
+

5.9

+
+

Ownership of assets

+
+

8.1.3

+
+

5.10

+
+

Acceptable use of assets

+
+

8.1.4

+
+

5.11

+
+

Return of assets

+
+

8.2

+
+

Information classification

+
+

8.2.1

+
+

5.12

+
+

Classification of information

+
+

8.2.2

+
+

5.13

+
+

Labelling of information

+
+

8.2.3

+
+

5.10

+
+

Handling of assets

+
+

8.3

+
+

Media handling

+
+

8.3.1

+
+

7.10

+
+

Management of removable media

+
+

8.3.2

+
+

7.10

+
+

Disposal of media

+
+

8.3.3

+
+

7.10

+
+

Physical media transfer

+
+

9

+
+

Access control

+
+

9.1

+
+

Business requirements of access control

+
+

9.1.1

+
+

5.15

+
+

Access control policy

+
+

9.1.2

+
+

5.15

+
+

Access to networks and network services

+
+

9.2

+
+

User access management

+
+

9.2.1

+
+

5.16

+
+

User registration and de-registration

+
+

9.2.2

+
+

5.18

+
+

User access provisioning

+
+

9.2.3

+
+

8.2

+
+

Management of privileged access rights

+
+

9.2.4

+
+

5.17

+
+

Management of secret authentication information of users

+
+ + +**Table B.2** *(continued)* + + + +++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

ISO/IEC 27002:2013 control identifier

+
+

ISO/

+

IEC 27002:2022 control identifier

+
+

Control name according to ISO/IEC 27002:2013

+
+

9.2.5

+
+

5.18

+
+

Review of user access rights

+
+

9.2.6

+
+

5.18

+
+

Removal or adjustment of access rights

+
+

9.3

+
+

User responsibilities

+
+

9.3.1

+
+

5.17

+
+

Use of secret authentication information

+
+

9.4

+
+

System and application access control

+
+

9.4.1

+
+

8.3

+
+

Information access restriction

+
+

9.4.2

+
+

8.5

+
+

Secure log-on procedures

+
+

9.4.3

+
+

5.17

+
+

Password management system

+
+

9.4.4

+
+

8.18

+
+

Use of privileged utility programs

+
+

9.4.5

+
+

8.4

+
+

Access control to program source code

+
+

10

+
+

Cryptography

+
+

10.1

+
+

Cryptographic controls

+
+

10.1.1

+
+

8.24

+
+

Policy on the use of cryptographic controls

+
+

10.1.2

+
+

8.24

+
+

Key management

+
+

11

+
+

Physical and environmental security

+
+

11.1

+
+

Secure areas

+
+

11.1.1

+
+

7.1

+
+

Physical security perimeter

+
+

11.1.2

+
+

7.2

+
+

Physical entry controls

+
+

11.1.3

+
+

7.3

+
+

Securing offices, rooms and facilities

+
+

11.1.4

+
+

7.5

+
+

Protecting against external and environmental threats

+
+

11.1.5

+
+

7.6

+
+

Working in secure areas

+
+

11.1.6

+
+

7.2

+
+

Delivery and loading areas

+
+

11.2

+
+

Equipment

+
+

11.2.1

+
+

7.8

+
+

Equipment siting and protection

+
+

11.2.2

+
+

7.11

+
+

Supporting utilities

+
+

11.2.3

+
+

7.12

+
+

Cabling security

+
+

11.2.4

+
+

7.13

+
+

Equipment maintenance

+
+

11.2.5

+
+

7.10

+
+

Removal of assets

+
+

11.2.6

+
+

7.9

+
+

Security of equipment and assets off-premises

+
+

11.2.7

+
+

7.14

+
+

Secure disposal or reuse of equipment

+
+

11.2.8

+
+

8.1

+
+

Unattended user equipment

+
+

11.2.9

+
+

7.7

+
+

Clear desk and clear screen policy

+
+

12

+
+

Operations security

+
+

12.1

+
+

Operational procedures and responsibilities

+
+

12.1.1

+
+

5.37

+
+

Documented operating procedures

+
+

12.1.2

+
+

8.32

+
+

Change management

+
+

12.1.3

+
+

8.6

+
+

Capacity management

+
+

12.1.4

+
+

8.31

+
+

Separation of development, testing and operational environments

+
+

12.2

+
+

Protection from malware

+
+

12.2.1

+
+

8.7

+
+

Controls against malware

+
+

12.3

+
+

Backup

+
+

12.3.1

+
+

8.13

+
+

Information backup

+
+ + + + + + + +**Table B.2** *(continued)* + + +++++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

ISO/IEC 27002:2013 control identifier

+
+

ISO/

+

IEC 27002:2022 control identifier

+
+

Control name according to ISO/IEC 27002:2013

+
+

12.4

+
+

Logging and monitoring

+
+

12.4.1

+
+

8.15

+
+

Event logging

+
+

12.4.2

+
+

8.15

+
+

Protection of log information

+
+

12.4.3

+
+

8.15

+
+

Administrator and operator logs

+
+

12.4.4

+
+

8.17

+
+

Clock synchronization

+
+

12.5

+
+

Control of operational software

+
+

12.5.1

+
+

8.19

+
+

Installation of software on operational systems

+
+

12.6

+
+

Technical vulnerability management

+
+

12.6.1

+
+

8.8

+
+

Management of technical vulnerabilities

+
+

12.6.2

+
+

8.19

+
+

Restrictions on software installation

+
+

12.7

+
+

Information systems audit considerations

+
+

12.7.1

+
+

8.34

+
+

Information systems audit controls

+
+

13

+
+

Communications security

+
+

13.1

+
+

Network security management facilities.

+
+

13.1.1

+
+

8.20

+
+

Network controls

+
+

13.1.2

+
+

8.21

+
+

Security of network services

+
+

13.1.3

+
+

8.22

+
+

Segregation in networks

+
+

13.2

+
+

Information transfer

+
+

13.2.1

+
+

5.14

+
+

Information transfer policies and procedures

+
+

13.2.2

+
+

5.14

+
+

Agreements on information transfer

+
+

13.2.3

+
+

5.14

+
+

Electronic messaging

+
+

13.2.4

+
+

6.6

+
+

Confidentiality or nondisclosure agreements

+
+

14

+
+

System acquisition, development and maintenance

+
+

14.1

+
+

Security requirements of information systems

+
+

14.1.1

+
+

5.8

+
+

Information security requirements analysis and specification

+
+

14.1.2

+
+

8.26

+
+

Securing application services on public networks

+
+

14.1.3

+
+

8.26

+
+

Protecting application services transactions

+
+

14.2

+
+

Security in development and support processes

+
+

14.2.1

+
+

8.25

+
+

Secure development policy

+
+

14.2.2

+
+

8.32

+
+

System change control procedures

+
+

14.2.3

+
+

8.32

+
+

Technical review of applications after operating platform changes

+
+

14.2.4

+
+

8.32

+
+

Restrictions on changes to software packages

+
+

14.2.5

+
+

8.27

+
+

Secure system engineering principles

+
+

14.2.6

+
+

8.31

+
+

Secure development environment

+
+

14.2.7

+
+

8.30

+
+

Outsourced development

+
+

14.2.8

+
+

8.29

+
+

System security testing

+
+

14.2.9

+
+

8.29

+
+

System acceptance testing

+
+

14.3

+
+

Test data

+
+

14.3.1

+
+

8.33

+
+

Protection of test data

+
+

15

+
+

Supplier relationships

+
+

15.1

+
+

Information security in supplier relationships

+
+

15.1.1

+
+

5.19

+
+

Information security policy for supplier relationships

+
+ + + + + +**Table B.2** *(continued)* + + + + + ++++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

ISO/IEC 27002:2013 control identifier

+
+

ISO/

+

IEC 27002:2022 control identifier

+
+

Control name according to ISO/IEC 27002:2013

+
+

15.1.2

+
+

5.20

+
+

Addressing security within supplier agreements

+
+

15.1.3

+
+

5.21

+
+

Information and communication technology supply chain

+
+

15.2

+
+

Supplier service delivery management

+
+

15.2.1

+
+

5.22

+
+

Monitoring and review of supplier services

+
+

15.2.2

+
+

5.22

+
+

Managing changes to supplier services

+
+

16

+
+

Information security incident management

+
+

16.1

+
+

Management of information security incidents and improvements

+
+

16.1.1

+
+

5.24

+
+

Responsibilities and procedures

+
+

16.1.2

+
+

6.8

+
+

Reporting information security events

+
+

16.1.3

+
+

6.8

+
+

Reporting information security weaknesses

+
+

16.1.4

+
+

5.25

+
+

Assessment of and decision on information security events

+
+

16.1.5

+
+

5.26

+
+

Response to information security incidents

+
+

16.1.6

+
+

5.27

+
+

Learning from information security incidents

+
+

16.1.7

+
+

5.28

+
+

Collection of evidence

+
+

17

+
+

Information security aspects of business continuity management

+
+

17.1

+
+

Information security continuity

+
+

17.1.1

+
+

5.29

+
+

Planning information security continuity

+
+

17.1.2

+
+

5.29

+
+

Implementing information security continuity

+
+

17.1.3

+
+

5.29

+
+

Verify, review and evaluate information security continuity

+
+

17.2

+
+

Redundancies

+
+

17.2.1

+
+

8.14

+
+

Availability of information processing facilities

+
+

18

+
+

Compliance

+
+

18.1

+
+

Compliance with legal and contractual requirements

+
+

18.1.1

+
+

5.31

+
+

Identification of applicable legislation and contractual requirements

+
+

18.1.2

+
+

5.32

+
+

Intellectual property rights

+
+

18.1.3

+
+

5.33

+
+

Protection of records

+
+

18.1.4

+
+

5.34

+
+

Privacy and protection of personally identifiable information

+
+

18.1.5

+
+

5.31

+
+

Regulation of cryptographic controls

+
+

18.2

+
+

Information security reviews

+
+

18.2.1

+
+

5.35

+
+

Independent review of information security

+
+

18.2.2

+
+

5.36

+
+

Compliance with security policies and standards

+
+

18.2.3

+
+

5.36

+
+

, >8.8>

+
+

Technical compliance review

+
+ + + + + + + +**Bibliography** + +\[1\] I SO 9000, *Quality management systems — Fundamentals and vocabulary* + +\[2\] ISO 55001, *Asset management — Management systems — Requirements* + +\[3\] ISO/IEC 11770 (all parts), *Information security — Key management* + +\[4\] + +ISO/IEC 15408 (all parts), *Information technology — Security techniques — Evaluation criteria for IT security* + +\[5\] ISO 15489 (all parts), *Information and documentation — Records management* + +\[6\] ISO/IEC 17788, *Information technology — Cloud computing — Overview and vocabulary* + +\[7\] ISO/IEC 17789, *Information technology — Cloud computing — Reference architecture* + +\[8\] ISO/IEC 19086 (all parts), *Cloud computing — Service level agreement (SLA) framework* + +\[9\] ISO/IEC 19770 (all parts), *Information technology — IT asset management* + +\[10\] ISO/IEC 19941, *Information technology — Cloud computing — Interoperability and portability* + +\[11\] ISO/IEC 20889, *Privacy enhancing data de-identification terminology and classification of* + +*techniques* + +\[12\] ISO 21500, *Project, programme and portfolio management — Context and concepts* + +\[13\] ISO 21502, *Project, programme and portfolio management — Guidance on project management* + +\[14\] ISO 22301, *Security and resilience — Business continuity management systems — Requirements* + +\[15\] ISO 22313, *Security and resilience — Business continuity management systems — Guidance on the* + +*use of ISO 22301* + +\[16\] ISO/TS 22317, *Societal security — Business continuity management systems — Guidelines for* + +*business impact analysis (BIA)* + +\[17\] ISO 22396, *Security and resilience — Community resilience — Guidelines for information exchange* + +*between organizations* + +\[18\] ISO/IEC TS 23167, *Information technology — Cloud computing — Common technologies and* + +*techniques* + +\[19\] ISO/IEC 23751:—2), *Information technology — Cloud computing and distributed platforms — Data* + +*sharing agreement (DSA) framework* + +\[20\] ISO/IEC 24760 (all parts), *IT Security and Privacy — A framework for identity management* + +\[21\] ISO/IEC 27001:2013, *Information technology — Security techniques — Information security* + +*management systems — Requirements* + +\[22\] ISO/IEC 27005, *Information technology — Security techniques — Information security risk* + +*management* + +\[23\] ISO/IEC 27007, *Information security, cybersecurity and privacy protection — Guidelines for* + +*information security management systems auditing* + +\[24\] ISO/IEC TS 27008, *Information technology — Security techniques — Guidelines for the assessment* + +*of information security controls* + +2\) Under preparation. Stage at the time of publication: ISO/IEC PRF 23751:2022. + + +\[25\] ISO/IEC 27011, *Information technology — Security techniques — Code of practice for Information* + +*security controls based on ISO/IEC 27002 for telecommunications organizations* + +\[26\] ISO/IEC TR 27016, *Information technology — Security techniques — Information security* + +*management — Organizational economics* + +\[27\] ISO/IEC 27017, *Information technology — Security techniques — Code of practice for information* + +*security controls based on ISO/IEC 27002 for cloud services* + +\[28\] ISO/IEC 27018, *Information technology — Security techniques — Code of practice for protection of* + +*personally identifiable information (PII) in public clouds acting as PII processors* + +\[29\] ISO/IEC 27019, *Information technology — Security techniques — Information security controls for* + +*the energy utility industry* + +\[30\] ISO/IEC 27031, *Information technology — Security techniques — Guidelines for information and* + +*communication technology readiness for business continuity* + +\[31\] ISO/IEC 27033 (all parts), *Information technology — Security techniques — Network security* + +\[32\] ISO/IEC 27034 (all parts), *Information technology — Application security* + +\[33\] ISO/IEC 27035 (all parts), *Information technology — Security techniques — Information security* + +*incident management* + +\[34\] ISO/IEC 27036 (all parts), *Information technology — Security techniques — Information security* + +*for supplier relationships* + +\[35\] ISO/IEC 27037, *Information technology — Security techniques — Guidelines for identification,* + +*collection, acquisition and preservation of digital evidence* + +\[36\] ISO/IEC 27040, *Information technology — Security techniques — Storage security* + +\[37\] ISO/IEC 27050 (all parts), *Information technology — Electronic discovery* + +\[38\] ISO/IEC TS 27110, *Information technology, cybersecurity and privacy protection — Cybersecurity* + +*framework development guidelines* + +\[39\] ISO/IEC 27701, *Security techniques — Extension to ISO/IEC 27001 and ISO/IEC 27002 for privacy* + +*information management — Requirements and guidelines* + +\[40\] ISO 27799, *Health informatics — Information security management in health using ISO/IEC 27002* + +\[41\] ISO/IEC 29100, *Information technology — Security techniques — Privacy framework* + +\[42\] ISO/IEC 29115, *Information technology — Security techniques — Entity authentication assurance* + +*framework* + +\[43\] ISO/IEC 29134, *Information technology — Security techniques — Guidelines for privacy impact* + +*assessment* + +\[44\] ISO/IEC 29146, *Information technology — Security techniques — A framework for access* + +*management* + +\[45\] ISO/IEC 29147, *Information technology — Security techniques — Vulnerability disclosure* + +\[46\] ISO 30000, *Ships and marine technology — Ship recycling management systems — Specifications* + +*for management systems for safe and environmentally sound ship recycling facilities* + +\[47\] ISO/IEC 30111, *Information technology — Security techniques — Vulnerability handling processes* + +\[48\] ISO 31000:2018, *Risk management — Guidelines* + +\[49\] IEC 31010, *Risk management — Risk assessment techniques* + + + + + + + +\[50\] ISO/IEC 22123 (all parts), *Information technology — Cloud computing* + +\[51\] ISO/IEC 27555, *Information security, cybersecurity and privacy protection — Guidelines on* + +*personally identifiable information deletion* + +\[52\] Information Security Forum (ISF). The ISF Standard of Good Practice for Information + +Security 2020, August 2018. Available at https://www.securityforum.org/tool/standard-of -good-practice-for-information-security-2020/ + +\[53\] ITIL® Foundation, ITIL 4 edition, AXELOS, February 2019, ISBN: 9780113316076 + +\[54\] National Institute of Standards and Technology (NIST), SP 800-37, Risk Management + +Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy, Revision 2. December 2018 \[viewed 2020-07-31\]. Available at >https://doi> + +>.org/10.6028/NIST.SP.800-37r2> + +\[55\] Open Web Application Security Project (OWASP). OWASP Top Ten - 2017, The Ten Most + +Critical Web Application Security Risks, 2017 \[viewed 2020-07-31\]. Available at >https://owasp>.org/www-project-top-ten/OWASP_Top_Ten_2017/> + +\[56\] Open Web Application Security Project (OWASP). OWASP Developer Guide, \[online\] \[viewed + +2020-10-22\]. Available at >https://github.com/OWASP/DevGuide> + +\[57\] National Institute of Standards and Technology (NIST), SP 800-63B, Digital Identity + +Guidelines; Authentication and Lifecycle Management. February 2020 \[viewed 2020-07-31\]. Available at >https://doi.org/10.6028/NIST.SP.800-63b> + +\[58\] OASIS, Structured Threat Information Expression. Available at >https://www.oasis-open.org/> + +>standards#stix2.0> + +\[59\] OASIS, Trusted Automated Exchange of Indicator Information. Available at >https://www.oasis> + +>-open.org/standards#taxii2.0> + + +**ICS 3 5.030** diff --git a/Corpus/Standards/ISO27x/ISO 27k standards overview.md b/Corpus/Standards/ISO27x/ISO 27k standards overview.md index 1a14edc..5b333b0 100644 --- a/Corpus/Standards/ISO27x/ISO 27k standards overview.md +++ b/Corpus/Standards/ISO27x/ISO 27k standards overview.md @@ -11,8 +11,8 @@ tags: Indexes: - [ISO 27001:2022 EN](../../MoCs/ISO_27001_2022_00_MoC%20Index.md) - [ISO 27002:2022 EN](../../MoCs/ISO_27001_2022_00_MoC%20Index%20EXT.md) – Includes references to 2013 version! -- [ISO 27001:2023 NL](OST/27001/NL/ISO_27001_2023_NL_Index.md) -- [ISO 27002:2022 NL](OST/27002/NL/ISO_27002_2022_NL_Index.md) +- [ISO 27001:2023 NL](OST/ISO_27001_2023_NL_Index.md) +- [ISO 27002:2022 NL](OST/ISO_27002_2022_NL_Index.md) - [Vertaaltabel Engels-Nederlands](../../MoCs/ISO_27002_2022_Vertaaltabel_Engels_Nederlands.md) EN source tekst: @@ -21,17 +21,17 @@ EN source tekst: NL brontekst: - ISO 27001:2023 [PDF](OST/27001/NL/ISO_27001_2023_NL_PDF.md) -- ISO 27002:2022 [PDF](OST/27002/NL/ISO_27002_2022_NL_PDF.md) +- ISO 27002:2022 [PDF](OST/ISO_27002_2022_NL_PDF.md) See also: - [Plain English ISO IEC 27002 2005 from Praxiom](https://www.praxiom.com/iso-17799-objectives.htm) - [Changes in ISO 27001:2022 (table)](../../🎇%20Sparks/Detailed%20comparison%20between%202017%20and%202022.md) - [[ISO 27002 2022 What's New]] -- [ISO_27001_2023_NL_Aanpassingen](OST/27001/NL/ISO_27001_2023_NL_Aanpassingen.md) +- [ISO_27001_2023_NL_Aanpassingen](OST/ISO_27001_2023_NL_Aanpassingen.md) - [Changes in ISO 27001_2022_Advisera](../../../../iso27DIY-gis/reference/Changes%20in%20ISO%2027001_2022_Advisera.md) -- [IBB op hoofdlijnen](OST/27001/NL/IBB%20op%20hoofdlijnen.md) -- [ISO 27001 2023 Processen en Artefacten](OST/27001/NL/ISO%2027001%202023%20Processen%20en%20Artefacten.md) +- [IBB op hoofdlijnen](OST/IBB%20op%20hoofdlijnen.md) +- [ISO 27001 2023 Processen en Artefacten](OST/ISO%2027001%202023%20Processen%20en%20Artefacten.md) - [Advised Documents for ISO 27001](../../../../iso27DIY-gis/reference/Advised%20Documents%20for%20ISO%2027001.md) - [Types of Controls](../../🎇%20Sparks/Types%20of%20Controls.md) diff --git a/Corpus/Standards/ISO27x/OST/27001/EN/add_yaml.py b/Corpus/Standards/ISO27x/OST/27001/EN/add_yaml.py new file mode 100644 index 0000000..7623607 --- /dev/null +++ b/Corpus/Standards/ISO27x/OST/27001/EN/add_yaml.py @@ -0,0 +1,54 @@ +#!/usr/bin/env python3 +import os +import re + +directory = '/Users/rico/src/iso27diy-corp/Corpus/Standards/ISO27x/OST/27001/EN/' + +for filename in os.listdir(directory): + if filename.endswith('.md'): + filepath = os.path.join(directory, filename) + with open(filepath, 'r') as f: + lines = f.readlines() + if lines and lines[0].strip() == '---': + continue # Already has YAML + # Extract id and title from filename + match = re.match(r'c-([0-9.]+)-(.+)\.md', filename) + if match: + num = match.group(1) + title_part = match.group(2) + id_val = f'C.{num}' + title = title_part.replace('-', ' ') + elif filename == 'c-0-Introduction.md': + id_val = 'C.0' + title = 'Introduction' + elif filename == 'ISO_27001_OT F Foreword.md': + id_val = 'Foreword' + title = 'Foreword' + else: + # For other files like c-2-Normative-references.md + match = re.match(r'c-([0-9]+)-(.+)\.md', filename) + if match: + num = match.group(1) + title_part = match.group(2) + id_val = f'C.{num}' + title = title_part.replace('-', ' ') + else: + continue # Skip if not matching + + yaml = f'''--- +notetype: sourcetext +standard: ISO 27001 +version: 2022 +language: EN +type: clause +id: "{id_val}" +title: "{title}" +tags: +- iso27001/2022/EN +status: active +--- +''' + with open(filepath, 'w') as f: + f.write(yaml + ''.join(lines)) + +print("YAML front matter added to files that didn't have it.") \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/OST/27001/EN/c-0-Introduction.md b/Corpus/Standards/ISO27x/OST/27001/EN/c-0-Introduction.md index 8623006..5e0f417 100644 --- a/Corpus/Standards/ISO27x/OST/27001/EN/c-0-Introduction.md +++ b/Corpus/Standards/ISO27x/OST/27001/EN/c-0-Introduction.md @@ -1,8 +1,19 @@ -#iso27001/2022/EN +--- +notetype: reference +standard: ISO 27001 +version: 2022 +language: EN +type: clause +id: "C.0" +title: "Introduction" +tags: +- iso27001/2022/EN +- sourcetext +status: active +--- +## 0 Introduction -# Introduction - -## 0.1 General +### 0.1 General This document has been prepared to provide requirements for establishing, implementing, maintaining and continually improving an information security management system. The adoption of an information security management system is a strategic decision for an organization. The establishment and implementation of an organization's information security management system is influenced by the organization's needs and objectives, security requirements, the organizational processes used and the size and structure of the organization. All of these influencing factors are expected to change over time. @@ -16,7 +27,7 @@ The order in which requirements are presented in this document does not reflect ISO/IEC 27000 describes the overview and the vocabulary of information security management systems, referencing the information security management system family of standards (including ISO/IEC 27003, ISO/IEC 27004 and ISO/IEC 27005), with related terms and definitions. -## 0.2 Compatibility with other management system standards +### 0.2 Compatibility with other management system standards This document applies the high-level structure, identical sub-clause titles, identical text, common terms, and core definitions defined in Annex SL of ISO/IEC Directives, Part 1, Consolidated ISO Supplement, and therefore maintains compatibility with other management system standards that have adopted the Annex SL. diff --git a/Corpus/Standards/ISO27x/OST/27001/EN/c-1-Scope.md b/Corpus/Standards/ISO27x/OST/27001/EN/c-1-Scope.md index 81fa321..d5136d1 100644 --- a/Corpus/Standards/ISO27x/OST/27001/EN/c-1-Scope.md +++ b/Corpus/Standards/ISO27x/OST/27001/EN/c-1-Scope.md @@ -1,6 +1,17 @@ -#iso27001/2022/EN - -# 1 Scope +--- +notetype: reference +standard: ISO 27001 +version: 2022 +language: EN +type: clause +id: "C.1" +title: "Scope" +tags: +- iso27001/2022/EN +- sourcetext +status: active +--- +## 1 Scope This document specifies the requirements for establishing, implementing, maintaining and continually improving an information diff --git a/Corpus/Standards/ISO27x/OST/27001/EN/c-10-Improvement.md b/Corpus/Standards/ISO27x/OST/27001/EN/c-10-Improvement.md new file mode 100644 index 0000000..57150e4 --- /dev/null +++ b/Corpus/Standards/ISO27x/OST/27001/EN/c-10-Improvement.md @@ -0,0 +1,16 @@ +--- +notetype: reference +standard: ISO 27001 +version: 2022 +language: EN +type: clause +id: "C.10" +title: "Improvement" +tags: +- iso27001/2022/EN +- sourcetext +status: active +--- +# 10 Improvement +[c-10.1-Continual-improvement](c-10.1-Continual-improvement.md) +[c-10.2-Nonconformity-and-corrective-action](c-10.2-Nonconformity-and-corrective-action.md) diff --git a/Corpus/Standards/ISO27x/OST/27001/EN/c-10.1-Continual-improvement.md b/Corpus/Standards/ISO27x/OST/27001/EN/c-10.1-Continual-improvement.md index 8dd354d..cbbea3f 100644 --- a/Corpus/Standards/ISO27x/OST/27001/EN/c-10.1-Continual-improvement.md +++ b/Corpus/Standards/ISO27x/OST/27001/EN/c-10.1-Continual-improvement.md @@ -1,4 +1,16 @@ -#iso27001/2022/EN +--- +notetype: reference +standard: ISO 27001 +version: 2022 +language: EN +type: clause +id: "C.10.1" +title: "Continual improvement" +tags: +- iso27001/2022/EN +- sourcetext +status: active +--- ## 10.1 Continual improvement The organization shall continually improve the suitability, adequacy and effectiveness of the information security management system. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/OST/27001/EN/c-10.2-Nonconformity-and-corrective-action.md b/Corpus/Standards/ISO27x/OST/27001/EN/c-10.2-Nonconformity-and-corrective-action.md index 3f82d30..fe8e540 100644 --- a/Corpus/Standards/ISO27x/OST/27001/EN/c-10.2-Nonconformity-and-corrective-action.md +++ b/Corpus/Standards/ISO27x/OST/27001/EN/c-10.2-Nonconformity-and-corrective-action.md @@ -1,6 +1,16 @@ -#iso27001/2022/EN - - +--- +notetype: reference +standard: ISO 27001 +version: 2022 +language: EN +type: clause +id: "C.10.2" +title: "Nonconformity and corrective action" +tags: +- iso27001/2022/EN +- sourcetext +status: active +--- ## 10.2 Nonconformity and corrective action When a nonconformity occurs, the organization shall: diff --git a/Corpus/Standards/ISO27x/OST/27001/EN/c-2-Normative-references.md b/Corpus/Standards/ISO27x/OST/27001/EN/c-2-Normative-references.md index 825801e..6b89b11 100644 --- a/Corpus/Standards/ISO27x/OST/27001/EN/c-2-Normative-references.md +++ b/Corpus/Standards/ISO27x/OST/27001/EN/c-2-Normative-references.md @@ -1,5 +1,16 @@ -#iso27001/2022/EN - -# 2 Normative references +--- +notetype: reference +standard: ISO 27001 +version: 2022 +language: EN +type: clause +id: "C.2" +title: "Normative references" +tags: +- iso27001/2022/EN +- sourcetext +status: active +--- +## 2 Normative references The following documents are referred to in the text in such a way that some or all of their content constitutes requirements of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/OST/27001/EN/c-3-Terms-and-definitions.md b/Corpus/Standards/ISO27x/OST/27001/EN/c-3-Terms-and-definitions.md index a940411..ce18537 100644 --- a/Corpus/Standards/ISO27x/OST/27001/EN/c-3-Terms-and-definitions.md +++ b/Corpus/Standards/ISO27x/OST/27001/EN/c-3-Terms-and-definitions.md @@ -1,6 +1,16 @@ -#iso27001/2022/EN - -# 3 Terms and definitions +--- +notetype: sourcetext +standard: ISO 27001 +version: 2022 +language: EN +type: clause +id: "C.3" +title: "Terms and definitions" +tags: +- iso27001/2022/EN +status: active +--- +## 3 Terms and definitions For the purposes of this document, the terms and definitions given in ISO/IEC 27000 apply. diff --git a/Corpus/Standards/ISO27x/OST/27001/EN/c-4-Context-of-the-organization.md b/Corpus/Standards/ISO27x/OST/27001/EN/c-4-Context-of-the-organization.md new file mode 100644 index 0000000..92c64e1 --- /dev/null +++ b/Corpus/Standards/ISO27x/OST/27001/EN/c-4-Context-of-the-organization.md @@ -0,0 +1,18 @@ +--- +notetype: reference +standard: ISO 27001 +version: 2022 +language: EN +type: clause +id: C.4 +title: Context of the organisation +tags: + - iso27001/2022/EN + - sourcetext +status: active +--- +# 4 Context of the organisation +[c-4.1-Understanding-the-organization-and-its-context](c-4.1-Understanding-the-organization-and-its-context.md) +[c-4.2-Understanding-the-needs-and-expectations-of-interested-parties](c-4.2-Understanding-the-needs-and-expectations-of-interested-parties.md) +[c-4.3-Determining-the-scope-of-the-information-security-management-system](c-4.3-Determining-the-scope-of-the-information-security-management-system.md) +[c-4.4-Information-security-management-system](c-4.4-Information-security-management-system.md) diff --git a/Corpus/Standards/ISO27x/OST/27001/EN/c-4.1-Understanding-the-organization-and-its-context.md b/Corpus/Standards/ISO27x/OST/27001/EN/c-4.1-Understanding-the-organization-and-its-context.md index a52b54a..d36ed28 100644 --- a/Corpus/Standards/ISO27x/OST/27001/EN/c-4.1-Understanding-the-organization-and-its-context.md +++ b/Corpus/Standards/ISO27x/OST/27001/EN/c-4.1-Understanding-the-organization-and-its-context.md @@ -1,4 +1,17 @@ -# Clause 4.1: Understanding the organization and its context +--- +notetype: reference +standard: ISO 27001 +version: 2022 +language: EN +type: clause +id: "C.4.1" +title: "Understanding the organization and its context" +tags: +- iso27001/2022/EN +- sourcetext +status: active +--- +## Clause 4.1: Understanding the organization and its context The organization shall determine external and internal issues that are relevant to its purpose and that affect its ability to achieve the intended outcome(s) of its information security management system. diff --git a/Corpus/Standards/ISO27x/OST/27001/EN/c-4.2-Understanding-the-needs-and-expectations-of-interested-parties.md b/Corpus/Standards/ISO27x/OST/27001/EN/c-4.2-Understanding-the-needs-and-expectations-of-interested-parties.md index def5f7a..32d5851 100644 --- a/Corpus/Standards/ISO27x/OST/27001/EN/c-4.2-Understanding-the-needs-and-expectations-of-interested-parties.md +++ b/Corpus/Standards/ISO27x/OST/27001/EN/c-4.2-Understanding-the-needs-and-expectations-of-interested-parties.md @@ -1,5 +1,17 @@ -#iso27001/2022/EN -# 4.2 Understanding the needs and expectations of interested parties +--- +notetype: reference +standard: ISO 27001 +version: 2022 +language: EN +type: clause +id: "C.4.2" +title: "Understanding the needs and expectations of interested parties" +tags: +- iso27001/2022/EN +- sourcetext +status: active +--- +## 4.2 Understanding the needs and expectations of interested parties The organization shall determine: diff --git a/Corpus/Standards/ISO27x/OST/27001/EN/c-4.3-Determining-the-scope-of-the-information-security-management-system.md b/Corpus/Standards/ISO27x/OST/27001/EN/c-4.3-Determining-the-scope-of-the-information-security-management-system.md index 31d130a..922e06b 100644 --- a/Corpus/Standards/ISO27x/OST/27001/EN/c-4.3-Determining-the-scope-of-the-information-security-management-system.md +++ b/Corpus/Standards/ISO27x/OST/27001/EN/c-4.3-Determining-the-scope-of-the-information-security-management-system.md @@ -1,5 +1,17 @@ -#iso27001/2022/EN -# 4.3 Determining the scope of the information security management system +--- +notetype: reference +standard: ISO 27001 +version: 2022 +language: EN +type: clause +id: "C.4.3" +title: "Determining the scope of the information security management system" +tags: +- iso27001/2022/EN +- sourcetext +status: active +--- +## 4.3 Determining the scope of the information security management system The organization shall determine the boundaries and applicability of the information security management system to establish its scope. diff --git a/Corpus/Standards/ISO27x/OST/27001/EN/c-4.4-Information-security-management-system.md b/Corpus/Standards/ISO27x/OST/27001/EN/c-4.4-Information-security-management-system.md index 18df68a..87ffade 100644 --- a/Corpus/Standards/ISO27x/OST/27001/EN/c-4.4-Information-security-management-system.md +++ b/Corpus/Standards/ISO27x/OST/27001/EN/c-4.4-Information-security-management-system.md @@ -1,4 +1,16 @@ -#iso27001/2022/EN -# 4.4 Information security management system +--- +notetype: reference +standard: ISO 27001 +version: 2022 +language: EN +type: clause +id: "C.4.4" +title: "Information security management system" +tags: +- iso27001/2022/EN +- sourcetext +status: active +--- +## 4.4 Information security management system The organization shall establish, implement, maintain and continually improve an information security management system, including the processes needed and their interactions, in accordance with the requirements of this document. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/OST/27001/EN/c-5-Leadership.md b/Corpus/Standards/ISO27x/OST/27001/EN/c-5-Leadership.md new file mode 100644 index 0000000..9b3e67b --- /dev/null +++ b/Corpus/Standards/ISO27x/OST/27001/EN/c-5-Leadership.md @@ -0,0 +1,18 @@ +--- +notetype: reference +standard: ISO 27001 +version: 2022 +language: EN +type: clause +id: C.5 +title: Leadership +tags: + - iso27001/2022/EN + - sourcetext +status: active +--- +# 5 Leadership + +[c-5.1-Leadership-and-commitment](c-5.1-Leadership-and-commitment.md) +[c-5.2-Policy](c-5.2-Policy.md) +[c-5.3-Organizational-roles-responsibilities-and-authorities](c-5.3-Organizational-roles-responsibilities-and-authorities.md) diff --git a/Corpus/Standards/ISO27x/OST/27001/EN/c-5.1-Leadership-and-commitment.md b/Corpus/Standards/ISO27x/OST/27001/EN/c-5.1-Leadership-and-commitment.md index 7cb915e..c2daa29 100644 --- a/Corpus/Standards/ISO27x/OST/27001/EN/c-5.1-Leadership-and-commitment.md +++ b/Corpus/Standards/ISO27x/OST/27001/EN/c-5.1-Leadership-and-commitment.md @@ -1,4 +1,16 @@ -#iso27001/2022/EN +--- +notetype: reference +standard: ISO 27001 +version: 2022 +language: EN +type: clause +id: "C.5.1" +title: "Leadership and commitment" +tags: +- iso27001/2022/EN +- sourcetext +status: active +--- ## 5.1 Leadership and commitment Top management shall demonstrate leadership and commitment with respect to the information security management system by: diff --git a/Corpus/Standards/ISO27x/OST/27001/EN/c-5.2-Policy.md b/Corpus/Standards/ISO27x/OST/27001/EN/c-5.2-Policy.md index 414bca5..c467e38 100644 --- a/Corpus/Standards/ISO27x/OST/27001/EN/c-5.2-Policy.md +++ b/Corpus/Standards/ISO27x/OST/27001/EN/c-5.2-Policy.md @@ -1,4 +1,16 @@ -#iso27001/2022/EN +--- +notetype: reference +standard: ISO 27001 +version: 2022 +language: EN +type: clause +id: "C.5.2" +title: "Policy" +tags: +- iso27001/2022/EN +- sourcetext +status: active +--- ## 5.2 Policy Top management shall establish an information security policy that: diff --git a/Corpus/Standards/ISO27x/OST/27001/EN/c-5.3-Organizational-roles-responsibilities-and-authorities.md b/Corpus/Standards/ISO27x/OST/27001/EN/c-5.3-Organizational-roles-responsibilities-and-authorities.md index 0c02608..ed455d9 100644 --- a/Corpus/Standards/ISO27x/OST/27001/EN/c-5.3-Organizational-roles-responsibilities-and-authorities.md +++ b/Corpus/Standards/ISO27x/OST/27001/EN/c-5.3-Organizational-roles-responsibilities-and-authorities.md @@ -1,5 +1,17 @@ -#iso27001/2022/EN -## 5.3 Organizational roles, responsibilities and authorities +--- +notetype: reference +standard: ISO 27001 +version: 2022 +language: EN +type: clause +id: "C.5.3" +title: "Organizational roles responsibilities and authorities" +tags: +- iso27001/2022/EN +- sourcetext +status: active +--- +## 5.3 Organizational roles responsibilities and authorities Top management shall ensure that the responsibilities and authorities for roles relevant to information security are assigned and communicated within the organization. diff --git a/Corpus/Standards/ISO27x/OST/27001/EN/c-6-Planning.md b/Corpus/Standards/ISO27x/OST/27001/EN/c-6-Planning.md new file mode 100644 index 0000000..2672402 --- /dev/null +++ b/Corpus/Standards/ISO27x/OST/27001/EN/c-6-Planning.md @@ -0,0 +1,17 @@ +--- +notetype: reference +standard: ISO 27001 +version: 2022 +language: EN +type: clause +id: C.6 +title: Planning +tags: + - iso27001/2022/EN + - sourcetext +status: active +--- +# 6 Planning +[c-6.1-Actions-to-address-risks-and-opportunities](c-6.1-Actions-to-address-risks-and-opportunities.md) +[c-6.2-Information-security-objectives-and-planning-to-achieve-them](c-6.2-Information-security-objectives-and-planning-to-achieve-them.md) +[c-6.3-Planning-of-changes](c-6.3-Planning-of-changes.md) diff --git a/Corpus/Standards/ISO27x/OST/27001/EN/c-6.1-Actions-to-address-risks-and-opportunities.md b/Corpus/Standards/ISO27x/OST/27001/EN/c-6.1-Actions-to-address-risks-and-opportunities.md new file mode 100644 index 0000000..5e16316 --- /dev/null +++ b/Corpus/Standards/ISO27x/OST/27001/EN/c-6.1-Actions-to-address-risks-and-opportunities.md @@ -0,0 +1,19 @@ +--- +notetype: reference +standard: ISO 27001 +version: 2022 +language: EN +type: clause +id: C.6.1 +title: Actions to address risks and opportunities +tags: + - iso27001/2022/EN +- sourcetext +status: active +--- +## 6.1 Actions to address risks and opportunities + +[c-6.1.1-General](c-6.1.1-General.md) +[c-6.1.2-Information-security-risk-assessment](c-6.1.2-Information-security-risk-assessment.md) +[c-6.1.3-Information-security-risk-treatment](c-6.1.3-Information-security-risk-treatment.md) + diff --git a/Corpus/Standards/ISO27x/OST/27001/EN/c-6.1.1-General.md b/Corpus/Standards/ISO27x/OST/27001/EN/c-6.1.1-General.md index 091785a..0873821 100644 --- a/Corpus/Standards/ISO27x/OST/27001/EN/c-6.1.1-General.md +++ b/Corpus/Standards/ISO27x/OST/27001/EN/c-6.1.1-General.md @@ -1,3 +1,16 @@ +--- +notetype: reference +standard: ISO 27001 +version: 2022 +language: EN +type: clause +id: "C.6.1.1" +title: "General" +tags: +- iso27001/2022/EN +- sourcetext +status: active +--- ### 6.1.1 General When planning for the information security management system, the organization shall consider the issues referred to in [4.1](c-4.1-Understanding-the-organization-and-its-context.md) and the requirements referred to in [4.2](ISO_27001_2022_OT%204.2%20Understanding%20the%20needs%20and%20expectations%20of%20interested%20parties.md) and determine the risks and opportunities that need to be addressed to: diff --git a/Corpus/Standards/ISO27x/OST/27001/EN/c-6.1.2-Information-security-risk-assessment.md b/Corpus/Standards/ISO27x/OST/27001/EN/c-6.1.2-Information-security-risk-assessment.md index 6dae621..1d80461 100644 --- a/Corpus/Standards/ISO27x/OST/27001/EN/c-6.1.2-Information-security-risk-assessment.md +++ b/Corpus/Standards/ISO27x/OST/27001/EN/c-6.1.2-Information-security-risk-assessment.md @@ -1,3 +1,16 @@ +--- +notetype: reference +standard: ISO 27001 +version: 2022 +language: EN +type: clause +id: "C.6.1.2" +title: "Information security risk assessment" +tags: +- iso27001/2022/EN +- sourcetext +status: active +--- ### 6.1.2 Information security risk assessment The organization shall define and apply an information security risk assessment process that: diff --git a/Corpus/Standards/ISO27x/OST/27001/EN/c-6.1.3-Information-security-risk-treatment.md b/Corpus/Standards/ISO27x/OST/27001/EN/c-6.1.3-Information-security-risk-treatment.md index 3d2b38e..1130b04 100644 --- a/Corpus/Standards/ISO27x/OST/27001/EN/c-6.1.3-Information-security-risk-treatment.md +++ b/Corpus/Standards/ISO27x/OST/27001/EN/c-6.1.3-Information-security-risk-treatment.md @@ -1,3 +1,16 @@ +--- +notetype: reference +standard: ISO 27001 +version: 2022 +language: EN +type: clause +id: "C.6.1.3" +title: "Information security risk treatment" +tags: +- iso27001/2022/EN +- sourcetext +status: active +--- ### 6.1.3 Information security risk treatment The organization shall define and apply an information security risk treatment process to: diff --git a/Corpus/Standards/ISO27x/OST/27001/EN/c-6.2-Information-security-objectives-and-planning-to-achieve-them.md b/Corpus/Standards/ISO27x/OST/27001/EN/c-6.2-Information-security-objectives-and-planning-to-achieve-them.md index 3934666..22b0b8c 100644 --- a/Corpus/Standards/ISO27x/OST/27001/EN/c-6.2-Information-security-objectives-and-planning-to-achieve-them.md +++ b/Corpus/Standards/ISO27x/OST/27001/EN/c-6.2-Information-security-objectives-and-planning-to-achieve-them.md @@ -1,4 +1,16 @@ -#iso27001/2022/EN +--- +notetype: reference +standard: ISO 27001 +version: 2022 +language: EN +type: clause +id: "C.6.2" +title: "Information security objectives and planning to achieve them" +tags: +- iso27001/2022/EN +- sourcetext +status: active +--- ## 6.2 Information security objectives and planning to achieve them The organization shall establish information security objectives at relevant functions and levels. diff --git a/Corpus/Standards/ISO27x/OST/27001/EN/c-6.3-Planning-of-changes.md b/Corpus/Standards/ISO27x/OST/27001/EN/c-6.3-Planning-of-changes.md index 07b83f1..f680f97 100644 --- a/Corpus/Standards/ISO27x/OST/27001/EN/c-6.3-Planning-of-changes.md +++ b/Corpus/Standards/ISO27x/OST/27001/EN/c-6.3-Planning-of-changes.md @@ -1,4 +1,16 @@ -#iso27001/2022/EN +--- +notetype: reference +standard: ISO 27001 +version: 2022 +language: EN +type: clause +id: "C.6.3" +title: "Planning of changes" +tags: +- iso27001/2022/EN +- sourcetext +status: active +--- ## 6.3 Planning of changes When the organization determines the need for changes to the information security management system, the changes shall be carried out in a planned manner. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/OST/27001/EN/c-7-Support.md b/Corpus/Standards/ISO27x/OST/27001/EN/c-7-Support.md new file mode 100644 index 0000000..3f4b7cb --- /dev/null +++ b/Corpus/Standards/ISO27x/OST/27001/EN/c-7-Support.md @@ -0,0 +1,19 @@ +--- +notetype: reference +standard: ISO 27001 +version: 2022 +language: EN +type: clause +id: C.7 +title: Support +tags: + - iso27001/2022/EN + - sourcetext +status: active +--- +# 7 Support +[c-7.1-Resources](c-7.1-Resources.md) +[c-7.2-Competence](c-7.2-Competence.md) +[c-7.3-Awareness](c-7.3-Awareness.md) +[c-7.4-Communication](c-7.4-Communication.md) +[c-7.5-Documented-information](c-7.5-Documented-information.md) diff --git a/Corpus/Standards/ISO27x/OST/27001/EN/c-7.1-Resources.md b/Corpus/Standards/ISO27x/OST/27001/EN/c-7.1-Resources.md index 840b863..b10ab56 100644 --- a/Corpus/Standards/ISO27x/OST/27001/EN/c-7.1-Resources.md +++ b/Corpus/Standards/ISO27x/OST/27001/EN/c-7.1-Resources.md @@ -1,4 +1,16 @@ -#iso27001/2022/EN +--- +notetype: reference +standard: ISO 27001 +version: 2022 +language: EN +type: clause +id: "C.7.1" +title: "Resources" +tags: +- iso27001/2022/EN +- sourcetext +status: active +--- ## 7.1 Resources The organization shall determine and provide the resources needed for the establishment, implementation, maintenance and continual improvement of the information security management system. diff --git a/Corpus/Standards/ISO27x/OST/27001/EN/c-7.2-Competence.md b/Corpus/Standards/ISO27x/OST/27001/EN/c-7.2-Competence.md index d674099..4e2f82b 100644 --- a/Corpus/Standards/ISO27x/OST/27001/EN/c-7.2-Competence.md +++ b/Corpus/Standards/ISO27x/OST/27001/EN/c-7.2-Competence.md @@ -1,5 +1,16 @@ -#iso27001/2022/EN - +--- +notetype: reference +standard: ISO 27001 +version: 2022 +language: EN +type: clause +id: "C.7.2" +title: "Competence" +tags: +- iso27001/2022/EN +- sourcetext +status: active +--- ## 7.2 Competence The organization shall: diff --git a/Corpus/Standards/ISO27x/OST/27001/EN/c-7.3-Awareness.md b/Corpus/Standards/ISO27x/OST/27001/EN/c-7.3-Awareness.md index 1f7e419..47b695e 100644 --- a/Corpus/Standards/ISO27x/OST/27001/EN/c-7.3-Awareness.md +++ b/Corpus/Standards/ISO27x/OST/27001/EN/c-7.3-Awareness.md @@ -1,5 +1,16 @@ -#iso27001/2022/EN - +--- +notetype: reference +standard: ISO 27001 +version: 2022 +language: EN +type: clause +id: "C.7.3" +title: "Awareness" +tags: +- iso27001/2022/EN +- sourcetext +status: active +--- ## 7.3 Awareness Persons doing work under the organization's control shall be aware of: diff --git a/Corpus/Standards/ISO27x/OST/27001/EN/c-7.4-Communication.md b/Corpus/Standards/ISO27x/OST/27001/EN/c-7.4-Communication.md index 4bb908d..a234a71 100644 --- a/Corpus/Standards/ISO27x/OST/27001/EN/c-7.4-Communication.md +++ b/Corpus/Standards/ISO27x/OST/27001/EN/c-7.4-Communication.md @@ -1,5 +1,16 @@ -#iso27001/2022/EN - +--- +notetype: reference +standard: ISO 27001 +version: 2022 +language: EN +type: clause +id: "C.7.4" +title: "Communication" +tags: +- iso27001/2022/EN +- sourcetext +status: active +--- ## 7.4 Communication The organization shall determine the need for internal and external communications relevant to the information security management system including: diff --git a/Corpus/Standards/ISO27x/OST/27001/EN/c-7.5-Documented-information.md b/Corpus/Standards/ISO27x/OST/27001/EN/c-7.5-Documented-information.md index bf511be..5b5d6f2 100644 --- a/Corpus/Standards/ISO27x/OST/27001/EN/c-7.5-Documented-information.md +++ b/Corpus/Standards/ISO27x/OST/27001/EN/c-7.5-Documented-information.md @@ -1,4 +1,16 @@ -#iso27001/2022/EN +--- +notetype: reference +standard: ISO 27001 +version: 2022 +language: EN +type: clause +id: "C.7.5" +title: "Documented information" +tags: +- iso27001/2022/EN +- sourcetext +status: active +--- ## 7.5 Documented information ### 7.5.1 General diff --git a/Corpus/Standards/ISO27x/OST/27001/EN/c-8-Operation.md b/Corpus/Standards/ISO27x/OST/27001/EN/c-8-Operation.md new file mode 100644 index 0000000..21c4955 --- /dev/null +++ b/Corpus/Standards/ISO27x/OST/27001/EN/c-8-Operation.md @@ -0,0 +1,17 @@ +--- +notetype: reference +standard: ISO 27001 +version: 2022 +language: EN +type: clause +id: C.8 +title: Operation +tags: + - iso27001/2022/EN + - sourcetext +status: active +--- +# 8 Operation +[c-8.1-Operational-planning-and-control](c-8.1-Operational-planning-and-control.md) +[c-8.2-Information-security-risk-assessment](c-8.2-Information-security-risk-assessment.md) +[c-8.3-Information-security-risk-treatment](c-8.3-Information-security-risk-treatment.md) diff --git a/Corpus/Standards/ISO27x/OST/27001/EN/c-8.1-Operational-planning-and-control.md b/Corpus/Standards/ISO27x/OST/27001/EN/c-8.1-Operational-planning-and-control.md index 6793dae..f3b460d 100644 --- a/Corpus/Standards/ISO27x/OST/27001/EN/c-8.1-Operational-planning-and-control.md +++ b/Corpus/Standards/ISO27x/OST/27001/EN/c-8.1-Operational-planning-and-control.md @@ -1,4 +1,16 @@ -#iso27001/2022/EN +--- +notetype: reference +standard: ISO 27001 +version: 2022 +language: EN +type: clause +id: "C.8.1" +title: "Operational planning and control" +tags: +- iso27001/2022/EN +- sourcetext +status: active +--- ## 8.1 Operational planning and control The organization shall plan, implement and control the processes needed to meet requirements, and to implement the actions determined in Clause 6, by: diff --git a/Corpus/Standards/ISO27x/OST/27001/EN/c-8.2-Information-security-risk-assessment.md b/Corpus/Standards/ISO27x/OST/27001/EN/c-8.2-Information-security-risk-assessment.md index 27c30b7..7dc2e4b 100644 --- a/Corpus/Standards/ISO27x/OST/27001/EN/c-8.2-Information-security-risk-assessment.md +++ b/Corpus/Standards/ISO27x/OST/27001/EN/c-8.2-Information-security-risk-assessment.md @@ -1,5 +1,17 @@ -#iso27001/2022/EN -# Clause 8.2: Information security risk assessment +--- +notetype: reference +standard: ISO 27001 +version: 2022 +language: EN +type: clause +id: "C.8.2" +title: "Information security risk assessment" +tags: +- iso27001/2022/EN +- sourcetext +status: active +--- +## 8.2 Information security risk assessment The organization shall perform information security risk assessments at planned intervals or when significant changes are proposed or occur, taking account of the criteria established in [6.1.2a](ISO_27001_OT%206.1.2%20Information%20security%20risk%20assessment.md). diff --git a/Corpus/Standards/ISO27x/OST/27001/EN/c-8.3-Information-security-risk-treatment.md b/Corpus/Standards/ISO27x/OST/27001/EN/c-8.3-Information-security-risk-treatment.md index c0b1739..8b6a17f 100644 --- a/Corpus/Standards/ISO27x/OST/27001/EN/c-8.3-Information-security-risk-treatment.md +++ b/Corpus/Standards/ISO27x/OST/27001/EN/c-8.3-Information-security-risk-treatment.md @@ -1,8 +1,17 @@ --- +notetype: reference +standard: ISO 27001 +version: 2022 +language: EN +type: clause +id: "C.8.3" +title: "Information security risk treatment" tags: - - iso27001/2022/EN +- iso27001/2022/EN +- sourcetext +status: active --- -# Clause 8.3 Information security risk treatment +## 8.3 Information security risk treatment The organization shall implement the information security risk treatment plan. diff --git a/Corpus/Standards/ISO27x/OST/27001/EN/c-9-Performance-evaluation.md b/Corpus/Standards/ISO27x/OST/27001/EN/c-9-Performance-evaluation.md new file mode 100644 index 0000000..6913988 --- /dev/null +++ b/Corpus/Standards/ISO27x/OST/27001/EN/c-9-Performance-evaluation.md @@ -0,0 +1,17 @@ +--- +notetype: reference +standard: ISO 27001 +version: 2022 +language: EN +type: clause +id: C.9 +title: Performance evaluation +tags: + - iso27001/2022/EN + - sourcetext +status: active +--- +# 9 Performance evaluation +[c-9.1-Monitoring-measurement-analysis-and-evaluation](c-9.1-Monitoring-measurement-analysis-and-evaluation.md) +[c-9.2-Internal-audit](c-9.2-Internal-audit.md) +[c-9.3-Management-review](c-9.3-Management-review.md) diff --git a/Corpus/Standards/ISO27x/OST/27001/EN/c-9.1-Monitoring-measurement-analysis-and-evaluation.md b/Corpus/Standards/ISO27x/OST/27001/EN/c-9.1-Monitoring-measurement-analysis-and-evaluation.md index 5c743e5..91e061c 100644 --- a/Corpus/Standards/ISO27x/OST/27001/EN/c-9.1-Monitoring-measurement-analysis-and-evaluation.md +++ b/Corpus/Standards/ISO27x/OST/27001/EN/c-9.1-Monitoring-measurement-analysis-and-evaluation.md @@ -1,5 +1,17 @@ -#iso27001/2022/EN -## 9.1 Monitoring, measurement, analysis and evaluation +--- +notetype: reference +standard: ISO 27001 +version: 2022 +language: EN +type: clause +id: "C.9.1" +title: "Monitoring measurement analysis and evaluation" +tags: +- iso27001/2022/EN +- sourcetext +status: active +--- +## 9.1 Monitoring measurement analysis and evaluation The organization shall determine: diff --git a/Corpus/Standards/ISO27x/OST/27001/EN/c-9.2-Internal-audit.md b/Corpus/Standards/ISO27x/OST/27001/EN/c-9.2-Internal-audit.md index ca63f44..c782b93 100644 --- a/Corpus/Standards/ISO27x/OST/27001/EN/c-9.2-Internal-audit.md +++ b/Corpus/Standards/ISO27x/OST/27001/EN/c-9.2-Internal-audit.md @@ -1,6 +1,17 @@ -#iso27001/2022/EN +--- +notetype: reference +standard: ISO 27001 +version: 2022 +language: EN +type: clause +id: "C.9.2" +title: "Internal audit" +tags: +- iso27001/2022/EN +- sourcetext +status: active +--- ## 9.2 Internal audit - ### 9.2.1 General The organization shall conduct internal audits at planned intervals to provide information on whether the information security management system: diff --git a/Corpus/Standards/ISO27x/OST/27001/EN/c-9.3-Management-review.md b/Corpus/Standards/ISO27x/OST/27001/EN/c-9.3-Management-review.md index de57def..a701705 100644 --- a/Corpus/Standards/ISO27x/OST/27001/EN/c-9.3-Management-review.md +++ b/Corpus/Standards/ISO27x/OST/27001/EN/c-9.3-Management-review.md @@ -1,5 +1,16 @@ -#iso27001/2022/EN - +--- +notetype: reference +standard: ISO 27001 +version: 2022 +language: EN +type: clause +id: "C.9.3" +title: "Management review" +tags: +- iso27001/2022/EN +- sourcetext +status: active +--- ## 9.3 Management review ### 9.3.1 General diff --git a/Corpus/Standards/ISO27x/OST/27001/EN/ISO_27001_OT F Foreword.md b/Corpus/Standards/ISO27x/OST/27001/EN/c-f-Foreword.md similarity index 98% rename from Corpus/Standards/ISO27x/OST/27001/EN/ISO_27001_OT F Foreword.md rename to Corpus/Standards/ISO27x/OST/27001/EN/c-f-Foreword.md index 3415d87..70a6076 100644 --- a/Corpus/Standards/ISO27x/OST/27001/EN/ISO_27001_OT F Foreword.md +++ b/Corpus/Standards/ISO27x/OST/27001/EN/c-f-Foreword.md @@ -1,6 +1,4 @@ -#iso27001/2022/EN - -# Foreword +## F Foreword ISO (the International Organization for Standardization) and IEC (the International Electrotechnical Commission) form the specialized system for worldwide standardization. National bodies that are members of ISO or IEC participate in the development of International Standards through technical committees established by the respective organization to deal with particular fields of technical activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other international organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the work. diff --git a/Corpus/Standards/ISO27x/OST/27001/EN/rename-iso-title.zsh b/Corpus/Standards/ISO27x/OST/27001/EN/rename-iso-title.zsh deleted file mode 100755 index d756956..0000000 --- a/Corpus/Standards/ISO27x/OST/27001/EN/rename-iso-title.zsh +++ /dev/null @@ -1,90 +0,0 @@ -#!/usr/bin/env zsh -set -euo pipefail - -execute=false -if [[ ${1:-} == '--execute' ]]; then - execute=true - shift -fi - -if [[ $# -gt 0 ]]; then - print -u2 'Usage: rename-iso-title.zsh [--execute]' - exit 2 -fi - -# Requires Obsidian app running and CLI enabled. -: ${OBSIDIAN_CLI:=obsidian} - -files=(c-[0-9]*\.md(N)) -if (( ${#files} == 0 )); then - print 'No matching files found.' - exit 0 -fi - -for src in "$files[@]"; do - base=${src:t} - - # Read the level 1 header from the file - # Format: # - # Extract everything after the first number and space - header=$(head -n 1 "$src" | sed 's/^# [0-9.]* //') - - if [[ -z "$header" ]]; then - print -u2 "WARN skipped (no header found): $src" - continue - fi - - # Clean up the title - title=$header - # Replace spaces with dashes - title=${title// /-} - # Remove commas, slashes, parentheses, quotes - title=${title//,/} - title=${title//\//} - title=${title//\\/} - title=${title//\(} - title=${title//\)} - title=${title//\'} - title=${title//\'} - # Replace diacritics with base characters - title=${title//ï/i} - title=${title//é/e} - title=${title//è/e} - title=${title//ê/e} - title=${title//ë/e} - title=${title//ö/o} - title=${title//ü/u} - title=${title//ó/o} - title=${title//ô/o} - title=${title//á/a} - title=${title//à/a} - title=${title//ã/a} - title=${title//ä/a} - title=${title//í/i} - title=${title//ì/i} - title=${title//ñ/n} - title=${title//ú/u} - title=${title//ù/u} - # Remove multiple dashes - title=${title//---/-} - title=${title//--/-} - # Remove leading/trailing dashes - title=${title#-} - title=${title%-} - - # Build new filename: c-n.n-TITLE.md - ext="${src:r}.md" # extension without the extra .md issue - filename="${src%.*}" - target="${filename}-${title}.md" - - if [[ $src == $target ]]; then - print "SKIP $src" - continue - fi - - print "SRC $src" - print "DEST $target" - if $execute; then - "$OBSIDIAN_CLI" rename file="$src" name="$target" - fi -done \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/OST/27001/EN/rename-iso.zsh b/Corpus/Standards/ISO27x/OST/27001/EN/rename-iso.zsh deleted file mode 100755 index b28bf84..0000000 --- a/Corpus/Standards/ISO27x/OST/27001/EN/rename-iso.zsh +++ /dev/null @@ -1,50 +0,0 @@ -#!/usr/bin/env zsh -set -euo pipefail - -execute=false -if [[ ${1:-} == '--execute' ]]; then - execute=true - shift -fi - -if [[ $# -gt 0 ]]; then - print -u2 'Usage: rename-iso.zsh [--execute]' - exit 2 -fi - -# Requires Obsidian app running and CLI enabled. -# Adjust OBSIDIAN_CLI to the command you actually use (e.g. `obsidian`). -: ${OBSIDIAN_CLI:=obsidian} - -files=(ISO_27001*.md(N)) -if (( ${#files} == 0 )); then - print 'No matching files found.' - exit 0 -fi - -for src in "$files[@]"; do - base=${src:t} - # Match both ISO_27001_OT and ISO_27001_2022_OT patterns - if [[ $base =~ '^ISO_27001(_2022)?_OT ([0-9.]+) (.+)\.md$' ]]; then - version=${match[2]#_} - title=${match[3]} - target="c-${version}-${title}.md" - # Replace spaces with dashes - target=${target// /-} - # Remove commas - target=${target//,} - # Prevent double dashes - target=${target//--/-} - if [[ $src == $target ]]; then - print "SKIP $src" - continue - fi - print "SRC $src" - print "DEST $target" - if $execute; then - "$OBSIDIAN_CLI" rename file="$src" name="$target" - fi - else - print -u2 "WARN skipped (pattern mismatch): $src" - fi -done diff --git a/Corpus/Standards/ISO27x/OST/27001/NL/ISO_27001_2023_NL_PDF.md b/Corpus/Standards/ISO27x/OST/27001/NL/ISO_27001_2023_NL_PDF.md deleted file mode 100644 index 5c52de0..0000000 --- a/Corpus/Standards/ISO27x/OST/27001/NL/ISO_27001_2023_NL_PDF.md +++ /dev/null @@ -1,6 +0,0 @@ -#iso27001/2023/NL -# ISO 27001 2023 NL - -![](ISO_IEC_27001_2023_NL.pdf) - - diff --git a/Corpus/Standards/ISO27x/OST/27001/NL/add_yaml.py b/Corpus/Standards/ISO27x/OST/27001/NL/add_yaml.py new file mode 100644 index 0000000..1206c0c --- /dev/null +++ b/Corpus/Standards/ISO27x/OST/27001/NL/add_yaml.py @@ -0,0 +1,51 @@ +#!/usr/bin/env python3 +import os +import re + +directory = '/Users/rico/src/iso27diy-corp/Corpus/Standards/ISO27x/OST/27001/NL/' + +for filename in os.listdir(directory): + if filename.endswith('.md'): + filepath = os.path.join(directory, filename) + with open(filepath, 'r') as f: + lines = f.readlines() + if lines and lines[0].strip() == '---': + continue # Already has YAML + # Extract id and title from filename + match = re.match(r'c-([0-9.]+)-(.+)\.md', filename) + if match: + num = match.group(1) + title_part = match.group(2) + id_val = f'C.{num}' + title = title_part.replace('-', ' ') + elif filename == 'c-0-Inleiding.md': + id_val = 'C.0' + title = 'Inleiding' + else: + # For other files + match = re.match(r'c-([0-9]+)-(.+)\.md', filename) + if match: + num = match.group(1) + title_part = match.group(2) + id_val = f'C.{num}' + title = title_part.replace('-', ' ') + else: + continue # Skip if not matching + + yaml = f'''--- +notetype: sourcetext +standard: ISO 27001 +version: 2023 +language: NL +type: clause +id: "{id_val}" +title: "{title}" +tags: +- iso27001/2023/NL +status: active +--- +''' + with open(filepath, 'w') as f: + f.write(yaml + ''.join(lines)) + +print("YAML front matter added to files that didn't have it.") \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/OST/27001/NL/c-0-Inleiding.md b/Corpus/Standards/ISO27x/OST/27001/NL/c-0-Inleiding.md index bc0bcf7..c14e7b0 100644 --- a/Corpus/Standards/ISO27x/OST/27001/NL/c-0-Inleiding.md +++ b/Corpus/Standards/ISO27x/OST/27001/NL/c-0-Inleiding.md @@ -1,3 +1,16 @@ +--- +notetype: reference +standard: ISO 27001 +version: 2023 +language: NL +type: clause +id: "C.0" +title: "Inleiding" +tags: +- iso27001/2023/NL +- sourcetext +status: active +--- # 0 Inleiding 1. **Algemeen** diff --git a/Corpus/Standards/ISO27x/OST/27001/NL/c-1-Onderwerp-en-toepassingsgebied.md b/Corpus/Standards/ISO27x/OST/27001/NL/c-1-Onderwerp-en-toepassingsgebied.md index 8f90e1e..d226f71 100644 --- a/Corpus/Standards/ISO27x/OST/27001/NL/c-1-Onderwerp-en-toepassingsgebied.md +++ b/Corpus/Standards/ISO27x/OST/27001/NL/c-1-Onderwerp-en-toepassingsgebied.md @@ -1,3 +1,16 @@ +--- +notetype: reference +standard: ISO 27001 +version: 2023 +language: NL +type: clause +id: "C.1" +title: "Onderwerp en toepassingsgebied" +tags: +- iso27001/2023/NL +- sourcetext +status: active +--- # 1 Onderwerp en toepassingsgebied Dit document specificeert de eisen voor het binnen de context van de organisatie inrichten, implementeren, in stand houden en continu verbeteren van een managementsysteem voor informatiebeveiliging. Dit document bevat ook eisen voor het beoordelen en behandelen van informatiebeveiligingsrisico\'s afgestemd op de behoeften van de organisatie. De eisen in dit document zijn algemeen en bedoeld om van toepassing te zijn voor alle organisaties, ongeacht type, omvang of aard. Het uitsluiten van een of meer eisen van hoofdstuk 4 t/m 10 is niet aanvaardbaar als een organisatie naleving van dit document wil claimen. diff --git a/Corpus/Standards/ISO27x/OST/27001/NL/c-10-Verbetering.md b/Corpus/Standards/ISO27x/OST/27001/NL/c-10-Verbetering.md index 981a35c..234a38b 100644 --- a/Corpus/Standards/ISO27x/OST/27001/NL/c-10-Verbetering.md +++ b/Corpus/Standards/ISO27x/OST/27001/NL/c-10-Verbetering.md @@ -1 +1,16 @@ +--- +notetype: reference +standard: ISO 27001 +version: 2023 +language: NL +type: clause +id: "C.10" +title: "Verbetering" +tags: +- iso27001/2023/NL +- sourcetext +status: active +--- # 10 Verbetering +[c-10.1-Continue-verbetering](c-10.1-Continue-verbetering.md) +[c-10.2-Afwijkingen-en-corrigerende-maatregelen](c-10.2-Afwijkingen-en-corrigerende-maatregelen.md) diff --git a/Corpus/Standards/ISO27x/OST/27001/NL/c-10.1-Continue-verbetering.md b/Corpus/Standards/ISO27x/OST/27001/NL/c-10.1-Continue-verbetering.md index 5239ef9..19c0d9c 100644 --- a/Corpus/Standards/ISO27x/OST/27001/NL/c-10.1-Continue-verbetering.md +++ b/Corpus/Standards/ISO27x/OST/27001/NL/c-10.1-Continue-verbetering.md @@ -1,3 +1,16 @@ -# 10.1 Continue verbetering +--- +notetype: reference +standard: ISO 27001 +version: 2023 +language: NL +type: clause +id: "C.10.1" +title: "Continue verbetering" +tags: +- iso27001/2023/NL +- sourcetext +status: active +--- +## 10.1 Continue verbetering De organisatie moet continu de geschiktheid, toereikendheid en doeltreffendheid van het managementsysteem voor informatiebeveiliging verbeteren. diff --git a/Corpus/Standards/ISO27x/OST/27001/NL/c-10.2-Afwijkingen-en-corrigerende-maatregelen.md b/Corpus/Standards/ISO27x/OST/27001/NL/c-10.2-Afwijkingen-en-corrigerende-maatregelen.md index db8adee..c336904 100644 --- a/Corpus/Standards/ISO27x/OST/27001/NL/c-10.2-Afwijkingen-en-corrigerende-maatregelen.md +++ b/Corpus/Standards/ISO27x/OST/27001/NL/c-10.2-Afwijkingen-en-corrigerende-maatregelen.md @@ -1,20 +1,33 @@ -# 10.2 Afwijkingen en corrigerende maatregelen +--- +notetype: reference +standard: ISO 27001 +version: 2023 +language: NL +type: clause +id: "C.10.2" +title: "Afwijkingen en corrigerende maatregelen" +tags: +- iso27001/2023/NL +- sourcetext +status: active +--- +## 10.2 Afwijkingen en corrigerende maatregelen Wanneer zich een afwijking voordoet, moet de organisatie: a) op de afwijking reageren, en indien van toepassing: - 1. maatregelen treffen om de afwijking te beheersen en te corrigeren; +## 1. maatregelen treffen om de afwijking te beheersen en te corrigeren; - 2. de consequenties aanpakken; +## 2. de consequenties aanpakken; b) de noodzaak evalueren om maatregelen te treffen om de oorzaken van de afwijking weg te nemen, zodat de afwijking zich niet herhaalt of zich niet elders voordoet, door: - 1. de afwijking te beoordelen; +## 1. de afwijking te beoordelen; - 2. de oorzaken van de afwijking vast te stellen; en +## 2. de oorzaken van de afwijking vast te stellen; en - 3. vast te stellen of zich gelijksoortige afwijkingen voordoen of kunnen voordoen; +## 3. vast te stellen of zich gelijksoortige afwijkingen voordoen of kunnen voordoen; c) de benodigde maatregelen implementeren; diff --git a/Corpus/Standards/ISO27x/OST/27001/NL/c-2-Normatieve-verwijzingen.md b/Corpus/Standards/ISO27x/OST/27001/NL/c-2-Normatieve-verwijzingen.md index ca8dc6c..523c2f2 100644 --- a/Corpus/Standards/ISO27x/OST/27001/NL/c-2-Normatieve-verwijzingen.md +++ b/Corpus/Standards/ISO27x/OST/27001/NL/c-2-Normatieve-verwijzingen.md @@ -1,3 +1,16 @@ +--- +notetype: reference +standard: ISO 27001 +version: 2023 +language: NL +type: clause +id: "C.2" +title: "Normatieve verwijzingen" +tags: +- iso27001/2023/NL +- sourcetext +status: active +--- # 2 Normatieve verwijzingen Naar de volgende documenten wordt in de tekst zo verwezen dat de bepalingen ervan geheel diff --git a/Corpus/Standards/ISO27x/OST/27001/NL/c-3-Termen-en-definities.md b/Corpus/Standards/ISO27x/OST/27001/NL/c-3-Termen-en-definities.md index cafbf27..0cb72e2 100644 --- a/Corpus/Standards/ISO27x/OST/27001/NL/c-3-Termen-en-definities.md +++ b/Corpus/Standards/ISO27x/OST/27001/NL/c-3-Termen-en-definities.md @@ -1,3 +1,15 @@ +--- +notetype: sourcetext +standard: ISO 27001 +version: 2023 +language: NL +type: clause +id: "C.3" +title: "Termen en definities" +tags: +- iso27001/2023/NL +status: active +--- # 3 Termen en definities Voor de toepassing van dit document gelden de termen en definities zoals opgenomen in ISO/IEC 27000. diff --git a/Corpus/Standards/ISO27x/OST/27001/NL/c-4-Context-van-de-organisatie.md b/Corpus/Standards/ISO27x/OST/27001/NL/c-4-Context-van-de-organisatie.md index ece95e2..e997571 100644 --- a/Corpus/Standards/ISO27x/OST/27001/NL/c-4-Context-van-de-organisatie.md +++ b/Corpus/Standards/ISO27x/OST/27001/NL/c-4-Context-van-de-organisatie.md @@ -1 +1,18 @@ +--- +notetype: reference +standard: ISO 27001 +version: 2023 +language: NL +type: clause +id: "C.4" +title: "Context van de organisatie" +tags: +- iso27001/2023/NL +- sourcetext +status: active +--- # 4 Context van de organisatie +[c-4.1-Inzicht-in-de-organisatie-en-haar-context](c-4.1-Inzicht-in-de-organisatie-en-haar-context.md) +[c-4.2-Inzicht-in-de-behoeften-en-verwachtingen-van-belanghebbenden](c-4.2-Inzicht-in-de-behoeften-en-verwachtingen-van-belanghebbenden.md) +[c-4.3-Het-toepassingsgebied-van-het-managementsysteem-voor-informatiebeveiliging-vaststellen](c-4.3-Het-toepassingsgebied-van-het-managementsysteem-voor-informatiebeveiliging-vaststellen.md) +[c-4.4-Managementsysteem-voor-informatiebeveiliging](c-4.4-Managementsysteem-voor-informatiebeveiliging.md) diff --git a/Corpus/Standards/ISO27x/OST/27001/NL/c-4.1-Inzicht-in-de-organisatie-en-haar-context.md b/Corpus/Standards/ISO27x/OST/27001/NL/c-4.1-Inzicht-in-de-organisatie-en-haar-context.md index f67a7ec..e897f5a 100644 --- a/Corpus/Standards/ISO27x/OST/27001/NL/c-4.1-Inzicht-in-de-organisatie-en-haar-context.md +++ b/Corpus/Standards/ISO27x/OST/27001/NL/c-4.1-Inzicht-in-de-organisatie-en-haar-context.md @@ -1,4 +1,17 @@ -# 4.1 Inzicht in de organisatie en haar context +--- +notetype: reference +standard: ISO 27001 +version: 2023 +language: NL +type: clause +id: "C.4.1" +title: "Inzicht in de organisatie en haar context" +tags: +- iso27001/2023/NL +- sourcetext +status: active +--- +## 4.1 Inzicht in de organisatie en haar context De organisatie moet externe en interne (belangrijke) punten vaststellen die relevant zijn voor haar doelstelling en die haar vermogen beïnvloeden om het (de) beoogde resulta(a)t(en) van haar managementsysteem voor informatiebeveiliging te behalen. diff --git a/Corpus/Standards/ISO27x/OST/27001/NL/c-4.2-Inzicht-in-de-behoeften-en-verwachtingen-van-belanghebbenden.md b/Corpus/Standards/ISO27x/OST/27001/NL/c-4.2-Inzicht-in-de-behoeften-en-verwachtingen-van-belanghebbenden.md index 257645f..e1c8333 100644 --- a/Corpus/Standards/ISO27x/OST/27001/NL/c-4.2-Inzicht-in-de-behoeften-en-verwachtingen-van-belanghebbenden.md +++ b/Corpus/Standards/ISO27x/OST/27001/NL/c-4.2-Inzicht-in-de-behoeften-en-verwachtingen-van-belanghebbenden.md @@ -1,4 +1,17 @@ -# 4.2 Inzicht in de behoeften en verwachtingen van belanghebbenden +--- +notetype: reference +standard: ISO 27001 +version: 2023 +language: NL +type: clause +id: "C.4.2" +title: "Inzicht in de behoeften en verwachtingen van belanghebbenden" +tags: +- iso27001/2023/NL +- sourcetext +status: active +--- +## 4.2 Inzicht in de behoeften en verwachtingen van belanghebbenden De organisatie moet vaststellen: diff --git a/Corpus/Standards/ISO27x/OST/27001/NL/c-4.3-Het-toepassingsgebied-van-het-managementsysteem-voor-informatiebeveiliging-vaststellen.md b/Corpus/Standards/ISO27x/OST/27001/NL/c-4.3-Het-toepassingsgebied-van-het-managementsysteem-voor-informatiebeveiliging-vaststellen.md index c4ecc82..3457fd8 100644 --- a/Corpus/Standards/ISO27x/OST/27001/NL/c-4.3-Het-toepassingsgebied-van-het-managementsysteem-voor-informatiebeveiliging-vaststellen.md +++ b/Corpus/Standards/ISO27x/OST/27001/NL/c-4.3-Het-toepassingsgebied-van-het-managementsysteem-voor-informatiebeveiliging-vaststellen.md @@ -1,4 +1,17 @@ -# 4.3 Het toepassingsgebied van het managementsysteem voor informatiebeveiliging vaststellen +--- +notetype: reference +standard: ISO 27001 +version: 2023 +language: NL +type: clause +id: "C.4.3" +title: "Het toepassingsgebied van het managementsysteem voor informatiebeveiliging vaststellen" +tags: +- iso27001/2023/NL +- sourcetext +status: active +--- +## 4.3 Het toepassingsgebied van het managementsysteem voor informatiebeveiliging vaststellen De organisatie moet de grenzen en toepasselijkheid van het managementsysteem voor informatiebeveiliging bepalen om het toepassingsgebied ervan vast te stellen. diff --git a/Corpus/Standards/ISO27x/OST/27001/NL/c-4.4-Managementsysteem-voor-informatiebeveiliging.md b/Corpus/Standards/ISO27x/OST/27001/NL/c-4.4-Managementsysteem-voor-informatiebeveiliging.md index b896733..a68d7c1 100644 --- a/Corpus/Standards/ISO27x/OST/27001/NL/c-4.4-Managementsysteem-voor-informatiebeveiliging.md +++ b/Corpus/Standards/ISO27x/OST/27001/NL/c-4.4-Managementsysteem-voor-informatiebeveiliging.md @@ -1,3 +1,16 @@ -# 4.4 Managementsysteem voor informatiebeveiliging +--- +notetype: reference +standard: ISO 27001 +version: 2023 +language: NL +type: clause +id: "C.4.4" +title: "Managementsysteem voor informatiebeveiliging" +tags: +- iso27001/2023/NL +- sourcetext +status: active +--- +## 4.4 Managementsysteem voor informatiebeveiliging De organisatie moet een managementsysteem voor informatiebeveiliging inrichten, implementeren, onderhouden en continu verbeteren, met inbegrip van de benodigde processen en hun interacties, in overeenstemming met de eisen van dit document. diff --git a/Corpus/Standards/ISO27x/OST/27001/NL/c-5-Leiderschap.md b/Corpus/Standards/ISO27x/OST/27001/NL/c-5-Leiderschap.md index fc2ade1..c432dce 100644 --- a/Corpus/Standards/ISO27x/OST/27001/NL/c-5-Leiderschap.md +++ b/Corpus/Standards/ISO27x/OST/27001/NL/c-5-Leiderschap.md @@ -1 +1,17 @@ +--- +notetype: reference +standard: ISO 27001 +version: 2023 +language: NL +type: clause +id: "C.5" +title: "Leiderschap" +tags: +- iso27001/2023/NL +- sourcetext +status: active +--- # 5 Leiderschap +[c-5.1-Leiderschap-en-betrokkenheid](c-5.1-Leiderschap-en-betrokkenheid.md) +[c-5.2-Beleid](c-5.2-Beleid.md) +[c-5.3-Rollen-verantwoordelijkheden-en-bevoegdheden-binnen-de-organisatie](c-5.3-Rollen-verantwoordelijkheden-en-bevoegdheden-binnen-de-organisatie.md) diff --git a/Corpus/Standards/ISO27x/OST/27001/NL/c-5.1-Leiderschap-en-betrokkenheid.md b/Corpus/Standards/ISO27x/OST/27001/NL/c-5.1-Leiderschap-en-betrokkenheid.md index 73eae0b..b42ee8b 100644 --- a/Corpus/Standards/ISO27x/OST/27001/NL/c-5.1-Leiderschap-en-betrokkenheid.md +++ b/Corpus/Standards/ISO27x/OST/27001/NL/c-5.1-Leiderschap-en-betrokkenheid.md @@ -1,4 +1,17 @@ -# 5.1 Leiderschap en betrokkenheid +--- +notetype: reference +standard: ISO 27001 +version: 2023 +language: NL +type: clause +id: "C.5.1" +title: "Leiderschap en betrokkenheid" +tags: +- iso27001/2023/NL +- sourcetext +status: active +--- +## 5.1 Leiderschap en betrokkenheid Het topmanagement moet leiderschap en betrokkenheid tonen met betrekking tot het managementsysteem voor informatiebeveiliging door: diff --git a/Corpus/Standards/ISO27x/OST/27001/NL/c-5.2-Beleid.md b/Corpus/Standards/ISO27x/OST/27001/NL/c-5.2-Beleid.md index d64d983..18bc994 100644 --- a/Corpus/Standards/ISO27x/OST/27001/NL/c-5.2-Beleid.md +++ b/Corpus/Standards/ISO27x/OST/27001/NL/c-5.2-Beleid.md @@ -1,4 +1,17 @@ -# 5.2 Beleid +--- +notetype: reference +standard: ISO 27001 +version: 2023 +language: NL +type: clause +id: "C.5.2" +title: "Beleid" +tags: +- iso27001/2023/NL +- sourcetext +status: active +--- +## 5.2 Beleid Het topmanagement moet een informatiebeveiligingsbeleid vaststellen dat: diff --git a/Corpus/Standards/ISO27x/OST/27001/NL/c-5.3-Rollen-verantwoordelijkheden-en-bevoegdheden-binnen-de-organisatie.md b/Corpus/Standards/ISO27x/OST/27001/NL/c-5.3-Rollen-verantwoordelijkheden-en-bevoegdheden-binnen-de-organisatie.md index 5a37d11..97f8242 100644 --- a/Corpus/Standards/ISO27x/OST/27001/NL/c-5.3-Rollen-verantwoordelijkheden-en-bevoegdheden-binnen-de-organisatie.md +++ b/Corpus/Standards/ISO27x/OST/27001/NL/c-5.3-Rollen-verantwoordelijkheden-en-bevoegdheden-binnen-de-organisatie.md @@ -1,4 +1,17 @@ -# 5.3 Rollen, verantwoordelijkheden en bevoegdheden binnen de organisatie +--- +notetype: reference +standard: ISO 27001 +version: 2023 +language: NL +type: clause +id: "C.5.3" +title: "Rollen verantwoordelijkheden en bevoegdheden binnen de organisatie" +tags: +- iso27001/2023/NL +- sourcetext +status: active +--- +## 5.3 Rollen, verantwoordelijkheden en bevoegdheden binnen de organisatie Het topmanagement moet bewerkstelligen dat de verantwoordelijkheden en bevoegdheden voor rollen die relevant zijn voor informatiebeveiliging worden toegekend en gecommuniceerd binnen de organisatie. diff --git a/Corpus/Standards/ISO27x/OST/27001/NL/c-6-Planning.md b/Corpus/Standards/ISO27x/OST/27001/NL/c-6-Planning.md index 0fafa83..04988c2 100644 --- a/Corpus/Standards/ISO27x/OST/27001/NL/c-6-Planning.md +++ b/Corpus/Standards/ISO27x/OST/27001/NL/c-6-Planning.md @@ -1 +1,17 @@ +--- +notetype: reference +standard: ISO 27001 +version: 2023 +language: NL +type: clause +id: "C.6" +title: "Planning" +tags: +- iso27001/2023/NL +- sourcetext +status: active +--- # 6 Planning +[c-6.1-Acties-om-risicos-en-kansen-op-te-pakken](c-6.1-Acties-om-risicos-en-kansen-op-te-pakken.md) +[c-6.2-Informatiebeveiligingsdoelstellingen-en-de-planning-om-ze-te-bereiken](c-6.2-Informatiebeveiligingsdoelstellingen-en-de-planning-om-ze-te-bereiken.md) +[c-6.3-Planning-van-wijzigingen](c-6.3-Planning-van-wijzigingen.md) diff --git a/Corpus/Standards/ISO27x/OST/27001/NL/c-6.1-Acties-om-risicos-en-kansen-op-te-pakken.md b/Corpus/Standards/ISO27x/OST/27001/NL/c-6.1-Acties-om-risicos-en-kansen-op-te-pakken.md index e9715a0..c44b738 100644 --- a/Corpus/Standards/ISO27x/OST/27001/NL/c-6.1-Acties-om-risicos-en-kansen-op-te-pakken.md +++ b/Corpus/Standards/ISO27x/OST/27001/NL/c-6.1-Acties-om-risicos-en-kansen-op-te-pakken.md @@ -1,4 +1,17 @@ -# 6.1 Acties om risico's en kansen op te pakken +--- +notetype: reference +standard: ISO 27001 +version: 2023 +language: NL +type: clause +id: "C.6.1" +title: "Acties om risicos en kansen op te pakken" +tags: +- iso27001/2023/NL +- sourcetext +status: active +--- +## 6.1 Acties om risico's en kansen op te pakken 1. **Algemeen** @@ -16,41 +29,41 @@ d) acties plannen om deze risico's en kansen op te pakken; en e) plannen op welke manier: - 1. de acties in de processen van haar managementsysteem voor informatiebeveiliging worden geïntegreerd en geïmplementeerd; en +## 1. de acties in de processen van haar managementsysteem voor informatiebeveiliging worden geïntegreerd en geïmplementeerd; en - 2. de doeltreffendheid van deze acties wordt geëvalueerd. +## 2. de doeltreffendheid van deze acties wordt geëvalueerd. - 1. **Risicobeoordeling van informatiebeveiliging** +## 1. **Risicobeoordeling van informatiebeveiliging** De organisatie moet een risicobeoordelingsprocedure voor informatiebeveiliging definiëren en toepassen die: a) risicocriteria voor informatiebeveiliging vaststelt en onderhoudt, waaronder: - 1. de risicoacceptatiecriteria; en +## 1. de risicoacceptatiecriteria; en - 2. criteria voor het uitvoeren van risicobeoordelingen van informatiebeveiliging; +## 2. criteria voor het uitvoeren van risicobeoordelingen van informatiebeveiliging; b) waarborgt dat herhaalde risicobeoordelingen van informatiebeveiliging consistente, valide en vergelijkbare resultaten opleveren; c) de informatiebeveiligingsrisico's identificeert: - 1. pas de risicobeoordelingsprocedure voor informatiebeveiliging toe om de risico's in verband met het verlies van vertrouwelijkheid, integriteit en beschikbaarheid van informatie binnen het toepassingsgebied van het managementsysteem voor informatiebeveiliging te identificeren; en +## 1. pas de risicobeoordelingsprocedure voor informatiebeveiliging toe om de risico's in verband met het verlies van vertrouwelijkheid, integriteit en beschikbaarheid van informatie binnen het toepassingsgebied van het managementsysteem voor informatiebeveiliging te identificeren; en - 2. identificeer de risico-eigenaren; +## 2. identificeer de risico-eigenaren; d) de informatiebeveiligingsrisico's analyseert: - 1. beoordeel de potentiële gevolgen indien de risico's die in 6.1.2 c) 1) zijn vastgesteld, zich zouden voordoen; +## 1. beoordeel de potentiële gevolgen indien de risico's die in 6.1.2 c) 1) zijn vastgesteld, zich zouden voordoen; - 2. beoordeel de realistische waarschijnlijkheid dat de risico's die zijn vastgesteld in 6.1.2 c) 1) zich voordoen; en +## 2. beoordeel de realistische waarschijnlijkheid dat de risico's die zijn vastgesteld in 6.1.2 c) 1) zich voordoen; en - 3. stel de risiconiveaus vast; +## 3. stel de risiconiveaus vast; e) de informatiebeveiligingsrisico's evalueert: - 1. vergelijk de resultaten van de risicoanalyse met de risicocriteria die zijn vastgesteld in 6.1.2 a); en +## 1. vergelijk de resultaten van de risicoanalyse met de risicocriteria die zijn vastgesteld in 6.1.2 a); en - 2. prioriteer de geanalyseerde risico's voor risicobehandeling. +## 2. prioriteer de geanalyseerde risico's voor risicobehandeling. De organisatie moet gedocumenteerde informatie bewaren over de risicobeoordelingsprocedure voor informatiebeveiliging. @@ -72,13 +85,13 @@ OPMERKING 3 De lijst van beheersmaatregelen voor informatiebeveiliging in bijlag d) een verklaring van toepasselijkheid op te stellen die het volgende bevat: - - de noodzakelijke beheersmaatregelen (zie 6.1.3 b) en c)); +## - de noodzakelijke beheersmaatregelen (zie 6.1.3 b) en c)); - - een rechtvaardiging voor het opnemen ervan; +## - een rechtvaardiging voor het opnemen ervan; - - de informatie of de benodigde beheersmaatregelen zijn geïmplementeerd of niet; en +## - de informatie of de benodigde beheersmaatregelen zijn geïmplementeerd of niet; en - - de rechtvaardiging voor het uitsluiten van beheersmaatregelen uit bijlage A. +## - de rechtvaardiging voor het uitsluiten van beheersmaatregelen uit bijlage A. e) een plan voor de behandeling van informatiebeveiligingsrisico's te formuleren; en diff --git a/Corpus/Standards/ISO27x/OST/27001/NL/c-6.2-Informatiebeveiligingsdoelstellingen-en-de-planning-om-ze-te-bereiken.md b/Corpus/Standards/ISO27x/OST/27001/NL/c-6.2-Informatiebeveiligingsdoelstellingen-en-de-planning-om-ze-te-bereiken.md index dec1304..da1284c 100644 --- a/Corpus/Standards/ISO27x/OST/27001/NL/c-6.2-Informatiebeveiligingsdoelstellingen-en-de-planning-om-ze-te-bereiken.md +++ b/Corpus/Standards/ISO27x/OST/27001/NL/c-6.2-Informatiebeveiligingsdoelstellingen-en-de-planning-om-ze-te-bereiken.md @@ -1,4 +1,17 @@ -# 6.2 Informatiebeveiligingsdoelstellingen en de planning om ze te bereiken +--- +notetype: reference +standard: ISO 27001 +version: 2023 +language: NL +type: clause +id: "C.6.2" +title: "Informatiebeveiligingsdoelstellingen en de planning om ze te bereiken" +tags: +- iso27001/2023/NL +- sourcetext +status: active +--- +## 6.2 Informatiebeveiligingsdoelstellingen en de planning om ze te bereiken De organisatie moet voor relevante functies en op relevante niveaus informatiebeveiligingsdoel- stellingen vaststellen. diff --git a/Corpus/Standards/ISO27x/OST/27001/NL/c-6.3-Planning-van-wijzigingen.md b/Corpus/Standards/ISO27x/OST/27001/NL/c-6.3-Planning-van-wijzigingen.md index e3ca24e..440ee4f 100644 --- a/Corpus/Standards/ISO27x/OST/27001/NL/c-6.3-Planning-van-wijzigingen.md +++ b/Corpus/Standards/ISO27x/OST/27001/NL/c-6.3-Planning-van-wijzigingen.md @@ -1,5 +1,18 @@ -# 6.3 Planning van wijzigingen +--- +notetype: reference +standard: ISO 27001 +version: 2023 +language: NL +type: clause +id: "C.6.3" +title: "Planning van wijzigingen" +tags: +- iso27001/2023/NL +- sourcetext +status: active +--- +## 6.3 Planning van wijzigingen Wanneer de organisatie besluit dat er een noodzaak is voor wijzigingen in het managementsysteem voor informatiebeveiliging, moeten de wijzigingen worden uitgevoerd volgens een geplande werkwijze. -[]{#_bookmark20 .anchor}\* Nederlandse voetnoot: De tekst is niet overgenomen in deze vertaling, omdat de strekking ervan identiek is aan die van het nieuwe opsommingsdeel g). +Nederlandse voetnoot: De tekst is niet overgenomen in deze vertaling, omdat de strekking ervan identiek is aan die van het nieuwe opsommingsdeel g). diff --git a/Corpus/Standards/ISO27x/OST/27001/NL/c-7-Ondersteuning.md b/Corpus/Standards/ISO27x/OST/27001/NL/c-7-Ondersteuning.md index 1df9e15..b7ea35e 100644 --- a/Corpus/Standards/ISO27x/OST/27001/NL/c-7-Ondersteuning.md +++ b/Corpus/Standards/ISO27x/OST/27001/NL/c-7-Ondersteuning.md @@ -1 +1,19 @@ +--- +notetype: reference +standard: ISO 27001 +version: 2023 +language: NL +type: clause +id: "C.7" +title: "Ondersteuning" +tags: +- iso27001/2023/NL +- sourcetext +status: active +--- # 7 Ondersteuning +[c-7.1-Middelen](c-7.1-Middelen.md) +[c-7.2-Competentie](c-7.2-Competentie.md) +[c-7.3-Bewustzijn](c-7.3-Bewustzijn.md) +[c-7.4-Communicatie](c-7.4-Communicatie.md) +[c-7.5-Gedocumenteerde-informatie](c-7.5-Gedocumenteerde-informatie.md) diff --git a/Corpus/Standards/ISO27x/OST/27001/NL/c-7.1-Middelen.md b/Corpus/Standards/ISO27x/OST/27001/NL/c-7.1-Middelen.md index 7e7f7f2..1505302 100644 --- a/Corpus/Standards/ISO27x/OST/27001/NL/c-7.1-Middelen.md +++ b/Corpus/Standards/ISO27x/OST/27001/NL/c-7.1-Middelen.md @@ -1,3 +1,16 @@ -# 7.1 Middelen +--- +notetype: reference +standard: ISO 27001 +version: 2023 +language: NL +type: clause +id: "C.7.1" +title: "Middelen" +tags: +- iso27001/2023/NL +- sourcetext +status: active +--- +## 7.1 Middelen De organisatie moet de middelen vaststellen en beschikbaar stellen die nodig zijn voor het inrichten, implementeren, onderhouden en continu verbeteren van het managementsysteem voor informatiebeveiliging. diff --git a/Corpus/Standards/ISO27x/OST/27001/NL/c-7.2-Competentie.md b/Corpus/Standards/ISO27x/OST/27001/NL/c-7.2-Competentie.md index 67d9e5e..e0d00ad 100644 --- a/Corpus/Standards/ISO27x/OST/27001/NL/c-7.2-Competentie.md +++ b/Corpus/Standards/ISO27x/OST/27001/NL/c-7.2-Competentie.md @@ -1,4 +1,17 @@ -# 7.2 Competentie +--- +notetype: reference +standard: ISO 27001 +version: 2023 +language: NL +type: clause +id: "C.7.2" +title: "Competentie" +tags: +- iso27001/2023/NL +- sourcetext +status: active +--- +## 7.2 Competentie De organisatie moet: diff --git a/Corpus/Standards/ISO27x/OST/27001/NL/c-7.3-Bewustzijn.md b/Corpus/Standards/ISO27x/OST/27001/NL/c-7.3-Bewustzijn.md index c617a36..3fec18a 100644 --- a/Corpus/Standards/ISO27x/OST/27001/NL/c-7.3-Bewustzijn.md +++ b/Corpus/Standards/ISO27x/OST/27001/NL/c-7.3-Bewustzijn.md @@ -1,4 +1,17 @@ -# 7.3 Bewustzijn +--- +notetype: reference +standard: ISO 27001 +version: 2023 +language: NL +type: clause +id: "C.7.3" +title: "Bewustzijn" +tags: +- iso27001/2023/NL +- sourcetext +status: active +--- +## 7.3 Bewustzijn Personen die werkzaamheden verrichten onder het gezag van de organisatie, moeten zich bewust zijn van: diff --git a/Corpus/Standards/ISO27x/OST/27001/NL/c-7.4-Communicatie.md b/Corpus/Standards/ISO27x/OST/27001/NL/c-7.4-Communicatie.md index 0c09940..8c1c25f 100644 --- a/Corpus/Standards/ISO27x/OST/27001/NL/c-7.4-Communicatie.md +++ b/Corpus/Standards/ISO27x/OST/27001/NL/c-7.4-Communicatie.md @@ -1,4 +1,17 @@ -# 7.4 Communicatie +--- +notetype: reference +standard: ISO 27001 +version: 2023 +language: NL +type: clause +id: "C.7.4" +title: "Communicatie" +tags: +- iso27001/2023/NL +- sourcetext +status: active +--- +## 7.4 Communicatie De organisatie moet vaststellen welke interne en externe communicatie relevant is voor het managementsysteem voor informatiebeveiliging, inclusief: diff --git a/Corpus/Standards/ISO27x/OST/27001/NL/c-7.5-Gedocumenteerde-informatie.md b/Corpus/Standards/ISO27x/OST/27001/NL/c-7.5-Gedocumenteerde-informatie.md index 0b3e31d..5a15b1a 100644 --- a/Corpus/Standards/ISO27x/OST/27001/NL/c-7.5-Gedocumenteerde-informatie.md +++ b/Corpus/Standards/ISO27x/OST/27001/NL/c-7.5-Gedocumenteerde-informatie.md @@ -1,4 +1,17 @@ -# 7.5 Gedocumenteerde informatie +--- +notetype: reference +standard: ISO 27001 +version: 2023 +language: NL +type: clause +id: "C.7.5" +title: "Gedocumenteerde informatie" +tags: +- iso27001/2023/NL +- sourcetext +status: active +--- +## 7.5 Gedocumenteerde informatie 1. **Algemeen** @@ -16,7 +29,7 @@ OPMERKING De uitgebreidheid van gedocumenteerde informatie voor een managementsy 3) de competentie van de mensen. - 1. **Creëren en actualiseren** +## 1. **Creëren en actualiseren** Bij het creëren en actualiseren van gedocumenteerde informatie moet de organisatie zorgen voor (een) passend(e): @@ -26,7 +39,7 @@ b) format (bijv. taal, softwareversie, afbeeldingen) en media (bijv. papier, el c) beoordeling en goedkeuring van geschiktheid en toereikendheid. - 1. **Beheersing van gedocumenteerde informatie** +## 1. **Beheersing van gedocumenteerde informatie** Gedocumenteerde informatie zoals het managementsysteem voor informatiebeveiliging en dit document vereisen, moet worden beheerst om te bewerkstelligen dat: diff --git a/Corpus/Standards/ISO27x/OST/27001/NL/c-8-Uitvoering.md b/Corpus/Standards/ISO27x/OST/27001/NL/c-8-Uitvoering.md index 080da36..00000ae 100644 --- a/Corpus/Standards/ISO27x/OST/27001/NL/c-8-Uitvoering.md +++ b/Corpus/Standards/ISO27x/OST/27001/NL/c-8-Uitvoering.md @@ -1 +1,18 @@ +--- +notetype: reference +standard: ISO 27001 +version: 2023 +language: NL +type: clause +id: "C.8" +title: "Uitvoering" +tags: +- iso27001/2023/NL +- sourcetext +status: active +--- # 8 Uitvoering + +[c-8.1-Operationele-planning-en-beheersing](c-8.1-Operationele-planning-en-beheersing.md) +[c-8.2-Risicobeoordeling-van-informatiebeveiliging](c-8.2-Risicobeoordeling-van-informatiebeveiliging.md) +[c-8.3-Informatiebeveiligingsrisicos-behandelen](c-8.3-Informatiebeveiligingsrisicos-behandelen.md) diff --git a/Corpus/Standards/ISO27x/OST/27001/NL/c-8.1-Operationele-planning-en-beheersing.md b/Corpus/Standards/ISO27x/OST/27001/NL/c-8.1-Operationele-planning-en-beheersing.md index 33b1381..92f4f32 100644 --- a/Corpus/Standards/ISO27x/OST/27001/NL/c-8.1-Operationele-planning-en-beheersing.md +++ b/Corpus/Standards/ISO27x/OST/27001/NL/c-8.1-Operationele-planning-en-beheersing.md @@ -1,4 +1,17 @@ -# 8.1 Operationele planning en beheersing +--- +notetype: reference +standard: ISO 27001 +version: 2023 +language: NL +type: clause +id: "C.8.1" +title: "Operationele planning en beheersing" +tags: +- iso27001/2023/NL +- sourcetext +status: active +--- +## 8.1 Operationele planning en beheersing Om te voldoen aan de eisen en om de in hoofdstuk 6 vastgestelde acties te implementeren moet de organisatie de benodigde processen plannen, implementeren en beheersen, door: diff --git a/Corpus/Standards/ISO27x/OST/27001/NL/c-8.2-Risicobeoordeling-van-informatiebeveiliging.md b/Corpus/Standards/ISO27x/OST/27001/NL/c-8.2-Risicobeoordeling-van-informatiebeveiliging.md index c2950b7..efcd07c 100644 --- a/Corpus/Standards/ISO27x/OST/27001/NL/c-8.2-Risicobeoordeling-van-informatiebeveiliging.md +++ b/Corpus/Standards/ISO27x/OST/27001/NL/c-8.2-Risicobeoordeling-van-informatiebeveiliging.md @@ -1,4 +1,17 @@ -# 8.2 Risicobeoordeling van informatiebeveiliging +--- +notetype: reference +standard: ISO 27001 +version: 2023 +language: NL +type: clause +id: "C.8.2" +title: "Risicobeoordeling van informatiebeveiliging" +tags: +- iso27001/2023/NL +- sourcetext +status: active +--- +## 8.2 Risicobeoordeling van informatiebeveiliging De organisatie moet, met geplande tussenpozen of zodra belangrijke veranderingen worden voorgesteld of zich voordoen, risicobeoordelingen voor informatiebeveiliging uitvoeren, rekening houdend met de in 6.1.2 a) vastgestelde criteria. diff --git a/Corpus/Standards/ISO27x/OST/27001/NL/c-8.3-Informatiebeveiligingsrisicos-behandelen.md b/Corpus/Standards/ISO27x/OST/27001/NL/c-8.3-Informatiebeveiligingsrisicos-behandelen.md index 9284a05..18fafbe 100644 --- a/Corpus/Standards/ISO27x/OST/27001/NL/c-8.3-Informatiebeveiligingsrisicos-behandelen.md +++ b/Corpus/Standards/ISO27x/OST/27001/NL/c-8.3-Informatiebeveiligingsrisicos-behandelen.md @@ -1,4 +1,17 @@ -# 8.3 Informatiebeveiligingsrisico's behandelen +--- +notetype: reference +standard: ISO 27001 +version: 2023 +language: NL +type: clause +id: "C.8.3" +title: "Informatiebeveiligingsrisicos behandelen" +tags: +- iso27001/2023/NL +- sourcetext +status: active +--- +## 8.3 Informatiebeveiligingsrisico's behandelen De organisatie moet het risicobehandelingsplan voor informatiebeveiliging implementeren. diff --git a/Corpus/Standards/ISO27x/OST/27001/NL/c-9-Evaluatie-van-de-prestaties.md b/Corpus/Standards/ISO27x/OST/27001/NL/c-9-Evaluatie-van-de-prestaties.md index 33846b8..17911e3 100644 --- a/Corpus/Standards/ISO27x/OST/27001/NL/c-9-Evaluatie-van-de-prestaties.md +++ b/Corpus/Standards/ISO27x/OST/27001/NL/c-9-Evaluatie-van-de-prestaties.md @@ -1 +1,17 @@ +--- +notetype: reference +standard: ISO 27001 +version: 2023 +language: NL +type: clause +id: "C.9" +title: "Evaluatie van de prestaties" +tags: +- iso27001/2023/NL +- sourcetext +status: active +--- # 9 Evaluatie van de prestaties +[c-9.1-Monitoren-meten-analyseren-en-evalueren](c-9.1-Monitoren-meten-analyseren-en-evalueren.md) +[c-9.2-Interne-audit](c-9.2-Interne-audit.md) +[c-9.3-Management-review](c-9.3-Management-review.md) diff --git a/Corpus/Standards/ISO27x/OST/27001/NL/c-9.1-Monitoren-meten-analyseren-en-evalueren.md b/Corpus/Standards/ISO27x/OST/27001/NL/c-9.1-Monitoren-meten-analyseren-en-evalueren.md index 8b3273f..3408deb 100644 --- a/Corpus/Standards/ISO27x/OST/27001/NL/c-9.1-Monitoren-meten-analyseren-en-evalueren.md +++ b/Corpus/Standards/ISO27x/OST/27001/NL/c-9.1-Monitoren-meten-analyseren-en-evalueren.md @@ -1,4 +1,17 @@ -# 9.1 Monitoren, meten, analyseren en evalueren +--- +notetype: reference +standard: ISO 27001 +version: 2023 +language: NL +type: clause +id: "C.9.1" +title: "Monitoren meten analyseren en evalueren" +tags: +- iso27001/2023/NL +- sourcetext +status: active +--- +## 9.1 Monitoren, meten, analyseren en evalueren De organisatie moet vaststellen: diff --git a/Corpus/Standards/ISO27x/OST/27001/NL/c-9.2-Interne-audit.md b/Corpus/Standards/ISO27x/OST/27001/NL/c-9.2-Interne-audit.md index 0b0e259..83b01ef 100644 --- a/Corpus/Standards/ISO27x/OST/27001/NL/c-9.2-Interne-audit.md +++ b/Corpus/Standards/ISO27x/OST/27001/NL/c-9.2-Interne-audit.md @@ -1,4 +1,17 @@ -# 9.2 Interne audit +--- +notetype: reference +standard: ISO 27001 +version: 2023 +language: NL +type: clause +id: "C.9.2" +title: "Interne audit" +tags: +- iso27001/2023/NL +- sourcetext +status: active +--- +## 9.2 Interne audit 1. **Algemeen** @@ -6,13 +19,13 @@ De organisatie moet met geplande tussenpozen interne audits uitvoeren om informa a) voldoet aan - 1. de eigen eisen van de organisatie voor haar managementsysteem voor informatiebeveiliging; +## 1. de eigen eisen van de organisatie voor haar managementsysteem voor informatiebeveiliging; - 2. de eisen van dit document; +## 2. de eisen van dit document; b) doeltreffend is geïmplementeerd en onderhouden. - 1. **Intern auditprogramma** +## 1. **Intern auditprogramma** De organisatie moet (een) auditprogramma('s) plannen, vaststellen, implementeren en onderhouden, met inbegrip van de frequentie, methoden, verantwoordelijkheden, planningseisen en rapportage. diff --git a/Corpus/Standards/ISO27x/OST/27001/NL/c-9.3-Management-review.md b/Corpus/Standards/ISO27x/OST/27001/NL/c-9.3-Management-review.md index ccc3788..f194239 100644 --- a/Corpus/Standards/ISO27x/OST/27001/NL/c-9.3-Management-review.md +++ b/Corpus/Standards/ISO27x/OST/27001/NL/c-9.3-Management-review.md @@ -1,4 +1,17 @@ -# 9.3 Management review +--- +notetype: reference +standard: ISO 27001 +version: 2023 +language: NL +type: clause +id: "C.9.3" +title: "Management review" +tags: +- iso27001/2023/NL +- sourcetext +status: active +--- +## 9.3 Management review 1. **Algemeen** @@ -16,13 +29,13 @@ c) wijzigingen in de behoeften en verwachtingen van de belanghebbenden die rele d) feedback over de prestaties van de informatiebeveiliging, met inbegrip van trends in: - 1. afwijkingen en corrigerende maatregelen; +## 1. afwijkingen en corrigerende maatregelen; - 2. resultaten van monitoren en meten; +## 2. resultaten van monitoren en meten; - 3. auditresultaten; +## 3. auditresultaten; - 4. het voldoen aan informatiebeveiligingsdoelstellingen; +## 4. het voldoen aan informatiebeveiligingsdoelstellingen; e) feedback van belanghebbenden; @@ -30,7 +43,7 @@ f) resultaten van risicobeoordeling en de status van het risicobehandelingsplan g) kansen voor continue verbetering. - 1. **Resultaten van de management review** +## 1. **Resultaten van de management review** De resultaten van de management reviews moeten beslissingen omvatten met betrekking tot kansen voor continue verbetering en de noodzaak voor wijzigingen in het managementsysteem voor informatiebeveiliging. diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/A-4-Structure-of-this-document.md b/Corpus/Standards/ISO27x/OST/27002/EN/A-4-Structure-of-this-document.md new file mode 100644 index 0000000..1cc20e2 --- /dev/null +++ b/Corpus/Standards/ISO27x/OST/27002/EN/A-4-Structure-of-this-document.md @@ -0,0 +1,101 @@ +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +id: "A.4" +title: "Structure of this document" +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- +# 4 Structure of this document + +## 4.1 Clauses + +This document is structured as follows: + +a\) Organizational controls (Clause 5) + +b\) People controls (Clause 6) + +c\) Physical controls (Clause 7) + +d\) Technological controls (Clause 8) + +There are 2 informative annexes: + +— Annex A— Using attributes +— Annex B— Correspondence with ISO/IEC 27002:2013 + +Annex A explains how an organization can use attributes (see 4.2) to create its own views based on the control attributes defined in this document or of its own creation. + +Annex B shows the correspondence between the controls in this edition of ISO/IEC 27002 and the previous 2013 edition. + +## 4.2 Themes and attributes + +The categorization of controls given in Clauses 5to 8are referred to as themes. + +Controls are categorized as: + +a\) people, if they concern individual people; + +b\) physical, if they concern physical objects; + +c\) technological, if they concern technology; + +d\) otherwise they are categorized as organizational. + +The organization can use attributes to create different views which are different categorizations of controls as seen from a different perspective to the themes. Attributes can be used to filter, sort or present controls in different views for different audiences. Annex Aexplains how this can be achieved and provides an example of a view. + +By way of example, each control in this document has been associated with five attributes with corresponding attribute values (preceded by "#" to make them searchable), as follows: + +a\) Control type + +Control type is an attribute to view controls from the perspective of when and how the control modifies the risk with regard to the occurrence of an information security incident. Attribute values consist of Preventive (the control that is intended to prevent the occurrence of an information security incident), Detective (the control acts when an information security incident occurs) and Corrective (the control acts after an information security incident occurs). + +b\) Information security properties + +Information security properties is an attribute to view controls from the perspective of which characteristic of information the control will contribute to preserving. Attribute values consist of Confidentiality, Integrity and Availability. + +c\) Cybersecurity concepts + +Cybersecurity concepts is an attribute to view controls from the perspective of the association of controls to cybersecurity concepts defined in the cybersecurity framework described in ISO/IEC TS 27110. Attribute values consist of Identify, Protect, Detect, Respond and Recover. + +d\) Operational capabilities + +Operational capabilities is an attribute to view controls from the practitioner’s perspective of information security capabilities. Attribute values consist of Governance, Asset_management, Information_protection, Human_resource_security, Physical_security, System_and_network\_ security, Application_security, Secure_configuration, Identity_and_access_management, + +Threat_and_vulnerability_management, Continuity, Supplier_relationships_security, Legal_and\_ compliance, Information_security_event_management and Information_security_assurance. + + + + + +e\) Security domains + + +Security domains is an attribute to view controls from the perspective of four information security + +domains: “Governance and Ecosystem” includes “Information System Security Governance & + +Risk Management” and “Ecosystem cybersecurity management” (including internal and external stakeholders); “Protection” includes “IT Security Architecture”, “IT Security Administration”, “Identity and access management”, “IT Security Maintenance” and “Physical and environmental security”; “Defence” includes “Detection” and “Computer Security Incident Management”; “Resilience” includes “Continuity of operations” and “Crisis management”. Attribute values consist of Governance_and_Ecosystem, Protection, Defence and Resilience. + +The attributes given in this document are selected because they are considered generic enough to be used by different types of organizations. Organizations can choose to disregard one or more of the attributes given in this document. They can also create attributes of their own (with the corresponding attribute values) to create their own organizational views. Clause A.2includes examples of such attributes. + +## 4.3 Control layout + +The layout for each control contains the following: + +— **Control title:** Short name of the control; + +— **Attribute table**: A table shows the value(s) of each attribute for the given control; + +— **Control:** What the control is; + +— **Purpose**: Why the control should be implemented; — **Guidance:** How the control should be implemented; + +— **Other information:** Explanatory text or references to other related documents. + +Subheadings are used in the guidance text for some controls to aid readability where guidance is lengthy and addresses multiple topics. Such headings are not necessarily used in all guidance text. Subheadings are underlined. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/ISO 27002_2022_EN_complete.docx b/Corpus/Standards/ISO27x/OST/27002/EN/ISO 27002_2022_EN_complete.docx new file mode 100644 index 0000000..3faf329 Binary files /dev/null and b/Corpus/Standards/ISO27x/OST/27002/EN/ISO 27002_2022_EN_complete.docx differ diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/ISO_27002_OT 3 Terms, definitions and abbreviated terms.md b/Corpus/Standards/ISO27x/OST/27002/EN/ISO_27002_OT 3 Terms, definitions and abbreviated terms.md deleted file mode 100644 index 4ac17cb..0000000 --- a/Corpus/Standards/ISO27x/OST/27002/EN/ISO_27002_OT 3 Terms, definitions and abbreviated terms.md +++ /dev/null @@ -1,818 +0,0 @@ -#iso27002/2022/EN - - -**3.1** **Terms** **and** **definitions** - - - -For the purposes of this document, the following terms and definitions apply. - - - -ISO and IEC maintain terminology databases for use in standardization at the following addresses: — ISO Online browsing platform: available at https://www.iso.org/obp - -— IEC Electropedia: available at https://www.electropedia.org/ - - - -**3.****1.1** - -**access** **control** - -means to ensure that physical and logical access to _assets_ (3.1.2) is authorized and restricted based on business and information security requirements - - - -**3.****1.2** - -**ass****et** - -anything that has value to the organization - - - -Note 1 to entry: In the context of information security, two kinds of assets can be distinguished: - - - -— the primary assets: — information; - -— business _processes_ (3.1.27) and activities; - - - -— the supporting assets (on which the primary assets rely) of all types, for example: — hardware; - -— software; — network; - -— _personnel_ (3.1.20); - - - - - -© ISO/IEC 2022 – All rights reserved **1** - - - - - - - -**ISO/IEC 27002:2022(E)** - - - - - - - -— site; - -Licensed to ISO27DIY / Richard Kranendonk (rkranendonk@mac.com) - -ISO Store Order: OP-582678 / Downloaded: 2022-02-17 Single user licence only, copying and networking prohibited. - - - -— organization’s structure. - - - -**3.****1.3** - -**attack** - -successful or unsuccessful unauthorized attempt to destroy, alter, disable, gain access to an _asset_ (3.1.2) or any attempt to expose, steal, or make unauthorized use of an _asset_ (3.1.2) - - - -**3.1.4** - -**aut****hentication** - -provision of assurance that a claimed characteristic of an _entity_ (3.1.11) is correct - - - -**3****.1.5** - -**au****thenticity** - -property that an _entity_ (3.1.11) is what it claims to be - - - -**3.1.6** - -**chain** **of** **custody** - -demonstrable possession, movement, handling and location of material from one point in time until another - - - -Note 1 to entry: Material includes information and other associated _assets_ (3.1.2) in the context of ISO/IEC 27002. - - - -[SOURCE: ISO/IEC 27050-1:2019, 3.1, modified — “Note 1 to entry” added] - - - -**3.****1.7** - -**confidential** **information** - -information that is not intended to be made available or disclosed to unauthorized individuals, _entities_ (3.1.11) or _processes_ (3.1.27) - - - -**3****.1.8** - -**control** - -measure that maintains and/or modifies risk - - - -Note 1 to entry: Controls include, but are not limited to, any _process_ (3.1.27), _policy_ (3.1.24), device, practice or other conditions and/or actions which maintain and/or modify risk. - - - -Note 2 to entry: Controls may not always exert the intended or assumed modifying effect. - - - -[SOURCE: ISO 31000:2018, 3.8] - - - -**3.****1.9** - -**disrupti****on** - -incident, whether anticipated or unanticipated, that causes an unplanned, negative deviation from the expected delivery of products and services according to an organization’s objectives - - - -[SOURCE: ISO 22301:2019, 3.10] - - - -**3.1****.10** - -**endpoint** **device** - -network connected information and communication technology (ICT) hardware device - - - -Note 1 to entry: Endpoint device can refer to desktop computers, laptops, smart phones, tablets, thin clients, printers or other specialized hardware including smart meters and Internet of things (IoT) devices. - - - -**3.1.11** - -**entity** - -item relevant for the purpose of operation of a domain that has recognizably distinct existence - - - -Note 1 to entry: An entity can have a physical or a logical embodiment. - - - - - - - -**2** © ISO/IEC 2022 – All rights reserved - - - - - - - - - - - - - - - - - -EXAMPLE - -Licensed to ISO27DIY / Richard Kranendonk (rkranendonk@mac.com) - -ISO Store Order: OP-582678 / Downloaded: 2022-02-17 - -Single user licence only, copying and networking prohibited. - -**ISO/IEC 27002:2022(E)** - - - - - - - -A person, an organization, a device, a group of such items, a human subscriber to a telecom - -service, a SIM card, a passport, a network interface card, a software application, a service or a website. - - - -[SOURCE: ISO/IEC 24760-1:2019, 3.1.1] - - - -**3.****1.12** - -**information** **processing** **facility** - -any information processing system, service or infrastructure, or the physical location housing it [SOURCE: ISO/IEC 27000:2018, 3.27, modified — "facilities" has been replaced with facility.] **3****.1.13** - -**information** **security** **breach** - -compromise of information security that leads to the undesired destruction, loss, alteration, disclosure of, or access to, protected information transmitted, stored or otherwise processed - - - -**3.1****.14** - -**information** **security** **event** - -occurrence indicating a possible _information_ _security_ _breach_ (3.1.13) or failure of _controls_ (3.1.8) - - - -[SOURCE: ISO/IEC 27035-1:2016, 3.3, modified — “breach of information security” has been replaced with “information security breach”] - - - -**3.1****.15** - -**information** **security incident** - -one or multiple related and identified _information_ _security_ _events_ (3.1.14) that can harm an organization’s _assets_ (3.1.2) or compromise its operations - - - -[SOURCE: ISO/IEC 27035-1:2016, 3.4] - - - -**3.1.16** - -**information** **security** **incident** **management** - -exercise of a consistent and effective approach to the handling of _information_ _security_ _incidents_ (3.1.15) [SOURCE: ISO/IEC 27035-1:2016, 3.5] - -**3****.1.17** - -**information** **system** - -set of applications, services, information technology _assets_ (3.1.2), or other information-handling components - - - -[SOURCE: ISO/IEC 27000:2018, 3.35] - - - -**3.1.18** - -**interested** **party** stakeholder - -person or organization that can affect, be affected by, or perceive itself to be affected by a decision or activity - - - -[SOURCE: ISO/IEC 27000:2018, 3.37] - - - -**3.****1.19** - -**non-repudiation** - -ability to prove the occurrence of a claimed event or action and its originating _entities_ (3.1.11) - - - -**3.1.20** - -**pers****onnel** - -persons doing work under the organization’s direction - - - -Note 1 to entry: The concept of personnel includes the organization’s members, such as the governing body, top management, employees, temporary staff, contractors and volunteers. - - - - - - - -© ISO/IEC 2022 – All rights reserved **3** - - - - - - - -**ISO/IEC 27002:2022(E)** - - - - - - - -**3.1****.21** - -Licensed to ISO27DIY / Richard Kranendonk (rkranendonk@mac.com) - -ISO Store Order: OP-582678 / Downloaded: 2022-02-17 Single user licence only, copying and networking prohibited. - -**personally identifiable** **information** - -**PII** - -any information that (a) can be used to establish a link between the information and the natural person to whom such information relates, or (b) is or can be directly or indirectly linked to a natural person. - - - -Note 1 to entry: The “natural person” in the definition is the _PII_ _principal_ (3.1.22). To determine whether a PII principal is identifiable, account should be taken of all the means which can reasonably be used by the privacy stakeholder holding the data, or by any other party, to establish the link between the set of PII and the natural person. - - - -[SOURCE: ISO/IEC 29100:2011/Amd.1:2018, 2.9] - - - -**3.1.22** - -**PII** **principal** - -natural person to whom the _personally identifiable_ _information_ _(PII)_ (3.1.21) relates - - - -Note 1 to entry: Depending on the jurisdiction and the particular data protection and privacy legislation, the synonym “data subject” can also be used instead of the term “PII principal”. - - - -[SOURCE: ISO/IEC 29100:2011, 2.11] - - - -**3.1.23** - -**PII** **processor** - -privacy stakeholder that processes _personally_ _identifiable_ _information_ _(PII)_ (3.1.21) on behalf of and in accordance with the instructions of a PII controller - - - -[SOURCE: ISO/IEC 29100:2011, 2.12] - - - -**3.1****.24** - -**policy** - -intentions and direction of an organization, as formally expressed by its top management [SOURCE: ISO/IEC 27000:2018, 3.53] - -**3.1.25** - -**privacy** **impact** **assessment** **PIA** - -overall _process_ (3.1.27) of identifying, analysing, evaluating, consulting, communicating and planning the treatment of potential privacy impacts with regard to the processing of _personally_ _identifiable_ _information_ _(PII)_ (3.1.21), framed within an organization’s broader risk management framework - - - -[SOURCE: ISO/IEC 29134:2017, 3.7, modified — Note 1 to entry removed.] - - - -**3.1.26** - -**procedure** - -specified way to carry out an activity or a _process_ (3.1.27) - - - -[SOURCE: ISO 30000:2009, 3.12] - - - -**3.1.27** - -**proce****ss** - -set of interrelated or interacting activities that uses or transforms inputs to deliver a result - - - -[SOURCE: ISO 9000:2015, 3.4.1, modified— Notes to entry removed.] - - - -**3.1****.28** - -**re****cord** - -information created, received and maintained as evidence and as an _asset_ (3.1.2) by an organization or person, in pursuit of legal obligations or in the transaction of business - - - - - - - - - -**4** © ISO/IEC 2022 – All rights reserved - -Licensed to ISO27DIY / Richard Kranendonk (rkranendonk@mac.com) - -ISO Store Order: OP-582678 / Downloaded: 2022-02-17 Single user licence only, copying and networking prohibited. - - - - - - - -**ISO/IEC 27002:2022(E)** - - - - - - - -Note 1 to entry: Legal obligations in this context include all legal, statutory, regulatory and contractual requirements. - - - -[SOURCE: ISO 15489-1:2016, 3.14, modified— “Note 1 to entry” added.] - - - -**3.1.29** - -**recovery** **point** **objective** - -**RPO** - -point in time to which data are to be recovered after a _disruption_ (3.1.9) has occurred [SOURCE: ISO/IEC 27031:2011, 3.12, modified — "must" replaced by "are to be".] **3.1.30** - -**recovery** **time** **objective** **RTO** - -period of time within which minimum levels of services and/or products and the supporting systems, applications, or functions are to be recovered after a _disruption_ (3.1.9) has occurred - - - -[SOURCE: ISO/IEC 27031:2011, 3.13, modified — "must" replaced by "are to be".] - - - -**3.1****.31** - -**reliability** - -property of consistent intended behaviour and results - - - -**3.1.32** - -**rule** - -accepted principle or instruction that states the organization’s expectations on what is required to be done, what is allowed or not allowed - - - -Note 1 to entry: Rules can be formally expressed in _topic-specific policies_ (3.1.35) and in other types of documents. - - - -**3.1.33** - -**sensitive** **information** - -information that needs to be protected from unavailability, unauthorized access, modification or public disclosure because of potential adverse effects on an individual, organization, national security or public safety - - - -**3****.1.34** - -**thr****eat** - -potential cause of an unwanted incident, which can result in harm to a system or organization [SOURCE: ISO/IEC 27000:2018, 3.74] - -**3.1.35** - -**topic-specific** **policy** - -intentions and direction on a specific subject or topic, as formally expressed by the appropriate level of management - - - -Note 1 to entry: Topic-specific policies can formally express _rules_ (3.1.32) or organization standards. Note 2 to entry: Some organizations use other terms for these topic-specific policies. - -Note 3 to entry: The topic-specific policies referred to in this document are related to information security. - - - -EXAMPLE Topic-specific policy on _access_ _control_ (3.1.1), topic-specific policy on clear desk and clear screen. - - - -**3.1.36** - -**u****ser** - -_interested_ _party_ (3.1.18) with access to the organization’s _information_ _systems_ (3.1.17) - - - -EXAMPLE _Personnel_ (3.1.20), customers, suppliers. - - - - - - - - - -© ISO/IEC 2022 – All rights reserved - - - - - - - - - - - -**5** - - - - - - - -**ISO/IEC 27002:2022(E)** - - - - - - - -**3.1.37** - -**user** **endpoint** **device** - -Licensed to ISO27DIY / Richard Kranendonk (rkranendonk@mac.com) - -ISO Store Order: OP-582678 / Downloaded: 2022-02-17 Single user licence only, copying and networking prohibited. - -_endpoint_ _device_ (3.1.10) used by users to access information processing services - - - -Note 1 to entry: User endpoint device can refer to desktop computers, laptops, smart phones, tablets, thin clients, etc. - - - -**3.1****.38** - -**vu****lnerability** - -weakness of an _asset_ (3.1.2) or _control_ (3.1.8) that can be exploited by one or more _threats_ (3.1.34) [SOURCE: ISO/IEC 27000:2018, 3.77] - - - -**3.2** **Abbreviated** **terms** - - - -ABAC attribute-based access control - - - -ACL access control list - - - -BIA business impact analysis - - - -BYOD bring your own device - - - -CAPTCHA completely automated public Turing test to tell computers and humans apart - - - -CPU central processing unit - - - -DAC discretionary access control - - - -DNS domain name system - - - -GPS global positioning system - - - -IAM identity and access management - - - -ICT information and communication technology - - - -ID identifier - - - -IDE integrated development environment - - - -IDS intrusion detection system - - - -IoT internet of things - - - -IP internet protocol - - - -IPS intrusion prevention system - - - -IT information technology - - - -ISMS information security management system - - - -MAC mandatory access control - - - -NTP network time protocol - - - -PIA privacy impact assessment - - - -PII personally identifiable information - - - - - - - -**6** © ISO/IEC 2022 – All rights reserved - -Licensed to ISO27DIY / Richard Kranendonk (rkranendonk@mac.com) - -ISO Store Order: OP-582678 / Downloaded: 2022-02-17 Single user licence only, copying and networking prohibited. - - - - - - - -**ISO/IEC 27002:2022(E)** - - - - - - - -PIN personal identification number - - - -PKI public key infrastructure - - - -PTP precision time protocol - - - -RBAC role-based access control - - - -RPO recovery point objective - - - -RTO recovery time objective - - - -SAST static application security testing - - - -SD secure digital - - - -SDN software-defined networking - - - -SD-WAN software-defined wide area networking - - - -SIEM security information and event management - - - -SMS short message service - - - -SQL structured query language - - - -SSO single sign on - - - -SWID software identification - - - -UEBA user and entity behaviour analytics - - - -UPS uninterruptible power supply - - - -URL uniform resource locator - - - -USB universal serial bus - - - -VM virtual machine - - - -VPN virtual private network - - - -WiFi wireless fidelity \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-3-Terms-definitions-and-abbreviated-terms.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-3-Terms-definitions-and-abbreviated-terms.md new file mode 100644 index 0000000..31ffb18 --- /dev/null +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-3-Terms-definitions-and-abbreviated-terms.md @@ -0,0 +1,201 @@ +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +id: "A.3" +title: "Terms, definitions, and abbreviated terms" +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- +# 3 Terms, definitions, and abbreviated terms + +## 3.1 Terms and definitions +For the purposes of this document, the following terms and definitions apply. +ISO and IEC maintain terminology databases for use in standardization at the following addresses: — ISO Online browsing platform: available at https://www.iso.org/obp +— IEC Electropedia: available at https://www.electropedia.org/ + +3.1.1 **access control** +means to ensure that physical and logical access to _assets_ (3.1.2) is authorized and restricted based on business and information security requirements + +3.1.2 **asset** +anything that has value to the organization +*Note 1 to entry: In the context of information security, two kinds of assets can be distinguished:* +— the primary assets: — information; +— business _processes_ (3.1.27) and activities; +— the supporting assets (on which the primary assets rely) of all types, for example: — hardware; +— software; — network; +— _personnel_ (3.1.20); +— site; +— organization’s structure. + +3.1.3 **attack** +successful or unsuccessful unauthorized attempt to destroy, alter, disable, gain access to an _asset_ (3.1.2) or any attempt to expose, steal, or make unauthorized use of an _asset_ (3.1.2) + +3.1.4 **authentication** +provision of assurance that a claimed characteristic of an _entity_ (3.1.11) is correct + +3.1.5 **authenticity** +property that an _entity_ (3.1.11) is what it claims to be + +3.1.6 **chain of custody** +demonstrable possession, movement, handling and location of material from one point in time until another +*Note 1 to entry: Material includes information and other associated _assets_ (3.1.2) in the context of ISO/IEC 27002.* + +3.1.7 **confidential information** +information that is not intended to be made available or disclosed to unauthorized individuals, _entities_ (3.1.11) or _processes_ (3.1.27) + +3.1.8 **control** +measure that maintains and/or modifies risk + +*Note 1 to entry: Controls include, but are not limited to, any _process_ (3.1.27), _policy_ (3.1.24), device, practice or other conditions and/or actions which maintain and/or modify risk.* +*Note 2 to entry: Controls may not always exert the intended or assumed modifying effect.* + +3.1.9 **disruption** +incident, whether anticipated or unanticipated, that causes an unplanned, negative deviation from the expected delivery of products and services according to an organization’s objectives + +3.1.10 **endpoint device** +network connected information and communication technology (ICT) hardware device +*Note 1 to entry: Endpoint device can refer to desktop computers, laptops, smart phones, tablets, thin clients, printers or other specialized hardware including smart meters and Internet of things (IoT) devices.* + +3.1.11 **entity** +item relevant for the purpose of operation of a domain that has recognizably distinct existence + +*Note 1 to entry: An entity can have a physical or a logical embodiment.* +A person, an organization, a device, a group of such items, a human subscriber to a telecom +service, a SIM card, a passport, a network interface card, a software application, a service or a website. + +3.1.12 **information processing facility** +any information processing system, service or infrastructure, or the physical location housing it [SOURCE: ISO/IEC 27000:2018, 3.27, modified — "facilities" has been replaced with facility.] + +3.1.13 **information security breach** compromise of information security that leads to the undesired destruction, loss, alteration, disclosure of, or access to, protected information transmitted, stored or otherwise processed + +3.1.14 **information security event** +occurrence indicating a possible _information_ _security_ _breach_ (3.1.13) or failure of _controls_ (3.1.8) + +3.1.15 **information security incident** +one or multiple related and identified _information_ _security_ _events_ (3.1.14) that can harm an organization’s _assets_ (3.1.2) or compromise its operations + +3.1.16 **information security incident management** +exercise of a consistent and effective approach to the handling of _information_ _security_ _incidents_ (3.1.15) [SOURCE: ISO/IEC 27035-1:2016, 3.5] + +3.1.17 **information system** set of applications, services, information technology _assets_ (3.1.2), or other information-handling components + +3.1.18 **interested party stakeholder** +person or organization that can affect, be affected by, or perceive itself to be affected by a decision or activity + +3.1.19 **non-repudiation** +ability to prove the occurrence of a claimed event or action and its originating _entities_ (3.1.11) + +3.1.20 **personnel** +persons doing work under the organization’s direction +*Note 1 to entry: The concept of personnel includes the organization’s members, such as the governing body, top management, employees, temporary staff, contractors and volunteers.* + +3.1.21 **personally identifiable information / PII** +any information that (a) can be used to establish a link between the information and the natural person to whom such information relates, or (b) is or can be directly or indirectly linked to a natural person. +*Note 1 to entry: The “natural person” in the definition is the PII principal (3.1.22). To determine whether a PII principal is identifiable, account should be taken of all the means which can reasonably be used by the privacy stakeholder holding the data, or by any other party, to establish the link between the set of PII and the natural person.* + +3.1.22 **PII principal** +natural person to whom the _personally identifiable_ _information_ _(PII)_ (3.1.21) relates +*Note 1 to entry: Depending on the jurisdiction and the particular data protection and privacy legislation, the synonym “data subject” can also be used instead of the term “PII principal”.* + +3.1.23 **PII processor** +privacy stakeholder that processes _personally_ _identifiable_ _information_ _(PII)_ (3.1.21) on behalf of and in accordance with the instructions of a PII controller + +3.1.24 **policy** +intentions and direction of an organization, as formally expressed by its top management +[SOURCE: ISO/IEC 27000:2018, 3.53] + +3.1.25 **privacy impact assessment PIA** +overall _process_ (3.1.27) of identifying, analysing, evaluating, consulting, communicating and planning the treatment of potential privacy impacts with regard to the processing of _personally_ _identifiable_ _information_ _(PII)_ (3.1.21), framed within an organization’s broader risk management framework + +3.1.26 **procedure** +specified way to carry out an activity or a _process_ (3.1.27) + +3.1.27 **process** +set of interrelated or interacting activities that uses or transforms inputs to deliver a result + +3.1.28 **record** +information created, received and maintained as evidence and as an _asset_ (3.1.2) by an organization or person, in pursuit of legal obligations or in the transaction of business +*Note 1 to entry: Legal obligations in this context include all legal, statutory, regulatory and contractual requirements.* + +3.1.29 **recovery point objective** / **RPO** +point in time to which data are to be recovered after a _disruption_ (3.1.9) has occurred [SOURCE: ISO/IEC 27031:2011, 3.12, modified — "must" replaced by "are to be".] + +3.1.30 **recovery time objective RTO** +period of time within which minimum levels of services and/or products and the supporting systems, applications, or functions are to be recovered after a _disruption_ (3.1.9) has occurred + +3.1.31 **reliability** +property of consistent intended behaviour and results + +3.1.32 **rule** +accepted principle or instruction that states the organization’s expectations on what is required to be done, what is allowed or not allowed +*Note 1 to entry: Rules can be formally expressed in _topic-specific policies_ (3.1.35) and in other types of documents.* + +3.1.33 **sensitive information** +information that needs to be protected from unavailability, unauthorized access, modification or public disclosure because of potential adverse effects on an individual, organization, national security or public safety + +3.1.34 **threat** potential cause of an unwanted incident, which can result in harm to a system or organization [SOURCE: ISO/IEC 27000:2018, 3.74] + +3.1.35 **topic-specific policy** +intentions and direction on a specific subject or topic, as formally expressed by the appropriate level of management +*Note 1 to entry: Topic-specific policies can formally express _rules_ (3.1.32) or organization standards. Note 2 to entry: Some organizations use other terms for these topic-specific policies.* +*Note 3 to entry: The topic-specific policies referred to in this document are related to information security.* + +3.1.36 **user** +_interested_ _party_ (3.1.18) with access to the organization’s _information_ _systems_ (3.1.17) + +3.1.37 **user endpoint device** +_endpoint_ _device_ (3.1.10) used by users to access information processing services +*Note 1 to entry: User endpoint device can refer to desktop computers, laptops, smart phones, tablets, thin clients, etc.* + +3.1.38 **vulnerability** +weakness of an _asset_ (3.1.2) or _control_ (3.1.8) that can be exploited by one or more _threats_ (3.1.34) [SOURCE: ISO/IEC 27000:2018, 3.77] + +### 3.2 Abbreviated terms + +ABAC attribute-based access control +ACL access control list +BIA business impact analysis +BYOD bring your own device +CAPTCHA completely automated public Turing test to tell computers and humans apart +CPU central processing unit +DAC discretionary access control +DNS domain name system +GPS global positioning system +IAM identity and access management +ICT information and communication technology +ID identifier IDE integrated development environment +IDS intrusion detection system IoT internet of things +IP internet protocol +IPS intrusion prevention system +IT information technology +ISMS information security management system +MAC mandatory access control +NTP network time protocol +PIA privacy impact assessment +PII personally identifiable information +PIN personal identification number +PKI public key infrastructure +PTP precision time protocol +RBAC role-based access control +RPO recovery point objective +RTO recovery time objective +SAST static application security testing +SD secure digital +SDN software-defined networking +SD-WAN software-defined wide area networking +SIEM security information and event management +SMS short message service +SQL structured query language +SSO single sign on +SWID software identification +UEBA user and entity behaviour analytics +UPS uninterruptible power supply +URL uniform resource locator +USB universal serial bus +VM virtual machine +VPN virtual private network +WiFi wireless fidelity diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-5.1-Policies-for-information-security.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-5.1-Policies-for-information-security.md index c16d528..3aaf7c7 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-5.1-Policies-for-information-security.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-5.1-Policies-for-information-security.md @@ -1,14 +1,38 @@ -#iso27002/2022/EN +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.5.1" +title: "Policies for information security" +theme: Organizational +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Identify] +operational_capabilities: [Governance] +security_domains: + - Governance_and_Ecosystem + - Resilience +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- + ## 5.1 Policies for information security -#### Control +### Control Information security policy and topic-specific policies should be defined, approved by management, published, communicated to and acknowledged by relevant personnel and relevant interested parties, and reviewed at planned intervals and if significant changes occur. -#### Purpose +### Purpose To ensure continuing suitability, adequacy, effectiveness of management direction and support for information security in accordance with business, legal, statutory, regulatory and contractual requirements. -#### Guidance -At the highest level, the organization should define an “information security policy” which is approved by top management and which sets out the organization’s approach to managing its information security. +### Guidance +At the highest level, the organization should define an "information security policy" which is approved by top management and which sets out the organization's approach to managing its information security. The information security policy should take into consideration requirements derived from: @@ -45,10 +69,10 @@ j) information classification and handling; k) management of technical vulnerabilities; l) secure development. -The responsibility for the development, review and approval of the topic-specific policies should be allocated to relevant personnel based on their appropriate level of authority and technical competency. The review should include assessing opportunities for improvement of the organization’s information security policy and topic-specific policies and managing information security in response to changes to: +The responsibility for the development, review and approval of the topic-specific policies should be allocated to relevant personnel based on their appropriate level of authority and technical competency. The review should include assessing opportunities for improvement of the organization's information security policy and topic-specific policies and managing information security in response to changes to: -a) the organization’s business strategy; -b) the organization’s technical environment; +a) the organization's business strategy; +b) the organization's technical environment; c) regulations, statutes, legislation and contracts; d) information security risks; e) the current and projected information security threat environment; @@ -56,7 +80,7 @@ f) lessons learned from information security events and incidents. The review of information security policy and topic-specific policies should take the results of management reviews and audits into account. Review and update of other related policies should be considered when one policy is changed to maintain consistency. -The information security policy and topic-specific policies should be communicated to relevant personnel and interested parties in a form that is relevant, accessible and understandable to the intended reader. Recipients of the policies should be required to acknowledge they understand and agree to comply with the policies where applicable. The organization can determine the formats and names of these policy documents that meet the organization’s needs. In some organizations, the information security policy and topic-specific policies can be in a single document. The organization can name these topic-specific policies as standards, directives, policies or others. +The information security policy and topic-specific policies should be communicated to relevant personnel and interested parties in a form that is relevant, accessible and understandable to the intended reader. Recipients of the policies should be required to acknowledge they understand and agree to comply with the policies where applicable. The organization can determine the formats and names of these policy documents that meet the organization's needs. In some organizations, the information security policy and topic-specific policies can be in a single document. The organization can name these topic-specific policies as standards, directives, policies or others. If the information security policy or any topic-specific policy is distributed outside the organization, care should be taken not to improperly disclose confidential information. @@ -68,10 +92,9 @@ Level of detail | General or high-level | Specific and detailed Documented and formally approved by | Top management | Appropriate level of management -#### Other information +### Other information Topic-specific policies can vary across organizations. # Related - [[ISO_27002_PE 5.1 Policies for information security]] - diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-5.10-Acceptable-use-of-information-and-other-associated-assets.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-5.10-Acceptable-use-of-information-and-other-associated-assets.md index e627b91..3908613 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-5.10-Acceptable-use-of-information-and-other-associated-assets.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-5.10-Acceptable-use-of-information-and-other-associated-assets.md @@ -1,16 +1,39 @@ +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.5.10" +title: "Acceptable use of information and other associated assets" +theme: Organizational +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: + - Asset_management + - Information_protection +security_domains: + - Governance_and_Ecosystem + - Protection +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- + ## 5.10 Acceptable use of information and other associated assets -| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | -| ------------ | ----------------------------------------- | ---------------------- | ----------------------------------------- | ------------------------------------- | -| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Asset_management #Information_protection | #Governance_and_Ecosystem #Protection | - -**Control** +### Control Rules for the acceptable use and procedures for handling information and other associated assets should be identified, documented and implemented. -**Purpose** +### Purpose To ensure information and other associated assets are appropriately protected, used and handled. -**Guidance** +### Guidance Personnel and external party users using or having access to the organization’s information and other associated assets should be made aware of the information security requirements for protecting and handling the organization’s information and other associated assets. They should be responsible for their use of any information processing facilities. The organization should establish a topic-specific policy on the acceptable use of information and other associated assets and communicate it to anyone who uses or handles information and other associated assets. The topic-specific policy on acceptable use should provide clear direction on how individuals are expected to use information and other associated assets. The topic-specific policy should state: @@ -35,5 +58,5 @@ e\) clear marking of all copies of storage media (electronic or physical) for th f\) authorization of disposal of information and other associated assets and supported deletion method(s) (see [8.10](a-8.10-Information-deletion.md)). -**Other information** +### Other information It can be the case that the assets concerned do not directly belong to the organization, such as public cloud services. The use of such third-party assets and any assets of the organization associated with such external assets (e.g. information, software) should be identified as applicable and controlled, for example, through agreements with cloud service providers. Care should also be taken when a collaborative working environment is used. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-5.11-Return-of-assets.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-5.11-Return-of-assets.md index 6281a5f..a09c0c6 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-5.11-Return-of-assets.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-5.11-Return-of-assets.md @@ -1,18 +1,37 @@ +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.5.11" +title: "Return of assets" +theme: Organizational +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: [Asset_management] +security_domains: [Protection] +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- + ## 5.11 Return of assets -| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | -| ------------ | ----------------------------------------- | ---------------------- | ------------------------ | ---------------- | -| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Asset_management | #Protection | - -**Control** +### Control Personnel and other interested parties as appropriate should return all the organization’s assets in their possession upon change or termination of their employment, contract or agreement. -**Purpose** +### Purpose To protect the organization’s assets as part of the process of changing or terminating employment, contract or agreement. -**Guidance** +### Guidance The change or termination process should be formalized to include the return of all previously issued physical and electronic assets owned by or entrusted to the organization. @@ -30,5 +49,5 @@ c\) specialist equipment; d\) authentication hardware (e.g. mechanical keys, physical tokens and smartcards) for information systems, sites and physical archives; e\) physical copies of information. -**Other information** +### Other information It can be difficult to return information held on assets which are not owned by the organization. In such cases, it is necessary to restrict the use of information using other information security controls such as access rights management (5.18) or use of cryptography (8.24). \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-5.12-Classification-of-information.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-5.12-Classification-of-information.md index 0ea107a..020810a 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-5.12-Classification-of-information.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-5.12-Classification-of-information.md @@ -1,18 +1,37 @@ -#iso27002/2022/EN +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.5.12" +title: "Classification of information" +theme: Organizational +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Identify] +operational_capabilities: [Information_protection] +security_domains: + - Protection + - Defence +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- ## 5.12 Classification of information -| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | -| ------------ | ----------------------------------------- | ---------------------- | ------------------------ | -------------------- | -| #Preventive | #Confidentiality #Integrity #Availability | #Identify | #Information_protection | #Protection #Defence | - -**Control** +### Control Information should be classified according to the information security needs of the organization based on confidentiality, integrity, availability and relevant interested party requirements. -**Purpose** +### Purpose To ensure identification and understanding of protection needs of information in accordance with its importance to the organization. -**Guidance** +### Guidance The organization should establish a topic-specific policy on information classification and communicate it to all relevant interested parties. The organization should take into account requirements for confidentiality, integrity and availability in the classification scheme. @@ -31,7 +50,7 @@ The scheme should be consistent across the whole organization and included in it The classification scheme used within the organization can be different from the schemes used by other organizations, even if the names for levels are similar. In addition, information moving between organizations can vary in classification depending on its context in each organization, even if their classification schemes are identical. Therefore, agreements with other organizations that include information sharing should include procedures to identify the classification of that information and to interpret the classification levels from other organizations. Correspondence between different schemes can be determined by looking for equivalence in the associated handling and protection methods. -**Other information** +### Other information Classification provides people who deal with information with a concise indication of how to handle and protect it. Creating groups of information with similar protection needs and specifying information security procedures that apply to all the information in each group facilitates this. This approach reduces the need for case-by-case risk assessment and custom design of controls. Information can cease to be sensitive or critical after a certain period of time. For example, when the information has been made public, it no longer has confidentiality requirements but can still require protection for its integrity and availability properties. These aspects should be taken into account, as over-classification can lead to the implementation of unnecessary controls resulting in additional expense or, on the contrary, under-classification can lead to insufficient controls to protect the information from compromise. diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-5.13-Labelling-of-information.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-5.13-Labelling-of-information.md index 343d95a..fc3fa9f 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-5.13-Labelling-of-information.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-5.13-Labelling-of-information.md @@ -1,14 +1,39 @@ +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.5.13" +title: "Labelling of information" +theme: Organizational +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: [Information_protection] +security_domains: + - Defence + - Protection +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- + ## 5.13 Labelling of information -**Control** +### Control An appropriate set of procedures for information labelling should be developed and implemented in accordance with the information classification scheme adopted by the organization. -**Purpose** +### Purpose To facilitate the communication of classification of information and support automation of information processing and management. -**Guidance** +### Guidance Procedures for information labelling should cover information and other associated assets in all formats. The labelling should reflect the classification scheme established in 5.12. The labels should be easily recognizable. The procedures should give guidance on where and how labels are attached in consideration of how the information is accessed or the assets are handled depending on the types of storage media. The procedures can define: a\) cases where labelling is omitted (e.g. labelling of non-confidential information to reduce workloads); @@ -37,7 +62,7 @@ Personnel and other interested parties should be made aware of labelling procedu Output from systems containing information that is classified as being sensitive or critical should carry an appropriate classification label. -**Other information** +### Other information Labelling of classified information is a key requirement for information sharing. Other useful metadata that can be attached to the information is which organizational process created the information and at what time. diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-5.14-Information-transfer.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-5.14-Information-transfer.md index e9cc43d..1ec4ceb 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-5.14-Information-transfer.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-5.14-Information-transfer.md @@ -1,16 +1,37 @@ +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.5.14" +title: "Information transfer" +theme: Organizational +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: + - Asset_management + - Information_protection +security_domains: [Protection] +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- + ## 5.14 Information transfer -| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | -| ------------ | ----------------------------------------- | ---------------------- | ----------------------------------------- | ---------------- | -| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Asset_management #Information_protection | #Protection | - -**Control** +### Control Information transfer rules, procedures, or agreements should be in place for all types of transfer facilities within the organization and between the organization and other parties. -**Purpose** +### Purpose To maintain the security of information transferred within an organization and with any external interested party. -**Guidance** +### Guidance <u>General</u> The organization should establish and communicate a topic-specific policy on information transfer to all relevant interested parties. Rules, procedures and agreements to protect information in transit should reflect the classification of the information involved. Where information is transferred between the organization and third parties, transfer agreements (including recipient authentication) should be established and maintained to protect information in all forms in transit (see [5.10](a-5.10-Acceptable-use-of-information-and-other-associated-assets.md)). @@ -136,6 +157,6 @@ e\) begin any sensitive conversations with a disclaimer so those present know th -**Other information** +### Other information No other information. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-5.15-Access-control.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-5.15-Access-control.md index bfe1808..1273efe 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-5.15-Access-control.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-5.15-Access-control.md @@ -1,18 +1,35 @@ -#iso27002/2022/EN +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.5.15" +title: "Access control" +theme: Organizational +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: [Identity_and_access_management] +security_domains: [Protection] +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- ## 5.15 Access control -| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | -| ------------ | ----------------------------------------- | ---------------------- | ------------------------------- | ---------------- | -| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Identity_and_access_management | #Protection | - -**Control** +### Control Rules to control physical and logical access to information and other associated assets should be established and implemented based on business and information security requirements. -**Purpose** +### Purpose To ensure authorized access and to prevent unauthorized access to information and other associated assets. -**Guidance** +### Guidance Owners of information and other associated assets should determine information security and business requirements related to access control. A topic-specific policy on access control should be defined which takes account of these requirements and should be communicated to all relevant interested parties. These requirements and the topic-specific policy should consider the following: @@ -51,7 +68,7 @@ c\) considering all types of available connections in distributed environments s d\) considering how elements or factors relevant to dynamic access control can be reflected. -**Other information** +### Other information There are often overarching principles used in the context of access control. Two of the most frequently used principles are: diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-5.16-Identity-management.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-5.16-Identity-management.md index 481ee8d..6837e87 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-5.16-Identity-management.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-5.16-Identity-management.md @@ -1,16 +1,35 @@ +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.5.16" +title: "Identity management" +theme: Organizational +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: [Identity_and_access_management] +security_domains: [Protection] +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- + ## 5.16 Identity management -| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | -| ------------ | ----------------------------------------- | ---------------------- | ------------------------------- | ---------------- | -| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Identity_and_access_management | #Protection | - -**Control** +### Control The full life cycle of identities should be managed. -**Purpose** +### Purpose To allow for the unique identification of individuals and systems accessing the organization’s information and other associated assets and to enable appropriate assignment of access rights. -**Guidance** +### Guidance The processes used in the context of identity management should ensure that: a\) for identities assigned to persons, a specific identity is only linked to a single person to be able to hold the person accountable for actions performed with this specific identity; @@ -29,7 +48,7 @@ The organization should have a supporting process in place to handle changes to When using identities provided or issued by third parties (e.g. social media credentials), the organization should ensure the third-party identities provide the required trust level and any associated risks are known and sufficiently treated. This can include controls related to the third parties (see [5.19](a-5.19-Information-security-in-supplier-relationships.md)) as well as controls related to associated authentication information (see [5.17](a-5.17-Authentication-information.md)). -**Other information** +### Other information Providing or revoking access to information and other associated assets is usually a multi-step procedure: a\) confirming the business requirements for an identity to be established; diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-5.17-Authentication-information.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-5.17-Authentication-information.md index debc788..65c1333 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-5.17-Authentication-information.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-5.17-Authentication-information.md @@ -1,4 +1,26 @@ -#iso27002/2022/EN +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.5.17" +title: "Authentication information" +theme: Organizational +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: [Identity_and_access_management] +security_domains: [Protection] +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- + ## 5.17 Authentication information ### Control @@ -65,7 +87,7 @@ h)   store and transmit passwords in protected form. Password  encryption  and  hashing  should  be  performed  according  to  approved  cryptographic techniques for passwords (see [8.24](a-8.24-Use-of-cryptography.md)). -**Other information** +### Other information Passwords or passphrases are a commonly used type of authentication information and are a common means of verifying a user’s identity. Other types of authentication information are cryptographic keys, data stored on hardware tokens (e.g. smart cards) that produce authentication codes and biometric data such as iris scans or fingerprints. Additional information can be found in the ISO/IEC 24760 series. diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-5.18-Access-rights.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-5.18-Access-rights.md index 7020cd9..50f9d01 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-5.18-Access-rights.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-5.18-Access-rights.md @@ -1,16 +1,35 @@ +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.5.18" +title: "Access rights" +theme: Organizational +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: [Identity_and_access_management] +security_domains: [Protection] +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- + ## 5.18 Access rights -| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | -| ------------ | ----------------------------------------- | ---------------------- | ------------------------------- | ---------------- | -| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Identity_and_access_management | #Protection | - -**Control** +### Control Access rights to information and other associated assets should be provisioned, reviewed, modified and removed in accordance with the organization’s topic-specific policy on and rules for access control. -**Purpose** +### Purpose To ensure access to information and other associated assets is defined and authorized according to the business requirements. -**Guidance** +### Guidance <u>Provision and revocation of access rights</u> The provisioning process for assigning or revoking physical and logical access rights granted to an entity’s authenticated identity should include: @@ -53,7 +72,7 @@ b\) the current responsibilities of the user; c\) the value of the assets currently accessible. -**Other information** +### Other information Consideration should be given to establishing user access roles based on business requirements that summarize a number of access rights into typical user access profiles. Access requests and reviews of access rights are easier managed at the level of such roles than at the level of particular rights. Consideration should be given to including clauses in personnel contracts and service contracts that specify sanctions if unauthorized access is attempted by personnel (see [5.20](a-5.20-Addressing-information-security-within-supplier-agreements.md), [6.2](a-6.2-Terms-and-conditions-of-employment.md), [6.4](a-6.4-Disciplinary-process.md), [6.6](a-6.6-Confidentiality-or-non-disclosure-agreements.md)). diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-5.19-Information-security-in-supplier-relationships.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-5.19-Information-security-in-supplier-relationships.md index 11664ac..91399a7 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-5.19-Information-security-in-supplier-relationships.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-5.19-Information-security-in-supplier-relationships.md @@ -1,15 +1,39 @@ -#iso27002/2022/EN +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.5.19" +title: "Information security in supplier relationships" +theme: Organizational +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Identify] +operational_capabilities: [Supplier_relationships_security] +security_domains: + - Governance_and_Ecosystem + - Protection +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- + ## 5.19 Information security in supplier relationships -**Control** +### Control Processes and procedures should be defined and implemented to manage the information security risks associated with the use of supplier’s products or services. -**Purpose** +### Purpose To maintain an agreed level of information security in supplier relationships. -**Guidance** +### Guidance The organization should establish and communicate a topic-specific policy on supplier relationships to all relevant interested parties. @@ -56,7 +80,7 @@ n\) level of personnel security and physical security expected from supplier's p The procedures for continuing information processing in the event that the supplier becomes unable to supply its products or services (e.g. because of an incident, because the supplier is no longer in business, or no longer provides some components due to technology advancements) should be considered to avoid any delay in arranging replacement products or services (e.g. identifying an alternative supplier in advance or always using alternative suppliers). -**Other information** +### Other information In cases where it is not possible for an organization to place requirements on a supplier, the organization should: diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-5.2-Information-security-roles-and-responsibilities.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-5.2-Information-security-roles-and-responsibilities.md index d525666..9cae277 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-5.2-Information-security-roles-and-responsibilities.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-5.2-Information-security-roles-and-responsibilities.md @@ -1,4 +1,29 @@ -#iso27002/2022/EN +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.5.2" +title: "Information security roles and responsibilities" +theme: Organizational +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Identify] +operational_capabilities: [Governance] +security_domains: + - Governance_and_Ecosystem + - Protection + - Resilience +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- + ## 5.2 Information security roles and responsibilities ### Control diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-5.20-Addressing-information-security-within-supplier-agreements.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-5.20-Addressing-information-security-within-supplier-agreements.md index 55e407d..79b79ea 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-5.20-Addressing-information-security-within-supplier-agreements.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-5.20-Addressing-information-security-within-supplier-agreements.md @@ -1,13 +1,37 @@ -#iso27002/2022/EN +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.5.20" +title: "Addressing information security within supplier agreements" +theme: Organizational +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Identify] +operational_capabilities: [Supplier_relationships_security] +security_domains: + - Governance_and_Ecosystem + - Protection +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- + ## 5.20 Addressing information security within supplier agreements -**Control** +### Control Relevant information security requirements should be established and agreed with each supplier based on the type of supplier relationship. -**Purpose** +### Purpose To maintain an agreed level of information security in supplier relationships. -**Guidance** +### Guidance Supplier agreements should be established and documented to ensure that there is clear understanding between the organization and the supplier regarding both parties’ obligations to fulfil relevant information security requirements. The following terms can be considered for inclusion in the agreements in order to satisfy the identified information security requirements: @@ -66,7 +90,7 @@ z\) ensuring, at the end of the contract, handover support to another supplier o The organization should establish and maintain a register of agreements with external parties (e.g. contracts, memorandum of understanding, information-sharing agreements) to keep track of where their information is going. The organization should also regularly review, validate and update their agreements with external parties to ensure they are still required and fit for purpose with relevant information security clauses. -**Other information** +### Other information The agreements can vary considerably for different organizations and among the different types of suppliers. Therefore, care should be taken to include all relevant requirements for addressing information security risks. For details on supplier agreements, see ISO/IEC 27036 series. For cloud service agreements, see ISO/IEC 19086 series. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-5.21-Managing-information-security-in-the-ICT-supply-chain.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-5.21-Managing-information-security-in-the-ICT-supply-chain.md index bed7514..a2264fd 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-5.21-Managing-information-security-in-the-ICT-supply-chain.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-5.21-Managing-information-security-in-the-ICT-supply-chain.md @@ -1,15 +1,37 @@ -#iso27002/2022/EN -[[ISO_27002_PE 5.21 Managing information security in the ICT supply chain]] +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.5.21" +title: "Managing information security in the ICT supply chain" +theme: Organizational +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Identify] +operational_capabilities: [Supplier_relationships_security] +security_domains: + - Governance_and_Ecosystem + - Protection +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- ## 5.21 Managing information security in the ICT supply chain -**Control** +### Control Processes and procedures should be defined and implemented to manage the information security risks associated with the ICT products and services supply chain. -**Purpose** +### Purpose To maintain an agreed level of information security in supplier relationships. -**Guidance** +### Guidance The following topics should be considered to address information security within ICT supply chain security in addition to the general information security requirements for supplier relationships: @@ -39,7 +61,7 @@ l\) defining rules for sharing of information regarding the supply chain and any m\) implementing specific processes for managing ICT component life cycle and availability and associated security risks. This includes managing the risks of components no longer being available due to suppliers no longer being in business or suppliers no longer providing these components due to technology advancements. Identification of an alternative supplier and the process to transfer software and competence to the alternative supplier should be considered. -**Other information** +### Other information The specific ICT supply chain risk management practices are built on top of general information security, quality, project management and system engineering practices but do not replace them. diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-5.22-Monitoring-review-and-change-management-of-supplier-services.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-5.22-Monitoring-review-and-change-management-of-supplier-services.md index 6f842b7..b42b2fe 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-5.22-Monitoring-review-and-change-management-of-supplier-services.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-5.22-Monitoring-review-and-change-management-of-supplier-services.md @@ -1,12 +1,39 @@ -#iso27002/2022/EN +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.5.22" +title: "Monitoring, review and change management of supplier services" +theme: Organizational +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Identify] +operational_capabilities: [Supplier_relationships_security] +security_domains: + - Governance_and_Ecosystem + - Protection + - Defence + - Information_security_assurance +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- -**Control** +## 5.22 Monitoring, review, and change management of supplier services + +### Control The organization should regularly monitor, review, evaluate and manage change in supplier information security practices and service delivery. -**Purpose** +### Purpose To maintain an agreed level of information security and service delivery in line with supplier agreements. -**Guidance** +### Guidance Monitoring, review and change management of supplier services should ensure the information security terms and conditions of the agreements are complied with, information security incidents and problems are managed properly and changes in supplier services or business status do not affect service delivery. This should involve a process to manage the relationship between the organization and the supplier to: @@ -51,5 +78,5 @@ m\) evaluate regularly that the suppliers maintain adequate information security The responsibility for managing supplier relationships should be assigned to a designated individual or team. Sufficient technical skills and resources should be made available to monitor that the requirements of the agreement, in particular the information security requirements, are being met. Appropriate actions should be taken when deficiencies in the service delivery are observed. -**Other information** +### Other information See ISO/IEC 27036-3 for more detail. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-5.23-Information-security-for-use-of-cloud-services.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-5.23-Information-security-for-use-of-cloud-services.md index 4b5329c..439e702 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-5.23-Information-security-for-use-of-cloud-services.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-5.23-Information-security-for-use-of-cloud-services.md @@ -1,13 +1,37 @@ -#iso27002/2022/EN +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.5.23" +title: "Information security for use of cloud services" +theme: Organizational +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: [Supplier_relationships_security] +security_domains: + - Governance_and_Ecosystem + - Protection +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- + ## 5.23 Information security for use of cloud services -#### Control +### Control Processes for acquisition, use, management and exit from cloud services should be established in accordance with the organization’s information security requirements. -#### Purpose +### Purpose To specify and manage information security for the use of cloud services. -#### Guidance +### Guidance The organization should establish and communicate topic-specific policy on the use of cloud services to all relevant interested parties. The organization should define and communicate how it intends to manage information security risks associated with the use of cloud services. It can be an extension or part of the existing approach for how an organization manages services provided by external parties (see [5.21](a-5.21-Managing-information-security-in-the-ICT-supply-chain.md), [5.22](a-5.22-Monitoring-review-and-change-management-of-supplier-services.md)). @@ -48,7 +72,7 @@ c) use of peer cloud service providers or other sub-contractors (including chang The organization using cloud services should maintain close contact with its cloud service providers. These contacts enable mutual exchange of information about information security for the use of the cloud services including a mechanism for both cloud service provider and the organization, acting as the cloud service customer, to monitor each service characteristic and report failures to the commitments contained in the agreements. -#### Other information +### Other information This control considers cloud security from the perspective of the cloud service customer. Additional information relating to cloud services can be found in ISO/IEC 17788, ISO/IEC 17789 and ISO/IEC 22123-1. Specifics related to cloud portability in support of exit strategies can be found in ISO/IEC 19941. Specifics related to information security and public cloud services are described in ISO/IEC 27017. Specifics related to PII protection in public clouds acting as PII processor are described in ISO/IEC 27018. Supplier relationships for cloud services are covered by ISO/IEC 27036-4 and cloud service agreements and their contents are dealt with in the ISO/IEC 19086 series, with security and privacy specifically covered by ISO/IEC 19086-4. diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-5.24-Information-security-incident-management-planning-and-preparation.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-5.24-Information-security-incident-management-planning-and-preparation.md index f8fac08..4d5d23c 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-5.24-Information-security-incident-management-planning-and-preparation.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-5.24-Information-security-incident-management-planning-and-preparation.md @@ -1,13 +1,39 @@ -#iso27002/2022/EN +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.5.24" +title: "Information security incident management planning and preparation" +theme: Organizational +control_type: [Corrective] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: + - Respond + - Recover +operational_capabilities: + - Governance + - Information_security_event_management +security_domains: [Defence] +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- + ## 5.24 Information security incident management planning and preparation -#### Control +### Control The organization should plan and prepare for managing information security incidents by defining, establishing and communicating information security incident management processes, roles and responsibilities. -#### Purpose +### Purpose To ensure quick, effective, consistent and orderly response to information security incidents, including communication on information security events. -#### Guidance +### Guidance **Roles and responsibilities** @@ -61,7 +87,7 @@ d\) creation of incident reports. Any external requirements on reporting of incidents to relevant interested parties within the defined time frame (e.g. breach notification requirements to regulators) should be considered when implementing incident management procedures. -**Other information** +### Other information Information security incidents can transcend organizational and national boundaries. To respond to such incidents, it is beneficial to coordinate response and share information about these incidents with external organizations as appropriate. diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-5.25-Assessment-and-decision-on-information-security-events.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-5.25-Assessment-and-decision-on-information-security-events.md index 827c3ad..9b25384 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-5.25-Assessment-and-decision-on-information-security-events.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-5.25-Assessment-and-decision-on-information-security-events.md @@ -1,19 +1,38 @@ +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.5.25" +title: "Assessment and decision on information security events" +theme: Organizational +control_type: [Detective] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: + - Detect + - Respond +operational_capabilities: [Information_security_event_management] +security_domains: [Defence] +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- + ## 5.25 Assessment and decision on information security events -| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | -| ------------ | ----------------------------------------- | ---------------------- | -------------------------------------- | ---------------- | -| #Detective | #Confidentiality #Integrity #Availability | #Detect #Respond | #Information_security_event_management | #Defence | - - - -**Control** +### Control The organization should assess information security events and decide if they are to be categorized as information security incidents. -**Purpose** +### Purpose @@ -21,7 +40,7 @@ To ensure effective categorization and prioritization of information security ev -**Guidance** +### Guidance @@ -31,5 +50,5 @@ Personnel responsible for coordinating and responding to information security in Results of the assessment and decision should be recorded in detail for the purpose of future reference and verification. -**Other information** +### Other information The ISO/IEC 27035 series provides further guidance on incident management. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-5.26-Response-to-information-security-incidents.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-5.26-Response-to-information-security-incidents.md index f1a470f..bf3c090 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-5.26-Response-to-information-security-incidents.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-5.26-Response-to-information-security-incidents.md @@ -1,19 +1,39 @@ +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.5.26" +title: "Response to information security incidents" +theme: Organizational +control_type: [Corrective] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: + - Respond + - Recover +operational_capabilities: [Information_security_event_management] +security_domains: [Defence] +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- + ## 5.26 Response to information security incidents -| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | -| ------------ | ----------------------------------------- | ---------------------- | -------------------------------------- | ---------------- | -| #Corrective | #Confidentiality #Integrity #Availability | #Respond #Recover | #Information_security_event_management | #Defence | - - -**Control** +### Control Information security incidents should be responded to in accordance with the documented procedures. -**Purpose** +### Purpose To ensure efficient and effective response to information security incidents. -**Guidance** +### Guidance The organization should establish and communicate procedures on information security incident response to all relevant interested parties. Information security incidents should be responded to by a designated team with the required competency (see [5.24](a-5.24-Information-security-incident-management-planning-and-preparation.md)). @@ -31,5 +51,5 @@ h\) conducting information security forensic analysis, as required (see [5.28](a i\) performing post-incident analysis to identify root cause. Ensure it is documented and communicated according to defined procedures (see [5.27](a-5.27-Learning-from-information-security-incidents.md)); j\) identifying and managing information security vulnerabilities and weaknesses including those related to controls which have caused, contributed to or failed to prevent the incident. -**Other information** +### Other information The ISO/IEC 27035 series provides further guidance on incident management. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-5.27-Learning-from-information-security-incidents.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-5.27-Learning-from-information-security-incidents.md index 6b32db2..1619cd2 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-5.27-Learning-from-information-security-incidents.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-5.27-Learning-from-information-security-incidents.md @@ -1,13 +1,37 @@ -#iso27002/2022/EN +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.5.27" +title: "Learning from information security incidents" +theme: Organizational +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: + - Identify + - Protect +operational_capabilities: [Information_security_event_management] +security_domains: [Defence] +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- + ## 5.27 Learning from information security incidents -#### Control +### Control Knowledge gained from information security incidents should be used to strengthen and improve the information security controls. -#### Purpose +### Purpose To reduce the likelihood or consequences of future incidents. -#### Guidance +### Guidance The organization should establish procedures to quantify and monitor the types, volumes and costs of information security incidents. The information gained from the evaluation of information security incidents should be used to: @@ -18,6 +42,6 @@ b\) identify recurring or serious incidents and their causes to update the organ c\) enhance user awareness and training (see [6.3](ISO_27002_2022_6.3_OT%20Information%20security%20awareness%2C%20education%20and%20training.md)) by providing examples of what can happen, how to respond to such incidents and how to avoid them in the future. -#### Other information +### Other information The ISO/IEC 27035 series provides further guidance. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-5.28-Collection-of-evidence.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-5.28-Collection-of-evidence.md index d4b3cff..f97cfc5 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-5.28-Collection-of-evidence.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-5.28-Collection-of-evidence.md @@ -1,20 +1,39 @@ +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.5.28" +title: "Collection of evidence" +theme: Organizational +control_type: [Corrective] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: + - Detect + - Respond +operational_capabilities: [Information_security_event_management] +security_domains: [Defence] +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- + ## 5.28 Collection of evidence -| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | -| ------------ | ----------------------------------------- | ---------------------- | -------------------------------------- | ---------------- | -| #Corrective | #Confidentiality #Integrity #Availability | #Detect #Respond | #Information_security_event_management | #Defence | - - - -**Control** +### Control The organization should establish and implement procedures for the identification, collection, acquisition and preservation of evidence related to information security events. -**Purpose** +### Purpose To ensure a consistent and effective management of evidence related to information security incidents for the purposes of disciplinary and legal actions. -**Guidance** +### Guidance Internal procedures should be developed and followed when dealing with evidence related to information security events for the purposes of disciplinary and legal actions. The requirements of different jurisdictions should be considered to maximize chances of admission across the relevant jurisdictions. In general, these procedures for the management of evidence should provide instructions for the identification, collection, acquisition and preservation of evidence in accordance with different types of storage media, devices and status of devices (i.e. powered on or off). Evidence typically needs to be collected in a manner that is admissible in the appropriate national courts of law or another disciplinary forum. It should be possible to show that: @@ -29,7 +48,7 @@ Where available, certification or other relevant means of qualification of perso Digital evidence can transcend organizational or jurisdictional boundaries. In such cases, it should be ensured that the organization is entitled to collect the required information as digital evidence. -**Other information** +### Other information When an information security event is first detected, it is not always obvious whether or not the event will result in court action. Therefore, the danger exists that necessary evidence is destroyed intentionally or accidentally before the seriousness of the incident is realized. It is advisable to involve legal advice or law enforcement early in any contemplated legal action and take advice on the evidence required. diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-5.29-Information-security-during-disruption.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-5.29-Information-security-during-disruption.md index c37ffcf..e6a46d9 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-5.29-Information-security-during-disruption.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-5.29-Information-security-during-disruption.md @@ -1,17 +1,41 @@ -#iso27002/2022/EN +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.5.29" +title: "Information security during disruption" +theme: Organizational +control_type: + - Preventive + - Corrective +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: + - Protect + - Respond +operational_capabilities: [Continuity] +security_domains: + - Protection + - Resilience +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- + ## 5.29 Information security during disruption -| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | -| ----------------------- | ----------------------------------------- | ---------------------- | ------------------------ | ----------------------- | -| #Preventive #Corrective | #Confidentiality #Integrity #Availability | #Protect #Respond | #Continuity | #Protection #Resilience | - -**Control** +### Control The organization should plan how to maintain information security at an appropriate level during disruption. -**Purpose** +### Purpose To protect information and other associated assets during disruption. -**Guidance** +### Guidance The organization should determine its requirements for adapting information security controls during disruption. Information security requirements should be included in the business continuity management processes. Plans should be developed, implemented, tested, reviewed and evaluated to maintain or restore the security of information of critical business processes following interruption or failure. Security of information should be restored at the required level and in the required time frames. @@ -24,7 +48,7 @@ b\) processes to maintain existing information security controls during disrupti c\) compensating controls for information security controls that cannot be maintained during disruption. -**Other information** +### Other information In the context of business continuity and ICT continuity planning, it can be necessary to adapt the information security requirements depending on the type of disruption, compared to normal operational conditions. As part of the business impact analysis and risk assessment performed within business continuity management, the consequences of loss of confidentiality and integrity of information should be considered and prioritized in addition to the need for maintaining availability. Information on business continuity management systems can be found in ISO 22301 and ISO 22313. Further guidance on business impact analysis (BIA) can be found in ISO/TS 22317. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-5.3-Segregation-of-duties.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-5.3-Segregation-of-duties.md index 9895400..616387a 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-5.3-Segregation-of-duties.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-5.3-Segregation-of-duties.md @@ -1,4 +1,27 @@ -#iso27002/2022/EN +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.5.3" +title: "Segregation of duties" +theme: Organizational +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: + - Governance + - Identity_and_access_management +security_domains: [Governance_and_Ecosystem] +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- ## 5.3 Segregation of duties ### Control @@ -12,24 +35,24 @@ Segregation of duties and areas of responsibility aims to separate conflicting d The organization should determine which duties and areas of responsibility need to be segregated. The following are examples of activities that can require segregation: -a)   initiating, approving and executing a change; +a) initiating, approving and executing a change; -b)   requesting, approving and implementing access rights; +b) requesting, approving and implementing access rights; -c)   designing, implementing and reviewing code; +c) designing, implementing and reviewing code; -d)   developing software and administering production systems; +d) developing software and administering production systems; -e)   using and administering applications; +e) using and administering applications; -f)   using applications and administering databases; +f) using applications and administering databases; -g)   designing, auditing and assuring information security controls. +g) designing, auditing and assuring information security controls. -The  possibility of collusion should be considered in designing the segregation controls. Small organizations can find segregation of duties difficult to achieve, but the principle should be applied as far as is possible and practicable. Whenever it is difficult to segregate, other controls should be considered, such as monitoring of activities, audit trails and management supervision. +The possibility of collusion should be considered in designing the segregation controls. Small organizations can find segregation of duties difficult to achieve, but the principle should be applied as far as is possible and practicable. Whenever it is difficult to segregate, other controls should be considered, such as monitoring of activities, audit trails and management supervision. Care should be taken when using role-based access control systems to ensure that persons are not granted conflicting roles. When there is a large number of roles, the organization should consider using automated tools to identify conflicts and facilitate their removal. Roles should be carefully defined and provisioned to minimize access problems if a role is removed or reassigned. -### Other **information** +### Other information No other information. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-5.30-ICT-readiness-for-business-continuity.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-5.30-ICT-readiness-for-business-continuity.md index 57a9d36..ff2353c 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-5.30-ICT-readiness-for-business-continuity.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-5.30-ICT-readiness-for-business-continuity.md @@ -1,15 +1,30 @@ -#iso27002/2022/EN -See also: -- [BCP_Bedrijfscontinuïteitsplanning](../../../../../📚️%20Literature%20notes/BCP_Bedrijfscontinuïteitsplanning.md) -- [Disaster Recovery Planning](../../../../../🎇%20Sparks/Disaster%20Recovery%20Planning.md) +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.5.30" +title: "ICT readiness for business continuity" +theme: Organizational +control_type: [Corrective] +information_security_properties: [Availability] +cybersecurity_concepts: [Respond] +operational_capabilities: [Continuity] +security_domains: [Resilience] +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- -# **5.30** **ICT** **readiness** **for** **business** continuity +## 5.30 ICT readiness for business continuity -## Purpose +### Purpose To ensure the availability of the organization’s information and other associated assets during disruption. -## Guidance +### Guidance ICT readiness for business continuity is an important component in business continuity management and information security management to ensure that the organization’s objectives can continue to be met during disruption. @@ -34,7 +49,7 @@ c)   ICT continuity plans include the following ICT continuity information: 2)   RTO of each prioritized ICT service and the procedures for restoring those components; 3)   RPO of the prioritized ICT resources defined as information and the procedures for restoring the information. -## Other **information** +### Other information Managing ICT continuity forms a key part of business continuity requirements concerning availability to be able to: diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-5.31-Legal-statutory-regulatory-and-contractual-requirements.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-5.31-Legal-statutory-regulatory-and-contractual-requirements.md index 03202b6..b8cae64 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-5.31-Legal-statutory-regulatory-and-contractual-requirements.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-5.31-Legal-statutory-regulatory-and-contractual-requirements.md @@ -1,16 +1,37 @@ +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.5.31" +title: "Legal, statutory, regulatory and contractual requirements" +theme: Organizational +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Identify] +operational_capabilities: [Legal_and_compliance] +security_domains: + - Governance_and_Ecosystem + - Protection +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- + ## 5.31 Legal, statutory, regulatory and contractual requirements -| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | -| ------------ | ----------------------------------------- | ---------------------- | ------------------------ | ------------------------------------- | -| #Preventive | #Confidentiality #Integrity #Availability | #Identify | #Legal_and_compliance | #Governance_and_Ecosystem #Protection | - -**Control** +### Control Legal, statutory, regulatory and contractual requirements relevant to information security and the organization’s approach to meet these requirements should be identified, documented and kept up to date. -**Purpose** +### Purpose To ensure compliance with legal, statutory, regulatory and contractual requirements related to information security. -**Guidance** +### Guidance <u>General</u> External requirements including legal, statutory, regulatory or contractual requirements should be taken into consideration when: diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-5.32-Intellectual-property-rights.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-5.32-Intellectual-property-rights.md index 74e38b0..0c9b14b 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-5.32-Intellectual-property-rights.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-5.32-Intellectual-property-rights.md @@ -1,10 +1,32 @@ -#iso27002/2022/EN +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.5.32" +title: "Intellectual property rights" +theme: Organizational +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Identify] +operational_capabilities: [Legal_and_compliance] +security_domains: [Governance_and_Ecosystem] +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- + ## 5.32 Intellectual property rights -**Control** +### Control The organization should implement appropriate procedures to protect intellectual property rights. -**Purpose** +### Purpose To ensure compliance with legal, statutory, regulatory and contractual requirements related to intellectual property rights and use of proprietary products. The following guidelines should be considered to protect any material that can be considered intellectual property: @@ -33,7 +55,7 @@ k\) not duplicating, converting to another format or extracting from commercial l\) not copying, in full or in part, standards (e.g. ISO/IEC International Standards), books, articles, reports or other documents, other than permitted by copyright law or the applicable licences. -**Other information** +### Other information Intellectual property rights include software or document copyright, design rights, trademarks, patents and source code licences. diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-5.33-Protection-of-records.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-5.33-Protection-of-records.md index b4d26f3..4715ae0 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-5.33-Protection-of-records.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-5.33-Protection-of-records.md @@ -1,19 +1,39 @@ +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.5.33" +title: "Protection of records" +theme: Organizational +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: + - Identify + - Protect +operational_capabilities: + - Legal_and_compliance + - Asset_management + - Information_protection +security_domains: [Defence] +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- ## 5.33 Protection of records - - -| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | -| ------------ | ----------------------------------------- | ---------------------- | --------------------------------------------------------------- | ---------------- | -| #Preventive | #Confidentiality #Integrity #Availability | #Identify #Protect | #Legal_and_compliance #Asset_management #Information_protection | #Defence | - - -**Control** +### Control Records should be protected from loss, destruction, falsification, unauthorized access and unauthorized release. -**Purpose** +### Purpose To ensure compliance with legal, statutory, regulatory and contractual requirements, as well as community or societal expectations related to the protection and availability of records. -**Guidance** +### Guidance The organization should take the following steps to protect the authenticity, reliability, integrity and usability of records, as their business context and requirements for their management change over time: a\) issue guidelines on the storage, handling chain of custody and disposal of records, which includes prevention of manipulation of records. These guidelines should be aligned with the organization’s topic-specific policy on records management and other records requirements; @@ -30,7 +50,7 @@ Where electronic storage media are chosen, procedures to ensure the ability to a Storage and handling procedures should be implemented in accordance with recommendations provided by manufacturers of storage media. Consideration should be given to the possibility of deterioration of media used for storage of records. -**Other information** +### Other information Records document individual events or transactions or can form aggregations that have been designed to document work processes, activities or functions. They are both evidence of business activity and information assets. Any set of information, regardless of its structure or form, can be managed as a record. This includes information in the form of a document, a collection of data or other types of digital or analogue information which are created, captured and managed in the course of business. diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-5.34-Privacy-and-protection-of-PII.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-5.34-Privacy-and-protection-of-PII.md index cf279bd..b1c018f 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-5.34-Privacy-and-protection-of-PII.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-5.34-Privacy-and-protection-of-PII.md @@ -1,18 +1,39 @@ +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.5.34" +title: "Privacy and protection of PII" +theme: Organizational +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: + - Identify + - Protect +operational_capabilities: + - Information_protection + - Legal_and_compliance +security_domains: [Protection] +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- + ## 5.34 Privacy and protection of PII - - -| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | -| ------------ | ----------------------------------------- | ---------------------- | --------------------------------------------- | ---------------- | -| #Preventive | #Confidentiality #Integrity #Availability | #Identify #Protect | #Information_protection #Legal_and_compliance | #Protection | - -**Control** +### Control The organization should identify and meet the requirements regarding the preservation of privacy and protection of PII according to applicable laws and regulations and contractual requirements. -**Purpose** +### Purpose To ensure compliance with legal, statutory, regulatory and contractual requirements related to the information security aspects of the protection of PII. -**Guidance** +### Guidance The organization should establish and communicate a topic-specific policy on privacy and protection of PII to all relevant interested parties. The organization should develop and implement procedures for the preservation of privacy and protection of PII. These procedures should be communicated to all relevant interested parties involved in the processing of personally identifiable information. @@ -23,7 +44,7 @@ Responsibility for handling PII should be dealt with taking into consideration r Appropriate technical and organizational measures to protect PII should be implemented. -**Other information** +### Other information A number of countries have introduced legislation placing controls on the collection, processing, transmission and deletion of PII. Depending on the respective national legislation, such controls can impose duties on those collecting, processing and disseminating PII and can also restrict the authority to transfer PII to other countries. ISO/IEC 29100 provides a high-level framework for the protection of PII within ICT systems. Further information on privacy information management systems can be found in ISO/IEC 27701. Specific information regarding privacy information management for public clouds acting as PII processors can be found in ISO/IEC 27018. diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-5.35-Independent-review-of-information-security.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-5.35-Independent-review-of-information-security.md index 893e829..baeadd9 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-5.35-Independent-review-of-information-security.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-5.35-Independent-review-of-information-security.md @@ -1,18 +1,39 @@ +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.5.35" +title: "Independent review of information security" +theme: Organizational +control_type: + - Preventive + - Corrective +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: + - Identify + - Protect +operational_capabilities: [Information_security_assurance] +security_domains: [Governance_and_Ecosystem] +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- + ## 5.35 Independent review of information security - - -| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | -| ----------------------- | ----------------------------------------- | ---------------------- | ------------------------------- | ------------------------- | -| #Preventive #Corrective | #Confidentiality #Integrity #Availability | #Identify #Protect | #Information_security_assurance | #Governance_and_Ecosystem | - -**Control** +### Control The organization’s approach to managing information security and its implementation including people, processes and technologies should be reviewed independently at planned intervals, or when significant changes occur. -**Purpose** +### Purpose To ensure the continuing suitability, adequacy and effectiveness of the organization’s approach to managing information security. -**Guidance** +### Guidance The organization should have processes to conduct independent reviews. Management should plan and initiate periodic independent reviews. The reviews should include assessing opportunities for improvement and the need for changes to the approach to information security, including the information security policy, topic-specific policies and other controls. diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-5.36-Compliance-with-policies-rules-and-standards-for-information-security.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-5.36-Compliance-with-policies-rules-and-standards-for-information-security.md index ed00652..4a607c3 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-5.36-Compliance-with-policies-rules-and-standards-for-information-security.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-5.36-Compliance-with-policies-rules-and-standards-for-information-security.md @@ -1,16 +1,39 @@ +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.5.36" +title: "Compliance with policies, rules and standards for information security" +theme: Organizational +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: + - Identify + - Protect +operational_capabilities: + - Legal_and_compliance + - Information_security_assurance +security_domains: [Governance_and_Ecosystem] +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- + ## 5.36 Compliance with policies, rules and standards for information security -| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | -| ------------ | ----------------------------------------- | ---------------------- | ----------------------------------------------------- | ------------------------- | -| #Preventive | #Confidentiality #Integrity #Availability | #Identify #Protect | #Legal_and_compliance #Information_security_assurance | #Governance_and_Ecosystem | - -**Control** +### Control Compliance with the organization’s information security policy, topic-specific policies, rules and standards should be regularly reviewed. -**Purpose** +### Purpose To ensure that information security is implemented and operated in accordance with the organization’s information security policy, topic-specific policies, rules and standards. -**Guidance** +### Guidance Managers, service, product or information owners should identify how to review that information security requirements defined in the information security policy, topic-specific policies, rules, standards and other applicable regulations are met. Automatic measurement and reporting tools should be considered for efficient regular review. If any non-compliance is found as a result of the review, managers should: @@ -27,5 +50,5 @@ Results of reviews and corrective actions carried out by managers, service, prod Corrective actions should be completed in a timely manner as appropriate to the risk. If not completed by the next scheduled review, progress should at least be addressed at that review. -**Other information** +### Other information Operational monitoring of system use is covered in 8.15, 8.16, 8.17. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-5.37-Documented-operating-procedures.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-5.37-Documented-operating-procedures.md index 141da41..2ea3c96 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-5.37-Documented-operating-procedures.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-5.37-Documented-operating-procedures.md @@ -1,18 +1,51 @@ - +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.5.37" +title: "Documented operating procedures" +theme: Organizational +control_type: + - Preventive + - Corrective +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: + - Protect + - Recover +operational_capabilities: + - Asset_management + - Physical_security + - System_and_network_security + - Application_security + - Secure_configuration + - Identity_and_access_management + - Threat_and_vulnerability_management + - Continuity + - Information_security_event_management +security_domains: + - Governance_and_Ecosystem + - Protection + - Defence +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- ## 5.37 Documented operating procedures -| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | -| ----------------------- | ----------------------------------------- | ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------- | -| #Preventive #Corrective | #Confidentiality #Integrity #Availability | #Protect #Recover | #Asset_management #Physical_security #System_and_network_security #Application_security #Secure_configuration #Identity_and_access_management #Threat_and_vulnerability_management #Continuity #Information_security_event_management | #Governance_and_Ecosystem #Protection #Defence | - -**Control** +### Control Operating procedures for information processing facilities should be documented and made available to personnel who need them. -**Purpose** +### Purpose To ensure the correct and secure operation of information processing facilities. -**Guidance** +### Guidance Documented procedures should be prepared for the organization’s operational activities associated with information security, for example: a\) when the activity needs to be performed in the same way by many people; @@ -51,5 +84,5 @@ l\) maintenance instructions. Documented operating procedures should be reviewed and updated when needed. Changes to documented operating procedures should be authorized. Where technically feasible, information systems should be managed consistently, using the same procedures, tools and utilities. -**Other information** +### Other information No other information. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-5.4-Management-responsibilities.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-5.4-Management-responsibilities.md index 2f50de6..89977fb 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-5.4-Management-responsibilities.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-5.4-Management-responsibilities.md @@ -1,13 +1,35 @@ -#iso27002/2022/EN +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.5.4" +title: "Management responsibilities" +theme: Organizational +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Identify] +operational_capabilities: [Governance] +security_domains: [Governance_and_Ecosystem] +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- + ## 5.4 Management responsibilities -#### Control +### Control Management should require all personnel to apply information security in accordance with the established information security policy, topic-specific policies and procedures of the organization. -#### Purpose +### Purpose To ensure management understand their role in information security and undertake actions aiming to ensure all personnel are aware of and fulfill their information security responsibilities. -#### Guidance +### Guidance Management should demonstrate support of the information security policy, topic-specific policies, procedures and information security controls. Management responsibilities should include ensuring that personnel: @@ -28,5 +50,5 @@ g)   where practicable, are provided with a confidential channel for reporting h)   are provided with adequate resources and project planning time for implementing the organization’s security-related processes and controls. -#### Other information +### Other information No other information. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-5.5-Contact-with-authorities.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-5.5-Contact-with-authorities.md index 423a885..13cef6b 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-5.5-Contact-with-authorities.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-5.5-Contact-with-authorities.md @@ -1,18 +1,48 @@ -#iso27002/2022/EN +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.5.5" +title: "Contact with authorities" +theme: Organizational +control_type: + - Preventive + - Corrective +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: + - Identify + - Protect + - Respond + - Recover +operational_capabilities: [Governance] +security_domains: + - Defence + - Resilience +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- + ## 5.5 Contact with authorities -#### Control +### Control The organization should establish and maintain contact with relevant authorities. -#### Purpose +### Purpose To ensure appropriate flow of information takes place with respect to information security between the organization and relevant legal, regulatory and supervisory authorities. -#### Guidance +### Guidance The organization should specify when and by whom authorities (e.g. law enforcement, regulatory bodies, supervisory authorities) should be contacted and how identified information security incidents should be reported in a timely manner. Contacts with authorities should also be used to facilitate the understanding about the current and upcoming expectations of these authorities (e.g. applicable information security regulations). -#### Other information +### Other information Organizations under attack can request authorities to take action against the attack source. Maintaining such contacts can be a requirement to support information security incident management (see 5.24 to 5.28) or the contingency planning and business continuity processes (see [5.29](a-5.29-Information-security-during-disruption.md), [5.30](a-5.30-ICT-readiness-for-business-continuity.md)). Contacts with regulatory bodies are also useful to anticipate and prepare for upcoming changes in relevant laws or regulations that affect the organization. Contacts with other authorities include utilities, emergency services, electricity suppliers and health and safety \[e.g. fire departments (in connection with business continuity), telecommunication providers (in connection with line routing and availability) and water suppliers (in connection with cooling facilities for equipment)\]. diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-5.6-Contact-with-special-interest-groups.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-5.6-Contact-with-special-interest-groups.md index ad461d2..07c4661 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-5.6-Contact-with-special-interest-groups.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-5.6-Contact-with-special-interest-groups.md @@ -1,13 +1,40 @@ -#iso27002/2022/EN +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.5.6" +title: "Contact with special interest groups" +theme: Organizational +control_type: + - Preventive + - Corrective +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: + - Protect + - Respond + - Recover +operational_capabilities: [Governance] +security_domains: [Defence] +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- + ## 5.6 Contact with special interest groups -#### Control +### Control The organization should establish and maintain contact with special interest groups or other specialist security forums and professional associations. -#### Purpose +### Purpose To ensure appropriate flow of information takes place with respect to information security. -#### Guidance +### Guidance Membership of special interest groups or forums should be considered as a means to: @@ -24,5 +51,5 @@ e)   share  and  exchange  information  about  new  technologies,  produ f)   provide suitable liaison points when dealing with information security incidents (see 5.24 to 5.28). -#### Other information +### Other information No other information. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-5.7-Threat-intelligence.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-5.7-Threat-intelligence.md index 538e7c8..b21bede 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-5.7-Threat-intelligence.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-5.7-Threat-intelligence.md @@ -1,13 +1,43 @@ -#iso27002/2022/EN +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.5.7" +title: "Threat intelligence" +theme: Organizational +control_type: + - Preventive + - Detective + - Corrective +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: + - Identify + - Detect + - Respond +operational_capabilities: [Threat_and_vulnerability_management] +security_domains: + - Defence + - Resilience +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- + ## 5.7 Threat intelligence -#### Control +### Control Information relating to information security threats should be collected and analysed to produce threat intelligence. -#### Purpose +### Purpose To provide awareness of the organization’s threat environment so that the appropriate mitigation actions can be taken. -#### Guidance +### Guidance Information about existing or emerging threats is collected and analysed in order to: a)  facilitate informed actions to prevent the threats from causing harm to the organization; diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-5.8-Information-security-in-project-management.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-5.8-Information-security-in-project-management.md index 1cded2c..fb36120 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-5.8-Information-security-in-project-management.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-5.8-Information-security-in-project-management.md @@ -1,13 +1,39 @@ -#iso27002/2022/EN +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.5.8" +title: "Information security in project management" +theme: Organizational +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: + - Identify + - Protect +operational_capabilities: [Governance] +security_domains: + - Governance_and_Ecosystem + - Protection +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- + ## 5.8 Information security in project management -#### Control +### Control Information security should be integrated into project management. -#### Purpose +### Purpose To ensure information security risks related to projects and deliverables are effectively addressed in project management throughout the project life cycle. -#### Guidance +### Guidance Information security should be integrated into project management to ensure information security risks are addressed as part of the project management. This can be applied to any type of project regardless of its complexity, size, duration, discipline or application area (e.g. a project for a core business process, ICT, facility management or other supporting processes). The project management in use should require that: @@ -46,7 +72,7 @@ h)   compliance with the legal, statutory, regulatory and contractual environme i) level of confidence or assurance required for third parties to meet the organization’s information security policy and topic-specific policies including relevant security clauses in any agreements or contracts. -#### Other information +### Other information The project development approach, such as waterfall life cycle or agile life cycle, should support information security in a structured way that can be adapted to suit the assessed severity of the information security risks, based on the character of the project. Early consideration of information security requirements for the product or service (e.g. at the planning and design stages), can lead to more effective and cost-efficient solutions for quality and information security. ISO 21500 and ISO 21502 provide guidance on concepts and processes of project management that are important for the performance of projects. ISO/IEC 27005 provides guidance on the use of risk management processes to identify controls to meet information security requirements. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-5.9-Inventory-of-information-and-other-associated-assets.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-5.9-Inventory-of-information-and-other-associated-assets.md index 8168224..16f1d51 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-5.9-Inventory-of-information-and-other-associated-assets.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-5.9-Inventory-of-information-and-other-associated-assets.md @@ -1,18 +1,37 @@ -#iso27002/2022/EN +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.5.9" +title: "Inventory of information and other associated assets" +theme: Organizational +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Identify] +operational_capabilities: [Asset_management] +security_domains: + - Governance_and_Ecosystem + - Protection +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- ## 5.9 Inventory of information and other associated assets -| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | -|--------------|----------------------------------------|-----------------------|-------------------------|-----------------------------------| -| #Preventive | #Confidentiality #Integrity #Availability | #Identify | #Asset_management | #Governance_and_Ecosystem #Protection | - -**Control** +### Control An inventory of information and other associated assets, including owners, should be developed and maintained. -**Purpose** +### Purpose To identify the organization’s information and other associated assets in order to preserve their information security and assign appropriate ownership. -**Guidance** +### Guidance <u>Inventory</u> The organization should identify its information and other associated assets and determine their importance in terms of information security. Documentation should be maintained in dedicated or existing inventories as appropriate. @@ -55,7 +74,7 @@ h\) they are involved in the identification and management of risks associated w i\) they support personnel who have the roles and responsibilities of managing their information. -**Other information** +### Other information Inventories of information and other associated assets are often necessary to ensure the effective protection of information and can be required for other purposes, such as health and safety, insurance or financial reasons. Inventories of information and other associated assets also support risk management, audit activities, vulnerability management, incident response and recovery planning. Tasks and responsibilities can be delegated (e.g. to a custodian looking after the assets on a daily basis), but the person or group who delegated them remains accountable. diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-6.1-Screening.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-6.1-Screening.md index 640bc60..bd8f9e3 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-6.1-Screening.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-6.1-Screening.md @@ -1,20 +1,35 @@ -# Control 6.1 Screening - - +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.6.1" +title: "Screening" +theme: People +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: [Human_resource_security] +security_domains: [Governance_and_Ecosystem] +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- ## 6.1 Screening -| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | -| ---------------- | ----------------------------------------- | -------------------------- | ---------------------------- | ------------------------- | -| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Human_resource_security | #Governance_and_Ecosystem | - -**Control** +### Control Background verification checks on all candidates to become personnel should be carried out prior to joining the organization and on an ongoing basis taking into consideration applicable laws, regulations and ethics and be proportional to the business requirements, the classification of the information to be accessed and the perceived risks. -**Purpose** +### Purpose To ensure all personnel are eligible and suitable for the roles for which they are considered and remain eligible and suitable during their employment. -**Guidance** +### Guidance A screening process should be performed for all personnel including full-time, part-time and temporary staff. Where these individuals are contracted through suppliers of services, screening requirements should be included in the contractual agreements between the organization and the suppliers. Information on all candidates being considered for positions within the organization should be collected and handled taking into consideration any appropriate legislation existing in the relevant jurisdiction. In some jurisdictions, the organization can be legally required to inform the candidates beforehand about the screening activities. @@ -44,5 +59,5 @@ d\) termination of employment. Verification checks should be repeated periodically to confirm ongoing suitability of personnel, depending on the criticality of a person’s role. -**Other information** +### Other information No other information. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-6.2-Terms-and-conditions-of-employment.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-6.2-Terms-and-conditions-of-employment.md index 5583450..24f2a5b 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-6.2-Terms-and-conditions-of-employment.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-6.2-Terms-and-conditions-of-employment.md @@ -1,16 +1,35 @@ +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.6.2" +title: "Terms and conditions of employment" +theme: People +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: [Human_resource_security] +security_domains: [Governance_and_Ecosystem] +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- + ## 6.2 Terms and conditions of employment -| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | -| ---------------- | ----------------------------------------- | -------------------------- | ---------------------------- | ------------------------- | -| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Human_resource_security | #Governance_and_Ecosystem | - -**Control** +### Control The employment contractual agreements should state the personnel’s and the organization’s responsibilities for information security. -**Purpose** +### Purpose To ensure personnel understand their information security responsibilities for the roles for which they are considered. -**Guidance** +### Guidance The contractual obligations for personnel should take into consideration the organization’s information security policy and relevant topic-specific policies. In addition, the following points can be clarified and stated: a\) confidentiality or non-disclosure agreements that personnel who are given access to confidential information should sign prior to being given access to information and other associated assets (see [6.6](a-6.6-Confidentiality-or-non-disclosure-agreements.md)); @@ -29,7 +48,7 @@ The organization should ensure that personnel agree to terms and conditions conc Where appropriate, responsibilities contained within the terms and conditions of employment should continue for a defined period after the end of the employment (see [6.5](a-6.5-Responsibilities-after-termination-or-change-of-employment.md)). -**Other information** +### Other information A code of conduct can be used to state personnel’s information security responsibilities regarding confidentiality, PII protection, ethics, appropriate use of the organization’s information and other associated assets, as well as reputable practices expected by the organization. diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-6.3-Information-security-awareness-education-and-training.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-6.3-Information-security-awareness-education-and-training.md index 5994f8f..9a8ccb1 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-6.3-Information-security-awareness-education-and-training.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-6.3-Information-security-awareness-education-and-training.md @@ -1,20 +1,35 @@ -#iso27002/2022/EN +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.6.3" +title: "Information security awareness, education and training" +theme: People +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: [Human_resource_security] +security_domains: [Governance_and_Ecosystem] +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- ## 6.3 Information security awareness, education and training -| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | -| ---------------- | ----------------------------------------- | -------------------------- | ---------------------------- | ------------------------- | -| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Human_resource_security | #Governance_and_Ecosystem | - - - -**Control** +### Control Personnel of the organization and relevant interested parties should receive appropriate information security awareness, education and training and regular updates of the organization's information security policy, topic-specific policies and procedures, as relevant for their job function. -**Purpose** +### Purpose To ensure personnel and relevant interested parties are aware of and fullfil their information security responsibilities. -**Guidance** +### Guidance <u>General</u> An information security awareness, education and training programme should be established in line with the organization’s information security policy, topic-specific policies and relevant procedures on information security, taking into consideration the organization’s information to be protected and the information security controls that have been implemented to protect the information. @@ -66,7 +81,7 @@ The education and training programme should consider different forms \[e.g. lect -**Other information** +### Other information When composing an awareness programme, it is important not only to focus on the ’what’ and ’how’, but also the ’why’, when possible. It is important that personnel understand the aim of information security and the potential effect, positive and negativ e, on the organization of their own behaviour. diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-6.4-Disciplinary-process.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-6.4-Disciplinary-process.md index b2f1db0..c39b460 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-6.4-Disciplinary-process.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-6.4-Disciplinary-process.md @@ -1,16 +1,35 @@ +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.6.4" +title: "Disciplinary process" +theme: People +control_type: + - Preventive + - Corrective +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: + - Protect + - Respond +operational_capabilities: [Human_resource_security] +security_domains: [Governance_and_Ecosystem] +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- + ## 6.4 Disciplinary process -| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | - -|----------------------------|-----------------------------------------|---------------------------|-------------------------------|-----------------------------| - -| #Preventive #Corrective | #Confidentiality #Integrity #Availability | #Protect #Respond | #Human_resource_security | #Governance_and_Ecosystem | - - - -**Control** +### Control @@ -18,7 +37,7 @@ A disciplinary process should be formalized and communicated to take actions aga -**Purpose** +### Purpose @@ -26,7 +45,7 @@ To ensure personnel and other relevant interested parties understand the consequ -**Guidance** +### Guidance @@ -58,7 +77,7 @@ The response should take into consideration relevant legal, statutory, regulator -**Other information** +### Other information diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-6.5-Responsibilities-after-termination-or-change-of-employment.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-6.5-Responsibilities-after-termination-or-change-of-employment.md index 172277d..9d69dc9 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-6.5-Responsibilities-after-termination-or-change-of-employment.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-6.5-Responsibilities-after-termination-or-change-of-employment.md @@ -1,18 +1,37 @@ - +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.6.5" +title: "Responsibilities after termination or change of employment" +theme: People +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: + - Human_resource_security + - Asset_management +security_domains: [Governance_and_Ecosystem] +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- ## 6.5 Responsibilities after termination or change of employment -| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | -| ---------------- | ----------------------------------------- | -------------------------- | ---------------------------- | -------------------- | -| #Preventive | #Confidentiality #Integrity #Availability | | | | - -**Control** +### Control Information security responsibilities and duties that remain valid after termination or change of employment should be defined, enforced and communicated to relevant personnel and other interested parties. -**Purpose** +### Purpose To protect the organization’s interests as part of the process of changing or terminating employment or contracts. -**Guidance** +### Guidance The process for managing termination or change of employment should define which information security responsibilities and duties should remain valid after termination or change. This can include confidentiality of information, intellectual property and other knowledge obtained, as well as responsibilities contained within any other confidentiality agreement (see [6.6](a-6.6-Confidentiality-or-non-disclosure-agreements.md)). Responsibilities and duties still valid after termination of employment or contract should be contained in the individual’s terms and conditions of employment (see [6.2](a-6.2-Terms-and-conditions-of-employment.md)), contract or agreement. Other contracts or agreements that continue for a defined period after the end of the individual’s employment can also contain information security responsibilities. Changes of responsibility or employment should be managed as the termination of the current responsibility or employment combined with the initiation of the new responsibility or employment. @@ -23,5 +42,5 @@ A process should be established for the communication of the changes and of oper The process for the termination or change of employment should also be applied to external personnel (i.e. suppliers) when a termination occurs of personnel, the contract or the job with the organization, or when there is a change of the job within the organization. -**Other information** +### Other information In many organizations, the human resources function is generally responsible for the overall termination process and works together with the supervising manager of the person transitioning to manage the information security aspects of the relevant procedures. In the case of personnel provided through an external party (e.g. through a supplier), this termination process is undertaken by the external party in accordance with the contract between the organization and the external party. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-6.6-Confidentiality-or-non-disclosure-agreements.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-6.6-Confidentiality-or-non-disclosure-agreements.md index b669405..2e0d8c6 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-6.6-Confidentiality-or-non-disclosure-agreements.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-6.6-Confidentiality-or-non-disclosure-agreements.md @@ -1,24 +1,37 @@ - +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.6.6" +title: "Confidentiality or non-disclosure agreements" +theme: People +control_type: [Preventive] +information_security_properties: [Confidentiality] +cybersecurity_concepts: [Protect] +operational_capabilities: + - Human_resource_security + - Information_protection + - Supplier_relationships_security +security_domains: [Governance_and_Ecosystem] +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- ## 6.6 Confidentiality or non-disclosure agreements -| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | - -|------------------|------------------------------------|---------------------------|-------------------------------------------------------------|-------------------------------| - -| #Preventive | #Confidentiality | #Protect | #Human_resource_security #Information_protection #Supplier_relationships | #Governance_and_Ecosystem | - - - -**Control** +### Control Confidentiality or non-disclosure agreements reflecting the organization’s needs for the protection of information should be identified, documented, regularly reviewed and signed by personnel and other relevant interested parties. -**Purpose** +### Purpose @@ -26,7 +39,7 @@ To maintain confidentiality of information accessible by personnel or external p -**Guidance** +### Guidance @@ -82,7 +95,7 @@ Requirements for confidentiality and non-disclosure agreements should be reviewe -**Other information** +### Other information diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-6.7-Remote-working.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-6.7-Remote-working.md index 289fc7c..9d8f4be 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-6.7-Remote-working.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-6.7-Remote-working.md @@ -1,16 +1,35 @@ +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.6.7" +title: "Remote working" +theme: People +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: + - Asset_management + - Information_protection + - Physical_security + - System_and_network_security +security_domains: [Protection] +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- + ## 6.7 Remote working -| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | - -|------------------|-----------------------------------------|---------------------------|--------------------------------------------------------------------------------|---------------------| - -| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Asset_management #Information_protection #Physical_security #System_and_network_security | #Protection | - - - -**Control** +### Control @@ -18,7 +37,7 @@ Security measures should be implemented when personnel are working remotely to p -**Purpose** +### Purpose @@ -26,7 +45,7 @@ To ensure the security of information when personnel are working remotely. -**Guidance** +### Guidance diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-6.8-Information-security-event-reporting.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-6.8-Information-security-event-reporting.md index 0b00a6c..eb5001c 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-6.8-Information-security-event-reporting.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-6.8-Information-security-event-reporting.md @@ -1,18 +1,30 @@ - +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.6.8" +title: "Information security event reporting" +theme: People +control_type: [Detective] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Detect] +operational_capabilities: [Information_security_event_management] +security_domains: [Defence] +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- ## 6.8 Information security event reporting - -| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | - -|------------------|-----------------------------------------|---------------------------|---------------------------------------------|---------------------| - -| #Detective | #Confidentiality #Integrity #Availability | #Detect | #Information_security_event_management | #Defence | - - - -**Control** +### Control @@ -20,7 +32,7 @@ The organization should provide a mechanism for personnel to report observed or -**Purpose** +### Purpose @@ -28,7 +40,7 @@ To support timely, consistent and effective reporting of information security ev -**Guidance** +### Guidance @@ -88,7 +100,7 @@ Personnel and users should be advised not to attempt to prove suspected informat -**Other information** +### Other information diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-7.1-Physical-security-perimeters.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-7.1-Physical-security-perimeters.md index 216097e..e7d281f 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-7.1-Physical-security-perimeters.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-7.1-Physical-security-perimeters.md @@ -1,22 +1,38 @@ - - +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.7.1" +title: "Physical security perimeters" +theme: Physical +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: [Physical_security] +security_domains: [Protection] +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- ## 7.1 Physical security perimeters -| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | -|------------------|-----------------------------------------|---------------------------|-----------------------------------|---------------------| -| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Physical_security | - -**Control** +### Control Security perimeters should be defined and used to protect areas that contain information and other associated assets. -**Purpose** +### Purpose To prevent unauthorized physical access, damage and interference to the organization’s information and other associated assets. -**Guidance** +### Guidance @@ -36,7 +52,7 @@ c\) alarming, monitoring and testing all fire doors on a security perimeter in c -**Other information** +### Other information Physical protection can be achieved by creating one or more physical barriers around the organization’s premises and information processing facilities. A secure area can be a lockable office or several rooms surrounded by a continuous internal physical security barrier. Additional barriers and perimeters to control physical access can be necessary between areas with different security requirements inside the security perimeter. The organization should consider having physical security measures that can be strengthened during increased threat situations. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-7.10-Storage-media.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-7.10-Storage-media.md index a22aea1..cee88d6 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-7.10-Storage-media.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-7.10-Storage-media.md @@ -1,16 +1,33 @@ +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.7.10" +title: "Storage media" +theme: Physical +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: + - Physical_security + - Asset_management +security_domains: [Protection] +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- + ## 7.10 Storage media -| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | - -|------------------|-----------------------------------------|---------------------------|---------------------------------------------|---------------------| - -| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Physical_security #Asset_management | #Protection | - - - -**Control** +### Control @@ -18,7 +35,7 @@ Storage media should be managed through their life cycle of acquisition, use, tr -**Purpose** +### Purpose @@ -26,7 +43,7 @@ To ensure only authorized disclosure, modification, removal or destruction of in -**Guidance** +### Guidance @@ -118,6 +135,6 @@ A risk assessment should be performed on damaged devices containing sensitive da -**Other information** +### Other information When confidential information on storage media is not encrypted, additional physical protection of the storage media should be considered. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-7.11-Supporting-utilities.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-7.11-Supporting-utilities.md index 3ee2bd9..303920f 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-7.11-Supporting-utilities.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-7.11-Supporting-utilities.md @@ -1,16 +1,34 @@ +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.7.11" +title: "Supporting utilities" +theme: Physical +control_type: + - Preventive + - Detective +information_security_properties: + - Integrity + - Availability +cybersecurity_concepts: + - Protect + - Detect +operational_capabilities: [Physical_security] +security_domains: [Protection] +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- + ## 7.11 Supporting utilities -| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | - -|-----------------------|------------------------------------|---------------------------|-----------------------------|----------------------| - -| #Preventive<br>#Detective | #Integrity<br>#Availability | #Protect #Detect | #Physical_security | #Protection | - - - -**Control** +### Control @@ -18,7 +36,7 @@ Information processing facilities should be protected from power failures and ot -**Purpose** +### Purpose @@ -26,7 +44,7 @@ To prevent loss, damage or compromise of information and other associated assets -**Guidance** +### Guidance @@ -66,7 +84,7 @@ Emergency lighting and communications should be provided. Emergency switches and -**Other information** +### Other information diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-7.12-Cabling-security.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-7.12-Cabling-security.md index 26f7384..92336c0 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-7.12-Cabling-security.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-7.12-Cabling-security.md @@ -1,16 +1,30 @@ +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.7.12" +title: "Cabling security" +theme: Physical +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: [Physical_security] +security_domains: [Protection] +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- + ## 7.12 Cabling security -| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | - -|------------------|------------------------------------|---------------------------|-----------------------------|----------------------| - -| #Preventive | #Confidentiality #Availability | #Protect | #Physical_security | #Protection | - - - -**Control** +### Control @@ -18,7 +32,7 @@ Cables carrying power, data or supporting information services should be protect -**Purpose** +### Purpose @@ -26,7 +40,7 @@ To prevent loss, damage, theft or compromise of information and other associated -**Guidance** +### Guidance @@ -74,7 +88,7 @@ Specialist advice should be sought on how to manage risks arising from cabling i -**Other information** +### Other information diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-7.13-Equipment-maintenance.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-7.13-Equipment-maintenance.md index 2f16d29..346eda3 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-7.13-Equipment-maintenance.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-7.13-Equipment-maintenance.md @@ -1,16 +1,35 @@ +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.7.13" +title: "Equipment maintenance" +theme: Physical +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: + - Physical_security + - Asset_management +security_domains: + - Protection + - Resilience +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- + ## 7.13 Equipment maintenance -| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | - -|------------------|-----------------------------------------|---------------------------|----------------------------------------|---------------------------| - -| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Physical_security #Asset_management | #Protection #Resilience | - - - -**Control** +### Control @@ -18,7 +37,7 @@ Equipment should be maintained correctly to ensure availability, integrity and c -**Purpose** +### Purpose @@ -26,7 +45,7 @@ To prevent loss, damage, theft or compromise of information and other associated -**Guidance** +### Guidance @@ -78,7 +97,7 @@ k\) applying measures for secure disposal or re-use of equipment (see [7.14](a-7 -**Other information** +### Other information diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-7.14-Secure-disposal-or-re-use-of-equipment.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-7.14-Secure-disposal-or-re-use-of-equipment.md index c3867ad..192b0e3 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-7.14-Secure-disposal-or-re-use-of-equipment.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-7.14-Secure-disposal-or-re-use-of-equipment.md @@ -1,16 +1,30 @@ +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.7.14" +title: "Secure disposal or re-use of equipment" +theme: Physical +control_type: [Preventive] +information_security_properties: [Confidentiality] +cybersecurity_concepts: [Protect] +operational_capabilities: + - Physical_security + - Asset_management +security_domains: [Protection] +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- + ## 7.14 Secure disposal or re-use of equipment -| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | - -|------------------|------------------------------------|---------------------------|----------------------------------------|---------------------------| - -| #Preventive | #Confidentiality | #Protect | #Physical_security #Asset_management | #Protection | - - - -**Control** +### Control @@ -18,7 +32,7 @@ Items of equipment containing storage media should be verified to ensure that an -**Purpose** +### Purpose @@ -54,7 +68,7 @@ c\) the ability to reuse the controls at the next facility. -**Other information** +### Other information diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-7.2-Physical-entry.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-7.2-Physical-entry.md index 0208a84..f71a8ba 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-7.2-Physical-entry.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-7.2-Physical-entry.md @@ -1,16 +1,33 @@ +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.7.2" +title: "Physical entry" +theme: Physical +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: + - Physical_security + - Identity_and_access_management +security_domains: [Protection] +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- + ## 7.2 Physical entry - -| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | -|------------------|-----------------------------------------|---------------------------|-----------------------------------------------------|---------------------| - -| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Physical_security #Identity_and_Access - - - -**Control** +### Control @@ -18,7 +35,7 @@ Secure areas should be protected by appropriate entry controls and access points -**Purpose** +### Purpose @@ -26,7 +43,7 @@ To ensure only authorized physical access to the organization’s information an -**Guidance** +### Guidance @@ -146,6 +163,6 @@ g\) inspecting incoming deliveries for evidence of tampering on the way. If tamp -**Other information** +### Other information No other information. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-7.3-Securing-offices-rooms-and-facilities.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-7.3-Securing-offices-rooms-and-facilities.md index 3868b43..3260fa2 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-7.3-Securing-offices-rooms-and-facilities.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-7.3-Securing-offices-rooms-and-facilities.md @@ -1,18 +1,33 @@ - +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.7.3" +title: "Securing offices, rooms and facilities" +theme: Physical +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: + - Physical_security + - Asset_management +security_domains: [Protection] +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- ## 7.3 Securing offices, rooms and facilities -| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | - -|------------------|-----------------------------------------|---------------------------|--------------------------------------|---------------------| - -| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Physical_security<br>#Asset_management | #Protection | - - - -**Control** +### Control @@ -24,7 +39,7 @@ To prevent unauthorized physical access, damage and interference to the organiza -**Guidance** +### Guidance @@ -48,6 +63,6 @@ d\) not making directories, internal telephone books and online accessible maps -**Other information** +### Other information No other information. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-7.4-Physical-security-monitoring.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-7.4-Physical-security-monitoring.md index bec1efd..401de2d 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-7.4-Physical-security-monitoring.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-7.4-Physical-security-monitoring.md @@ -1,18 +1,37 @@ - +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.7.4" +title: "Physical security monitoring" +theme: Physical +control_type: + - Preventive + - Detective +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: + - Protect + - Detect +operational_capabilities: [Physical_security] +security_domains: + - Protection + - Defence +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- ## 7.4 Physical security monitoring -| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | - -|----------------------------|-----------------------------------------|---------------------------|-----------------------------|---------------------------| - -| #Preventive #Detective | #Confidentiality #Integrity #Availability | #Protect #Detect | #Physical_security | #Protection #Defence | - - - -**Control** +### Control @@ -20,7 +39,7 @@ Premises should be continuously monitored for unauthorized physical access. -**Purpose** +### Purpose @@ -28,7 +47,7 @@ To detect and deter unauthorized physical access. -**Guidance** +### Guidance @@ -80,6 +99,6 @@ Any monitoring and recording mechanism should be used taking into consideration -**Other information** +### Other information No other information. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-7.5-Protecting-against-physical-and-environmental-threats.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-7.5-Protecting-against-physical-and-environmental-threats.md index b20093b..fc95cdf 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-7.5-Protecting-against-physical-and-environmental-threats.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-7.5-Protecting-against-physical-and-environmental-threats.md @@ -1,16 +1,31 @@ +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.7.5" +title: "Protecting against physical and environmental threats" +theme: Physical +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: [Physical_security] +security_domains: [Protection] +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- + ## 7.5 Protecting against physical and environmental threats -| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | - -|------------------|-----------------------------------------|---------------------------|-----------------------------|----------------------| - -| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Physical_security | #Protection | - - - -**Control** +### Control @@ -18,7 +33,7 @@ Protection against physical and environmental threats, such as natural disasters -**Purpose** +### Purpose @@ -62,7 +77,7 @@ d\) explosives and weapons: performing random inspections for the presence of ex -**Other information** +### Other information diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-7.6-Working-in-secure-areas.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-7.6-Working-in-secure-areas.md index 4cc388d..9da475f 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-7.6-Working-in-secure-areas.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-7.6-Working-in-secure-areas.md @@ -1,22 +1,37 @@ +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.7.6" +title: "Working in secure areas" +theme: Physical +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: [Physical_security] +security_domains: [Protection] +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- + ## 7.6 Working in secure areas -| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | - -|------------------|-----------------------------------------|---------------------------|-----------------------------|----------------------| - -| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Physical_security | #Protection | - - - -**Control** +### Control Security measures for working in secure areas should be designed and implemented. -**Purpose** +### Purpose @@ -24,7 +39,7 @@ To protect information and other associated assets in secure areas from damage a -**Guidance** +### Guidance @@ -60,6 +75,6 @@ f\) posting emergency procedures in a readily visible or accessible manner. -**Other information** +### Other information No other information. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-7.7-Clear-desk-and-clear-screen.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-7.7-Clear-desk-and-clear-screen.md index 04aa36a..b692108 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-7.7-Clear-desk-and-clear-screen.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-7.7-Clear-desk-and-clear-screen.md @@ -1,14 +1,28 @@ +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.7.7" +title: "Clear desk and clear screen" +theme: Physical +control_type: [Preventive] +information_security_properties: [Confidentiality] +cybersecurity_concepts: [Protect] +operational_capabilities: [Physical_security] +security_domains: [Protection] +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- + ## 7.7 Clear desk and clear screen -| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | - -|------------------|------------------------------------|---------------------------|-----------------------------|----------------------| - -| #Preventive | #Confidentiality | #Protect | #Physical_security | #Protection | - -**Control** +### Control @@ -16,7 +30,7 @@ Clear desk rules for papers and removable storage media and clear screen rules f -**Purpose** +### Purpose @@ -24,7 +38,7 @@ To reduce the risks of unauthorized access, loss of and damage to information on -**Guidance** +### Guidance @@ -68,6 +82,6 @@ The organization should have procedures in place when vacating facilities includ -**Other information** +### Other information No other information. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-7.8-Equipment-siting-and-protection.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-7.8-Equipment-siting-and-protection.md index 0f5874a..3236785 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-7.8-Equipment-siting-and-protection.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-7.8-Equipment-siting-and-protection.md @@ -1,16 +1,33 @@ +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.7.8" +title: "Equipment siting and protection" +theme: Physical +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: + - Physical_security + - Asset_management +security_domains: [Protection] +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- + ## 7.8 Equipment siting and protection -| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | - -|------------------|-----------------------------------------|---------------------------|----------------------------------------|---------------------| - -| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Physical_security #Asset_management | #Protection | - - - -**Control** +### Control @@ -18,7 +35,7 @@ Equipment should be sited securely and protected. -**Purpose** +### Purpose @@ -26,7 +43,7 @@ To reduce the risks from physical and environmental threats, and from unauthoriz -**Guidance** +### Guidance @@ -70,6 +87,6 @@ i\) physically separating information processing facilities managed by the organ -**Other information** +### Other information No other information. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-7.9-Security-of-assets-off-premises.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-7.9-Security-of-assets-off-premises.md index 79afda5..074ebe4 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-7.9-Security-of-assets-off-premises.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-7.9-Security-of-assets-off-premises.md @@ -1,14 +1,33 @@ +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.7.9" +title: "Security of assets off-premises" +theme: Physical +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: + - Physical_security + - Asset_management +security_domains: [Protection] +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- + ## 7.9 Security of assets off-premises -| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | - -|------------------|-----------------------------------------|---------------------------|----------------------------------------|---------------------| - -| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Physical_security #Asset_management | #Protection | - -**Control** +### Control @@ -20,7 +39,7 @@ To prevent loss, damage, theft or compromise of off-site devices and interruptio -**Guidance** +### Guidance @@ -76,7 +95,7 @@ d\) logical access controls. -**Other information** +### Other information diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-8.1-User-endpoint-devices.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-8.1-User-endpoint-devices.md index a5a364b..9892a0f 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-8.1-User-endpoint-devices.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-8.1-User-endpoint-devices.md @@ -1,18 +1,39 @@ +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.8.1" +title: "User endpoint devices" +theme: Technological +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: + - Asset_management + - Information_protection +security_domains: [Protection] +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- + ## 8.1 User endpoint devices -| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | -| -------------- | ---------------------------------------- | --------------------- | ----------------------------------------- | --------------- | -| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Asset_management<br>#Information_protection | #Protection | - -**Control** +### Control Information stored on, processed by or accessible via user endpoint devices should be protected. -**Purpose** +### Purpose To protect information against the risks introduced by using user endpoint devices. -**Guidance** +### Guidance <u>General</u> @@ -65,7 +86,7 @@ The organization should establish procedures for: a\) the configuration of wireless connections on devices (e.g. disabling vulnerable protocols); b\) using wireless or wired connections with appropriate bandwidth in accordance with relevant topic-specific policies (e.g. because backups or software updates are needed). -**Other information** +### Other information Controls to protect information on user endpoint devices depend on whether the user endpoint device is used only inside of the organization's secured premises and network connections, or whether it is exposed to increased physical and network related threats outside of the organization. The wireless connections for user endpoint devices are similar to other types of network connections but have important differences that should be considered when identifying controls. In particular, back-up of information stored on user endpoint devices can sometimes fail because of limited network bandwidth or because user endpoint devices are not connected at the times when backups are scheduled. diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-8.10-Information-deletion.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-8.10-Information-deletion.md index edf72c5..c2ce872 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-8.10-Information-deletion.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-8.10-Information-deletion.md @@ -1,16 +1,34 @@ +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.8.10" +title: "Information deletion" +theme: Technological +control_type: [Preventive] +information_security_properties: [Confidentiality] +cybersecurity_concepts: [Protect] +operational_capabilities: + - Information_protection + - Legal_and_compliance +security_domains: [Protection] +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- + ## 8.10 Information deletion -| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | -| ---------------- | ----------------------------------- | -------------------------- | --------------------------------------------- | -------------------- | -| #Preventive | #Confidentiality | #Protect | #Information_protection #Legal_and_compliance | #Protection | - -**Control** +### Control Information stored in information systems, devices or in any other storage media should be deleted when no longer required. -**Purpose** +### Purpose To prevent unnecessary exposure of sensitive information and to comply with legal, statutory, regulatory and contractual requirements for information deletion. -**Guidance** +### Guidance <u>General</u> Sensitive information should not be kept for longer than it is required to reduce the risk of undesirable disclosure. @@ -48,5 +66,5 @@ Control measures described in 7.14 should be applied to physically destroy the s An official record of information deletion is useful when analysing the cause of a possible information leakage event. -**Other information** +### Other information Information on user data deletion in cloud services can be found in ISO/IEC 27017. Information on deletion of PII can be found in ISO/IEC 27555. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-8.11-Data-masking.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-8.11-Data-masking.md index a09772a..4aeaf54 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-8.11-Data-masking.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-8.11-Data-masking.md @@ -1,16 +1,32 @@ +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.8.11" +title: "Data masking" +theme: Technological +control_type: [Preventive] +information_security_properties: [Confidentiality] +cybersecurity_concepts: [Protect] +operational_capabilities: [Information_protection] +security_domains: [Protection] +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- + ## 8.11 Data masking -| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | -| ---------------- | ----------------------------------- | -------------------------- | ---------------------------- | -------------------- | -| #Preventive | #Confidentiality | #Protect | #Information_protection | #Protection | - -**Control** +### Control Data masking should be used in accordance with the organization’s topic-specific policy on access control and other related topic-specific policies, and business requirements, taking applicable legislation into consideration. -**Purpose** +### Purpose To limit the exposure of sensitive data including PII, and to comply with legal, statutory, regulatory and contractual requirements. -**Guidance** +### Guidance Where the protection of sensitive data (e.g. PII) is a concern, the organization should consider hiding such data by using techniques such as data masking, pseudonymization or anonymization. Pseudonymization or anonymization techniques can hide PII, disguise the true identity of PII principals or other sensitive information, and disconnect the link between PII and the identity of the PII principal or the link between other sensitive information. @@ -40,7 +56,7 @@ c\) agreements or restrictions on usage of the processed data; d\) prohibiting collating the processed data with other information in order to identify the PII principal; e\) keeping track of providing and receiving the processed data. -**Other information** +### Other information Anonymization irreversibly alters PII in such a way that the PII principal can no longer be identified directly or indirectly. Pseudonymization replaces the identifying information with an alias. Knowledge of the algorithm (sometimes referred to as the “additional information”) used to perform the pseudonymization allows for at least some form of identification of the PII principal. Such “additional information” should therefore be kept separate and protected. diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-8.12-Data-leakage-prevention.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-8.12-Data-leakage-prevention.md index ec2d2c2..c171100 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-8.12-Data-leakage-prevention.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-8.12-Data-leakage-prevention.md @@ -1,16 +1,38 @@ +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.8.12" +title: "Data leakage prevention" +theme: Technological +control_type: + - Preventive + - Detective +information_security_properties: [Confidentiality] +cybersecurity_concepts: + - Protect + - Detect +operational_capabilities: [Information_protection] +security_domains: + - Protection + - Defence +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- + ## 8.12 Data leakage prevention -| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | -| ---------------------- | ----------------------------------- | -------------------------- | ---------------------------- | -------------------- | -| #Preventive #Detective | #Confidentiality | #Protect #Detect | #Information_protection | #Protection #Defence | - -**Control** +### Control Data leakage prevention measures should be applied to systems, networks and any other devices that process, store or transmit sensitive information. -**Purpose** +### Purpose To detect and prevent the unauthorized disclosure and extraction of information by individuals or systems. -**Guidance** +### Guidance The organization should consider the following to reduce the risk of data leakage: a\) identifying and classifying information to protect against leakage (e.g. personal information, pricing models and product designs); @@ -33,7 +55,7 @@ Where data is backed up, care should be taken to ensure sensitive information is Data leakage prevention should also be considered to protect against the intelligence actions of an adversary from obtaining confidential or secret information (geopolitical, human, financial, commercial, scientific or any other) which can be of interest for espionage or can be critical for the community. The data le akage prevention actions should be oriented to confuse the adversary’s decisions for example by replacing authentic information with false information, either as an independent action or as response to the adversary’s intelligence actions. Examples of these kinds of actions are reverse social engineering or the use of honeypots to attract attackers. -**Other information** +### Other information Data leakage prevention tools are designed to identify data, monitor data usage and movement, and take actions to prevent data from leaking (e.g. alerting users to their risky behaviour and blocking the transfer of data to portable storage devices). Data leakage prevention inherently involves monitoring personnel’s communications and online activities, and by extension external party messages, which raises legal concerns that should be considered prior to deploying data leakage prevention tools. There is a variety of legislation relating to privacy, data protection, employment, interception of data and telecommunications that is applicable to monitoring and data processing in the context of data leakage prevention. diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-8.13-Information-backup.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-8.13-Information-backup.md index e978a2d..d44a2d6 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-8.13-Information-backup.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-8.13-Information-backup.md @@ -1,17 +1,34 @@ -#iso27002/2022/EN +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.8.13" +title: "Information backup" +theme: Technological +control_type: [Corrective] +information_security_properties: + - Integrity + - Availability +cybersecurity_concepts: [Recover] +operational_capabilities: [Continuity] +security_domains: [Protection] +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- + ## 8.13 Information backup -| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | -| ------------ | ------------------------------- | ---------------------- | ------------------------ | ---------------- | -| #Corrective | #Integrity #Availability | #Recover | #Continuity | #Protection | - -**Control** +### Control Backup copies of information, software and systems should be maintained and regularly tested in accordance with the agreed topic-specific policy on backup. -**Purpose** +### Purpose To enable recovery from loss of data or systems. -**Guidance** +### Guidance A topic-specific policy on backup should be established to address the organization’s data retention and information security requirements. Adequate backup facilities should be provided to ensure that all essential information and software can be recovered following an incident or failure or loss of storage media. @@ -42,5 +59,5 @@ When the organization uses a cloud service, backup copies of the organization’ The retention period for essential business information should be determined, taking into account any requirement for retention of archive copies. The organization should consider the deletion of information (see [8.10](a-8.10-Information-deletion.md)) in storage media used for backup once the information’s retention period expires and should take into consideration legislation and regulations. -**Other information** +### Other information For further information on storage security including retention consideration, see ISO/IEC 27040. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-8.14-Redundancy-of-information-processing-facilities.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-8.14-Redundancy-of-information-processing-facilities.md index d1266e8..90a5026 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-8.14-Redundancy-of-information-processing-facilities.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-8.14-Redundancy-of-information-processing-facilities.md @@ -1,16 +1,36 @@ +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.8.14" +title: "Redundancy of information processing facilities" +theme: Technological +control_type: [Preventive] +information_security_properties: [Availability] +cybersecurity_concepts: [Protect] +operational_capabilities: + - Continuity + - Asset_management +security_domains: + - Protection + - Resilience +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- + ## 8.14 Redundancy of information processing facilities -| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | -| ------------ | ------------------------------- | ---------------------- | ----------------------------- | ----------------------- | -| #Preventive | #Availability | #Protect | #Continuity #Asset_management | #Protection #Resilience | - -**Control** +### Control Information processing facilities should be implemented with redundancy sufficient to meet availability requirements. -**Purpose** +### Purpose To ensure the continuous operation of information processing facilities. -**Guidance** +### Guidance The organization should identify requirements for the availability of business services and information systems. The organization should design and implement systems architecture with appropriate redundancy to meet these requirements. Redundancy can be introduced by duplicating information processing facilities in part or in their entirety (i.e. spare components or having two of everything). The organization should plan and implement procedures for the activation of the redundant components and processing facilities. The procedures should establish if the redundant components and processing activities are always activated, or in case of emergency, automatically or manually activated. The redundant components and information processing facilities should ensure the same security level as the primary ones. @@ -28,7 +48,7 @@ f\) having duplicated components in systems (e.g. CPU, hard disks, memories) or Where applicable, preferably in production mode, redundant information systems should be tested to ensure the failover from one component to another component works as intended. -**Other information** +### Other information There is a strong relationship between redundancy and ICT readiness for business continuity (see [5.30](a-5.30-ICT-readiness-for-business-continuity.md)) especially if short recovery times are required. Many of the redundancy measures can be part of the ICT continuity strategies and solutions. The implementation of redundancies can introduce risks to the integrity (e.g. processes of copying data to duplicated components can introduce errors) or confidentiality (e.g. weak security control of duplicated components can lead to compromise) of information and information systems, which need to be considered when designing information systems. diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-8.15-Logging.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-8.15-Logging.md index cfdfc06..9834c45 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-8.15-Logging.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-8.15-Logging.md @@ -1,18 +1,37 @@ -#iso27002/2022/EN +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.8.15" +title: "Logging" +theme: Technological +control_type: [Detective] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Detect] +operational_capabilities: [Information_security_event_management] +security_domains: + - Protection + - Defence +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- ## 8.15 Logging -| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | -| ---------------- | ----------------------------------------- | -------------------------- | -------------------------------------- | -------------------- | -| #Detective | #Confidentiality #Integrity #Availability | #Detect | #Information_security_event_management | #Protection #Defence | - -**Control** +### Control Logs that record activities, exceptions, faults and other relevant events should be produced, stored, protected and analysed. -**Purpose** +### Purpose To record events, generate evidence, ensure the integrity of log information, prevent against unauthorized access, identify information security events that can lead to an information security incident and to support investigations. -**Guidance** +### Guidance <u>General</u> @@ -82,7 +101,7 @@ e\) correlating logs to enable efficient and highly accurate analysis. Suspected and actual information security incidents should be identified (e.g. malware infection or probing of firewalls) and be subject to further investigation (e.g. as part of an information security incident management process, see >5.25>). -**Other information** +### Other information System logs often contain a large volume of information, much of which is extraneous to information security monitoring. To help identify significant events for information security monitoring purposes, the use of suitable utility programs or audit tools to perform file interrogation can be considered. diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-8.16-Monitoring-activities.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-8.16-Monitoring-activities.md index b7d3de8..49996d1 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-8.16-Monitoring-activities.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-8.16-Monitoring-activities.md @@ -1,18 +1,39 @@ -#iso27002/2022/EN +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.8.16" +title: "Monitoring activities" +theme: Technological +control_type: + - Detective + - Corrective +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: + - Detect + - Respond +operational_capabilities: [Information_security_event_management] +security_domains: [Defence] +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- + ## 8.16 Monitoring activities -| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | -| ---------------------- | ----------------------------------------- | -------------------------- | -------------------------------------- | -------------------- | -| #Detective #Corrective | #Confidentiality #Integrity #Availability | #Detect #Respond | #Information_security_event_management | #Defence | - - -**Control** +### Control Networks, systems and applications should be monitored for anomalous behaviour and appropriate actions taken to evaluate potential information security incidents. -**Purpose** +### Purpose To detect anomalous behaviour and potential information security incidents. -**Guidance** +### Guidance The monitoring scope and level should be determined in accordance with business and information security requirements and taking into consideration relevant laws and regulations. Monitoring records should be maintained for defined retention periods. The following should be considered for inclusion within the monitoring system: diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-8.17-Clock-synchronization.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-8.17-Clock-synchronization.md index 7b5e866..3c68637 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-8.17-Clock-synchronization.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-8.17-Clock-synchronization.md @@ -1,16 +1,36 @@ +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.8.17" +title: "Clock synchronization" +theme: Technological +control_type: [Detective] +information_security_properties: [Integrity] +cybersecurity_concepts: + - Protect + - Detect +operational_capabilities: [Information_security_event_management] +security_domains: + - Protection + - Defence +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- + ## 8.17 Clock synchronization -| **Control type** | **Information security properties** | **Cybersecurity concepts** | **Operational capabilities** | **Security domains** | -| ---------------- | ----------------------------------- | -------------------------- | -------------------------------------- | -------------------- | -| #Detective | #Integrity | #Protect #Detect | #Information_security_event_management | #Protection #Defence | - -**Control** +### Control The clocks of information processing systems used by the organization should be synchronized to approved time sources. -**Purpose** +### Purpose To enable the correlation and analysis of security-related events and other recorded data, and to support investigations into information security incidents. -**Guidance** +### Guidance External and internal requirements for time representation, reliable synchronization and accuracy should be documented and implemented. Such requirements can be from legal, statutory, regulatory, contractual, standards and internal monitoring needs. A standard reference time for use within the organization should be defined and considered for all systems, including building management systems, entry and exit systems and others that can be used to aid investigations. A clock linked to a radio time broadcast from a national atomic clock or global positioning system (GPS) should be used as the reference clock for logging systems; a consistent, trusted date and time source to ensure accurate time-stamps. Protocols such as network time protocol (NTP) or precision time protocol (PTP) should be used to keep all networked systems in synchronization with a reference clock. @@ -19,5 +39,5 @@ The organization can use two external time sources at the same time in order to Clock synchronization can be difficult when using multiple cloud services or when using both cloud and on-premises services. In this case, the clock of each service should be monitored and the difference recorded in order to mitigate risks arising from discrepancies. -**Other information** +### Other information The correct setting of computer clocks is important to ensure the accuracy of event logs, which can be required for investi gations or as evidence in legal and disciplinary cases. Inaccurate audit logs can hinder such investigations and damage the credibility of such evidence. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-8.18-Use-of-privileged-utility-programs.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-8.18-Use-of-privileged-utility-programs.md index 51c226f..fe289df 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-8.18-Use-of-privileged-utility-programs.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-8.18-Use-of-privileged-utility-programs.md @@ -1,16 +1,38 @@ +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.8.18" +title: "Use of privileged utility programs" +theme: Technological +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: + - System_and_network_security + - Secure_configuration + - Application_security +security_domains: [Protection] +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- + ## 8.18 Use of privileged utility programs -| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | -| ------------ | ----------------------------------------- | ---------------------- | ------------------------------------------------------------------------ | ---------------- | -| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #System_and_network_security #Secure_configuration #Application_security | #Protection | - -**Control** +### Control The use of utility programs that can be capable of overriding system and application controls should be restricted and tightly controlled. -**Purpose** +### Purpose To ensure the use of utility programs does not harm system and application controls for information security. -**Guidance** +### Guidance The following guidelines for the use of utility programs that can be capable of overriding system and application controls should be considered: a\) limitation of the use of utility programs to the minimum practical number of trusted, authorized users (see [8.2](a-8.2-Privileged-access-rights.md)); @@ -31,6 +53,6 @@ h\) limitation of the availability of utility programs (e.g. for the duration of i\) logging of all use of utility programs. -**Other information** +### Other information Most information systems have one or more utility programs that can be capable of overriding system and application controls, for example diagnostics, patching, antivirus, disk defragmenters, debuggers, backup and network tools. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-8.19-Installation-of-software-on-operational-systems.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-8.19-Installation-of-software-on-operational-systems.md index 4282a53..b2fbffc 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-8.19-Installation-of-software-on-operational-systems.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-8.19-Installation-of-software-on-operational-systems.md @@ -1,17 +1,37 @@ -#iso27002/2022/EN +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.8.19" +title: "Installation of software on operational systems" +theme: Technological +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: + - Secure_configuration + - Application_security +security_domains: [Protection] +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- + ## 8.19 Installation of software on operational systems -| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | -| ------------ | ----------------------------------------- | ---------------------- | ------------------------------------------- | ---------------- | -| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Secure_configuration #Application_security | #Protection | - -**Control** +### Control Procedures and measures should be implemented to securely manage software installation on operational systems. -**Purpose** +### Purpose To ensure the integrity of operational systems and prevent exploitation of technical vulnerabilities. -**Guidance** +### Guidance The following guidelines should be considered to securely manage changes and installation of software on operational systems: a\) performing updates of operational software only by trained administrators upon appropriate management authorization (see [8.5](a-8.5-Secure-authentication.md)); @@ -42,5 +62,5 @@ The organization should define and enforce strict rules on which types of softwa The principle of least privilege should be applied to software installation on operational systems. The organization should identify what types of software installations are permitted (e.g. updates and security patches to existing software) and what types of installations are prohibited (e.g. software that is only for personal use and software whose pedigree with regard to being potentially malicious is unknown or suspect). These privileges should be granted based on the roles of the users concerned. -**Other information** +### Other information No other information. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-8.2-Privileged-access-rights.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-8.2-Privileged-access-rights.md index 9cbe003..ec3ab9b 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-8.2-Privileged-access-rights.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-8.2-Privileged-access-rights.md @@ -1,18 +1,35 @@ -#iso27002/2022/EN +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.8.2" +title: "Privileged access rights" +theme: Technological +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: [Identity_and_access_management] +security_domains: [Protection] +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- ## 8.2 Privileged access rights -| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | -| ------------ | ----------------------------------------- | ---------------------- | ------------------------------- | ---------------- | -| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Identity_and_access_management | #Protection | - -**Control** +### Control The allocation and use of privileged access rights should be restricted and managed. -**Purpose** +### Purpose To ensure only authorized users, software components and services are provided with privileged access rights. -**Guidance** +### Guidance The allocation of privileged access rights should be controlled through an authorization process in accordance with the relevant topic-specific policy on access control (see [5.15](a-5.15-Access-control.md)). The following should be considered: a\) identifying users who need privileged access rights for each system or process (e.g. operating systems, database management systems and applications); @@ -39,7 +56,7 @@ k\) not sharing or linking identities with privileged access rights to multiple l\) only using identities with privileged access rights for undertaking administrative tasks and not for day-to-day general tasks \[i.e. checking email, accessing the web (users should have a separate normal network identity for these activities)\]. -**Other information** +### Other information Privileged access rights are access rights provided to an identity, a role or a process that allows the performance of activities that typical users or processes cannot perform. System administrator roles typically require privileged access rights. Inappropriate use of system administrator privileges (any feature or facility of an information system that enables the user to override system or application controls) is a major contributory factor to failures or breaches of systems. diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-8.20-Networks-security.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-8.20-Networks-security.md index b00856b..d9c284c 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-8.20-Networks-security.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-8.20-Networks-security.md @@ -1,18 +1,41 @@ +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.8.20" +title: "Networks security" +theme: Technological +control_type: + - Preventive + - Detective +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: + - Protect + - Detect +operational_capabilities: [System_and_network_security] +security_domains: [Protection] +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- + ## 8.20 Networks security -| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | -| ---------------------- | ----------------------------------------- | ---------------------- | ---------------------------- | ---------------- | -| #Preventive #Detective | #Confidentiality #Integrity #Availability | #Protect #Detect | #System_and_network_security | #Protection | - -**Control** +### Control Networks and network devices should be secured, managed and controlled to protect information in systems and applications. -**Purpose** +### Purpose To protect information in networks and its supporting information processing facilities from compromise via the network. -**Guidance** +### Guidance Controls should be implemented to ensure the security of information in networks and to protect connected services from unauthorized access. In particular, the following items should be considered: a\) the type and classification level of information that the network can support; @@ -45,5 +68,5 @@ n\) disabling vulnerable network protocols. The organization should ensure that appropriate security controls are applied to the use of virtualized networks. Virtualized networks also cover software-defined networking (SDN, SD-WAN). Virtualized networks can be desirable from a security viewpoint, since they can permit logical separation of communication taking place over physical networks, particularly for systems and applications that are implemented using distributed computing. -**Other information** +### Other information Additional information on network security can be found in the ISO/IEC 27033 series. More information concerning virtualized networks can be found in ISO/IEC TS 23167. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-8.21-Security-of-network-services.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-8.21-Security-of-network-services.md index 9ec3b9f..bd4299f 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-8.21-Security-of-network-services.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-8.21-Security-of-network-services.md @@ -1,18 +1,35 @@ - +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.8.21" +title: "Security of network services" +theme: Technological +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: [System_and_network_security] +security_domains: [Protection] +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- ## 8.21 Security of network services -| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | -| ------------ | ----------------------------------------- | ---------------------- | ---------------------------- | ---------------- | -| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #System_and_network_security | #Protection | - -**Control** +### Control Security mechanisms, service levels and service requirements of network services should be identified, implemented and monitored. -**Purpose** +### Purpose To ensure security in the use of network services. -**Guidance** +### Guidance The security measures necessary for particular services, such as security features, service levels and service requirements, should be identified and implemented (by internal or external network service providers). The organization should ensure that network service providers implement these measures. The ability of the network service provider to manage agreed services in a secure way should be determined and regularly monitored. The right to audit should be agreed between the organization and the provider. The organization should also consider third-party attestations provided by service providers to demonstrate they maintain appropriate security measures. @@ -43,7 +60,7 @@ c\) caching (e.g. in a content delivery network) and its parameters that allow u d\) procedures for the network service usage to restrict access to network services or applications, where necessary. -**Other information** +### Other information Network services include the provision of connections, private network services and managed network security solutions such as firewalls and intrusion detection systems. These services can range from simple unmanaged bandwidth to complex value-added offerings. More guidance on a framework for access management is given in ISO/IEC 29146. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-8.22-Segregation-of-networks.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-8.22-Segregation-of-networks.md index 61f0528..3f61a7d 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-8.22-Segregation-of-networks.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-8.22-Segregation-of-networks.md @@ -1,23 +1,40 @@ -#iso27002/2022/EN +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.8.22" +title: "Segregation of networks" +theme: Technological +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: [System_and_network_security] +security_domains: [Protection] +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- ## 8.22 Segregation of networks -| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | -| ------------ | ----------------------------------------- | ---------------------- | ---------------------------- | ---------------- | -| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #System_and_network_security | #Protection | - -**Control** +### Control Groups of information services, users and information systems should be segregated in the organization’s networks. -**Purpose** +### Purpose To split the network in security boundaries and to control traffic between them based on business needs. -**Guidance** +### Guidance The organization should consider managing the security of large networks by dividing them into separate network domains and separating them from the public network (i.e. internet). The domains can be chosen based on levels of trust, criticality and sensitivity (e.g. public access domain, desktop domain, server domain, low- and high-risk systems), along organizational units (e.g. human resources, finance, marketing) or some combination (e.g. server domain connecting to multiple organizational units). The segregation can be done using either physically different networks or by using different logical networks. The perimeter of each domain should be well-defined. If access between network domains is allowed, it should be controlled at the perimeter using a gateway (e.g. firewall, filtering router). The criteria for segregation of networks into domains, and the access allowed through the gateways, should be based on an assessment of the security requirements of each domain. The assessment should be in accordance with the topic-specific policy on access control (see [5.15](a-5.15-Access-control.md)), access requirements, value and classification of information processed and take account of the relative cost and performance impact of incorporating suitable gateway technology. Wireless networks require special treatment due to the poorly-defined network perimeter. Radio coverage adjustment should be considered for segregation of wireless networks. For sensitive environments, consideration should be made to treat all wireless access as external connections and to segregate this access from internal networks until the access has passed through a gateway in accordance with network controls (see [8.20](a-8.20-Networks-security.md)) before granting access to internal systems. Wireless access network for guests should be segregated from those for personnel if personnel only use controlled user endpoint devices compliant to the organization’s topic-specific policies. WiFi for guests should have at least the same restrictions as WiFi for personnel, in order to discourage the use of guest WiFi by personnel. -**Other information** +### Other information Networks often extend beyond organizational boundaries, as business partnerships are formed that require the interconnection or sharing of information processing and networking facilities. Such extensions can increase the risk of unauthorized access to the organization’s information systems that use the network, some of which require protection from other network users because of their sensitivity or criticality. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-8.23-Web-filtering.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-8.23-Web-filtering.md index 2925df8..2f9a3ed 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-8.23-Web-filtering.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-8.23-Web-filtering.md @@ -1,16 +1,35 @@ +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.8.23" +title: "Web filtering" +theme: Technological +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: [System_and_network_security] +security_domains: [Protection] +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- + ## 8.23 Web filtering -| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | -| ------------ | ----------------------------------------- | ---------------------- | ---------------------------- | ---------------- | -| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #System_and_network_security | #Protection | - -**Control** +### Control Access to external websites should be managed to reduce exposure to malicious content. -**Purpose** +### Purpose To protect systems from being compromised by malware and to prevent access to unauthorized web resources. -**Guidance** +### Guidance The organization should reduce the risks of its personnel accessing websites that contain illegal information or are known to contain viruses or phishing material. A technique for achieving this works by blocking the IP address or domain of the website(s) concerned. Some browsers and anti-malware technologies do this automatically or can be configured to do so. The organization should identify the types of websites to which personnel should or should not have access. The organization should consider blocking access to the following types of websites: @@ -29,5 +48,5 @@ Prior to deploying this control, the organization should establish rules for saf Training should be given to personnel on the secure and appropriate use of online resources including access to the web. The training should include the organization’s rules, contact point for raising security concerns, and exception process when restricted web resources need to be accessed for legitimate business reasons. Training should also be given to personnel to ensure that they do not overrule any browser advisory that reports that a website is not secure but allows the user to proceed. -**Other information** +### Other information Web filtering can include a range of techniques including signatures, heuristics, list of acceptable websites or domains, list of prohibited websites or domains and bespoke configuration to help prevent malicious software and other malicious activity from attacking the organization’s network and systems. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-8.24-Use-of-cryptography.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-8.24-Use-of-cryptography.md index e3b584b..163d8c5 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-8.24-Use-of-cryptography.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-8.24-Use-of-cryptography.md @@ -1,23 +1,35 @@ --- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.8.24" +title: "Use of cryptography" +theme: Technological +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: [Secure_configuration] +security_domains: [Protection] tags: - - iso27001/2022/EN +- iso27002/2022/EN +- sourcetext +status: active --- - ## 8.24 Use of cryptography -| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains -| -------------- | ---------------------------------------- | --------------------- | ------------------------- | --------------- | -| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Secure_configuration | #Protection | - - -**Control** +### Control Rules for the effective use of cryptography, including cryptographic key management, should be defined and implemented. -**Purpose** +### Purpose @@ -25,7 +37,7 @@ To ensure proper and effective use of cryptography to protect the confidentialit -**Guidance** +### Guidance @@ -153,7 +165,7 @@ In addition to integrity, for many use cases, the authenticity of public keys sh -**Other information** +### Other information diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-8.25-Secure-development-life-cycle.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-8.25-Secure-development-life-cycle.md index 661a1a2..6b9f13b 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-8.25-Secure-development-life-cycle.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-8.25-Secure-development-life-cycle.md @@ -1,17 +1,31 @@ --- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.8.25" +title: "Secure development life cycle" +theme: Technological +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: + - Application_security + - System_and_network_security +security_domains: [Protection] tags: - - iso27001/2022/EN +- iso27002/2022/EN +- sourcetext +status: active --- ## 8.25 Secure development life cycle -| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | -| ------------ | ----------------------------------------- | ---------------------- | -------------------------------------------------- | ---------------- | -| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Application_security #System_and_network_security | #Protection | - - - -**Control** +### Control @@ -23,7 +37,7 @@ To ensure information security is designed and implemented within the secure dev -**Guidance** +### Guidance @@ -83,7 +97,7 @@ If development is outsourced, the organization should obtain assurance that the -**Other information** +### Other information diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-8.26-Application-security-requirements.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-8.26-Application-security-requirements.md index f83b078..2dd4d6a 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-8.26-Application-security-requirements.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-8.26-Application-security-requirements.md @@ -1,4 +1,30 @@ -#iso27002/2022/EN +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.8.26" +title: "Application security requirements" +theme: Technological +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: + - Application_security + - System_and_network_security +security_domains: + - Protection + - Defence +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- + ## 8.26 Application security requirements | Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | @@ -6,13 +32,13 @@ | #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Application_security #System_and_network_security | #Protection #Defence | -#### Control +### Control Information security requirements should be identified, specified and approved when developing or acquiring applications. -#### Purpose +### Purpose To ensure all information security requirements are identified and addressed when developing or acquiring applications. -#### Guidance +### Guidance <u>General</u> @@ -88,6 +114,6 @@ e\) where a trusted authority is used (e.g. for the purposes of issuing and main Several of the above considerations can be addressed by the application of cryptography (see [[8.24]]), taking into consideration legal requirements (see [[5.31]], [[5.36]], especially see [[5.31]] for cryptography legislation). -**Other information** +### Other information Applications accessible via networks are subject to a range of network related threats, such as fraudulent activities, contract disputes or disclosure of information to the public; incomplete transmission, mis- routing, unauthorized message alteration, duplication or replay. Therefore, detailed risk assessments and careful determination of controls are indispensable. Controls required often include cryptographic methods for authentication and securing data transfer. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-8.27-Secure-system-architecture-and-engineering-principles.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-8.27-Secure-system-architecture-and-engineering-principles.md index 130b1a0..3b9b741 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-8.27-Secure-system-architecture-and-engineering-principles.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-8.27-Secure-system-architecture-and-engineering-principles.md @@ -1,23 +1,39 @@ --- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.8.27" +title: "Secure system architecture and engineering principles" +theme: Technological +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: + - Application_security + - System_and_network_security +security_domains: [Protection] tags: - - iso27001/2022/EN +- iso27002/2022/EN +- sourcetext +status: active --- ## 8.27 Secure system architecture and engineering principles -| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | -| ------------ | ----------------------------------------- | ---------------------- | -------------------------------------------------- | ---------------- | -| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Application_security #System_and_network_security | #Protection | - -**Control** +### Control Principles for engineering secure systems should be established, documented, maintained and applied to any information system development activities. -**Purpose** +### Purpose To ensure information systems are securely designed, implemented and operated within the development life cycle. -**Guidance** +### Guidance Security engineering principles should be established, documented and applied to information system engineering activities. Security should be designed into all architecture layers (business, data, applications and technology). New technology should be analysed for security risks and the design should be reviewed against known attack patterns. @@ -81,7 +97,7 @@ The established security engineering principles should be applied, where applica The security engineering principles and the established engineering procedures should be regularly reviewed to ensure that they are effectively contributing to enhanced standards of security within the engineering process. They should also be regularly reviewed to ensure that they remain up-to- date in terms of combatting any new potential threats and in remaining applicable to advances in the technologies and solutions being applied. -**Other information** +### Other information Secure engineering principles can be applied to the design or configuration of a range of techniques, such as: diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-8.28-Secure-coding.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-8.28-Secure-coding.md index 1d24c99..8c252d8 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-8.28-Secure-coding.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-8.28-Secure-coding.md @@ -1,20 +1,34 @@ --- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.8.28" +title: "Secure coding" +theme: Technological +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: + - Application_security + - System_and_network_security +security_domains: [Protection] tags: - - iso27001/2022/EN +- iso27002/2022/EN +- sourcetext +status: active --- - -| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | -| ------------ | ----------------------------------------- | ---------------------- | -------------------------------------------------- | ---------------- | -| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Application_security #System_and_network_security | #Protection | - - ## 8.28 Secure coding -#### Control +### Control Secure coding principles should be applied to software development. -#### Purpose +### Purpose To ensure software is written securely thereby reducing the number of potential information security vulnerabilities in the software. #### Guidance diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-8.29-Security-testing-in-development-and-acceptance.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-8.29-Security-testing-in-development-and-acceptance.md index e386602..199f11d 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-8.29-Security-testing-in-development-and-acceptance.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-8.29-Security-testing-in-development-and-acceptance.md @@ -1,18 +1,38 @@ -#iso27002/2022/EN +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.8.29" +title: "Security testing in development and acceptance" +theme: Technological +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Identify] +operational_capabilities: + - Application_security + - Information_security_assurance + - System_and_network_security +security_domains: [Protection] +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- ## 8.29 Security testing in development and acceptance -| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | -| ------------ | ----------------------------------------- | ---------------------- | ---------------------------------------------------------------------------------- | ---------------- | -| #Preventive | #Confidentiality #Integrity #Availability | #Identify | #Application_security #Information_security_assurance #System_and_network_security | #Protection | - -**Control** +### Control Security testing processes should be defined and implemented in the development life cycle. -**Purpose** +### Purpose To validate if information security requirements are met when applications or code are deployed to the production environment. -**Guidance** +### Guidance New information systems, upgrades and new versions should be thoroughly tested and verified during the development processes. Security testing should be an integral part of the testing for systems or components. Security testing should be conducted against a set of requirements, which can be expressed as functional or non-functional. Security testing should include testing of: @@ -47,7 +67,7 @@ For outsourced development and purchasing components, an acquisition process sho Testing should be performed in a test environment that matches the target production environment as closely as possible to ensure that the system does not introduce vulnerabilities to the organization’s environment and that the tests are reliable (see [8.31](a-8.31-Separation-of-development-test-and-production-environments.md)). -**Other information** +### Other information Multiple test environments can be established, which can be used for different kinds of testing (e.g. functional and performance testing). These different environments can be virtual, with individual configurations to simulate a variety of operating environments. Testing and monitoring of test environments, tools and technologies also needs to be considered to ensure effective testing. The same considerations apply to monitoring of the monitoring systems deployed in development, test and production settings. Judgeme nt is needed, guided by the sensitivity of the systems and data, to determine how many layers of meta-testing are useful. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-8.3-Information-access-restriction.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-8.3-Information-access-restriction.md index 1ef746b..ebc8b1f 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-8.3-Information-access-restriction.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-8.3-Information-access-restriction.md @@ -1,16 +1,35 @@ +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.8.3" +title: "Information access restriction" +theme: Technological +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: [Identity_and_access_management] +security_domains: [Protection] +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- + ## 8.3 Information access restriction -| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | -| ------------ | ----------------------------------------- | ---------------------- | ------------------------------- | ---------------- | -| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Identity_and_access_management | #Protection | - -**Control** +### Control Access to information and other associated assets should be restricted in accordance with the established topic-specific policy on access control. -**Purpose** +### Purpose To ensure only authorized access and to prevent unauthorized access to information and other associated assets. -**Guidance** +### Guidance Access to information and other associated assets should be restricted in accordance with the established topic-specific policies. The following should be considered in order to support access restriction requirements: a\) not allowing access to sensitive information by unknown user identities or anonymously. Public or anonymous access should only be granted to storage locations that do not contain any sensitive information; @@ -45,7 +64,7 @@ d\) defining the printing permissions for the information; e\) recording who accesses the information and how the information is used; f\) raising alerts if attempts to misuse the information are detected. -**Other information** +### Other information Dynamic access management techniques and other dynamic information protection technologies can support the protection of information even when data is shared beyond the originating organization, where traditional access controls cannot be enforced. It can be applied to documents, emails or other files containing information to limit who can access the content and in what way. It can be at a granular level and be adapted over the life cycle of the information. Dynamic access management techniques do not replace classical access management \[e.g. using access control lists (ACLs)\], but can add more factors for conditionality, real-time evaluation, just-in-time data reduction and other enhancements that can be useful for the most sensitive information. It offers a way to control access outside the organization’s environment. Incident response can be supported by dynamic access management techniques as permissions can be modified or revoked at any time. diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-8.30-Outsourced-development.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-8.30-Outsourced-development.md index 0d3174d..fb10f74 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-8.30-Outsourced-development.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-8.30-Outsourced-development.md @@ -1,16 +1,45 @@ +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.8.30" +title: "Outsourced development" +theme: Technological +control_type: + - Preventive + - Detective +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: + - Identify + - Protect + - Detect +operational_capabilities: + - System_and_network_security + - Application_security + - Supplier_relationships_security +security_domains: + - Governance_and_Ecosystem + - Protection +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- + ## 8.30 Outsourced development -| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | -| :--------------------- | :------------------------------------------- | :---------------------------- | :---------------------------------------------------------------------------------- | :------------------------------------ | -| #Preventive #Detective | #Confidentiality<br>#Integrity #Availability | #Identify #Protect<br>#Detect | #System_and_network_security #Application_security #Supplier_relationships_security | #Governance_and_Ecosystem #Protection | - -**Control** +### Control The organization should direct, monitor and review the activities related to outsourced system development. -**Purpose** +### Purpose To ensure information security measures required by the organization are implemented in outsourced system development. -**Guidance** +### Guidance Where system development is outsourced, the organization should communicate and agree requirements and expectations, and continually monitor and review whether the delivery of outsourced work meets these expectations. The following points should be considered across the organization’s entire external supply chain: a\) licensing agreements, code ownership and intellectual property rights related to the outsourced content (see [5.32](a-5.32-Intellectual-property-rights.md)); @@ -35,5 +64,5 @@ j\) security requirements for the development environment (see [8.31](a-8.31-Sep k\) taking consideration of applicable legislation (e.g. on protection of personal data). -**Other information** +### Other information Further information on supplier relationships can be found in the ISO/IEC 27036 series. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-8.31-Separation-of-development-test-and-production-environments.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-8.31-Separation-of-development-test-and-production-environments.md index 191f9e4..2187d9a 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-8.31-Separation-of-development-test-and-production-environments.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-8.31-Separation-of-development-test-and-production-environments.md @@ -1,16 +1,37 @@ +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.8.31" +title: "Separation of development, test and production environments" +theme: Technological +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: + - Application_security + - System_and_network_security +security_domains: [Protection] +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- + ## 8.31 Separation of development, test and production environments -| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | -| --- | --- | --- | --- | --- | -| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Application_security #System_and_network_security | #Protection | - -**Control** +### Control Development, testing and production environments should be separated and secured. -**Purpose** +### Purpose To protect the production environment and data from compromise by development and test activities. -**Guidance** +### Guidance The level of separation between production, testing and development environments that is necessary to prevent production problems should be identified and implemented. @@ -79,7 +100,7 @@ A single person should not have the ability to make changes to both development -**Other information** +### Other information Without adequate measures and procedures, developers and testers having access to production systems can introduce significant risks (e.g. unwanted modification of files or system environment, system failure, running unauthorized and untested code in product ion systems, disclosure of confidential data, data integrity and availability issues). There is a need to maintain a known and stable environment in which to perform meaningful testing and to prevent inappropriate developer access to the production environment. diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-8.32-Change-management.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-8.32-Change-management.md index eb8b550..15a49eb 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-8.32-Change-management.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-8.32-Change-management.md @@ -1,17 +1,37 @@ -#iso27002/2022/EN +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.8.32" +title: "Change management" +theme: Technological +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: + - Application_security + - System_and_network_security +security_domains: [Protection] +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- + ## 8.32 Change management -| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | -| ------------ | ----------------------------------------- | ---------------------- | -------------------------------------------------- | ---------------- | -| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Application_security #System_and_network_security | #Protection | - -**Control** +### Control Changes to information processing facilities and information systems should be subject to change management procedures. -**Purpose** +### Purpose To preserve information security when executing changes. -**Guidance** +### Guidance Introduction of new systems and major changes to existing systems should follow agreed rules and a formal process of documentation, specification, testing, quality control and managed implementation. Management responsibilities and procedures should be in place to ensure satisfactory control of all changes. Change control procedures should be documented and enforced to ensure the confidentiality, integrity and availability of information in information processing facilities and information systems, for the entire system development life cycle from the early design stages through all subsequent maintenance efforts. @@ -38,7 +58,7 @@ h\) ensuring that operating documentation (see [5.37](a-5.37-Documented-operatin i\) ensuring that ICT continuity plans and response and recovery procedures (see [5.30](a-5.30-ICT-readiness-for-business-continuity.md)) are changed as necessary to remain appropriate. -**Other information** +### Other information Inadequate control of changes to information processing facilities and information systems is a common cause of system or security failures. Changes to the production environment, especially when transferring software from development to operational environment, can impact on the integrity and availability of applications. Changing software can impact the production environment and vice versa. diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-8.33-Test-information.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-8.33-Test-information.md index e827f33..9fe4089 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-8.33-Test-information.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-8.33-Test-information.md @@ -1,16 +1,34 @@ +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.8.33" +title: "Test information" +theme: Technological +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity +cybersecurity_concepts: [Protect] +operational_capabilities: [Information_protection] +security_domains: [Protection] +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- + ## 8.33 Test information -| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | -| ------------ | ------------------------------- | ---------------------- | ------------------------ | ---------------- | -| #Preventive | #Confidentiality #Integrity | #Protect | #Information_protection | #Protection | - -**Control** +### Control Test information should be appropriately selected, protected and managed. -**Purpose** +### Purpose To ensure relevance of testing and protection of operational information used for testing. -**Guidance** +### Guidance Test information should be selected to ensure the reliability of tests results and the confidentiality of the relevant operational information. Sensitive information (including personally identifiable information) should not be copied into the development and testing environments (see [8.31](a-8.31-Separation-of-development-test-and-production-environments.md)). The following guidelines should be applied to protect the copies of operational information, when used for testing purposes, whether the test environment is built in-house or on a cloud service: @@ -27,5 +45,5 @@ e\) properly deleting (see [8.10](a-8.10-Information-deletion.md)) operational i Test information should be securely stored (to prevent tampering, which can otherwise lead to invalid results) and only used for testing purposes. -**Other information** +### Other information System and acceptance testing can require substantial volumes of test information that are as close as possible to operational information. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-8.34-Protection-of-information-systems-during-audit-testing.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-8.34-Protection-of-information-systems-during-audit-testing.md index 6e209fe..b5aa165 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-8.34-Protection-of-information-systems-during-audit-testing.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-8.34-Protection-of-information-systems-during-audit-testing.md @@ -1,16 +1,39 @@ +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.8.34" +title: "Protection of information systems during audit testing" +theme: Technological +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: + - System_and_network_security + - Information_protection +security_domains: + - Governance_and_Ecosystem + - Protection +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- + ## 8.34 Protection of information systems during audit testing -| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | -| --- | --- | --- | --- | --- | -| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #System_and_network_security #Information_protection | #Governance_and_Ecosystem #Protection | - -**Control** +### Control Audit tests and other assurance activities involving assessment of operational systems should be planned and agreed between the tester and appropriate management. -**Purpose** +### Purpose To minimize the impact of audit and other assurance activities on operational systems and business processes. -**Guidance** +### Guidance The following guidelines should be observed: a\) agreeing audit requests for access to systems and data with appropriate management; @@ -29,5 +52,5 @@ g\) running audit tests that can affect system availability outside business hou h\) monitoring and logging all access for audit and test purposes. -**Other information** +### Other information Audit tests and other assurance activities can also happen on development and test systems, where such tests can impact for example the integrity of code or lead to disclosure of any sensitive information held in such environments. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-8.4-Access-to-source-code.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-8.4-Access-to-source-code.md index cadaf79..a223b5d 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-8.4-Access-to-source-code.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-8.4-Access-to-source-code.md @@ -1,16 +1,38 @@ +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.8.4" +title: "Access to source code" +theme: Technological +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: + - Identity_and_access_management + - Application_security + - Secure_configuration +security_domains: [Protection] +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- + ## 8.4 Access to source code -| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | -| ------------ | ----------------------------------------- | ---------------------- | --------------------------------------------------------------------------- | ---------------- | -| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Identity_and_access_management #Application_security #Secure_configuration | #Protection | - -**Control** +### Control Read and write access to source code, development tools and software libraries should be appropriately managed. -**Purpose** +### Purpose To prevent the introduction of unauthorized functionality, avoid unintentional or malicious changes and to maintain the confidentiality of valuable intellectual property. -**Guidance** +### Guidance Access to source code and associated items (such as designs, specifications, verification plans and validation plans) and development tools (e.g. compilers, builders, integration tools, test platforms and environments) should be strictly controlled. For source code, this can be achieved by controlling central storage of such code, preferably in source code management system. @@ -28,5 +50,5 @@ f\) maintaining an audit log of all accesses and of all changes to source code. If the program source code is intended to be published, additional controls to provide assurance on its integrity (e.g. digital signature) should be considered. -**Other information** +### Other information If access to source code is not properly controlled, source code can be modified or some data in the development environment (e.g. copies of production data, configuration details) can be retrieved by unauthorized persons. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-8.5-Secure-authentication.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-8.5-Secure-authentication.md index 6355aa3..ed2e0fd 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-8.5-Secure-authentication.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-8.5-Secure-authentication.md @@ -1,18 +1,35 @@ -#iso27002/2022/EN +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.8.5" +title: "Secure authentication" +theme: Technological +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: [Identity_and_access_management] +security_domains: [Protection] +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- ## 8.5 Secure authentication -| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | -| ------------ | ----------------------------------------- | ---------------------- | ------------------------------- | ---------------- | -| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Identity_and_access_management | #Protection | - -**Control** +### Control Secure authentication technologies and procedures should be implemented based on information access restrictions and the topic-specific policy on access control. -**Purpose** +### Purpose To ensure a user or an entity is securely authenticated, when access to systems, applications and services is granted. -**Guidance** +### Guidance A suitable authentication technique should be chosen to substantiate the claimed identity of a user, software, messages and other entities. The strength of authentication should be appropriate for the classification of the information to be accessed. Where strong authentication and identity verification is required, authentication methods alternative to passwords, such as digital certificates, smart cards, tokens or biometric means, should be used. @@ -38,5 +55,5 @@ j\) not transmitting passwords in clear text over a network to avoid being captu k\) terminating inactive sessions after a defined period of inactivity, especially in high risk locations such as public or external areas outside the organization’s security management or on user endpoint devices; l\) restricting connection duration times to provide additional security for high-risk applications and reduce the window of opportunity for unauthorized access. -**Other information** +### Other information Additional information on entity authentication assurance can be found is ISO/IEC 29115. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-8.6-Capacity-management.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-8.6-Capacity-management.md index 516cb86..01c6c72 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-8.6-Capacity-management.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-8.6-Capacity-management.md @@ -1,16 +1,41 @@ +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.8.6" +title: "Capacity management" +theme: Technological +control_type: + - Preventive + - Detective +information_security_properties: + - Integrity + - Availability +cybersecurity_concepts: + - Identify + - Protect + - Detect +operational_capabilities: [Continuity] +security_domains: + - Governance_and_Ecosystem + - Protection +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- + ## 8.6 Capacity management -| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | -| ---------------------- | ------------------------------- | -------------------------- | ------------------------ | ------------------------------------- | -| #Preventive #Detective | #Integrity #Availability | #Identify #Protect #Detect | #Continuity | #Governance_and_Ecosystem #Protection | - -**Control** +### Control The use of resources should be monitored and adjusted in line with current and expected capacity requirements. -**Purpose** +### Purpose To ensure the required capacity of information processing facilities, human resources, offices and other facilities. -**Guidance** +### Guidance Capacity requirements for information processing facilities, human resources, offices and other facilities should be identified, taking into account the business criticality of the concerned systems and processes. System tuning and monitoring should be applied to ensure and, where necessary, improve the availability and efficiency of systems. @@ -43,5 +68,5 @@ f\) denying or restricting bandwidth for resource-consuming services if these ar A documented capacity management plan should be considered for mission critical systems. -**Other information** +### Other information For more detail on the elasticity and scalability of cloud computing, see ISO/IEC TS 23167. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-8.7-Protection-against-malware.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-8.7-Protection-against-malware.md index 8ed499e..a0e8057 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-8.7-Protection-against-malware.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-8.7-Protection-against-malware.md @@ -1,15 +1,45 @@ -#iso27002/2022/EN +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.8.7" +title: "Protection against malware" +theme: Technological +control_type: + - Preventive + - Detective + - Corrective +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: + - Protect + - Detect +operational_capabilities: + - System_and_network_security + - Information_protection +security_domains: + - Protection + - Defence +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- -# 8.7  **Protection** **against** **malware** +## 8.7  Protection against malware ## Control Protection against malware should be implemented and supported by appropriate user awareness. -## Purpose +### Purpose To ensure information and other associated assets are protected against malware. -## Guidance +### Guidance Protection against malware should be based on malware detection and repair software, information security awareness, appropriate system access and change management controls. Use of malware detection and repair software alone is not usually adequate. The following guidance should be considered: @@ -53,6 +83,6 @@ n)   implementing procedures to regularly collect information about new malware o)   verifying that information relating to malware, such as warning bulletins, comes from qualified and reputable sources (e.g. reliable internet sites or suppliers of malware detection software) and is accurate and informative. -## Other **information** +### Other information It is not always possible to install software that protects against malware on some systems (e.g. some industrial control systems). Some forms of malware infect computer operating systems and computer firmware such that common malware controls cannot clean the system and a full reimaging of the operating system software and sometimes the computer firmware is necessary to return to a secure state. diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-8.8-Management-of-technical-vulnerabilities.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-8.8-Management-of-technical-vulnerabilities.md index 77430c6..613e22d 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-8.8-Management-of-technical-vulnerabilities.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-8.8-Management-of-technical-vulnerabilities.md @@ -1,19 +1,37 @@ -#iso27002/2022/EN -x +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.8.8" +title: "Management of technical vulnerabilities" +theme: Technological +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: + - Identify + - Protect +operational_capabilities: [Threat_and_vulnerability_management] +security_domains: + - Governance_and_Ecosystem + - Protection + - Defence +tags: +- iso27002/2022/EN +- sourcetext +status: active +--- + ## 8.8 Management of technical vulnerabilities -| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | - -| -------------- | ---------------------------------------- | --------------------- | ------------------------------- | ------------------------------- | - -| #Preventive | #Confidentiality #Integrity #Availability | #Identify #Protect | #Threat_and_vulnerability_management | #Governance_and_Ecosystem #Protection #Defence | - - - -**Control** +### Control @@ -21,7 +39,7 @@ Information about technical vulnerabilities of information systems in use should -**Purpose** +### Purpose @@ -29,7 +47,7 @@ To prevent exploitation of technical vulnerabilities. -**Guidance** +### Guidance @@ -198,7 +216,7 @@ Where the organization uses a cloud service supplied by a third-party cloud serv -**Other information** +### Other information diff --git a/Corpus/Standards/ISO27x/OST/27002/EN/a-8.9-Configuration-management.md b/Corpus/Standards/ISO27x/OST/27002/EN/a-8.9-Configuration-management.md index 518d996..139bb0a 100644 --- a/Corpus/Standards/ISO27x/OST/27002/EN/a-8.9-Configuration-management.md +++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-8.9-Configuration-management.md @@ -1,4 +1,27 @@ -#iso27002/2022/EN +--- +notetype: reference +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.8.9" +title: "Configuration management" +theme: Technological +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: [Secure_configuration] +security_domains: [Protection] +tags: +- iso27002/2022/EN +- sourcetext +- sourcetext +status: active +--- + ## 8.9 Configuration management ### Control diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-4.2-Themas-en-attributen.md b/Corpus/Standards/ISO27x/OST/27002/NL/A-4-Structuur-van-dit-document.md similarity index 73% rename from Corpus/Standards/ISO27x/OST/27002/NL/a-4.2-Themas-en-attributen.md rename to Corpus/Standards/ISO27x/OST/27002/NL/A-4-Structuur-van-dit-document.md index 4062dc3..7d1c811 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-4.2-Themas-en-attributen.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/A-4-Structuur-van-dit-document.md @@ -1,7 +1,34 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +id: "A.4" +title: "Structuur van dit document" +tags: +- iso27002/2022/NL +- sourcetext +status: active --- +# 4 Structuur van dit document + +## 4.1 Hoofdstukken + +Dit document is als volgt ingedeeld: + +a) Organisatorische beheersmaatregelen (hoofdstuk 5) +b) Mensgerichte beheersmaatregelen (hoofdstuk 6) +c) Fysieke beheersmaatregelen (hoofdstuk 7) +d) Technologische beheersmaatregelen (hoofdstuk 8) Er zijn 2 informatieve bijlagen: + +--- Bijlage A -- Attributen gebruiken + +--- Bijlage B -- Overeenstemming met ISO/IEC 27002:2013 + +In bijlage A wordt uitgelegd hoe een organisatie attributen (zie 4.2) kan gebruiken om haar eigen overzichten aan te maken op basis van de in dit document gedefinieerde of zelfbedachte attributen voor beheersmaatregelen. + +Bijlage B laat zien hoe de beheersmaatregelen in deze editie van ISO/IEC 27002 overeenstemmen met de vorige editie uit 2013. + ## 4.2 Thema's en attributen De categorieën waarin beheersmaatregelen kunnen worden ingedeeld volgens de hoofdstukken 5 t/m 8 worden aangeduid als thema's. @@ -44,4 +71,22 @@ Beveiligingsdomeinen is een attribuut om beheersmaatregelen te bekijken vanuit h De in dit document vermelde attributen zijn gekozen op basis van het feit dat ze als generiek genoeg worden beschouwd om door verschillende soorten organisaties te worden gebruiktrganisaties kunnen ervoor kiezen een of meer van de in dit document vermelde attributen buiten beschouwing te latene kunnen ook zelf attributen (met de bijbehorende attribuutwaarden) aanmaken om hun eigen organisatieoverzichten te maken. Hoofdstuk A.2 bevat voorbeelden van dergelijke attributen. -Zie ook: [ISO_27002_NL_Template_Attribuuttabel](../../../legacy/iso27DIY%20mk%20I/📒%20Templates/ISO_27002_NL_Template_Attribuuttabel.md) \ No newline at end of file +Zie ook: [ISO_27002_NL_Template_Attribuuttabel](../../../legacy/iso27DIY%20mk%20I/📒%20Templates/ISO_27002_NL_Template_Attribuuttabel.md) + +## 4.3 Indeling beheersmaatregel + +De indeling van elke beheersmaatregel bevat het volgende: + +--- **Titel van de beheersmaatregel:** Korte naam van de beheersmaatregel; + +--- **Attribuuttabel**: Een tabel toont de waarde(n) van elk attribuut voor de beheersmaatregel in kwestie; + +--- **Beheersmaatregel:** Wat de beheersmaatregel is; + +--- **Doel**: Waarom de beheersmaatregel behoort te worden geïmplementeerd; + +--- **Richtlijn:** Hoe de beheersmaatregel behoort te worden geïmplementeerd; + +--- **Overige informatie:** Tekst met uitleg of verwijzingen naar andere gerelateerde documenten. + +Omwille van de leesbaarheid zijn lange richtlijnteksten die op meer onderwerpen ingaan, soms onderverdeelde titels van deze secties zijn onderstreept. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/ISO_27002_2022_NL_5.17_NN Beheren van authenticatie-informatie.md b/Corpus/Standards/ISO27x/OST/27002/NL/ISO_27002_2022_NL_5.17_NN Beheren van authenticatie-informatie.md deleted file mode 100644 index f5ab1a6..0000000 --- a/Corpus/Standards/ISO27x/OST/27002/NL/ISO_27002_2022_NL_5.17_NN Beheren van authenticatie-informatie.md +++ /dev/null @@ -1,61 +0,0 @@ -#iso27002/2022/NL ---- -Standard: ISO 27002:2022 NL ---- -# 5.17 Beheren van authenticatie-informatie -ISO 27002:2022 [[ISO_27002_2022_NL_BT 5.17 Beheren van authenticatie-informatie|Brontekst]] - -#### Wat -Er moet een proces zijn voor toewijzing en beheer van authenticatie-informatie, met aandacht voor de communicatie naar medewerkers hierover. -#### Waarom -Zorgen voor passende authenticatie en voorkomen van fouten in het proces. -#### Hoe - -##### Verstrekking en wijziging -- tijdelijke wachtwoorden of pincodes die bij inschrijving verstrekt worden, mogen niet gemakkelijk te raden zijn, en moeten na het eerste gebruik verplicht gewijzigd worden; -- gebruikers moeten hun eigen wachtwoord mogen kiezen – daarbij hoort een bevestigingsprocedure om invoerfouten te voorkómen en moeten 'sterke' wachtwoorden worden afgedwongen (zie 'Verantwoordelijkheden van gebruikers'); -- bij invoer mag het wachtwoord niet op het scherm getoond worden (om 'afkijken' te voorkomen); -- Hergebruik van wachtwoorden moet worden voorkomen; -- bij nieuwe, vervangende of tijdelijke authenticatie-informatie moet eerst de identiteit van een gebruiker worden vastgesteld; -- authenticatie-informatie moet altijd versleuteld worden opgeslagen en verzonden (dus niet in onversleutelde mails)[^1]; -- gebruikers moeten ontvangst van authenticatie-informatie bevestigen; -- acties rond het verstrekken en wijzigen van authenticatie-informatie moeten geregistreerd worden (bijv. in beveiligde logfiles of in een wachtwoordkluis) -- bij de installatie van software en systemen moet altijd direct de standaard authenticatie-informatie worden gewijzigd – dit geldt ook voor bijv. wachtwoorden die door verkopers/consultants verstrekt worden. -- Na een beveiligingsincident moeten wachtwoordwijzigingen worden afgedwongen. -- Wachtwoorden van groepsaccounts moeten gewijzigd worden bij uitdiensttredingen en functiewijzigingen. -- Veelgebruikte en gecompromitteerde wachtwoorden moeten gewijzigd worden – dit kan gesignaleerd worden met security scans en 'hacking alerts' zoals voorzien in de meeste wachtwoordkluizen. - -##### Verantwoordelijkheden van gebruikers -- Wachtwoorden moeten 'sterk' zijn: - - gebruik 'wachtzinnen' die makkelijk te onthouden zijn en gebruik daarin nummers, leestekens en speciale tekens; - - zorg voor een minimale lengte; - - gebruik géén persoonlijke informatie als namen, telefoonnummers, adressen en geboortedata; - - gebruik géén woordenboekwoorden of combinaties daarvan; -- Authenticatie-informatie mag niet met anderen worden gedeeld. Bij niet-persoonlijke accounts (bijv. groepsaccounts) mag de informatie alleen met bevoegde personen (bijv. leden van die groep) gedeeld worden. -- Als authenticatie-informatie gelekt is ('gecompromitteerd'), moet die onmiddellijk gewijzigd worden. -- Gebruik nooit hetzelfde wachtwoord voor verschillende systemen of diensten; -- Zorg dat deze regels als verplichting worden opgenomen in de arbeidsovereenkomst (zie [6.2](ISO_27002_2022_NL_[6.2](ISO_27002_2022_NL_6.2_BT%20Arbeidsovereenkomst.md)_BT%20Arbeidsovereenkomst.md)); - -#### Overige informatie -- Het frequent afdwingen van wachtwoordwijzigingen kan contra-productief zijn: het zorgt voor irritatie bij gebruikers, nieuwe wachtwoorden worden gemakkelijk vergeten en op onveilige plekken worden genoteerd, en gebruikers kiezen sneller voor gemakkelijk te onthouden (en te raden) wachtwoorden. -- Het gebruik van 'Single Sign On' (SSO) en wachtwoordkluizen kan dit risico verminderen, maar aan de andere kant kan het lekken van een wachtwoord hiervan ook weer een grotere impact hebben. -- In plaats van wachtwoorden of wachtzinnen kunnen ook andere authenticatie-middelen gebruikt worden, zoals cryptografische sleutels, hardware tokens, en biometrische gegevens (multi-factor authenticatie). - -#### Bewijs -Auditors kijken naar bewijzen van de implementatie van het proces. Dit kan bijvoorbeeld de volgende vorm aannemen: - -| Omschrijving van bewijs | ISO27DIY artefact | -| ----------------------- | ----------------- | -| Omschrijving 1 | Artefact 1 | - -#### Gerelateerd -Naar deze maatregel wordt verwezen in: -- [ ] Andere beheersmaatregelen binnen dezelfde norm die verwijzen naar deze maatregel - -Andere gerelateerde ISO 27x beheersmaatregelen: -- [ ] Gerelateerde ISO 27x beheersmaatregelen die *niet* letterlijk in de brontekst genoemd worden. - - - -[^1]: Gebruik voor versleuteling en hashing goedgekeurde technieken (zie [8.24](ISO_27002_2022_NL_[8.24](ISO_27002_2022_NL_8.24_BT%20Gebruik%20van%20cryptografie.md)_BT%20Gebruik%20van%20cryptografie.md)). - diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/ISO_27002_2022_NL_Index.md b/Corpus/Standards/ISO27x/OST/27002/NL/ISO_27002_2022_NL_Index.md deleted file mode 100644 index 4aec30d..0000000 --- a/Corpus/Standards/ISO27x/OST/27002/NL/ISO_27002_2022_NL_Index.md +++ /dev/null @@ -1,114 +0,0 @@ -#iso27002/2022/NL -# ISO 27002:2022 NL Index - - -| 2022 ID | Maatregel | Brontekst | -| :------ | :---------------------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------- | -| **3** | **Termen, definities en afgekorte termen** | | -| 3.1 | Termen en definities | [BT](a-3.1-Termen-en-definities.md) | -| 3.2 | Afgekorte termen | [BT](a-3.2-Afgekorte-termen.md) | -| **4** | **Structuur van dit document** | _ | -| 4.1 | Hoofdstukken | [BT](a-4.1-Hoofdstukken.md) | -| 4.2 | Thema's en attributen | [BT](a-4.2-Themas-en-attributen.md) | -| 4.3 | Indeling beheersmaatregel | [BT](a-4.3-Indeling-beheersmaatregel.md) | -| **5** | **Organisatorische beheersmaatregelen** | _ | -| 5.1 | Beleidsregels voor informatiebeveiliging | [BT](a-5.1-Beleidsregels-voor-informatiebeveiliging.md) | -| 5.2 | Rollen en verantwoordelijkheden bij informatiebeveiliging | [BT](a-5.2-Rollen-en-verantwoordelijkheden-bij-informatiebeveiliging.md) | -| 5.3 | Functiescheiding | [BT](a-5.3-Functiescheiding.md) | -| 5.4 | Managementverantwoordelijkheden | [BT](a-5.4-Managementverantwoordelijkheden.md) | -| 5.5 | Contact met overheidsinstanties | [BT](a-5.5-Contact-met-overheidsinstanties.md) | -| 5.6 | Contact met speciale belangengroepen | [BT](a-5.6-Contact-met-speciale-belangengroepen.md) | -| 5.7 | Informatie en analyses over dreigingen | [BT](a-5.7-Informatie-en-analyses-over-dreigingen.md) | -| 5.8 | Informatiebeveiliging in projectmanagement | [BT](a-5.8-Informatiebeveiliging-in-projectmanagement.md) | -| 5.9 | Inventarisatie van informatie en andere gerelateerde bedrijfsmiddelen | [BT](a-5.9-Inventarisatie-van-informatie-en-andere-gerelateerde-bedrijfsmiddelen.md) | -| 5.10 | Aanvaardbaar gebruik van informatie en andere gerelateerde bedrijfsmiddelen | [BT](a-5.10-Aanvaardbaar-gebruik-van-informatie-en-andere-gerelateerde-bedrijfsmiddelen.md) | -| 5.11 | Retourneren van bedrijfsmiddelen | [BT](a-5.11-Retourneren-van-bedrijfsmiddelen.md) | -| 5.12 | Classificeren van informatie | [BT](a-5.12-Classificeren-van-informatie.md) | -| 5.13 | Labelen van informatie | [BT](a-5.13-Labelen-van-informatie.md) | -| 5.14 | Overdragen van informatie | [BT](a-5.14-Overdragen-van-informatie.md) | -| 5.15 | Toegangsbeveiliging | [BT](a-5.15-Toegangsbeveiliging.md) | -| 5.16 | Identiteitsbeheer | [BT](a-5.16-Identiteitsbeheer.md) | -| 5.17 | Beheren van authenticatie-informatie | [BT](a-5.17-Beheren-van-authenticatie-informatie.md) | -| 5.18 | Toegangsrechten | [BT](a-5.18-Toegangsrechten.md) | -| 5.19 | Informatiebeveiliging in leveranciersrelaties | [BT](a-5.19-Informatiebeveiliging-in-leveranciersrelaties.md) | -| 5.20 | Adresseren van informatiebeveiliging in leveranciersovereenkomsten | [BT](a-5.20-Adresseren-van-informatiebeveiliging-in-leveranciersovereenkomsten.md) | -| 5.21 | Beheren van informatiebeveiliging in de ICT-keten | [BT](a-5.21-Beheren-van-informatiebeveiliging-in-de-ICT-keten.md) | -| 5.22 | Monitoren, beoordelen en het beheren van wijzigingen van leveranciersdiensten | [BT](a-5.22-Monitoren-beoordelen-en-het-beheren-van-wijzigingen-van-leveranciersdiensten.md) | -| 5.23 | Informatiebeveiliging voor het gebruik van clouddiensten | [BT](a-5.23-Informatiebeveiliging-voor-het-gebruik-van-clouddiensten.md) | -| 5.24 | Plannen en voorbereiden van het beheer van informatiebeveiligingsincidenten | [BT](a-5.24-Plannen-en-voorbereiden-van-het-beheer-van-informatiebeveiligingsincidenten.md) | -| 5.25 | Beoordelen van en besluiten over informatiebeveiligingsgebeurtenissen | [BT](a-5.25-Beoordelen-van-en-besluiten-over-informatiebeveiligingsgebeurtenissen.md) | -| 5.26 | Reageren op informatiebeveiligingsincidenten | [BT](a-5.26-Reageren-op-informatiebeveiligingsincidenten.md) | -| 5.27 | Leren van informatiebeveiligingsincidenten | [BT](a-5.27-Leren-van-informatiebeveiligingsincidenten.md) | -| 5.28 | Verzamelen van bewijsmateriaal | [BT](a-5.28-Verzamelen-van-bewijsmateriaal.md) | -| 5.29 | Informatiebeveiliging tijdens een verstoring | [BT](a-5.29-Informatiebeveiliging-tijdens-een-verstoring.md) | -| 5.30 | ICT-gereedheid voor bedrijfscontinuïteit | [BT](a-5.30-ICT-gereedheid-voor-bedrijfscontinuiteit.md) | -| 5.31 | Wettelijke, statutaire, regelgevende en contractuele eisen | [BT](a-5.31-Wettelijke-statutaire-regelgevende-en-contractuele-eisen.md) | -| 5.32 | Intellectuele-eigendomsrechten | [BT](a-5.32-Intellectuele-eigendomsrechten.md) | -| 5.33 | Beschermen van registraties | [BT](a-5.33-Beschermen-van-registraties.md) | -| 5.34 | Privacy en bescherming van persoonsgegevens | [BT](a-5.34-Privacy-en-bescherming-van-persoonsgegevens.md) | -| 5.35 | Onafhankelijke beoordeling van informatiebeveiliging | [BT](a-5.35-Onafhankelijke-beoordeling-van-informatiebeveiliging.md) | -| 5.36 | Naleving van beleid, regels en normen voor informatiebeveiliging | [BT](a-5.36-Naleving-van-beleid-regels-en-normen-voor-informatiebeveiliging.md) | -| 5.37 | Gedocumenteerde bedieningsprocedures | [BT](a-5.37-Gedocumenteerde-bedieningsprocedures.md) | -| | | | -| **6** | **Mensgerichte beheersmaatregelen** | | -| 6.1 | Screening | [BT](../EN/a-6.1-Screening.md) | -| 6.2 | Arbeidsovereenkomst | [BT](a-6.2-Arbeidsovereenkomst.md) | -| 6.3 | Bewustwording van, opleiding en training in informatiebeveiliging | [BT](a-6.3-Bewustwording-van-opleiding-en-training-in-informatiebeveiliging.md) | -| 6.4 | Disciplinaire procedure | [BT](a-6.4-Disciplinaire-procedure.md) | -| 6.5 | Verantwoordelijkheden na beëindiging of wijziging van het dienstverband | [BT](a-6.5-Verantwoordelijkheden-na-beeindiging-of-wijziging-van-het-dienstverband.md) | -| 6.6 | Vertrouwelijkheids- of geheimhoudingsovereenkomsten | [BT](a-6.6-Vertrouwelijkheids-of-geheimhoudingsovereenkomsten.md) | -| 6.7 | Werken op afstand | [BT](a-6.7-Werken-op-afstand.md) | -| 6.8 | Melden van informatiebeveiligingsgebeurtenissen | [BT](a-6.8-Melden-van-informatiebeveiligingsgebeurtenissen.md) | -| | | | -| **7** | **Fysieke beheersmaatregelen** | | -| 7.1 | Fysieke beveiligingszones | [BT](a-7.1-Fysieke-beveiligingszones.md) | -| 7.2 | Fysieke toegangsbeveiliging | [BT](a-7.2-Fysieke-toegangsbeveiliging.md) | -| 7.3 | Beveiligen van kantoren, ruimten en faciliteiten | [BT](a-7.3-Beveiligen-van-kantoren-ruimten-en-faciliteiten.md) | -| 7.4 | Monitoren van de fysieke beveiliging | [BT](a-7.4-Monitoren-van-de-fysieke-beveiliging.md) | -| 7.5 | Beschermen tegen fysieke en omgevingsdreigingen | [BT](a-7.5-Beschermen-tegen-fysieke-en-omgevingsdreigingen.md) | -| 7.6 | Werken in beveiligde zones | [BT](a-7.6-Werken-in-beveiligde-zones.md) | -| 7.7 | ‘Clear desk’ en ‘clear screen’ | [BT](a-7.7-Clear-desk-en-clear-screen.md) | -| 7.8 | Plaatsen en beschermen van apparatuur | [BT](a-7.8-Plaatsen-en-beschermen-van-apparatuur.md) | -| 7.9 | Beveiligen van bedrijfsmiddelen buiten het terrein | [BT](a-7.9-Beveiligen-van-bedrijfsmiddelen-buiten-het-terrein.md) | -| 7.10 | Opslagmedia | [BT](a-7.10-Opslagmedia.md) | -| 7.11 | Nutsvoorzieningen | [BT](a-7.11-Nutsvoorzieningen.md) | -| 7.12 | Beveiligen van bekabeling | [BT](a-7.12-Beveiligen-van-bekabeling.md) | -| 7.13 | Onderhoud van apparatuur | [BT](a-7.13-Onderhoud-van-apparatuur.md) | -| 7.14 | Veilig verwijderen of hergebruiken van apparatuur | [BT](a-7.14-Veilig-verwijderen-of-hergebruiken-van-apparatuur.md) | -| | | | -| **8** | **Technologische beheersmaatregelen** | | -| 8.1 | ‘User endpoint devices’ | [BT](../EN/a-8.1-User-endpoint-devices.md) | -| 8.2 | Speciale toegangsrechten | [BT](a-8.2-Speciale-toegangsrechten.md) | -| 8.3 | Beperking toegang tot informatie | [BT](a-8.3-Beperking-toegang-tot-informatie.md) | -| 8.4 | Toegangsbeveiliging op broncode | [BT](a-8.4-Toegangsbeveiliging-op-broncode.md) | -| 8.5 | Beveiligde authenticatie | [BT](a-8.5-Beveiligde-authenticatie.md) | -| 8.6 | Capaciteitsbeheer | [BT](a-8.6-Capaciteitsbeheer.md) | -| 8.7 | Bescherming tegen malware | [BT](a-8.7-Bescherming-tegen-malware.md) | -| 8.8 | Beheer van technische kwetsbaarheden | [BT](a-8.8-Beheer-van-technische-kwetsbaarheden.md) | -| 8.9 | Configuratiebeheer | [BT](a-8.9-Configuratiebeheer.md) | -| 8.10 | Wissen van informatie | [BT](a-8.10-Wissen-van-informatie.md) | -| 8.11 | Maskeren van gegevens | [BT](a-8.11-Maskeren-van-gegevens.md) | -| 8.12 | Voorkomen van gegevenslekken (Data leakage prevention) | [BT](a-8.12-Voorkomen-van-gegevenslekken-Data-leakage-prevention.md) | -| 8.13 | Back-up van informatie | [BT](a-8.13-Back-up-van-informatie.md) | -| 8.14 | Redundantie van informatieverwerkende faciliteiten | [BT](a-8.14-Redundantie-van-informatieverwerkende-faciliteiten.md) | -| 8.15 | Logging | [BT](../EN/a-8.15-Logging.md) | -| 8.16 | Monitoren van activiteiten | [BT](a-8.16-Monitoren-van-activiteiten.md) | -| 8.17 | Kloksynchronisatie | [BT](a-8.17-Kloksynchronisatie.md) | -| 8.18 | Gebruik van speciale systeemhulpmiddelen | [BT](a-8.18-Gebruik-van-speciale-systeemhulpmiddelen.md) | -| 8.19 | Installeren van software op operationele systemen | [BT](a-8.19-Installeren-van-software-op-operationele-systemen.md) | -| 8.20 | Beveiliging netwerkcomponenten | [BT](a-8.20-Beveiliging-netwerkcomponenten.md) | -| 8.21 | Beveiliging van netwerkdiensten | [BT](a-8.21-Beveiliging-van-netwerkdiensten.md) | -| 8.22 | Netwerksegmentatie | [BT](a-8.22-Netwerksegmentatie.md) | -| 8.23 | Toepassen van webfilters | [BT](a-8.23-Toepassen-van-webfilters.md) | -| 8.24 | Gebruik van cryptografie | [BT](a-8.24-Gebruik-van-cryptografie.md) | -| 8.25 | Beveiligen tijdens de ontwikkelcyclus | [BT](a-8.25-Beveiligen-tijdens-de-ontwikkelcyclus.md) | -| 8.26 | Toepassingsbeveiligingseisen | [BT](a-8.26-Toepassingsbeveiligingseisen.md) | -| 8.27 | Veilige systeemarchitectuur en technische uitgangspunten | [BT](a-8.27-Veilige-systeemarchitectuur-en-technische-uitgangspunten.md) | -| 8.28 | Veilig coderen | [BT](a-8.28-Veilig-coderen.md) | -| 8.29 | Testen van de beveiliging tijdens ontwikkeling en acceptatie | [BT](a-8.29-Testen-van-de-beveiliging-tijdens-ontwikkeling-en-acceptatie.md) | -| 8.30 | Uitbestede systeemontwikkeling | [BT](a-8.30-Uitbestede-systeemontwikkeling.md) | -| 8.31 | Scheiding van ontwikkel-, test- en productieomgevingen | [BT](a-8.31-Scheiding-van-ontwikkel-test-en-productieomgevingen.md) | -| 8.32 | Wijzigingsbeheer | [BT](a-8.32-Wijzigingsbeheer.md) | -| 8.33 | Testgegevens | [BT](a-8.33-Testgegevens.md) | -| 8.34 | Bescherming van informatiesystemen tijdens audits | [BT](a-8.34-Bescherming-van-informatiesystemen-tijdens-audits.md) | - diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-3.1-Termen-en-definities.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-3.1-Termen-en-definities.md index f7c9046..d3f9013 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-3.1-Termen-en-definities.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-3.1-Termen-en-definities.md @@ -1,7 +1,16 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +id: "3.1" +title: "Termen en definities" +tags: +- iso27002/2022/NL +- sourcetext +status: active --- +## 3.1 Termen en definities In het kader van dit document zijn de volgende termen en definities van toepassing. diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-3.2-Afgekorte-termen.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-3.2-Afgekorte-termen.md index 1cf1bc9..7fefa28 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-3.2-Afgekorte-termen.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-3.2-Afgekorte-termen.md @@ -1,6 +1,14 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +id: "3.2" +title: "Afgekorte termen" +tags: +- iso27002/2022/NL +- sourcetext +status: active --- ## 3.2 Afgekorte termen diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-4.1-Hoofdstukken.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-4.1-Hoofdstukken.md deleted file mode 100644 index 6ab70d2..0000000 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-4.1-Hoofdstukken.md +++ /dev/null @@ -1,41 +0,0 @@ -#iso27002/2022/NL ---- -Standard: ISO 27002:2022 NL ---- -## 4.1 Hoofdstukken - - - -Dit document is als volgt ingedeeld: - - - -a) Organisatorische beheersmaatregelen (hoofdstuk 5) - - - -b) Mensgerichte beheersmaatregelen (hoofdstuk 6) - - - -c) Fysieke beheersmaatregelen (hoofdstuk 7) - - - -d) Technologische beheersmaatregelen (hoofdstuk 8) Er zijn 2 informatieve bijlagen: - - - ---- Bijlage A -- Attributen gebruiken - - - ---- Bijlage B -- Overeenstemming met ISO/IEC 27002:2013 - - - -In bijlage A wordt uitgelegd hoe een organisatie attributen (zie 4.2) kan gebruiken om haar eigen overzichten aan te maken op basis van de in dit document gedefinieerde of zelfbedachte attributen voor beheersmaatregelen. - - - -Bijlage B laat zien hoe de beheersmaatregelen in deze editie van ISO/IEC 27002 overeenstemmen met de vorige editie uit 2013. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-4.3-Indeling-beheersmaatregel.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-4.3-Indeling-beheersmaatregel.md deleted file mode 100644 index e640229..0000000 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-4.3-Indeling-beheersmaatregel.md +++ /dev/null @@ -1,21 +0,0 @@ -#iso27002/2022/NL ---- -Standard: ISO 27002:2022 NL ---- -## 4.3 Indeling beheersmaatregel - -De indeling van elke beheersmaatregel bevat het volgende: - ---- **Titel van de beheersmaatregel:** Korte naam van de beheersmaatregel; - ---- **Attribuuttabel**: Een tabel toont de waarde(n) van elk attribuut voor de beheersmaatregel in kwestie; - ---- **Beheersmaatregel:** Wat de beheersmaatregel is; - ---- **Doel**: Waarom de beheersmaatregel behoort te worden geïmplementeerd; - ---- **Richtlijn:** Hoe de beheersmaatregel behoort te worden geïmplementeerd; - ---- **Overige informatie:** Tekst met uitleg of verwijzingen naar andere gerelateerde documenten. - -Omwille van de leesbaarheid zijn lange richtlijnteksten die op meer onderwerpen ingaan, soms onderverdeelde titels van deze secties zijn onderstreept. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-5.1-Beleidsregels-voor-informatiebeveiliging.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-5.1-Beleidsregels-voor-informatiebeveiliging.md index 82702c4..1ee0cd5 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-5.1-Beleidsregels-voor-informatiebeveiliging.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-5.1-Beleidsregels-voor-informatiebeveiliging.md @@ -1,26 +1,37 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "5.1" +title: "Beleidsregels voor informatiebeveiliging" +theme: Organizational +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Identify] +operational_capabilities: [Governance] +security_domains: + - Governance_and_Ecosystem + - Resilience +tags: +- iso27002/2022/NL +- sourcetext +status: active --- ## 5.1 Beleidsregels voor informatiebeveiliging - -| Attribuut | Waarde | -| :----------------------------------- | :----------------------------------------------- | -| Type beheersmaatregel: | #Preventief | -| Informatiebeveiligingseigenschappen: | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | -| Cybersecurityconcepten: | #Identificeren | -| Operationele capaciteiten: | #Governance | -| Beveiligingsdomeinen: | #Governance_en_Eco-systeem #Veerkracht | - -**Beheersmaatregel** +### Beheersmaatregel Informatiebeveiligingsbeleid en onderwerpspecifieke beleidsregels behoren te worden gedefinieerd, goedgekeurd door het management, gepubliceerd, gecommuniceerd aan en erkend door relevant personeel en relevante belanghebbenden en met geplande tussenpozen of zodra zich belangrijke veranderingen voordoen, te worden beoordeeld. -**Doel** +### Doel De voortdurende geschiktheid, toereikendheid, doeltreffendheid van de sturing en ondersteuning door het management overeenkomstig de bedrijfseisen en de eisen van wet- en regelgeving, statutaire en contractuele eisen bewerkstelligen. -**Richtlijn** +### Richtlijn De organisatie behoort op het hoogste niveau een 'informatiebeveiligingsbeleid' te definiëren dat is goedgekeurd door de directie en dat de aanpak van de organisatie beschrijft om haar informatiebeveiliging te bereiken. @@ -109,6 +120,5 @@ Tabel 1 illustreert de verschillen tussen informatiebeveiligingsbeleid en onderw | **Detailniveau** | Algemeen of op hoofdlijnen | Specifiek en gedetailleerd | | **Gedocumenteerd en formeel goedgekeurd door** | De directie | Het passende managementniveau | -**Overige informatie** +### Overige informatie -Onderwerpspecifieke beleidsregels kunnen van organisatie tot organisatie verschillen. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-5.10-Aanvaardbaar-gebruik-van-informatie-en-andere-gerelateerde-bedrijfsmiddelen.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-5.10-Aanvaardbaar-gebruik-van-informatie-en-andere-gerelateerde-bedrijfsmiddelen.md index 8df21eb..e5fe86d 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-5.10-Aanvaardbaar-gebruik-van-informatie-en-andere-gerelateerde-bedrijfsmiddelen.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-5.10-Aanvaardbaar-gebruik-van-informatie-en-andere-gerelateerde-bedrijfsmiddelen.md @@ -1,27 +1,39 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "5.10" +title: "Aanvaardbaar gebruik van informatie en andere gerelateerde bedrijfsmiddelen" +theme: Organizational +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: + - Asset_management + - Information_protection +security_domains: + - Governance_and_Ecosystem + - Protection +tags: +- iso27002/2022/NL +- sourcetext +status: active --- ## 5.10 Aanvaardbaar gebruik van informatie en andere gerelateerde bedrijfsmiddelen - - -| Attribuut | Waarde | -| :----------------------------------- | :----------------------------------------------------- | -| Type beheersmaatregel: | #Preventief | -| Informatiebeveiligingseigenschappen: | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | -| Cybersecurityconcepten: | #Beschermen | -| Operationele capaciteiten: | #Beheer_van_bedrijfsmiddelen #Informatiebescherming | -| Beveiligingsdomeinen: | #Governance_en_Ecosysteem #Bescherming | - -**Beheersmaatregel** +### Beheersmaatregel Regels voor het aanvaardbaar gebruik van en procedures voor het omgaan met informatie en andere gerelateerde bedrijfsmiddelen behoren te worden vastgesteld, gedocumenteerd en geïmplementeerd. -**Doel** +### Doel Waarborgen dat informatie en andere gerelateerde bedrijfsmiddelen passend worden beschermd, gebruikt en behandeld. -**Richtlijn** +### Richtlijn Personeel en externe gebruikers die informatie en andere gerelateerde bedrijfsmiddelen van de organisatie gebruiken of er toegang toe hebben, behoren bewust te worden gemaakt van de informatiebeveiligingseisen voor het beschermen van en omgaan met de informatie van de organisatie en andere gerelateerde bedrijfsmiddelenij behoren verantwoordelijk te zijn voor het gebruik dat zij maken van informatieverwerkende faciliteiten. @@ -47,6 +59,5 @@ e) duidelijke markering van alle kopieën van (elektronische of fysieke) opslagm f) autorisatie van het verwijderen van informatie en andere gerelateerde bedrijfsmiddelen en ondersteunde wismethode(n) (zie [8.10](a-8.10-Wissen-van-informatie.md)). -**Overige informatie** +### Overige informatie -Het is mogelijk dat de desbetreffende bedrijfsmiddelen niet direct tot de organisatie behoren, zoals openbare clouddienstenet gebruik van zulke bedrijfsmiddelen van derden en van bedrijfsmiddelen van de organisatie in verband met zulke externe bedrijfsmiddelen (bijv. informatie, software) behoort te worden geïdentificeerd al naargelang de situatie en beheerst, bijvoor middel van overeenkomsten met aanbieders van clouddienstenndien er gebruik wordt gemaakt van een op samenwerking gerichte werkomgeving, behoort er ook zorgvuldig te worden gehandeld. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-5.11-Retourneren-van-bedrijfsmiddelen.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-5.11-Retourneren-van-bedrijfsmiddelen.md index b74c7d6..c41e16e 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-5.11-Retourneren-van-bedrijfsmiddelen.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-5.11-Retourneren-van-bedrijfsmiddelen.md @@ -1,28 +1,35 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "5.11" +title: "Retourneren van bedrijfsmiddelen" +theme: Organizational +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: [Asset_management] +security_domains: [Protection] +tags: +- iso27002/2022/NL +- sourcetext +status: active --- ## 5.11 Retourneren van bedrijfsmiddelen - - -| Attribuut | Waarde | -| :----------------------------------- | :----------------------------------------------------- | -| Type beheersmaatregel: | #Preventief | -| Informatiebeveiligingseigenschappen: | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | -| Cybersecurityconcepten: | #Beschermen | -| Operationele capaciteiten: | #Beheer_van_bedrijfsmiddelen | -| Beveiligingsdomeinen: | #Bescherming | - - -**Beheersmaatregel** +### Beheersmaatregel Personeel en andere belanghebbenden, al naargelang de situatie, behoren alle bedrijfsmiddelen van de organisatie die ze in hun bezit hebben bij beëindiging van hun dienstverband, contract of overeenkomst te retourneren. -**Doel** +### Doel De bedrijfsmiddelen van de organisatie beschermen als onderdeel van de procedure voor het wijzigen of beëindigen van het dienstverband, het contract of de overeenkomst. -**Richtlijn** +### Richtlijn In de wijzigings- of beëindigingsprocedure behoort formeel het retourneren van alle eerder verstrekte fysieke en elektronische bedrijfsmiddelen die het eigendom zijn van of toevertrouwd zijn aan de organisatie, te worden opgenomen. @@ -44,6 +51,5 @@ d) authenticatiehardware (bijv. mechanische sleutels, fysieke tokens en chipkaar e) fysieke kopieën van informatie. -**Overige informatie** +### Overige informatie -Het kan lastig zijn informatie te retourneren die zich bevindt op bedrijfsmiddelen die geen eigendom zijn van de organisatien dergelijke gevallen is het nodig het gebruik van informatie door middel van andere beheersmaatregelen voor informatiebeveiliging, zoals het beheer van toegangsrechten (5.18) of het gebruik van cryptografie (8.24) te beperken. diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-5.12-Classificeren-van-informatie.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-5.12-Classificeren-van-informatie.md index 7d26163..e968fdc 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-5.12-Classificeren-van-informatie.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-5.12-Classificeren-van-informatie.md @@ -1,26 +1,37 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "5.12" +title: "Classificeren van informatie" +theme: Organizational +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Identify] +operational_capabilities: [Information_protection] +security_domains: + - Protection + - Defence +tags: +- iso27002/2022/NL +- sourcetext +status: active --- ## 5.12 Classificeren van informatie - -| Attribuut | Waarde | -| :----------------------------------- | :----------------------------------------------- | -| Type beheersmaatregel: | #Preventief | -| Informatiebeveiligingseigenschappen: | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | -| Cybersecurityconcepten: | #Identificeren | -| Operationele capaciteiten: | #Informatiebescherming | -| Beveiligingsdomeinen: | #Bescherming #Verdediging | - -**Beheersmaatregel** +### Beheersmaatregel Informatie behoort te worden geclassificeerd volgens de informatiebeveiligingsbehoeften van de organisatie, op basis van de eisen voor vertrouwelijkheid, integriteit, beschikbaarheid en relevante belanghebbenden. -**Doel** +### Doel Bewerkstelligen dat het identificeren van en het inzicht in de beschermingsbehoeften voor informatie in overeenstemming zijn met het belang ervan voor de organisatie. -**Richtlijn** +### Richtlijn De organisatie behoort een onderwerpspecifiek beleid inzake het classificeren van informatie vast te stellen en aan alle relevante belanghebbenden mee te delen. @@ -40,7 +51,7 @@ Het schema behoort organisatiebreed consistent te zijn en te zijn opgenomen in d Het binnen de organisatie gebruikte classificatieschema kan verschillen van de schema's die andere organisaties gebruiken, zelf als de namen voor niveaus op elkaar lijkenovendien kan de classificatie van informatie die tussen organisaties wordt getransporteerd verschillen, afhankelijk van de context ervan binnen elke organisatie, zelfs als de organisaties dezelfde classificatieschema's gebruiken. Daarom behoren overeenkomsten met andere organisaties waarin het delen van informatie voorkomt, procedures te bevatten voor het identificeren van de classificatie van die informatie en voor het interpreteren van de classificatieniveaus van andere organisaties. De overeenstemming tussen verschillende schema's kan worden vastgesteld door te zoeken naar gelijkwaardigheid in de gerelateerde methoden voor hantering en bescherming. -**Overige informatie** +### Overige informatie Classificatie biedt personen die met informatie omgaan, een beknopte indicatie van hoe deze te behandelen en te beschermen. Het aanmaken van informatiegroepen met gelijksoortige beschermingsbehoeften en het specificeren van informatiebeveiligingsprocedures die gelden voor alle informatie in elke groep, vergemakkelijken diteze aanpak vermindert de behoefte aan afzonderlijke risicobeoordeling en speciaal ontworpen beheersmaatregelen. @@ -51,4 +62,3 @@ Bij wijze van voorbeeld kan een classificatieschema betreffende de vertrouwelijk a) openbaarmaking veroorzaakt geen schade; b) openbaarmaking veroorzaakt geringe reputatieschade of een geringe operationele impact; c) openbaarmaking heeft een kortdurende significante impact op de operationele of bedrijfsdoelstellingen; -d) openbaarmaking heeft een ernstige impact op de langetermijnbedrijfsdoelstellingen of brengt het voortbestaan van de organisatie in gevaar. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-5.13-Labelen-van-informatie.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-5.13-Labelen-van-informatie.md index cdafd81..9f2e98b 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-5.13-Labelen-van-informatie.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-5.13-Labelen-van-informatie.md @@ -1,26 +1,37 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "5.13" +title: "Labelen van informatie" +theme: Organizational +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: [Information_protection] +security_domains: + - Defence + - Protection +tags: +- iso27002/2022/NL +- sourcetext +status: active --- ## 5.13 Labelen van informatie - -| Attribuut | Waarde | -| :----------------------------------- | :----------------------------------------------- | -| Type beheersmaatregel: | #Preventief | -| Informatiebeveiligingseigenschappen: | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | -| Cybersecurityconcepten: | #Beschermen | -| Operationele capaciteiten: | #Informatiebescherming | -| Beveiligingsdomeinen: | #Verdediging #Bescherming | - -**Beheersmaatregel** +### Beheersmaatregel Om informatie te labelen behoort een passende reeks procedures te worden vastgesteld en geïmplementeerd in overeenstemming met het informatieclassificatieschema dat is vastgesteld door de organisatie. -**Doel** +### Doel Het communiceren van de classificatie van informatie mogelijk maken en het automatiseren van informatieverwerking en -beheer ondersteunen. -**Richtlijn** +### Richtlijn Procedures voor het labelen van informatie behoren te gaan over informatie en andere gerelateerde bedrijfsmiddelen in alle formatene labeling behoort in overeenstemming te zijn met het classificatieschema vastgesteld in 5e labels behoren gemakkelijk herkenbaar te zijne procedures behoren richtlijnen te geven over waar en hoe labels zijn bevestigd, rekening houdend met hoe de informatie wordt bereikt of hoe de bedrijfsmiddelen worden gehanteerd afhankelijk van de soorten opslagmediae procedures kunnen het volgende definiëren: @@ -52,7 +63,7 @@ Personeel en andere belanghebbenden behoren op de hoogte te worden gebracht van Output van systemen die informatie bevatten die is geclassificeerd als gevoelig of essentieel, behoort een passend classificatielabel te dragen. -**Overige informatie** +### Overige informatie Het labelen van geclassificeerde informatie is een belangrijke eis voor het delen van informatie. @@ -60,4 +71,3 @@ Andere nuttige metagegevens die aan de informatie kunnen worden gekoppeld, zijn Het labelen van informatie en andere gerelateerde bedrijfsmiddelen kan soms negatieve effecten hebben. Geclassificeerde bedrijfsmiddelen zijn gemakkelijker te identificeren door kwaadwillenden, die daarvan mogelijk misbruik maken. -Bepaalde systemen voorzien individuele bestanden of registraties in databases niet van labels met de classificatie, maar beschermen alle informatie op het hoogste classificatieniveau van de informatie die erin vervat is of mag zijnet is gebruikelijk in dergelijke systemen dat informatie wordt geïdentificeerd en vervolgens gelabeld op het moment van exporteren. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-5.14-Overdragen-van-informatie.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-5.14-Overdragen-van-informatie.md index 937ddb7..cf556ba 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-5.14-Overdragen-van-informatie.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-5.14-Overdragen-van-informatie.md @@ -1,27 +1,37 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "5.14" +title: "Overdragen van informatie" +theme: Organizational +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: + - Asset_management + - Information_protection +security_domains: [Protection] +tags: +- iso27002/2022/NL +- sourcetext +status: active --- ## 5.14 Overdragen van informatie - -| Attribuut | Waarde | -| :----------------------------------- | :-------------------------------------------------- | -| Type beheersmaatregel: | #Preventief | -| Informatiebeveiligingseigenschappen: | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | -| Cybersecurityconcepten: | #Beschermen | -| Operationele capaciteiten: | #Beheer_van_bedrijfsmiddelen #Informatiebescherming | -| Beveiligingsdomeinen: | #Bescherming | - - -**Beheersmaatregel** +### Beheersmaatregel Er behoren regels, procedures of overeenkomsten voor informatieoverdracht te zijn vastgesteld voor alle soorten van overdracht binnen de organisatie en tussen de organisatie en andere partijen. -**Doel** +### Doel Handhaven van de beveiliging van informatie die wordt uitgewisseld binnen een organisatie en met een externe belanghebbende. -**Richtlijn** +### Richtlijn <u>Algemeen</u> @@ -113,5 +123,4 @@ d) behoren te waarborgen dat passende beheersmaatregelen voor de ruimte zijn ge e) gevoelige gesprekken altijd behoren te beginnen met een disclaimer zodat de aanwezigen het classificatieniveau kennen van wat ze gaan horen en eventuele eisen met betrekking tot de omgang ermee. -**Overige informatie** -Geen overige informatie. \ No newline at end of file +### Overige informatie diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-5.15-Toegangsbeveiliging.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-5.15-Toegangsbeveiliging.md index ab9fb3d..8e41e36 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-5.15-Toegangsbeveiliging.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-5.15-Toegangsbeveiliging.md @@ -1,27 +1,35 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "5.15" +title: "Toegangsbeveiliging" +theme: Organizational +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: [Identity_and_access_management] +security_domains: [Protection] +tags: +- iso27002/2022/NL +- sourcetext +status: active --- ## 5.15 Toegangsbeveiliging - -| Attribuut | Waarde | -| :----------------------------------- | :----------------------------------------------- | -| Type beheersmaatregel: | #Preventief | -| Informatiebeveiligingseigenschappen: | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | -| Cybersecurityconcepten: | #Beschermen | -| Operationele capaciteiten: | #Identiteits-_en_toegangsbeheer | -| Beveiligingsdomeinen: | #Bescherming | - - -**Beheersmaatregel** +### Beheersmaatregel Er behoren regels op basis van bedrijfs- en informatiebeveiligingseisen te worden vastgesteld en geïmplementeerd om de fysieke en logische toegang tot informatie en andere gerelateerde bedrijfsmiddelen te beheersen. -**Doel** +### Doel Toegang voor bevoegden bewerkstelligen en toegang voor onbevoegden tot informatie en andere gerelateerde bedrijfsmiddelen voorkomen. -**Richtlijn** +### Richtlijn Eigenaren van informatie en andere gerelateerde bedrijfsmiddelen behoren informatiebeveiligings- en bedrijfseisen met betrekking tot toegangsbeveiliging vast te stellen. Er behoort onderwerpspecifiek beleid inzake toegangsbeveiliging te worden gedefinieerd waarin rekening wordt gehouden met deze eisen en dit behoort naar alle desbetreffende belanghebbenden te worden gecommuniceerd. @@ -61,7 +69,7 @@ c) het in aanmerking nemen van alle soorten beschikbare verbindingen in gedistri d) het overwegen hoe elementen of factoren die relevant zijn voor dynamische toegangsbeveiliging kunnen worden weergegeven. -**Overige informatie** +### Overige informatie Er worden vaak overkoepelende principes gebruikt in de toegangsbeveiligingscontext. Twee van de meest gebruikte principes zijn: @@ -83,4 +91,3 @@ Regels voor toegangsbeveiliging behoren te worden ondersteund door formele proce Er zijn diverse manieren om toegangsbeveiliging te implementeren, waaronder MAC ('mandatory access control' - verplichte toegangsbeveiliging), DAC ('discretionary access control' - discretionaire toegangsbeveiliging), RBAC ('role-based access control' - op rollen gebaseerde toegangsbeveiliging) en ABAC ('attribute-based access control' - op attributen gebaseerde toegangsbeveiliging). -Regels voor toegangsbeveiliging kunnen ook dynamische elementen bevatten (bijv. een functie die toegangsinstanties uit het verleden of specifieke omgevingswaarden beoordeelt). Regels voor toegangsbeveiliging kunnen met verschillende granulariteit worden geïmplementeerd, uiteenlopend van het afdekken van volledige netwerken of systemen tot specifieke gegevensvelden, en hierbij kunnen ook eigenschappen zoals de locatie van de gebruiker of het soort netwerkverbinding dat voor de toegang wordt gebruikt, in aanmerking worden genomeneze principes, evenals de wijze waarop granulaire toegangsbeveiliging wordt gedefinieerd, kunnen een aanmerkelijk kosteneffect hebbentrengere regels en meer granulariteit leiden doorgaans tot hogere kostenan de hand van bedrijfseisen en risico-overwegingen behoort te worden gedefinieerd welke regels voor toegangsbeveiliging worden toegepast en welke granulariteit vereist is. diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-5.16-Identiteitsbeheer.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-5.16-Identiteitsbeheer.md index 738a0a8..44dbab6 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-5.16-Identiteitsbeheer.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-5.16-Identiteitsbeheer.md @@ -1,27 +1,35 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "5.16" +title: "Identiteitsbeheer" +theme: Organizational +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: [Identity_and_access_management] +security_domains: [Protection] +tags: +- iso27002/2022/NL +- sourcetext +status: active --- ## 5.16 Identiteitsbeheer - -| Attribuut | Waarde | -| :----------------------------------- | :----------------------------------------------- | -| Type beheersmaatregel: | #Preventief | -| Informatiebeveiligingseigenschappen: | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | -| Cybersecurityconcepten: | #Beschermen | -| Operationele capaciteiten: | #Identiteits-_en_toegangsbeheer | -| Beveiligingsdomeinen: | #Bescherming | - - -**Beheersmaatregel** +### Beheersmaatregel De volledige levenscyclus van identiteiten behoort te worden beheerd. -**Doel** +### Doel De unieke identificatie van personen en systemen die toegang hebben tot de informatie en andere gerelateerde bedrijfsmiddelen van de organisatie, en een juiste toewijzing van toegangsrechten mogelijk maken. -**Richtlijn** +### Richtlijn De processen die worden gebruikt in de context van identiteitsbeheer, behoren te bewerkstelligen dat: @@ -41,7 +49,7 @@ De organisatie behoort een ondersteunend proces te hebben ingesteld voor het omg Wanneer gebruik wordt gemaakt van door derden verstrekte of uitgegeven identiteiten (bijvoegangsgegevens voor sociale media), behoort de organisatie te bewerkstelligen dat deze identiteiten van derden de vereiste mate van vertrouwen bieden en dat eventueel daarmee samenhangende risico's bekend zijn en voldoende worden behandeldit kan beheersmaatregelen in verband met de derden (zie [5.19](a-5.19-Informatiebeveiliging-in-leveranciersrelaties.md)) alsmede beheersmaatregelen in verband met gerelateerde authenticatie-informatie (zie [5.17](a-5.17-Beheren-van-authenticatie-informatie.md)) omvatten. -**Overige informatie** +### Overige informatie Het verlenen of intrekken van toegang tot informatie en andere gerelateerde bedrijfsmiddelen is doorgaans een meerstapsprocedure: @@ -53,4 +61,3 @@ c) het vaststellen van een identiteit; d) het configureren en activeren van de identiteitit omvat ook het configureren en initieel instellen van gerelateerde authenticatiediensten; -e) het verlenen of intrekken van specifieke toegangsrechten aan de identiteit, op basis van passende beslissingen over autorisatie of rechten (zie [5.18](a-5.18-Toegangsrechten.md)). \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-5.17-Beheren-van-authenticatie-informatie.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-5.17-Beheren-van-authenticatie-informatie.md index f60d0ab..39efec4 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-5.17-Beheren-van-authenticatie-informatie.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-5.17-Beheren-van-authenticatie-informatie.md @@ -1,17 +1,26 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "5.17" +title: "Beheren van authenticatie-informatie" +theme: Organizational +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: [Identity_and_access_management] +security_domains: [Protection] +tags: +- iso27002/2022/NL +- sourcetext +status: active --- ## 5.17 Beheren van authenticatie-informatie - -| Attribuut | Waarde | -| :----------------------------------- | :----------------------------------------------- | -| Type beheersmaatregel: | #Preventief | -| Informatiebeveiligingseigenschappen: | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | -| Cybersecurityconcepten: | #Beschermen | -| Operationele capaciteiten: | #Identiteits-_en_toegangsbeheer | -| Beveiligingsdomeinen: | #Bescherming | - ### Beheersmaatregel De toewijzing en het beheer van authenticatie-informatie behoort te worden beheerst door middel van een beheerproces waarvan het informeren van het personeel over de juiste manier van omgaan met authenticatie-informatie deel uitmaakt. ### Doel @@ -85,4 +94,3 @@ Wachtwoorden of wachtzinnen zijn een algemeen gebruikt type authenticatie-inform Verplichten dat wachtwoorden vaak worden gewijzigd kan een probleem zijn, aangezien gebruikers geïrriteerd kunnen raken door de frequente wijzigingen, nieuwe wachtwoorden kunnen vergeten, ze op onveilige plaatsen kunnen noteren, of onveilige wachtwoorden kunnen kiezen. Als 'Single Sign On' (SSO) of andere authenticatiebeheerinstrumenten (bijv. wachtwoordkluizen) beschikbaar worden gesteld, vermindert dat de hoeveelheid authenticatie-informatie die gebruikers moeten beschermen, waardoor de doeltreffendheid van deze beheersmaatregel kan toenemen. Echter, deze instrumenten kunnen ook de impact van openbaarmaking van authenticatie-informatie vergroten. -Bepaalde toepassingen vereisen dat wachtwoorden voor gebruikers door een onafhankelijke instantie worden toegewezen. In dergelijke gevallen zijn de punten a), c) en d) van 'Systeem voor wachtwoordbeheer' niet van toepassing. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-5.18-Toegangsrechten.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-5.18-Toegangsrechten.md index a6dfba1..4f51d23 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-5.18-Toegangsrechten.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-5.18-Toegangsrechten.md @@ -1,28 +1,35 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "5.18" +title: "Toegangsrechten" +theme: Organizational +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: [Identity_and_access_management] +security_domains: [Protection] +tags: +- iso27002/2022/NL +- sourcetext +status: active --- - ## 5.18 Toegangsrechten - -| Attribuut | Waarde | -| :----------------------------------- | :----------------------------------------------- | -| Type beheersmaatregel: | #Preventief | -| Informatiebeveiligingseigenschappen: | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | -| Cybersecurityconcepten: | #Beschermen | -| Operationele capaciteiten: | #Identiteits-_en_toegangsbeheer | -| Beveiligingsdomeinen: | #Bescherming | - - -**Beheersmaatregel** +### Beheersmaatregel Toegangsrechten met betrekking tot informatie en andere gerelateerde bedrijfsmiddelen behoren te worden verstrekt, beoordeeld, aangepast en verwijderd overeenkomstig het onderwerpspecifieke beleid en de regels inzake toegangsbeveiliging van de organisatie. -**Doel** +### Doel Bewerkstelligen dat de toegang tot informatie en andere gerelateerde bedrijfsmiddelen wordt vastgesteld en goedgekeurd overeenkomstig de bedrijfseisen. -**Richtlijn** +### Richtlijn <u>Verlenen en intrekken van toegangsrechten</u> @@ -84,7 +91,7 @@ c) de waarde van de bedrijfsmiddelen die op dat moment toegankelijk zijn. -**Overige informatie** +### Overige informatie @@ -100,4 +107,3 @@ Ingeval het management de beëindiging van het dienstverband heeft geïnitieerd, -Klonen is een doelmatige manier waarop organisaties toegang aan gebruikers kunnen toewijzenit behoort echter met zorg te gebeuren, op basis van door de organisatie vastgestelde onderscheiden rollen, in plaats van een identiteit met alle gerelateerde toegangsrechten zomaar te klonenan het klonen is het inherente risico verbonden dat het leidt tot buitensporige toegangsrechten tot informatie en andere gerelateerde bedrijfsmiddelen. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-5.19-Informatiebeveiliging-in-leveranciersrelaties.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-5.19-Informatiebeveiliging-in-leveranciersrelaties.md index db1bd16..6483c6c 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-5.19-Informatiebeveiliging-in-leveranciersrelaties.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-5.19-Informatiebeveiliging-in-leveranciersrelaties.md @@ -1,28 +1,37 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "5.19" +title: "Informatiebeveiliging in leveranciersrelaties" +theme: Organizational +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Identify] +operational_capabilities: [Supplier_relationships_security] +security_domains: + - Governance_and_Ecosystem + - Protection +tags: +- iso27002/2022/NL +- sourcetext +status: active --- - -| Attribuut | Waarde | -| :----------------------------------- | :----------------------------------------------- | -| Type beheersmaatregel: | #Preventief | -| Informatiebeveiligingseigenschappen: | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | -| Cybersecurityconcepten: | #Identificeren | -| Operationele capaciteiten: | #Beveiliging_in_leveranciersrelaties | -| Beveiligingsdomeinen: | #Governance_en_Eco-systeem #Bescherming | - - ## 5.19 Informatiebeveiliging in leveranciersrelaties - -**Beheersmaatregel** +### Beheersmaatregel Er behoren processen en procedures te worden vastgesteld en geïmplementeerd om de informatiebeveiligingsrisico's in verband met het gebruik van producten of diensten van de leverancier te beheren. -**Doel** +### Doel Een overeengekomen niveau van informatiebeveiliging in leveranciersrelaties in stand houden. -**Richtlijn** +### Richtlijn De organisatie behoort een onderwerpspecifiek beleid inzake leveranciersrelaties vast te stellen en aan alle relevante belanghebbenden mee te delen. @@ -72,7 +81,7 @@ n) het niveau van beveiliging van personeel en fysieke beveiliging dat wordt ver Er behoort te worden nagedacht over de procedures voor het voortzetten van de verwerking van informatie indien de leverancier zijn producten of diensten niet meer kan leveren (bijvls gevolg van een incident, omdat de leverancier zijn bedrijf heeft gestaakt, of bepaalde onderdelen niet meer levert als gevolg van technologische ontwikkelingen) om vertraging bij het regelen van vervangende producten of diensten te voorkomen (bijvoor van tevoren een alternatieve leverancier aan te wijzen of altijd gebruik te maken van alternatieve leveranciers). -**Overige informatie** +### Overige informatie In gevallen waarin het voor een organisatie niet mogelijk is eisen te stellen aan een leverancier, behoort de organisatie: @@ -89,4 +98,3 @@ Ander voorbeeld vormen risico\'s voor de bescherming van persoonlijke gegevens a Risico\'s kunnen ook worden veroorzaakt door ontoereikende beheersmaatregelen van door leveranciers geleverde ICT-infrastructuurcomponenten of -dienstenomponenten of diensten met storingen of kwetsbaarheden kunnen inbreuken op de informatiebeveiliging in de organisatie of voor een andere entiteit veroorzaken. Ze kunnen bijvoorbeeld besmetting met malware, aanvallen of andere schade aan andere entiteiten dan de organisatie veroorzaken. -Zie ISO/IEC 27036-2 voor nadere details. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-5.2-Rollen-en-verantwoordelijkheden-bij-informatiebeveiliging.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-5.2-Rollen-en-verantwoordelijkheden-bij-informatiebeveiliging.md index 46e7d88..0523ff3 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-5.2-Rollen-en-verantwoordelijkheden-bij-informatiebeveiliging.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-5.2-Rollen-en-verantwoordelijkheden-bij-informatiebeveiliging.md @@ -1,26 +1,38 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "5.2" +title: "Rollen en verantwoordelijkheden bij informatiebeveiliging" +theme: Organizational +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Identify] +operational_capabilities: [Governance] +security_domains: + - Governance_and_Ecosystem + - Protection + - Resilience +tags: +- iso27002/2022/NL +- sourcetext +status: active --- ## 5.2 Rollen en verantwoordelijkheden bij informatiebeveiliging - -| Attribuut | Waarde | -| :----------------------------------- | :------------------------------------------------- | -| Type beheersmaatregel: | #Preventief | -| Informatiebeveiligingseigenschappen: | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | -| Cybersecurityconcepten: | #Identificeren | -| Operationele capaciteiten: | #Governance | -| Beveiligingsdomeinen: | #Governance_en_Ecosysteem #Bescherming #Veerkracht | - -**Beheersmaatregel** +### Beheersmaatregel Rollen en verantwoordelijkheden bij informatiebeveiliging behoren te worden gedefinieerd en toegewezen overeenkomstig de behoeften van de organisatie. -**Doel** +### Doel Een gedefinieerde, goedgekeurde en duidelijk te begrijpen structuur voor de implementatie, uitvoering en het beheer van informatiebeveiliging binnen de organisatie inrichten. -**Richtlijn** +### Richtlijn Het toewijzen van de rollen en verantwoordelijkheden die bij informatiebeveiliging horen, behoort te worden gedaan in overeenstemming met het beleid voor informatiebeveiliging en onderwerpspecifieke beleidsregels (zie [5.1](a-5.1-Beleidsregels-voor-informatiebeveiliging.md)). De organisatie behoort verantwoordelijkheden te definiëren en te beheren voor: @@ -36,10 +48,9 @@ Deze verantwoordelijkheden behoren waar nodig te worden aangevuld met meer gedet Elk beveiligingsgebied waarvoor personen verantwoordelijk zijn, behoort te worden gedefinieerd, gedocumenteerd en gecommuniceerdutorisatieniveaus behoren te worden gedefinieerd en gedocumenteerdersonen die een specifieke rol op het gebied van informatiebeveiliging op zich nemen, behoren competent te zijn wat betreft de kennis en vaardigheden die de rol vereist en behoren te worden ondersteund bij het op de hoogte blijven van de ontwikkelingen die verband houden met de rol en die vereist zijn om aan de verantwoordelijkheden van de rol te kunnen voldoen. -**Overige informatie** +### Overige informatie Veel organisaties benoemen een manager informatiebeveiliging die de algehele verantwoordelijkheid draagt voor de ontwikkeling en implementatie van informatiebeveiliging en om de identificatie van risico\'s en beperkende beheersmaatregelen te ondersteunen. Echter, de verantwoordelijkheid voor het verzorgen en implementeren van de beheersmaatregelen blijft vaak een taak van individuele managersen gangbare praktijk is om voor elk bedrijfsmiddel een eigenaar te benoemen die verantwoordelijk wordt voor de dagelijkse bescherming ervan. -Afhankelijk van de omvang en de middelen van een organisatie kan informatiebeveiliging door speciale rollen of door functies die naast bestaande rollen worden uitgevoerd, worden afgedekt. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-5.20-Adresseren-van-informatiebeveiliging-in-leveranciersovereenkomsten.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-5.20-Adresseren-van-informatiebeveiliging-in-leveranciersovereenkomsten.md index 0cc7bc0..bac455f 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-5.20-Adresseren-van-informatiebeveiliging-in-leveranciersovereenkomsten.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-5.20-Adresseren-van-informatiebeveiliging-in-leveranciersovereenkomsten.md @@ -1,27 +1,37 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "5.20" +title: "Adresseren van informatiebeveiliging in leveranciersovereenkomsten" +theme: Organizational +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Identify] +operational_capabilities: [Supplier_relationships_security] +security_domains: + - Governance_and_Ecosystem + - Protection +tags: +- iso27002/2022/NL +- sourcetext +status: active --- - ## 5.20 Adresseren van informatiebeveiliging in leveranciersovereenkomsten - -| Attribuut | Waarde | -| :----------------------------------- | :----------------------------------------------- | -| Type beheersmaatregel: | #Preventief | -| Informatiebeveiligingseigenschappen: | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | -| Cybersecurityconcepten: | #Identificeren | -| Operationele capaciteiten: | #Beveiliging_in_leveranciersrelaties | -| Beveiligingsdomeinen: | #Governance_en_Eco-systeem #Bescherming | - -**Beheersmaatregel** +### Beheersmaatregel Relevante informatiebeveiligingseisen behoren te worden vastgesteld en met elke leverancier op basis van het type leveranciersrelatie te worden overeengekomen. -**Doel** +### Doel Een overeengekomen niveau van informatiebeveiliging in leveranciersrelaties in stand houden. -**Richtlijn** +### Richtlijn Leveranciersovereenkomsten behoren te worden vastgesteld en gedocumenteerd om te waarborgen dat er tussen de organisatie en de leverancier duidelijkheid bestaat ten aanzien van de verplichtingen van beide partijen om te voldoen aan relevante informatiebeveiligingseisen. @@ -81,9 +91,8 @@ z) het bewerkstelligen van ondersteuning bij de overdracht aan een andere levera De organisatie behoort een register van afspraken met externe partijen (bijv. contracten, een memorandum van overeenstemming, overeenkomsten voor het delen van informatie) op te stellen en te onderhouden om bij te houden waar haar informatie naartoe gaate organisatie behoort ook haar overeenkomsten met externe partijen regelmatig te beoordelen, te valideren en bij te werken om te garanderen dat ze nog steeds vereist zijn en geschikt zijn voor het doel en dat ze relevante clausules over informatiebeveiliging bevatten. -**Overige informatie** +### Overige informatie De overeenkomsten kunnen voor de verschillende organisaties en de verschillende soorten leveranciers aanzienlijk variërenerhalve behoort erop te worden toegezien dat alle relevante eisen voor het oppakken van informatiebeveiligingsrisico's erin worden opgenomen. Voor gegevens over overeenkomsten met leveranciers, zie de ISO/IEC 27036-reeks. Voor gegevens over overeenkomsten voor clouddiensten, zie de ISO/IEC 19086-reeks. - diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-5.21-Beheren-van-informatiebeveiliging-in-de-ICT-keten.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-5.21-Beheren-van-informatiebeveiliging-in-de-ICT-keten.md index fdecb94..1aeed8c 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-5.21-Beheren-van-informatiebeveiliging-in-de-ICT-keten.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-5.21-Beheren-van-informatiebeveiliging-in-de-ICT-keten.md @@ -1,32 +1,37 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "5.21" +title: "Beheren van informatiebeveiliging in de ICT-keten" +theme: Organizational +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Identify] +operational_capabilities: [Supplier_relationships_security] +security_domains: + - Governance_and_Ecosystem + - Protection +tags: +- iso27002/2022/NL +- sourcetext +status: active --- - - -| Attribuut | Waarde | -| :----------------------------------- | :----------------------------------------------- | -| Type beheersmaatregel: | #Preventief | -| Informatiebeveiligingseigenschappen: | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | -| Cybersecurityconcepten: | #Identificeren | -| Operationele capaciteiten: | #Beveiliging_in_leveranciersrelaties | -| Beveiligingsdomeinen: | #Governance_en_Eco-systeem #Bescherming | - - - - ## 5.21 Beheren van informatiebeveiliging in de ICT-keten - - -**Beheersmaatregel** +### Beheersmaatregel Er behoren processen en procedures te worden vastgesteld en geïmplementeerd om de informatiebeveiligingsrisico's in verband met de toeleveringsketen van ICT-producten en -diensten te beheren. -**Doel** +### Doel Een overeengekomen niveau van informatiebeveiliging in leveranciersrelaties in stand houden. -**Richtlijn** +### Richtlijn In aanvulling op de algemene informatiebeveiligingseisen voor leveranciersrelaties behoren de volgende informatiebeveiligingsonderwerpen in aanmerking te worden genomen binnen de beveiliging van de ITC-toeleveringsketen: @@ -58,7 +63,7 @@ l) regels definiëren voor het delen van informatie met betrekking tot de toelev m) specifieke processen implementeren voor het beheren van de levenscyclus en beschikbaarheid van ICT-componenten en gerelateerde beveiligingsrisico\'s. Dit omvat het beheren van de risico\'s dat onderdelen niet langer beschikbaar zijn omdat leveranciers hun bedrijf hebben gestaakt of deze onderdelen als gevolg van technologische ontwikkelingen niet meer aanbieden. Het identificeren van een alternatieve leverancier en het proces om software en competentie naar de alternatieve leverancier over te brengen behoren te worden overwogen. -**Overige informatie** +### Overige informatie De specifieke risicobeheerpraktijken betreffende de ICT-toeleveringsketen komen boven op de algemene praktijken van informatiebeveiliging, kwaliteit, projectmanagement en systeemengineering, maar vervangen deze niet. @@ -76,4 +81,3 @@ c) hostingdiensten, waar de aanbieder op externe servicebalies vertrouwt, met in Zie ISO/IEC 27036-3 voor nadere details met inbegrip van richtlijnen voor risicobeoordeling. -Software-identificatietags (SWID) kunnen ook bijdragen aan betere informatiebeveiliging in de toeleveringsketen, door informatie te geven over de herkomst van software. Zie ISO/IEC 19770-2 voor nadere details. diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-5.22-Monitoren-beoordelen-en-het-beheren-van-wijzigingen-van-leveranciersdiensten.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-5.22-Monitoren-beoordelen-en-het-beheren-van-wijzigingen-van-leveranciersdiensten.md index 82c0b22..411838b 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-5.22-Monitoren-beoordelen-en-het-beheren-van-wijzigingen-van-leveranciersdiensten.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-5.22-Monitoren-beoordelen-en-het-beheren-van-wijzigingen-van-leveranciersdiensten.md @@ -1,27 +1,39 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "5.22" +title: "Monitoren, beoordelen en het beheren van wijzigingen van leveranciersdiensten" +theme: Organizational +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Identify] +operational_capabilities: [Supplier_relationships_security] +security_domains: + - Governance_and_Ecosystem + - Protection + - Defence + - Information_security_assurance +tags: +- iso27002/2022/NL +- sourcetext +status: active --- - - -| Attribuut | Waarde | -| :----------------------------------- | :---------------------------------------------------------------------- | -| Type beheersmaatregel: | #Preventief | -| Informatiebeveiligingseigenschappen: | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | -| Cybersecurityconcepten: | #Identificeren | -| Operationele capaciteiten: | #Beveiliging_in_leveranciersrelaties #Borging_van_informatiebeveiliging | -| Beveiligingsdomeinen: | #Governance_en_Eco-systeem #Bescherming #Verdediging | - - -**Beheersmaatregel** +## 5.22 Monitoren, beoordelen en het beheren van wijzigingen van leveranciersdiensten +### Beheersmaatregel De organisatie behoort de informatiebeveiligingspraktijken en de leveranciersdiensten regelmatig te monitoren, beoordelen, evalueren en veranderingen daaraan te beheren. -**Doel** +### Doel Een overeengekomen niveau van informatiebeveiliging en dienstverlening in overeenstemming met de leveranciersovereenkomsten handhaven. -**Richtlijn** +### Richtlijn Het monitoren en beoordelen van, en het beheren van veranderingen aan, leveranciersdiensten behoort te bewerkstelligen dat aan de informatiebeveiligingsvoorwaarden van de overeenkomsten wordt voldaan, informatiebeveiligingsincidenten en -problemen naar behoren worden beheerd en veranderingen in leveranciersdiensten of de bedrijfsstatus niet van invloed zijn op de dienstverlening. @@ -69,6 +81,5 @@ m)regelmatig te evalueren of de leveranciers afdoende informatiebeveiligingsnive De verantwoordelijkheid voor het beheer van leveranciersrelaties behoort te worden toegekend aan een daarvoor aangewezen persoon of teamm te monitoren dat de eisen van de overeenkomst, in het bijzonder de informatiebeveiligingseisen, worden nagekomen, behoren voldoende technische vaardigheden en middelen beschikbaar te worden gesteldls tekortkomingen in de dienstverlening worden waargenomen behoren passende maatregelen te worden getroffen. -**Overige informatie** +### Overige informatie -Zie ISO/IEC 27036-3 voor nadere details. diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-5.23-Informatiebeveiliging-voor-het-gebruik-van-clouddiensten.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-5.23-Informatiebeveiliging-voor-het-gebruik-van-clouddiensten.md index d0725b4..e036e9d 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-5.23-Informatiebeveiliging-voor-het-gebruik-van-clouddiensten.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-5.23-Informatiebeveiliging-voor-het-gebruik-van-clouddiensten.md @@ -1,17 +1,37 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "5.23" +title: "Informatiebeveiliging voor het gebruik van clouddiensten" +theme: Organizational +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: [Supplier_relationships_security] +security_domains: + - Governance_and_Ecosystem + - Protection +tags: +- iso27002/2022/NL +- sourcetext +status: active --- - -**Beheersmaatregel** +## 5.23 Informatiebeveiliging voor het gebruik van clouddiensten +### Beheersmaatregel Processen voor het aanschaffen, gebruiken, beheren en beëindigen van clouddiensten behoren overeenkomstig de informatiebeveiligingseisen van de organisatie te worden opgesteld. -**Doel** +### Doel Informatiebeveiliging voor het gebruik van clouddiensten specificeren en beheren. -**Richtlijn** +### Richtlijn De organisatie behoort een onderwerpspecifiek beleid inzake het gebruik van clouddiensten vast te stellen en aan alle relevante belanghebbenden mee te delen. @@ -76,9 +96,8 @@ c) het gebruik van collega-aanbieders van clouddiensten of andere onderaannemers De organisatie die clouddiensten gebruikt, behoort nauw contact te onderhouden met haar aanbieders van de clouddiensteneze contacten maken wederzijdse uitwisseling mogelijk van informatie over informatiebeveiliging voor het gebruik van de clouddiensten, met inbegrip van een mechanisme voor zowel de aanbieder als de organisatie, in haar rol van afnemer van de clouddiensten, om elk kenmerk van de diensten te monitoren en tekortkomingen ten opzichte van de in de overeenkomsten opgenomen verbintenissen te melden. -**Overige informatie** +### Overige informatie Deze beheersmaatregel bekijkt cloudbeveiliging vanuit het oogpunt van de afnemer van de clouddienst(en). Aanvullende informatie met betrekking tot clouddiensten is te vinden in ISO/IEC 17788, ISO/IEC 17789 en ISO/IEC 22123-1. Specifieke informatie met betrekking tot clouds en overdraagbaarheid bij exitstrategieën is te vinden in ISO/IEC 19941. Specifieke informatie met betrekking tot informatiebeveiliging en publieke clouddiensten wordt beschreven in ISO/IEC 27017. Specifieke informatie met betrekking tot de bescherming van persoonsgegevens in publieke clouds die als verwerker van persoonsgegevens fungeren, wordt beschreven in ISO/IEC 27018. Leveranciers- relaties voor clouddiensten worden behandeld in ISO/IEC 27036-4 en clouddienstovereenkomsten en de inhoud ervan worden behandeld in de ISO/IEC 19086-reeks, waarbij ISO/IEC 19086-4 specifiek ingaat op beveiliging en privacy. - diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-5.24-Plannen-en-voorbereiden-van-het-beheer-van-informatiebeveiligingsincidenten.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-5.24-Plannen-en-voorbereiden-van-het-beheer-van-informatiebeveiligingsincidenten.md index b0d3658..b67a9e3 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-5.24-Plannen-en-voorbereiden-van-het-beheer-van-informatiebeveiligingsincidenten.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-5.24-Plannen-en-voorbereiden-van-het-beheer-van-informatiebeveiligingsincidenten.md @@ -1,36 +1,39 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "5.24" +title: "Plannen en voorbereiden van het beheer van informatiebeveiligingsincidenten" +theme: Organizational +control_type: [Corrective] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: + - Respond + - Recover +operational_capabilities: + - Governance + - Information_security_event_management +security_domains: [Defence] +tags: +- iso27002/2022/NL +- sourcetext +status: active --- - -| Attribuut | Waarde | -| :----------------------------------- | :----------------------------------------------- | -| Type beheersmaatregel: | #Corrigerend | -| Informatiebeveiligingseigenschappen: | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | -| Cybersecurityconcepten: | #Reageren | -| Operationele capaciteiten: | #Beheer_van_infor- matiebeveiligings- gebeurtenissen | -| Beveiligingsdomeinen: | #Verdediging | - - -| | | | | | -| **beheersmaatregel** | **beveiligings-** | **concepten** | **capaciteiten** | **domeinen** | -| | | | | | -| | **eigenschappen** | | | | -+========================+====================================================+======================+====================================================================+=====================+ -| #Corrigerend | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | #Reageren | #Governance #Beheer_van_infor- matiebeveiligings- gebeurtenissen | #Verdediging | -| | | | | | -| | | #Herstellen | | | -+------------------------+----------------------------------------------------+----------------------+--------------------------------------------------------------------+---------------------+ - -**Beheersmaatregel** +## 5.24 Plannen en voorbereiden van het beheer van informatiebeveiligingsincidenten +### Beheersmaatregel De organisatie behoort plannen op te stellen voor, en zich voor te bereiden op, het beheren van informatiebeveiligingsincidenten door processen, rollen en verantwoordelijkheden voor het beheer van informatiebeveiligingsincidenten te definiëren, vast te stellen en te communiceren. -**Doel** +### Doel Een snelle, doeltreffende, consistente en geordende reactie op informatiebeveiligingsincidenten, met inbegrip van communicatie over informatiebeveiligingsgebeurtenissen, bewerkstelligen. -**Richtlijn** +### Richtlijn <u>Rollen en verantwoordelijkheden</u> @@ -108,8 +111,7 @@ Bij het implementeren van procedures voor incidentenbeheer behoren externe eisen -**Overige informatie** +### Overige informatie Informatiebeveiligingsincidenten kunnen de grenzen van organisaties en landen overschrijdenm op dergelijke incidenten te kunnen reageren is het nuttig om indien van toepassing opvolging te coördineren en informatie over deze incidenten te delen met externe organisaties. -De ISO/IEC 27035-reeks biedt gedetailleerde richtlijnen over het beheer van informatiebeveiligingsincidenten. diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-5.25-Beoordelen-van-en-besluiten-over-informatiebeveiligingsgebeurtenissen.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-5.25-Beoordelen-van-en-besluiten-over-informatiebeveiligingsgebeurtenissen.md index f70097b..40aaf7f 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-5.25-Beoordelen-van-en-besluiten-over-informatiebeveiligingsgebeurtenissen.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-5.25-Beoordelen-van-en-besluiten-over-informatiebeveiligingsgebeurtenissen.md @@ -1,29 +1,37 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "5.25" +title: "Beoordelen van en besluiten over informatiebeveiligingsgebeurtenissen" +theme: Organizational +control_type: [Detective] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: + - Detect + - Respond +operational_capabilities: [Information_security_event_management] +security_domains: [Defence] +tags: +- iso27002/2022/NL +- sourcetext +status: active --- - -+------------------------+----------------------------------------------------+----------------------+--------------------------------------------------------+---------------------+ -| **Type** | **Informatie-** | **Cybersecurity-** | **Operationele** | **Beveiligings-** | -| | | | | | -| **beheersmaatregel** | **beveiligings-** | **concepten** | **capaciteiten** | **domeinen** | -| | | | | | -| | **eigenschappen** | | | | -+========================+====================================================+======================+========================================================+=====================+ -| #Detectief | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | #Detecteren | #Beheer_van_infor- matiebeveiligings- gebeurtenissen | #Verdediging | -| | | | | | -| | | #Reageren | | | -+------------------------+----------------------------------------------------+----------------------+--------------------------------------------------------+---------------------+ - -**Beheersmaatregel** +## 5.25 Beoordelen van en besluiten over informatiebeveiligingsgebeurtenissen +### Beheersmaatregel De organisatie behoort informatiebeveiligingsgebeurtenissen te beoordelen en te beslissen of ze moeten worden gecategoriseerd als informatiebeveiligingsincidenten. -**Doel** +### Doel Doeltreffende categorisering en prioritering van informatiebeveiligingsgebeurtenissen bewerkstelligen. -**Richtlijn** +### Richtlijn Er behoort een categoriserings- en prioriteringsschema voor informatiebeveiligingsincidenten te worden overeengekomen voor het identificeren van de gevolgen en prioriteit van een incidentet schema behoort de criteria te omvatten voor het als informatiebeveiligingsincident categoriseren van gebeurtenissenet contactpunt behoort elke informatiebeveiligingsgebeurtenis aan de hand van het overeengekomen schema te beoordelen. @@ -31,6 +39,5 @@ Personeel dat verantwoordelijk is voor het coördineren van en reageren op infor Resultaten van de beoordeling en het besluit behoren in detail te worden geregistreerd ten behoeve van toekomstige raadpleging en verificatie. -**Overige informatie** +### Overige informatie -De ISO/IEC 27035-reeks geeft verdere richtlijnen over het beheer van incidenten. diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-5.26-Reageren-op-informatiebeveiligingsincidenten.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-5.26-Reageren-op-informatiebeveiligingsincidenten.md index 99dc918..af80bd8 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-5.26-Reageren-op-informatiebeveiligingsincidenten.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-5.26-Reageren-op-informatiebeveiligingsincidenten.md @@ -1,29 +1,37 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "5.26" +title: "Reageren op informatiebeveiligingsincidenten" +theme: Organizational +control_type: [Corrective] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: + - Respond + - Recover +operational_capabilities: [Information_security_event_management] +security_domains: [Defence] +tags: +- iso27002/2022/NL +- sourcetext +status: active --- - -+------------------------+----------------------------------------------------+----------------------+--------------------------------------------------------+---------------------+ -| **Type** | **Informatie-** | **Cybersecurity-** | **Operationele** | **Beveiligings-** | -| | | | | | -| **beheersmaatregel** | **beveiligings-** | **concepten** | **capaciteiten** | **domeinen** | -| | | | | | -| | **eigenschappen** | | | | -+========================+====================================================+======================+========================================================+=====================+ -| #Corrigerend | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | #Reageren | #Beheer_van_infor- matiebeveiligings- gebeurtenissen | #Verdediging | -| | | | | | -| | | #Herstellen | | | -+------------------------+----------------------------------------------------+----------------------+--------------------------------------------------------+---------------------+ - -**Beheersmaatregel** +## 5.26 Reageren op informatiebeveiligingsincidenten +### Beheersmaatregel Op informatiebeveiligingsincidenten behoort te worden gereageerd in overeenstemming met de gedocumenteerde procedures. -**Doel** +### Doel Een doelmatige en doeltreffende reactie op informatiebeveiligingsincidenten bewerkstelligen. -**Richtlijn** +### Richtlijn De organisatie behoort procedures voor het reageren op informatiebeveiligingsincidenten op te stellen en aan alle relevante belanghebbenden mee te delen. @@ -64,6 +72,5 @@ wordt gedocumenteerd en gecommuniceerd volgens gedefinieerde procedures (zie 5.2 j) kwetsbaarheden en zwakke punten in de informatiebeveiliging, onder andere met betrekking tot beheersmaatregelen die het incident hebben veroorzaakt, eraan hebben bijgedragen of het niet hebben voorkomen, identificeren en beheren. -**Overige informatie** +### Overige informatie -De ISO/IEC 27035-reeks geeft verdere richtlijnen over het beheer van incidenten. diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-5.27-Leren-van-informatiebeveiligingsincidenten.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-5.27-Leren-van-informatiebeveiligingsincidenten.md index 7a88404..0f61aea 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-5.27-Leren-van-informatiebeveiligingsincidenten.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-5.27-Leren-van-informatiebeveiligingsincidenten.md @@ -1,29 +1,37 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "5.27" +title: "Leren van informatiebeveiligingsincidenten" +theme: Organizational +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: + - Identify + - Protect +operational_capabilities: [Information_security_event_management] +security_domains: [Defence] +tags: +- iso27002/2022/NL +- sourcetext +status: active --- - -+------------------------+----------------------------------------------------+----------------------+--------------------------------------------------------+---------------------+ -| **Type** | **Informatie-** | **Cybersecurity-** | **Operationele** | **Beveiligings-** | -| | | | | | -| **beheersmaatregel** | **beveiligings-** | **concepten** | **capaciteiten** | **domeinen** | -| | | | | | -| | **eigenschappen** | | | | -+========================+====================================================+======================+========================================================+=====================+ -| #Preventief | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | #Identificeren | #Beheer_van_infor- matiebeveiligings- gebeurtenissen | #Verdediging | -| | | | | | -| | | #Beschermen | | | -+------------------------+----------------------------------------------------+----------------------+--------------------------------------------------------+---------------------+ - -**Beheersmaatregel** +## 5.27 Leren van informatiebeveiligingsincidenten +### Beheersmaatregel Kennis die is opgedaan met informatiebeveiligingsincidenten behoort te worden gebruikt om de beheersmaatregelen voor informatiebeveiliging te versterken en te verbeteren. -**Doel** +### Doel De waarschijnlijkheid of de gevolgen van toekomstige incidenten verminderen. -**Richtlijn** +### Richtlijn De organisatie behoort procedures op te stellen om de soorten, volumes en kosten van informatiebeveiligingsincidenten te kwantificeren en te monitoren. @@ -39,6 +47,5 @@ c) de bewustwording en training van gebruikers (zie 6.3) te verbeteren door voor van wat er kan gebeuren, hoe te reageren op dergelijke incidenten en hoe ze in de toekomst kunnen worden vermeden. -**Overige informatie** +### Overige informatie -De ISO/IEC 27035-reeks geeft verdere richtlijnen. diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-5.28-Verzamelen-van-bewijsmateriaal.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-5.28-Verzamelen-van-bewijsmateriaal.md index 6f862bf..98c1189 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-5.28-Verzamelen-van-bewijsmateriaal.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-5.28-Verzamelen-van-bewijsmateriaal.md @@ -1,29 +1,37 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "5.28" +title: "Verzamelen van bewijsmateriaal" +theme: Organizational +control_type: [Corrective] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: + - Detect + - Respond +operational_capabilities: [Information_security_event_management] +security_domains: [Defence] +tags: +- iso27002/2022/NL +- sourcetext +status: active --- - -+------------------------+----------------------------------------------------+----------------------+--------------------------------------------------------+---------------------+ -| **Type** | **Informatie-** | **Cybersecurity-** | **Operationele** | **Beveiligings-** | -| | | | | | -| **beheersmaatregel** | **beveiligings-** | **concepten** | **capaciteiten** | **domeinen** | -| | | | | | -| | **eigenschappen** | | | | -+========================+====================================================+======================+========================================================+=====================+ -| #Corrigerend | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | #Detecteren | #Beheer_van_infor- matiebeveiligings- gebeurtenissen | #Verdediging | -| | | | | | -| | | #Reageren | | | -+------------------------+----------------------------------------------------+----------------------+--------------------------------------------------------+---------------------+ - -**Beheersmaatregel** +## 5.28 Verzamelen van bewijsmateriaal +### Beheersmaatregel De organisatie behoort procedures vast te stellen en te implementeren voor het identificeren, verzamelen, verkrijgen en bewaren van bewijs met betrekking tot informatiebeveiligingsgebeurtenissen. -**Doel** +### Doel In het kader van disciplinaire en gerechtelijke stappen consistent en doeltreffend beheer bewerkstelligen van bewijsmateriaal in verband met informatiebeveiligingsincidenten. -**Richtlijn** +### Richtlijn Bij het in het kader van disciplinaire en gerechtelijke stappen omgaan met bewijs met betrekking tot informatiebeveiligingsgebeurtenissen behoren interne procedures te worden ontwikkeld en gevolgde eisen van verschillende rechtsgebieden behoren in aanmerking te worden genomen om de kans zo groot mogelijk te maken dat het bewijs wordt toegelaten in de relevante rechtsgebieden. @@ -41,7 +49,7 @@ Indien beschikbaar, behoort certificatie of andere relevante methoden om persone Digitaal bewijs kan grenzen van organisaties of rechtsgebieden overschrijdenn zulke gevallen behoort te worden gewaarborgd dat de organisatie het recht heeft de vereiste informatie als digitaal bewijs te verzamelen. -**Overige informatie** +### Overige informatie Direct na het ontdekken van een informatiebeveiligingsgebeurtenis is het niet altijd duidelijk of de gebeurtenis zal leiden tot gerechtelijke stappenet gevaar bestaat dan ook dat noodzakelijk bewijs bewust of toevallig wordt vernietigd voordat de ernst van het incident wordt onderkendet is raadzaam om vroegtijdig juridisch advies of de rechtshandhavers in te schakelen als gerechtelijke stappen worden overwogen en advies in te winnen over het vereiste bewijs. @@ -50,4 +58,3 @@ Direct na het ontdekken van een informatiebeveiligingsgebeurtenis is het niet al ISO/IEC 27037 biedt definities en richtlijnen voor het identificeren, verzamelen, verkrijgen en bewaren van digitaal bewijs. -De ISO/IEC 27050-reeks behandelt elektronische ontdekking, hetgeen gepaard gaat met het als bewijsmiddel verwerken van elektronisch opgeslagen informatie. diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-5.29-Informatiebeveiliging-tijdens-een-verstoring.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-5.29-Informatiebeveiliging-tijdens-een-verstoring.md index cda1a9e..8007b51 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-5.29-Informatiebeveiliging-tijdens-een-verstoring.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-5.29-Informatiebeveiliging-tijdens-een-verstoring.md @@ -1,29 +1,41 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "5.29" +title: "Informatiebeveiliging tijdens een verstoring" +theme: Organizational +control_type: + - Preventive + - Corrective +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: + - Protect + - Respond +operational_capabilities: [Continuity] +security_domains: + - Protection + - Resilience +tags: +- iso27002/2022/NL +- sourcetext +status: active --- - -+------------------------+----------------------------------------------------+----------------------+--------------------+---------------------+ -| **Type** | **Informatie-** | **Cybersecurity-** | **Operationele** | **Beveiligings-** | -| | | | | | -| **beheersmaatregel** | **beveiligings-** | **concepten** | **capaciteiten** | **domeinen** | -| | | | | | -| | **eigenschappen** | | | | -+========================+====================================================+======================+====================+=====================+ -| #Preventief | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | #Beschermen | #Continuïteit | #Bescherming | -| | | | | | -| #Corrigerend | | #Reageren | | #Veerkracht | -+------------------------+----------------------------------------------------+----------------------+--------------------+---------------------+ - -**Beheersmaatregel** +## 5.29 Informatiebeveiliging tijdens een verstoring +### Beheersmaatregel De organisatie behoort plannen te maken voor het op het passende niveau waarborgen van de informatiebeveiliging tijdens een verstoring. -**Doel** +### Doel Informatie en andere gerelateerde bedrijfsmiddelen tijdens een verstoring beschermen. -**Richtlijn** +### Richtlijn De organisatie behoort haar eisen vast te stellen voor het tijdens een verstoring aanpassen van beheersmaatregelen voor informatiebeveiligingnformatiebeveiligingseisen behoren te worden opgenomen in de processen voor bedrijfscontinuïteitsbeheer van de organisatie. @@ -43,11 +55,10 @@ c) compenserende beheersmaatregelen voor beheersmaatregelen voor informatiebevei tijdens een verstoring niet kunnen worden gehandhaafd. -**Overige informatie** +### Overige informatie In de context van de bedrijfscontinuïteits- en ICT-continuïteitsplanning kan het nodig zijn de informatiebeveiligingseisen aan te passen, afhankelijk van de soort verstoring, in vergelijking met de normale operationele omstandighedenls onderdeel van de bedrijfsimpactanalyse en de risicobeoordeling die worden uitgevoerd binnen bedrijfscontinuïteitsbeheer, behoren de gevolgen van het wegvallen van de geheimhouding en de integriteit van informatie, naast de noodzaak om de beschikbaarheid in stand te houden, te worden overwogen en geprioriteerd. -Informatie over systemen voor bedrijfscontinuïteitsbeheer is te vinden in ISO 22301 en ISO 22313erdere richtlijnen voor bedrijfsimpactanalyse (BIA) zijn te vinden in ISO/TS 22317. diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-5.3-Functiescheiding.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-5.3-Functiescheiding.md index 591c33b..d1ecf1e 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-5.3-Functiescheiding.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-5.3-Functiescheiding.md @@ -1,27 +1,37 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "5.3" +title: "Functiescheiding" +theme: Organizational +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: + - Governance + - Identity_and_access_management +security_domains: [Governance_and_Ecosystem] +tags: +- iso27002/2022/NL +- sourcetext +status: active --- ## 5.3 Functiescheiding - -| Attribuut | Waarde | -| :----------------------------------- | :------------------------------------------------- | -| Type beheersmaatregel: | #Preventief | -| Informatiebeveiligingseigenschappen: | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | -| Cybersecurityconcepten: | #Beschermen | -| Operationele capaciteiten: | #Governance #Identiteits-_en_toegangsbeheer | -| Beveiligingsdomeinen: | #Governance_en_Ecosysteem | - - -**Beheersmaatregel** +### Beheersmaatregel Conflicterende taken en conflicterende verantwoordelijkheden behoren te worden gescheiden. -**Doel** +### Doel Het risico op fraude, fouten en het omzeilen van beheersmaatregelen voor informatiebeveiliging verminderen. -**Richtlijn** +### Richtlijn De functiescheiding en verantwoordelijkheidszones hebben tot doel conflicterende functies te scheiden en onder verschillende personen te verdelen om te voorkomen dat mogelijk conflicterende functies door één persoon alleen worden uitgevoerd. @@ -47,4 +57,3 @@ Bij het gebruik van op functies gebaseerde toegangsbeveiligingssystemen behoort **Overige informatie** -Geen overige informatie. diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-5.30-ICT-gereedheid-voor-bedrijfscontinuiteit.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-5.30-ICT-gereedheid-voor-bedrijfscontinuiteit.md index d1596bd..e259e01 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-5.30-ICT-gereedheid-voor-bedrijfscontinuiteit.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-5.30-ICT-gereedheid-voor-bedrijfscontinuiteit.md @@ -1,27 +1,32 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "5.30" +title: "ICT-gereedheid voor bedrijfscontinuïteit" +theme: Organizational +control_type: [Corrective] +information_security_properties: [Availability] +cybersecurity_concepts: [Respond] +operational_capabilities: [Continuity] +security_domains: [Resilience] +tags: +- iso27002/2022/NL +- sourcetext +status: active --- - - -| Attribuut | Waarde | -| :----------------------------------- | :--------------- | -| Type beheersmaatregel: | #Corrigerend | -| Informatiebeveiligingseigenschappen: | #Beschikbaarheid | -| Cybersecurityconcepten: | #Reageren | -| Operationele capaciteiten: | #Continuïteit | -| Beveiligingsdomeinen: | #Veerkracht | - - -**Beheersmaatregel** +## 5.30 ICT-gereedheid voor bedrijfscontinuïteit +### Beheersmaatregel De ICT-gereedheid behoort te worden gepland, geïmplementeerd, onderhouden en getest op basis van bedrijfscontinuïteitsdoelstellingen en ICT-continuïteitseisen. -**Doel** +### Doel De beschikbaarheid van de informatie en andere gerelateerde bedrijfsmiddelen van de organisatie tijdens een verstoring waarborgen. -**Richtlijn** +### Richtlijn De ICT-gereedheid voor bedrijfscontinuïteit is een belangrijk onderdeel van bedrijfscontinuïteitsbeheer en informatiebeveiligingsbeheer om te bewerkstelligen dat ook tijdens een verstoring aan de doelstellingen van de organisatie kan blijven worden voldaan. @@ -49,7 +54,7 @@ c) ICT-continuïteitsplannen de volgende ICT-continuïteitsinformatie omvatten: 3) de RPO van de als informatie gedefinieerde geprioriteerde ICT-middelen en de procedures om de informatie te herstellen. -**Overige informatie** +### Overige informatie Het beheer van de ICT-continuïteit vormt een essentieel onderdeel van de bedrijfscontinuïteitseisen met betrekking tot beschikbaarheid om in staat te zijn: @@ -63,4 +68,3 @@ Verdere richtlijnen over de ICT-gereedheid voor bedrijfscontinuïteit zijn te vi Verdere richtlijnen over een systeem voor bedrijfscontinuïteitsbeheer zijn te vinden in ISO 22301 en ISO 22313. -Verdere richtlijnen over BIA zijn te vinden in ISO/TS 22317. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-5.31-Wettelijke-statutaire-regelgevende-en-contractuele-eisen.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-5.31-Wettelijke-statutaire-regelgevende-en-contractuele-eisen.md index 119498c..58b69df 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-5.31-Wettelijke-statutaire-regelgevende-en-contractuele-eisen.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-5.31-Wettelijke-statutaire-regelgevende-en-contractuele-eisen.md @@ -1,30 +1,37 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "5.31" +title: "Wettelijke, statutaire, regelgevende en contractuele eisen" +theme: Organizational +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Identify] +operational_capabilities: [Legal_and_compliance] +security_domains: + - Governance_and_Ecosystem + - Protection +tags: +- iso27002/2022/NL +- sourcetext +status: active --- - -+------------------------+----------------------------------------------------+----------------------+------------------------------+--------------------------------------------+ -| **Type** | **Informatie-** | **Cybersecurity-** | **Operationele** | **Beveiligings-** | -| | | | | | -| **beheersmaatregel** | **beveiligings-** | **concepten** | **capaciteiten** | **domeinen** | -| | | | | | -| | **eigenschappen** | | | | -+========================+====================================================+======================+==============================+============================================+ -| #Preventief | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | #Identificeren | #Juridisch_en_com- pliance | #Governance_en\_ Ecosysteem #Bescherming | -+------------------------+----------------------------------------------------+----------------------+------------------------------+--------------------------------------------+ - - - - -**Beheersmaatregel** +## 5.31 Wettelijke, statutaire, regelgevende en contractuele eisen +### Beheersmaatregel Eisen van wettelijke, statutaire, regelgevende en contractuele eisen die relevant zijn voor informatiebeveiliging en de aanpak van de organisatie om aan deze eisen te voldoen behoren te worden vastgesteld, gedocumenteerd en actueel gehouden. -**Doel** +### Doel De naleving bewerkstelligen van wettelijke, statutaire, regelgevende en contractuele eisen in verband met informatiebeveiliging. -**Richtlijn** +### Richtlijn <u>Algemeen</u> @@ -109,4 +116,3 @@ b) contracten met leveranciers (zie 5.20); c) verzekeringscontracten. -**Overige informatie** Geen overige informatie. diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-5.32-Intellectuele-eigendomsrechten.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-5.32-Intellectuele-eigendomsrechten.md index 9ed3e81..533f417 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-5.32-Intellectuele-eigendomsrechten.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-5.32-Intellectuele-eigendomsrechten.md @@ -1,32 +1,38 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "5.32" +title: "Intellectuele-eigendomsrechten" +theme: Organizational +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Identify] +operational_capabilities: [Legal_and_compliance] +security_domains: [Governance_and_Ecosystem] +tags: +- iso27002/2022/NL +- sourcetext +status: active --- - -+------------------------+----------------------------------------------------+----------------------+------------------------------+---------------------+ -| **Type** | **Informatie-** | **Cybersecurity-** | **Operationele** | **Beveiligings-** | -| | | | | | -| **beheersmaatregel** | **beveiligings-** | **concepten** | **capaciteiten** | **domeinen** | -| | | | | | -| | **eigenschappen** | | | | -+========================+====================================================+======================+==============================+=====================+ -| #Preventief | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | #Identificeren | #Juridisch_en_com- pliance | #Governance_en\_ | -| | | | | | -| | | | | Ecosysteem | -+------------------------+----------------------------------------------------+----------------------+------------------------------+---------------------+ - -**Beheersmaatregel** +## 5.32 Intellectuele-eigendomsrechten +### Beheersmaatregel De organisatie behoort passende procedures te implementeren om intellectuele eigendomsrechten te beschermen. -**Doel** +### Doel De naleving bewerkstelligen van eisen van wet- en regelgeving, statutaire en contractuele eisen in verband met intellectuele-eigendomsrechten en het gebruik van gepatenteerde producten. -**Richtlijn** +### Richtlijn De volgende richtlijnen behoren in overweging te worden genomen om materiaal dat kan worden beschouwd als intellectuele eigendom te beschermen: @@ -68,7 +74,7 @@ k) niet dupliceren, naar een ander formaat converteren of een uittreksel maken v l) geen normen (bijvnternationale normen van ISO/IEC), boeken, artikelen, rapporten of andere documenten geheel of ten dele kopiëren, tenzij dit auteursrechtelijk of volgens de licenties die van toepassing zijn, is toegestaan. -**Overige informatie** +### Overige informatie Onder intellectuele-eigendomsrechten vallen auteursrechten op software of documenten, ontwerprechten, handelsmerken, patenten en broncodelicenties. @@ -85,4 +91,3 @@ Eisen van wet- en regelgeving, statutaire en contractuele eisen kunnen beperking tot gerechtelijke stappen, die kunnen resulteren in een geldboete of een strafproces. -Afgezien van het feit dat het nodig is dat de organisatie voldoet aan haar verplichtingen wat betreft de intellectuele-eigendomsrechten van derden, behoren de risico\'s dat personeel en derden de eigen intellectuele-eigendomsrechten van de organisatie niet behartigen ook te worden beheerst. diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-5.33-Beschermen-van-registraties.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-5.33-Beschermen-van-registraties.md index d596837..4ec1dd8 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-5.33-Beschermen-van-registraties.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-5.33-Beschermen-van-registraties.md @@ -1,29 +1,40 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "5.33" +title: "Beschermen van registraties" +theme: Organizational +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: + - Identify + - Protect +operational_capabilities: + - Legal_and_compliance + - Asset_management + - Information_protection +security_domains: [Defence] +tags: +- iso27002/2022/NL +- sourcetext +status: active --- - -+------------------------+----------------------------------------------------+----------------------+--------------------------------------------------------------------------------------+---------------------+ -| **Type** | **Informatie-** | **Cybersecurity-** | **Operationele** | **Beveiligings-** | -| | | | | | -| **beheersmaatregel** | **beveiligings-** | **concepten** | **capaciteiten** | **domeinen** | -| | | | | | -| | **eigenschappen** | | | | -+========================+====================================================+======================+======================================================================================+=====================+ -| #Preventief | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | #Identificeren | #Juridisch_en_com- pliance #Beheer_van_bedrijfs- middelen #Informatiebescher- ming | #Verdediging | -| | | | | | -| | | #Beschermen | | | -+------------------------+----------------------------------------------------+----------------------+--------------------------------------------------------------------------------------+---------------------+ - -**Beheersmaatregel** +## 5.33 Beschermen van registraties +### Beheersmaatregel Registraties behoren te worden beschermd tegen verlies, vernietiging, vervalsing, toegang door onbevoegden en ongeoorloofde vrijgave. -**Doel** +### Doel De naleving bewerkstelligen van wet- en regelgeving, statutaire en contractuele eisen, alsmede gemeenschaps- of maatschappelijke verwachtingen, met betrekking tot de bescherming en beschikbaarheid van registraties. -**Richtlijn** +### Richtlijn De organisatie behoort de volgende stappen te ondernemen om de authenticiteit, betrouwbaarheid, integriteit en bruikbaarheid van registraties te beschermen, aangezien de bedrijfscontext en de eisen voor het beheer ervan na verloop van tijd veranderen: @@ -50,7 +61,7 @@ Als elektronische opslagmedia worden gekozen behoren procedures te worden vastge Procedures voor het bewaren en behandelen van deze media behoren te worden geïmplementeerd in overeenstemming met de aanbevelingen van fabrikanten van opslagmediar behoort rekening te worden gehouden met de mogelijkheid dat media die worden gebruikt om registraties te bewaren, in kwaliteit achteruitgaan. -**Overige informatie** +### Overige informatie Registraties documenteren individuele gebeurtenissen of transacties of kunnen samenvoegingen zijn van gegevens die ervoor zijn opgezet om arbeidsprocessen, activiteiten of functies te documenterene vormen het bewijs van zowel bedrijfsactiviteiten als van informatiebedrijfsmiddelenlke informatieverzameling, ongeacht structuur of vorm, kan als registratie worden beheerdit omvat informatie in de vorm van een document, een verzameling gegevens of andere soorten digitale of analoge informatie die in het kader van de bedrijfsvoering worden aangemaakt, vastgelegd en beheerd. @@ -58,4 +69,3 @@ In het kader van het beheren van registraties zijn metagegevens gegevens die de Het kan nodig zijn sommige registraties veilig te bewaren om te voldoen aan eisen van wet- en regelgeving, statutaire en contractuele eisen, en om essentiële bedrijfsactiviteiten te ondersteunene bewaartermijn en de soort informatie die behoort te worden bewaard, kunnen zijn vastgelegd in nationale wet- of regelgevingerdere informatie over beheer van registraties is te vinden in -ISO 15489. diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-5.34-Privacy-en-bescherming-van-persoonsgegevens.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-5.34-Privacy-en-bescherming-van-persoonsgegevens.md index fb7fa60..d8f8f67 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-5.34-Privacy-en-bescherming-van-persoonsgegevens.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-5.34-Privacy-en-bescherming-van-persoonsgegevens.md @@ -1,29 +1,39 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "5.34" +title: "Privacy en bescherming van persoonsgegevens" +theme: Organizational +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: + - Identify + - Protect +operational_capabilities: + - Information_protection + - Legal_and_compliance +security_domains: [Protection] +tags: +- iso27002/2022/NL +- sourcetext +status: active --- - -+------------------------+----------------------------------------------------+----------------------+----------------------------+---------------------+ -| **Type** | **Informatie-** | **Cybersecurity-** | **Operationele** | **Beveiligings-** | -| | | | | | -| **beheersmaatregel** | **beveiligings-** | **concepten** | **capaciteiten** | **domeinen** | -| | | | | | -| | **eigenschappen** | | | | -+========================+====================================================+======================+============================+=====================+ -| #Preventief | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | #Identificeren | #Informatiebescherming | #Bescherming | -| | | | | | -| | | #Beschermen | #Juridisch_en_compliance | | -+------------------------+----------------------------------------------------+----------------------+----------------------------+---------------------+ - -**Beheersmaatregel** +## 5.34 Privacy en bescherming van persoonsgegevens +### Beheersmaatregel De organisatie behoort de eisen met betrekking tot het behoud van privacy en de bescherming van persoonsgegevens volgens de toepasselijke wet- en regelgeving en contractuele eisen te identificeren en eraan te voldoen. -**Doel** +### Doel De naleving bewerkstelligen van wet- en regelgeving, statutaire en contractuele eisen met betrekking tot de informatiebeveiligingsaspecten voor de bescherming van persoonsgegevens. -**Richtlijn** +### Richtlijn De organisatie behoort een onderwerpspecifiek beleid inzake privacy en bescherming van persoonsgegevens vast te stellen en aan alle relevante belanghebbenden mee te delen. @@ -35,7 +45,7 @@ Verantwoordelijkheid voor het omgaan met persoonsgegevens behoort met inachtnemi Er behoren passende technische en organisatorische maatregelen te worden geïmplementeerd om persoonsgegevens te beschermen. -**Overige informatie** +### Overige informatie Een aantal landen heeft wetgeving ingevoerd waardoor er beheersmaatregelen zijn ingesteld voor het verzamelen, verwerken, verzenden en wissen van persoonsgegevensfhankelijk van de respectieve nationale wetgeving kunnen dergelijke beheersmaatregelen verplichtingen opleggen aan personen die persoonsgegevens verzamelen, verwerken en verspreiden, en kunnen zij ook de bevoegdheid voor het versturen van persoonsgegevens naar andere landen beperken. @@ -44,4 +54,3 @@ ISO/IEC 29100 voorziet in een kader op hoog niveau voor de bescherming van perso -ISO/IEC 29134 geeft richtlijnen voor privacy-effectbeoordelingen (PIA) en een voorbeeld van de structuur en inhoud van een PIA-rapportn vergelijking met ISO/IEC 27005 is dit toegespitst op het verwerken van persoonsgegevens en is het relevant voor die organisaties die persoonsgegevens verwerkenit kan helpen bij het identificeren van privacyrisico\'s en mogelijke beperkende maatregelen om deze risico\'s tot een aanvaardbaar niveau terug te brengen. diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-5.35-Onafhankelijke-beoordeling-van-informatiebeveiliging.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-5.35-Onafhankelijke-beoordeling-van-informatiebeveiliging.md index 0cc87b1..6615119 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-5.35-Onafhankelijke-beoordeling-van-informatiebeveiliging.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-5.35-Onafhankelijke-beoordeling-van-informatiebeveiliging.md @@ -1,29 +1,39 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "5.35" +title: "Onafhankelijke beoordeling van informatiebeveiliging" +theme: Organizational +control_type: + - Preventive + - Corrective +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: + - Identify + - Protect +operational_capabilities: [Information_security_assurance] +security_domains: [Governance_and_Ecosystem] +tags: +- iso27002/2022/NL +- sourcetext +status: active --- - -+------------------------+----------------------------------------------------+----------------------+----------------------------------------+---------------------+ -| **Type** | **Informatie-** | **Cybersecurity-** | **Operationele** | **Beveiligings-** | -| | | | | | -| **beheersmaatregel** | **beveiligings-** | **concepten** | **capaciteiten** | **domeinen** | -| | | | | | -| | **eigenschappen** | | | | -+========================+====================================================+======================+========================================+=====================+ -| #Preventief | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | #Identificeren | #Borging_van_infor- matiebeveiliging | #Governance_en\_ | -| | | | | | -| #Corrigerend | | #Beschermen | | Ecosysteem | -+------------------------+----------------------------------------------------+----------------------+----------------------------------------+---------------------+ - -**Beheersmaatregel** +## 5.35 Onafhankelijke beoordeling van informatiebeveiliging +### Beheersmaatregel De aanpak van de organisatie ten aanzien van het beheer van informatiebeveiliging en de implementatie ervan, met inbegrip van mensen, processen en technologieën, behoren onafhankelijk en met geplande tussenpozen of zodra zich belangrijke veranderingen voordoen, te worden beoordeeld. -**Doel** +### Doel Waarborgen dat de organisatie continu een geschikte, toereikende en doeltreffende aanpak voor het beheer van informatiebeveiliging hanteert. -**Richtlijn** +### Richtlijn De organisatie behoort te beschikken over processen om onafhankelijke beoordelingen uit te voeren. @@ -52,6 +62,5 @@ gebruikt(e) product of dienst wijzigt; e) de organisatie de beheersmaatregelen en procedures voor informatiebeveiliging significant wijzigt. -**Overige informatie** +### Overige informatie -ISO/IEC 27007 en ISO/IEC TS 27008 voorzien in richtlijnen voor het uitvoeren van onafhankelijke beoordelingen. diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-5.36-Naleving-van-beleid-regels-en-normen-voor-informatiebeveiliging.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-5.36-Naleving-van-beleid-regels-en-normen-voor-informatiebeveiliging.md index 5a62918..fab2677 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-5.36-Naleving-van-beleid-regels-en-normen-voor-informatiebeveiliging.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-5.36-Naleving-van-beleid-regels-en-normen-voor-informatiebeveiliging.md @@ -1,29 +1,39 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "5.36" +title: "Naleving van beleid, regels en normen voor informatiebeveiliging" +theme: Organizational +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: + - Identify + - Protect +operational_capabilities: + - Legal_and_compliance + - Information_security_assurance +security_domains: [Governance_and_Ecosystem] +tags: +- iso27002/2022/NL +- sourcetext +status: active --- - -+------------------------+----------------------------------------------------+----------------------+-------------------------------------------------------------------+---------------------+ -| **Type** | **Informatie-** | **Cybersecurity-** | **Operationele** | **Beveiligings-** | -| | | | | | -| **beheersmaatregel** | **beveiligings-** | **concepten** | **capaciteiten** | **domeinen** | -| | | | | | -| | **eigenschappen** | | | | -+========================+====================================================+======================+===================================================================+=====================+ -| #Preventief | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | #Identificeren | #Juridisch_en_com- pliance #Borging_van_infor- matiebeveiliging | #Governance_en\_ | -| | | | | | -| | | #Beschermen | | Ecosysteem | -+------------------------+----------------------------------------------------+----------------------+-------------------------------------------------------------------+---------------------+ - -**Beheersmaatregel** +## 5.36 Naleving van beleid, regels en normen voor informatiebeveiliging +### Beheersmaatregel De naleving van het informatiebeveiligingsbeleid, het onderwerpspecifieke beleid, regels en de normen van de organisatie behoort regelmatig te worden beoordeeld. -**Doel** +### Doel Bewerkstelligen dat informatiebeveiliging in overeenstemming met het informatiebeveiligingsbeleid, het onderwerpspecifieke beleid, regels en normen van de organisatie wordt geïmplementeerd en uitgevoerd. -**Richtlijn** +### Richtlijn Managers of de eigenaren van diensten, producten of informatie behoren vast te stellen op welke manier wordt beoordeeld of aan informatiebeveiligingseisen zoals gedefinieerd in het informatiebeveiligingsbeleid, het onderwerpspecifieke beleid, regels, normen en andere toepasselijke regelgeving, wordt nageleefdoor een doeltreffende regelmatige beoordeling behoort te worden overwogen om automatische meet- en rapportage-instrumenten in te zetten. @@ -48,6 +58,5 @@ Resultaten van door managers of de eigenaren van diensten, producten of informat Corrigerende maatregelen behoren tijdig te worden voltooid, naarmate passend is gezien het risicondien deze maatregelen niet voor de volgende geplande beoordeling zijn voltooid, behoren de vorderingen in ieder geval als onderdeel van die beoordeling te worden behandeld. -**Overige informatie** +### Overige informatie -Operationele monitoring van het gebruik van systemen wordt behandeld in 8, 8, 8. diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-5.37-Gedocumenteerde-bedieningsprocedures.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-5.37-Gedocumenteerde-bedieningsprocedures.md index 334e663..3df5e3f 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-5.37-Gedocumenteerde-bedieningsprocedures.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-5.37-Gedocumenteerde-bedieningsprocedures.md @@ -1,32 +1,54 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "5.37" +title: "Gedocumenteerde bedieningsprocedures" +theme: Organizational +control_type: + - Preventive + - Corrective +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: + - Protect + - Recover +operational_capabilities: + - Asset_management + - Physical_security + - System_and_network_security + - Application_security + - Secure_configuration + - Identity_and_access_management + - Threat_and_vulnerability_management + - Continuity + - Information_security_event_management +security_domains: + - Governance_and_Ecosystem + - Protection + - Defence +tags: +- iso27002/2022/NL +- sourcetext +status: active --- - -+------------------------+----------------------------------------------------+----------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------+ -| **Type** | **Informatie-** | **Cybersecurity-** | **Operationele** | **Beveiligings-** | -| | | | | | -| **beheersmaatregel** | **beveiligings-** | **concepten** | **capaciteiten** | **domeinen** | -| | | | | | -| | **eigenschappen** | | | | -+========================+====================================================+======================+=========================================================================================================================================================================================================================+=========================================================+ -| #Preventief | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | #Beschermen | #Beheer_van_bedrijfs\_ middelen #Fysieke_beveiliging #Systeem- \_en_netwerkbeveiliging #Toepassingsbeveili- ging #Veilige_configuratie #Identiteits- \_en_toegangsbeheer #Beheer_van_dreigin- gen_en_kwetsbaar- heden | #Governance_en\_ Ecosysteem #Bescherming #Verdediging | -| | | | | | -| #Corrigerend | | #Herstellen | #Continuïteit #Beheer_van_infor- matiebeveiligings- gebeurtenissen | | -+------------------------+----------------------------------------------------+----------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------+ - -**Beheersmaatregel** +## 5.37 Gedocumenteerde bedieningsprocedures +### Beheersmaatregel Bedieningsprocedures voor informatieverwerkende faciliteiten behoren te worden gedocumenteerd en beschikbaar te worden gesteld aan het personeel dat ze nodig heeft. -**Doel** +### Doel De correcte en veilige bediening van informatieverwerkende faciliteiten waarborgen. -**Richtlijn** +### Richtlijn Er behoren gedocumenteerde procedures te worden opgesteld voor de operationele activiteiten van de organisatie die verband houden met informatiebeveiliging, bijvoorbeeld: @@ -77,4 +99,3 @@ Gedocumenteerde bedieningsprocedures behoren te worden beoordeeld en zo nodig bi -# 6 Mensgerichte beheersmaatregelen diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-5.4-Managementverantwoordelijkheden.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-5.4-Managementverantwoordelijkheden.md index 7497dd3..27a3c6b 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-5.4-Managementverantwoordelijkheden.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-5.4-Managementverantwoordelijkheden.md @@ -1,27 +1,35 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "5.4" +title: "Managementverantwoordelijkheden" +theme: Organizational +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Identify] +operational_capabilities: [Governance] +security_domains: [Governance_and_Ecosystem] +tags: +- iso27002/2022/NL +- sourcetext +status: active --- ## 5.4 Managementverantwoordelijkheden - - -| Attribuut | Waarde | -| :----------------------------------- | :------------------------------------------------ | -| Type beheersmaatregel: | #Preventief | -| Informatiebeveiligingseigenschappen: | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | -| Cybersecurityconcepten: | #Identificeren | -| Operationele capaciteiten: | #Governance | -| Beveiligingsdomeinen: | #Governance_en_Ecosysteem | - -**Beheersmaatregel** +### Beheersmaatregel Het management behoort van al het personeel te eisen dat ze informatiebeveiliging toepassen overeenkomstig het vastgestelde informatiebeveiligingsbeleid, de onderwerpspecifieke beleidsregels en procedures van de organisatie. -**Doel** +### Doel Bewerkstelligen dat het management zijn rol bij informatiebeveiliging begrijpt en maatregelen neemt om ervoor te zorgen dat al het personeel zich bewust is van zijn verantwoordelijkheden op het gebied van informatiebeveiliging en deze ook nakomt. -**Richtlijn** +### Richtlijn Het management behoort er blijk van te geven dat het het informatiebeveiligingsbeleid, onderwerpspecifieke beleidsregels, procedures en beheersmaatregelen voor informatiebeveiliging ondersteunt. @@ -47,4 +55,3 @@ h) voldoende middelen en tijd voor projectplanning krijgen voor het implementere Geen overige informatie. -\*) Nederlandse voetnoot: Anders geformuleerd dan in de brontekst, diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-5.5-Contact-met-overheidsinstanties.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-5.5-Contact-met-overheidsinstanties.md index f4e35a7..5e94eca 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-5.5-Contact-met-overheidsinstanties.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-5.5-Contact-met-overheidsinstanties.md @@ -1,22 +1,39 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "5.5" +title: "Contact met overheidsinstanties" +theme: Organizational +control_type: + - Preventive + - Corrective +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: + - Identify + - Protect + - Respond + - Recover +operational_capabilities: [Governance] +security_domains: + - Defence + - Resilience +tags: +- iso27002/2022/NL +- sourcetext +status: active --- ## 5.5 Contact met overheidsinstanties - -| Attribuut | Waarde | -| :----------------------------------- | :------------------------------------------------- | -| Type beheersmaatregel: | #Preventief #Corrigerend | -| Informatiebeveiligingseigenschappen: | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | -| Cybersecurityconcepten: | #Identificeren #Beschermen #Reageren #Herstellen | -| Operationele capaciteiten: | #Governance | -| Beveiligingsdomeinen: | #Verdediging #Veerkracht | - -**Beheersmaatregel** +### Beheersmaatregel De organisatie behoort contact met de relevante instanties te leggen en te onderhouden. -**Doel** +### Doel Een passende stroom van informatie met betrekking tot informatiebeveiliging tussen de organisatie en relevante juridische, regelgevende en toezichthoudende instanties bewerkstelligen. @@ -24,14 +41,13 @@ Een passende stroom van informatie met betrekking tot informatiebeveiliging tuss **27** -**Richtlijn** +### Richtlijn De organisatie behoort aan te geven wanneer en door wie contact behoort te worden opgenomen met overheidsinstanties (bijvolitie, regelgevende organen, toezichthouders) en hoe geïdentificeerde informatiebeveiligingsincidenten tijdig behoren te worden gemeld. Contacten met overheidsinstanties behoren ook te worden gebruikt om inzicht mogelijk te maken in de bestaande en toekomstige verwachtingen van deze instanties (bijvoepasselijke regelgeving met betrekking tot informatiebeveiliging). -**Overige informatie** +### Overige informatie Organisaties die worden aangevallen, kunnen instanties verzoeken om actie te ondernemen tegen de aanvaller. -Het onderhouden van dergelijke contacten kan een eis zijn voor het ondersteunen van het beheer van informatiebeveiligingsincidenten (zie [5.24](a-5.24-Plannen-en-voorbereiden-van-het-beheer-van-informatiebeveiligingsincidenten.md) t/m [5.28](a-5.28-Verzamelen-van-bewijsmateriaal.md)) of de noodplan- en bedrijfscontinuïteitsprocessen (zie [5.29](a-5.29-Informatiebeveiliging-tijdens-een-verstoring.md) en [5.30](a-5.30-ICT-gereedheid-voor-bedrijfscontinuiteit.md)). Contacten met regelgevende organen zijn ook nuttig om te anticiperen op en voorbereidingen te treffen voor komende veranderingen in relevante wet- en regelgeving die op de organisatie van invloed zijn. Contacten met andere instanties omvatten contacten met nutsbedrijven, eerstehulpdiensten, elektriciteitsleveranciers en gezondheids- en veiligheidsinstanties [bijv. de brandweer (in verband met de bedrijfscontinuïteit), telecommunicatiebedrijven (in verband met verbindingen en beschikbaarheid) en waterleidingbedrijven (in verband met koelvoorzieningen voor apparatuur)]. diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-5.6-Contact-met-speciale-belangengroepen.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-5.6-Contact-met-speciale-belangengroepen.md index ec95701..4a191d2 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-5.6-Contact-met-speciale-belangengroepen.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-5.6-Contact-met-speciale-belangengroepen.md @@ -1,26 +1,40 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "5.6" +title: "Contact met speciale belangengroepen" +theme: Organizational +control_type: + - Preventive + - Corrective +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: + - Protect + - Respond + - Recover +operational_capabilities: [Governance] +security_domains: [Defence] +tags: +- iso27002/2022/NL +- sourcetext +status: active --- ## 5.6 Contact met speciale belangengroepen - -| Attribuut | Waarde | -| :----------------------------------- | :------------------------------------------------- | -| Type beheersmaatregel: | #Preventief #Corrigerend | -| Informatiebeveiligingseigenschappen: | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | -| Cybersecurityconcepten: | #Beschermen #Reageren #Herstellen | -| Operationele capaciteiten: | #Governance | -| Beveiligingsdomeinen: | #Verdediging | - -**Beheersmaatregel** +### Beheersmaatregel De organisatie behoort contacten met speciale belangengroepen of andere gespecialiseerde beveiligingsfora en beroepsverenigingen te leggen en te onderhouden. -**Doel** +### Doel Een passende stroom van informatie met betrekking tot informatiebeveiliging bewerkstelligen. -**Richtlijn** +### Richtlijn Lidmaatschap van speciale belangengroepen of fora behoort te worden overwogen als middel om: @@ -37,4 +51,3 @@ e) informatie over nieuwe technologieën, producten, diensten, dreigingen of kwe f) geschikte contactpunten te verkrijgen als er informatiebeveiligingsincidenten aan de orde zijn (zie [5.24](a-5.24-Plannen-en-voorbereiden-van-het-beheer-van-informatiebeveiligingsincidenten.md) t/m [5.28](a-5.28-Verzamelen-van-bewijsmateriaal.md)). **Overige informatie** -Geen overige informatie. diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-5.7-Informatie-en-analyses-over-dreigingen.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-5.7-Informatie-en-analyses-over-dreigingen.md index b2f2116..874de3a 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-5.7-Informatie-en-analyses-over-dreigingen.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-5.7-Informatie-en-analyses-over-dreigingen.md @@ -1,26 +1,43 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "5.7" +title: "Informatie en analyses over dreigingen" +theme: Organizational +control_type: + - Preventive + - Detective + - Corrective +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: + - Identify + - Detect + - Respond +operational_capabilities: [Threat_and_vulnerability_management] +security_domains: + - Defence + - Resilience +tags: +- iso27002/2022/NL +- sourcetext +status: active --- ## 5.7 Informatie en analyses over dreigingen - -| Attribuut | Waarde | -| :----------------------------------- | :------------------------------------------------- | -| Type beheersmaatregel: | #Preventief #Detectief #Corrigerend | -| Informatiebeveiligingseigenschappen: | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | -| Cybersecurityconcepten: | #Identificeren #Detecteren #Reageren | -| Operationele capaciteiten: | #Beheer_van_dreigingen_en_kwetsbaarheden | -| Beveiligingsdomeinen: | #Veerkracht | - -**Beheersmaatregel** +### Beheersmaatregel Informatie met betrekking tot informatiebeveiligingsdreigingen behoort te worden verzameld en geanalyseerd om informatie en analyses over dreigingen te produceren. -**Doel** +### Doel Bewustwording bieden van de mogelijke dreigingen voor de organisatie zodat de passende mitigerende maatregelen kunnen worden getroffen. -**Richtlijn** +### Richtlijn Informatie over bestaande of opkomende dreigingen wordt verzameld en geanalyseerd teneinde: @@ -70,10 +87,9 @@ c) als input voor de processen en technieken voor het testen van de informatiebe De organisatie behoort informatie en analyses over dreigingen op wederzijdse basis met andere organisaties te delen om de algemene informatie en analyses over dreigingen te verbeteren. -**Overige informatie** +### Overige informatie Organisaties kunnen informatie en analyses over dreigingen gebruiken om dreigingen te voorkomen, detecteren of erop te reagerenrganisaties kunnen zelf informatie en analyses over dreigingen produceren, maar het is gebruikelijker dat ze informatie en analyses over dreigingen ontvangen en gebruiken die door andere bronnen wordt geproduceerd. Informatie en analyses over dreigingen worden vaak verstrekt door onafhankelijke aanbieders of adviseurs, overheidsinstanties of groepen die gezamenlijk informatie over dreigingen verzamelen en analyseren. -De doeltreffendheid van beheersmaatregelen zoals 5.25, 8.7, 8.16 of 8.23 is afhankelijk van de kwaliteit van de beschikbare informatie en analyses over dreigingen. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-5.8-Informatiebeveiliging-in-projectmanagement.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-5.8-Informatiebeveiliging-in-projectmanagement.md index 84b5a26..8d3201f 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-5.8-Informatiebeveiliging-in-projectmanagement.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-5.8-Informatiebeveiliging-in-projectmanagement.md @@ -1,26 +1,39 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "5.8" +title: "Informatiebeveiliging in projectmanagement" +theme: Organizational +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: + - Identify + - Protect +operational_capabilities: [Governance] +security_domains: + - Governance_and_Ecosystem + - Protection +tags: +- iso27002/2022/NL +- sourcetext +status: active --- ## 5.8 Informatiebeveiliging in projectmanagement - -| Attribuut | Waarde | -| :----------------------------------- | :------------------------------------------------- | -| Type beheersmaatregel: | #Preventief | -| Informatiebeveiligingseigenschappen: | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | -| Cybersecurityconcepten: | #Identificeren #Beschermen | -| Operationele capaciteiten: | #Governance | -| Beveiligingsdomeinen: | #Governance_en_Ecosysteem #Bescherming | - -**Beheersmaatregel** +### Beheersmaatregel Informatiebeveiliging behoort te worden geïntegreerd in projectmanagement. -**Doel** +### Doel Ervoor zorgen dat informatiebeveiligingsrisico's binnen projecten en te leveren producten en diensten gedurende de gehele levenscyclus van het project op doeltreffende wijze binnen het projectmanagement worden aangepakt. -**Richtlijn** +### Richtlijn Informatiebeveiliging behoort te worden geïntegreerd in projectmanagement om ervoor te zorgen dat informatiebeveiligingsrisico\'s in het kader van projectmanagement worden aangepaktit kan worden toegepast op elk type project ongeacht de complexiteit, omvang, duur, discipline of het toepassingsgebied (bijv. een project voor een proces voor kernactiviteiten, IT, 'facility management' of andere ondersteunende processen). @@ -62,8 +75,7 @@ h) naleving van de wettelijke, statutaire, regelgevende en contractuele omgeving i) het vereiste niveau van vertrouwen of zekerheid dat derden zullen voldoen aan het informatiebeveiligingsbeleid en de onderwerpspecifieke beleidsregels van de organisatie, met inbegrip van relevante beveiligingsclausules in overeenkomsten of contracten. -**Overige informatie** +### Overige informatie De projectontwikkelaanpak, zoals de Waterfall-levenscyclus of de Agile-levenscyclus, behoort gestructureerde informatiebeveiliging te ondersteunen die kan worden aangepast aan de volgens een beoordeling vastgestelde informatiebeveiligingsrisico's, aansluitend bij het karakter van het projectet vroegtijdig nadenken over informatiebeveiligingseisen voor het product of de dienst (bijvijdens de plannings- en ontwerpfasen) kan leiden tot doeltreffender en kostenefficiëntere oplossingen voor kwaliteits- en informatiebeveiliging. ISO 21500 en ISO 21502 geven richtlijnen voor projectmanagementconcepten en -processen die belangrijk zijn voor de prestaties van projecten. -ISO/IEC 27005 geeft richtlijnen voor het gebruik van risicobeheerprocessen om beheersmaatregelen te identificeren die aan informatiebeveiligingseisen voldoen. diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-5.9-Inventarisatie-van-informatie-en-andere-gerelateerde-bedrijfsmiddelen.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-5.9-Inventarisatie-van-informatie-en-andere-gerelateerde-bedrijfsmiddelen.md index 0e20717..c9be0aa 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-5.9-Inventarisatie-van-informatie-en-andere-gerelateerde-bedrijfsmiddelen.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-5.9-Inventarisatie-van-informatie-en-andere-gerelateerde-bedrijfsmiddelen.md @@ -1,28 +1,37 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "5.9" +title: "Inventarisatie van informatie en andere gerelateerde bedrijfsmiddelen" +theme: Organizational +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Identify] +operational_capabilities: [Asset_management] +security_domains: + - Governance_and_Ecosystem + - Protection +tags: +- iso27002/2022/NL +- sourcetext +status: active --- ## 5.9 Inventarisatie van informatie en andere gerelateerde bedrijfsmiddelen - - -| Attribuut | Waarde | -| :----------------------------------- | :----------------------------------------------- | -| Type beheersmaatregel: | #Preventief | -| Informatiebeveiligingseigenschappen: | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | -| Cybersecurityconcepten: | #Identificeren | -| Operationele capaciteiten: | #Beheer_van_bedrijfsmiddelen | -| Beveiligingsdomeinen: | #Governance_en_Ecosysteem #Bescherming | - - -**Beheersmaatregel** +### Beheersmaatregel Er behoort een inventarislijst van informatie en andere gerelateerde bedrijfsmiddelen, met inbegrip van de eigenaren, te worden opgesteld en onderhouden. -**Doel** +### Doel De informatie en andere gerelateerde bedrijfsmiddelen van de organisatie identificeren om de informatiebeveiliging ervan te behouden en passend eigenaarschap toe te wijzen. -**Richtlijn** +### Richtlijn [Inventarislijst] @@ -68,7 +77,7 @@ h) hij betrokken is bij het identificeren en het beheer van de risico\'s in verb i) hij het personeel ondersteunt dat de rollen en de verantwoordelijkheden heeft voor het beheren van zijn informatie. -**Overige informatie** +### Overige informatie Inventarislijsten van informatie en andere gerelateerde bedrijfsmiddelen zijn vaak nodig om de doeltreffende bescherming van informatie zeker te stellen en kunnen voor andere doeleinden vereist zijn, zoals om gezondheids- en veiligheids-, verzekerings- of financiële redenennventarislijsten van informatie en andere gerelateerde bedrijfsmiddelen ondersteunen ook risicobeheer, auditactiviteiten, kwetsbaarhedenbeheer, incidentrespons- en herstelplanning. @@ -76,4 +85,3 @@ Taken en verantwoordelijkheden kunnen worden gedelegeerd (bijvan een beheerder d Het kan nuttig zijn om groepen van informatie en andere gerelateerde bedrijfsmiddelen aan te wijzen die samen een bepaalde dienst verlenenn dat geval is de eigenaar van deze dienst verantwoordelijk voor het leveren van de dienst, met inbegrip van de werking van de bedrijfsmiddelen die de dienst verzorgen. -Zie ISO/IEC 19770-1 voor aanvullende informatie over het beheer van IT-bedrijfsmiddelenie ISO 55001 voor aanvullende informatie over het beheer van bedrijfsmiddelen. diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-6.1-Screening.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-6.1-Screening.md index fff0967..648ad8f 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-6.1-Screening.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-6.1-Screening.md @@ -1,29 +1,56 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "6.1" +title: "Screening" +theme: People +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: [Human_resource_security] +security_domains: [Governance_and_Ecosystem] +tags: +- iso27002/2022/NL +- sourcetext +status: active --- - -+------------------------+----------------------------------------------------+----------------------+----------------------------+---------------------+ -| **Type** | **Informatie-** | **Cybersecurity-** | **Operationele** | **Beveiligings-** | -| | | | | | -| **beheersmaatregel** | **beveiligings-** | **concepten** | **capaciteiten** | **domeinen** | -| | | | | | -| | **eigenschappen** | | | | -+========================+====================================================+======================+============================+=====================+ -| #Preventief | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | #Beschermen | #Personeelsbeveili- ging | #Governance_en\_ | -| | | | | | -| | | | | Ecosysteem | -+------------------------+----------------------------------------------------+----------------------+----------------------------+---------------------+ - -**Beheersmaatregel** +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "6.1" +title: "Screening" +theme: People +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: [Human_resource_security] +security_domains: [Governance_and_Ecosystem] +tags: +- iso27002/2022/NL +- sourcetext +status: active +--- +## 6.1 Screening +### Beheersmaatregel De achtergrond van alle kandidaten die in aanmerking komen voor posities binnen de organisatie behoort te worden gecontroleerd voordat ze bij de organisatie in dienst treden en daarna op gezette tijden te worden herhaaldierbij behoort rekening te worden gehouden met de toepasselijke wet- en regelgeving, voorschriften en ethische overwegingen, en deze controle behoort in verhouding te staan tot de bedrijfseisen, de classificatie van de informatie waartoe toegang wordt verleend en de vastgestelde risico\'s. -**Doel** +### Doel Bewerkstelligen dat al het personeel in aanmerking komt en geschikt is voor de functies waarvoor zij worden overwogen en dat zij hiervoor gedurende hun dienstverband in aanmerking blijven komen en geschikt blijven. -**Richtlijn** +### Richtlijn Al het personeel, met inbegrip van voltijd-, deeltijd- en tijdelijk personeel, behoort te worden gescreendndien deze personen via dienstverleners worden ingehuurd, behoren screeningeisen te worden opgenomen in de contractuele afspraken tussen de organisatie en de dienstverleners. @@ -72,4 +99,3 @@ d) beëindiging van het dienstverband. Deze controles behoren op gezette tijden te worden herhaald om te bevestigen dat personeel nog altijd geschikt is, afhankelijk van hoe essentieel de rol van een persoon is. -**Overige informatie** Geen overige informatie. diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-6.2-Arbeidsovereenkomst.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-6.2-Arbeidsovereenkomst.md index e34d5d2..8f7bd0a 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-6.2-Arbeidsovereenkomst.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-6.2-Arbeidsovereenkomst.md @@ -1,32 +1,38 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "6.2" +title: "Arbeidsovereenkomst" +theme: People +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: [Human_resource_security] +security_domains: [Governance_and_Ecosystem] +tags: +- iso27002/2022/NL +- sourcetext +status: active --- - -+------------------------+----------------------------------------------------+----------------------+----------------------------+---------------------+ -| **Type** | **Informatie-** | **Cybersecurity-** | **Operationele** | **Beveiligings-** | -| | | | | | -| **beheersmaatregel** | **beveiligings-** | **concepten** | **capaciteiten** | **domeinen** | -| | | | | | -| | **eigenschappen** | | | | -+========================+====================================================+======================+============================+=====================+ -| #Preventief | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | #Beschermen | #Personeelsbeveili- ging | #Governance_en\_ | -| | | | | | -| | | | | ecosysteem | -+------------------------+----------------------------------------------------+----------------------+----------------------------+---------------------+ - -**Beheersmaatregel** +## 6.2 Arbeidsovereenkomst +### Beheersmaatregel In arbeidsovereenkomsten behoort te worden vermeld wat de verantwoordelijkheden van het personeel en van de organisatie zijn wat betreft informatiebeveiliging. -**Doel** +### Doel Bewerkstelligen dat personeel begrijpt wat hun verantwoordelijkheden zijn op het gebied van informatiebeveiliging voor de rollen waarvoor zij mogelijk in aanmerking komen. -**Richtlijn** +### Richtlijn In de contractuele verplichtingen voor personeel behoren het informatiebeveiligingsbeleid en relevante onderwerpspecifieke beleidsregels van de organisatie in aanmerking te worden genomenovendien kunnen de volgende punten worden opgehelderd en vermeld: @@ -46,7 +52,7 @@ De organisatie behoort ervoor te zorgen dat personeel en contractanten instemmen Waar van toepassing behoren de verantwoordelijkheden die in de arbeidsovereenkomst staan, voor een vastgestelde periode na het einde van het dienstverband van kracht te blijven (zie 6.5) -**Overige informatie** +### Overige informatie Er kan een gedragscode worden gebruikt die de verantwoordelijkheden van het personeel in het kader van informatiebeveiliging aangeeft ten aanzien van vertrouwelijkheid, bescherming van persoonsgegevens, ethiek, passend gebruik van de informatie en andere gerelateerde @@ -54,4 +60,3 @@ bedrijfsmiddelen van de organisatie, alsmede ten aanzien van door de organisatie Een externe partij waarmee personeel van leveranciers is verbonden, kan ertoe zijn verplicht namens de gecontracteerde persoon contractuele afspraken te maken. -Indien de organisatie geen rechtspersoon is en geen werknemers heeft, kan het equivalent van een contractuele overeenkomst en van contractuele voorwaarden in aanmerking worden genomen, overeenkomstig de richtlijnen van deze beheersmaatregel. diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-6.3-Bewustwording-van-opleiding-en-training-in-informatiebeveiliging.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-6.3-Bewustwording-van-opleiding-en-training-in-informatiebeveiliging.md index c6755d0..be5d132 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-6.3-Bewustwording-van-opleiding-en-training-in-informatiebeveiliging.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-6.3-Bewustwording-van-opleiding-en-training-in-informatiebeveiliging.md @@ -1,29 +1,35 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "6.3" +title: "Bewustwording van, opleiding en training in informatiebeveiliging" +theme: People +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: [Human_resource_security] +security_domains: [Governance_and_Ecosystem] +tags: +- iso27002/2022/NL +- sourcetext +status: active --- - -+------------------------+----------------------------------------------------+----------------------+----------------------------+---------------------+ -| **Type** | **Informatie-** | **Cybersecurity-** | **Operationele** | **Beveiligings-** | -| | | | | | -| **beheersmaatregel** | **beveiligings-** | **concepten** | **capaciteiten** | **domeinen** | -| | | | | | -| | **eigenschappen** | | | | -+========================+====================================================+======================+============================+=====================+ -| #Preventief | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | #Beschermen | #Personeelsbeveili- ging | #Governance_en\_ | -| | | | | | -| | | | | Ecosysteem | -+------------------------+----------------------------------------------------+----------------------+----------------------------+---------------------+ - -**Beheersmaatregel** +## 6.3 Bewustwording van, opleiding en training in informatiebeveiliging +### Beheersmaatregel Personeel van de organisatie en relevante belanghebbenden behoren een passend(e) bewustwording van, opleiding, training en bijscholing in informatiebeveiliging en regelmatige updates over het informatiebeveiligingsbeleid, onderwerpspecifieke beleidsregels en procedures van de organisatie, voor zover relevant voor hun functie, te krijgen. -**Doel** +### Doel Ervoor zorgen dat personeel en relevante belanghebbenden zich bewust zijn van hun verantwoordelijkheden op het gebied van informatiebeveiliging en deze nakomen. -**Richtlijn** +### Richtlijn <u>Algemeen</u> @@ -66,8 +72,7 @@ stand houden van het vereiste beveiligingsniveau voor apparaten, systemen, toepa Voor het opleidings- en trainingsprogramma behoren verschillende vormen te worden overwogen [bijvessen of zelfstudie, begeleiding door deskundig personeel of consultants (training in de praktijk), het rouleren van personeelsleden om verschillende activiteiten te volgen, mensen met de juiste vaardigheden werven en consultants inhuren]it kan via verschillende middelen worden geleverd, bijvlassikaal, via afstandsonderwijs, via internet, in eigen tempoechnisch personeel behoort zijn kennis op peil te houden door zich te abonneren op nieuwsbrieven en tijdschriften of door conferenties en evenementen te bezoeken die zich richten op technische en professionele verbetering. -**Overige informatie** +### Overige informatie Bij het opstellen van een bewustwordingsprogramma is het belangrijk niet alleen de aandacht te richten op het 'wat' en 'hoe', maar ook op het 'waarom', indien mogelijket is belangrijk dat personeel het doel van informatiebeveiliging en de mogelijke uitwerking, positief en negatief, van het eigen gedrag op de organisatie begrijpt. -Bewustwording van, opleiding en training in informatiebeveiliging kunnen onderdeel zijn van, of worden gegeven in combinatie met andere activiteiten, bijvoorbeeld algemene informatiemanagement-, ICT-, beveiligings-, privacy- of veiligheidstraining. diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-6.4-Disciplinaire-procedure.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-6.4-Disciplinaire-procedure.md index 180b1fb..e891afd 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-6.4-Disciplinaire-procedure.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-6.4-Disciplinaire-procedure.md @@ -1,29 +1,39 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "6.4" +title: "Disciplinaire procedure" +theme: People +control_type: + - Preventive + - Corrective +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: + - Protect + - Respond +operational_capabilities: [Human_resource_security] +security_domains: [Governance_and_Ecosystem] +tags: +- iso27002/2022/NL +- sourcetext +status: active --- - -+------------------------+----------------------------------------------------+----------------------+----------------------------+---------------------+ -| **Type** | **Informatie-** | **Cybersecurity-** | **Operationele** | **Beveiligings-** | -| | | | | | -| **beheersmaatregel** | **beveiligings-** | **concepten** | **capaciteiten** | **domeinen** | -| | | | | | -| | **eigenschappen** | | | | -+========================+====================================================+======================+============================+=====================+ -| #Preventief | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | #Beschermen | #Personeelsbeveili- ging | #Governance_en\_ | -| | | | | | -| #Corrigerend | | #Reageren | | Ecosysteem | -+------------------------+----------------------------------------------------+----------------------+----------------------------+---------------------+ - -**Beheersmaatregel** +## 6.4 Disciplinaire procedure +### Beheersmaatregel Er behoort een formele en gecommuniceerde disciplinaire procedure te zijn om actie te ondernemen tegen personeel en andere belanghebbenden die zich schuldig hebben gemaakt aan een schending van het informatiebeveiligingsbeleid. -**Doel** +### Doel Bewerkstelligen dat personeel en andere relevante belanghebbenden de gevolgen begrijpen van schending van het informatiebeveiligingsbeleid, personeel en andere relevante belanghebbenden ervan weerhouden zich schuldig te maken aan een schending, en personeel en andere relevante belanghebbenden die zich schuldig hebben gemaakt aan een schending op de juiste manier aanpakken. -**Richtlijn** +### Richtlijn De disciplinaire procedure behoort niet te worden geïnitieerd voordat is geverifieerd dat er zich een schending van het informatiebeveiligingsbeleid heeft voorgedaan (zie 5.1). @@ -39,8 +49,7 @@ d) of de overtreder al dan niet naar behoren was opgeleid. Bij de reactie behoort rekening te worden gehouden met relevante eisen van wet- en regelgeving, statutaire, contractuele en bedrijfseisen evenals andere factoren voor zover vereiste disciplinaire procedure behoort ook te worden gebruikt als een afschrikmiddel om te voorkomen dat personeel en andere relevante belanghebbenden het informatiebeveiligingsbeleid, onderwerpspecifieke beleidsregels en procedures voor informatiebeveiliging overtredenpzettelijke schendingen van het informatiebeveiligingsbeleid kunnen onmiddellijke maatregelen vereisen. -**Overige informatie** +### Overige informatie Indien mogelijk behoort de identiteit van personen tegen wie disciplinaire actie wordt ondernomen overeenkomstig de toepasselijke eisen te worden beschermd. -Wanneer personen blijk hebben gegeven van uitstekend gedrag met betrekking tot informatiebeveiliging, kunnen ze worden beloond om de informatiebeveiliging te bevorderen en goed gedrag te stimuleren. diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-6.5-Verantwoordelijkheden-na-beeindiging-of-wijziging-van-het-dienstverband.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-6.5-Verantwoordelijkheden-na-beeindiging-of-wijziging-van-het-dienstverband.md index 0788305..38a205a 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-6.5-Verantwoordelijkheden-na-beeindiging-of-wijziging-van-het-dienstverband.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-6.5-Verantwoordelijkheden-na-beeindiging-of-wijziging-van-het-dienstverband.md @@ -1,29 +1,37 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "6.5" +title: "Verantwoordelijkheden na beëindiging of wijziging van het dienstverband" +theme: People +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: + - Human_resource_security + - Asset_management +security_domains: [Governance_and_Ecosystem] +tags: +- iso27002/2022/NL +- sourcetext +status: active --- - -+------------------------+----------------------------------------------------+----------------------+-----------------------------------------------------------+---------------------+ -| **Type** | **Informatie-** | **Cybersecurity-** | **Operationele** | **Beveiligings-** | -| | | | | | -| **beheersmaatregel** | **beveiligings-** | **concepten** | **capaciteiten** | **domeinen** | -| | | | | | -| | **eigenschappen** | | | | -+========================+====================================================+======================+===========================================================+=====================+ -| #Preventief | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | #Beschermen | #Personeelsbeveili- ging #Beheer_van_be- drijfsmiddelen | #Governance_en\_ | -| | | | | | -| | | | | Ecosysteem | -+------------------------+----------------------------------------------------+----------------------+-----------------------------------------------------------+---------------------+ - -**Beheersmaatregel** +## 6.5 Verantwoordelijkheden na beëindiging of wijziging van het dienstverband +### Beheersmaatregel Verantwoordelijkheden en taken met betrekking tot informatiebeveiliging die van kracht blijven na beëindiging of wijziging van het dienstverband behoren te worden gedefinieerd, gehandhaafd en gecommuniceerd aan relevant personeel en andere belanghebbenden. -**Doel** +### Doel De belangen van de organisatie beschermen als onderdeel van de wijzigings- of beëindigingsprocedure van dienstverband of contracten. -**Richtlijn** +### Richtlijn Het proces voor het beheer van een beëindiging of verandering van dienstverband behoort te definiëren welke verantwoordelijkheden en plichten op het gebied van informatiebeveiliging na de beëindiging of verandering behoren te blijven geldenit kan onder meer betrekking hebben op de vertrouwelijkheid van informatie, intellectuele eigendom en andere kennis die wordt verkregen, alsmede op de verantwoordelijkheden die deel uitmaken van andere geheimhoudingsovereenkomsten (zie 6.6). Verantwoordelijkheden en taken die na beëindiging van het dienstverband of contract nog altijd van kracht zijn, behoren te worden opgenomen in de arbeidsovereenkomst, het contract of de overeenkomst van de persoon (zie 6.2). Andere contracten of overeenkomsten die na het einde van het dienstverband van de persoon nog een bepaalde tijd doorlopen, kunnen ook verantwoordelijkheden @@ -39,11 +47,10 @@ Het proces voor het beëindigen of wijzigen van een dienstverband behoort ook te op extern personeel (dzeveranciers) wanneer een dienstverband van personeel, het contract of de functie bij de organisatie wordt beëindigd of wanneer er een verandering van functie binnen de organisatie is. -**Overige informatie** +### Overige informatie In veel organisaties is de afdeling personeelszaken doorgaans verantwoordelijk voor de totale beëindigingsprocedure en werkt deze afdeling samen met de direct leidinggevende van de persoon die -overstapt om de informatiebeveiligingsaspecten van de relevante procedures af te handelenls het gaat om personeel dat is ingehuurd via een externe partij (bijvia een leverancier), dan wordt deze beëindigingsprocedure uitgevoerd door de externe partij in overeenstemming met het contract tussen de organisatie en de externe partij. diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-6.6-Vertrouwelijkheids-of-geheimhoudingsovereenkomsten.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-6.6-Vertrouwelijkheids-of-geheimhoudingsovereenkomsten.md index c143899..02ba1ed 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-6.6-Vertrouwelijkheids-of-geheimhoudingsovereenkomsten.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-6.6-Vertrouwelijkheids-of-geheimhoudingsovereenkomsten.md @@ -1,29 +1,35 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "6.6" +title: "Vertrouwelijkheids- of geheimhoudingsovereenkomsten" +theme: People +control_type: [Preventive] +information_security_properties: [Confidentiality] +cybersecurity_concepts: [Protect] +operational_capabilities: + - Human_resource_security + - Information_protection + - Supplier_relationships_security +security_domains: [Governance_and_Ecosystem] +tags: +- iso27002/2022/NL +- sourcetext +status: active --- - -+------------------------+----------------------+----------------------+-----------------------------------------------------------------------+---------------------+ -| **Type** | **Informatie-** | **Cybersecurity-** | **Operationele capaciteiten** | **Beveiligings-** | -| | | | | | -| **beheersmaatregel** | **beveiligings-** | **concepten** | | **domeinen** | -| | | | | | -| | **eigenschappen** | | | | -+========================+======================+======================+=======================================================================+=====================+ -| #Preventief | #Vertrouwelijkheid | #Beschermen | #Personeelsbeveiliging #Informatiebescherming #Leveranciersrelaties | #Governance_en\_ | -| | | | | | -| | | | | Ecosysteem | -+------------------------+----------------------+----------------------+-----------------------------------------------------------------------+---------------------+ - -**Beheersmaatregel** +## 6.6 Vertrouwelijkheids- of geheimhoudingsovereenkomsten +### Beheersmaatregel Vertrouwelijkheids- of geheimhoudingsovereenkomsten die de behoeften van de organisatie inzake de bescherming van informatie weerspiegelen, behoren te worden geïdentificeerd, gedocumenteerd, regelmatig te worden beoordeeld en ondertekend door personeel en andere relevante belanghebbenden. -**Doel** +### Doel De vertrouwelijkheid van informatie waartoe personeel of externe partijen toegang hebben handhaven. -**Richtlijn** +### Richtlijn Vertrouwelijkheids- of geheimhoudingsovereenkomsten behoren de eis van bescherming van vertrouwelijke informatie te behandelen binnen juridisch afdwingbare voorwaardenertrouwelijkheids- of geheimhoudingsovereenkomsten zijn van toepassing op belanghebbenden en personeel van de organisatiep basis van de informatiebeveiligingseisen van een organisatie behoren de voorwaarden in de overeenkomsten te worden vastgesteld door te kijken naar de soort informatie waarmee de belanghebbenden of het personeel zullen omgaan, het classificatieniveau en het gebruik ervan en de toegestane toegang door de andere partijij het vaststellen van eisen voor vertrouwelijkheids- of geheimhoudingsovereenkomsten, behoren de volgende elementen in overweging te worden genomen: @@ -68,6 +74,5 @@ De organisatie behoort het voldoen aan vertrouwelijkheids- en geheimhoudingsover Eisen voor vertrouwelijkheids- en geheimhoudingsovereenkomsten behoren periodiek te worden beoordeeld, en als zich veranderingen voordoen die van invloed zijn op deze eisen. -**Overige informatie** +### Overige informatie -Vertrouwelijkheids- en geheimhoudingsovereenkomsten beschermen informatie van de organisatie en informeren de ondertekenaars over hun verantwoordelijkheid om informatie op een verantwoordelijke en bevoegde manier te beschermen, te gebruiken en openbaar te maken. diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-6.7-Werken-op-afstand.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-6.7-Werken-op-afstand.md index 66be0a9..02cb69b 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-6.7-Werken-op-afstand.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-6.7-Werken-op-afstand.md @@ -1,27 +1,39 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "6.7" +title: "Werken op afstand" +theme: People +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: + - Asset_management + - Information_protection + - Physical_security + - System_and_network_security +security_domains: [Protection] +tags: +- iso27002/2022/NL +- sourcetext +status: active --- - -+------------------------+----------------------------------------------------+----------------------+-------------------------------------------------------------------------------------------------------------------+---------------------+ -| **Type** | **Informatie-** | **Cybersecurity-** | **Operationele** | **Beveiligings-** | -| | | | | | -| **beheersmaatregel** | **beveiligings-** | **concepten** | **capaciteiten** | **domeinen** | -| | | | | | -| | **eigenschappen** | | | | -+========================+====================================================+======================+===================================================================================================================+=====================+ -| #Preventief | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | #Beschermen | #Beheer_van_bedrijfs- middelen #Informatiebescher- ming #Fysieke_beveiliging #Systeem-\_en_net- werkbeveiliging | #Bescherming | -+------------------------+----------------------------------------------------+----------------------+-------------------------------------------------------------------------------------------------------------------+---------------------+ - -**Beheersmaatregel** +## 6.7 Werken op afstand +### Beheersmaatregel Wanneer personeel op afstand werkt, behoren er beveiligingsmaatregelen te worden geïmplementeerd om informatie te beschermen die buiten het gebouw en/of terrein van de organisatie wordt ingezien, verwerkt of opgeslagen. -**Doel** +### Doel De beveiliging van informatie waarborgen wanneer personeel op afstand werkt. -**Richtlijn** +### Richtlijn Er is sprake van werken op afstand telkens wanneer personeel van de organisatie vanaf een locatie buiten het gebouw en/of terrein van de organisatie werkt en toegang maakt tot informatie, hetzij in gedrukte vorm of elektronisch via ICT-apparatuurmgevingen voor werken op afstand zijn onder andere omgevingen die worden aangeduid als 'telewerken', 'teleforenzen', 'flexibele werkplek', 'virtuele werkomgevingen' en 'onderhoud op afstand'. @@ -95,4 +107,3 @@ k) intrekking van bevoegdheid en toegangsrechten en het inleveren van apparatuur van de werkactiviteiten op afstand. -**Overige informatie** Geen overige informatie. diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-6.8-Melden-van-informatiebeveiligingsgebeurtenissen.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-6.8-Melden-van-informatiebeveiligingsgebeurtenissen.md index 90bdb31..49e4b9a 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-6.8-Melden-van-informatiebeveiligingsgebeurtenissen.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-6.8-Melden-van-informatiebeveiligingsgebeurtenissen.md @@ -1,27 +1,35 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "6.8" +title: "Melden van informatiebeveiligingsgebeurtenissen" +theme: People +control_type: [Detective] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Detect] +operational_capabilities: [Information_security_event_management] +security_domains: [Defence] +tags: +- iso27002/2022/NL +- sourcetext +status: active --- - -+------------------------+----------------------------------------------------+----------------------+--------------------------------------------------------+---------------------+ -| **Type** | **Informatie-** | **Cybersecurity-** | **Operationele** | **Beveiligings-** | -| | | | | | -| **beheersmaatregel** | **beveiligings-** | **concepten** | **capaciteiten** | **domeinen** | -| | | | | | -| | **eigenschappen** | | | | -+========================+====================================================+======================+========================================================+=====================+ -| #Detectief | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | #Detecteren | #Beheer_van_infor- matiebeveiligings- gebeurtenissen | #Verdediging | -+------------------------+----------------------------------------------------+----------------------+--------------------------------------------------------+---------------------+ - -**Beheersmaatregel** +## 6.8 Melden van informatiebeveiligingsgebeurtenissen +### Beheersmaatregel De organisatie behoort te voorzien in een mechanisme waarmee personeel waargenomen of vermoede informatiebeveiligingsgebeurtenissen tijdig via passende kanalen kan melden. -**Doel** +### Doel Tijdige, consistente en doeltreffende melding ondersteunen van informatiebeveiligingsgebeurtenissen die door personeel kunnen worden geïdentificeerd. -**Richtlijn** +### Richtlijn Al het personeel en alle gebruikers behoren bewust te worden gemaakt van hun verantwoordelijkheid om informatiebeveiligingsgebeurtenissen zo snel mogelijk te melden om het effect van informatiebeveiligingsincidenten te voorkomen of tot het minimum te beperkenij behoren ook te worden geïnformeerd over de procedure voor het melden van informatiebeveiligingsgebeurtenissen en het contactpunt waar de gebeurtenissen behoren te worden gemeldet meldmechanisme behoort zo eenvoudig, toegankelijk en beschikbaar mogelijk te zijnnformatiebeveiligingsgebeurtenissen zijn onder andere incidenten, inbreuken en kwetsbaarheden. @@ -54,8 +62,7 @@ j) vermoedelijke besmetting door malware. Personeel en gebruikers behoort te worden geadviseerd niet te proberen om de vermeende aanwezigheid van kwetsbaarheden op het gebied van informatiebeveiliging aan te tonenet testen op kwetsbaarheden kan worden uitgelegd als potentieel misbruik van het systeem en kan ook schade veroorzaken aan het informatiesysteem en het kan digitaal bewijs corrumperen of aan het oog onttrekkeniteindelijk kan dit leiden tot wettelijke aansprakelijkheid voor de persoon die de tests uitvoert. -**Overige informatie** +### Overige informatie Zie de ISO/IEC 27035-reeks voor aanvullende informatie. -# 7 Fysieke beheersmaatregelen diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-7.1-Fysieke-beveiligingszones.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-7.1-Fysieke-beveiligingszones.md index a770425..48d2c53 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-7.1-Fysieke-beveiligingszones.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-7.1-Fysieke-beveiligingszones.md @@ -1,30 +1,38 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "7.1" +title: "Fysieke beveiligingszones" +theme: Physical +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: [Physical_security] +security_domains: [Protection] +tags: +- iso27002/2022/NL +- sourcetext +status: active --- - -+------------------------+----------------------------------------------------+----------------------+------------------------+---------------------+ -| **Type** | **Informatie-** | **Cybersecurity-** | **Operationele** | **Beveiligings-** | -| | | | | | -| **beheersmaatregel** | **beveiligings-** | **concepten** | **capaciteiten** | **domeinen** | -| | | | | | -| | **eigenschappen** | | | | -+========================+====================================================+======================+========================+=====================+ -| #Preventief | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | #Beschermen | #Fysieke_beveiliging | #Bescherming | -+------------------------+----------------------------------------------------+----------------------+------------------------+---------------------+ - -**Beheersmaatregel** +## 7.1 Fysieke beveiligingszones +### Beheersmaatregel Zones die informatie en andere gerelateerde bedrijfsmiddelen bevatten, behoren te worden beschermd door beveiligingszones te definiëren en te gebruiken. -**Doel** +### Doel Onbevoegde fysieke toegang tot, schade aan en interferentie met informatie en andere gerelateerde bedrijfsmiddelen van de organisatie voorkomen. -**Richtlijn** +### Richtlijn Voor zover van toepassing behoren de volgende richtlijnen voor fysieke beveiligingszones te worden overwogen: @@ -36,8 +44,7 @@ b) beschikken over fysiek solide buitengrenzen voor een gebouw of locatie met in c) alle branddeuren die deel uitmaken van een beveiligingszone, van alarmsystemen voorzien en ze in combinatie met de muren monitoren en testen om vast te stellen of ze het vereiste weerstandsniveau, overeenkomstig geschikte normen, biedene behoren faalveilig te werken. -**Overige informatie** +### Overige informatie Fysieke bescherming kan worden verkregen door een of meer fysieke barrières rond het gebouw en/of terrein en de informatieverwerkende faciliteiten van de organisatie aan te brengen. -Een beveiligd gebied kan een afsluitbaar kantoor zijn of diverse ruimten omgeven door een ononderbroken interne fysieke beveiligingsbarrièreussen zones met verschillende beveiligingseisen binnen de beveiligingszone kunnen extra barrières en buitengrenzen nodig zijn om fysieke toegang te beheersene organisatie behoort te overwegen fysieke beveiligingsmaatregelen in te voeren die tijdens situaties waar er sprake is van een verhoogd dreigingsniveau kunnen worden versterkt. diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-7.10-Opslagmedia.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-7.10-Opslagmedia.md index f5f0637..114dd71 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-7.10-Opslagmedia.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-7.10-Opslagmedia.md @@ -1,30 +1,40 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "7.10" +title: "Opslagmedia" +theme: Physical +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: + - Physical_security + - Asset_management +security_domains: [Protection] +tags: +- iso27002/2022/NL +- sourcetext +status: active --- - -+------------------------+----------------------------------------------------+----------------------+-------------------------------------------------------+---------------------+ -| **Type** | **Informatie-** | **Cybersecurity-** | **Operationele** | **Beveiligings-** | -| | | | | | -| **beheersmaatregel** | **beveiligings-** | **concepten** | **capaciteiten** | **domeinen** | -| | | | | | -| | **eigenschappen** | | | | -+========================+====================================================+======================+=======================================================+=====================+ -| #Preventief | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | #Beschermen | #Fysieke_beveiliging #Beheer_van_be- drijfsmiddelen | #Bescherming | -+------------------------+----------------------------------------------------+----------------------+-------------------------------------------------------+---------------------+ - -**Beheersmaatregel** +## 7.10 Opslagmedia +### Beheersmaatregel Opslagmedia behoren te worden beheerd gedurende hun volledige levenscyclus van aanschaf, gebruik, transport en verwijdering overeenkomstig het classificatieschema en de hanteringseisen van de organisatie. -**Doel** +### Doel Uitsluitend geoorloofde openbaarmaking, wijziging, verwijdering of vernietiging van informatie op opslagmedia bewerkstelligen. -**Richtlijn** +### Richtlijn <u>Verwijderbare opslagmedia</u> @@ -91,6 +101,5 @@ waardoor een grote hoeveelheid niet-gevoelige informatie gevoelig kan worden. Er behoort een risicobeoordeling te worden uitgevoerd van beschadigde apparatuur die gevoelige gegevens bevat om vast te stellen of de media fysiek behoren te worden vernietigd in plaats van te worden gerepareerd of verwijderd (zie 7.14). -**Overige informatie** +### Overige informatie -Als vertrouwelijke informatie op opslagmedia niet versleuteld is, behoort aanvullende fysieke bescherming van de opslagmedia te worden overwogen. diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-7.11-Nutsvoorzieningen.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-7.11-Nutsvoorzieningen.md index d4f3d53..8c036df 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-7.11-Nutsvoorzieningen.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-7.11-Nutsvoorzieningen.md @@ -1,29 +1,38 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "7.11" +title: "Nutsvoorzieningen" +theme: Physical +control_type: + - Preventive + - Detective +information_security_properties: + - Integrity + - Availability +cybersecurity_concepts: + - Protect + - Detect +operational_capabilities: [Physical_security] +security_domains: [Protection] +tags: +- iso27002/2022/NL +- sourcetext +status: active --- - -+------------------------+---------------------+----------------------+------------------------+---------------------+ -| **Type** | **Informatie-** | **Cybersecurity-** | **Operationele** | **Beveiligings-** | -| | | | | | -| **beheersmaatregel** | **beveiligings-** | **concepten** | **capaciteiten** | **domeinen** | -| | | | | | -| | **eigenschappen** | | | | -+========================+=====================+======================+========================+=====================+ -| #Preventief | #Integriteit | #Beschermen | #Fysieke_beveiliging | #Bescherming | -| | | | | | -| #Detectief | #Beschikbaarheid | #Detecteren | | | -+------------------------+---------------------+----------------------+------------------------+---------------------+ - -**Beheersmaatregel** +## 7.11 Nutsvoorzieningen +### Beheersmaatregel Informatieverwerkende faciliteiten behoren te worden beschermd tegen stroomuitval en andere verstoringen die worden veroorzaakt door storingen in nutsvoorzieningen. -**Doel** +### Doel Verlies, schade of compromittering van informatie en andere gerelateerde bedrijfsmiddelen of onderbreking van de bedrijfsvoering van de organisatie vanwege verstoring en ontregeling van ondersteunende nutsvoorzieningen voorkomen. -**Richtlijn** +### Richtlijn Organisaties zijn afhankelijk van nutsvoorzieningen (bijvlektriciteit, telecommunicatie, water, gas, riolering, ventilatie en airconditioning) om hun informatieverwerkende faciliteiten te ondersteunenaarom behoort de organisatie: @@ -56,6 +65,5 @@ wijze en slechts wanneer dat nodig is met het internet wordt verbonden. Noodverlichting en communicatiemiddelen behoren aanwezig te zijnabij nooduitgangen of ruimten waar apparatuur aanwezig is, behoren noodschakelaars en knoppen te zijn waarmee stroom, water, gas of andere voorzieningen kunnen worden uitgeschakeldontactgegevens voor noodgevallen behoren te worden geregistreerd en bij uitval ter beschikking van het personeel te staan. -**Overige informatie** +### Overige informatie -Redundantie voor netwerkverbinding kan worden verkregen via meerdere routes vanaf meer dan één aanbieder. diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-7.12-Beveiligen-van-bekabeling.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-7.12-Beveiligen-van-bekabeling.md index f5d5b2f..494591b 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-7.12-Beveiligen-van-bekabeling.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-7.12-Beveiligen-van-bekabeling.md @@ -1,29 +1,34 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "7.12" +title: "Beveiligen van bekabeling" +theme: Physical +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: [Physical_security] +security_domains: [Protection] +tags: +- iso27002/2022/NL +- sourcetext +status: active --- - -+------------------------+----------------------+----------------------+------------------------+---------------------+ -| **Type** | **Informatie-** | **Cybersecurity-** | **Operationele** | **Beveiligings-** | -| | | | | | -| **beheersmaatregel** | **beveiligings-** | **concepten** | **capaciteiten** | **domeinen** | -| | | | | | -| | **eigenschappen** | | | | -+========================+======================+======================+========================+=====================+ -| #Preventief | #Vertrouwelijkheid | #Beschermen | #Fysieke_beveiliging | #Bescherming | -| | | | | | -| | #Beschikbaarheid | | | | -+------------------------+----------------------+----------------------+------------------------+---------------------+ - -**Beheersmaatregel** +## 7.12 Beveiligen van bekabeling +### Beheersmaatregel Voedingskabels en kabels voor het versturen van gegevens of die informatiediensten ondersteunen, behoren te worden beschermd tegen onderschepping, interferentie of beschadiging. -**Doel** +### Doel Verlies, schade, diefstal of compromittering van informatie en andere gerelateerde bedrijfsmiddelen en onderbreking van de bedrijfsvoering van de organisatie in verband met voedings- en communicatiekabels voorkomen. -**Richtlijn** +### Richtlijn Met de volgende richtlijnen voor beveiligen van bekabeling behoort rekening te worden gehouden: @@ -60,6 +65,5 @@ bestemming om fysieke identificatie en inspectie van de kabel mogelijk te maken. Specialistisch advies behoort te worden ingewonnen over het beheren van risico\'s die voortvloeien uit incidenten met of disfunctioneren van kabels. -**Overige informatie** +### Overige informatie -Soms worden voedings- en telecommunicatiekabels door meer dan één organisatie op één locatie gedeeld. diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-7.13-Onderhoud-van-apparatuur.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-7.13-Onderhoud-van-apparatuur.md index 03680e8..88436b4 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-7.13-Onderhoud-van-apparatuur.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-7.13-Onderhoud-van-apparatuur.md @@ -1,29 +1,39 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "7.13" +title: "Onderhoud van apparatuur" +theme: Physical +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: + - Physical_security + - Asset_management +security_domains: + - Protection + - Resilience +tags: +- iso27002/2022/NL +- sourcetext +status: active --- - -+------------------------+----------------------------------------------------+----------------------+-------------------------------------------------------+---------------------+ -| **Type** | **Informatie-** | **Cybersecurity-** | **Operationele** | **Beveiligings-** | -| | | | | | -| **beheersmaatregel** | **beveiligings-** | **concepten** | **capaciteiten** | **domeinen** | -| | | | | | -| | **eigenschappen** | | | | -+========================+====================================================+======================+=======================================================+=====================+ -| #Preventief | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | #Beschermen | #Fysieke_beveiliging #Beheer_van_be- drijfsmiddelen | #Bescherming | -| | | | | | -| | | | | #Veerkracht | -+------------------------+----------------------------------------------------+----------------------+-------------------------------------------------------+---------------------+ - -**Beheersmaatregel** +## 7.13 Onderhoud van apparatuur +### Beheersmaatregel Apparatuur behoort op de juiste wijze te worden onderhouden om de beschikbaarheid, integriteit en betrouwbaarheid van informatie te garanderen. -**Doel** +### Doel Verlies, schade, diefstal of compromittering van informatie en andere gerelateerde bedrijfsmiddelen en onderbreking van de bedrijfsvoering van de organisatie door gebrekkig onderhoud voorkomen. -**Richtlijn** +### Richtlijn De volgende richtlijnen voor onderhoud van apparatuur behoren in aanmerking te worden genomen: @@ -60,6 +70,5 @@ k) maatregelen toepassen voor het veilig verwijderen of hergebruiken van apparat indien wordt vastgesteld dat het nodig is apparatuur te verwijderen. -**Overige informatie** +### Overige informatie -Apparatuur omvat technische componenten van informatieverwerkende faciliteiten, UPS, batterijen en accu's, stroomgeneratoren, wisselstroomgeneratoren en vermogensomzetters, fysieke inbraakdetectiesystemen en -alarmen, rookmelders, brandblussers, airconditioning en liften. diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-7.14-Veilig-verwijderen-of-hergebruiken-van-apparatuur.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-7.14-Veilig-verwijderen-of-hergebruiken-van-apparatuur.md index b6801bd..6c5ac3f 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-7.14-Veilig-verwijderen-of-hergebruiken-van-apparatuur.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-7.14-Veilig-verwijderen-of-hergebruiken-van-apparatuur.md @@ -1,27 +1,34 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "7.14" +title: "Veilig verwijderen of hergebruiken van apparatuur" +theme: Physical +control_type: [Preventive] +information_security_properties: [Confidentiality] +cybersecurity_concepts: [Protect] +operational_capabilities: + - Physical_security + - Asset_management +security_domains: [Protection] +tags: +- iso27002/2022/NL +- sourcetext +status: active --- - -+------------------------+----------------------+----------------------+-------------------------------------------------------+---------------------+ -| **Type** | **Informatie-** | **Cybersecurity-** | **Operationele** | **Beveiligings-** | -| | | | | | -| **beheersmaatregel** | **beveiligings-** | **concepten** | **capaciteiten** | **domeinen** | -| | | | | | -| | **eigenschappen** | | | | -+========================+======================+======================+=======================================================+=====================+ -| #Preventief | #Vertrouwelijkheid | #Beschermen | #Fysieke_beveiliging #Beheer_van_be- drijfsmiddelen | #Bescherming | -+------------------------+----------------------+----------------------+-------------------------------------------------------+---------------------+ - -**Beheersmaatregel** +## 7.14 Veilig verwijderen of hergebruiken van apparatuur +### Beheersmaatregel Onderdelen van de apparatuur die opslagmedia bevatten, behoren te worden gecontroleerd om te waarborgen dat gevoelige gegevens en gelicentieerde software zijn verwijderd of veilig zijn overschreven voordat ze worden verwijderd of hergebruikt. -**Doel** +### Doel Het lekken van informatie via af te voeren of te hergebruiken apparatuur voorkomen. -**Richtlijn** +### Richtlijn Voorafgaand aan verwijdering of hergebruik behoort te worden gecontroleerd of apparatuur opslagmedia bevat. @@ -40,7 +47,7 @@ b) het minimaliseren van het risico dat systemen met gevoelige informatie erop w c) de mogelijkheid om de beheersmaatregelen in de volgende faciliteit opnieuw te gebruiken. -**Overige informatie** +### Overige informatie Voor beschadigde apparatuur die opslagmedia bevat, kan een risicobeoordeling nodig zijn om vast te stellen of het desbetreffende onderdeel van de apparatuur fysiek behoort te worden vernietigd in plaats van te worden gerepareerd of verwijderdnformatie kan worden gecompromitteerd door onzorgvuldige verwijdering of door hergebruik van apparatuur. @@ -67,4 +74,3 @@ Zie ISO/IEC 27040 voor nadere informatie over methoden om opslagmedia leeg te ma -# 8 Technologische beheersmaatregelen diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-7.2-Fysieke-toegangsbeveiliging.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-7.2-Fysieke-toegangsbeveiliging.md index bf1fb19..380a128 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-7.2-Fysieke-toegangsbeveiliging.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-7.2-Fysieke-toegangsbeveiliging.md @@ -1,30 +1,40 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "7.2" +title: "Fysieke toegangsbeveiliging" +theme: Physical +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: + - Physical_security + - Identity_and_access_management +security_domains: [Protection] +tags: +- iso27002/2022/NL +- sourcetext +status: active --- - -+------------------------+----------------------------------------------------+----------------------+----------------------------------------------------------+---------------------+ -| **Type** | **Informatie-** | **Cybersecurity-** | **Operationele** | **Beveiligings-** | -| | | | | | -| **beheersmaatregel** | **beveiligings-** | **concepten** | **capaciteiten** | **domeinen** | -| | | | | | -| | **eigenschappen** | | | | -+========================+====================================================+======================+==========================================================+=====================+ -| #Preventief | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | #Beschermen | #Fysieke_beveiliging #Identiteits- \_en_toegangsbeheer | #Bescherming | -+------------------------+----------------------------------------------------+----------------------+----------------------------------------------------------+---------------------+ - -**Beheersmaatregel** +## 7.2 Fysieke toegangsbeveiliging +### Beheersmaatregel Beveiligde zones behoren te worden beschermd door passende toegangscontroles en toegangspunten. -**Doel** +### Doel Bewerkstelligen dat er alleen bevoegde fysieke toegang tot de informatie en andere gerelateerde bedrijfsmiddelen van de organisatie plaatsvindt. -**Richtlijn** +### Richtlijn <u>Algemeen</u> @@ -123,4 +133,3 @@ g) inkomende leveringen inspecteren op bewijs van manipulatie onderwegndien verv ontdekt, behoort dit direct aan beveiligingspersoneel te worden gemeld. -**Overige informatie** Geen overige informatie. diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-7.3-Beveiligen-van-kantoren-ruimten-en-faciliteiten.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-7.3-Beveiligen-van-kantoren-ruimten-en-faciliteiten.md index 493e6b4..9c20316 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-7.3-Beveiligen-van-kantoren-ruimten-en-faciliteiten.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-7.3-Beveiligen-van-kantoren-ruimten-en-faciliteiten.md @@ -1,30 +1,40 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "7.3" +title: "Beveiligen van kantoren, ruimten en faciliteiten" +theme: Physical +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: + - Physical_security + - Asset_management +security_domains: [Protection] +tags: +- iso27002/2022/NL +- sourcetext +status: active --- - -+------------------------+----------------------------------------------------+----------------------+-------------------------------------------------------+---------------------+ -| **Type** | **Informatie-** | **Cybersecurity-** | **Operationele** | **Beveiligings-** | -| | | | | | -| **beheersmaatregel** | **beveiligings-** | **concepten** | **capaciteiten** | **domeinen** | -| | | | | | -| | **eigenschappen** | | | | -+========================+====================================================+======================+=======================================================+=====================+ -| #Preventief | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | #Beschermen | #Fysieke_beveiliging #Beheer_van_be- drijfsmiddelen | #Bescherming | -+------------------------+----------------------------------------------------+----------------------+-------------------------------------------------------+---------------------+ - -**Beheersmaatregel** +## 7.3 Beveiligen van kantoren, ruimten en faciliteiten +### Beheersmaatregel Voor kantoren, ruimten en faciliteiten behoort fysieke beveiliging te worden ontworpen en geïmplementeerd. -**Doel** +### Doel Onbevoegde fysieke toegang tot, schade aan en interferentie met informatie en andere gerelateerde bedrijfsmiddelen van de organisatie in kantoren, ruimten en faciliteiten voorkomen. -**Richtlijn** +### Richtlijn Bij het beveiligen van kantoren, ruimten en faciliteiten behoren de volgende richtlijnen in aanmerking te worden genomen: @@ -38,4 +48,3 @@ c) faciliteiten zo configureren dat wordt voorkomen dat vertrouwelijke informati d) ervoor zorgen dat adreslijsten, interne telefoongidsen en online toegankelijke plattegronden met daarop de locaties van faciliteiten waar vertrouwelijke informatie wordt verwerkt, niet gemakkelijk beschikbaar zijn voor onbevoegden. -**Overige informatie** Geen overige informatie. diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-7.4-Monitoren-van-de-fysieke-beveiliging.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-7.4-Monitoren-van-de-fysieke-beveiliging.md index f8cc2ef..b24dc3e 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-7.4-Monitoren-van-de-fysieke-beveiliging.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-7.4-Monitoren-van-de-fysieke-beveiliging.md @@ -1,29 +1,41 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "7.4" +title: "Monitoren van de fysieke beveiliging" +theme: Physical +control_type: + - Preventive + - Detective +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: + - Protect + - Detect +operational_capabilities: [Physical_security] +security_domains: + - Protection + - Defence +tags: +- iso27002/2022/NL +- sourcetext +status: active --- - -+------------------------+----------------------------------------------------+----------------------+------------------------+---------------------+ -| **Type** | **Informatie-** | **Cybersecurity-** | **Operationele** | **Beveiligings-** | -| | | | | | -| **beheersmaatregel** | **beveiligings-** | **concepten** | **capaciteiten** | **domeinen** | -| | | | | | -| | **eigenschappen** | | | | -+========================+====================================================+======================+========================+=====================+ -| #Preventief | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | #Beschermen | #Fysieke_beveiliging | #Bescherming | -| | | | | | -| #Detectief | | #Detecteren | | #Verdediging | -+------------------------+----------------------------------------------------+----------------------+------------------------+---------------------+ - -**Beheersmaatregel** +## 7.4 Monitoren van de fysieke beveiliging +### Beheersmaatregel Het gebouw en terrein behoort voortdurend te worden gemonitord op onbevoegde fysieke toegang. -**Doel** +### Doel Onbevoegde fysieke toegang detecteren en ontmoedigen. -**Richtlijn** +### Richtlijn Fysieke terreinen en gebouwen behoren te worden bewaakt door bewakingssystemen die kunnen bestaan uit bewakers, inbraakalarmen, videobewakingssystemen zoals gesloten televisiecircuits en software voor het beheer van informatie over fysieke beveiliging die intern of door een aanbieder van bewakingsdiensten wordt beheerd. @@ -60,4 +72,3 @@ Het bedieningspaneel van het alarmsysteem behoort in een met een alarm beveiligd Elk monitoring- en opnamemechanisme behoort te worden gebruikt met inachtneming van de plaatselijke wet- en regelgeving, met inbegrip van de wetgeving inzake gegevensbescherming en de bescherming van persoonsgegevens, met name wat betreft het monitoren van werknemers en de bewaringstermijnen voor video-opnamen. -**Overige informatie** Geen overige informatie. diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-7.5-Beschermen-tegen-fysieke-en-omgevingsdreigingen.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-7.5-Beschermen-tegen-fysieke-en-omgevingsdreigingen.md index ff67a2f..727123b 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-7.5-Beschermen-tegen-fysieke-en-omgevingsdreigingen.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-7.5-Beschermen-tegen-fysieke-en-omgevingsdreigingen.md @@ -1,27 +1,35 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "7.5" +title: "Beschermen tegen fysieke en omgevingsdreigingen" +theme: Physical +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: [Physical_security] +security_domains: [Protection] +tags: +- iso27002/2022/NL +- sourcetext +status: active --- - -+------------------------+----------------------------------------------------+----------------------+------------------------+---------------------+ -| **Type** | **Informatie-** | **Cybersecurity-** | **Operationele** | **Beveiligings-** | -| | | | | | -| **beheersmaatregel** | **beveiligings-** | **concepten** | **capaciteiten** | **domeinen** | -| | | | | | -| | **eigenschappen** | | | | -+========================+====================================================+======================+========================+=====================+ -| #Preventief | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | #Beschermen | #Fysieke_beveiliging | #Bescherming | -+------------------------+----------------------------------------------------+----------------------+------------------------+---------------------+ - -**Beheersmaatregel** +## 7.5 Beschermen tegen fysieke en omgevingsdreigingen +### Beheersmaatregel Er behoort bescherming tegen fysieke en omgevingsdreigingen, zoals natuurrampen en andere opzettelijke of onopzettelijke fysieke dreigingen van de infrastructuur, te worden ontworpen en geïmplementeerd. -**Doel** +### Doel De gevolgen van gebeurtenissen die voortvloeien uit fysieke en omgevingsdreigingen, voorkomen of beperken. -**Richtlijn** +### Richtlijn Risicobeoordelingen om de potentiële gevolgen van fysieke en omgevingsdreigingen te identificeren, behoren voorafgaand aan kritische activiteiten op een fysieke locatie en met regelmatige tussenpozen te worden uitgevoerde nodige voorzorgsmaatregelen behoren te worden getroffen en veranderingen in de dreigingen behoren te worden gemonitordpecialistisch advies behoort te worden ingewonnen over het beheren van risico\'s die voortvloeien uit fysieke en omgevingsdreigingen, zoals brand, overstroming, aardbeving, explosie, oproer, toxisch afval, uitstoot van milieubelastende stoffen en andere vormen van natuurrampen of door personen veroorzaakte rampen. @@ -48,8 +56,7 @@ c) stroompieken: systemen die zowel server- als clientinformatiesystemen tegen s d) explosieven en wapens: steekproefsgewijze inspecties verrichten naar de aanwezigheid van explosieven of wapens bij personeel, in voertuigen of in goederen die faciliteiten binnenkomen waar gevoelige informatie wordt verwerkt. -**Overige informatie** +### Overige informatie Kluizen en andere vormen van beveiligde opslagvoorzieningen kunnen de daarin opgeslagen informatie beschermen tegen rampen zoals brand, aardbeving, overstroming of explosie. -Organisaties kunnen de concepten van criminaliteitspreventie door het ontwerp van de omgeving in overweging nemen bij het ontwerpen van de beheersmaatregelen om hun omgeving te beveiligen en dreigingen die inherent zijn aan stedelijke omgevingen, te beperkenn plaats van verkeerspalen te gebruiken, kunnen bijvoorbeeld standbeelden of waterpartijen als decoratie en als fysieke barrière fungeren. diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-7.6-Werken-in-beveiligde-zones.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-7.6-Werken-in-beveiligde-zones.md index 251e176..3dfb348 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-7.6-Werken-in-beveiligde-zones.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-7.6-Werken-in-beveiligde-zones.md @@ -1,27 +1,35 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "7.6" +title: "Werken in beveiligde zones" +theme: Physical +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: [Physical_security] +security_domains: [Protection] +tags: +- iso27002/2022/NL +- sourcetext +status: active --- - -+------------------------+----------------------------------------------------+----------------------+------------------------+---------------------+ -| **Type** | **Informatie-** | **Cybersecurity-** | **Operationele** | **Beveiligings-** | -| | | | | | -| **beheersmaatregel** | **beveiligings-** | **concepten** | **capaciteiten** | **domeinen** | -| | | | | | -| | **eigenschappen** | | | | -+========================+====================================================+======================+========================+=====================+ -| #Preventief | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | #Beschermen | #Fysieke_beveiliging | #Bescherming | -+------------------------+----------------------------------------------------+----------------------+------------------------+---------------------+ - -**Beheersmaatregel** +## 7.6 Werken in beveiligde zones +### Beheersmaatregel Voor het werken in beveiligde zones behoren beveiligingsmaatregelen te worden ontwikkeld en geïmplementeerd. -**Doel** +### Doel Informatie en andere gerelateerde bedrijfsmiddelen in beveiligde zones beschermen tegen schade en onbevoegde verstoring door personeel dat in deze zones aan het werk is. -**Richtlijn** +### Richtlijn De beveiligingsmaatregelen voor het werken in beveiligde gebieden behoren van toepassing te zijn op al het personeel en behoren alle activiteiten te bestrijken die in de beveiligde zone plaatsvinden. @@ -50,4 +58,3 @@ behoren beheersen; f) noodprocedures duidelijk zichtbaar en toegankelijk ophangen. -**Overige informatie** Geen overige informatie. diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-7.7-Clear-desk-en-clear-screen.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-7.7-Clear-desk-en-clear-screen.md index 8b92a85..37ae317 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-7.7-Clear-desk-en-clear-screen.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-7.7-Clear-desk-en-clear-screen.md @@ -1,27 +1,32 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "7.7" +title: "‘Clear desk’ en ‘clear screen’" +theme: Physical +control_type: [Preventive] +information_security_properties: [Confidentiality] +cybersecurity_concepts: [Protect] +operational_capabilities: [Physical_security] +security_domains: [Protection] +tags: +- iso27002/2022/NL +- sourcetext +status: active --- - -+------------------------+----------------------+----------------------+------------------------+---------------------+ -| **Type** | **Informatie-** | **Cybersecurity-** | **Operationele** | **Beveiligings-** | -| | | | | | -| **beheersmaatregel** | **beveiligings-** | **concepten** | **capaciteiten** | **domeinen** | -| | | | | | -| | **eigenschappen** | | | | -+========================+======================+======================+========================+=====================+ -| #Preventief | #Vertrouwelijkheid | #Beschermen | #Fysieke_beveiliging | #Bescherming | -+------------------------+----------------------+----------------------+------------------------+---------------------+ - -**Beheersmaatregel** +## 7.7 ‘Clear desk’ en ‘clear screen’ +### Beheersmaatregel Er behoren 'clear desk'-regels voor papieren documenten en verwijderbare opslagmedia en 'clear screen'-regels voor informatieverwerkende faciliteiten te worden gedefinieerd en op passende wijze ten uitvoer worden gebracht. -**Doel** +### Doel De risico\'s op onbevoegde toegang tot, verlies van en schade aan informatie op bureaus, schermen en op andere toegankelijke plaatsen tijdens en buiten de gebruikelijke werkuren beperken. -**Richtlijn** +### Richtlijn De organisatie behoort een onderwerpspecifiek beleid inzake 'clear desk' en 'clear screen' vast te stellen en aan alle relevante belanghebbenden mee te delen. @@ -52,4 +57,3 @@ niet meer nodig is. De organisatie behoort te beschikken over procedures voor het ontruimen van faciliteiten, waaronder een laatste doorzoeking voorafgaand aan vertrek om te garanderen dat er geen bedrijfsmiddelen van de organisatie worden achtergelaten (bijvocumenten die achter laden of meubilair zijn gevallen). -**Overige informatie** Geen overige informatie. diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-7.8-Plaatsen-en-beschermen-van-apparatuur.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-7.8-Plaatsen-en-beschermen-van-apparatuur.md index affb117..0f6071a 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-7.8-Plaatsen-en-beschermen-van-apparatuur.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-7.8-Plaatsen-en-beschermen-van-apparatuur.md @@ -1,27 +1,37 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "7.8" +title: "Plaatsen en beschermen van apparatuur" +theme: Physical +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: + - Physical_security + - Asset_management +security_domains: [Protection] +tags: +- iso27002/2022/NL +- sourcetext +status: active --- - -+------------------------+----------------------------------------------------+----------------------+-------------------------------------------------------+---------------------+ -| **Type** | **Informatie-** | **Cybersecurity-** | **Operationele** | **Beveiligings-** | -| | | | | | -| **beheersmaatregel** | **beveiligings-** | **concepten** | **capaciteiten** | **domeinen** | -| | | | | | -| | **eigenschappen** | | | | -+========================+====================================================+======================+=======================================================+=====================+ -| #Preventief | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | #Beschermen | #Fysieke_beveiliging #Beheer_van_be- drijfsmiddelen | #Bescherming | -+------------------------+----------------------------------------------------+----------------------+-------------------------------------------------------+---------------------+ - -**Beheersmaatregel** +## 7.8 Plaatsen en beschermen van apparatuur +### Beheersmaatregel Apparatuur behoort veilig te worden geplaatst en beschermd. -**Doel** +### Doel De risico\'s op fysieke en omgevingsdreigingen en op toegang door onbevoegden en schade beperken. -**Richtlijn** +### Richtlijn Om apparatuur te beschermen behoren de volgende richtlijnen in overweging te worden genomen: @@ -58,4 +68,3 @@ i) informatieverwerkende faciliteiten die worden beheerd door de organisatie fys informatieverwerkende faciliteiten die niet door de organisatie worden beheerd. -**Overige informatie** Geen overige informatie. diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-7.9-Beveiligen-van-bedrijfsmiddelen-buiten-het-terrein.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-7.9-Beveiligen-van-bedrijfsmiddelen-buiten-het-terrein.md index c73404a..36acf7a 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-7.9-Beveiligen-van-bedrijfsmiddelen-buiten-het-terrein.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-7.9-Beveiligen-van-bedrijfsmiddelen-buiten-het-terrein.md @@ -1,27 +1,37 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "7.9" +title: "Beveiligen van bedrijfsmiddelen buiten het terrein" +theme: Physical +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: + - Physical_security + - Asset_management +security_domains: [Protection] +tags: +- iso27002/2022/NL +- sourcetext +status: active --- - -+------------------------+----------------------------------------------------+----------------------+-------------------------------------------------------+---------------------+ -| **Type** | **Informatie-** | **Cybersecurity-** | **Operationele** | **Beveiligings-** | -| | | | | | -| **beheersmaatregel** | **beveiligings-** | **concepten** | **capaciteiten** | **domeinen** | -| | | | | | -| | **eigenschappen** | | | | -+========================+====================================================+======================+=======================================================+=====================+ -| #Preventief | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | #Beschermen | #Fysieke_beveiliging #Beheer_van_be- drijfsmiddelen | #Bescherming | -+------------------------+----------------------------------------------------+----------------------+-------------------------------------------------------+---------------------+ - -**Beheersmaatregel** +## 7.9 Beveiligen van bedrijfsmiddelen buiten het terrein +### Beheersmaatregel Bedrijfsmiddelen buiten het gebouw en/of terrein behoren te worden beschermd. -**Doel** +### Doel Verlies, schade, diefstal of compromittering van bedrijfsmiddelen buiten het gebouw en/of terrein en onderbreking van de bedrijfsvoering van de organisatie voorkomen. -**Richtlijn** +### Richtlijn Het is nodig apparatuur die buiten het gebouw en/of terrein van de organisatie wordt gebruikt en waarop informatie wordt opgeslagen of verwerkt (bijven mobiel apparaat), met inbegrip van apparaten die eigendom zijn van de organisatie en apparaten die particulier eigendom zijn en gebruikt worden namens de organisatie ['bring your own device (BYOD)'], te beschermenet gebruik van deze apparaten behoort door het management te worden goedgekeurd. @@ -62,6 +72,5 @@ c) fysieke toegangsbeveiligingsmaatregelen en beheersmaatregelen om manipuleren d) logische toegangsbeveiligingsmaatregelen. -**Overige informatie** +### Overige informatie -Meer informatie over andere aspecten van de bescherming van apparatuur waarop informatie wordt opgeslagen en verwerkt, en 'endpoint devices' van gebruikers is te vinden in 8en 6 diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-8.1-User-endpoint-devices.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-8.1-User-endpoint-devices.md index 3469dc9..ffa89c5 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-8.1-User-endpoint-devices.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-8.1-User-endpoint-devices.md @@ -1,28 +1,37 @@ - -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "8.1" +title: "‘User endpoint devices’" +theme: Technological +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: + - Asset_management + - Information_protection +security_domains: [Protection] +tags: +- iso27002/2022/NL +- sourcetext +status: active --- - -+------------------------+----------------------------------------------------+----------------------+---------------------------------------------------------+---------------------+ -| **Type** | **Informatie-** | **Cybersecurity-** | **Operationele** | **Beveiligings-** | -| | | | | | -| **beheersmaatregel** | **beveiligings-** | **concepten** | **capaciteiten** | **domeinen** | -| | | | | | -| | **eigenschappen** | | | | -+========================+====================================================+======================+=========================================================+=====================+ -| #Preventief | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | #Beschermen | #Beheer_van_bedrijfs- middelen #Informatiebescherming | #Bescherming | -+------------------------+----------------------------------------------------+----------------------+---------------------------------------------------------+---------------------+ - -**Beheersmaatregel** +## 8.1 ‘User endpoint devices’ +### Beheersmaatregel Informatie die is opgeslagen op, wordt verwerkt door of toegankelijk is via 'user endpoint devices' behoort te worden beschermd. -**Doel** +### Doel Informatie beschermen tegen de risico\'s als gevolg van het gebruik van 'user endpoint devices'. -**Richtlijn** +### Richtlijn <u>Algemeen</u> @@ -124,10 +133,9 @@ b) het gebruik van draadloze of bedrade verbindingen met passende bandbreedte ov relevante onderwerpspecifieke beleidsregels (bijvmdat back-ups of software-updates nodig zijn). -**Overige informatie** +### Overige informatie Beheersmaatregelen voor het beschermen van informatie op 'user endpoint devices' zijn afhankelijk van of het 'endpoint device' van de gebruiker alleen binnen het beveiligde gebouw en terrein en de beveiligde netwerkverbindingen van de organisatie wordt gebruikt of dat het wordt blootgesteld aan meer fysieke en netwerkgerelateerde dreigingen buiten de organisatie. De draadloze verbindingen van 'user endpoint devices' zijn gelijksoortig aan andere vormen van netwerkverbindingen, maar hebben belangrijke verschillen waar rekening mee behoort te worden gehouden bij het identificeren van beheersmaatregelenr kan met name soms iets fout gaan bij het maken van back-ups van informatie die op 'user endpoint devices' is opgeslagen indien de bandbreedte van het netwerk beperkt is of 'user endpoint devices' niet zijn aangesloten op de tijden waarop de back-ups zijn gepland. -Voor bepaalde USB-poorten, zoals USB-C, is het niet mogelijk de USB-poort uit te schakelen, omdat deze voor andere doelen (bijvoeding of als uitgang voor een weergavescherm) in gebruik is. diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-8.10-Wissen-van-informatie.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-8.10-Wissen-van-informatie.md index 00f2edd..105e8ba 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-8.10-Wissen-van-informatie.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-8.10-Wissen-van-informatie.md @@ -1,27 +1,34 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "8.10" +title: "Wissen van informatie" +theme: Technological +control_type: [Preventive] +information_security_properties: [Confidentiality] +cybersecurity_concepts: [Protect] +operational_capabilities: + - Information_protection + - Legal_and_compliance +security_domains: [Protection] +tags: +- iso27002/2022/NL +- sourcetext +status: active --- - -+------------------------+----------------------+----------------------+-------------------------------------------------------+---------------------+ -| **Type** | **Informatie-** | **Cybersecurity-** | **Operationele** | **Beveiligings-** | -| | | | | | -| **beheersmaatregel** | **beveiligings-** | **concepten** | **capaciteiten** | **domeinen** | -| | | | | | -| | **eigenschappen** | | | | -+========================+======================+======================+=======================================================+=====================+ -| #Preventief | #Vertrouwelijkheid | #Beschermen | #Informatiebe- scherming #Juridisch_en_com- pliance | #Bescherming | -+------------------------+----------------------+----------------------+-------------------------------------------------------+---------------------+ - -**Beheersmaatregel** +## 8.10 Wissen van informatie +### Beheersmaatregel In informatiesystemen, apparaten of andere opslagmedia opgeslagen informatie behoort te worden gewist als deze niet langer nodig is. -**Doel** +### Doel Onnodige openbaarmaking van gevoelige informatie voorkomen en aan de eisen van wet- en regelgeving, statutaire en contractuele eisen voor het wissen van informatie voldoen. -**Richtlijn** +### Richtlijn <u>Algemeen</u> @@ -70,6 +77,5 @@ De in 7 beschreven beheersmaatregelen behoren te worden toegepast om het opslaga Een officiële registratie van het wissen van informatie is nuttig om de oorzaak van een mogelijk lek van informatie te analyseren. -**Overige informatie** +### Overige informatie -Informatie over het wissen van gebruikersgegevens in clouddiensten is te vinden in ISO/IEC 27017nformatie over het wissen van persoonsgegevens is te vinden in ISO/IEC 27555. diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-8.11-Maskeren-van-gegevens.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-8.11-Maskeren-van-gegevens.md index 0c651fd..9411283 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-8.11-Maskeren-van-gegevens.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-8.11-Maskeren-van-gegevens.md @@ -1,27 +1,32 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "8.11" +title: "Maskeren van gegevens" +theme: Technological +control_type: [Preventive] +information_security_properties: [Confidentiality] +cybersecurity_concepts: [Protect] +operational_capabilities: [Information_protection] +security_domains: [Protection] +tags: +- iso27002/2022/NL +- sourcetext +status: active --- - -+------------------------+----------------------+----------------------+--------------------------+---------------------+ -| **Type** | **Informatie-** | **Cybersecurity-** | **Operationele** | **Beveiligings-** | -| | | | | | -| **beheersmaatregel** | **beveiligings-** | **concepten** | **capaciteiten** | **domeinen** | -| | | | | | -| | **eigenschappen** | | | | -+========================+======================+======================+==========================+=====================+ -| #Preventief | #Vertrouwelijkheid | #Beschermen | #Informatiebescherming | #Bescherming | -+------------------------+----------------------+----------------------+--------------------------+---------------------+ - -**Beheersmaatregel** +## 8.11 Maskeren van gegevens +### Beheersmaatregel Gegevens behoren te worden gemaskeerd overeenkomstig het onderwerpspecifieke beleid inzake toegangsbeveiliging en andere gerelateerde onderwerpspecifieke beleidsregels, en bedrijfseisen van de organisatie, rekening houdend met de toepasselijke wetgeving. -**Doel** +### Doel De openbaarmaking van gevoelige informatie met inbegrip van persoonsgegevens beperken en aan de eisen van wet- en regelgeving, statutaire en contractuele eisen voldoen. -**Richtlijn** +### Richtlijn Indien de bescherming van gevoelige gegevens (bijversoonsgegevens) een punt van zorg is, behoort de organisatie te overwegen dergelijke gegevens te verbergen door gebruik te maken van technieken als het maskeren, pseudonimiseren of anonimiseren van gegevens. @@ -80,7 +85,7 @@ betrokkene te identificeren; e) de verstrekking en ontvangst van de verwerkte gegevens bijhouden. -**Overige informatie** +### Overige informatie Door anonimisering worden persoonsgegevens dusdanig onomkeerbaar gewijzigd dat de betrokkene niet langer rechtstreeks of indirect kan worden geïdentificeerd. @@ -101,4 +106,3 @@ Persoonsgegevens in identificatiecodes van middelen en de bijbehorende attribute Aanvullende beheersmaatregelen met betrekking tot de bescherming van persoonsgegevens in publieke clouds worden gegeven in ISO/IEC 27018. -Aanvullende informatie over de-identificatietechnieken is te vinden in ISO/IEC 20889. diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-8.12-Voorkomen-van-gegevenslekken-Data-leakage-prevention.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-8.12-Voorkomen-van-gegevenslekken-Data-leakage-prevention.md index 9777823..f373292 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-8.12-Voorkomen-van-gegevenslekken-Data-leakage-prevention.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-8.12-Voorkomen-van-gegevenslekken-Data-leakage-prevention.md @@ -1,29 +1,38 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "8.12" +title: "Voorkomen van gegevenslekken (Data leakage prevention)" +theme: Technological +control_type: + - Preventive + - Detective +information_security_properties: [Confidentiality] +cybersecurity_concepts: + - Protect + - Detect +operational_capabilities: [Information_protection] +security_domains: + - Protection + - Defence +tags: +- iso27002/2022/NL +- sourcetext +status: active --- - -+------------------------+----------------------+----------------------+----------------------------+---------------------+ -| **Type** | **Informatie-** | **Cybersecurity-** | **Operationele** | **Beveiligings-** | -| | | | | | -| **beheersmaatregel** | **beveiligings-** | **concepten** | **capaciteiten** | **domeinen** | -| | | | | | -| | **eigenschappen** | | | | -+========================+======================+======================+============================+=====================+ -| #Preventief | #Vertrouwelijkheid | #Beschermen | #Informatiebe- scherming | #Bescherming | -| | | | | | -| #Detectief | | #Detecteren | | #Verdediging | -+------------------------+----------------------+----------------------+----------------------------+---------------------+ - -**Beheersmaatregel** +## 8.12 Voorkomen van gegevenslekken (Data leakage prevention) +### Beheersmaatregel Maatregelen om gegevenslekken te voorkomen behoren te worden toegepast in systemen, netwerken en andere apparaten waarop of waarmee gevoelige informatie wordt verwerkt, opgeslagen of getransporteerd. -**Doel** +### Doel Om de ongeoorloofde openbaarmaking en extractie van informatie door personen of systemen te detecteren en te voorkomen. -**Richtlijn** +### Richtlijn De organisatie behoort het volgende te overwegen om het risico op gegevenslekken te beperken: @@ -64,7 +73,7 @@ Indien er een back-up van gegevens wordt gemaakt, behoort ervoor te worden gezor Het voorkomen van gegevenslekken behoort ook te worden beschouwd als een vorm van bescherming tegen de acties van tegenstanders om vertrouwelijke of geheime informatie (geopolitieke, menselijke, financiële, commerciële, wetenschappelijke of andere informatie) te verkrijgen die van belang kan zijn voor spionage of essentieel kan zijn voor de gemeenschape maatregelen ter voorkoming van het lekken van gegevens behoren erop gericht te zijn verwarring te zaaien wat betreft de beslissingen van de tegenstander, bijvoorbeeld door authentieke informatie te vervangen door valse informatie, hetzij als een eigen maatregel, hetzij als reactie op de acties van de tegenstander om informatie te verzamelenoorbeelden van dergelijke maatregelen zijn omgekeerde 'social engineering' of het gebruik van 'honeypots' om aanvallers te lokken. -**Overige informatie** +### Overige informatie Hulpmiddelen om gegevenslekken te voorkomen, zijn ervoor ontworpen om gegevens te identificeren, het gebruik en de verplaatsing van gegevens te monitoren, en maatregelen te nemen om gegevenslekken te voorkomen (bijvebruikers waarschuwen voor hun risicogedrag en de overdracht van gegevens naar draagbare opslagapparatuur blokkeren). @@ -73,4 +82,3 @@ Een inherent element van het voorkomen van gegevenslekken is toezicht op de comm -Het voorkomen van gegevenslekken kan worden ondersteund door standaardbeheersmaatregelen voor informatiebeveiliging, zoals onderwerpspecifiek beleid inzake toegangscontrole en veilig documentenbeheer (zie 5.15 en 5.37). diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-8.13-Back-up-van-informatie.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-8.13-Back-up-van-informatie.md index 24d3f9f..e7b4f88 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-8.13-Back-up-van-informatie.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-8.13-Back-up-van-informatie.md @@ -1,29 +1,34 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "8.13" +title: "Back-up van informatie" +theme: Technological +control_type: [Corrective] +information_security_properties: + - Integrity + - Availability +cybersecurity_concepts: [Recover] +operational_capabilities: [Continuity] +security_domains: [Protection] +tags: +- iso27002/2022/NL +- sourcetext +status: active --- - -+------------------------+---------------------+----------------------+--------------------+---------------------+ -| **Type** | **Informatie-** | **Cybersecurity-** | **Operationele** | **Beveiligings-** | -| | | | | | -| **beheersmaatregel** | **beveiligings-** | **concepten** | **capaciteiten** | **domeinen** | -| | | | | | -| | **eigenschappen** | | | | -+========================+=====================+======================+====================+=====================+ -| #Corrigerend | #Integriteit | #Herstellen | #Continuïteit | #Bescherming | -| | | | | | -| | #Beschikbaarheid | | | | -+------------------------+---------------------+----------------------+--------------------+---------------------+ - -**Beheersmaatregel** +## 8.13 Back-up van informatie +### Beheersmaatregel Back-ups van informatie, software en systemen behoren te worden bewaard en regelmatig te worden getest overeenkomstig het overeengekomen onderwerpspecifieke beleid inzake back-ups. -**Doel** +### Doel Herstel mogelijk maken na verlies van gegevens of systemen. -**Richtlijn** +### Richtlijn Er behoort een onderwerpspecifiek beleid inzake back-ups te worden opgesteld met het oog op de eisen van de organisatie wat betreft het bewaren van gegevens en informatiebeveiliging. @@ -68,6 +73,5 @@ Wanneer de organisatie gebruikmaakt van een clouddienst, behoren er back-ups van Voor belangrijke bedrijfsinformatie behoort de bewaartermijn te worden vastgesteld, rekening houdend met eisen voor het bewaren van archiefkopieëne organisatie behoort na te denken over het wissen van informatie (zie 8.10) in of op opslagmedia zodra de bewaartermijn van de informatie verstrijkt en behoort hierbij de wet- en regelgeving in aanmerking te nemen. -**Overige informatie** +### Overige informatie -Zie voor verdere informatie over beveiligde opslag, met inbegrip van bewaarspecifieke overwegingen, ISO/IEC 27040. diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-8.14-Redundantie-van-informatieverwerkende-faciliteiten.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-8.14-Redundantie-van-informatieverwerkende-faciliteiten.md index 6085101..4896923 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-8.14-Redundantie-van-informatieverwerkende-faciliteiten.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-8.14-Redundantie-van-informatieverwerkende-faciliteiten.md @@ -1,32 +1,39 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "8.14" +title: "Redundantie van informatieverwerkende faciliteiten" +theme: Technological +control_type: [Preventive] +information_security_properties: [Availability] +cybersecurity_concepts: [Protect] +operational_capabilities: + - Continuity + - Asset_management +security_domains: + - Protection + - Resilience +tags: +- iso27002/2022/NL +- sourcetext +status: active --- - -+------------------------+---------------------+----------------------+------------------------------------------------+---------------------+ -| **Type** | **Informatie-** | **Cybersecurity-** | **Operationele** | **Beveiligings-** | -| | | | | | -| **beheersmaatregel** | **beveiligings-** | **concepten** | **capaciteiten** | **domeinen** | -| | | | | | -| | **eigenschappen** | | | | -+========================+=====================+======================+================================================+=====================+ -| #Preventief | #Beschikbaarheid | #Beschermen | #Continuïteit #Beheer_van_be- drijfsmiddelen | #Bescherming | -| | | | | | -| | | | | #Veerkracht | -+------------------------+---------------------+----------------------+------------------------------------------------+---------------------+ - -**Beheersmaatregel** +## 8.14 Redundantie van informatieverwerkende faciliteiten +### Beheersmaatregel Informatieverwerkende faciliteiten behoren met voldoende redundantie te worden geïmplementeerd om aan beschikbaarheidseisen te voldoen. -**Doel** +### Doel De ononderbroken werking van informatieverwerkende faciliteiten waarborgen. -**Richtlijn** +### Richtlijn De organisatie behoort eisen te identificeren voor de beschikbaarheid van zakelijke diensten en informatiesystemene organisatie behoort een systeemarchitectuur te ontwerpen en implementeren met passende redundantie om aan deze eisen te voldoen. @@ -54,7 +61,7 @@ in netwerken (bijvirewalls, routers, switches). Indien van toepassing, bij voorkeur in productiebedrijf, behoren redundante informatiesystemen te worden getest om te waarborgen dat de automatische omschakeling van de ene op de andere component bij storing werkt zoals voorzien. -**Overige informatie** +### Overige informatie Er bestaat een sterk verband tussen redundantie en de gereedheid van ICT voor bedrijfscontinuïteit (zie 5.30), vooral indien korte hersteltijden vereist zijneel van de redundantiemaatregelen kunnen deel uitmaken van de strategieën en oplossingen voor ICT-continuïteit. @@ -67,4 +74,3 @@ Redundantie in informatieverwerkende faciliteiten gaat meestal niet in op het ni Met het gebruik van 'public cloud computing' is het mogelijk om meerdere liveversies van informatieverwerkende faciliteiten te hebben, die zich op meerdere afzonderlijke fysieke locaties bevinden met automatische omschakeling bij storingen en onderlinge loadbalancing. -Een aantal technologieën en technieken voor het voorzien in redundantie en automatische omschakeling bij storingen in de context van clouddiensten wordt besproken in ISO/IEC TS 23167. diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-8.15-Logging.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-8.15-Logging.md index f478254..0e19afd 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-8.15-Logging.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-8.15-Logging.md @@ -1,29 +1,60 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "8.15" +title: "Logging" +theme: Technological +control_type: [Detective] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Detect] +operational_capabilities: [Information_security_event_management] +security_domains: + - Protection + - Defence +tags: +- iso27002/2022/NL +- sourcetext +status: active --- - -+------------------------+----------------------------------------------------+----------------------+--------------------------------------------------------+---------------------+ -| **Type** | **Informatie-** | **Cybersecurity-** | **Operationele** | **Beveiligings-** | -| | | | | | -| **beheersmaatregel** | **beveiligings-** | **concepten** | **capaciteiten** | **domeinen** | -| | | | | | -| | **eigenschappen** | | | | -+========================+====================================================+======================+========================================================+=====================+ -| #Detectief | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | #Detecteren | #Beheer_van_infor- matiebeveiligings- gebeurtenissen | #Bescherming | -| | | | | | -| | | | | #Verdediging | -+------------------------+----------------------------------------------------+----------------------+--------------------------------------------------------+---------------------+ - -**Beheersmaatregel** +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "8.15" +title: "Logging" +theme: Technological +control_type: [Detective] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Detect] +operational_capabilities: [Information_security_event_management] +security_domains: + - Protection + - Defence +tags: +- iso27002/2022/NL +- sourcetext +status: active +--- +## 8.15 Logging +### Beheersmaatregel Er behoren logbestanden waarin activiteiten, uitzonderingen, fouten en andere relevante gebeurtenissen worden geregistreerd te worden geproduceerd, opgeslagen, beschermd en geanalyseerd. -**Doel** +### Doel Gebeurtenissen registreren, bewijs genereren, de integriteit van informatie in logbestanden waarborgen, onbevoegde toegang voorkomen, informatiebeveiligingsgebeurtenissen identificeren die tot een informatiebeveiligingsincident kunnen leiden en onderzoeken ondersteunen. -**Richtlijn** +### Richtlijn <u>Algemeen</u> @@ -148,7 +179,7 @@ Vermeende en daadwerkelijke informatiebeveiligingsincidenten behoren te worden g -**Overige informatie** +### Overige informatie Systeemlogbestanden bevatten vaak een grote hoeveelheid informatie, waarvan een groot deel irrelevant is voor het monitoren van informatiebeveiligingm belangrijke gebeurtenissen voor het monitoren in het kader van informatiebeveiliging te helpen identificeren, kan het gebruik van geschikte systeemhulpmiddelen of auditinstrumenten voor het bevragen van bestanden worden overwogen. @@ -158,4 +189,3 @@ Er kan een hulpmiddel voor het beheer van beveiligingsinformatie en -gebeurtenis Er worden openbaar transparante bestanden gebruikt voor het registreren van logbestanden, bijvoorbeeld in systemen voor de transparantie van certificatenergelijke bestanden kunnen een extra detectiemechanisme bieden dat nuttig is ter bescherming tegen manipulatie van logbestanden. -In cloudomgevingen kunnen de afnemer en de leverancier van de clouddienst de verantwoordelijkheden voor het beheer van logbestanden met elkaar delene verantwoordelijkheden variëren afhankelijk van de soort clouddienst die wordt gebruikterdere richtlijnen zijn te vinden in ISO/IEC 27017. diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-8.16-Monitoren-van-activiteiten.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-8.16-Monitoren-van-activiteiten.md index d73cf54..807665a 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-8.16-Monitoren-van-activiteiten.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-8.16-Monitoren-van-activiteiten.md @@ -1,29 +1,39 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "8.16" +title: "Monitoren van activiteiten" +theme: Technological +control_type: + - Detective + - Corrective +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: + - Detect + - Respond +operational_capabilities: [Information_security_event_management] +security_domains: [Defence] +tags: +- iso27002/2022/NL +- sourcetext +status: active --- - -+------------------------+----------------------------------------------------+----------------------+--------------------------------------------------------+---------------------+ -| **Type** | **Informatie-** | **Cybersecurity-** | **Operationele** | **Beveiligings-** | -| | | | | | -| **beheersmaatregel** | **beveiligings-** | **concepten** | **capaciteiten** | **domeinen** | -| | | | | | -| | **eigenschappen** | | | | -+========================+====================================================+======================+========================================================+=====================+ -| #Detectief | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | #Detecteren | #Beheer_van_infor- matiebeveiligings- gebeurtenissen | #Verdediging | -| | | | | | -| #Corrigerend | | #Reageren | | | -+------------------------+----------------------------------------------------+----------------------+--------------------------------------------------------+---------------------+ - -**Beheersmaatregel** +## 8.16 Monitoren van activiteiten +### Beheersmaatregel Netwerken, systemen en toepassingen behoren te worden gemonitord op afwijkend gedrag en er behoren passende maatregelen te worden genomen om potentiële informatiebeveiligingsincidenten te evalueren. -**Doel** +### Doel Afwijkend gedrag en potentiële informatiebeveiligingsincidenten detecteren. -**Richtlijn** +### Richtlijn De reikwijdte en het niveau van de monitoring behoren te worden bepaald overeenkomstig de bedrijfs- en informatiebeveiligingseisen en met inachtneming van de relevante wet- en regelgevingr behoren registraties van de monitoring te worden bijgehouden gedurende gedefinieerde bewaartermijnen. @@ -98,7 +108,7 @@ zijn om potentiële incidenten accuraat te interpreterenr behoren redundante sys Abnormale gebeurtenissen behoren aan relevante partijen te worden meegedeeld, zodat de volgende activiteiten kunnen worden verbeterd: auditen, evaluatie van de beveiliging, scannen op kwetsbaarheden en monitoren (zie 5.36). Er behoren procedures te zijn ingevoerd om tijdig te reageren op positieve indicatoren van het monitoringsysteem teneinde het effect van nadelige gebeurtenissen op informatiebeveiliging tot het minimum te beperken (zie 5.26). Er behoren ook procedures te worden vastgesteld om valspositieven te identificeren en aan te pakken, waaronder het afstemmen van de monitoringsoftware om het toekomstige aantal valspositieven te beperken. -**Overige informatie** +### Overige informatie Beveiligingsmonitoring kan worden verbeterd door: @@ -120,4 +130,3 @@ Monitoringactiviteiten worden vaak uitgevoerd met behulp van gespecialiseerde so Op afwijkende communicatie monitoren helpt bij het identificeren van botnets (dzen verzameling apparaten onder de kwaadwillige controle van de botneteigenaar, die meestal wordt gebruikt voor het uitvoeren van gedistribueerde denial-of-serviceaanvallen op andere computers van andere organisaties)ndien de computer door een extern apparaat wordt bestuurd, is er communicatie -tussen het besmette en het besturende apparaate organisatie behoort daarom technologieën in te zetten om afwijkende communicatie te monitoren en zo nodig maatregelen te nemen. diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-8.17-Kloksynchronisatie.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-8.17-Kloksynchronisatie.md index 825ed91..d8ce579 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-8.17-Kloksynchronisatie.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-8.17-Kloksynchronisatie.md @@ -1,29 +1,36 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "8.17" +title: "Kloksynchronisatie" +theme: Technological +control_type: [Detective] +information_security_properties: [Integrity] +cybersecurity_concepts: + - Protect + - Detect +operational_capabilities: [Information_security_event_management] +security_domains: + - Protection + - Defence +tags: +- iso27002/2022/NL +- sourcetext +status: active --- - -+------------------------+---------------------+----------------------+--------------------------------------------------------+---------------------+ -| **Type** | **Informatie-** | **Cybersecurity-** | **Operationele** | **Beveiligings-** | -| | | | | | -| **beheersmaatregel** | **beveiligings-** | **concepten** | **capaciteiten** | **domeinen** | -| | | | | | -| | **eigenschappen** | | | | -+========================+=====================+======================+========================================================+=====================+ -| #Detectief | #Integriteit | #Beschermen | #Beheer_van_infor- matiebeveiligings- gebeurtenissen | #Bescherming | -| | | | | | -| | | #Detecteren | | #Verdediging | -+------------------------+---------------------+----------------------+--------------------------------------------------------+---------------------+ - -**Beheersmaatregel** +## 8.17 Kloksynchronisatie +### Beheersmaatregel De klokken van informatieverwerkende systemen die door de organisatie worden gebruikt, behoren te worden gesynchroniseerd met goedgekeurde tijdsbronnen. -**Doel** +### Doel De correlatie en analyse van beveiligingsgerelateerde gebeurtenissen en andere geregistreerde gegevens mogelijk maken en onderzoeken bij informatiebeveiligingsincidenten ondersteunen. -**Richtlijn** +### Richtlijn Externe en interne eisen voor weergave, betrouwbare synchronisatie en nauwkeurigheid van tijd behoren te worden gedocumenteerd en geïmplementeerdulke eisen kunnen voortvloeien uit wet- @@ -35,6 +42,5 @@ De organisatie kan twee externe tijdsbronnen tegelijk gebruiken om de betrouwbaa Klokken kunnen lastig te synchroniseren zijn wanneer meerdere clouddiensten worden gebruikt of wanneer zowel cloud- als op locatie gehoste diensten worden gebruiktn dat geval behoort de klok van elke dienst te worden gecontroleerd en het verschil te worden geregistreerd om risico\'s als gevolg van verschillen te verkleinen. -**Overige informatie** +### Overige informatie -De correcte instelling van computerklokken is belangrijk om de nauwkeurigheid van logbestanden van gebeurtenissen te waarborgenit kan nodig zijn voor onderzoeken of als bewijs in juridische en disciplinaire zakennnauwkeurige auditlogbestanden kunnen dergelijke onderzoeken belemmeren en de geloofwaardigheid van het bewijs schaden. diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-8.18-Gebruik-van-speciale-systeemhulpmiddelen.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-8.18-Gebruik-van-speciale-systeemhulpmiddelen.md index 2666d96..84aeefe 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-8.18-Gebruik-van-speciale-systeemhulpmiddelen.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-8.18-Gebruik-van-speciale-systeemhulpmiddelen.md @@ -1,27 +1,38 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "8.18" +title: "Gebruik van speciale systeemhulpmiddelen" +theme: Technological +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: + - System_and_network_security + - Secure_configuration + - Application_security +security_domains: [Protection] +tags: +- iso27002/2022/NL +- sourcetext +status: active --- - -+------------------------+----------------------------------------------------+----------------------+---------------------------------------------------------------------------------------+---------------------+ -| **Type** | **Informatie-** | **Cybersecurity-** | **Operationele** | **Beveiligings-** | -| | | | | | -| **beheersmaatregel** | **beveiligings-** | **concepten** | **capaciteiten** | **domeinen** | -| | | | | | -| | **eigenschappen** | | | | -+========================+====================================================+======================+=======================================================================================+=====================+ -| #Preventief | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | #Beschermen | #Systeem- \_en_netwerkbeveili- ging #Veilige_configuratie #Toepassingsbeveili- ging | #Bescherming | -+------------------------+----------------------------------------------------+----------------------+---------------------------------------------------------------------------------------+---------------------+ - -**Beheersmaatregel** +## 8.18 Gebruik van speciale systeemhulpmiddelen +### Beheersmaatregel Het gebruik van systeemhulpmiddelen die in staat kunnen zijn om beheersmaatregelen voor systemen en toepassingen te omzeilen, behoort te worden beperkt en nauwkeurig te worden gecontroleerd. -**Doel** +### Doel Bewerkstelligen dat het gebruik van systeemhulpmiddelen geen schade toebrengt aan systeem- en toepassingsbeheersmaatregelen voor informatiebeveiliging. -**Richtlijn** +### Richtlijn Voor het gebruik van systeemhulpmiddelen die in staat kunnen zijn om beheersmaatregelen voor systemen en toepassingen te omzeilen, behoren de volgende richtlijnen te worden overwogen: @@ -45,6 +56,5 @@ geautoriseerde wijziging); i) registreren van alle gebruik van systeemhulpmiddelen. -**Overige informatie** +### Overige informatie -De meeste informatiesystemen hebben een of meer systeemhulpmiddelen die systeem- en toepassingsbeheersmaatregelen kunnen omzeilen, bijvoorbeeld diagnose-, patching-, antivirus-, schijfdefragmentatie-, probleemdetectie- en probleemoplossings-, back-up- en netwerkhulpmiddelen. diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-8.19-Installeren-van-software-op-operationele-systemen.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-8.19-Installeren-van-software-op-operationele-systemen.md index b67858e..d330c40 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-8.19-Installeren-van-software-op-operationele-systemen.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-8.19-Installeren-van-software-op-operationele-systemen.md @@ -1,27 +1,37 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "8.19" +title: "Installeren van software op operationele systemen" +theme: Technological +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: + - Secure_configuration + - Application_security +security_domains: [Protection] +tags: +- iso27002/2022/NL +- sourcetext +status: active --- - -+------------------------+----------------------------------------------------+----------------------+---------------------------------------------------+---------------------+ -| **Type** | **Informatie-** | **Cybersecurity-** | **Operationele** | **Beveiligings-** | -| | | | | | -| **beheersmaatregel** | **beveiligings-** | **concepten** | **capaciteiten** | **domeinen** | -| | | | | | -| | **eigenschappen** | | | | -+========================+====================================================+======================+===================================================+=====================+ -| #Preventief | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | #Beschermen | #Veilige_configuratie #Toepassingsbeveili- ging | #Bescherming | -+------------------------+----------------------------------------------------+----------------------+---------------------------------------------------+---------------------+ - -**Beheersmaatregel** +## 8.19 Installeren van software op operationele systemen +### Beheersmaatregel Er behoren procedures en maatregelen te worden geïmplementeerd om het installeren van software op operationele systemen op veilige wijze te beheren. -**Doel** +### Doel De integriteit van operationele systemen garanderen en voorkomen dat misbruik wordt gemaakt van technische kwetsbaarheden. -**Richtlijn** +### Richtlijn De volgende richtlijnen behoren in overweging te worden genomen om wijzigingen en de installatie van software op operationele systemen op beveiligde wijze te beheren: @@ -53,4 +63,3 @@ De organisatie behoort strikte regels te definiëren en ten uitvoer te brengen m Het beginsel van het 'least privilege' (minste voorrechten) behoort te worden toegepast op de installatie van software op operationele systemene organisatie behoort vast te leggen welke soorten software mogen worden geïnstalleerd (bijvpdates en beveiligingspatches voor bestaande software) en welke verboden zijn (bijvoftware uitsluitend voor persoonlijk gebruik en software waarvan de herkomst met betrekking tot de potentiële kwaadaardigheid onbekend of verdacht is)eze voorrechten behoren te worden verleend op basis van de rollen van de betrokken gebruikers. -**Overige informatie** Geen overige informatie. diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-8.2-Speciale-toegangsrechten.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-8.2-Speciale-toegangsrechten.md index 81fb2ab..0c05da7 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-8.2-Speciale-toegangsrechten.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-8.2-Speciale-toegangsrechten.md @@ -1,30 +1,38 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "8.2" +title: "Speciale toegangsrechten" +theme: Technological +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: [Identity_and_access_management] +security_domains: [Protection] +tags: +- iso27002/2022/NL +- sourcetext +status: active --- - -+------------------------+----------------------------------------------------+----------------------+-------------------------------------+---------------------+ -| **Type** | **Informatie-** | **Cybersecurity-** | **Operationele** | **Beveiligings-** | -| | | | | | -| **beheersmaatregel** | **beveiligings-** | **concepten** | **capaciteiten** | **domeinen** | -| | | | | | -| | **eigenschappen** | | | | -+========================+====================================================+======================+=====================================+=====================+ -| #Preventief | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | #Beschermen | #Identiteits- \_en_toegangsbeheer | #Bescherming | -+------------------------+----------------------------------------------------+----------------------+-------------------------------------+---------------------+ - -**Beheersmaatregel** +## 8.2 Speciale toegangsrechten +### Beheersmaatregel Het toewijzen en gebruik van speciale toegangsrechten behoren te worden beperkt en beheerd. -**Doel** +### Doel Bewerkstelligen dat alleen bevoegde gebruikers, softwarecomponenten en diensten speciale toegangsrechten krijgen. -**Richtlijn** +### Richtlijn Het toewijzen van speciale toegangsrechten behoort te worden beheerst door een autorisatieprocedure die in overeenstemming is met het relevante onderwerpspecifieke beleid inzake toegangsbeveiliging (zie 5.15)et volgende behoort te worden overwogen: @@ -57,10 +65,9 @@ k) identiteiten met speciale toegangsrechten niet met meerdere personen delen of l) het gebruik van identiteiten met speciale toegangsrechten beperken tot het uitvoeren van beheerfuncties en deze identiteiten niet gebruiken voor de dagelijkse algemene taken [dz-mail bekijken, toegang tot internet (gebruikers behoren voor deze activiteiten een afzonderlijke normale netwerkidentiteit te hebben)]. -**Overige informatie** +### Overige informatie Speciale toegangsrechten zijn toegangsrechten die aan een identiteit, rol of proces worden verleend om activiteiten te kunnen uitvoeren die gewone gebruikers of processen niet kunnen uitvoerenysteembeheerdersrollen vereisen meestal speciale toegangsrechten. Ongepast gebruik van speciale systeembeheerdersrechten (elke functie of faciliteit van een informatiesysteem die de gebruiker in staat stelt systeem- of toepassingsbeheersmaatregelen op te heffen) is een factor die in grote mate bijdraagt aan storingen van of inbreuken op het systeem. -Meer informatie over toegangsbeheer en het beveiligde beheer van de toegang tot informatie en informatie- en communicatietechnologiemiddelen is te vinden in ISO/IEC 29146. diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-8.20-Beveiliging-netwerkcomponenten.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-8.20-Beveiliging-netwerkcomponenten.md index 574e7a9..0d92f4a 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-8.20-Beveiliging-netwerkcomponenten.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-8.20-Beveiliging-netwerkcomponenten.md @@ -1,32 +1,42 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "8.20" +title: "Beveiliging netwerkcomponenten" +theme: Technological +control_type: + - Preventive + - Detective +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: + - Protect + - Detect +operational_capabilities: [System_and_network_security] +security_domains: [Protection] +tags: +- iso27002/2022/NL +- sourcetext +status: active --- - -+------------------------+----------------------------------------------------+----------------------+---------------------------------------+---------------------+ -| **Type** | **Informatie-** | **Cybersecurity-** | **Operationele** | **Beveiligings-** | -| | | | | | -| **beheersmaatregel** | **beveiligings-** | **concepten** | **capaciteiten** | **domeinen** | -| | | | | | -| | **eigenschappen** | | | | -+========================+====================================================+======================+=======================================+=====================+ -| #Preventief | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | #Beschermen | #Systeem- \_en_netwerkbeveili- ging | #Bescherming | -| | | | | | -| #Detectief | | #Detecteren | | | -+------------------------+----------------------------------------------------+----------------------+---------------------------------------+---------------------+ - -**Beheersmaatregel** +## 8.20 Beveiliging netwerkcomponenten +### Beheersmaatregel Netwerken en netwerkapparaten behoren te worden beveiligd, beheerd en beheerst om informatie in systemen en toepassingen te beschermen. -**Doel** +### Doel Informatie in netwerken en de ondersteunende informatieverwerkingsfaciliteiten beschermen tegen compromittering via het netwerk. -**Richtlijn** +### Richtlijn Er behoren beheersmaatregelen te worden geïmplementeerd om de veiligheid van informatie in netwerken te waarborgen en aangesloten diensten tegen onbevoegde toegang te beschermenn het bijzonder behoort met de volgende aspecten rekening te worden gehouden: @@ -77,6 +87,5 @@ gevirtualiseerde netwerken wenselijk zijn, omdat ze een logische segmentatie mog -**Overige informatie** +### Overige informatie -Aanvullende informatie over netwerkbeveiliging is te vinden in de ISO/IEC 27033-reekseer informatie over gevirtualiseerde netwerken is te vinden in ISO/IEC TS 23167. diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-8.21-Beveiliging-van-netwerkdiensten.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-8.21-Beveiliging-van-netwerkdiensten.md index d397616..bd4fa95 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-8.21-Beveiliging-van-netwerkdiensten.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-8.21-Beveiliging-van-netwerkdiensten.md @@ -1,27 +1,35 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "8.21" +title: "Beveiliging van netwerkdiensten" +theme: Technological +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: [System_and_network_security] +security_domains: [Protection] +tags: +- iso27002/2022/NL +- sourcetext +status: active --- - -+------------------------+----------------------------------------------------+----------------------+--------------------------------------+---------------------+ -| **Type** | **Informatie-** | **Cybersecurity-** | **Operationele** | **Beveiligings-** | -| | | | | | -| **beheersmaatregel** | **beveiligings-** | **concepten** | **capaciteiten** | **domeinen** | -| | | | | | -| | **eigenschappen** | | | | -+========================+====================================================+======================+======================================+=====================+ -| #Preventief | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | #Beschermen | #Systeem-\_en_net- werkbeveiliging | #Bescherming | -+------------------------+----------------------------------------------------+----------------------+--------------------------------------+---------------------+ - -**Beheersmaatregel** +## 8.21 Beveiliging van netwerkdiensten +### Beheersmaatregel Beveiligingsmechanismen, dienstverleningsniveaus en dienstverleningseisen voor alle netwerkdiensten behoren te worden geïdentificeerd, geïmplementeerd en gemonitord. -**Doel** +### Doel De beveiliging bij het gebruik van netwerkdiensten waarborgen. -**Richtlijn** +### Richtlijn De beveiligingsmaatregelen die nodig zijn voor bepaalde diensten, zoals beveiligingskenmerken, dienstverleningsniveaus en -eisen, behoren te worden vastgesteld en geïmplementeerd (door interne of externe aanbieders van netwerkdiensten)e organisatie behoort ervoor te zorgen dat aanbieders van netwerkdiensten deze maatregelen implementeren. @@ -68,8 +76,7 @@ d) procedures voor het gebruik van netwerkdiensten ter beperking van toegang tot of, voor zover noodzakelijk, -toepassingen. -**Overige informatie** +### Overige informatie Tot netwerkdiensten behoren het leveren van aansluitingen, particuliere netwerkdiensten en beheerde netwerkbeveiligingsoplossingen zoals firewalls en inbraakdetectiesystemeneze diensten kunnen variëren van eenvoudige onbeheerde bandbreedte tot en met complexe aanbiedingen met toegevoegde waarde. -Verdere richtlijnen over een kader voor toegangsbeheer worden gegeven in ISO/IEC 29146. diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-8.22-Netwerksegmentatie.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-8.22-Netwerksegmentatie.md index f5750fd..a111dd1 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-8.22-Netwerksegmentatie.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-8.22-Netwerksegmentatie.md @@ -1,27 +1,35 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "8.22" +title: "Netwerksegmentatie" +theme: Technological +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: [System_and_network_security] +security_domains: [Protection] +tags: +- iso27002/2022/NL +- sourcetext +status: active --- - -+------------------------+----------------------------------------------------+----------------------+--------------------------------------+---------------------+ -| **Type** | **Informatie-** | **Cybersecurity-** | **Operationele** | **Beveiligings-** | -| | | | | | -| **beheersmaatregel** | **beveiligings-** | **concepten** | **capaciteiten** | **domeinen** | -| | | | | | -| | **eigenschappen** | | | | -+========================+====================================================+======================+======================================+=====================+ -| #Preventief | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | #Beschermen | #Systeem-\_en_net- werkbeveiliging | #Bescherming | -+------------------------+----------------------------------------------------+----------------------+--------------------------------------+---------------------+ - -**Beheersmaatregel** +## 8.22 Netwerksegmentatie +### Beheersmaatregel Groepen informatiediensten, gebruikers en informatiesystemen behoren in de netwerken van de organisatie te worden gesegmenteerd. -**Doel** +### Doel Het netwerk opsplitsen met beveiligingsgrenzen en het verkeer ertussen op basis van de bedrijfsbehoeften beheersen. -**Richtlijn** +### Richtlijn De organisatie behoort te overwegen de beveiliging van grote netwerken te beheren door ze te verdelen in gesegmenteerde netwerkdomeinen en ze van het openbare netwerk (dznternet) te segmenterene domeinen kunnen worden gekozen op basis van betrouwbaarheids-, kritikaliteits- en gevoeligheidsniveaus (bijvpenbaar toegankelijk domein, bureaubladdomein, serverdomein, systemen met laag of hoog risico), op basis van organisatieafdelingen (bijversoneelszaken, financiën, marketing) of een combinatie ervan (bijververdomein verbonden met meerdere afdelingen van de organisatie)e segmentering kan tot stand worden gebracht door hetzij fysiek verschillende netwerken, hetzij verschillende logische netwerken te gebruiken. @@ -32,6 +40,5 @@ De buitengrenzen van elk domein behoren goed te worden gedefinieerdndien toegang Draadloze netwerken vereisen een speciale behandeling in verband met de slecht gedefinieerde buitengrenzen van het netwerkanpassing van de radiodekking behoort te worden overwogen om draadloze netwerken te segmenterenoor gevoelige omgevingen behoort te worden overwogen om elke draadloze toegang te behandelen als externe verbinding en om deze toegang te segmenteren van interne netwerken totdat de toegang een gateway is gepasseerd, in overeenstemming met de netwerkbeheersmaatregelen (zie 8.20), alvorens toegang tot interne systemen wordt verleendraadloze toegangsnetwerken voor gasten behoren te worden gescheiden van die voor personeel, indien personeel alleen beheerste 'endpoint devices' gebruikt die voldoen aan de onderwerpspecifieke beleidsregels van de organisatieoor wifi voor gasten behoren ten minste dezelfde beperkingen te gelden als voor wifi voor personeel; zo wordt het gebruik van wifi voor gasten door het personeel ontmoedigd. -**Overige informatie** +### Overige informatie -Netwerken strekken zich vaak uit tot buiten de muren van de organisatie omdat bedrijfsmatige partnerschappen worden gevormd waarvoor onderlinge verbinding of het delen van informatieverwerkende en netwerkfaciliteiten vereist isoor dergelijke uitbreidingen kan het risico op onbevoegde toegang tot de informatiesystemen van de organisatie die gebruikmaken van het netwerk toenemen, waarbij sommige gevoelige en essentiële informatiesystemen bescherming tegen andere netwerkgebruikers nodig hebben. diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-8.23-Toepassen-van-webfilters.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-8.23-Toepassen-van-webfilters.md index 08ab74b..40ad08f 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-8.23-Toepassen-van-webfilters.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-8.23-Toepassen-van-webfilters.md @@ -1,27 +1,35 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "8.23" +title: "Toepassen van webfilters" +theme: Technological +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: [System_and_network_security] +security_domains: [Protection] +tags: +- iso27002/2022/NL +- sourcetext +status: active --- - -+------------------------+----------------------------------------------------+----------------------+--------------------------------------+---------------------+ -| **Type** | **Informatie-** | **Cybersecurity-** | **Operationele** | **Beveiligings-** | -| | | | | | -| **beheersmaatregel** | **beveiligings-** | **concepten** | **capaciteiten** | **domeinen** | -| | | | | | -| | **eigenschappen** | | | | -+========================+====================================================+======================+======================================+=====================+ -| #Preventief | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | #Beschermen | #Systeem-\_en_net- werkbeveiliging | #Bescherming | -+------------------------+----------------------------------------------------+----------------------+--------------------------------------+---------------------+ - -**Beheersmaatregel** +## 8.23 Toepassen van webfilters +### Beheersmaatregel De toegang tot externe websites behoort te worden beheerd om de blootstelling aan kwaadaardige inhoud te beperken. -**Doel** +### Doel Systemen beschermen om te voorkomen dat ze door malware worden gecompromitteerd en om toegang tot ongeoorloofde internetbronnen te voorkomen. -**Richtlijn** +### Richtlijn De organisatie behoort de risico\'s te beperken dat haar personeel toegang krijgt tot websites die illegale informatie bevatten of waarvan bekend is dat ze virussen of phishingmateriaal bevattenen techniek om dit te bereiken is het IP-adres of het domein van de desbetreffende website(s) te @@ -50,6 +58,5 @@ Alvorens deze beheersmaatregel in te zetten, behoort de organisatie regels op te Het personeel behoort training te krijgen over het beveiligde en passende gebruik van online middelen, met inbegrip van toegang tot internete training behoort onder andere in te gaan op de regels van de organisatie, het contactpunt voor het melden van veiligheidskwesties en de uitzonderingsprocedure wanneer toegang tot online middelen waarvoor beperkingen gelden om legitieme zakelijke redenen nodig isr behoort ook training aan het personeel te worden gegeven om te garanderen dat ze browsermeldingen die aangeven dat een website niet veilig is, maar waarbij de gebruiker wel kan doorgaan, niet in de wind slaan. -**Overige informatie** +### Overige informatie -Allerlei technieken kunnen worden gebruikt om webfilters toe te passen, zoals onder andere handtekeningen, heuristiek, een lijst van aanvaardbare websites of domeinen, een lijst van verboden websites of domeinen en configuratie op maat om te helpen voorkomen dat kwaadaardige software en andere kwaadaardige activiteiten het netwerk en de systemen van de organisatie aanvallen. diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-8.24-Gebruik-van-cryptografie.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-8.24-Gebruik-van-cryptografie.md index e0b4b0e..970e85e 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-8.24-Gebruik-van-cryptografie.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-8.24-Gebruik-van-cryptografie.md @@ -1,30 +1,38 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "8.24" +title: "Gebruik van cryptografie" +theme: Technological +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: [Secure_configuration] +security_domains: [Protection] +tags: +- iso27002/2022/NL +- sourcetext +status: active --- - -+------------------------+----------------------------------------------------+----------------------+-------------------------+---------------------+ -| **Type** | **Informatie-** | **Cybersecurity-** | **Operationele** | **Beveiligings-** | -| | | | | | -| **beheersmaatregel** | **beveiligings-** | **concepten** | **capaciteiten** | **domeinen** | -| | | | | | -| | **eigenschappen** | | | | -+========================+====================================================+======================+=========================+=====================+ -| #Preventief | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | #Beschermen | #Veilige_configuratie | #Bescherming | -+------------------------+----------------------------------------------------+----------------------+-------------------------+---------------------+ - -**Beheersmaatregel** +## 8.24 Gebruik van cryptografie +### Beheersmaatregel Regels voor het doeltreffende gebruik van cryptografie, met inbegrip van het beheer van cryptografische sleutels, behoren te worden gedefinieerd en geïmplementeerd. -**Doel** +### Doel Correct en doeltreffend gebruik bewerkstelligen van cryptografie om de vertrouwelijkheid, authenticiteit of integriteit van informatie overeenkomstig de bedrijfs- en informatiebeveiligingseisen te beschermen en met inachtneming van de eisen van wet- en regelgeving, statutaire en contractuele eisen met betrekking tot cryptografie. -**Richtlijn** +### Richtlijn <u>Algemeen</u> @@ -103,7 +111,7 @@ Alle cryptografische sleutels behoren te worden beschermd tegen aanpassing en ve Naast integriteit behoort voor veel usecases aandacht te worden besteed aan de authenticiteit van openbare sleutels. -**Overige informatie** +### Overige informatie Voor de authenticiteit van openbare sleutels worden er meestal processen voor het beheer van openbare sleutels toegepast die gebruikmaken van certificaatinstanties en openbare- sleutelcertificaten, maar het is ook mogelijk om hiervoor gebruik te maken van technologieën zoals het toepassen van handmatige processen voor een klein aantal sleutels. @@ -126,4 +134,3 @@ d) authenticatie: cryptografische technieken gebruiken ter authenticatie van geb systeementiteiten die toegang vragen tot of die verrichtingen doen met systeemgebruikers, -entiteiten en -bronnen. -De ISO/IEC 11770-reeks geeft verdere informatie over sleutelbeheer. diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-8.25-Beveiligen-tijdens-de-ontwikkelcyclus.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-8.25-Beveiligen-tijdens-de-ontwikkelcyclus.md index 995c59e..ef6aadc 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-8.25-Beveiligen-tijdens-de-ontwikkelcyclus.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-8.25-Beveiligen-tijdens-de-ontwikkelcyclus.md @@ -1,27 +1,37 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "8.25" +title: "Beveiligen tijdens de ontwikkelcyclus" +theme: Technological +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: + - Application_security + - System_and_network_security +security_domains: [Protection] +tags: +- iso27002/2022/NL +- sourcetext +status: active --- - -+------------------------+----------------------------------------------------+----------------------+----------------------------------------------------------------+---------------------+ -| **Type** | **Informatie-** | **Cybersecurity-** | **Operationele** | **Beveiligings-** | -| | | | | | -| **beheersmaatregel** | **beveiligings-** | **concepten** | **capaciteiten** | **domeinen** | -| | | | | | -| | **eigenschappen** | | | | -+========================+====================================================+======================+================================================================+=====================+ -| #Preventief | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | #Beschermen | #Toepassingsbeveili- ging #Systeem-\_en_net- werkbeveiliging | #Bescherming | -+------------------------+----------------------------------------------------+----------------------+----------------------------------------------------------------+---------------------+ - -**Beheersmaatregel** +## 8.25 Beveiligen tijdens de ontwikkelcyclus +### Beheersmaatregel Voor het veilig ontwikkelen van software en systemen behoren regels te worden vastgesteld en toegepast. -**Doel** +### Doel Bewerkstelligen dat informatiebeveiliging binnen de veilige ontwikkelcyclus van software en systemen wordt ontworpen en geïmplementeerd. -**Richtlijn** +### Richtlijn Beveiligd ontwikkelen is een eis voor het opbouwen van een beveiligde dienstverlening, architectuur, software en een beveiligd systeemm dit te bereiken behoort met de volgende aspecten rekening te worden gehouden: @@ -60,6 +70,5 @@ toekomstige licentieproblemen te voorkomen (zie 5.32). Indien ontwikkelactiviteiten worden uitbesteed, behoort de organisatie zich ervan te vergewissen dat de leverancier voldoet aan de regels van de organisatie voor veilig ontwikkelen (zie 8.30). -**Overige informatie** +### Overige informatie -Ook binnen toepassingen kan ontwikkeling plaatsvinden, zoals binnen kantoortoepassingen, scripting, browsers en databases. diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-8.26-Toepassingsbeveiligingseisen.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-8.26-Toepassingsbeveiligingseisen.md index 077712b..b5ad9cb 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-8.26-Toepassingsbeveiligingseisen.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-8.26-Toepassingsbeveiligingseisen.md @@ -1,29 +1,39 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "8.26" +title: "Toepassingsbeveiligingseisen" +theme: Technological +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: + - Application_security + - System_and_network_security +security_domains: + - Protection + - Defence +tags: +- iso27002/2022/NL +- sourcetext +status: active --- - -+------------------------+----------------------------------------------------+----------------------+----------------------------------------------------------------+---------------------+ -| **Type** | **Informatie-** | **Cybersecurity-** | **Operationele** | **Beveiligings-** | -| | | | | | -| **beheersmaatregel** | **beveiligings-** | **concepten** | **capaciteiten** | **domeinen** | -| | | | | | -| | **eigenschappen** | | | | -+========================+====================================================+======================+================================================================+=====================+ -| #Preventief | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | #Beschermen | #Toepassingsbeveili- ging #Systeem-\_en_net- werkbeveiliging | #Bescherming | -| | | | | | -| | | | | #Verdediging | -+------------------------+----------------------------------------------------+----------------------+----------------------------------------------------------------+---------------------+ - -**Beheersmaatregel** +## 8.26 Toepassingsbeveiligingseisen +### Beheersmaatregel Er behoren eisen aan de informatiebeveiliging te worden geïdentificeerd, gespecificeerd en goedgekeurd bij het ontwikkelen of aanschaffen van toepassingen. -**Doel** +### Doel Garanderen dat alle informatiebeveiligingseisen zijn geïdentificeerd en meegenomen bij het ontwikkelen of aanschaffen van toepassingen. -**Richtlijn** +### Richtlijn <u>Algemeen</u> @@ -127,7 +137,7 @@ e) als een vertrouwde instantie wordt gebruikt (bijvoor het uitgeven en onderhou Een aantal van de bovengenoemde aspecten kan worden opgepakt door toepassing van cryptografie (zie 8.24), waarbij wettelijke eisen in aanmerking worden genomen (zie 5.31 t/m 5.36, zie in het bijzonder 5.31 voor wetgeving betreffende cryptografie). -**Overige informatie** +### Overige informatie Toepassingen die toegankelijk zijn via netwerken, staan bloot aan een reeks netwerkgerelateerde dreigingen zoals frauduleuze activiteiten, geschillen over contracten of openbaarmaking van informatie; onvolledige verzending, foutieve routering, ongeautoriseerd(e) wijziging, vermenigvuldiging of afspelen van berichtenaarom zijn gedetailleerde risicobeoordelingen en zorgvuldige vaststelling van beheersmaatregelen onmisbaarereiste beheersmaatregelen behelzen vaak cryptografische methoden voor het authenticeren en beveiligen van gegevensoverdracht. @@ -148,15 +158,15 @@ Verdere informatie over de beveiliging van toepassingen is te vinden in de ISO/I | #Preventief | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | #Beschermen | #Toepassingsbeveili- ging #Systeem-\_en_net- werkbeveiliging | #Bescherming | +------------------------+----------------------------------------------------+----------------------+----------------------------------------------------------------+---------------------+ -**Beheersmaatregel** +### Beheersmaatregel Uitgangspunten voor het ontwerpen van beveiligde systemen behoren te worden vastgesteld, gedocumenteerd, onderhouden en toegepast voor alle activiteiten betreffende het ontwikkelen van informatiesystemen. -**Doel** +### Doel Waarborgen dat informatiesystemen veilig worden ontworpen, geïmplementeerd en beheerd binnen de ontwikkelingslevenscyclus. -**Richtlijn** +### Richtlijn Er behoren uitgangspunten voor het ontwerpen van beveiligde systemen te worden vastgesteld, gedocumenteerd en toegepast voor ontwerpactiviteiten voor informatiesystemen. Bij alle architectuurlagen (bedrijf, gegevens, toepassingen en technologie) behoort beveiliging deel uit te maken van het ontwerp. Nieuwe technologie behoort te worden geanalyseerd op veiligheidsrisico's en het ontwerp behoort te worden beoordeeld aan de hand van bekende aanvalspatronen. @@ -214,7 +224,7 @@ De vastgestelde uitgangspunten voor het ontwerpen van beveiligde systemen en sys De uitgangspunten voor het ontwerpen van beveiligde systemen en de vastgestelde ontwerpprocedures behoren regelmatig te worden beoordeeld om te waarborgen dat ze doelmatig bijdragen aan verbeterde normen voor beveiliging binnen het ontwerpprocese behoren ook regelmatig te worden beoordeeld om ervoor te zorgen dat ze actueel blijven in de zin dat ze nieuwe potentiële dreigingen afwenden en toepasbaar blijven bij verbeteringen die worden toegepast in de technologieën en oplossingen. -**Overige informatie** +### Overige informatie Uitgangspunten voor het ontwerpen van beveiligde systemen kunnen worden toegepast op het ontwerp of de configuratie van allerlei technieken, zoals: @@ -224,4 +234,3 @@ Uitgangspunten voor het ontwerpen van beveiligde systemen kunnen worden toegepas Er kunnen technieken voor beveiligde virtualisatie worden gebruikt om interferentie te voorkomen tussen toepassingen die op hetzelfde fysieke apparaat draaienls een virtuele instantie van een toepassing door een aanvaller wordt gecompromitteerd, wordt alleen die instantie getroffene aanval heeft geen effect op andere toepassingen of gegevens. -Technieken voor weerstand tegen manipulatie kunnen worden gebruikt om manipulatie van informatiecontainers te detecteren, hetzij fysiek (bijven inbraakalarm), hetzij logisch (bijven gegevensbestand)en kenmerk van dergelijke technieken is dat de poging om de container te manipuleren, wordt geregistreerdovendien kan de beheersmaatregel voorkomen dat gegevens met succes worden geëxtraheerd door ze te vernietigen (het geheugen van het apparaat kan bijvoorbeeld worden gewist). diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-8.27-Veilige-systeemarchitectuur-en-technische-uitgangspunten.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-8.27-Veilige-systeemarchitectuur-en-technische-uitgangspunten.md index 296baab..a222685 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-8.27-Veilige-systeemarchitectuur-en-technische-uitgangspunten.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-8.27-Veilige-systeemarchitectuur-en-technische-uitgangspunten.md @@ -1,27 +1,37 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "8.27" +title: "Veilige systeemarchitectuur en technische uitgangspunten" +theme: Technological +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: + - Application_security + - System_and_network_security +security_domains: [Protection] +tags: +- iso27002/2022/NL +- sourcetext +status: active --- - -+------------------------+----------------------------------------------------+----------------------+----------------------------------------------------------------+---------------------+ -| **Type** | **Informatie-** | **Cybersecurity-** | **Operationele** | **Beveiligings-** | -| | | | | | -| **beheersmaatregel** | **beveiligings-** | **concepten** | **capaciteiten** | **domeinen** | -| | | | | | -| | **eigenschappen** | | | | -+========================+====================================================+======================+================================================================+=====================+ -| #Preventief | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | #Beschermen | #Toepassingsbeveili- ging #Systeem-\_en_net- werkbeveiliging | #Bescherming | -+------------------------+----------------------------------------------------+----------------------+----------------------------------------------------------------+---------------------+ - -**Beheersmaatregel** +## 8.27 Veilige systeemarchitectuur en technische uitgangspunten +### Beheersmaatregel Uitgangspunten voor het ontwerpen van beveiligde systemen behoren te worden vastgesteld, gedocumenteerd, onderhouden en toegepast voor alle activiteiten betreffende het ontwikkelen van informatiesystemen. -**Doel** +### Doel Waarborgen dat informatiesystemen veilig worden ontworpen, geïmplementeerd en beheerd binnen de ontwikkelingslevenscyclus. -**Richtlijn** +### Richtlijn Er behoren uitgangspunten voor het ontwerpen van beveiligde systemen te worden vastgesteld, gedocumenteerd en toegepast voor ontwerpactiviteiten voor informatiesystemen. Bij alle architectuurlagen (bedrijf, gegevens, toepassingen en technologie) behoort beveiliging deel uit te maken van het ontwerp. Nieuwe technologie behoort te worden geanalyseerd op veiligheidsrisico's en het ontwerp behoort te worden beoordeeld aan de hand van bekende aanvalspatronen. @@ -79,7 +89,7 @@ De vastgestelde uitgangspunten voor het ontwerpen van beveiligde systemen en sys De uitgangspunten voor het ontwerpen van beveiligde systemen en de vastgestelde ontwerpprocedures behoren regelmatig te worden beoordeeld om te waarborgen dat ze doelmatig bijdragen aan verbeterde normen voor beveiliging binnen het ontwerpprocese behoren ook regelmatig te worden beoordeeld om ervoor te zorgen dat ze actueel blijven in de zin dat ze nieuwe potentiële dreigingen afwenden en toepasbaar blijven bij verbeteringen die worden toegepast in de technologieën en oplossingen. -**Overige informatie** +### Overige informatie Uitgangspunten voor het ontwerpen van beveiligde systemen kunnen worden toegepast op het ontwerp of de configuratie van allerlei technieken, zoals: @@ -89,4 +99,3 @@ Uitgangspunten voor het ontwerpen van beveiligde systemen kunnen worden toegepas Er kunnen technieken voor beveiligde virtualisatie worden gebruikt om interferentie te voorkomen tussen toepassingen die op hetzelfde fysieke apparaat draaienls een virtuele instantie van een toepassing door een aanvaller wordt gecompromitteerd, wordt alleen die instantie getroffene aanval heeft geen effect op andere toepassingen of gegevens. -Technieken voor weerstand tegen manipulatie kunnen worden gebruikt om manipulatie van informatiecontainers te detecteren, hetzij fysiek (bijven inbraakalarm), hetzij logisch (bijven gegevensbestand)en kenmerk van dergelijke technieken is dat de poging om de container te manipuleren, wordt geregistreerdovendien kan de beheersmaatregel voorkomen dat gegevens met succes worden geëxtraheerd door ze te vernietigen (het geheugen van het apparaat kan bijvoorbeeld worden gewist). diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-8.28-Veilig-coderen.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-8.28-Veilig-coderen.md index fc04adb..390d8b9 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-8.28-Veilig-coderen.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-8.28-Veilig-coderen.md @@ -1,27 +1,37 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "8.28" +title: "Veilig coderen" +theme: Technological +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: + - Application_security + - System_and_network_security +security_domains: [Protection] +tags: +- iso27002/2022/NL +- sourcetext +status: active --- - -+------------------------+----------------------------------------------------+----------------------+----------------------------------------------------------------+---------------------+ -| **Type** | **Informatie-** | **Cybersecurity-** | **Operationele** | **Beveiligings-** | -| | | | | | -| **beheersmaatregel** | **beveiligings-** | **concepten** | **capaciteiten** | **domeinen** | -| | | | | | -| | **eigenschappen** | | | | -+========================+====================================================+======================+================================================================+=====================+ -| #Preventief | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | #Beschermen | #Toepassingsbeveili- ging #Systeem-\_en_net- werkbeveiliging | #Bescherming | -+------------------------+----------------------------------------------------+----------------------+----------------------------------------------------------------+---------------------+ - -**Beheersmaatregel** +## 8.28 Veilig coderen +### Beheersmaatregel Er behoren principes voor veilig coderen te worden toegepast op softwareontwikkeling. -**Doel** +### Doel Waarborgen dat veilige software wordt geschreven waardoor het aantal potentiële informatiebeveiligingskwetsbaarheden in de software wordt beperkt. -**Richtlijn** +### Richtlijn <u>Algemeen</u> @@ -109,7 +119,7 @@ d) de impact als de organisatie verantwoordelijk wordt gehouden voor het toekoms e) compatibiliteit met andere software die in gebruik is. -**Overige informatie** +### Overige informatie Een leidend principe is bewerkstelligen dat beveiligingsrelevante code wordt aangeroepen wanneer dat nodig is en deze bestand is tegen manipulatierogramma\'s die worden geïnstalleerd op basis van gecompileerde binaire code hebben deze eigenschappen ook, maar alleen voor gegevens die binnen de toepassing worden bewaardoor geïnterpreteerde talen werkt het concept alleen wanneer de code wordt uitgevoerd op een server waartoe de gebruikers en de processen die er gebruik van maken verder geen toegang hebben en de gegevens ervan in een op vergelijkbare wijze beschermde database worden bewaarde geïnterpreteerde code kan bijvoorbeeld worden uitgevoerd op een clouddienst waar beheerdersrechten vereist zijn voor toegang tot de code op zichergelijke toegang door een beheerder behoort te worden beschermd door beveiligingsmechanismen zoals just-in- timebeheerprincipes en krachtige authenticatiendien de eigenaar van een toepassing op afstand via de server toegang kan maken tot scripts, kan een aanvaller dat in principe ookebservers behoren dusdanig te worden geconfigureerd dat het doorzoeken van directory\'s in dergelijke gevallen niet mogelijk is. @@ -117,4 +127,3 @@ Het is het beste om er bij het ontwerpen van een toepassingscode vanuit te gaan Bepaalde internettoepassingen zijn gevoelig voor allerlei kwetsbaarheden die worden veroorzaakt door slecht ontwerp en slecht coderen, zoals injectieaanvallen op databases en 'cross-site scripting'- aanvallenij deze aanvallen kunnen verzoeken worden gemanipuleerd om misbruik te maken van de webserverfunctionaliteit. -Meer informatie over het evalueren van ICT-beveiliging is te vinden in de ISO/IEC 15408-reeks. diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-8.29-Testen-van-de-beveiliging-tijdens-ontwikkeling-en-acceptatie.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-8.29-Testen-van-de-beveiliging-tijdens-ontwikkeling-en-acceptatie.md index 628979f..7c40b35 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-8.29-Testen-van-de-beveiliging-tijdens-ontwikkeling-en-acceptatie.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-8.29-Testen-van-de-beveiliging-tijdens-ontwikkeling-en-acceptatie.md @@ -1,27 +1,38 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "8.29" +title: "Testen van de beveiliging tijdens ontwikkeling en acceptatie" +theme: Technological +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Identify] +operational_capabilities: + - Application_security + - Information_security_assurance + - System_and_network_security +security_domains: [Protection] +tags: +- iso27002/2022/NL +- sourcetext +status: active --- - -+------------------------+----------------------------------------------------+----------------------+-----------------------------------------------------------------------------------------------------+---------------------+ -| **Type** | **Informatie-** | **Cybersecurity-** | **Operationele** | **Beveiligings-** | -| | | | | | -| **beheersmaatregel** | **beveiligings-** | **concepten** | **capaciteiten** | **domeinen** | -| | | | | | -| | **eigenschappen** | | | | -+========================+====================================================+======================+=====================================================================================================+=====================+ -| #Preventief | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | #Identificeren | #Toepassingsbeveili- ging #Borging_van_infor- matiebeveiliging #Systeem-\_en_net- werkbeveiliging | #Bescherming | -+------------------------+----------------------------------------------------+----------------------+-----------------------------------------------------------------------------------------------------+---------------------+ - -**Beheersmaatregel** +## 8.29 Testen van de beveiliging tijdens ontwikkeling en acceptatie +### Beheersmaatregel Processen voor het testen van de beveiliging behoren te worden gedefinieerd en geïmplementeerd in de ontwikkelcyclus. -**Doel** +### Doel Valideren of aan de informatiebeveiligingseisen wordt voldaan wanneer toepassingen of code in de productieomgeving worden uitgerold. -**Richtlijn** +### Richtlijn Nieuwe informatiesystemen, upgrades en nieuwe versies behoren tijdens de ontwikkelingsprocessen grondig te worden getest en geverifieerdet testen van de beveiliging behoort een integraal onderdeel te zijn van het testen voor systemen of componenten. @@ -57,8 +68,7 @@ Voor uitbestede ontwikkeling en het inkopen van componenten behoort een verwervi Tests behoren te worden uitgevoerd in een testomgeving die zo nauwkeurig mogelijk overeenkomt met de doelproductieomgeving om te bewerkstelligen dat het systeem geen kwetsbaarheden introduceert in de omgeving van de organisatie en dat de tests betrouwbaar zijn (zie 8.31). -**Overige informatie** +### Overige informatie Er kunnen meer testomgevingen worden opgezet die gebruikt kunnen worden voor verschillende soorten tests (bijvunctionele en prestatietests)eze verschillende omgevingen kunnen virtueel zijn, met individuele configuraties om allerlei verschillende bedrijfsomgevingen te simuleren. -Het testen en monitoren van testomgevingen, -instrumenten en -technologieën behoort ook te worden overwogen om doeltreffend testen te bewerkstelligenezelfde overwegingen gelden voor het monitoren van de monitoringsystemen die worden ingezet in ontwikkel-, test- en productieomgevingenan de hand van de gevoeligheid van de systemen en gegevens behoort te worden beoordeeld hoeveel lagen metatests zinvol zijn. diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-8.3-Beperking-toegang-tot-informatie.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-8.3-Beperking-toegang-tot-informatie.md index e20bb4c..3050e2c 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-8.3-Beperking-toegang-tot-informatie.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-8.3-Beperking-toegang-tot-informatie.md @@ -1,27 +1,35 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "8.3" +title: "Beperking toegang tot informatie" +theme: Technological +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: [Identity_and_access_management] +security_domains: [Protection] +tags: +- iso27002/2022/NL +- sourcetext +status: active --- - -+------------------------+----------------------------------------------------+----------------------+-------------------------------------+---------------------+ -| **Type** | **Informatie-** | **Cybersecurity-** | **Operationele** | **Beveiligings-** | -| | | | | | -| **beheersmaatregel** | **beveiligings-** | **concepten** | **capaciteiten** | **domeinen** | -| | | | | | -| | **eigenschappen** | | | | -+========================+====================================================+======================+=====================================+=====================+ -| #Preventief | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | #Beschermen | #Identiteits- \_en_toegangsbeheer | #Bescherming | -+------------------------+----------------------------------------------------+----------------------+-------------------------------------+---------------------+ - -**Beheersmaatregel** +## 8.3 Beperking toegang tot informatie +### Beheersmaatregel De toegang tot informatie en andere gerelateerde bedrijfsmiddelen behoort te worden beperkt overeenkomstig het vastgestelde onderwerpspecifieke beleid inzake toegangsbeveiliging. -**Doel** +### Doel Uitsluitend bevoegde toegang bewerkstelligen en onbevoegde toegang tot informatie en andere gerelateerde bedrijfsmiddelen voorkomen. -**Richtlijn** +### Richtlijn De toegang tot informatie en andere gerelateerde bedrijfsmiddelen behoort te worden beperkt overeenkomstig de vastgestelde onderwerpspecifieke beleidsregelse volgende aspecten behoren in aanmerking te worden genomen om de eisen voor toegangsbeperking te ondersteunen: @@ -101,7 +109,7 @@ waargenomen. -**Overige informatie** +### Overige informatie Indien traditionele toegangscontroles niet kunnen worden afgedwongen, kunnen technieken voor het beheer van dynamische toegang en andere technieken voor dynamische informatiebeveiliging de bescherming van informatie ondersteunen, zelfs wanneer gegevens buiten de organisatie van herkomst worden gedeeldit kan worden toegepast op documenten, e-mails of andere bestanden @@ -109,4 +117,3 @@ met informatie, om te beperken wie er toegang kan krijgen tot de inhoud en hoe m Technieken voor het beheer van dynamische toegang zijn geen vervangers van klassiek toegangsbeheer \[bijv. het gebruik van lijsten voor toegangsbeheer (ACL's)\], maar ze kunnen meer factoren toevoegen voor conditionaliteit, realtime-evaluatie, just-in-timedatabeperking en andere verbeteringen die nuttig kunnen zijn voor de meest gevoelige informatieit biedt een manier om toegang buiten de omgeving van de organisatie te beveiligenncidentrespons kan worden ondersteund door technieken voor het beheer van dynamische toegang aangezien rechten te allen tijde kunnen worden gewijzigd of ingetrokken. -Aanvullende informatie over een kader voor toegangsbeheer wordt gegeven in ISO/IEC 29146. diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-8.30-Uitbestede-systeemontwikkeling.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-8.30-Uitbestede-systeemontwikkeling.md index 64e780c..fe2923a 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-8.30-Uitbestede-systeemontwikkeling.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-8.30-Uitbestede-systeemontwikkeling.md @@ -1,32 +1,48 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "8.30" +title: "Uitbestede systeemontwikkeling" +theme: Technological +control_type: + - Preventive + - Detective +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: + - Identify + - Protect + - Detect +operational_capabilities: + - System_and_network_security + - Application_security + - Supplier_relationships_security +security_domains: + - Governance_and_Ecosystem + - Protection +tags: +- iso27002/2022/NL +- sourcetext +status: active --- - -+------------------------+----------------------------------------------------+------------------------------------------+-----------------------------------------------------------------------------------------------------+--------------------------------------------+ -| **Type** | **Informatie-** | **Cybersecurity-** | **Operationele** | **Beveiligings-** | -| | | | | | -| **beheersmaatregel** | **beveiligings-** | **concepten** | **capaciteiten** | **domeinen** | -| | | | | | -| | **eigenschappen** | | | | -+========================+====================================================+==========================================+=====================================================================================================+============================================+ -| #Preventief | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | #Identificeren #Beschermen #Detecteren | #Systeem-\_en_netwerk- beveiliging #Toepassingsbeveiliging #Beveiliging_in_leveran- ciersrelaties | #Governance_en\_ Ecosysteem #Bescherming | -| | | | | | -| #Detectief | | | | | -+------------------------+----------------------------------------------------+------------------------------------------+-----------------------------------------------------------------------------------------------------+--------------------------------------------+ - -**Beheersmaatregel** +## 8.30 Uitbestede systeemontwikkeling +### Beheersmaatregel De organisatie behoort de activiteiten in verband met uitbestede systeemontwikkeling te sturen, bewaken en beoordelen. -**Doel** +### Doel Garanderen dat de door de organisatie vereiste informatiebeveiligingsmaatregelen bij uitbestede systeemontwikkeling worden geïmplementeerd. -**Richtlijn** +### Richtlijn Als systeemontwikkeling wordt uitbesteed, behoort de organisatie eisen en verwachtingen te communiceren en overeen te komen en voortdurend te monitoren, en te beoordelen of de levering van uitbesteed werk aan deze verwachtingen voldoete volgende punten behoren in de gehele externe toeleveringsketen van de organisatie in overweging te worden genomen: @@ -52,6 +68,5 @@ j) beveiligingseisen voor de ontwikkelomgeving (zie 8.31); k) rekening houden met toepasselijke wetgeving (bijvnzake de bescherming van persoonsgegevens). -**Overige informatie** +### Overige informatie -Verdere informatie over leveranciersrelaties is te vinden in de ISO/IEC 27036-reeks. diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-8.31-Scheiding-van-ontwikkel-test-en-productieomgevingen.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-8.31-Scheiding-van-ontwikkel-test-en-productieomgevingen.md index 00c0209..4c71ffb 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-8.31-Scheiding-van-ontwikkel-test-en-productieomgevingen.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-8.31-Scheiding-van-ontwikkel-test-en-productieomgevingen.md @@ -1,30 +1,40 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "8.31" +title: "Scheiding van ontwikkel-, test- en productieomgevingen" +theme: Technological +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: + - Application_security + - System_and_network_security +security_domains: [Protection] +tags: +- iso27002/2022/NL +- sourcetext +status: active --- - -+------------------------+----------------------------------------------------+----------------------+----------------------------------------------------------------+---------------------+ -| **Type** | **Informatie-** | **Cybersecurity-** | **Operationele** | **Beveiligings-** | -| | | | | | -| **beheersmaatregel** | **beveiligings-** | **concepten** | **capaciteiten** | **domeinen** | -| | | | | | -| | **eigenschappen** | | | | -+========================+====================================================+======================+================================================================+=====================+ -| #Preventief | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | #Beschermen | #Toepassingsbeveili- ging #Systeem-\_en_net- werkbeveiliging | #Bescherming | -+------------------------+----------------------------------------------------+----------------------+----------------------------------------------------------------+---------------------+ - -**Beheersmaatregel** +## 8.31 Scheiding van ontwikkel-, test- en productieomgevingen +### Beheersmaatregel Ontwikkel-, test- en productieomgevingen behoren te worden gescheiden en beveiligd. -**Doel** +### Doel De productieomgeving en de gegevens beschermen tegen compromittering door ontwikkel- en testactiviteiten. -**Richtlijn** +### Richtlijn Het scheidingsniveau tussen productie-, test- en ontwikkelomgevingen dat nodig is om operationele problemen te voorkomen, behoort te worden geïdentificeerd en geïmplementeerd. @@ -72,7 +82,7 @@ f) back-ups maken van de omgevingen. Het behoort niet mogelijk te zijn dat één persoon zonder voorafgaande beoordeling en goedkeuring veranderingen aan zowel de ontwikkeling als de productie kan doorvoerenit kan bijvoorbeeld worden bereikt door toegangsrechten te scheiden of door middel van regels die worden gemonitordn uitzonderingssituaties behoren aanvullende maatregelen zoals het bijhouden van gedetailleerde logbestanden en realtimemonitoring te worden geïmplementeerd om veranderingen door onbevoegden te detecteren en er actie op te ondernemen. -**Overige informatie** +### Overige informatie Zonder afdoende maatregelen en procedures kunnen ontwikkelaars en testers die toegang hebben tot productiesystemen, aanmerkelijke risico\'s introduceren (bijvngewenste wijziging van bestanden of de systeemomgeving, systeemstoringen, niet-goedgekeurde en niet-geteste code in productiesystemen uitvoeren, openbaarmaking van vertrouwelijke gegevens, en problemen met de integriteit en beschikbaarheid van gegevens)et is nodig een bekende en stabiele omgeving te onderhouden voor @@ -89,4 +99,3 @@ In bepaalde gevallen kan het onderscheid tussen ontwikkel-, test- en productieom Er zijn ondersteunende processen nodig voor het gebruik van productiegegevens in ontwikkel- en testomgevingen (zie 8.33). -Organisaties kunnen ook de hier gegeven richtlijnen voor trainingsomgevingen bij het trainen van eindgebruikers in aanmerking nemen. diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-8.32-Wijzigingsbeheer.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-8.32-Wijzigingsbeheer.md index fbbfd42..962713b 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-8.32-Wijzigingsbeheer.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-8.32-Wijzigingsbeheer.md @@ -1,27 +1,37 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "8.32" +title: "Wijzigingsbeheer" +theme: Technological +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: + - Application_security + - System_and_network_security +security_domains: [Protection] +tags: +- iso27002/2022/NL +- sourcetext +status: active --- - -+------------------------+----------------------------------------------------+----------------------+----------------------------------------------------------------+---------------------+ -| **Type** | **Informatie-** | **Cybersecurity-** | **Operationele** | **Beveiligings-** | -| | | | | | -| **beheersmaatregel** | **beveiligings-** | **concepten** | **capaciteiten** | **domeinen** | -| | | | | | -| | **eigenschappen** | | | | -+========================+====================================================+======================+================================================================+=====================+ -| #Preventief | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | #Beschermen | #Toepassingsbeveili- ging #Systeem-\_en_net- werkbeveiliging | #Bescherming | -+------------------------+----------------------------------------------------+----------------------+----------------------------------------------------------------+---------------------+ - -**Beheersmaatregel** +## 8.32 Wijzigingsbeheer +### Beheersmaatregel Wijzigingen in informatieverwerkingsfaciliteiten en informatiesystemen behoren onderworpen te zijn aan procedures voor wijzigingsbeheer. -**Doel** +### Doel De informatiebeveiliging behouden tijdens het uitvoeren van wijzigingen. -**Richtlijn** +### Richtlijn Nieuwe systemen en belangrijke wijzigingen aan bestaande systemen behoren volgens overeengekomen regels en een formeel proces van documentatie, specificatie, testen, kwaliteitscontrole en beheerde implementatie te worden geïntroduceerderantwoordelijkheden en procedures voor beheer behoren te worden vastgelegd om afdoende beheersing van alle veranderingen te waarborgen. @@ -60,7 +70,7 @@ i) bewerkstelligen dat de plannen voor ICT-continuïteit en de respons- en herst 5) worden gewijzigd naarmate nodig is om passend te blijven. -**Overige informatie** +### Overige informatie Onvoldoende beheersing van veranderingen aan informatieverwerkende faciliteiten en informatiesystemen is een algemene oorzaak van systeem- of beveiligingsfouteneranderingen aan de productieomgeving, in het bijzonder als software wordt gemuteerd van de ontwikkelings- naar de uitvoeringsomgeving, kunnen van invloed zijn op de integriteit en beschikbaarheid van toepassingen. @@ -68,4 +78,3 @@ Het wijzigen van software kan van invloed zijn op de productieomgeving en vice v Bij een goede werkwijze wordt het testen van ICT-componenten uitgevoerd in een omgeving die zowel gescheiden is van de productie- als van de ontwikkelomgevingen (zie 8.31). Hierdoor wordt het mogelijk om controle te hebben over nieuwe software en om extra bescherming te bieden voor uitvoeringsinformatie die wordt gebruikt voor testdoeleindenit behoort te gelden voor patches, servicepacks en andere updates. -De productieomgeving omvat besturingssystemen, databases en middlewareplatformse controle behoort te worden toegepast voor veranderingen van toepassingen en infrastructuren. diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-8.33-Testgegevens.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-8.33-Testgegevens.md index 5107222..8c1e323 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-8.33-Testgegevens.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-8.33-Testgegevens.md @@ -1,29 +1,34 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "8.33" +title: "Testgegevens" +theme: Technological +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity +cybersecurity_concepts: [Protect] +operational_capabilities: [Information_protection] +security_domains: [Protection] +tags: +- iso27002/2022/NL +- sourcetext +status: active --- - -+------------------------+----------------------+----------------------+--------------------------+---------------------+ -| **Type** | **Informatie-** | **Cybersecurity-** | **Operationele** | **Beveiligings-** | -| | | | | | -| **beheersmaatregel** | **beveiligings-** | **concepten** | **capaciteiten** | **domeinen** | -| | | | | | -| | **eigenschappen** | | | | -+========================+======================+======================+==========================+=====================+ -| #Preventief | #Vertrouwelijkheid | #Beschermen | #Informatiebescherming | #Bescherming | -| | | | | | -| | #Integriteit | | | | -+------------------------+----------------------+----------------------+--------------------------+---------------------+ - -**Beheersmaatregel** +## 8.33 Testgegevens +### Beheersmaatregel Testgegevens behoren op passende wijze te worden geselecteerd, beschermd en beheerd. -**Doel** +### Doel De relevantie van het testen en de bescherming van operationele gegevens die voor het testen worden gebruikt, waarborgen. -**Richtlijn** +### Richtlijn Testgegevens behoren dusdanig te worden geselecteerd dat de betrouwbaarheid van testresultaten en de vertrouwelijkheid van de relevante operationele gegevens gegarandeerd wordenr behoren geen gevoelige gegevens (met inbegrip van persoonsgegevens) in de ontwikkel- en testomgevingen te worden gekopieerd (zie 8.31). @@ -41,6 +46,5 @@ e) operationele gegevens naar behoren uit een testomgeving wissen (zie 8.10) onm Testgegevens behoren veilig te worden opgeslagen (om manipulatie te voorkomen, die anders tot ongeldige resultaten kan leiden) en alleen voor testdoeleinden te worden gebruikt. -**Overige informatie** +### Overige informatie -Systeem- en acceptatietests kunnen substantiële hoeveelheden testgegevens vereisen die een zo getrouw mogelijke weergave zijn van operationele gegevens. diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-8.34-Bescherming-van-informatiesystemen-tijdens-audits.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-8.34-Bescherming-van-informatiesystemen-tijdens-audits.md index c0d1d69..943b093 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-8.34-Bescherming-van-informatiesystemen-tijdens-audits.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-8.34-Bescherming-van-informatiesystemen-tijdens-audits.md @@ -1,27 +1,39 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "8.34" +title: "Bescherming van informatiesystemen tijdens audits" +theme: Technological +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: + - System_and_network_security + - Information_protection +security_domains: + - Governance_and_Ecosystem + - Protection +tags: +- iso27002/2022/NL +- sourcetext +status: active --- - -+------------------------+----------------------------------------------------+----------------------+-------------------------------------------------------------+--------------------------------------------+ -| **Type** | **Informatie-** | **Cybersecurity-** | **Operationele** | **Beveiligings-** | -| | | | | | -| **beheersmaatregel** | **beveiligings-** | **concepten** | **capaciteiten** | **domeinen** | -| | | | | | -| | **eigenschappen** | | | | -+========================+====================================================+======================+=============================================================+============================================+ -| #Preventief | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | #Beschermen | #Systeem-\_en_netwerk- beveiliging #Informatiebescherming | #Governance_en\_ Ecosysteem #Bescherming | -+------------------------+----------------------------------------------------+----------------------+-------------------------------------------------------------+--------------------------------------------+ - -**Beheersmaatregel** +## 8.34 Bescherming van informatiesystemen tijdens audits +### Beheersmaatregel Audits en andere borgingsactiviteiten waarbij operationele systemen worden beoordeeld behoren te worden gepland en overeengekomen tussen de tester en het verantwoordelijke management. -**Doel** +### Doel De impact van audit- en andere borgingsactiviteiten op operationele systemen en bedrijfsprocessen tot een minimum beperken. -**Richtlijn** +### Richtlijn De volgende richtlijnen behoren te worden overwogen: @@ -41,7 +53,7 @@ g) audits die de beschikbaarheid van systemen kunnen beïnvloeden, buiten werkur h) alle toegang voor audit- en testdoeleinden monitoren en in logbestanden registreren. -**Overige informatie** +### Overige informatie Audits en andere borgingsactiviteiten kunnen ook plaatsvinden op ontwikkel- en testsystemen, waarbij deze tests bijvoorbeeld gevolgen kunnen hebben voor de integriteit van code of ertoe kunnen leiden dat in die omgevingen bewaarde gevoelige informatie openbaar wordt gemaakt. @@ -1499,4 +1511,3 @@ Kies voor slimmer werken en bekijk onze mogelijkheden op [wwwnconnect]{derline}. Onze Klantenservice is bereikbaar maandag tot en met vrijdag, van 8 uur tot 17 uur. -Telefoon: 015 2 690 391 E-mail: [klantenservice@nen]{derline} diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-8.4-Toegangsbeveiliging-op-broncode.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-8.4-Toegangsbeveiliging-op-broncode.md index 3e1f384..dfcd380 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-8.4-Toegangsbeveiliging-op-broncode.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-8.4-Toegangsbeveiliging-op-broncode.md @@ -1,27 +1,38 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "8.4" +title: "Toegangsbeveiliging op broncode" +theme: Technological +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: + - Identity_and_access_management + - Application_security + - Secure_configuration +security_domains: [Protection] +tags: +- iso27002/2022/NL +- sourcetext +status: active --- - -+------------------------+----------------------------------------------------+----------------------+-------------------------------------------------------------------------------------+---------------------+ -| **Type** | **Informatie-** | **Cybersecurity-** | **Operationele** | **Beveiligings-** | -| | | | | | -| **beheersmaatregel** | **beveiligings-** | **concepten** | **capaciteiten** | **domeinen** | -| | | | | | -| | **eigenschappen** | | | | -+========================+====================================================+======================+=====================================================================================+=====================+ -| #Preventief | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | #Beschermen | #Identiteits- \_en_toegangsbeheer #Toepassingsbeveili- ging #Veilige_configuratie | #Bescherming | -+------------------------+----------------------------------------------------+----------------------+-------------------------------------------------------------------------------------+---------------------+ - -**Beheersmaatregel** +## 8.4 Toegangsbeveiliging op broncode +### Beheersmaatregel Lees- en schrijftoegang tot broncode, ontwikkelinstrumenten en softwarebibliotheken behoort op passende wijze te worden beheerd. -**Doel** +### Doel Voorkomen dat er ongeoorloofde functionaliteit wordt geïntroduceerd, vermijden dat onbedoelde of kwaadwillige wijzigingen plaatsvinden en de vertrouwelijkheid behouden van waardevol intellectueel eigendom. -**Richtlijn** +### Richtlijn Toegang tot broncode en gerelateerde zaken (zoals ontwerpen, specificaties, verificatieplannen en validatieplannen) en ontwikkelinstrumenten (bijvompilers, builders, integratie-instrumenten, testplatformen en -omgevingen) behoort streng te worden beheerst. @@ -58,6 +69,5 @@ f) een auditlogbestand bijhouden van alle toegangsinstanties en van alle wijzigi Indien het de bedoeling is dat de programmabroncode wordt gepubliceerd, behoren aanvullende beheersmaatregelen die de integriteit ervan waarborgen (bijven digitale handtekening), te worden overwogen. -**Overige informatie** +### Overige informatie -Indien de toegang tot broncode niet naar behoren wordt beveiligd, kunnen onbevoegden broncode aanpassen of bepaalde gegevens in de ontwikkelomgeving (bijvopieën van productiegegevens, configuratiedetails) opvragen. diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-8.5-Beveiligde-authenticatie.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-8.5-Beveiligde-authenticatie.md index 2d1a5e7..b724d55 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-8.5-Beveiligde-authenticatie.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-8.5-Beveiligde-authenticatie.md @@ -1,30 +1,38 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "8.5" +title: "Beveiligde authenticatie" +theme: Technological +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: [Identity_and_access_management] +security_domains: [Protection] +tags: +- iso27002/2022/NL +- sourcetext +status: active --- - -+------------------------+----------------------------------------------------+----------------------+-------------------------------------+---------------------+ -| **Type** | **Informatie-** | **Cybersecurity-** | **Operationele** | **Beveiligings-** | -| | | | | | -| **beheersmaatregel** | **beveiligings-** | **concepten** | **capaciteiten** | **domeinen** | -| | | | | | -| | **eigenschappen** | | | | -+========================+====================================================+======================+=====================================+=====================+ -| #Preventief | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | #Beschermen | #Identiteits- \_en_toegangsbeheer | #Bescherming | -+------------------------+----------------------------------------------------+----------------------+-------------------------------------+---------------------+ - -**Beheersmaatregel** +## 8.5 Beveiligde authenticatie +### Beheersmaatregel Er behoren beveiligde authenticatietechnologieën en -procedures te worden geïmplementeerd op basis van beperkingen van de toegang tot informatie en het onderwerpspecifieke of aanvullende beleid inzake toegangsbeveiliging. -**Doel** +### Doel Bewerkstelligen dat een gebruiker of een entiteit veilig wordt geauthenticeerd wanneer toegang tot systemen, toepassingen en diensten wordt verleend. -**Richtlijn** +### Richtlijn Om de geclaimde identiteit van een gebruiker, software, berichten en andere entiteiten te bewijzen behoort een passende authenticatietechniek te worden gekozen. @@ -79,6 +87,5 @@ l) de verbindingsduur beperken om extra beveiliging te bieden voor toepassingen en de mogelijkheden voor onbevoegde toegang te verkleinen. -**Overige informatie** +### Overige informatie -Aanvullende informatie over de borging van de authenticatie van entiteiten is te vinden in ISO/IEC 29115. diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-8.6-Capaciteitsbeheer.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-8.6-Capaciteitsbeheer.md index d368324..4f16e0a 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-8.6-Capaciteitsbeheer.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-8.6-Capaciteitsbeheer.md @@ -1,29 +1,41 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "8.6" +title: "Capaciteitsbeheer" +theme: Technological +control_type: + - Preventive + - Detective +information_security_properties: + - Integrity + - Availability +cybersecurity_concepts: + - Identify + - Protect + - Detect +operational_capabilities: [Continuity] +security_domains: + - Governance_and_Ecosystem + - Protection +tags: +- iso27002/2022/NL +- sourcetext +status: active --- - -+------------------------+---------------------+------------------------------------------+--------------------+--------------------------------------------+ -| **Type** | **Informatie-** | **Cybersecurity-** | **Operationele** | **Beveiligings-** | -| | | | | | -| **beheersmaatregel** | **beveiligings-** | **concepten** | **capaciteiten** | **domeinen** | -| | | | | | -| | **eigenschappen** | | | | -+========================+=====================+==========================================+====================+============================================+ -| #Preventief | #Integriteit | #Identificeren #Beschermen #Detecteren | #Continuïteit | #Governance_en\_ Ecosysteem #Bescherming | -| | | | | | -| #Detectief | #Beschikbaarheid | | | | -+------------------------+---------------------+------------------------------------------+--------------------+--------------------------------------------+ - -**Beheersmaatregel** +## 8.6 Capaciteitsbeheer +### Beheersmaatregel Het gebruik van middelen behoort te worden gemonitord en afgestemd overeenkomstig de huidige en verwachte capaciteitseisen. -**Doel** +### Doel De vereiste capaciteit van informatieverwerkende faciliteiten, personeel, kantoren en andere faciliteiten waarborgen. -**Richtlijn** +### Richtlijn Capaciteitseisen voor informatieverwerkende faciliteiten, personeel, kantoren en andere faciliteiten behoren te worden gedefinieerd, rekening houdend met het belang van de betrokken systemen en processen voor de organisatie. @@ -72,6 +84,5 @@ overwegend belang zijn (bijvideostreaming). Voor systemen die belangrijk zijn voor de missie, behoort voor de capaciteit een gedocumenteerd beheersplan te worden overwogen. -**Overige informatie** +### Overige informatie -Meer informatie over de elasticiteit en schaalbaarheid van cloudcomputing is te vinden in ISO/IEC TS 23167. diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-8.7-Bescherming-tegen-malware.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-8.7-Bescherming-tegen-malware.md index 5b211b5..11b7719 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-8.7-Bescherming-tegen-malware.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-8.7-Bescherming-tegen-malware.md @@ -1,29 +1,44 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "8.7" +title: "Bescherming tegen malware" +theme: Technological +control_type: + - Preventive + - Detective + - Corrective +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: + - Protect + - Detect +operational_capabilities: + - System_and_network_security + - Information_protection +security_domains: + - Protection + - Defence +tags: +- iso27002/2022/NL +- sourcetext +status: active --- - -+---------------------------------------+----------------------------------------------------+----------------------+----------------------------------------------------------------+---------------------+ -| **Type** | **Informatie-** | **Cybersecurity-** | **Operationele** | **Beveiligings-** | -| | | | | | -| **beheersmaatregel** | **beveiligings-** | **concepten** | **capaciteiten** | **domeinen** | -| | | | | | -| | **eigenschappen** | | | | -+=======================================+====================================================+======================+================================================================+=====================+ -| #Preventief #Detectief #Corrigerend | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | #Beschermen | #Systeem- \_en_netwerk- beveiliging #Informatiebe- scherming | #Bescherming | -| | | | | | -| | | #Detecteren | | #Verdediging | -+---------------------------------------+----------------------------------------------------+----------------------+----------------------------------------------------------------+---------------------+ - -**Beheersmaatregel** +## 8.7 Bescherming tegen malware +### Beheersmaatregel Bescherming tegen malware behoort te worden geïmplementeerd en ondersteund door een passend gebruikersbewustzijn -**Doel** +### Doel Waarborgen dat informatie en andere gerelateerde bedrijfsmiddelen beschermd zijn tegen malware. -**Richtlijn** +### Richtlijn Bescherming tegen malware behoort te zijn gebaseerd op software die malware detecteert en op herstelsoftware, bewustwording ten aanzien van informatiebeveiliging, passende beheersmaatregelen met betrekking tot systeemtoegang en wijzigingsbeheeret gebruik van software voor het detecteren en herstellen van malware op zich is meestal niet afdoendee volgende richtlijnen behoren te worden overwogen: @@ -74,6 +89,5 @@ n) procedures toepassen om regelmatig informatie over nieuwe malware te verzamel o) verifiëren dat informatie met betrekking tot malware, zoals waarschuwingsbulletins, afkomstig is van gekwalificeerde en gerenommeerde bronnen (bijvetrouwbare internetsites of leveranciers van malwaredetectiesoftware), juist is en informatie biedt. -**Overige informatie** +### Overige informatie -Het is niet altijd mogelijk om op bepaalde systemen (bijv. bepaalde industriële besturingssystemen) software te installeren die tegen malware beschermt. Bepaalde vormen van malware infecteren computerbesturingssystemen en computerfirmware dusdanig dat gewone malwarebeheersmaatregelen het systeem niet kunnen opschonen en het nodig is de software voor het besturingssysteem en soms de computerfirmware vanaf een imagebestand volledig te herstellen om weer een veilige situatie te bereiken. diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-8.8-Beheer-van-technische-kwetsbaarheden.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-8.8-Beheer-van-technische-kwetsbaarheden.md index 0ccc11a..3f87093 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-8.8-Beheer-van-technische-kwetsbaarheden.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-8.8-Beheer-van-technische-kwetsbaarheden.md @@ -1,31 +1,40 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "8.8" +title: "Beheer van technische kwetsbaarheden" +theme: Technological +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: + - Identify + - Protect +operational_capabilities: [Threat_and_vulnerability_management] +security_domains: + - Governance_and_Ecosystem + - Protection + - Defence +tags: +- iso27002/2022/NL +- sourcetext +status: active --- - -+------------------------+----------------------------------------------------+----------------------+------------------------------------------------+-----------------------------+ -| **Type** | **Informatie-** | **Cybersecurity-** | **Operationele** | **Beveiligingsdomeinen** | -| | | | | | -| **beheersmaatregel** | **beveiligings-** | **concepten** | **capaciteiten** | | -| | | | | | -| | **eigenschappen** | | | | -+========================+====================================================+======================+================================================+=============================+ -| #Preventief | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | #Identificeren | #Beheer_van\_ dreigingen_en\_ kwetsbaarheden | #Governance_en_Ecosysteem | -| | | | | | -| | | #Beschermen | | #Bescherming | -| | | | | | -| | | | | #Verdediging | -+------------------------+----------------------------------------------------+----------------------+------------------------------------------------+-----------------------------+ - -**Beheersmaatregel** +## 8.8 Beheer van technische kwetsbaarheden +### Beheersmaatregel Er behoort informatie te worden verkregen over technische kwetsbaarheden van in gebruik zijnde informatiesystemen, de blootstelling van de organisatie aan dergelijke kwetsbaarheden behoort te worden geëvalueerd en er behorende passende maatregelen te worden getroffen. -**Doel** +### Doel Misbruik van technische kwetsbaarheden voorkomen. -**Richtlijn** +### Richtlijn <u>Technische kwetsbaarheden identificeren</u> @@ -138,7 +147,7 @@ Indien de organisatie gebruikmaakt van een door een derde aanbieder van clouddie omvatten voor het melden van maatregelen van de aanbieder van de clouddiensten met betrekking tot technische kwetsbaarheden (zie 5.23). Voor bepaalde clouddiensten zijn er verantwoordelijkheden respectievelijk voor de aanbieder van de clouddienst en voor de afnemer van de clouddiensto is de afnemer van de clouddienst bijvoorbeeld verantwoordelijk voor het beheer van kwetsbaarheden van de eigen bedrijfsmiddelen die voor de clouddiensten worden gebruikt. -**Overige informatie** +### Overige informatie Het beheer van technische kwetsbaarheid kan worden beschouwd als een subfunctie van wijzigingsbeheer en kan als zodanig profiteren van de processen en procedures van wijzigingsbeheer (zie 8.32). @@ -161,4 +170,3 @@ Meer informatie over het beheer van technische kwetsbaarheden bij het gebruik va -ISO/IEC 29147 geeft gedetailleerde informatie over het ontvangen van meldingen van kwetsbaarheden en het publiceren van adviezen met betrekking tot kwetsbaarhedenSO/IEC 30111 geeft gedetailleerde informatie over het omgaan met en oplossen van gemelde kwetsbaarheden. diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/a-8.9-Configuratiebeheer.md b/Corpus/Standards/ISO27x/OST/27002/NL/a-8.9-Configuratiebeheer.md index 95c262f..70d5f57 100644 --- a/Corpus/Standards/ISO27x/OST/27002/NL/a-8.9-Configuratiebeheer.md +++ b/Corpus/Standards/ISO27x/OST/27002/NL/a-8.9-Configuratiebeheer.md @@ -1,27 +1,35 @@ -#iso27002/2022/NL --- -Standard: ISO 27002:2022 NL +notetype: reference +standard: ISO 27002 +version: 2022 +language: NL +type: control +id: "8.9" +title: "Configuratiebeheer" +theme: Technological +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: [Secure_configuration] +security_domains: [Protection] +tags: +- iso27002/2022/NL +- sourcetext +status: active --- - -+------------------------+----------------------------------------------------+----------------------+-------------------------+---------------------+ -| **Type** | **Informatie-** | **Cybersecurity-** | **Operationele** | **Beveiligings-** | -| | | | | | -| **beheersmaatregel** | **beveiligings-** | **concepten** | **capaciteiten** | **domeinen** | -| | | | | | -| | **eigenschappen** | | | | -+========================+====================================================+======================+=========================+=====================+ -| #Preventief | #Vertrouwelijkheid #Integriteit #Beschikbaarheid | #Beschermen | #Veilige_configuratie | #Bescherming | -+------------------------+----------------------------------------------------+----------------------+-------------------------+---------------------+ - -**Beheersmaatregel** +## 8.9 Configuratiebeheer +### Beheersmaatregel Configuraties, met inbegrip van beveiligingsconfiguraties, van hardware, software, diensten en netwerken behoren te worden vastgesteld, gedocumenteerd, geïmplementeerd, gemonitord en beoordeeld. -**Doel** +### Doel Garanderen dat hardware, software, diensten en netwerken correct met de vereiste beveiligingsinstellingen functioneren en de configuratie niet door ongeautoriseerde of onjuiste wijzigingen wordt gewijzigd. -**Richtlijn** +### Richtlijn <u>Algemeen</u> @@ -97,7 +105,7 @@ door middel van het automatisch afdwingen van de gedefinieerde doelconfiguratie -**Overige informatie** +### Overige informatie In documentatie voor systemen worden vaak details vastgelegd over de configuratie van zowel hardware als software. @@ -107,4 +115,3 @@ Configuratiebeheer kan worden geïntegreerd met processen voor het beheer van be Automatisering is meestal doeltreffender voor het beheren van de beveiligingsconfiguratie (bijvoor gebruik te maken van infrastructuur als code). -Configuratiesjablonen en -doelen kunnen vertrouwelijke informatie zijn en behoren dienovereenkomstig te worden beschermd tegen toegang door onbevoegden. diff --git a/Corpus/Standards/ISO27x/OST/27001/NL/IBB op hoofdlijnen.md b/Corpus/Standards/ISO27x/OST/IBB op hoofdlijnen.md similarity index 100% rename from Corpus/Standards/ISO27x/OST/27001/NL/IBB op hoofdlijnen.md rename to Corpus/Standards/ISO27x/OST/IBB op hoofdlijnen.md diff --git a/Corpus/Standards/ISO27x/OST/27001/NL/ISO 27001 2023 Processen en Artefacten.md b/Corpus/Standards/ISO27x/OST/ISO 27001 2023 Processen en Artefacten.md similarity index 100% rename from Corpus/Standards/ISO27x/OST/27001/NL/ISO 27001 2023 Processen en Artefacten.md rename to Corpus/Standards/ISO27x/OST/ISO 27001 2023 Processen en Artefacten.md diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/ISO 27002_2022_NL_Compleet.md b/Corpus/Standards/ISO27x/OST/ISO 27002_2022_NL_Compleet.md similarity index 100% rename from Corpus/Standards/ISO27x/OST/27002/NL/ISO 27002_2022_NL_Compleet.md rename to Corpus/Standards/ISO27x/OST/ISO 27002_2022_NL_Compleet.md diff --git a/Corpus/Standards/ISO27x/OST/ISO 27002_2022_nl_compleet.docx b/Corpus/Standards/ISO27x/OST/ISO 27002_2022_nl_compleet.docx new file mode 100644 index 0000000..ac6576a Binary files /dev/null and b/Corpus/Standards/ISO27x/OST/ISO 27002_2022_nl_compleet.docx differ diff --git a/Corpus/Standards/ISO27x/OST/27001/NL/ISO_27001_2023_NL_Aanpassingen.md b/Corpus/Standards/ISO27x/OST/ISO_27001_2023_NL_Aanpassingen.md similarity index 100% rename from Corpus/Standards/ISO27x/OST/27001/NL/ISO_27001_2023_NL_Aanpassingen.md rename to Corpus/Standards/ISO27x/OST/ISO_27001_2023_NL_Aanpassingen.md diff --git a/Corpus/Standards/ISO27x/OST/27001/NL/ISO_27001_2023_NL_Index.md b/Corpus/Standards/ISO27x/OST/ISO_27001_2023_NL_Index.md similarity index 55% rename from Corpus/Standards/ISO27x/OST/27001/NL/ISO_27001_2023_NL_Index.md rename to Corpus/Standards/ISO27x/OST/ISO_27001_2023_NL_Index.md index 8e134e8..8dda451 100644 --- a/Corpus/Standards/ISO27x/OST/27001/NL/ISO_27001_2023_NL_Index.md +++ b/Corpus/Standards/ISO27x/OST/ISO_27001_2023_NL_Index.md @@ -4,37 +4,37 @@ Publicatiedatum: augustus 2023 | 2023 ID | Onderwerp | Brontekst | | :------ | :------------------------------------------------------------------------- | :----------------------------- | -| **0** | **Inleiding** | [BT](c-0-Inleiding.md) | -| **1** | **Onderwerp en toepassingsgebied** | [BT](c-1-Onderwerp-en-toepassingsgebied.md) | -| **2** | **Normatieve verwijzingen** | [BT](c-2-Normatieve-verwijzingen.md) | -| **3** | **Termen en definities** | [BT](c-3-Termen-en-definities.md) | +| **0** | **Inleiding** | [BT](27001/NL/c-0-Inleiding.md) | +| **1** | **Onderwerp en toepassingsgebied** | [BT](27001/NL/c-1-Onderwerp-en-toepassingsgebied.md) | +| **2** | **Normatieve verwijzingen** | [BT](27001/NL/c-2-Normatieve-verwijzingen.md) | +| **3** | **Termen en definities** | [BT](27001/NL/c-3-Termen-en-definities.md) | | **4** | **Context van de organisatie** | | -| 4.1 | Inzicht in de organisatie en haar context | [BT](c-4.1-Inzicht-in-de-organisatie-en-haar-context.md) | -| 4.2 | Inzicht in de behoeften en verwachtingen van belanghebbenden | [BT](c-4.2-Inzicht-in-de-behoeften-en-verwachtingen-van-belanghebbenden.md) | -| 4.3 | Het toepassingsgebied van het managementsysteem voor informatiebeveiliging | [BT](c-4.3-Het-toepassingsgebied-van-het-managementsysteem-voor-informatiebeveiliging-vaststellen.md) | -| 4.4 | Managementsysteem voor informatiebeveiliging | [BT](c-4.4-Managementsysteem-voor-informatiebeveiliging.md) | +| 4.1 | Inzicht in de organisatie en haar context | [BT](27001/NL/c-4.1-Inzicht-in-de-organisatie-en-haar-context.md) | +| 4.2 | Inzicht in de behoeften en verwachtingen van belanghebbenden | [BT](27001/NL/c-4.2-Inzicht-in-de-behoeften-en-verwachtingen-van-belanghebbenden.md) | +| 4.3 | Het toepassingsgebied van het managementsysteem voor informatiebeveiliging | [BT](27001/NL/c-4.3-Het-toepassingsgebied-van-het-managementsysteem-voor-informatiebeveiliging-vaststellen.md) | +| 4.4 | Managementsysteem voor informatiebeveiliging | [BT](27001/NL/c-4.4-Managementsysteem-voor-informatiebeveiliging.md) | | **5** | **Leiderschap** | | -| 5.1 | Leiderschap en betrokkenheid | [BT](c-5.1-Leiderschap-en-betrokkenheid.md) | -| 5.2 | Beleid | [BT](c-5.2-Beleid.md) | -| 5.3 | Rollen, verantwoordelijkheden en bevoegdheden binnen de organisatie | [BT](c-5.3-Rollen-verantwoordelijkheden-en-bevoegdheden-binnen-de-organisatie.md) | +| 5.1 | Leiderschap en betrokkenheid | [BT](27001/NL/c-5.1-Leiderschap-en-betrokkenheid.md) | +| 5.2 | Beleid | [BT](27001/NL/c-5.2-Beleid.md) | +| 5.3 | Rollen, verantwoordelijkheden en bevoegdheden binnen de organisatie | [BT](27001/NL/c-5.3-Rollen-verantwoordelijkheden-en-bevoegdheden-binnen-de-organisatie.md) | | **6** | **Planning** | | -| 6.1 | Acties om risico's en kansen op te pakken | [BT](c-6.1-Acties-om-risicos-en-kansen-op-te-pakken.md) | -| 6.2 | Informatiebeveiligingsdoelstellingen en de planning om ze te bereiken | [BT](c-6.2-Informatiebeveiligingsdoelstellingen-en-de-planning-om-ze-te-bereiken.md) | -| 6.3 | Planning van wijzigingen | [BT](c-6.3-Planning-van-wijzigingen.md) | +| 6.1 | Acties om risico's en kansen op te pakken | [BT](27001/NL/c-6.1-Acties-om-risicos-en-kansen-op-te-pakken.md) | +| 6.2 | Informatiebeveiligingsdoelstellingen en de planning om ze te bereiken | [BT](27001/NL/c-6.2-Informatiebeveiligingsdoelstellingen-en-de-planning-om-ze-te-bereiken.md) | +| 6.3 | Planning van wijzigingen | [BT](27001/NL/c-6.3-Planning-van-wijzigingen.md) | | **7** | **Ondersteuning** | | -| 7.1 | Middelen | [BT](c-7.1-Middelen.md) | -| 7.2 | Competentie | [BT](c-7.2-Competentie.md) | -| 7.3 | Bewustzijn | [BT](c-7.3-Bewustzijn.md) | -| 7.4 | Communicatie | [BT](c-7.4-Communicatie.md) | -| 7.5 | Gedocumenteerde informatie | [BT](c-7.5-Gedocumenteerde-informatie.md) | +| 7.1 | Middelen | [BT](27001/NL/c-7.1-Middelen.md) | +| 7.2 | Competentie | [BT](27001/NL/c-7.2-Competentie.md) | +| 7.3 | Bewustzijn | [BT](27001/NL/c-7.3-Bewustzijn.md) | +| 7.4 | Communicatie | [BT](27001/NL/c-7.4-Communicatie.md) | +| 7.5 | Gedocumenteerde informatie | [BT](27001/NL/c-7.5-Gedocumenteerde-informatie.md) | | **8** | **Uitvoering** | | -| 8.1 | Operationele planning en beheersing | [BT](c-8.1-Operationele-planning-en-beheersing.md) | -| 8.2 | Risicobeoordeling van informatiebeveiliging | [BT](c-8.2-Risicobeoordeling-van-informatiebeveiliging.md) | -| 8.3 | Informatiebeveiligingsrisico's behandelen | [BT](c-8.3-Informatiebeveiligingsrisicos-behandelen.md) | +| 8.1 | Operationele planning en beheersing | [BT](27001/NL/c-8.1-Operationele-planning-en-beheersing.md) | +| 8.2 | Risicobeoordeling van informatiebeveiliging | [BT](27001/NL/c-8.2-Risicobeoordeling-van-informatiebeveiliging.md) | +| 8.3 | Informatiebeveiligingsrisico's behandelen | [BT](27001/NL/c-8.3-Informatiebeveiligingsrisicos-behandelen.md) | | **9** | **Evaluatie van de prestaties** | | -| 9.1 | Monitoren, meten, analyseren en evalueren | [BT](c-9.1-Monitoren-meten-analyseren-en-evalueren.md) | -| 9.2 | Interne audit | [BT](c-9.2-Interne-audit.md) | -| 9.3 | Management review | [BT](../EN/c-9.3-Management-review.md) | +| 9.1 | Monitoren, meten, analyseren en evalueren | [BT](27001/NL/c-9.1-Monitoren-meten-analyseren-en-evalueren.md) | +| 9.2 | Interne audit | [BT](27001/NL/c-9.2-Interne-audit.md) | +| 9.3 | Management review | [BT](27001/EN/c-9.3-Management-review.md) | | **10** | **Verbetering** | | -| 10.1 | Continue verbetering | [BT](c-10.1-Continue-verbetering.md) | -| 10.2 | Afwijkingen en corrigerende maatregelen | [BT](c-10.2-Afwijkingen-en-corrigerende-maatregelen.md) | +| 10.1 | Continue verbetering | [BT](27001/NL/c-10.1-Continue-verbetering.md) | +| 10.2 | Afwijkingen en corrigerende maatregelen | [BT](27001/NL/c-10.2-Afwijkingen-en-corrigerende-maatregelen.md) | diff --git a/Corpus/Standards/ISO27x/OST/ISO_27002_2022_NL_Index.md b/Corpus/Standards/ISO27x/OST/ISO_27002_2022_NL_Index.md new file mode 100644 index 0000000..82be68c --- /dev/null +++ b/Corpus/Standards/ISO27x/OST/ISO_27002_2022_NL_Index.md @@ -0,0 +1,114 @@ +#iso27002/2022/NL +# ISO 27002:2022 NL Index + + +| 2022 ID | Maatregel | Brontekst | +| :------ | :---------------------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------- | +| **3** | **Termen, definities en afgekorte termen** | | +| 3.1 | Termen en definities | [BT](27002/NL/a-3.1-Termen-en-definities.md) | +| 3.2 | Afgekorte termen | [BT](27002/NL/a-3.2-Afgekorte-termen.md) | +| **4** | **Structuur van dit document** | _ | +| 4.1 | Hoofdstukken | [BT](27002/NL/a-4.1-Hoofdstukken.md) | +| 4.2 | Thema's en attributen | [BT](27002/NL/a-4.2-Themas-en-attributen.md) | +| 4.3 | Indeling beheersmaatregel | [BT](27002/NL/a-4.3-Indeling-beheersmaatregel.md) | +| **5** | **Organisatorische beheersmaatregelen** | _ | +| 5.1 | Beleidsregels voor informatiebeveiliging | [BT](27002/NL/a-5.1-Beleidsregels-voor-informatiebeveiliging.md) | +| 5.2 | Rollen en verantwoordelijkheden bij informatiebeveiliging | [BT](27002/NL/a-5.2-Rollen-en-verantwoordelijkheden-bij-informatiebeveiliging.md) | +| 5.3 | Functiescheiding | [BT](27002/NL/a-5.3-Functiescheiding.md) | +| 5.4 | Managementverantwoordelijkheden | [BT](27002/NL/a-5.4-Managementverantwoordelijkheden.md) | +| 5.5 | Contact met overheidsinstanties | [BT](27002/NL/a-5.5-Contact-met-overheidsinstanties.md) | +| 5.6 | Contact met speciale belangengroepen | [BT](27002/NL/a-5.6-Contact-met-speciale-belangengroepen.md) | +| 5.7 | Informatie en analyses over dreigingen | [BT](27002/NL/a-5.7-Informatie-en-analyses-over-dreigingen.md) | +| 5.8 | Informatiebeveiliging in projectmanagement | [BT](27002/NL/a-5.8-Informatiebeveiliging-in-projectmanagement.md) | +| 5.9 | Inventarisatie van informatie en andere gerelateerde bedrijfsmiddelen | [BT](27002/NL/a-5.9-Inventarisatie-van-informatie-en-andere-gerelateerde-bedrijfsmiddelen.md) | +| 5.10 | Aanvaardbaar gebruik van informatie en andere gerelateerde bedrijfsmiddelen | [BT](27002/NL/a-5.10-Aanvaardbaar-gebruik-van-informatie-en-andere-gerelateerde-bedrijfsmiddelen.md) | +| 5.11 | Retourneren van bedrijfsmiddelen | [BT](27002/NL/a-5.11-Retourneren-van-bedrijfsmiddelen.md) | +| 5.12 | Classificeren van informatie | [BT](27002/NL/a-5.12-Classificeren-van-informatie.md) | +| 5.13 | Labelen van informatie | [BT](27002/NL/a-5.13-Labelen-van-informatie.md) | +| 5.14 | Overdragen van informatie | [BT](27002/NL/a-5.14-Overdragen-van-informatie.md) | +| 5.15 | Toegangsbeveiliging | [BT](27002/NL/a-5.15-Toegangsbeveiliging.md) | +| 5.16 | Identiteitsbeheer | [BT](27002/NL/a-5.16-Identiteitsbeheer.md) | +| 5.17 | Beheren van authenticatie-informatie | [BT](27002/NL/a-5.17-Beheren-van-authenticatie-informatie.md) | +| 5.18 | Toegangsrechten | [BT](27002/NL/a-5.18-Toegangsrechten.md) | +| 5.19 | Informatiebeveiliging in leveranciersrelaties | [BT](27002/NL/a-5.19-Informatiebeveiliging-in-leveranciersrelaties.md) | +| 5.20 | Adresseren van informatiebeveiliging in leveranciersovereenkomsten | [BT](27002/NL/a-5.20-Adresseren-van-informatiebeveiliging-in-leveranciersovereenkomsten.md) | +| 5.21 | Beheren van informatiebeveiliging in de ICT-keten | [BT](27002/NL/a-5.21-Beheren-van-informatiebeveiliging-in-de-ICT-keten.md) | +| 5.22 | Monitoren, beoordelen en het beheren van wijzigingen van leveranciersdiensten | [BT](27002/NL/a-5.22-Monitoren-beoordelen-en-het-beheren-van-wijzigingen-van-leveranciersdiensten.md) | +| 5.23 | Informatiebeveiliging voor het gebruik van clouddiensten | [BT](27002/NL/a-5.23-Informatiebeveiliging-voor-het-gebruik-van-clouddiensten.md) | +| 5.24 | Plannen en voorbereiden van het beheer van informatiebeveiligingsincidenten | [BT](27002/NL/a-5.24-Plannen-en-voorbereiden-van-het-beheer-van-informatiebeveiligingsincidenten.md) | +| 5.25 | Beoordelen van en besluiten over informatiebeveiligingsgebeurtenissen | [BT](27002/NL/a-5.25-Beoordelen-van-en-besluiten-over-informatiebeveiligingsgebeurtenissen.md) | +| 5.26 | Reageren op informatiebeveiligingsincidenten | [BT](27002/NL/a-5.26-Reageren-op-informatiebeveiligingsincidenten.md) | +| 5.27 | Leren van informatiebeveiligingsincidenten | [BT](27002/NL/a-5.27-Leren-van-informatiebeveiligingsincidenten.md) | +| 5.28 | Verzamelen van bewijsmateriaal | [BT](27002/NL/a-5.28-Verzamelen-van-bewijsmateriaal.md) | +| 5.29 | Informatiebeveiliging tijdens een verstoring | [BT](27002/NL/a-5.29-Informatiebeveiliging-tijdens-een-verstoring.md) | +| 5.30 | ICT-gereedheid voor bedrijfscontinuïteit | [BT](27002/NL/a-5.30-ICT-gereedheid-voor-bedrijfscontinuiteit.md) | +| 5.31 | Wettelijke, statutaire, regelgevende en contractuele eisen | [BT](27002/NL/a-5.31-Wettelijke-statutaire-regelgevende-en-contractuele-eisen.md) | +| 5.32 | Intellectuele-eigendomsrechten | [BT](27002/NL/a-5.32-Intellectuele-eigendomsrechten.md) | +| 5.33 | Beschermen van registraties | [BT](27002/NL/a-5.33-Beschermen-van-registraties.md) | +| 5.34 | Privacy en bescherming van persoonsgegevens | [BT](27002/NL/a-5.34-Privacy-en-bescherming-van-persoonsgegevens.md) | +| 5.35 | Onafhankelijke beoordeling van informatiebeveiliging | [BT](27002/NL/a-5.35-Onafhankelijke-beoordeling-van-informatiebeveiliging.md) | +| 5.36 | Naleving van beleid, regels en normen voor informatiebeveiliging | [BT](27002/NL/a-5.36-Naleving-van-beleid-regels-en-normen-voor-informatiebeveiliging.md) | +| 5.37 | Gedocumenteerde bedieningsprocedures | [BT](27002/NL/a-5.37-Gedocumenteerde-bedieningsprocedures.md) | +| | | | +| **6** | **Mensgerichte beheersmaatregelen** | | +| 6.1 | Screening | [BT](27002/EN/a-6.1-Screening.md) | +| 6.2 | Arbeidsovereenkomst | [BT](27002/NL/a-6.2-Arbeidsovereenkomst.md) | +| 6.3 | Bewustwording van, opleiding en training in informatiebeveiliging | [BT](27002/NL/a-6.3-Bewustwording-van-opleiding-en-training-in-informatiebeveiliging.md) | +| 6.4 | Disciplinaire procedure | [BT](27002/NL/a-6.4-Disciplinaire-procedure.md) | +| 6.5 | Verantwoordelijkheden na beëindiging of wijziging van het dienstverband | [BT](27002/NL/a-6.5-Verantwoordelijkheden-na-beeindiging-of-wijziging-van-het-dienstverband.md) | +| 6.6 | Vertrouwelijkheids- of geheimhoudingsovereenkomsten | [BT](27002/NL/a-6.6-Vertrouwelijkheids-of-geheimhoudingsovereenkomsten.md) | +| 6.7 | Werken op afstand | [BT](27002/NL/a-6.7-Werken-op-afstand.md) | +| 6.8 | Melden van informatiebeveiligingsgebeurtenissen | [BT](27002/NL/a-6.8-Melden-van-informatiebeveiligingsgebeurtenissen.md) | +| | | | +| **7** | **Fysieke beheersmaatregelen** | | +| 7.1 | Fysieke beveiligingszones | [BT](27002/NL/a-7.1-Fysieke-beveiligingszones.md) | +| 7.2 | Fysieke toegangsbeveiliging | [BT](27002/NL/a-7.2-Fysieke-toegangsbeveiliging.md) | +| 7.3 | Beveiligen van kantoren, ruimten en faciliteiten | [BT](27002/NL/a-7.3-Beveiligen-van-kantoren-ruimten-en-faciliteiten.md) | +| 7.4 | Monitoren van de fysieke beveiliging | [BT](27002/NL/a-7.4-Monitoren-van-de-fysieke-beveiliging.md) | +| 7.5 | Beschermen tegen fysieke en omgevingsdreigingen | [BT](27002/NL/a-7.5-Beschermen-tegen-fysieke-en-omgevingsdreigingen.md) | +| 7.6 | Werken in beveiligde zones | [BT](27002/NL/a-7.6-Werken-in-beveiligde-zones.md) | +| 7.7 | ‘Clear desk’ en ‘clear screen’ | [BT](27002/NL/a-7.7-Clear-desk-en-clear-screen.md) | +| 7.8 | Plaatsen en beschermen van apparatuur | [BT](27002/NL/a-7.8-Plaatsen-en-beschermen-van-apparatuur.md) | +| 7.9 | Beveiligen van bedrijfsmiddelen buiten het terrein | [BT](27002/NL/a-7.9-Beveiligen-van-bedrijfsmiddelen-buiten-het-terrein.md) | +| 7.10 | Opslagmedia | [BT](27002/NL/a-7.10-Opslagmedia.md) | +| 7.11 | Nutsvoorzieningen | [BT](27002/NL/a-7.11-Nutsvoorzieningen.md) | +| 7.12 | Beveiligen van bekabeling | [BT](27002/NL/a-7.12-Beveiligen-van-bekabeling.md) | +| 7.13 | Onderhoud van apparatuur | [BT](27002/NL/a-7.13-Onderhoud-van-apparatuur.md) | +| 7.14 | Veilig verwijderen of hergebruiken van apparatuur | [BT](27002/NL/a-7.14-Veilig-verwijderen-of-hergebruiken-van-apparatuur.md) | +| | | | +| **8** | **Technologische beheersmaatregelen** | | +| 8.1 | ‘User endpoint devices’ | [BT](27002/EN/a-8.1-User-endpoint-devices.md) | +| 8.2 | Speciale toegangsrechten | [BT](27002/NL/a-8.2-Speciale-toegangsrechten.md) | +| 8.3 | Beperking toegang tot informatie | [BT](27002/NL/a-8.3-Beperking-toegang-tot-informatie.md) | +| 8.4 | Toegangsbeveiliging op broncode | [BT](27002/NL/a-8.4-Toegangsbeveiliging-op-broncode.md) | +| 8.5 | Beveiligde authenticatie | [BT](27002/NL/a-8.5-Beveiligde-authenticatie.md) | +| 8.6 | Capaciteitsbeheer | [BT](27002/NL/a-8.6-Capaciteitsbeheer.md) | +| 8.7 | Bescherming tegen malware | [BT](27002/NL/a-8.7-Bescherming-tegen-malware.md) | +| 8.8 | Beheer van technische kwetsbaarheden | [BT](27002/NL/a-8.8-Beheer-van-technische-kwetsbaarheden.md) | +| 8.9 | Configuratiebeheer | [BT](27002/NL/a-8.9-Configuratiebeheer.md) | +| 8.10 | Wissen van informatie | [BT](27002/NL/a-8.10-Wissen-van-informatie.md) | +| 8.11 | Maskeren van gegevens | [BT](27002/NL/a-8.11-Maskeren-van-gegevens.md) | +| 8.12 | Voorkomen van gegevenslekken (Data leakage prevention) | [BT](27002/NL/a-8.12-Voorkomen-van-gegevenslekken-Data-leakage-prevention.md) | +| 8.13 | Back-up van informatie | [BT](27002/NL/a-8.13-Back-up-van-informatie.md) | +| 8.14 | Redundantie van informatieverwerkende faciliteiten | [BT](27002/NL/a-8.14-Redundantie-van-informatieverwerkende-faciliteiten.md) | +| 8.15 | Logging | [BT](27002/EN/a-8.15-Logging.md) | +| 8.16 | Monitoren van activiteiten | [BT](27002/NL/a-8.16-Monitoren-van-activiteiten.md) | +| 8.17 | Kloksynchronisatie | [BT](27002/NL/a-8.17-Kloksynchronisatie.md) | +| 8.18 | Gebruik van speciale systeemhulpmiddelen | [BT](27002/NL/a-8.18-Gebruik-van-speciale-systeemhulpmiddelen.md) | +| 8.19 | Installeren van software op operationele systemen | [BT](27002/NL/a-8.19-Installeren-van-software-op-operationele-systemen.md) | +| 8.20 | Beveiliging netwerkcomponenten | [BT](27002/NL/a-8.20-Beveiliging-netwerkcomponenten.md) | +| 8.21 | Beveiliging van netwerkdiensten | [BT](27002/NL/a-8.21-Beveiliging-van-netwerkdiensten.md) | +| 8.22 | Netwerksegmentatie | [BT](27002/NL/a-8.22-Netwerksegmentatie.md) | +| 8.23 | Toepassen van webfilters | [BT](27002/NL/a-8.23-Toepassen-van-webfilters.md) | +| 8.24 | Gebruik van cryptografie | [BT](27002/NL/a-8.24-Gebruik-van-cryptografie.md) | +| 8.25 | Beveiligen tijdens de ontwikkelcyclus | [BT](27002/NL/a-8.25-Beveiligen-tijdens-de-ontwikkelcyclus.md) | +| 8.26 | Toepassingsbeveiligingseisen | [BT](27002/NL/a-8.26-Toepassingsbeveiligingseisen.md) | +| 8.27 | Veilige systeemarchitectuur en technische uitgangspunten | [BT](27002/NL/a-8.27-Veilige-systeemarchitectuur-en-technische-uitgangspunten.md) | +| 8.28 | Veilig coderen | [BT](27002/NL/a-8.28-Veilig-coderen.md) | +| 8.29 | Testen van de beveiliging tijdens ontwikkeling en acceptatie | [BT](27002/NL/a-8.29-Testen-van-de-beveiliging-tijdens-ontwikkeling-en-acceptatie.md) | +| 8.30 | Uitbestede systeemontwikkeling | [BT](27002/NL/a-8.30-Uitbestede-systeemontwikkeling.md) | +| 8.31 | Scheiding van ontwikkel-, test- en productieomgevingen | [BT](27002/NL/a-8.31-Scheiding-van-ontwikkel-test-en-productieomgevingen.md) | +| 8.32 | Wijzigingsbeheer | [BT](27002/NL/a-8.32-Wijzigingsbeheer.md) | +| 8.33 | Testgegevens | [BT](27002/NL/a-8.33-Testgegevens.md) | +| 8.34 | Bescherming van informatiesystemen tijdens audits | [BT](27002/NL/a-8.34-Bescherming-van-informatiesystemen-tijdens-audits.md) | + diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/ISO_27002_2022_NL_PDF.md b/Corpus/Standards/ISO27x/OST/ISO_27002_2022_NL_PDF.md similarity index 100% rename from Corpus/Standards/ISO27x/OST/27002/NL/ISO_27002_2022_NL_PDF.md rename to Corpus/Standards/ISO27x/OST/ISO_27002_2022_NL_PDF.md diff --git a/Corpus/Standards/ISO27x/OST/27002/NL/ISO_IEC 27002_2022_NL.pdf b/Corpus/Standards/ISO27x/OST/ISO_IEC 27002_2022_NL.pdf similarity index 100% rename from Corpus/Standards/ISO27x/OST/27002/NL/ISO_IEC 27002_2022_NL.pdf rename to Corpus/Standards/ISO27x/OST/ISO_IEC 27002_2022_NL.pdf diff --git a/Corpus/Standards/ISO27x/OST/27001/NL/ISO_IEC_27001_2023_NL_ bijlage-A.md b/Corpus/Standards/ISO27x/OST/ISO_IEC_27001_2023_NL_ bijlage-A.md similarity index 100% rename from Corpus/Standards/ISO27x/OST/27001/NL/ISO_IEC_27001_2023_NL_ bijlage-A.md rename to Corpus/Standards/ISO27x/OST/ISO_IEC_27001_2023_NL_ bijlage-A.md diff --git a/Corpus/Standards/ISO27x/OST/27001/NL/ISO_IEC_27001_2023_NL_compleet.md b/Corpus/Standards/ISO27x/OST/ISO_IEC_27001_2023_NL_compleet.md similarity index 100% rename from Corpus/Standards/ISO27x/OST/27001/NL/ISO_IEC_27001_2023_NL_compleet.md rename to Corpus/Standards/ISO27x/OST/ISO_IEC_27001_2023_NL_compleet.md diff --git a/Corpus/Standards/ISO27x/OST/Index to the original texts of ISO 27001.md b/Corpus/Standards/ISO27x/OST/Index to the original texts of ISO 27001.md index 8d14c7a..6306c93 100644 --- a/Corpus/Standards/ISO27x/OST/Index to the original texts of ISO 27001.md +++ b/Corpus/Standards/ISO27x/OST/Index to the original texts of ISO 27001.md @@ -3,7 +3,7 @@ | Clause | Title | | ----------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| **F** | **[Foreword](27001/EN/ISO_27001_OT%20F%20Foreword.md)** | +| **F** | **[Foreword](27001/EN/c-f-Foreword.md)** | | **0** | **[Introduction](27001/EN/c-0-Introduction.md)** | | **1** | **[Scope](27001/EN/c-1-Scope.md)** | | **2** | **[Normative references](27001/EN/c-2-Normative-references.md)** | 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 new file mode 100644 index 0000000..727e6b4 --- /dev/null +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S01-Course-objectives-and-structure.md @@ -0,0 +1 @@ +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 new file mode 100644 index 0000000..0edb387 --- /dev/null +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S02.1-Introduction-to-management-systems-and-ISO-27000-family-of-standards.md @@ -0,0 +1 @@ +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 new file mode 100644 index 0000000..4baaf5e --- /dev/null +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S02.2-Introduction-to-management-systems-and-ISO-27000-family-of-standards.md @@ -0,0 +1 @@ +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 new file mode 100644 index 0000000..5e2791f --- /dev/null +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S02.3-Introduction-to-management-systems-and-ISO-27000-family-of-standards.md @@ -0,0 +1 @@ +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 new file mode 100644 index 0000000..8ba7881 --- /dev/null +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S03-Certification-process.md @@ -0,0 +1 @@ +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 new file mode 100644 index 0000000..b73cf95 --- /dev/null +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S04.1-Fundamental-concepts-and-principles-of-information-security.md @@ -0,0 +1 @@ +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 new file mode 100644 index 0000000..b0a3014 --- /dev/null +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S04.2-Fundamental-concepts-and-principles-of-information-security.md @@ -0,0 +1 @@ +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 new file mode 100644 index 0000000..5a01c92 --- /dev/null +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S04.3-Fundamental-concepts-and-principles-of-information-security.md @@ -0,0 +1 @@ +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 new file mode 100644 index 0000000..cd527ac --- /dev/null +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S05.1-Overview-of-ISO-27001-requirements.md @@ -0,0 +1 @@ +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 new file mode 100644 index 0000000..f67b3e7 --- /dev/null +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S05.2-Overview-of-ISO-27001-requirements.md @@ -0,0 +1 @@ +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 new file mode 100644 index 0000000..62c3ba4 --- /dev/null +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S05.3-Overview-of-ISO-27001-requirements.md @@ -0,0 +1 @@ +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 new file mode 100644 index 0000000..67bf8c8 --- /dev/null +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S05.4-Overview-of-ISO-27001-requirements.md @@ -0,0 +1 @@ +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 new file mode 100644 index 0000000..855b793 --- /dev/null +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S05.5-Overview-of-ISO-27001-requirements.md @@ -0,0 +1 @@ +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 new file mode 100644 index 0000000..a0bf6e8 --- /dev/null +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S06.1-Fundamental-audit-concepts-and-principles.md @@ -0,0 +1 @@ +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 new file mode 100644 index 0000000..11dee03 --- /dev/null +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S06.2-Fundamental-audit-concepts-and-principles.md @@ -0,0 +1 @@ +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 new file mode 100644 index 0000000..5de214b --- /dev/null +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S06.3-Fundamental-audit-concepts-and-principles.md @@ -0,0 +1 @@ +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 new file mode 100644 index 0000000..a493e65 --- /dev/null +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S06.4-Fundamental-audit-concepts-and-principles.md @@ -0,0 +1 @@ +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 new file mode 100644 index 0000000..ab60cf1 --- /dev/null +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S06.5-Fundamental-audit-concepts-and-principles.md @@ -0,0 +1 @@ +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 new file mode 100644 index 0000000..3814cd1 --- /dev/null +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S06.6-Fundamental-audit-concepts-and-principles.md @@ -0,0 +1 @@ +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 new file mode 100644 index 0000000..2114c61 --- /dev/null +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S07.1-The-impact-of-trends-and-technology-in-auditing.md @@ -0,0 +1 @@ +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 new file mode 100644 index 0000000..b2e12e3 --- /dev/null +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S07.2-The-impact-of-trends-and-technology-in-auditing.md @@ -0,0 +1 @@ +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 new file mode 100644 index 0000000..cf6b5b4 --- /dev/null +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S08.1-Evidence-based-auditing.md @@ -0,0 +1 @@ +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 new file mode 100644 index 0000000..cf05958 --- /dev/null +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S08.2-Evidence-based-auditing.md @@ -0,0 +1 @@ +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 new file mode 100644 index 0000000..2b231f2 --- /dev/null +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S09-Risk-based-audit.md @@ -0,0 +1 @@ +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 new file mode 100644 index 0000000..0984c2f --- /dev/null +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S10.1-Initiation-of-the-audit-process.md @@ -0,0 +1 @@ +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 new file mode 100644 index 0000000..459b69a --- /dev/null +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S10.2-Initiation-of-the-audit-process.md @@ -0,0 +1 @@ +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 new file mode 100644 index 0000000..91ed729 --- /dev/null +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S10.3-Initiation-of-the-audit-process.md @@ -0,0 +1 @@ +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 new file mode 100644 index 0000000..fcc25f8 --- /dev/null +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S11.1-Stage-1-audit.md @@ -0,0 +1 @@ +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 new file mode 100644 index 0000000..0cd3e33 --- /dev/null +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S11.2-Stage-1-audit.md @@ -0,0 +1 @@ +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 new file mode 100644 index 0000000..4befa49 --- /dev/null +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S12.1-Preparing-for-stage-2-audit.md @@ -0,0 +1 @@ +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 new file mode 100644 index 0000000..5b3a51a --- /dev/null +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S12.2-Preparing-for-stage-2-audit.md @@ -0,0 +1 @@ +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 new file mode 100644 index 0000000..d1180db --- /dev/null +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S13.1-Stage-2-audit.md @@ -0,0 +1 @@ +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 new file mode 100644 index 0000000..5ad7133 --- /dev/null +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S13.2-Stage-2-audit.md @@ -0,0 +1 @@ +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 new file mode 100644 index 0000000..6919197 --- /dev/null +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S14.1-Communication-during-the-audit.md @@ -0,0 +1 @@ +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 new file mode 100644 index 0000000..a56b739 --- /dev/null +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S14.2-Communication-during-the-audit.md @@ -0,0 +1 @@ +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 new file mode 100644 index 0000000..be8a71b --- /dev/null +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S15.1-Audit-procedures.md @@ -0,0 +1 @@ +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 new file mode 100644 index 0000000..5981c2a --- /dev/null +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S15.2-Audit-procedures.md @@ -0,0 +1 @@ +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 new file mode 100644 index 0000000..b5c6bf4 --- /dev/null +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S15.3-Audit-procedures.md @@ -0,0 +1 @@ +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 new file mode 100644 index 0000000..1b5c229 --- /dev/null +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S15.4-Audit-procedures.md @@ -0,0 +1 @@ +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 new file mode 100644 index 0000000..0e55f27 --- /dev/null +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S15.5-Audit-procedures.md @@ -0,0 +1 @@ +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 new file mode 100644 index 0000000..df1b567 --- /dev/null +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S16.1-Creating-audit-test-plans.md @@ -0,0 +1 @@ +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 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 new file mode 100644 index 0000000..7781af9 --- /dev/null +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S16.2-Creating-audit-test-plans.md @@ -0,0 +1 @@ +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 new file mode 100644 index 0000000..48ea63e --- /dev/null +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S17.1-Drafting-audit-findings-and-nonconformity-reports.md @@ -0,0 +1 @@ +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 new file mode 100644 index 0000000..ff2e539 --- /dev/null +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S17.2-Drafting-audit-findings-and-nonconformity-reports.md @@ -0,0 +1 @@ +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 new file mode 100644 index 0000000..f326217 --- /dev/null +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S18-Audit-documentation-and-quality-review.md @@ -0,0 +1 @@ +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 new file mode 100644 index 0000000..55fd1c3 --- /dev/null +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S19.1-Closing-of-the-audit.md @@ -0,0 +1 @@ +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 new file mode 100644 index 0000000..118a0cd --- /dev/null +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S19.2-Closing-of-the-audit.md @@ -0,0 +1 @@ +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 new file mode 100644 index 0000000..7f359e3 --- /dev/null +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S20-Evaluation-of-action-plans-by-the-auditor.md @@ -0,0 +1 @@ +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 new file mode 100644 index 0000000..08a29e7 --- /dev/null +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S21.1-Beyond-the-initial-audit.md @@ -0,0 +1 @@ +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 new file mode 100644 index 0000000..c6b8580 --- /dev/null +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S21.2-Beyond-the-initial-audit.md @@ -0,0 +1 @@ +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 new file mode 100644 index 0000000..db21118 --- /dev/null +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S22.1-Managing-an-internal-audit-program.md @@ -0,0 +1 @@ +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 new file mode 100644 index 0000000..92f5205 --- /dev/null +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S22.2-Managing-an-internal-audit-program.md @@ -0,0 +1 @@ +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 new file mode 100644 index 0000000..517b40e --- /dev/null +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S23.1-Closing-of-the-training-course.md @@ -0,0 +1 @@ +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 new file mode 100644 index 0000000..ee2d899 --- /dev/null +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S23.2-Closing-of-the-training-course.md @@ -0,0 +1 @@ +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 diff --git a/Corpus/Standards/ISO27x/Toevoegingen IBB ISO27001-2022.md b/Corpus/Standards/ISO27x/Toevoegingen IBB ISO27001-2022.md index 5a0528e..642d42b 100644 --- a/Corpus/Standards/ISO27x/Toevoegingen IBB ISO27001-2022.md +++ b/Corpus/Standards/ISO27x/Toevoegingen IBB ISO27001-2022.md @@ -1,6 +1,6 @@ # Nieuwe beheersmaatregelen in ISO 27001:2022 -Gebaseerd op [Aanpassingen in ISO 27001:2023](OST/27001/NL/ISO_27001_2023_NL_Aanpassingen.md#Nieuwe%20beheersmaatregelen%20in%20Annex%20A) +Gebaseerd op [Aanpassingen in ISO 27001:2023](OST/ISO_27001_2023_NL_Aanpassingen.md#Nieuwe%20beheersmaatregelen%20in%20Annex%20A) Verwerkt in [Informatiebeveiligingsbeleid ISO 27001](Implementation%20Products/Informatiebeveiligingsbeleid%20ISO%2027001.md) | Maatregel | **Paragraaf** | diff --git a/Corpus/Standards/MoCs/ISO_27002_2022_8.25_MoC Secure development life cycle.md b/Corpus/Standards/MoCs/ISO_27002_2022_8.25_MoC Secure development life cycle.md deleted file mode 100644 index d29f3c8..0000000 --- a/Corpus/Standards/MoCs/ISO_27002_2022_8.25_MoC Secure development life cycle.md +++ /dev/null @@ -1,5 +0,0 @@ -[[ISO_27002_2022_8.25_OT Secure development life cycle \|Original Text]] -[[ISO_27002_2022_8.25_PE Secure development life cycle \|Plain English]] -ISO 27002:2013: 14.2.1 - -![[../../../../iso27DIY-gis/reference/examples/ci-cd-pipeline-security-best-practices.pdf]] \ No newline at end of file diff --git a/Corpus/Standards/other/Infosec frameworks and regulations.md b/Corpus/Standards/other/Infosec frameworks and regulations.md index adbb6ca..3ec211e 100644 --- a/Corpus/Standards/other/Infosec frameworks and regulations.md +++ b/Corpus/Standards/other/Infosec frameworks and regulations.md @@ -22,7 +22,7 @@ See also: - [ISO_27001_2013_EN_Index](../ISO27x/legacy/ISO%2027001%202013/ISO_27001_2013_EN_Index.md) - [ISO_27001_2017_NL_Index](../ISO27x/legacy/ISO%2027001%202017%20NL/ISO_27001_2017_NL_Index.md) - [ISO_27001_2022_00_MoC Index EXT](../../MoCs/ISO_27001_2022_00_MoC%20Index%20EXT.md) -- [ISO_27002_2022_NL_Index](../ISO27x/OST/27002/NL/ISO_27002_2022_NL_Index.md) +- [ISO_27002_2022_NL_Index](../ISO27x/OST/ISO_27002_2022_NL_Index.md) - [ISO31000-5.4.1-Understanding-the-organization-and-its-context](../ISO27x/ISO31000-5.4.1-Understanding-the-organization-and-its-context.md) - [NEN7510 Risicos](../ISO27x/OST/7510/NEN7510%20Risicos.md) - [NIST CSF 2.0](../NIST/NIST%20CSF%202.0.md) diff --git a/Corpus/🎇 Sparks/Risks.md b/Corpus/🎇 Sparks/Risks.md index 838101c..a0958dc 100644 --- a/Corpus/🎇 Sparks/Risks.md +++ b/Corpus/🎇 Sparks/Risks.md @@ -1,6 +1,6 @@ [Assets, Vulnerabilities, Threats, Risks](Assets,%20Vulnerabilities,%20Threats,%20Risks.md) [Vulnerability](../💡Drafts%20and%20Ideas/Vulnerability.md) -[📗 Information security concepts MoC](../📗%20Information%20security%20concepts%20MoC.md) +[Information security concepts MoC](../Information%20security%20concepts%20MoC.md) [Assets, Vulnerabilities, Threats, Risks](../📚️%20Literature%20notes/Assets,%20Vulnerabilities,%20Threats,%20Risks.md) diff --git a/Corpus/💡Drafts and Ideas/Information Security.md b/Corpus/💡Drafts and Ideas/Information Security.md index 7c1447e..8783fba 100644 --- a/Corpus/💡Drafts and Ideas/Information Security.md +++ b/Corpus/💡Drafts and Ideas/Information Security.md @@ -1,3 +1,3 @@ -- [📗 Information security concepts MoC](../📗%20Information%20security%20concepts%20MoC.md) +- [Information security concepts MoC](../Information%20security%20concepts%20MoC.md) - [🗃 Standards and Regulations for information security](../Standards/other/🗃%20Standards%20and%20Regulations%20for%20information%20security.md) diff --git a/Corpus/📗 Information security concepts MoC.md b/Corpus/📗 Information security concepts MoC.md index b2c42c7..8877780 100644 --- a/Corpus/📗 Information security concepts MoC.md +++ b/Corpus/📗 Information security concepts MoC.md @@ -1,6 +1,12 @@ --- Related: +<<<<<<< HEAD + - "[ISO\\_27002\\_OT 3 Terms, definitions and abbreviated terms](Standards/ISO27x/OST/27002/EN/a-3-Terms-definitions-and-abbreviated-terms.md)" +||||||| 2d92263 - "[ISO\\_27002\\_OT 3 Terms, definitions and abbreviated terms](Standards/ISO27x/OST/27002/EN/ISO_27002_OT%203%20Terms,%20definitions%20and%20abbreviated%20terms.md)" +======= + - "[ISO\\_27002\\_OT 3 Terms, definitions and abbreviated terms](Standards/ISO27x/OST/27002/EN/a-3-Terms-definitions-and-abbreviated%20terms.md)" +>>>>>>> 27002-metadata - https://csiac.org/databases/acronyms/ tags: - type/MoC diff --git a/prepend_frontmatter.py b/prepend_frontmatter.py new file mode 100644 index 0000000..0827aae --- /dev/null +++ b/prepend_frontmatter.py @@ -0,0 +1,2320 @@ +#!/usr/bin/env python3 +""" +prepend_frontmatter.py + +For each ISO 27002 control note in the target folder: +- Skips files that already have YAML frontmatter (starts with ---) +- Skips a-3-Terms* +- Prepends the correct frontmatter block and writes the file back + +Run from anywhere: + python3 prepend_frontmatter.py + +Requires Python 3.6+. No dependencies. +""" + +import os + +VAULT_DIR = "/Users/rico/src/iso27diy-corp/Corpus/Standards/ISO27x/OST/27002/EN" + +FRONTMATTER = { + "a-5.1-Policies-for-information-security.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.5.1" +title: "Policies for information security" +theme: Organizational +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Identify] +operational_capabilities: [Governance] +security_domains: + - Governance_and_Ecosystem + - Resilience +tags: + - iso27002/2022/EN +status: active +---""", + + "a-5.2-Information-security-roles-and-responsibilities.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.5.2" +title: "Information security roles and responsibilities" +theme: Organizational +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Identify] +operational_capabilities: [Governance] +security_domains: + - Governance_and_Ecosystem + - Protection + - Resilience +tags: + - iso27002/2022/EN +status: active +---""", + + "a-5.3-Segregation-of-duties.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.5.3" +title: "Segregation of duties" +theme: Organizational +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: + - Governance + - Identity_and_access_management +security_domains: [Governance_and_Ecosystem] +tags: + - iso27002/2022/EN +status: active +---""", + + "a-5.4-Management-responsibilities.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.5.4" +title: "Management responsibilities" +theme: Organizational +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Identify] +operational_capabilities: [Governance] +security_domains: [Governance_and_Ecosystem] +tags: + - iso27002/2022/EN +status: active +---""", + + "a-5.5-Contact-with-authorities.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.5.5" +title: "Contact with authorities" +theme: Organizational +control_type: + - Preventive + - Corrective +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: + - Identify + - Protect + - Respond + - Recover +operational_capabilities: [Governance] +security_domains: + - Defence + - Resilience +tags: + - iso27002/2022/EN +status: active +---""", + + "a-5.6-Contact-with-special-interest-groups.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.5.6" +title: "Contact with special interest groups" +theme: Organizational +control_type: + - Preventive + - Corrective +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: + - Protect + - Respond + - Recover +operational_capabilities: [Governance] +security_domains: [Defence] +tags: + - iso27002/2022/EN +status: active +---""", + + "a-5.7-Threat-intelligence.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.5.7" +title: "Threat intelligence" +theme: Organizational +control_type: + - Preventive + - Detective + - Corrective +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: + - Identify + - Detect + - Respond +operational_capabilities: [Threat_and_vulnerability_management] +security_domains: + - Defence + - Resilience +tags: + - iso27002/2022/EN +status: active +---""", + + "a-5.8-Information-security-in-project-management.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.5.8" +title: "Information security in project management" +theme: Organizational +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: + - Identify + - Protect +operational_capabilities: [Governance] +security_domains: + - Governance_and_Ecosystem + - Protection +tags: + - iso27002/2022/EN +status: active +---""", + + "a-5.9-Inventory-of-information-and-other-associated-assets.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.5.9" +title: "Inventory of information and other associated assets" +theme: Organizational +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Identify] +operational_capabilities: [Asset_management] +security_domains: + - Governance_and_Ecosystem + - Protection +tags: + - iso27002/2022/EN +status: active +---""", + + "a-5.10-Acceptable-use-of-information-and-other-associated-assets.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.5.10" +title: "Acceptable use of information and other associated assets" +theme: Organizational +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: + - Asset_management + - Information_protection +security_domains: + - Governance_and_Ecosystem + - Protection +tags: + - iso27002/2022/EN +status: active +---""", + + "a-5.11-Return-of-assets.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.5.11" +title: "Return of assets" +theme: Organizational +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: [Asset_management] +security_domains: [Protection] +tags: + - iso27002/2022/EN +status: active +---""", + + "a-5.12-Classification-of-information.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.5.12" +title: "Classification of information" +theme: Organizational +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Identify] +operational_capabilities: [Information_protection] +security_domains: + - Protection + - Defence +tags: + - iso27002/2022/EN +status: active +---""", + + "a-5.13-Labelling-of-information.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.5.13" +title: "Labelling of information" +theme: Organizational +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: [Information_protection] +security_domains: + - Defence + - Protection +tags: + - iso27002/2022/EN +status: active +---""", + + "a-5.14-Information-transfer.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.5.14" +title: "Information transfer" +theme: Organizational +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: + - Asset_management + - Information_protection +security_domains: [Protection] +tags: + - iso27002/2022/EN +status: active +---""", + + "a-5.15-Access-control.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.5.15" +title: "Access control" +theme: Organizational +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: [Identity_and_access_management] +security_domains: [Protection] +tags: + - iso27002/2022/EN +status: active +---""", + + "a-5.16-Identity-management.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.5.16" +title: "Identity management" +theme: Organizational +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: [Identity_and_access_management] +security_domains: [Protection] +tags: + - iso27002/2022/EN +status: active +---""", + + "a-5.17-Authentication-information.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.5.17" +title: "Authentication information" +theme: Organizational +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: [Identity_and_access_management] +security_domains: [Protection] +tags: + - iso27002/2022/EN +status: active +---""", + + "a-5.18-Access-rights.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.5.18" +title: "Access rights" +theme: Organizational +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: [Identity_and_access_management] +security_domains: [Protection] +tags: + - iso27002/2022/EN +status: active +---""", + + "a-5.19-Information-security-in-supplier-relationships.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.5.19" +title: "Information security in supplier relationships" +theme: Organizational +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Identify] +operational_capabilities: [Supplier_relationships_security] +security_domains: + - Governance_and_Ecosystem + - Protection +tags: + - iso27002/2022/EN +status: active +---""", + + "a-5.20-Addressing-information-security-within-supplier-agreements.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.5.20" +title: "Addressing information security within supplier agreements" +theme: Organizational +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Identify] +operational_capabilities: [Supplier_relationships_security] +security_domains: + - Governance_and_Ecosystem + - Protection +tags: + - iso27002/2022/EN +status: active +---""", + + "a-5.21-Managing-information-security-in-the-ICT-supply-chain.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.5.21" +title: "Managing information security in the ICT supply chain" +theme: Organizational +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Identify] +operational_capabilities: [Supplier_relationships_security] +security_domains: + - Governance_and_Ecosystem + - Protection +tags: + - iso27002/2022/EN +status: active +---""", + + "a-5.22-Monitoring-review-and-change-management-of-supplier-services.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.5.22" +title: "Monitoring, review and change management of supplier services" +theme: Organizational +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Identify] +operational_capabilities: [Supplier_relationships_security] +security_domains: + - Governance_and_Ecosystem + - Protection + - Defence + - Information_security_assurance +tags: + - iso27002/2022/EN +status: active +---""", + + "a-5.23-Information-security-for-use-of-cloud-services.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.5.23" +title: "Information security for use of cloud services" +theme: Organizational +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: [Supplier_relationships_security] +security_domains: + - Governance_and_Ecosystem + - Protection +tags: + - iso27002/2022/EN +status: active +---""", + + "a-5.24-Information-security-incident-management-planning-and-preparation.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.5.24" +title: "Information security incident management planning and preparation" +theme: Organizational +control_type: [Corrective] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: + - Respond + - Recover +operational_capabilities: + - Governance + - Information_security_event_management +security_domains: [Defence] +tags: + - iso27002/2022/EN +status: active +---""", + + "a-5.25-Assessment-and-decision-on-information-security-events.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.5.25" +title: "Assessment and decision on information security events" +theme: Organizational +control_type: [Detective] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: + - Detect + - Respond +operational_capabilities: [Information_security_event_management] +security_domains: [Defence] +tags: + - iso27002/2022/EN +status: active +---""", + + "a-5.26-Response-to-information-security-incidents.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.5.26" +title: "Response to information security incidents" +theme: Organizational +control_type: [Corrective] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: + - Respond + - Recover +operational_capabilities: [Information_security_event_management] +security_domains: [Defence] +tags: + - iso27002/2022/EN +status: active +---""", + + "a-5.27-Learning-from-information-security-incidents.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.5.27" +title: "Learning from information security incidents" +theme: Organizational +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: + - Identify + - Protect +operational_capabilities: [Information_security_event_management] +security_domains: [Defence] +tags: + - iso27002/2022/EN +status: active +---""", + + "a-5.28-Collection-of-evidence.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.5.28" +title: "Collection of evidence" +theme: Organizational +control_type: [Corrective] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: + - Detect + - Respond +operational_capabilities: [Information_security_event_management] +security_domains: [Defence] +tags: + - iso27002/2022/EN +status: active +---""", + + "a-5.29-Information-security-during-disruption.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.5.29" +title: "Information security during disruption" +theme: Organizational +control_type: + - Preventive + - Corrective +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: + - Protect + - Respond +operational_capabilities: [Continuity] +security_domains: + - Protection + - Resilience +tags: + - iso27002/2022/EN +status: active +---""", + + "a-5.30-ICT-readiness-for-business-continuity.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.5.30" +title: "ICT readiness for business continuity" +theme: Organizational +control_type: [Corrective] +information_security_properties: [Availability] +cybersecurity_concepts: [Respond] +operational_capabilities: [Continuity] +security_domains: [Resilience] +tags: + - iso27002/2022/EN +status: active +---""", + + "a-5.31-Legal-statutory-regulatory-and-contractual-requirements.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.5.31" +title: "Legal, statutory, regulatory and contractual requirements" +theme: Organizational +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Identify] +operational_capabilities: [Legal_and_compliance] +security_domains: + - Governance_and_Ecosystem + - Protection +tags: + - iso27002/2022/EN +status: active +---""", + + "a-5.32-Intellectual-property-rights.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.5.32" +title: "Intellectual property rights" +theme: Organizational +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Identify] +operational_capabilities: [Legal_and_compliance] +security_domains: [Governance_and_Ecosystem] +tags: + - iso27002/2022/EN +status: active +---""", + + "a-5.33-Protection-of-records.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.5.33" +title: "Protection of records" +theme: Organizational +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: + - Identify + - Protect +operational_capabilities: + - Legal_and_compliance + - Asset_management + - Information_protection +security_domains: [Defence] +tags: + - iso27002/2022/EN +status: active +---""", + + "a-5.34-Privacy-and-protection-of-PII.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.5.34" +title: "Privacy and protection of PII" +theme: Organizational +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: + - Identify + - Protect +operational_capabilities: + - Information_protection + - Legal_and_compliance +security_domains: [Protection] +tags: + - iso27002/2022/EN +status: active +---""", + + "a-5.35-Independent-review-of-information-security.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.5.35" +title: "Independent review of information security" +theme: Organizational +control_type: + - Preventive + - Corrective +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: + - Identify + - Protect +operational_capabilities: [Information_security_assurance] +security_domains: [Governance_and_Ecosystem] +tags: + - iso27002/2022/EN +status: active +---""", + + "a-5.36-Compliance-with-policies-rules-and-standards-for-information-security.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.5.36" +title: "Compliance with policies, rules and standards for information security" +theme: Organizational +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: + - Identify + - Protect +operational_capabilities: + - Legal_and_compliance + - Information_security_assurance +security_domains: [Governance_and_Ecosystem] +tags: + - iso27002/2022/EN +status: active +---""", + + "a-5.37-Documented-operating-procedures.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.5.37" +title: "Documented operating procedures" +theme: Organizational +control_type: + - Preventive + - Corrective +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: + - Protect + - Recover +operational_capabilities: + - Asset_management + - Physical_security + - System_and_network_security + - Application_security + - Secure_configuration + - Identity_and_access_management + - Threat_and_vulnerability_management + - Continuity + - Information_security_event_management +security_domains: + - Governance_and_Ecosystem + - Protection + - Defence +tags: + - iso27002/2022/EN +status: active +---""", + + "a-6.1-Screening.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.6.1" +title: "Screening" +theme: People +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: [Human_resource_security] +security_domains: [Governance_and_Ecosystem] +tags: + - iso27002/2022/EN +status: active +---""", + + "a-6.2-Terms-and-conditions-of-employment.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.6.2" +title: "Terms and conditions of employment" +theme: People +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: [Human_resource_security] +security_domains: [Governance_and_Ecosystem] +tags: + - iso27002/2022/EN +status: active +---""", + + "a-6.3-Information-security-awareness-education-and-training.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.6.3" +title: "Information security awareness, education and training" +theme: People +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: [Human_resource_security] +security_domains: [Governance_and_Ecosystem] +tags: + - iso27002/2022/EN +status: active +---""", + + "a-6.4-Disciplinary-process.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.6.4" +title: "Disciplinary process" +theme: People +control_type: + - Preventive + - Corrective +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: + - Protect + - Respond +operational_capabilities: [Human_resource_security] +security_domains: [Governance_and_Ecosystem] +tags: + - iso27002/2022/EN +status: active +---""", + + "a-6.5-Responsibilities-after-termination-or-change-of-employment.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.6.5" +title: "Responsibilities after termination or change of employment" +theme: People +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: + - Human_resource_security + - Asset_management +security_domains: [Governance_and_Ecosystem] +tags: + - iso27002/2022/EN +status: active +---""", + + "a-6.6-Confidentiality-or-non-disclosure-agreements.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.6.6" +title: "Confidentiality or non-disclosure agreements" +theme: People +control_type: [Preventive] +information_security_properties: [Confidentiality] +cybersecurity_concepts: [Protect] +operational_capabilities: + - Human_resource_security + - Information_protection + - Supplier_relationships_security +security_domains: [Governance_and_Ecosystem] +tags: + - iso27002/2022/EN +status: active +---""", + + "a-6.7-Remote-working.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.6.7" +title: "Remote working" +theme: People +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: + - Asset_management + - Information_protection + - Physical_security + - System_and_network_security +security_domains: [Protection] +tags: + - iso27002/2022/EN +status: active +---""", + + "a-6.8-Information-security-event-reporting.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.6.8" +title: "Information security event reporting" +theme: People +control_type: [Detective] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Detect] +operational_capabilities: [Information_security_event_management] +security_domains: [Defence] +tags: + - iso27002/2022/EN +status: active +---""", + + "a-7.1-Physical-security-perimeters.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.7.1" +title: "Physical security perimeters" +theme: Physical +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: [Physical_security] +security_domains: [Protection] +tags: + - iso27002/2022/EN +status: active +---""", + + "a-7.2-Physical-entry.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.7.2" +title: "Physical entry" +theme: Physical +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: + - Physical_security + - Identity_and_access_management +security_domains: [Protection] +tags: + - iso27002/2022/EN +status: active +---""", + + "a-7.3-Securing-offices-rooms-and-facilities.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.7.3" +title: "Securing offices, rooms and facilities" +theme: Physical +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: + - Physical_security + - Asset_management +security_domains: [Protection] +tags: + - iso27002/2022/EN +status: active +---""", + + "a-7.4-Physical-security-monitoring.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.7.4" +title: "Physical security monitoring" +theme: Physical +control_type: + - Preventive + - Detective +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: + - Protect + - Detect +operational_capabilities: [Physical_security] +security_domains: + - Protection + - Defence +tags: + - iso27002/2022/EN +status: active +---""", + + "a-7.5-Protecting-against-physical-and-environmental-threats.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.7.5" +title: "Protecting against physical and environmental threats" +theme: Physical +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: [Physical_security] +security_domains: [Protection] +tags: + - iso27002/2022/EN +status: active +---""", + + "a-7.6-Working-in-secure-areas.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.7.6" +title: "Working in secure areas" +theme: Physical +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: [Physical_security] +security_domains: [Protection] +tags: + - iso27002/2022/EN +status: active +---""", + + "a-7.7-Clear-desk-and-clear-screen.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.7.7" +title: "Clear desk and clear screen" +theme: Physical +control_type: [Preventive] +information_security_properties: [Confidentiality] +cybersecurity_concepts: [Protect] +operational_capabilities: [Physical_security] +security_domains: [Protection] +tags: + - iso27002/2022/EN +status: active +---""", + + "a-7.8-Equipment-siting-and-protection.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.7.8" +title: "Equipment siting and protection" +theme: Physical +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: + - Physical_security + - Asset_management +security_domains: [Protection] +tags: + - iso27002/2022/EN +status: active +---""", + + "a-7.9-Security-of-assets-off-premises.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.7.9" +title: "Security of assets off-premises" +theme: Physical +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: + - Physical_security + - Asset_management +security_domains: [Protection] +tags: + - iso27002/2022/EN +status: active +---""", + + "a-7.10-Storage-media.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.7.10" +title: "Storage media" +theme: Physical +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: + - Physical_security + - Asset_management +security_domains: [Protection] +tags: + - iso27002/2022/EN +status: active +---""", + + "a-7.11-Supporting-utilities.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.7.11" +title: "Supporting utilities" +theme: Physical +control_type: + - Preventive + - Detective +information_security_properties: + - Integrity + - Availability +cybersecurity_concepts: + - Protect + - Detect +operational_capabilities: [Physical_security] +security_domains: [Protection] +tags: + - iso27002/2022/EN +status: active +---""", + + "a-7.12-Cabling-security.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.7.12" +title: "Cabling security" +theme: Physical +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: [Physical_security] +security_domains: [Protection] +tags: + - iso27002/2022/EN +status: active +---""", + + "a-7.13-Equipment-maintenance.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.7.13" +title: "Equipment maintenance" +theme: Physical +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: + - Physical_security + - Asset_management +security_domains: + - Protection + - Resilience +tags: + - iso27002/2022/EN +status: active +---""", + + "a-7.14-Secure-disposal-or-re-use-of-equipment.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.7.14" +title: "Secure disposal or re-use of equipment" +theme: Physical +control_type: [Preventive] +information_security_properties: [Confidentiality] +cybersecurity_concepts: [Protect] +operational_capabilities: + - Physical_security + - Asset_management +security_domains: [Protection] +tags: + - iso27002/2022/EN +status: active +---""", + + "a-8.1-User-endpoint-devices.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.8.1" +title: "User endpoint devices" +theme: Technological +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: + - Asset_management + - Information_protection +security_domains: [Protection] +tags: + - iso27002/2022/EN +status: active +---""", + + "a-8.2-Privileged-access-rights.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.8.2" +title: "Privileged access rights" +theme: Technological +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: [Identity_and_access_management] +security_domains: [Protection] +tags: + - iso27002/2022/EN +status: active +---""", + + "a-8.3-Information-access-restriction.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.8.3" +title: "Information access restriction" +theme: Technological +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: [Identity_and_access_management] +security_domains: [Protection] +tags: + - iso27002/2022/EN +status: active +---""", + + "a-8.4-Access-to-source-code.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.8.4" +title: "Access to source code" +theme: Technological +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: + - Identity_and_access_management + - Application_security + - Secure_configuration +security_domains: [Protection] +tags: + - iso27002/2022/EN +status: active +---""", + + "a-8.5-Secure-authentication.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.8.5" +title: "Secure authentication" +theme: Technological +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: [Identity_and_access_management] +security_domains: [Protection] +tags: + - iso27002/2022/EN +status: active +---""", + + "a-8.6-Capacity-management.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.8.6" +title: "Capacity management" +theme: Technological +control_type: + - Preventive + - Detective +information_security_properties: + - Integrity + - Availability +cybersecurity_concepts: + - Identify + - Protect + - Detect +operational_capabilities: [Continuity] +security_domains: + - Governance_and_Ecosystem + - Protection +tags: + - iso27002/2022/EN +status: active +---""", + + "a-8.7-Protection-against-malware.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.8.7" +title: "Protection against malware" +theme: Technological +control_type: + - Preventive + - Detective + - Corrective +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: + - Protect + - Detect +operational_capabilities: + - System_and_network_security + - Information_protection +security_domains: + - Protection + - Defence +tags: + - iso27002/2022/EN +status: active +---""", + + "a-8.8-Management-of-technical-vulnerabilities.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.8.8" +title: "Management of technical vulnerabilities" +theme: Technological +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: + - Identify + - Protect +operational_capabilities: [Threat_and_vulnerability_management] +security_domains: + - Governance_and_Ecosystem + - Protection + - Defence +tags: + - iso27002/2022/EN +status: active +---""", + + "a-8.9-Configuration-management.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.8.9" +title: "Configuration management" +theme: Technological +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: [Secure_configuration] +security_domains: [Protection] +tags: + - iso27002/2022/EN +status: active +---""", + + "a-8.10-Information-deletion.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.8.10" +title: "Information deletion" +theme: Technological +control_type: [Preventive] +information_security_properties: [Confidentiality] +cybersecurity_concepts: [Protect] +operational_capabilities: + - Information_protection + - Legal_and_compliance +security_domains: [Protection] +tags: + - iso27002/2022/EN +status: active +---""", + + "a-8.11-Data-masking.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.8.11" +title: "Data masking" +theme: Technological +control_type: [Preventive] +information_security_properties: [Confidentiality] +cybersecurity_concepts: [Protect] +operational_capabilities: [Information_protection] +security_domains: [Protection] +tags: + - iso27002/2022/EN +status: active +---""", + + "a-8.12-Data-leakage-prevention.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.8.12" +title: "Data leakage prevention" +theme: Technological +control_type: + - Preventive + - Detective +information_security_properties: [Confidentiality] +cybersecurity_concepts: + - Protect + - Detect +operational_capabilities: [Information_protection] +security_domains: + - Protection + - Defence +tags: + - iso27002/2022/EN +status: active +---""", + + "a-8.13-Information-backup.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.8.13" +title: "Information backup" +theme: Technological +control_type: [Corrective] +information_security_properties: + - Integrity + - Availability +cybersecurity_concepts: [Recover] +operational_capabilities: [Continuity] +security_domains: [Protection] +tags: + - iso27002/2022/EN +status: active +---""", + + "a-8.14-Redundancy-of-information-processing-facilities.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.8.14" +title: "Redundancy of information processing facilities" +theme: Technological +control_type: [Preventive] +information_security_properties: [Availability] +cybersecurity_concepts: [Protect] +operational_capabilities: + - Continuity + - Asset_management +security_domains: + - Protection + - Resilience +tags: + - iso27002/2022/EN +status: active +---""", + + "a-8.15-Logging.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.8.15" +title: "Logging" +theme: Technological +control_type: [Detective] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Detect] +operational_capabilities: [Information_security_event_management] +security_domains: + - Protection + - Defence +tags: + - iso27002/2022/EN +status: active +---""", + + "a-8.16-Monitoring-activities.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.8.16" +title: "Monitoring activities" +theme: Technological +control_type: + - Detective + - Corrective +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: + - Detect + - Respond +operational_capabilities: [Information_security_event_management] +security_domains: [Defence] +tags: + - iso27002/2022/EN +status: active +---""", + + "a-8.17-Clock-synchronization.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.8.17" +title: "Clock synchronization" +theme: Technological +control_type: [Detective] +information_security_properties: [Integrity] +cybersecurity_concepts: + - Protect + - Detect +operational_capabilities: [Information_security_event_management] +security_domains: + - Protection + - Defence +tags: + - iso27002/2022/EN +status: active +---""", + + "a-8.18-Use-of-privileged-utility-programs.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.8.18" +title: "Use of privileged utility programs" +theme: Technological +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: + - System_and_network_security + - Secure_configuration + - Application_security +security_domains: [Protection] +tags: + - iso27002/2022/EN +status: active +---""", + + "a-8.19-Installation-of-software-on-operational-systems.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.8.19" +title: "Installation of software on operational systems" +theme: Technological +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: + - Secure_configuration + - Application_security +security_domains: [Protection] +tags: + - iso27002/2022/EN +status: active +---""", + + "a-8.20-Networks-security.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.8.20" +title: "Networks security" +theme: Technological +control_type: + - Preventive + - Detective +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: + - Protect + - Detect +operational_capabilities: [System_and_network_security] +security_domains: [Protection] +tags: + - iso27002/2022/EN +status: active +---""", + + "a-8.21-Security-of-network-services.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.8.21" +title: "Security of network services" +theme: Technological +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: [System_and_network_security] +security_domains: [Protection] +tags: + - iso27002/2022/EN +status: active +---""", + + "a-8.22-Segregation-of-networks.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.8.22" +title: "Segregation of networks" +theme: Technological +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: [System_and_network_security] +security_domains: [Protection] +tags: + - iso27002/2022/EN +status: active +---""", + + "a-8.23-Web-filtering.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.8.23" +title: "Web filtering" +theme: Technological +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: [System_and_network_security] +security_domains: [Protection] +tags: + - iso27002/2022/EN +status: active +---""", + + "a-8.24-Use-of-cryptography.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.8.24" +title: "Use of cryptography" +theme: Technological +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: [Secure_configuration] +security_domains: [Protection] +tags: + - iso27002/2022/EN +status: active +---""", + + "a-8.25-Secure-development-life-cycle.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.8.25" +title: "Secure development life cycle" +theme: Technological +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: + - Application_security + - System_and_network_security +security_domains: [Protection] +tags: + - iso27002/2022/EN +status: active +---""", + + "a-8.26-Application-security-requirements.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.8.26" +title: "Application security requirements" +theme: Technological +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: + - Application_security + - System_and_network_security +security_domains: + - Protection + - Defence +tags: + - iso27002/2022/EN +status: active +---""", + + "a-8.27-Secure-system-architecture-and-engineering-principles.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.8.27" +title: "Secure system architecture and engineering principles" +theme: Technological +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: + - Application_security + - System_and_network_security +security_domains: [Protection] +tags: + - iso27002/2022/EN +status: active +---""", + + "a-8.28-Secure-coding.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.8.28" +title: "Secure coding" +theme: Technological +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: + - Application_security + - System_and_network_security +security_domains: [Protection] +tags: + - iso27002/2022/EN +status: active +---""", + + "a-8.29-Security-testing-in-development-and-acceptance.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.8.29" +title: "Security testing in development and acceptance" +theme: Technological +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Identify] +operational_capabilities: + - Application_security + - Information_security_assurance + - System_and_network_security +security_domains: [Protection] +tags: + - iso27002/2022/EN +status: active +---""", + + "a-8.30-Outsourced-development.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.8.30" +title: "Outsourced development" +theme: Technological +control_type: + - Preventive + - Detective +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: + - Identify + - Protect + - Detect +operational_capabilities: + - System_and_network_security + - Application_security + - Supplier_relationships_security +security_domains: + - Governance_and_Ecosystem + - Protection +tags: + - iso27002/2022/EN +status: active +---""", + + "a-8.31-Separation-of-development-test-and-production-environments.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.8.31" +title: "Separation of development, test and production environments" +theme: Technological +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: + - Application_security + - System_and_network_security +security_domains: [Protection] +tags: + - iso27002/2022/EN +status: active +---""", + + "a-8.32-Change-management.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.8.32" +title: "Change management" +theme: Technological +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: + - Application_security + - System_and_network_security +security_domains: [Protection] +tags: + - iso27002/2022/EN +status: active +---""", + + "a-8.33-Test-information.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.8.33" +title: "Test information" +theme: Technological +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity +cybersecurity_concepts: [Protect] +operational_capabilities: [Information_protection] +security_domains: [Protection] +tags: + - iso27002/2022/EN +status: active +---""", + + "a-8.34-Protection-of-information-systems-during-audit-testing.md": """--- +notetype: sourcetext +standard: ISO 27002 +version: 2022 +language: EN +type: control +id: "A.8.34" +title: "Protection of information systems during audit testing" +theme: Technological +control_type: [Preventive] +information_security_properties: + - Confidentiality + - Integrity + - Availability +cybersecurity_concepts: [Protect] +operational_capabilities: + - System_and_network_security + - Information_protection +security_domains: + - Governance_and_Ecosystem + - Protection +tags: + - iso27002/2022/EN +status: active +---""", +} + + +def main(): + written = [] + skipped_fm = [] + skipped_missing = [] + errors = [] + + for filename, frontmatter in sorted(FRONTMATTER.items()): + filepath = os.path.join(VAULT_DIR, filename) + + if not os.path.exists(filepath): + skipped_missing.append(filename) + continue + + with open(filepath, "r", encoding="utf-8") as f: + content = f.read() + + if content.startswith("---"): + skipped_fm.append(filename) + continue + + new_content = frontmatter + "\n\n" + content + + with open(filepath, "w", encoding="utf-8") as f: + f.write(new_content) + + written.append(filename) + + print(f"Written: {len(written)}") + print(f"Already had FM: {len(skipped_fm)}") + print(f"File not found: {len(skipped_missing)}") + print(f"Errors: {len(errors)}") + + if skipped_fm: + print("\nAlready had frontmatter (skipped):") + for f in skipped_fm: + print(f" {f}") + if skipped_missing: + print("\nNot found (skipped):") + for f in skipped_missing: + print(f" {f}") + if errors: + print("\nErrors:") + for e in errors: + print(f" {e}") + + +if __name__ == "__main__": + main() \ No newline at end of file