Took copyrighted material out of the GIS repo

This commit is contained in:
Richard Kranendonk 2026-04-19 19:05:10 +02:00
parent f53af4b9e0
commit 3ea4d4fbb0
345 changed files with 12578 additions and 0 deletions

View file

@ -0,0 +1,12 @@
#iso27002/2022/EN
Change Management in ISO 27002:
- [[ISO_27002_2022_5.8_MoC Information security in project management|5.8:]] Information security in project management
- [[ISO_27002_2022_5.22_MoC Monitoring, review and change management of supplier services|5.22:]] Monitoring, review and change management of supplier services
- [[ISO_27002_2022_8.28_MoC Secure coding|8.28:]] Secure coding
- [[ISO_27002_2022_8.29_MoC Security testing in development and acceptance|8.29:]] Security testing in development and acceptance
- [[ISO_27002_2022_8.32_MoC Change management|8.32:]] Change management
Also check the topic of risk / impact assessment.
5796×3260

View file

@ -0,0 +1,56 @@
# ISO 27002 Themes and Attributes
## Themes
In ISO 27002, controls are categorized into four main themes:
* **Organizational** (Clause 5)
* **People** (Clause 6)
* **Physical** (Clause 7)
* **Technological** (Clause 8)
## Attributes
Every control is associated with five attributes, which allow organizations to view and categorize the controls from different perspectives. The attributes and their possible values are:
**1. Control Type**
Views controls from the perspective of when and how the control modifies risk regarding the occurrence of an information security incident.
* Preventive
* Detective
* Corrective
**2. Information Security Properties**
Views controls from the perspective of which characteristic of information the control contributes to preserving.
* Confidentiality
* Integrity
* Availability
**3. Cybersecurity Concepts**
Views controls based on their association with the cybersecurity framework concepts defined in ISO/IEC TS 27110.
* Identify
* Protect
* Detect
* Respond
* Recover
**4. Operational Capabilities**
Views controls from the practitioners perspective of information security 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
**5. Security Domains**
Views controls from the perspective of four high-level information security domains.
* Governance_and_Ecosystem
* Protection
* Defence
* Resilience

View file

@ -0,0 +1,23 @@
#iso27001/2022/EN
# Introduction
## 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.
The information security management system preserves the confidentiality, integrity and availability of information by applying a risk management process and gives confidence to interested parties that risks are adequately managed.
It is important that the information security management system is part of and integrated with the organization's processes and overall management structure and that information security is considered in the design of processes, information systems, and controls. It is expected that an information security management system implementation will be scaled in accordance with the needs of the organization.
This document can be used by internal and external parties to assess the organization\'s ability to meet the organization's own information security requirements.
The order in which requirements are presented in this document does not reflect their importance or imply the order in which they are to be implemented. The list items are enumerated for reference purpose only.
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
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.
This common approach defined in the Annex SL will be useful for those organizations that choose to operate a single management system that meets the requirements of two or more management system standards.

View file

@ -0,0 +1,7 @@
#iso27001/2022/EN
# 1 Scope
This document specifies the requirements for establishing, implementing, maintaining and continually improving an information
security management system within the context of the organization. This document also includes requirements for the assessment and treatment of information security risks tailored to the needs of the organization. The requirements set out in this document are generic and are intended to be applicable to all organizations, regardless of type, size or nature. Excluding any of the requirements specified in Clauses 4 to 10 is not acceptable when an organization claims conformity to this document.

View file

@ -0,0 +1,5 @@
#iso27001/2022/EN
# 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.

View file

@ -0,0 +1,6 @@
# 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.
NOTE Determining these issues refers to establishing the external and internal context of the organization considered in [[ISO_31000_OT 5.4.1 Understanding the organization and its context|Clause 5.4.1]] of ISO 31000:2018.

View file

@ -0,0 +1,12 @@
#iso27001/2022/EN
# 4.2 Understanding the needs and expectations of interested parties
The organization shall determine:
a\) interested parties that are relevant to the information security management system;
b\) the relevant requirements of these interested parties;
c\) which of these requirements will be addressed through the information security management system.
NOTE The requirements of interested parties can include legal and regulatory requirements and contractual obligations.

View file

@ -0,0 +1,14 @@
#iso27001/2022/EN
# 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.
When determining this scope, the organization shall consider:
a\) the external and internal issues referred to in [[ISO_27001_2022_OT 4.1 Understanding the organization and its context|4.1]];
b\) the requirements referred to in [[ISO_27001_2022_4.2_MoC Understanding the needs and expectations of interested parties|4.2]];
c\) interfaces and dependencies between activities performed by the organization, and those that are performed by other organizations.
The scope shall be available as documented information.

View file

@ -0,0 +1,4 @@
#iso27001/2022/EN
# 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.

View file

@ -0,0 +1,22 @@
#iso27001/2022/EN
## 5.1 Leadership and commitment
Top management shall demonstrate leadership and commitment with respect to the information security management system by:
a\) ensuring the information security policy and the information security objectives are established and are compatible with the strategic direction of the organization;
b\) ensuring the integration of the information security management system requirements into the organization's processes;
c\) ensuring that the resources needed for the information security management system are available;
d\) communicating the importance of effective information security management and of conforming to the information security management system requirements;
e\) ensuring that the information security management system achieves its intended outcome(s);
f\) directing and supporting persons to contribute to the effectiveness of the information security management system;
g\) promoting continual improvement; and
h\) supporting other relevant management roles to demonstrate their leadership as it applies to their areas of responsibility.
NOTE Reference to "business" in this document can be interpreted broadly to mean those activities that are core to the purposes of the organization's existence.

View file

@ -0,0 +1,18 @@
#iso27001/2022/EN
## 5.2 Policy
Top management shall establish an information security policy that:
a\) is appropriate to the purpose of the organization;
b\) includes information security objectives (see [[ISO_27001_OT 6.2 Information security objectives and planning to achieve them|6.2]]) or provides the framework for setting information security objectives;
c\) includes a commitment to satisfy applicable requirements related to information security;
d\) includes a commitment to continual improvement of the information security management system. The information security policy shall:
e\) be available as documented information;
f\) be communicated within the organization;
g\) be available to interested parties, as appropriate.

View file

@ -0,0 +1,12 @@
#iso27001/2022/EN
## 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.
Top management shall assign the responsibility and authority for:
a\) ensuring that the information security management system conforms to the requirements of this document;
b\) reporting on the performance of the information security management system to top management.
NOTE Top management can also assign responsibilities and authorities for reporting performance of the information security management system within the organization.

View file

@ -0,0 +1,4 @@
#iso27001/2022/EN
## 10.1 Continual improvement
The organization shall continually improve the suitability, adequacy and effectiveness of the information security management system.

View file

@ -0,0 +1,29 @@
#iso27001/2022/EN
## 10.2 Nonconformity and corrective action
When a nonconformity occurs, the organization shall:
a\) react to the nonconformity, and as applicable:
1\) take action to control and correct it;
2\) deal with the consequences;
b\) evaluate the need for action to eliminate the causes of nonconformity, in order that it does not recur or occur elsewhere, by:
1\) reviewing the nonconformity;
2\) determining the causes of the nonconformity; and
3\) determining if similar nonconformities exist, or could potentially occur;
c\) implement any action needed;
d\) review the effectiveness of any corrective action taken; and
e\) make changes to the information security management system, if necessary.
Corrective actions shall be appropriate to the effects of the nonconformities encountered.
Documented information shall be available as evidence of:
f\) the nature of the nonconformities and any subsequent actions taken,
g\) the results of any corrective action.

View file

@ -0,0 +1,18 @@
### 6.1.1 General
When planning for the information security management system, the organization shall consider the issues referred to in [[ISO_27001_2022_OT 4.1 Understanding the organization and its context|4.1]] and the requirements referred to in [[ISO_27001_2022_OT 4.2 Understanding the needs and expectations of interested parties|4.2]] and determine the risks and opportunities that need to be addressed to:
a\) ensure the information security management system can achieve its intended outcome(s);
b\) prevent, or reduce, undesired effects;
c\) achieve continual improvement.
The organization shall plan:
d\) actions to address these risks and opportunities; and
e\) how to
1\) integrate and implement the actions into its information security management system processes; and
2\) evaluate the effectiveness of these actions.

View file

@ -0,0 +1,24 @@
### 6.1.2 Information security risk assessment
The organization shall define and apply an information security risk assessment process that:
a\) establishes and maintains information security risk criteria that include:
1\) the risk acceptance criteria; and
2\) criteria for performing information security risk assessments;
b\) ensures that repeated information security risk assessments produce consistent, valid and comparable results;
c\) identifies the information security risks:
1\) apply the information security risk assessment process to identify risks associated with the loss of confidentiality, integrity and availability for information within the scope of the information security management system; and
2\) identify the risk owners;
d\) analyses the information security risks:
1\) assess the potential consequences that would result if the risks identified in 6.1.2 c)1) were to materialize;
2\) assess the realistic likelihood of the occurrence of the risks identified in 6.1.2 c)1) ; and
3\) determine the levels of risk;
e\) evaluates the information security risks:
1\) compare the results of risk analysis with the risk criteria established in 6.1.2 a); and
2\) prioritize the analysed risks for risk treatment.
The organization shall retain documented information about the information security risk assessment process.

View file

@ -0,0 +1,29 @@
### 6.1.3 Information security risk treatment
The organization shall define and apply an information security risk treatment process to:
a\) select appropriate information security risk treatment options, taking account of the risk assessment results;
b) determine all controls that are necessary to implement the information security risk treatment option(s) chosen;
c\) compare the controls determined in 6.1.3b above with those in [Annex A] and verify that no necessary controls have been omitted;
NOTE 1 Organizations can design controls as required, or identify them from any source.
NOTE 2 [Annex A] contains a list of possible information security controls. Users of this document are directed to [Annex A] to ensure that no necessary information security controls are overlooked.
NOTE 3 The information security controls listed in [Annex A] are not exhaustive and additional information security controls can be included if needed.
d\) produce a Statement of Applicability that contains:
- the necessary controls (see 6.1.3 b) and c);
- justification for their inclusion;
- whether the necessary controls are implemented or not; and
- the justification for excluding any of the [Annex A] controls.
e\) formulate an information security risk treatment plan; and
f\) obtain risk owners' approval of the information security risk treatment plan and acceptance of the residual information security risks.
The organization shall retain documented information about the information security risk treatment process.
NOTE 4 The information security risk assessment and treatment process in this document aligns with the principles and generic guidelines provided in ISO 31000.

View file

@ -0,0 +1,34 @@
#iso27001/2022/EN
## 6.2 Information security objectives and planning to achieve them
The organization shall establish information security objectives at relevant functions and levels.
The information security objectives shall:
a\) be consistent with the information security policy;
b\) be measurable (if practicable);
c\) take into account applicable information security requirements, and results from risk assessment and risk treatment;
d\) be monitored;
e\) be communicated;
f\) be updated as appropriate;
g\) be available as documented information.
The organization shall retain documented information on the information security objectives.
When planning how to achieve its information security objectives, the organization shall determine:
h\) what will be done;
i\) what resources will be required;
j\) who will be responsible;
k\) when it will be completed; and
l\) how the results will be evaluated.

View file

@ -0,0 +1,4 @@
#iso27001/2022/EN
## 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.

View file

@ -0,0 +1,4 @@
#iso27001/2022/EN
## 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.

View file

@ -0,0 +1,15 @@
#iso27001/2022/EN
## 7.2 Competence
The organization shall:
a\) determine the necessary competence of person(s) doing work under its control that affects its information security performance;
b\) ensure that these persons are competent on the basis of appropriate education, training, or experience;
c\) where applicable, take actions to acquire the necessary competence, and evaluate the effectiveness of the actions taken; and
d\) retain appropriate documented information as evidence of competence.
NOTE Applicable actions can include, for example: the provision of training to, the mentoring of, or the re-assignment of current employees; or the hiring or contracting of competent persons.

View file

@ -0,0 +1,11 @@
#iso27001/2022/EN
## 7.3 Awareness
Persons doing work under the organization's control shall be aware of:
a\) the information security policy;
b\) their contribution to the effectiveness of the information security management system, including the benefits of improved information security performance; and
c\) the implications of not conforming with the information security management system requirements.

View file

@ -0,0 +1,13 @@
#iso27001/2022/EN
## 7.4 Communication
The organization shall determine the need for internal and external communications relevant to the information security management system including:
a\) on what to communicate;
b\) when to communicate;
c\) with whom to communicate;
d\) how to communicate.

View file

@ -0,0 +1,47 @@
#iso27001/2022/EN
## 7.5 Documented information
### 7.5.1 General
The organization's information security management system shall include:
a\) documented information required by this document; and
b\) documented information determined by the organization as being necessary for the effectiveness of the information security management system.
NOTE The extent of documented information for an information security management system can differ from one organization to another due to:
1\) the size of organization and its type of activities, processes, products and services;
2\) the complexity of processes and their interactions; and
3\) the competence of persons.
### 7.5.2 Creating and updating
When creating and updating documented information the organization shall ensure appropriate:
a\) identification and description (e.g. a title, date, author, or reference number);
b\) format (e.g. language, software version, graphics) and media (e.g. paper, electronic); and
c\) review and approval for suitability and adequacy.
### 7.5.3 Control of documented information
Documented information required by the information security management system and by this document shall be controlled to ensure:
a\) it is available and suitable for use, where and when it is needed; and
b\) it is adequately protected (e.g. from loss of confidentiality, improper use, or loss of integrity).
For the control of documented information, the organization shall address the following activities, as applicable:
c\) distribution, access, retrieval and use;
d\) storage and preservation, including the preservation of legibility;
e\) control of changes (e.g. version control); and
f\) retention and disposition.
Documented information of external origin, determined by the organization to be necessary for the planning and operation of the information security management system, shall be identified as appropriate, and controlled.
NOTE Access can imply a decision regarding the permission to view the documented information only, or the permission and authority to view and change the documented information, etc.

View file

@ -0,0 +1,12 @@
#iso27001/2022/EN
## 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:
- establishing criteria for the processes;
- implementing control of the processes in accordance with the criteria.
Documented information shall be available to the extent necessary to have confidence that the processes have been carried out as planned.
The organization shall control planned changes and review the consequences of unintended changes, taking action to mitigate any adverse effects, as necessary.
The organization shall ensure that externally provided processes, products or services that are relevant to the information security management system are controlled.

View file

@ -0,0 +1,6 @@
#iso27001/2022/EN
# Clause 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 [[ISO_27001_OT 6.1.2 Information security risk assessment|6.1.2a]].
The organization shall retain documented information of the results of the information security risk assessments.

View file

@ -0,0 +1,9 @@
---
tags:
- iso27001/2022/EN
---
# Clause 8.3 Information security risk treatment
The organization shall implement the information security risk treatment plan.
The organization shall retain documented information of the results of the information security risk treatment.

View file

@ -0,0 +1,20 @@
#iso27001/2022/EN
## 9.1 Monitoring, measurement, analysis and evaluation
The organization shall determine:
a\) what needs to be monitored and measured, including information security processes and controls;
b\) the methods for monitoring, measurement, analysis and evaluation, as applicable, to ensure valid results. The methods selected should produce comparable and reproducible results to be considered valid;
c\) when the monitoring and measuring shall be performed;
d\) who shall monitor and measure;
e\) when the results from monitoring and measurement shall be analysed and evaluated;
f\) who shall analyse and evaluate these results.
Documented information shall be available as evidence of the results.
The organization shall evaluate the information security performance and the effectiveness of the information security management system.

View file

@ -0,0 +1,28 @@
#iso27001/2022/EN
## 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:
a\) conforms to
1\) the organization's own requirements for its information security management system;
2\) the requirements of this document;
b\) is effectively implemented and maintained.
### 9.2.2 Internal audit programme
The organization shall plan, establish, implement and maintain an audit programme(s), including the frequency, methods, responsibilities, planning requirements and reporting.
When establishing the internal audit programme(s), the organization shall consider the importance of the processes concerned and the results of previous audits.
The organization shall:
a\) define the audit criteria and scope for each audit;
b\) select auditors and conduct audits that ensure objectivity and the impartiality of the audit process;
c\) ensure that the results of the audits are reported to relevant management;
Documented information shall be available as evidence of the implementation of the audit programme(s) and the audit results.

View file

@ -0,0 +1,34 @@
#iso27001/2022/EN
## 9.3 Management review
### 9.3.1 General
Top management shall review the organization\'s information security management system at planned intervals to ensure its continuing suitability, adequacy and effectiveness.
### 9.3.2 Management review inputs
The management review shall include consideration of:
a\) the status of actions from previous management reviews;
b\) changes in external and internal issues that are relevant to the information security management system;
c\) changes in needs and expectations of interested parties that are relevant to the information security management system;
d\) feedback on the information security performance, including trends in:
1\) nonconformities and corrective actions;
2\) monitoring and measurement results;
3\) audit results;
4\) fulfilment of information security objectives;
e\) feedback from interested parties;
f\) results of risk assessment and status of risk treatment plan;
g\) opportunities for continual improvement.
### 9.3.3 Management review results
The results of the management review shall include decisions related to continual improvement opportunities and any needs for changes to the information security management system.
Documented information shall be available as evidence of the results of management reviews.

View file

@ -0,0 +1,22 @@
#iso27001/2022/EN
# 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.
The procedures used to develop this document and those intended for its further maintenance are described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the different types of document should be noted. This document was drafted in accordance with the editorial rules of the ISO/IEC Directives, Part 2 (see [www.iso.org/directives] or [www.iec.ch/members_experts/refdocs]).
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights. Details of any patent rights identified during the development of the document will be in the Introduction and/or on the ISO list of patent declarations received (see [www.iso.org/patents]) or the IEC list of patent declarations received (see [https://patents.iec.ch]).
Any trade name used in this document is information given for the convenience of users and does not constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions related to conformity assessment, as well as information about ISO's adherence to the World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT) see [[www.iso.org/iso/foreword.html]](https://www.iso.org/iso/foreword.html). In the IEC, see [www.iec.ch/understanding-standards].
This document was prepared by Joint Technical Committee ISO/IEC JTC 1, *Information Technology*, Subcommittee SC 27, *Information security, cybersecurity and privacy protection*.
This third edition cancels and replaces the second edition (ISO/IEC 27001:2013), which has been technically revised. It also incorporates the Technical Corrigenda ISO/IEC 27001:2013/Cor 1:2014 and ISO/IEC 27001:2013/Cor 2:2015.
The main changes are as follows:
- the text has been aligned with the harmonized structure for management system standards and ISO/IEC 27002:2022.
Any feedback or questions on this document should be directed to the user's national standards body. A complete listing of these bodies can be found at [www.iso.org/members.html] and [[www.iec.ch/national-committees]](https://www.iec.ch/national-committees).

View file

@ -0,0 +1,8 @@
#iso27001/2022/EN
# 3 Terms and definitions
For the purposes of this document, the terms and definitions given in
ISO/IEC 27000 apply.
[[ISO 27000 MoC]]

View file

@ -0,0 +1,223 @@
#iso27001/2023/NL
# ISMS op hoofdlijnen
Een informatiebeveiligingsbeleid moet de hieronder genoemde punten adresseren.
_De nummering verwijst naar de hoofdstukken/paragrafen uit ISO 27001:2023_
**H4              Context van de organisatie**
H4.1         Relevante punten (intern en extern) die invloed kunnen hebben op het kunnen behalen van de doelstellingen m.b.t. informatiebeveiliging
Voorwaarde: formuleren doelstellingen m.b.t. informatiebeveiliging
H4.2         Relevante stakeholders en hun eisen, en welke hiervan geadresseerd zullen worden (binnen het domein informatiebeveiliging)
H4.3         Begrenzing en toepasselijkheid van het managementsysteem voor informatiebeveiliging, rekening houdend met H4.1, H4.2 en de raakvlakken met en afhankelijkheden van andere organisaties.
H4.4         Er moet een managementsysteem voor informatiebeveiliging worden ingericht, geïmplementeerd, onderhouden en verbeterd worden incl. benodigde processen.
**H5              Leiderschap**
H5.1         Het topmanagement moet leiderschap en betrokkenheid tonen door:
a)         doelen en beleid voor informatiebeveiliging vast te stellen, dat compatibel is met de strategische richting van de organisatie
Voorwaarde: strategie moet bekend zijn
b)        integratie van het informatiebeveiligingsmanagement in de processen van de organisatie
c)         beschikbaar stellen benodigde middelen
d)        communiceren van het belang en noodzaak van informatiebeveiligingsmanagement en de daaruit volgende eisen
e)         zorgen dat de doelstellingen/resultaten behaald worden
f)           mensen aansturen en ondersteunen om hun bijdrage te leveren
g)         bevorderen van continue verbetering
h)        ondersteunen van anderen bij de invulling van hun leiderschap
H.5.2        Het topmanagement moet een informatiebeveiligingsbeleid vaststellen dat:
a)         passend is voor het doel van de organisatie
b)        doelstellingen bevat, of een kader om die vast te stellen (zie 6.2)
c)         zich committeren aan het voldoen aan de gedefinieerde eisen
d)        zich committeren aan continue verbetering
e)         het beleid moet beschikbaar zijn
f)          het beleid moet gecommuniceerd worden
g)         het beleid moet beschikbaar zijn voor belanghebbenden
H5.3         Het topmanagement moet rollen, verantwoordelijkheden en bevoegdheden toekennen en communiceren, om:
a)         het managementsysteem voor informatiebeveiliging te laten voldoen aan de vastgestelde eisen (i.e. ISO 27001)
b)        te rapporteren over de prestaties van het managementsysteem voor informatiebeveiliging aan het topmanagement
**H6                  Planning**
_H6.1             Risicos en kansen_
H6.1.1        Risicos en kansen moeten vastgesteld en geadresseerd worden (met overweging van de issues en eisen uit 4.1 en 4.2), om:
a)           te zorgen dat de beoogde resultaten behaald worden (zie H51a en H5.2b)
b)           ongewenste effecten te voorkomen of te verminderen;
c)            continue verbetering te bereiken.
Acties om die risicos en kansen op te pakken moeten:
d)           gepland worden
e)            volgens een beschreven proces worden geïntegreerd, geïmplementeerd, en geëvalueerd (op doeltreffendheid)
H6.1.2        Er moet een procedure voor risicobeoordeling zijn die:
a)        criteria voor risicoacceptatie en het uitvoeren van risicobeoordelingen bevat
b)        herhaalbaar is (consistent)
c)         risicos voor vertrouwelijkheid, integriteit en beschikbaarheid identificeert en risico-eigenaren aanwijst
d)        van risicos de impact, waarschijnlijkheid en risicoscore (R = P x I) beoordeelt
e)         de risicos evalueert t.o.v. de criteria (a) en een prioriteit toekent.
H6.1.3        Er moet een procedure zijn voor risicobehandeling om:
a)        passende opties voor behandeling te benoemen, o.b.v. de risicobeoordeling
b)        de nodige maatregelen vast te stellen
c)         de vastgestelde maatregelen te vergelijken met de maatregelen in ISO 27001 Annex A.
d)        een _verklaring van toepasselijkheid_ op te stellen met de maatregelen uit b), de rechtvaardiging daarvan, en of deze maatregelen geïmplementeerd zijn, en een rechtvaardigen voor het niet toepassen van specifieke maatregelen uit Annex A.
e)         een plan op te stellen voor de behandeling van risicos
f)           de goedkeuring te krijgen van de risico-eigenaren voor die behandeling en de acceptatie van de restrisicos.
_H6.2             Doelstellingen en planning (aanpak)_
Per functie en niveau moeten doelstellingen vastgesteld worden, die consistent en meetbaar zijn, en rekening houden met gestelde eisen en de resultaten van de risicobeoordeling en -behandeling.
De doelstellingen moeten worden gemonitord, gecommuniceerd, geactualiseerd, en gedocumenteerd.
De planningen moeten beschrijven wat er zal worden gedaan, welke middelen nodig zijn, wie verantwoordelijk is, wanneer het voltooid zal zijn, en hoe de resultaten worden geëvalueerd.
H8 behandelt de uitvoering van deze planningen.
_H6.3             Wijzigingen_
Wijzigingen in het managementsysteem moeten volgens een beschreven werkwijze worden doorgevoerd.
**H7                  Ondersteuning**
Vaststellen welke middelen nodig zijn voor het managementsysteem voor informatiebeveiliging, en deze beschikbaar stellen. Dit betreft de volledige cyclus van inrichten, implementeren, onderhouden en continu verbeteren.
_H7.2             Competenties_
-          Vaststellen van de benodigde competenties van relevante personen
-          Zorgen dat deze personen competent zijn of worden
-          De doeltreffendheid van ondernomen acties hiervoor evalueren
-          Bewijzen van competenties bewaren.
_H7.3             Bewustzijn_
Medewerkers (en ingehuurd personeel) moeten zich bewust zijn van het informatiebeveiligingsbeleid, hun bijdrage aan de doeltreffendheid daarvan en de voordelen die dat oplevert, en de gevolgen van het niet voldoen aan de gestelde eisen.
_H7.4             Communicatie_
Vaststellen van de relevante interne en externe communicatie, met onderwerpen, momenten, doelgroepen en medium.
_H7.5             Documentatie_
Het managementsysteem moet alle documentatie bevatten die vereist is vanuit normen, wet- en regelgeving, plus wat de organisatie zelf nodig vindt voor de doeltreffendheid van het managementsysteem (H7.5.1).
Dit mag in verhouding zijn tot de omvang van de organisatie, de complexiteit van de processen, en de competentie van de mensen.
Voor het creëren en actualiseren moet gezorgd worden voor (H7.5.2):
a)        identificatie en beschrijving (bijv. een titel, datum, auteur of referentienummer);
b)        format (bijv. taal, softwareversie, afbeeldingen) en media (bijv. papier, elektronisch); en
c)         beoordeling en goedkeuring van geschiktheid en toereikendheid.
De documentatie moet beheerd worden zodat (H7.5.3) ze beschikbaar is waar en wanneer dat nodig is, en afdoende beveiligd is.
Dit moet ingevuld worden met activiteiten voor:
-          distributie, vindbaarheid en toegangsverlening
-          opslag en behoud van leesbaarheid
-          wijzigings- en versiebeheer
-          bewaring en vernietiging
**H8                  Uitvoering**
_H8.1             Operationele planning en beheersing_
Er moeten processen geïmplementeerd worden om te voldoen aan vastgestelde eisen, en de in H6 vastgestelde acties uit te voeren.
Er moet voldoende documentatie zijn om vast te stellen dat die processen volgens plan zijn uitgevoerd.
Wijzigingen in die processen moeten planmatig worden uitgevoerd, en de consequenties van onbedoelde wijzigingen (uitzonderingen) moeten beoordeeld worden. Als het nodig is, moeten er maatregelen komen om nadelige effecten tegen te gaan.
Er moeten ook processen zijn voor de beheersing van informatiebeveiliging van extern geleverde processen, producten of diensten.
_H8.2             Risicobeoordelingen_ moeten regelmatig worden uitgevoerd, èn bij belangrijke (interne of externe) veranderingen (volgens de criteria uit H6.1.2a). De resultaten moeten gedocumenteerd worden.
_H8.3_             Vervolgens moet het _Risicobehandelingsplan_ (uit H6.1.3e) geimplementeerd worden. De resultaten moeten gedocumenteerd worden.
**H9                  Evaluatie**
_H9.1             Monitoren, meten, analyseren en evalueren_
De organisatie moet vaststellen wat er gemonitord en gemeten moet worden, hoe dat moet gebeuren (reproduceerbaar en vergelijkbaar), wanneer en door wie dat moet gebeuren, en wanneer en door wie de resultaten worden geanalyseerd en geëvalueerd.
Dit geldt voor de informatiebeveiligingsmaatregelen, en het managementsysteem zelf.
_H9.2             Interne audit_
De organisatie moet met geplande tussenpozen interne audits uitvoeren op het managementsysteem voor informatiebeveiliging:
-          voldoet het aan de eigen eisen?
-          voldoet het aan de norm?
-          is het doeltreffend geïmplementeerd en onderhouden?
Hiervoor moet een auditprogramma worden vastgesteld, inclusief frequentie, methoden, verantwoordelijkheden en rapportage. Resultaten van eerdere audits moeten worden meegenomen.
Audits moeten voldoen aan gestelde criteria en hebben een bepaalde rijkwijdte. Ze moeten objectief worden uitgevoerd. De resultaten moeten aan het relevante management gerapporteerd worden.
_H9.3             Management review_
Het managementsysteem moet met geplande tussenpozen door het topmanagement beoordeeld worden op geschiktheid, toereikendheid en doeltreffendheid.
Als input dienen:
a)        status van acties uit eerdere reviews
b)        wijzigingen in relevante issues (H4.1)
c)         wijzigingen in de behoeften en verwachtingen van de belanghebbenden (H4.2)
d)        feedback over de prestaties van de informatiebeveiliging, incl. _trends_ in afwijkingen en corrigerende maatregelen, resultaten van monitoren en meten, auditresultaten, het voldoen aan doelstellingen;
e)         feedback van belanghebbenden
f)           resultaten van risicobeoordeling en de status van het risicobehandelingsplan
g)         kansen voor continue verbetering.
Resultaten van de review zijn o.a. beslissingen voor continue verbetering en noodzakelijke wijzigingen in het managementsysteem.
**H10              Verbetering**
Er moet een procedure zijn voor de omgang met afwijkingen in (de uitvoering van) het managementsysteem.
De organisatie moet:
a)        reageren op de afwijking: maatregelen treffen om de afwijking  te beheersen, corrigeren, en gevolgen aan te pakken;
b)        bepalen of maatregelen nodig zijn om herhaling te voorkomen (door oorzaken vast te stellen en weg te nemen)
c)         de maatregelen implementeren
d)        de doeltreffendheid daarvan te beoordelen
e)         wijzigingen in het managementsysteem aan te brengen, indien nodig
f)           de aard van de afwijkingen en maatregelen documenteren
g)         de resultaten van de maatregelen documenteren.
VOORBLAD
Document
Doelgroep
Classificatie
Versie
Eigenaar
INLEIDING
Over dit document:
-              Doelgroep
-              Doel
-              Gebaseerd op ISO 27001, organisatie-eigen stukken

View file

@ -0,0 +1,51 @@
#iso27001/2023/NL
## Processen
- Processen om het ISMS zelf te onderhouden
- contextanalyse (H4)
- Risicoanalyse (H6.1), incl. Dreigingsanalyse (A5.7)
- wijzigingen aan het ISMS (H6.3)
- risicobeoordeling en -acceptatie (H6.1.2, H8.2, H8.3)
- documentatie (H7.5)
- evaluatie van het ISMS (H9)
- afwijkingen en verbeteringen (H10)
- rollen en verantwoordelijkheden m.b.t. het ISMS (H5.3)
- Processen om de gekozen maatregelen te onderhouden
- Leveranciersmanagement (H8.1)
- Informatiebeveiliging in projecten (H5.8)
- evaluatie van maatregelen (H9)
- rollen en verantwoordelijkheden m.b.t. de maatregelen (H5.3)
## Te produceren stukken
- Beschrijving relevante issues (intern en extern) (H4.1)
- SWOT-analyse (H6.1)
- Risicoanalyse (H6.1), incl. Dreigingsanalyse (A5.7)
- Stakeholder analyse (H4.2)
- Overzicht wet- en regelgeving (H4.1, H4.2)
- Vaststellen doelen informatiebeveiliging (H5.1a)
- Informatiebeveiligingsbeleid (H5.2)
- Risicoanalyse (H6.1.2)
- Lijst maatregelen (H6.1.3)
- Toegangsbeveiliging informatiesystemen (A5.15)
- Identiteitsbeheer (A5.16)
- Toegangsrechten (A5.18)
- Maatregelen m.b.t. leveranciers (A5.19-A5.23)
- Fysieke toegangsbeveiliging (A7)
- EDM (8.1)
- Backups en redundantie (A8.13, A8.14)
- Logging en Monitoring (A8.15, A8.16)
- Update procedures (A8.19)
- Netwerkbeveiliging (A8.20-A8.23)
- Systeemarchitectuur (A8.27)
- Softwareontwikkeling (A8.25, A8.28-A8.33)
- Incidentenprocedure (A5.24-A5.29)
- Bedrijfscontinuïteitsplan (A5.30)
- Licentiebeheer (A5.32)
- Privacybeleid (A5.34)
- Voorschriften gebruik apparatuur en software (5.37)
- Planning implementatie maatregelen (H8.1)
- Communicatieplan (H7.4)
- Planning van terugkerende taken (evalueren, herzien, bijwerken)
- Asset-inventarisatie (A5.9)
- Classificatie van informatie en assets (A5.12)

View file

@ -0,0 +1,54 @@
#iso27001/2023/NL
# Aanpassingen in ISO 27001:2023
De ISO 27001:2022 is aangepast op de nieuwe HS (Harmonized Structure). Deze wijzigingen zorgen voor een betere aansluiting bij Annex SL.
Diverse punten in de hoofdstukken 4 t/m 10 zijn aangescherpt, toegevoegd, herschreven of gesplitst. Dit zijn de wijzigingen:
## Aanpassingen in het ISMS
- 4.1 Context is aangescherpt
- 4.2 Belanghebbenden is aangescherpt
- 4.4 ISMS is aangescherpt
- 6.1.3 Risicobehandeling is aangescherpt
- 6.2 Doelstellingen is aangescherpt
- 6.3 Verandermanagement is toegevoegd
- 8.1 Operationele planning is herschreven
- 9.1 Monitoring is aangescherpt
- 9.2 Algemeen en Auditprogramma is gesplitst
- 9.3 Algemeen, input en output is gesplitst
- 10.1 Verbeteren en Afwijkingen & Corrigerende maatregelen is aangepast
### Aanpassing aan nieuwe Harmonized Structure
De ISO 27001:2022 is aangepast op de nieuwe Harmonized Structure(HS). Deze HS is in 2021 gepubliceerd en is een update van de High Level Structure(HLS). HS is de basisstructuur van alle ISO managementsysteemnormen. In [dit artikel](https://www.cuccibu.eu/nieuws/de-nieuwe-high-level-structure/) lees je meer over de inhoudelijke veranderingen van HLS naar HS. De HS heeft de volgende impact op ISO 27001:  
- **Wijzigingen in gedocumenteerde informatie**. In de HLS werd verwezen naar verschillende werkwoorden, zoals onderhouden voor documenten en bijhouden voor registraties. Dit zorgde vaak voor verwarring. In de HS is gekozen voor een eenduidige terminologie. Er wordt gesproken over beschikbaar zijn van gedocumenteerde informatie.  
- **Behoeftes en verwachtingen stakeholders belangrijker.** In paragraaf 4.2 van de HLS staat dat een organisatie de relevante eisen van relevante belanghebbende moet identificeren. Hoe een organisatie omgaat met behoeftes en verwachtingen van stakeholders blijft echter onduidelijk. In de HS worden de behoeftes en verwachtingen wel opgenomen. De organisatie moet vaststellen welke belanghebbenden relevant zijn voor het managementsysteem voor informatiebeveiliging, welke eisen deze belanghebbenden stellen én welke van deze eisen zullen worden geadresseerd in het managementsysteem voor informatiebeveiliging. De eisen van belanghebbende kunnen wettelijke en regelgevende eisen, maar ook contractuele verplichtingen omvatten. 
- **Eisen aan de processen van het ISMS.** In de voorgaande versie van ISO 27001 is in paragraaf 4.4 afgeweken van de HLS. Er werden eisen gesteld voor het vaststellen, implementeren, onderhouden en continu verbeteren van het informatiebeveiligingsmanagementsysteem (ISMS). Echter ontbraken de eisen voor en de samenhang met de onderliggende processen. In de herziene versie is deze tekortkoming hersteld en wordt er weer aangesloten bij de HS. Dit bekent meer focus op processen in de ISO 27001:2022. 
- **Plannen van wijzigingen.** In hoofdstuk 6 van de HS is een nieuwe paragraaf opgenomen, namelijk 6.3. Deze paragraaf stelt dat wijzigingen aan het managementsysteem op een geplande manier moeten worden uitgevoerd. Management of change wordt hiermee expliciet onderdeel van de HS. In ISO 27001:2022 is paragraaf 6.3 ook opgenomen.
- **Van uitbesteden naar extern geleverde processen, producten en diensten.** De begrippen uitbesteden en beheersing van uitbestede processen worden niet meer toegepast in de HS. Voortaan worden er eisen gesteld aan de extern geleverde processen, producten en diensten die relevant zijn voor het managementsysteem. Ook de herziene ISO 27001 norm volgt deze benadering
## Nieuwe beheersmaatregelen in Annex A
In de oude norm ISO 27001:2013 waren 114 beheersmaatregelen opgenomen. Een flinke lijst, die in ISO 27001:2022 is ingekort. Er zijn nu 93 beheersmaatregelen. ISO besloot om veel maatregelen samen te voegen waardoor de norm past bij deze tijd. Wel voegde ISO 11 nieuwe beheersmaatregelen toe.
- 5.7 Informatie en analyses over dreigingen:
Informatie met betrekking tot informatiebeveiliging dreigingen moet worden verzameld en geanalyseerd om informatie over dreigingen te produceren.
- 5.23 Informatiebeveiliging voor het gebruik van clouddiensten:
Processen voor het aanschaffen, gebruiken, beheren en beëindigen van clouddiensten behoren overeenkomstig de informatiebeveiligingseisen van de organisatie te worden opgesteld.
- 5.30 ICT-gereedheid voor bedrijfscontinuïteit:
De ICT-gereedheid behoort te worden gepland, geïmplementeerd, onderhouden en getest op basis van bedrijfscontinuïteitsdoelstellingen en ICT-continuïteitseisen.
- 7.4 Monitoren van de fysieke beveiliging:
Het gebouw en terrein behoren voortdurend te worden gemonitord op onbevoegde fysieke toegang.
- 8.9 Configuratiebeheer:
Configuraties, met inbegrip van beveiligingsconfiguraties, van hardware, software, diensten en netwerken behoren te worden vastgesteld, gedocumenteerd, geïmplementeerd, gemonitord en beoordeeld.
- 8.10 Wissen van informatie:
In informatiesystemen, apparaten of andere opslagmedia opgeslagen informatie behoort te worden gewist als deze niet langer vereist is.
- 8.11 Maskeren van gegevens:
Gegevens behoren te worden gemaskeerd overeenkomstig het onderwerp specifieke beleid inzake toegangsbeveiliging en andere gerelateerde onderwerp specifieke beleidsregels, en bedrijfseisen van de organisatie, rekening houdend met de toepasselijke wetgeving.
- 8.12 Voorkomen van gegevenslekken:
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.
- 8.16 Monitoren van activiteiten:
Netwerken, systemen en toepassingen behoren te worden gemonitord op afwijkend gedrag en er behoren passende maatregelen te worden getroffen om potentiële informatiebeveiligingsincidenten te evalueren.
- 8.23 Toepassen van webfilters:
De toegang tot externe websites behoort te worden beheerd om de blootstelling aan kwaadaardige inhoud te beperken.
- 8.28 Veilig coderen:
Er behoren principes voor veilig coderen te worden toegepast op softwareontwikkeling.

View file

@ -0,0 +1,40 @@
#iso27001/2023/NL
Publicatiedatum: augustus 2023
| 2023 ID | Onderwerp | Brontekst | Normaal |
| :------ | :------------------------------------------------------------------------- | :----------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------ |
| **0** | **Inleiding** | [[ISO_27001_2023_NL_BT 0 Inzicht in de organisatie en haar context \|BT]] | [[ISO_27001_2023_NL_NN 0 Inzicht in de organisatie en haar context \|NN]] |
| **1** | **Onderwerp en toepassingsgebied** | [[ISO_27001_2023_NL_BT 1 Onderwerp en toepassingsgebied \|BT]] | [[ISO_27001_2023_NL_NN 1 Onderwerp en toepassingsgebied \|NN]] |
| **2** | **Normatieve verwijzingen** | [[ISO_27001_2023_NL_BT 2 Normatieve verwijzingen \|BT]] | [[ISO_27001_2023_NL_NN 2 Normatieve verwijzingen \|NN]] |
| **3** | **Termen en definities** | [[ISO_27001_2023_NL_BT 3 Termen en definities \|BT]] | [[ISO_27001_2023_NL_NN 3 Termen en definities \|NN]] |
| **4** | **Context van de organisatie** | | |
| 4.1 | Inzicht in de organisatie en haar context | [[ISO_27001_2023_NL_BT 4.1 Inzicht in de organisatie en haar context \|BT]] | [[ISO_27001_2023_NL_NN 4.1 Inzicht in de organisatie en haar context \|NN]] |
| 4.2 | Inzicht in de behoeften en verwachtingen van belanghebbenden | [[ISO_27001_2023_NL_BT 4.2 Inzicht in de behoeften en verwachtingen van belanghebbenden \|BT]] | [[ISO_27001_2023_NL_NN 4.2 Inzicht in de behoeften en verwachtingen van belanghebbenden \|NN]] |
| 4.3 | Het toepassingsgebied van het managementsysteem voor informatiebeveiliging | [[ISO_27001_2023_NL_BT 4.3 Het toepassingsgebied van het managementsysteem voor informatiebeveiliging \|BT]] | [[ISO_27001_2023_NL_NN 4.3 Het toepassingsgebied van het managementsysteem voor informatiebeveiliging \|NN]] |
| 4.4 | Managementsysteem voor informatiebeveiliging | [[ISO_27001_2023_NL_BT 4.4 Managementsysteem voor informatiebeveiliging \|BT]] | [[ISO_27001_2023_NL_NN 4.4 Managementsysteem voor informatiebeveiliging \|NN]] |
| **5** | **Leiderschap** | | |
| 5.1 | Leiderschap en betrokkenheid | [[ISO_27001_2023_NL_BT 5.1 Leiderschap en betrokkenheid \|BT]] | [[ISO_27001_2023_NL_NN 5.1 Leiderschap en betrokkenheid \|NN]] |
| 5.2 | Beleid | [[ISO_27001_2023_NL_BT 5.2 Beleid \|BT]] | [[ISO_27001_2023_NL_NN 5.2 Beleid \|NN]] |
| 5.3 | Rollen, verantwoordelijkheden en bevoegdheden binnen de organisatie | [[ISO_27001_2023_NL_BT 5.3 Rollen, verantwoordelijkheden en bevoegdheden binnen de organisatie \|BT]] | [[ISO_27001_2023_NL_NN 5.3 Rollen, verantwoordelijkheden en bevoegdheden binnen de organisatie \|NN]] |
| **6** | **Planning** | | |
| 6.1 | Acties om risico's en kansen op te pakken | [[ISO_27001_2023_NL_BT 6.1 Acties om risico's en kansen op te pakken \|BT]] | [[ISO_27001_2023_NL_NN 6.1 Acties om risico's en kansen op te pakken \|NN]] |
| 6.2 | Informatiebeveiligingsdoelstellingen en de planning om ze te bereiken | [[ISO_27001_2023_NL_BT 6.2 Informatiebeveiligings[doelstellingen en de planning om ze te bereiken \|BT]] | [[ISO_27001_2023_NL_NN 6.2 Informatiebeveiligings[doelstellingen en de planning om ze te bereiken \|NN]] |
| 6.3 | Planning van wijzigingen | [[ISO_27001_2023_NL_BT 6.3 Planning van wijzigingen \|BT]] | [[ISO_27001_2023_NL_NN 6.3 Planning van wijzigingen \|NN]] |
| **7** | **Ondersteuning** | | |
| 7.1 | Middelen | [[ISO_27001_2023_NL_BT 7.1 Middelen \|BT]] | [[ISO_27001_2023_NL_NN N.N 7.1 Middelen \|NN]] |
| 7.2 | Competentie | [[ISO_27001_2023_NL_BT 7.2 Competentie \|BT]] | [[ISO_27001_2023_NL_NN N.N 7.2 Competentie \|NN]] |
| 7.3 | Bewustzijn | [[ISO_27001_2023_NL_BT 7.3 Bewustzijn \|BT]] | [[ISO_27001_2023_NL_NN N.N 7.3 Bewustzijn \|NN]] |
| 7.4 | Communicatie | [[ISO_27001_2023_NL_BT 7.4 Communicatie \|BT]] | [[ISO_27001_2023_NL_NN N.N 7.4 Communicatie \|NN]] |
| 7.5 | Gedocumenteerde informatie | [[ISO_27001_2023_NL_BT 7.5 Gedocumenteerde informatie \|BT]] | [[ISO_27001_2023_NL_NN N.N 7.5 Gedocumenteerde informatie \|NN]] |
| **8** | **Uitvoering** | | |
| 8.1 | Operationele planning en beheersing | [[ISO_27001_2023_NL_BT 8.1 Operationele planning en beheersing \|BT]] | [[ISO_27001_2023_NL_NN 8.1 Operationele planning en beheersing \|NN]] |
| 8.2 | Risicobeoordeling van informatiebeveiliging | [[ISO_27001_2023_NL_BT 8.2 Risicobeoordeling van informatiebeveiliging \|BT]] | [[ISO_27001_2023_NL_NN 8.2 Risicobeoordeling van informatiebeveiliging \|NN]] |
| 8.3 | Informatiebeveiligingsrisico's behandelen | [[ISO_27001_2023_NL_BT 8.3 Informatiebeveiligingsrisico's behandelen \|BT]] | [[ISO_27001_2023_NL_NN 8.3 Informatiebeveiligingsrisico's behandelen \|NN]] |
| **9** | **Evaluatie van de prestaties** | | |
| 9.1 | Monitoren, meten, analyseren en evalueren | [[ISO_27001_2023_NL_BT 9.1 Monitoren, meten, analyseren en evalueren \|BT]] | [[ISO_27001_2023_NL_NN N.N 9.1 Monitoren, meten, analyseren en evalueren \|NN]] |
| 9.2 | Interne audit | [[ISO_27001_2023_NL_BT 9.2 Interne audit \|BT]] | [[ISO_27001_2023_NL_NN N.N 9.2 Interne audit \|NN]] |
| 9.3 | Management review | [[ISO_27001_2023_NL_BT 9.3 Management review \|BT]] | [[ISO_27001_2023_NL_NN N.N 9.3 Management review \|NN]] |
| **10** | **Verbetering** | | |
| 10.1 | Continue verbetering | [[ISO_27001_2023_NL_BT 10.1 Continue verbetering \|BT]] | [[ISO_27001_2023_NL_NN N.N 10.1 Continue verbetering \|NN]] |
| 10.2 | Afwijkingen en corrigerende maatregelen | [[ISO_27001_2023_NL_BT 10.1 Afwijkingen en corrigerende maatregelen \|BT]] | [[ISO_27001_2023_NL_NN N.N 10.1 Afwijkingen en corrigerende maatregelen \|NN]] |

View file

@ -0,0 +1,6 @@
#iso27001/2023/NL
# ISO 27001 2023 NL
![[ISO_IEC_27001_2023_NL.pdf]]

View file

@ -0,0 +1,39 @@
## 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 organizations information and other associated assets should be made aware of the information security requirements for protecting and handling the organizations 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.

View file

@ -0,0 +1,34 @@
## 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 organizations assets in their possession upon change or termination of their employment, contract or agreement.
**Purpose**
To protect the organizations 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 organizations 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).

View file

@ -0,0 +1,44 @@
#iso27002/2022/EN
## 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 schemes 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.

View file

@ -0,0 +1,47 @@
## 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 organizations 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.

View file

@ -0,0 +1,147 @@
## 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**
<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).
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).
<u>Electronic transfer</u>
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.
<u>Physical storage media transfer</u>
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.
<u>Verbal transfer</u>
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.

View file

@ -0,0 +1,76 @@
#iso27002/2022/EN
## 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.

View file

@ -0,0 +1,44 @@
## 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 organizations 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).

View file

@ -0,0 +1,72 @@
#iso27002/2022/EN
## 5.17 Authentication information
### 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 personrelated 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 users 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.

View file

@ -0,0 +1,63 @@
## 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 organizations 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**
<u>Provision and revocation of access rights</u>
The provisioning process for assigning or revoking physical and logical access rights granted to an entitys 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 organizations 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.
<u>Review of access rights</u>
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.
<u>Consideration before change or termination of employment</u>
A users 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.

View file

@ -0,0 +1,71 @@
#iso27002/2022/EN
## 5.19 Information security in supplier relationships
**Control**
Processes and procedures should be defined and implemented to manage the information security risks associated with the use of suppliers 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 organizations 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 suppliers products or services or for the termination of use of a suppliers 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 suppliers 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 suppliers information and information processing and hence the organizations information security;
d\) defining the organizations 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 organizations 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 suppliers information and information processing and hence the availability of the organizations information;
k\) awareness and training for the organizations 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 organizations 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.

View file

@ -0,0 +1,74 @@
#iso27002/2022/EN
## 5.1 Policies for information security
#### 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 organizations approach to managing its information security.
The information 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 organizations information security policy and topic-specific policies and managing information security in response to changes to:
a) the organizations business strategy;
b) the organizations 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 organizations 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* | 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.
# Related
- [[ISO_27002_PE 5.1 Policies for information security]]

View file

@ -0,0 +1,72 @@
#iso27002/2022/EN
## 5.20 Addressing information security within supplier agreements
**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 organizations classification scheme (see [[5.10]], [[5.12]], [[5.13]])
c\) mapping between the organizations 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 suppliers obligations to comply with the organizations 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 organizations information and other associated assets by supplier personnel (e.g. through an explicit list of supplier personnel authorized to use the organizations information and other associated assets);
h\) information security requirements regarding the suppliers 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 organizations 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 suppliers 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\) suppliers 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 organizations 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 organizations 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.

View file

@ -0,0 +1,58 @@
#iso27002/2022/EN
[[ISO_27002_PE 5.21 Managing information security in the ICT supply chain]]
## 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 organizations 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 suppliers 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.

View file

@ -0,0 +1,57 @@
#iso27002/2022/EN
# 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**
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 suppliers 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 auditors 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 suppliers 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.

View file

@ -0,0 +1,53 @@
#iso27002/2022/EN
## 5.23 Information security for use of cloud services
#### Control
Processes for acquisition, use, management and exit from cloud services should be established in accordance with the organizations 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.21 and 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 organizations 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 organizations 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 organizations 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.
# Related:
- [[ISO_27002_PE 5.23 Information security for use of cloud services]]

View file

@ -0,0 +1,66 @@
#iso27002/2022/EN
## 5.24 Information security incident management planning and preparation
#### 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 [[ISO_27002_OT n.n Title\|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 organizations 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 [[ISO_27002_OT n.n Title\|8.15]] and [[ISO_27002_OT n.n Title\|8.16]]), detecting (see [[ISO_27002_OT n.n Title\|8.16]]), classifying (see [[ISO_27002_OT n.n Title\|5.25]]), analysing and reporting (see [[ISO_27002_OT n.n Title\|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 [[ISO_27002_OT n.n Title\|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 [[ISO_27002_OT 5.5 Contact with authorities|5.5]] and [[ISO_27002_OT 5.6 Contact with special interest groups\|5.6]]);
e\) logging incident management activities;
f\) handling of evidence (see [[ISO_27002_OT n.n Title\|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.

View file

@ -0,0 +1,35 @@
## 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 incidents.
**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.

View file

@ -0,0 +1,35 @@
## 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\) once 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.

View file

@ -0,0 +1,20 @@
#iso27002/2022/EN
## 5.27 Learning from information security incidents
#### 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 [[ISO_27002_OT 5.24 Information security incident management planning and preparation|5.24]]);
b\) identify recurring or serious incidents and their causes to update the organizations 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 [[ISO_27002_OT 6.3 Information security awareness, education and training|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.

View file

@ -0,0 +1,38 @@
## 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.

View file

@ -0,0 +1,30 @@
#iso27002/2022/EN
## 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.

View file

@ -0,0 +1,27 @@
#iso27002/2022/EN
## 5.2 Information security roles and responsibilities
### 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 [[ISO_27002_OT 5.1 Policies for information security\|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 organizations 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.

View file

@ -0,0 +1,42 @@
#iso27002/2022/EN
# **5.30** **ICT** **readiness** **for** **business** continuity
## Purpose
To ensure the availability of the organizations 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 organizations 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.

View file

@ -0,0 +1,73 @@
## 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 organizations 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**
<u>General</u>
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.
<u>Legislation and regulations</u>
The organization should:
a\) identify all legislation and regulations relevant to the organizations 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.
<u>Cryptography</u>
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.
<u>Contracts</u>
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.

View file

@ -0,0 +1,48 @@
#iso27002/2022/EN
## 5.32 Intellectual property rights
**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 licenses, manuals, etc.;
f\) ensuring that any maximum number of users or resources \[e.g. central processing units (CPUs)\] permitted within the license is not exceeded;
g\) carrying out reviews to ensure that only authorized software and licensed products are installed;
h\) providing procedures for maintaining appropriate license 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 licenses.
Proprietary software products are usually supplied under a license 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 organizations own intellectual property rights should also be managed.
1\) Under preparation. Stage at the time of publication: ISO/IEC PRF 23751:2022.

View file

@ -0,0 +1,39 @@
## 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 organizations 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 organizations 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.

View file

@ -0,0 +1,31 @@
## 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.

View file

@ -0,0 +1,38 @@
## 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 organizations 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 organizations 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 organizations 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.

View file

@ -0,0 +1,31 @@
## 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 organizations 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 organizations 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.

View file

@ -0,0 +1,55 @@
## 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 organizations 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.10 and 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.15 and 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.

View file

@ -0,0 +1,33 @@
#iso27002/2022/EN
## 5.3 Segregation of duties
### 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 prevent 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.

View file

@ -0,0 +1,29 @@
#iso27002/2022/EN
## 5.4 Management responsibilities
#### 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 fulfill 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 organizations information and other associated assets;
b)   are provided with guidelines which state the information security expectations of their role within the organization;
c)   are mandated to fulfill 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 organizations 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 organizations security-related processes and controls.
#### Other information
No other information.

View file

@ -0,0 +1,15 @@
#iso27002/2022/EN
## 5.5 Contact with authorities
#### 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.24 to 5.28) or the contingency planning and business continuity processes (see 5.29 and 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 connection with business continuity), telecommunication providers (in connection with line routing and availability) and water suppliers (in connection with cooling facilities for equipment)\].

View file

@ -0,0 +1,25 @@
#iso27002/2022/EN
## 5.6 Contact with special interest groups
#### 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.24 to 5.28).
#### Other information
No other information.

View file

@ -0,0 +1,45 @@
#iso27002/2022/EN
## 5.7 Threat intelligence
#### Control
Information relating to information security threats should be collected and analysed to produce threat intelligence.
#### Purpose
To provide awareness of the organizations 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 organizations 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.
# Related:
- [[Threat Intelligence]]
- [[ISO_27002_PE 5.7 Threat intelligence]]

View file

@ -0,0 +1,50 @@
#iso27002/2022/EN
## 5.8 Information security in project management
#### 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 ([[ISO_27002_OT 8.26 Application security requirements|8.26]]), requirements for complying with intellectual property rights ([[ISO_27002_OT 5.32 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 [[ISO_27002_OT 5.12 Classification of information\|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 organizations 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.

View file

@ -0,0 +1,69 @@
#iso27002/2022/EN
## 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 organizations information and other associated assets in order to preserve their information security and assign appropriate ownership.
**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.
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.
<u>Ownership</u>
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.
<u>Owner duties</u>
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\) they 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.

View file

@ -0,0 +1,48 @@
# Control 6.1 Screening
## 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 applicants 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 persons role.
**Other information**
No other information.

View file

@ -0,0 +1,38 @@
## 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 personnels and the organizations 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 organizations 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 organizations 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 organizations 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 organizations 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 personnels information security responsibilities regarding confidentiality, PII protection, ethics, appropriate use of the organizations 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.

View file

@ -0,0 +1,75 @@
#iso27002/2022/EN
## 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 fullfil their information security responsibilities.
**Guidance**
<u>General</u>
An information security awareness, education and training programme should be established in line with the organizations information security policy, topic-specific policies and relevant procedures on information security, taking into consideration the organizations 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.
Personnels 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.
<u>Awareness</u>
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\) managements 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 ones 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.
<u>Education and training</u>
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.

View file

@ -0,0 +1,69 @@
## 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.

View file

@ -0,0 +1,27 @@
## 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 organizations 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 individuals 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 individuals 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.

View file

@ -0,0 +1,89 @@
## 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 organizations 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 organizations 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.

View file

@ -0,0 +1,137 @@
## 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 organizations 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 organizations 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 organizations 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 organizations 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.

View file

@ -0,0 +1,95 @@
## 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.

View file

@ -0,0 +1,123 @@
## 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 organizations classification scheme and handling requirements.
**Purpose**
To ensure only authorized disclosure, modification, removal or destruction of information on storage media.
**Guidance**
<u>Removable storage media</u>
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.
<u>Secure reuse or disposal</u>
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.

View file

@ -0,0 +1,73 @@
## 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**
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 organizations 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 manufacturers 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.

View file

@ -0,0 +1,81 @@
## 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 organizations 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.

View file

@ -0,0 +1,85 @@
## 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 organizations operations caused by lack of maintenance.
**Guidance**
The following guidelines for equipment maintenance should be considered:
a\) maintaining equipment in accordance with the suppliers 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.

View file

@ -0,0 +1,85 @@
## 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.

View file

@ -0,0 +1,42 @@
## 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 organizations 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 organizations 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.

View file

@ -0,0 +1,151 @@
## 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 organizations information and other associated assets occurs.
**Guidance**
<u>General</u>
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).
<u>Visitors</u>
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.

View file

@ -0,0 +1,53 @@
## 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**
Physical security for offices, rooms and facilities should be designed and implemented. **Purpose**
To prevent unauthorized physical access, damage and interference to the organizations 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.

View file

@ -0,0 +1,85 @@
## 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 organizations 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.

View file

@ -0,0 +1,73 @@
## 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.

View file

@ -0,0 +1,65 @@
## 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.

View file

@ -0,0 +1,73 @@
## 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 organizations assets are not left behind (e.g. documents fallen behind drawers or furniture).
**Other information**
No other information.

View file

@ -0,0 +1,75 @@
## 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.

View file

@ -0,0 +1,83 @@
## 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 organizations operations.
**Guidance**
Any device used outside the organizations 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 organizations 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 organizations 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 organizations 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 organizations 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.

View file

@ -0,0 +1,52 @@
## 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**
<u>General</u>
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 organizations 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.
<u>Deletion methods</u>
In accordance with the organizations 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 organizations 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.

View file

@ -0,0 +1,58 @@
## 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 organizations 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 applications 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.

View file

@ -0,0 +1,41 @@
## 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 users 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 users 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 organizations 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 adversarys decisions for example by replacing authentic information with false information, either as an independent action or as response to the adversarys 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 personnels 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.12 and >5.15>).

Some files were not shown because too many files have changed in this diff Show more