diff --git a/.DS_Store b/.DS_Store
index a784c66..bd9d599 100644
Binary files a/.DS_Store and b/.DS_Store differ
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.10_OT Acceptable use of information and other associated assets.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.10_OT Acceptable use of information and other associated assets.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.10_OT Acceptable use of information and other associated assets.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.10_OT Acceptable use of information and other associated assets.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.11_OT Return of assets.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.11_OT Return of assets.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.11_OT Return of assets.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.11_OT Return of assets.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.12_OT Classification of information.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.12_OT Classification of information.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.12_OT Classification of information.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.12_OT Classification of information.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.13_OT Labelling of information.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.13_OT Labelling of information.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.13_OT Labelling of information.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.13_OT Labelling of information.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.14_OT Information transfer.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.14_OT Information transfer.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.14_OT Information transfer.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.14_OT Information transfer.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.15_OT Access control.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.15_OT Access control.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.15_OT Access control.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.15_OT Access control.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.16_OT Identity management.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.16_OT Identity management.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.16_OT Identity management.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.16_OT Identity management.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.17_OT Authentication information.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.17_OT Authentication information.md
similarity index 99%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.17_OT Authentication information.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.17_OT Authentication information.md
index 93938d3..cb998c5 100644
--- a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.17_OT Authentication information.md
+++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.17_OT Authentication information.md
@@ -3,8 +3,10 @@
### 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**
@@ -63,7 +65,7 @@ h) store and transmit passwords in protected form.
Password encryption and hashing should be performed according to approved cryptographic techniques for passwords (see 8.24).
-**Other** **information**
+**Other information**
Passwords or passphrases are a commonly used type of authentication information and are a common means of verifying a user’s identity. Other types of authentication information are cryptographic keys, data stored on hardware tokens (e.g. smart cards) that produce authentication codes and biometric data such as iris scans or fingerprints. Additional information can be found in the ISO/IEC 24760 series.
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.18_OT Access rights.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.18_OT Access rights.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.18_OT Access rights.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.18_OT Access rights.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.19_OT Information security in supplier relationships.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.19_OT Information security in supplier relationships.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.19_OT Information security in supplier relationships.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.19_OT Information security in supplier relationships.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-2/ISO_27002_2022_5.1_OT Policies for information security.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.1_OT Policies for information security.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-2/ISO_27002_2022_5.1_OT Policies for information security.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.1_OT Policies for information security.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.20_OT Addressing information security within supplier agreements.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.20_OT Addressing information security within supplier agreements.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.20_OT Addressing information security within supplier agreements.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.20_OT Addressing information security within supplier agreements.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.21_OT Managing information security in the ICT supply chain.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.21_OT Managing information security in the ICT supply chain.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.21_OT Managing information security in the ICT supply chain.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.21_OT Managing information security in the ICT supply chain.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-2/ISO_27002_2022_5.22_OT Monitoring, review and change management of supplier services.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.22_OT Monitoring, review and change management of supplier services.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-2/ISO_27002_2022_5.22_OT Monitoring, review and change management of supplier services.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.22_OT Monitoring, review and change management of supplier services.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-2/ISO_27002_2022_5.23_OT Information security for use of cloud services.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.23_OT Information security for use of cloud services.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-2/ISO_27002_2022_5.23_OT Information security for use of cloud services.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.23_OT Information security for use of cloud services.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-2/ISO_27002_2022_5.24_OT Information security incident management planning and preparation.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.24_OT Information security incident management planning and preparation.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-2/ISO_27002_2022_5.24_OT Information security incident management planning and preparation.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.24_OT Information security incident management planning and preparation.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.25_OT Assessment and decision on information security events.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.25_OT Assessment and decision on information security events.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.25_OT Assessment and decision on information security events.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.25_OT Assessment and decision on information security events.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.26_OT Response to information security incidents.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.26_OT Response to information security incidents.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.26_OT Response to information security incidents.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.26_OT Response to information security incidents.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-2/ISO_27002_2022_5.27_OT Learning from information security incidents.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.27_OT Learning from information security incidents.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-2/ISO_27002_2022_5.27_OT Learning from information security incidents.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.27_OT Learning from information security incidents.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.28_OT Collection of evidence.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.28_OT Collection of evidence.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.28_OT Collection of evidence.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.28_OT Collection of evidence.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.29_OT Information security during disruption.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.29_OT Information security during disruption.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.29_OT Information security during disruption.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.29_OT Information security during disruption.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.2_OT Information security roles and responsibilities.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.2_OT Information security roles and responsibilities.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.2_OT Information security roles and responsibilities.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.2_OT Information security roles and responsibilities.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-2/ISO_27002_2022_5.30_OT ICT readiness for business continuity.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.30_OT ICT readiness for business continuity.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-2/ISO_27002_2022_5.30_OT ICT readiness for business continuity.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.30_OT ICT readiness for business continuity.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.31_OT Legal, statutory, regulatory and contractual requirements.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.31_OT Legal, statutory, regulatory and contractual requirements.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.31_OT Legal, statutory, regulatory and contractual requirements.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.31_OT Legal, statutory, regulatory and contractual requirements.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-2/ISO_27002_2022_5.32_OT Intellectual property rights.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.32_OT Intellectual property rights.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-2/ISO_27002_2022_5.32_OT Intellectual property rights.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.32_OT Intellectual property rights.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.33_OT Protection of records.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.33_OT Protection of records.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.33_OT Protection of records.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.33_OT Protection of records.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.34_OT Privacy and protection of PII.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.34_OT Privacy and protection of PII.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.34_OT Privacy and protection of PII.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.34_OT Privacy and protection of PII.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.35_OT Independent review of information security.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.35_OT Independent review of information security.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.35_OT Independent review of information security.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.35_OT Independent review of information security.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.36_OT Compliance with policies, rules and standards for information security.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.36_OT Compliance with policies, rules and standards for information security.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.36_OT Compliance with policies, rules and standards for information security.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.36_OT Compliance with policies, rules and standards for information security.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.37_OT Documented operating procedures.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.37_OT Documented operating procedures.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.37_OT Documented operating procedures.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.37_OT Documented operating procedures.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-2/ISO_27002_2022_5.3_OT Segregation of duties.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.3_OT Segregation of duties.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-2/ISO_27002_2022_5.3_OT Segregation of duties.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.3_OT Segregation of duties.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.4_OT Management responsibilities.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.4_OT Management responsibilities.md
similarity index 98%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.4_OT Management responsibilities.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.4_OT Management responsibilities.md
index a0ec231..8a17323 100644
--- a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.4_OT Management responsibilities.md
+++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.4_OT Management responsibilities.md
@@ -3,8 +3,10 @@
#### 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.
@@ -25,5 +27,6 @@ f) continue to have the appropriate information security skills and qualifica
g) where practicable, are provided with a confidential channel for reporting violations of information security policy, topic-specific policies or procedures for information security (“whistleblowing”). This can allow for anonymous reporting, or have provisions to ensure that knowledge of the identity of the reporter is known only to those who need to deal with such reports;
h) are provided with adequate resources and project planning time for implementing the organization’s security-related processes and controls.
+
#### Other information
No other information.
\ No newline at end of file
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-2/ISO_27002_2022_5.5_OT Contact with authorities.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.5_OT Contact with authorities.md
similarity index 94%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-2/ISO_27002_2022_5.5_OT Contact with authorities.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.5_OT Contact with authorities.md
index 321b677..fcbd955 100644
--- a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-2/ISO_27002_2022_5.5_OT Contact with authorities.md
+++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.5_OT Contact with authorities.md
@@ -2,35 +2,17 @@
## 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)].
\ No newline at end of file
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-2/ISO_27002_2022_5.6_OT Contact with special interest groups.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.6_OT Contact with special interest groups.md
similarity index 97%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-2/ISO_27002_2022_5.6_OT Contact with special interest groups.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.6_OT Contact with special interest groups.md
index 198388e..ad461d2 100644
--- a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-2/ISO_27002_2022_5.6_OT Contact with special interest groups.md
+++ b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.6_OT Contact with special interest groups.md
@@ -23,7 +23,6 @@ e) share and exchange information about new technologies, produ
f) provide suitable liaison points when dealing with information security incidents (see 5.24 to 5.28).
-
#### Other information
No other information.
\ No newline at end of file
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-2/ISO_27002_2022_5.7_OT Threat intelligence.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.7_OT Threat intelligence.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-2/ISO_27002_2022_5.7_OT Threat intelligence.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.7_OT Threat intelligence.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-2/ISO_27002_2022_5.8_OT Information security in project management.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.8_OT Information security in project management.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-2/ISO_27002_2022_5.8_OT Information security in project management.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.8_OT Information security in project management.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.9_OT Inventory of information and other associated assets.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.9_OT Inventory of information and other associated assets.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.9_OT Inventory of information and other associated assets.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_5.9_OT Inventory of information and other associated assets.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_6.1_OT Screening.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_6.1_OT Screening.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_6.1_OT Screening.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_6.1_OT Screening.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_6.2_OT Terms and conditions of employment.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_6.2_OT Terms and conditions of employment.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_6.2_OT Terms and conditions of employment.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_6.2_OT Terms and conditions of employment.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_6.3_OT Information security awareness, education and training.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_6.3_OT Information security awareness, education and training.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_6.3_OT Information security awareness, education and training.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_6.3_OT Information security awareness, education and training.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_6.4_OT Disciplinary process.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_6.4_OT Disciplinary process.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_6.4_OT Disciplinary process.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_6.4_OT Disciplinary process.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_6.5_OT Responsibilities after termination or change of employment.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_6.5_OT Responsibilities after termination or change of employment.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_6.5_OT Responsibilities after termination or change of employment.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_6.5_OT Responsibilities after termination or change of employment.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_6.6_OT Confidentiality or non-disclosure agreements.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_6.6_OT Confidentiality or non-disclosure agreements.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_6.6_OT Confidentiality or non-disclosure agreements.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_6.6_OT Confidentiality or non-disclosure agreements.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_6.7_OT Remote working.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_6.7_OT Remote working.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_6.7_OT Remote working.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_6.7_OT Remote working.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_6.8_OT Information security event reporting.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_6.8_OT Information security event reporting.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_6.8_OT Information security event reporting.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_6.8_OT Information security event reporting.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_7.10_OT Storage media.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_7.10_OT Storage media.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_7.10_OT Storage media.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_7.10_OT Storage media.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_7.11_OT Supporting utilities.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_7.11_OT Supporting utilities.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_7.11_OT Supporting utilities.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_7.11_OT Supporting utilities.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_7.12_OT Cabling security.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_7.12_OT Cabling security.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_7.12_OT Cabling security.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_7.12_OT Cabling security.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_7.13_OT Equipment maintenance.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_7.13_OT Equipment maintenance.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_7.13_OT Equipment maintenance.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_7.13_OT Equipment maintenance.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_7.14_OT Secure disposal or re-use of equipment.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_7.14_OT Secure disposal or re-use of equipment.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_7.14_OT Secure disposal or re-use of equipment.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_7.14_OT Secure disposal or re-use of equipment.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_7.1_OT Physical security perimeters.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_7.1_OT Physical security perimeters.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_7.1_OT Physical security perimeters.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_7.1_OT Physical security perimeters.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_7.2_OT Physical entry.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_7.2_OT Physical entry.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_7.2_OT Physical entry.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_7.2_OT Physical entry.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_7.3_OT Securing offices, rooms and facilities.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_7.3_OT Securing offices, rooms and facilities.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_7.3_OT Securing offices, rooms and facilities.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_7.3_OT Securing offices, rooms and facilities.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_7.4_OT Physical security monitoring.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_7.4_OT Physical security monitoring.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_7.4_OT Physical security monitoring.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_7.4_OT Physical security monitoring.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_7.5_OT Protecting against physical and environmental threats.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_7.5_OT Protecting against physical and environmental threats.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_7.5_OT Protecting against physical and environmental threats.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_7.5_OT Protecting against physical and environmental threats.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_7.6_OT Working in secure areas.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_7.6_OT Working in secure areas.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_7.6_OT Working in secure areas.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_7.6_OT Working in secure areas.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_7.7_OT Clear desk and clear screen.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_7.7_OT Clear desk and clear screen.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_7.7_OT Clear desk and clear screen.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_7.7_OT Clear desk and clear screen.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_7.8_OT Equipment siting and protection.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_7.8_OT Equipment siting and protection.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_7.8_OT Equipment siting and protection.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_7.8_OT Equipment siting and protection.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_7.9_OT Security of assets off-premises.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_7.9_OT Security of assets off-premises.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_7.9_OT Security of assets off-premises.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_7.9_OT Security of assets off-premises.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.10_OT Information deletion.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.10_OT Information deletion.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.10_OT Information deletion.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.10_OT Information deletion.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.11_OT Data masking.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.11_OT Data masking.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.11_OT Data masking.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.11_OT Data masking.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.12_OT Data leakage prevention.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.12_OT Data leakage prevention.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.12_OT Data leakage prevention.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.12_OT Data leakage prevention.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.13_OT Information backup.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.13_OT Information backup.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.13_OT Information backup.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.13_OT Information backup.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.14_OT Redundancy of information processing facilities.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.14_OT Redundancy of information processing facilities.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.14_OT Redundancy of information processing facilities.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.14_OT Redundancy of information processing facilities.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.15_OT Logging.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.15_OT Logging.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.15_OT Logging.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.15_OT Logging.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.16_OT Monitoring activities.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.16_OT Monitoring activities.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.16_OT Monitoring activities.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.16_OT Monitoring activities.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.17_OT Clock synchronization.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.17_OT Clock synchronization.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.17_OT Clock synchronization.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.17_OT Clock synchronization.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.18_OT Use of privileged utility programs.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.18_OT Use of privileged utility programs.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.18_OT Use of privileged utility programs.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.18_OT Use of privileged utility programs.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.19_OT Installation of software on operational systems.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.19_OT Installation of software on operational systems.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.19_OT Installation of software on operational systems.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.19_OT Installation of software on operational systems.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.1_OT User endpoint devices.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.1_OT User endpoint devices.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.1_OT User endpoint devices.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.1_OT User endpoint devices.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.20_OT Networks security.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.20_OT Networks security.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.20_OT Networks security.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.20_OT Networks security.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.21_OT Security of network services.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.21_OT Security of network services.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.21_OT Security of network services.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.21_OT Security of network services.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.22_OT Segregation of networks.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.22_OT Segregation of networks.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.22_OT Segregation of networks.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.22_OT Segregation of networks.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.23_OT Web filtering.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.23_OT Web filtering.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.23_OT Web filtering.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.23_OT Web filtering.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-2/ISO_27002_2022_8.24_OT Use of cryptography.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.24_OT Use of cryptography.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-2/ISO_27002_2022_8.24_OT Use of cryptography.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.24_OT Use of cryptography.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-2/ISO_27002_2022_8.25_OT Secure development life cycle.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.25_OT Secure development life cycle.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-2/ISO_27002_2022_8.25_OT Secure development life cycle.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.25_OT Secure development life cycle.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-2/ISO_27002_2022_8.26_OT Application security requirements.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.26_OT Application security requirements.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-2/ISO_27002_2022_8.26_OT Application security requirements.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.26_OT Application security requirements.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-2/ISO_27002_2022_8.27_OT Secure system architecture and engineering principles.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.27_OT Secure system architecture and engineering principles.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-2/ISO_27002_2022_8.27_OT Secure system architecture and engineering principles.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.27_OT Secure system architecture and engineering principles.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-2/ISO_27002_2022_8.28_OT Secure coding.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.28_OT Secure coding.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-2/ISO_27002_2022_8.28_OT Secure coding.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.28_OT Secure coding.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.29_OT Security testing in development and acceptance.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.29_OT Security testing in development and acceptance.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.29_OT Security testing in development and acceptance.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.29_OT Security testing in development and acceptance.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.2_OT Privileged access rights.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.2_OT Privileged access rights.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.2_OT Privileged access rights.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.2_OT Privileged access rights.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.30_OT Outsourced development.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.30_OT Outsourced development.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.30_OT Outsourced development.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.30_OT Outsourced development.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.31_OT Separation of development, test and production environments.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.31_OT Separation of development, test and production environments.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.31_OT Separation of development, test and production environments.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.31_OT Separation of development, test and production environments.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.32_OT Change management.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.32_OT Change management.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.32_OT Change management.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.32_OT Change management.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.33_OT Test information.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.33_OT Test information.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.33_OT Test information.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.33_OT Test information.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.34_OT Protection of information systems during audit testing.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.34_OT Protection of information systems during audit testing.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.34_OT Protection of information systems during audit testing.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.34_OT Protection of information systems during audit testing.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.3_OT Information access restriction.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.3_OT Information access restriction.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.3_OT Information access restriction.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.3_OT Information access restriction.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.4_OT Access to source code.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.4_OT Access to source code.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.4_OT Access to source code.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.4_OT Access to source code.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.5_OT Secure authentication.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.5_OT Secure authentication.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.5_OT Secure authentication.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.5_OT Secure authentication.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.6_OT Capacity management.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.6_OT Capacity management.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.6_OT Capacity management.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.6_OT Capacity management.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-2/ISO_27002_2022_8.7_OT Protection against malware.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.7_OT Protection against malware.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-2/ISO_27002_2022_8.7_OT Protection against malware.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.7_OT Protection against malware.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-2/ISO_27002_2022_8.8_OT Management of technical vulnerabilities.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.8_OT Management of technical vulnerabilities.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-2/ISO_27002_2022_8.8_OT Management of technical vulnerabilities.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.8_OT Management of technical vulnerabilities.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-2/ISO_27002_2022_8.9_OT Configuration management.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.9_OT Configuration management.md
similarity index 100%
rename from Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-2/ISO_27002_2022_8.9_OT Configuration management.md
rename to Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_8.9_OT Configuration management.md
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.1_OT Policies for information security.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.1_OT Policies for information security.md
deleted file mode 100644
index 58aa9f2..0000000
--- a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.1_OT Policies for information security.md
+++ /dev/null
@@ -1,74 +0,0 @@
-#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 organization’s 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 organization’s information security policy and topic-specific policies and managing information security in response to changes to:
-
-a) the organization’s business strategy;
-b) the organization’s technical environment;
-c) regulations, statutes, legislation and contracts;
-d) information security risks;
-e) the current and projected information security threat environment;
-f) lessons learned from information security events and incidents.
-
-The review of information security policy and topic-specific policies should take the results of management reviews and audits into account. Review and update of other related policies should be considered when one policy is changed to maintain consistency.
-
-The information security policy and topic-specific policies should be communicated to relevant personnel and interested parties in a form that is relevant, accessible and understandable to the intended reader. Recipients of the policies should be required to acknowledge they understand and agree to comply with the policies where applicable. The organization can determine the formats and names of these policy documents that meet the organization’s needs. In some organizations, the information security policy and topic-specific policies can be in a single document. The organization can name these topic-specific policies as standards, directives, policies or others.
-
-If the information security policy or any topic-specific policy is distributed outside the organization, care should be taken not to improperly disclose confidential information.
-
-Table 1 illustrates the differences between information security policy and topic-specific policy.
-
-*Table 1* | 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]]
-
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.22_OT Monitoring, review and change management of supplier services.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.22_OT Monitoring, review and change management of supplier services.md
deleted file mode 100644
index f123f36..0000000
--- a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.22_OT Monitoring, review and change management of supplier services.md
+++ /dev/null
@@ -1,57 +0,0 @@
-#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 supplier’s policies and procedures;
-4) new or changed controls to resolve information security incidents and to improve information security;
-
-c) monitor changes in supplier services including:
-1) changes and enhancement to networks;
-2) use of new technologies;
-3) adoption of new products or newer versions or releases;
-4) new development tools and environments;
-5) changes to physical location of service facilities;
-6) change of sub-suppliers;
-7) sub-contracting to another supplier;
-
-d\) review service reports produced by the supplier and arrange regular progress meetings as required by the agreements;
-
-e\) conduct audits of suppliers and sub-suppliers, in conjunction with review of independent auditor’s reports, if available and follow-up on issues identified;
-
-f\) provide information about information security incidents and review this information as required by the agreements and any supporting guidelines and procedures;
-
-g\) review supplier audit trails and records of information security events, operational problems, failures, tracing of faults and disruptions related to the service delivered;
-
-h\) respond to and manage any identified information security events or incidents;
-
-i\) identify information security vulnerabilities and manage them;
-
-j\) review information security aspects of the supplier’s relationships with its own suppliers;
-
-k\) ensure that the supplier maintains sufficient service capability together with workable plans designed to ensure that agreed service continuity levels are maintained following major service failures or disaster (see [[5.29]], [[5.30]], [[5.35]], [[5.36]], [[8.14]];
-
-l\) ensure that suppliers assign responsibilities for reviewing compliance and enforcing the requirements of the agreements;
-
-m\) evaluate regularly that the suppliers maintain adequate information security levels.
-
-
-The responsibility for managing supplier relationships should be assigned to a designated individual or team. Sufficient technical skills and resources should be made available to monitor that the requirements of the agreement, in particular the information security requirements, are being met. Appropriate actions should be taken when deficiencies in the service delivery are observed.
-
-**Other information**
-See ISO/IEC 27036-3 for more detail.
\ No newline at end of file
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.23_OT Information security for use of cloud services.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.23_OT Information security for use of cloud services.md
deleted file mode 100644
index f1f04c6..0000000
--- a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.23_OT Information security for use of cloud services.md
+++ /dev/null
@@ -1,53 +0,0 @@
-#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 organization’s information security requirements.
-#### Purpose
-To specify and manage information security for the use of cloud services.
-#### Guidance
-The organization should establish and communicate topic-specific policy on the use of cloud services to all relevant interested parties.
-
-The organization should define and communicate how it intends to manage information security risks associated with the use of cloud services. It can be an extension or part of the existing approach for how an organization manages services provided by external parties (see 5.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 organization’s data and availability of services:
-a) providing solutions based on industry accepted standards for architecture and infrastructure;
-b) managing access controls of the cloud service to meet the requirements of the organization;
-c) implementing malware monitoring and protection solutions;
-d) processing and storing the organization’s sensitive information in approved locations (e.g. particular country or region) or within or subject to a particular jurisdiction;
-e) providing dedicated support in the event of an information security incident in the cloud service environment;
-f) ensuring that the organization’s information security requirements are met in the event of cloud services being further sub-contracted to an external supplier (or prohibiting cloud services from being sub-contracted);
-g) supporting the organization in gathering digital evidence, taking into consideration laws and regulations for digital evidence across different jurisdictions;
-h) providing appropriate support and availability of services for an appropriate time frame when the organization wants to exit from the cloud service;
-i) providing required backup of data and configuration information and securely managing backups as applicable, based on the capabilities of the cloud service provider used by the organization, acting as the cloud service customer;
-j) providing and returning information such as configuration files, source code and data that are owned by the organization, acting as the cloud service customer, when requested during the service provision or at termination of service.
-
-The organization, acting as the cloud service customer, should consider whether the agreement should require cloud service providers to provide advance notification prior to any substantive customer impacting changes being made to the way the service is delivered to the organization, including:
-a) changes to the technical infrastructure (e.g. relocation, reconfiguration, or changes in hardware or software) that affect or change the cloud service offering;
-b) processing or storing information in a new geographical or legal jurisdiction;
-c) use of peer cloud service providers or other sub-contractors (including changing existing or using new parties).
-
-The organization using cloud services should maintain close contact with its cloud service providers. These contacts enable mutual exchange of information about information security for the use of the cloud services including a mechanism for both cloud service provider and the organization, acting as the cloud service customer, to monitor each service characteristic and report failures to the commitments contained in the agreements.
-
-#### Other information
-This control considers cloud security from the perspective of the cloud service customer.
-
-Additional information relating to cloud services can be found in ISO/IEC 17788, ISO/IEC 17789 and ISO/IEC 22123-1. Specifics related to cloud portability in support of exit strategies can be found in ISO/IEC 19941. Specifics related to information security and public cloud services are described in ISO/IEC 27017. Specifics related to PII protection in public clouds acting as PII processor are described in ISO/IEC 27018. Supplier relationships for cloud services are covered by ISO/IEC 27036-4 and cloud service agreements and their contents are dealt with in the ISO/IEC 19086 series, with security and privacy specifically covered by ISO/IEC 19086-4.
-# Related:
-- [[ISO_27002_PE 5.23 Information security for use of cloud services]]
\ No newline at end of file
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.24_OT Information security incident management planning and preparation.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.24_OT Information security incident management planning and preparation.md
deleted file mode 100644
index 439768d..0000000
--- a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.24_OT Information security incident management planning and preparation.md
+++ /dev/null
@@ -1,66 +0,0 @@
-#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 organization’s priorities for handling information security incidents, including resolution time frame based on potential consequences and severity. Incident management procedures should be implemented to meet these objectives and priorities.
-
-Management should ensure that an information security incident management plan is created considering different scenarios and procedures are developed and implemented for the following activities:
-
-a\) evaluation of information security events according to criteria for what constitutes an information security incident;
-
-b\) monitoring (see [[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.
\ No newline at end of file
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.27_OT Learning from information security incidents.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.27_OT Learning from information security incidents.md
deleted file mode 100644
index 0eb3532..0000000
--- a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.27_OT Learning from information security incidents.md
+++ /dev/null
@@ -1,20 +0,0 @@
-#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 organization’s information security risk assessment and determine and implement necessary additional controls to reduce the likelihood or consequences of future similar incidents. Mechanisms to enable that include collecting, quantifying and monitoring information about incident types, volumes and costs;
-
-c\) enhance user awareness and training (see [[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.
\ No newline at end of file
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.30_OT ICT readiness for business continuity.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.30_OT ICT readiness for business continuity.md
deleted file mode 100644
index 551ee75..0000000
--- a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.30_OT ICT readiness for business continuity.md
+++ /dev/null
@@ -1,42 +0,0 @@
-#iso27002/2022/EN
-# **5.30** **ICT** **readiness** **for** **business** continuity
-
-## Purpose
-To ensure the availability of the organization’s information and other associated assets during disruption.
-## Guidance
-ICT readiness for business continuity is an important component in business continuity management and information security management to ensure that the organization’s objectives can continue to be met during disruption.
-
-The ICT continuity requirements are the outcome of the business impact analysis (BIA). The BIA process should use impact types and criteria to assess the impacts over time resulting from the disruption of business activities that deliver products and services. The magnitude and duration of the resulting impact should be used to identify prioritized activities which should be assigned a recovery time objective (RTO). The BIA should then determine which resources are needed to support prioritized activities. An RTO should also be specified for these resources. A subset of these resources should include ICT services.
-
-The BIA involving ICT services can be expanded to define performance and capacity requirements of ICT systems and recovery point objectives (RPO) of information required to support activities during disruption.
-
-Based on the outputs from the BIA and risk assessment involving ICT services, the organization should identify and select ICT continuity strategies that consider options for before, during and after disruption. The business continuity strategies can comprise one or more solutions. Based on the strategies, plans should be developed, implemented and tested to meet the required availability level of ICT services and in the required time frames following interruption to, or failure of, critical processes.
-
-The organization should ensure that:
-
-a) an adequate organizational structure is in place to prepare for, mitigate and respond to a disruption supported by personnel with the necessary responsibility, authority and competence;
-
-b) ICT continuity plans, including response and recovery procedures detailing how the organization is planning to manage an ICT service disruption, are:
-
-1) regularly evaluated through exercises and tests;
-2) approved by management;
-
-c) ICT continuity plans include the following ICT continuity information:
-
-1) performance and capacity specifications to meet the business continuity requirements and objectives as specified in the BIA;
-2) RTO of each prioritized ICT service and the procedures for restoring those components;
-3) RPO of the prioritized ICT resources defined as information and the procedures for restoring the information.
-
-## Other **information**
-
-Managing ICT continuity forms a key part of business continuity requirements concerning availability to be able to:
-
-a) respond and recover from disruption to ICT services regardless of the cause;
-
-b) ensure continuity of prioritized activities are supported by the required ICT services;
-
-c) respond before a disruption to ICT services occurs, and upon detection of at least one incident that can result in a disruption to ICT services.
-
-Further guidance on ICT readiness for business continuity can be found in ISO/IEC 27031.
-
-Further guidance on business continuity management systems can be found in ISO 22301 and ISO 22313. Further guidance on BIA can be found in ISO/TS 22317.
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.32_OT Intellectual property rights.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.32_OT Intellectual property rights.md
deleted file mode 100644
index c5a2f9a..0000000
--- a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.32_OT Intellectual property rights.md
+++ /dev/null
@@ -1,48 +0,0 @@
-#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 organization’s own intellectual property rights should also be managed.
-
-1\) Under preparation. Stage at the time of publication: ISO/IEC PRF 23751:2022.
\ No newline at end of file
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.3_OT Segregation of duties.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.3_OT Segregation of duties.md
deleted file mode 100644
index e668c88..0000000
--- a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.3_OT Segregation of duties.md
+++ /dev/null
@@ -1,33 +0,0 @@
-#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.
\ No newline at end of file
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.5_OT Contact with authorities.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.5_OT Contact with authorities.md
deleted file mode 100644
index 8528be3..0000000
--- a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.5_OT Contact with authorities.md
+++ /dev/null
@@ -1,15 +0,0 @@
-#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)\].
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.6_OT Contact with special interest groups.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.6_OT Contact with special interest groups.md
deleted file mode 100644
index 04453d4..0000000
--- a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.6_OT Contact with special interest groups.md
+++ /dev/null
@@ -1,25 +0,0 @@
-#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.
\ No newline at end of file
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.7_OT Threat intelligence.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.7_OT Threat intelligence.md
deleted file mode 100644
index c0ae98e..0000000
--- a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.7_OT Threat intelligence.md
+++ /dev/null
@@ -1,45 +0,0 @@
-#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 organization’s threat environment so that the appropriate mitigation actions can be taken.
-#### Guidance
-Information about existing or emerging threats is collected and analysed in order to:
-
-a) facilitate informed actions to prevent the threats from causing harm to the organization;
-b) reduce the impact of such threats.
-
-Threat intelligence can be divided into three layers, which should all be considered:
-
-a) strategic threat intelligence: exchange of high-level information about the changing threat landscape (e.g. types of attackers or types of attacks);
-b) tactical threat intelligence: information about attacker methodologies, tools and technologies involved;
-c) operational threat intelligence: details about specific attacks, including technical indicators.
-
-Threat intelligence should be:
-
-a) relevant (i.e. related to the protection of the organization);
-b) insightful (i.e. providing the organization with an accurate and detailed understanding of the threat landscape);
-c) contextual, to provide situational awareness (i.e. adding context to the information based on the time of events, where they occur, previous experiences and prevalence in similar organizations);
-d) actionable (i.e. the organization can act on information quickly and effectively).
-
-Threat intelligence activities should include:
-
-a) establishing objectives for threat intelligence production;
-b) identifying, vetting and selecting internal and external information sources that are necessary and appropriate to provide information required for the production of threat intelligence;
-c) collecting information from selected sources, which can be internal and external;
-d) processing information collected to prepare it for analysis (e.g. by translating, formatting or corroborating information);
-e) analysing information to understand how it relates and is meaningful to the organization;
-f) communicating and sharing it to relevant individuals in a format that can be understood.
-
-Threat intelligence should be analysed and later used:
-
-a) by implementing processes to include information gathered from threat intelligence sources into the organization’s information security risk management processes;
-b) as additional input to technical preventive and detective controls like firewalls, intrusion detection system, or anti malware solutions;
-c) as input to the information security test processes and techniques.
-
-The organization should share threat intelligence with other organizations on a mutual basis in order to improve overall threat intelligence.
-# Related:
-- [[Threat Intelligence]]
-- [[ISO_27002_PE 5.7 Threat intelligence]]
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.8_OT Information security in project management.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.8_OT Information security in project management.md
deleted file mode 100644
index 9154593..0000000
--- a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_5.8_OT Information security in project management.md
+++ /dev/null
@@ -1,50 +0,0 @@
-#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 organization’s information security policy and topic-specific policies including relevant security clauses in any agreements or contracts.
-
-#### Other information
-The project development approach, such as waterfall life cycle or agile life cycle, should support information security in a structured way that can be adapted to suit the assessed severity of the information security risks, based on the character of the project. Early consideration of information security requirements for the product or service (e.g. at the planning and design stages), can lead to more effective and cost-efficient solutions for quality and information security. ISO 21500 and ISO 21502 provide guidance on concepts and processes of project management that are important for the performance of projects.
-
-ISO/IEC 27005 provides guidance on the use of risk management processes to identify controls to meet information security requirements.
\ No newline at end of file
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.24_OT Use of cryptography.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.24_OT Use of cryptography.md
deleted file mode 100644
index 4ce2b18..0000000
--- a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.24_OT Use of cryptography.md
+++ /dev/null
@@ -1,77 +0,0 @@
----
-tags:
- - iso27001/2022/EN
----
-## 8.24 Use of cryptography
-
-| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains |
-| ------------ | ----------------------------------------- | ---------------------- | ------------------------ | ---------------- |
-| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Secure_configuration | #Protection |
-
-**Control**
-Rules for the effective use of cryptography, including cryptographic key management, should be defined and implemented.
-
-**Purpose**
-To ensure proper and effective use of cryptography to protect the confidentiality, authenticity or integrity of information according to business and information security requirements, and taking into consideration legal, statutory, regulatory and contractual requirements related to cryptography.
-
-**Guidance**
-
-General
-When using cryptography, the following should be considered:
-
-a\) the topic-specific policy on cryptography defined by the organization, including the general principles for the protection of information. A topic-specific policy on the use of cryptography is necessary to maximize the benefits and minimize the risks of using cryptographic techniques and to avoid inappropriate or incorrect use;
-
-b\) identifying the required level of protection and the classification of the information andconsequently establishing the type, strength and quality of the cryptographic algorithms required;
-
-c\) the use of cryptography for protection of information held on mobile user endpoint devices or storage media and transmitted over networks to such devices or storage media;
-
-d\) the approach to key management, including methods to deal with the generation and protection of cryptographic keys and the recovery of encrypted information in the case of lost, compromised or damaged keys;
-
-e\) roles and responsibilities for:
-
- 1\) the implementation of the rules for the effective use of cryptography;
- 2\) the key management, including key generation (see 8.24);
-
-f\) the standards to be adopted, as well as cryptographic algorithms, cipher strength, cryptographic solutions and usage practices that are approved or required for use in the organization;
-
-g\) the impact of using encrypted information on controls that rely on content inspection (e.g. malware detection or content filtering).
-
-When implementing the organization’s rules for effective use of cryptography, the regulations and national restrictions that can apply to the use of cryptographic techniques in different parts of the world should be taken into consideration as well as the issues of trans-border flow of encrypted information (see 5.31).
-
-The contents of service level agreements or contracts with external suppliers of cryptographic services (e.g. with a certification authority) should cover issues of liability, reliability of services and response times for the provision of services (see 5.22).
-
-Key management
-
-Appropriate key management requires secure processes for generating, storing, archiving, retrieving, distributing, retiring and destroying cryptographic keys.
-
-A key management system should be based on an agreed set of standards, procedures and secure methods for:
-
- a\) generating keys for different cryptographic systems and different applications;
- b\) issuing and obtaining public key certificates;
- c\) distributing keys to intended entities, including how to activate keys when received;
- d\) storing keys, including how authorized users obtain access to keys;
- e\) changing or updating keys including rules on when to change keys and how this will be done;
- f\) dealing with compromised keys;
- g\) revoking keys including how to withdraw or deactivate keys \[e.g. when keys have been compromised or when a user leaves an organization (in which case keys should also be archived)\];
- h\) recovering keys that are lost or corrupted;
- i\) backing up or archiving keys;
- j\) destroying keys;
- k\) logging and auditing of key management related activities;
- l\) setting activation and deactivation dates for keys so that the keys can only be used for the period of time according to the organization's rules on key management;
- m\) handling legal requests for access to cryptographic keys (e.g. encrypted information can be required to be made available in an unencrypted form as evidence in a court case).
-
-All cryptographic keys should be protected against modification and loss. In addition, secret and private keys need protection against unauthorized use as well as disclosure. Equipment used to generate, store and archive keys should be physically protected.
-
-In addition to integrity, for many use cases, the authenticity of public keys should also be considered.
-
-**Other information**
-The authenticity of public keys is usually addressed by public key management processes using certificate authorities and public key certificates, but it is also possible to address it by using technologies such as applying manual processes for small number keys.
-
-Cryptography can be used to achieve different information security objectives, for example:
-
-a\) confidentiality: using encryption of information to protect sensitive or critical information, either stored or transmitted;
-b\) integrity or authenticity: using digital signatures or message authentication codes to verify the authenticity or integrity of stored or transmitted sensitive or critical information. Using algorithms for the purpose of file integrity checking;
-c\) non-repudiation: using cryptographic techniques to provide evidence of the occurrence or non-occurrence of an event or action;
-d\) authentication: using cryptographic techniques to authenticate users and other system entities requesting access to or transacting with system users, entities and resources.
-
-The ISO/IEC 11770 series provides further information on key management.
\ No newline at end of file
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.25_OT Secure development life cycle.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.25_OT Secure development life cycle.md
deleted file mode 100644
index ea0b64c..0000000
--- a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.25_OT Secure development life cycle.md
+++ /dev/null
@@ -1,45 +0,0 @@
----
-tags:
- - iso27001/2022/EN
----
-## 8.25 Secure development life cycle
-
-| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains |
-| ------------ | ----------------------------------------- | ---------------------- | -------------------------------------------------- | ---------------- |
-| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Application_security #System_and_network_security | #Protection |
-
-**Control**
-Rules for the secure development of software and systems should be established and applied.
-
-**Purpose**
-To ensure information security is designed and implemented within the secure development life cycle of software and systems.
-
-**Guidance**
-Secure development is a requirement to build up a secure service, architecture, software and system. To achieve this, the following aspects should be considered:
-
-a\) separation of development, test and production environments (see [[ISO_27002_2022_8.31_OT Separation of development, test and production environments|8.31]]);
-
-b\) guidance on the security in the software development life cycle:
- 1\) security in the software development methodology (see [[ISO_27002_2022_8.28_OT Secure coding|8.28]] and [[ISO_27002_2022_8.27_OT Secure system architecture and engineering principles|8.27]]);
- 2\) secure coding guidelines for each programming language used (see [[ISO_27002_2022_8.28_OT Secure coding|8.28]]);
-
-c\) security requirements in the specification and design phase (see [[ISO_27002_2022_5.8_OT Information security in project management|5.8]]);
-
-d\) security checkpoints in projects (see [[ISO_27002_2022_5.8_OT Information security in project management|5.8]]);
-
-e\) system and security testing, such as regression testing, code scan and penetration tests (see [[ISO_27002_2022_8.29_OT Security testing in development and acceptance|8.29]]);
-
-f\) secure repositories for source code and configuration (see [[ISO_27002_2022_8.4_OT Access to source code|8.4]] and [[ISO_27002_2022_8.9_OT Configuration management|8.9]]);
-
-g\) security in the version control (see [[ISO_27002_2022_8.32_OT Change management|8.32]]);
-
-h\) required application security knowledge and training (see [[ISO_27002_2022_8.28_OT Secure coding|8.28]]);
-
-i\) developers’ capability for preventing, finding and fixing vulnerabilities (see [[ISO_27002_2022_8.28_OT Secure coding|8.28]]);
-
-j\) licensing requirements and alternatives to ensure cost-effective solutions while avoiding future licensing issues (See [[ISO_27002_2022_5.32_OT Intellectual property rights|5.32]]).
-
-If development is outsourced, the organization should obtain assurance that the supplier complies with the organization’s rules for secure development (see [[ISO_27002_2022_8.30_OT Outsourced development|8.30]]).
-
-**Other information**
-Development can also take place inside applications, such as office applications, scripting, browsers and databases.
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.26_OT Application security requirements.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.26_OT Application security requirements.md
deleted file mode 100644
index 52f134b..0000000
--- a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.26_OT Application security requirements.md
+++ /dev/null
@@ -1,89 +0,0 @@
-#iso27002/2022/EN
-## 8.26 Application security requirements
-
-| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains |
-| ------------ | ----------------------------------------- | ---------------------- | -------------------------------------------------- | -------------------- |
-| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Application_security #System_and_network_security | #Protection #Defence |
-#### Control
-Information security requirements should be identified, specified and approved when developing or acquiring applications.
-#### Purpose
-To ensure all information security requirements are identified and addressed when developing or acquiring applications.
-#### Guidance
-
-General
-
-Application security requirements should be identified and specified. These requirements are usually determined through a risk assessment. The requirements should be developed with the support of information security specialists.
-
-Application security requirements can cover a wide range of topics, depending on the purpose of the application.
-
-Application security requirements should include, as applicable:
-
-a\) level of trust in identity of entities \[e.g. through authentication (see [[ISO_27002_OT 5.17 Authentication information|5.17]], [[ISO_27002_OT 8.2 Privileged access rights\|8.2]] and [[ISO_27002_OT 8.5 Secure authentication|8.5]])];
-
-b\) identifying the type of information and classification level to be processed by the application;
-
-c\) need for segregation of access and level of access to data and functions in the application;
-
-d\) resilience against malicious attacks or unintentional disruptions \[e.g. protection against buffer overflow or structured query language (SQL) injections\];
-
-e\) legal, statutory and regulatory requirements in the jurisdiction where the transaction is generated, processed, completed or stored;
-
-f\) need for privacy associated with all parties involved;
-
-g\) the protection requirements of any confidential information;
-
-h\) protection of data while being processed, in transit and at rest;
-
-i\) need to securely encrypt communications between all involved parties;
-
-j\) input controls, including integrity checks and input validation;
-
-k\) automated controls (e.g. approval limits or dual approvals);
-
-l\) output controls, also considering who can access outputs and its authorization;
-
-m\) restrictions around content of "free-text" fields, as these can lead to uncontrolled storage of confidential data (e.g. personal data);
-
-n\) requirements derived from the business process, such as transaction logging and monitoring, nonrepudiation requirements;
-
-o\) requirements mandated by other security controls (e.g. interfaces to logging and monitoring or data leakage detection systems);
-
-p) error message handling.
-
-Transactional services
-
-Additionally, for applications offering transactional services between the organization and a partner, the following should be considered when identifying information security requirements:
-
-a\) the level of trust each party requires in each other’s claimed identity;
-
-b\) the level of trust required in the integrity of information exchanged or processed and the mechanisms for identification of lack of integrity (e.g. cyclic redundancy check, hashing, digital signatures);
-
-c\) authorization processes associated with who can approve contents of, issue or sign key transactional documents;
-
-d\) confidentiality, integrity, proof of dispatch and receipt of key documents and the non-repudiation (e.g. contracts associated with tendering and contract processes);
-
-e\) the confidentiality and integrity of any transactions (e.g. orders, delivery address details and confirmation of receipts);
-
-f\) requirements on how long to maintain a transaction confidential;
-
-g\) insurance and other contractual requirements.
-
-Electronic ordering and payment applications
-
-Additionally, for applications involving electronic ordering and payment, the following should be considered:
-
-a\) requirements for maintaining the confidentiality and integrity of order information;
-
-b\) the degree of verification appropriate to verify payment information supplied by a customer;
-
-c\) avoidance of loss or duplication of transaction information;
-
-d\) storing transaction details outside of any publicly accessible environment (e.g. on a storage platform existing on the organizational intranet, and not retained and exposed on electronic storage media directly accessible from the internet);
-
-e\) where a trusted authority is used (e.g. for the purposes of issuing and maintaining digital signatures or digital certificates) security is integrated and embedded throughout the entire end-to-end certificate or signature management process.
-
-Several of the above considerations can be addressed by the application of cryptography (see [[8.24]]), taking into consideration legal requirements (see [[5.31]], [[5.36]], especially see [[5.31]] for cryptography legislation).
-
-**Other information**
-
-Applications accessible via networks are subject to a range of network related threats, such as fraudulent activities, contract disputes or disclosure of information to the public; incomplete transmission, mis- routing, unauthorized message alteration, duplication or replay. Therefore, detailed risk assessments and careful determination of controls are indispensable. Controls required often include cryptographic methods for authentication and securing data transfer.
\ No newline at end of file
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.27_OT Secure system architecture and engineering principles.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.27_OT Secure system architecture and engineering principles.md
deleted file mode 100644
index 05d7591..0000000
--- a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.27_OT Secure system architecture and engineering principles.md
+++ /dev/null
@@ -1,84 +0,0 @@
----
-tags:
- - iso27001/2022/EN
----
-## 8.27 Secure system architecture and engineering principles
-
-| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains |
-| ------------ | ----------------------------------------- | ---------------------- | -------------------------------------------------- | ---------------- |
-| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Application_security #System_and_network_security | #Protection |
-
-**Control**
-Principles for engineering secure systems should be established, documented, maintained and applied to any information system development activities.
-
-**Purpose**
-To ensure information systems are securely designed, implemented and operated within the development life cycle.
-
-**Guidance**
-Security engineering principles should be established, documented and applied to information system engineering activities. Security should be designed into all architecture layers (business, data, applications and technology). New technology should be analysed for security risks and the design should be reviewed against known attack patterns.
-
-Secure engineering principles provide guidance on user authentication techniques, secure session control and data validation and sanitisation.
-
-Secure system engineering principles should include analysis of:
-
-a\) the full range of security controls required to protect information and systems against identified threats;
-
-b\) the capabilities of security controls to prevent, detect or respond to security events;
-
-c\) specific security controls required by particular business processes (e.g. encryption of sensitive information, integrity checking and digitally signing information);
-
-d\) where and how security controls are to be applied (e.g. by integrating with a security architecture and the technical infrastructure);
-
-e\) how individual security controls (manual and automated) work together to produce an integrated set of controls.
-
-Security engineering principles should take account of:
-
-a\) the need to integrate with a security architecture;
-
-b\) technical security infrastructure \[e.g. public key infrastructure (PKI), identity and access management (IAM), data leakage prevention and dynamic access management\];
-
-c\) capability of the organization to develop and support the chosen technology;
-
-d\) cost, time and complexity of meeting security requirements;
-
-e\) current good practices.
-
-Secure system engineering should involve:
-
-a\) the use of security architecture principles, such as “security by design”, “defense in depth”, “security by default”, “default deny”, “fail securely”, “distrust input from external applications”, “security in deployment”, “assume breach”, "least privilege", “usability and manageability” and “least functionality”;
-
-b\) a security-oriented design review to help identify information security vulnerabilities, ensure security controls are specified and meet security requirements;
-
-c\) documentation and formal acknowledgement of security controls that do not fully meet requirements (e.g. due to overriding safety requirements);
-
-d\) hardening of systems.
-
-The organization should consider "zero trust" principles such as:
-
-a\) assuming the organization’s information systems are already breached and thus not be reliant on network perimeter security alone;
-
-b\) employing a “never trust and always verify” approach for access to information systems;
-
-c\) ensuring that requests to information systems are encrypted end-to-end;
-
-d\) verifying each request to an information system as if it originated from an open, external network, even if these requests originated internal to the organization (i.e. not automatically trusting anything inside or outside its perimeters);
-
-e\) using "least privilege" and dynamic access control techniques (see 5.15, 5.18and 8.2). This includes authenticating and authorizing requests for information or to systems based on contextual information such as authentication information (see 5.17), user identities (see 5.16), data about the user endpoint device, and data classification (see >5.12>);
-
-f\) always authenticating requesters and always validating authorization requests to information systems based on information including authentication information (see >5.17>) and user identities (>5.16>), data about the user endpoint device, and data classification (see >5.12>), for example enforcing strong authentication (e.g. multi-factor, see >8.5>).
-
-The established security engineering principles should be applied, where applicable, to outsourced development of information systems through the contracts and other binding agreements between the organization and the supplier to whom the organization outsources. The organization should ensure that suppliers’ security engineering practices align with the organization’s needs.
-
-The security engineering principles and the established engineering procedures should be regularly reviewed to ensure that they are effectively contributing to enhanced standards of security within the engineering process. They should also be regularly reviewed to ensure that they remain up-to- date in terms of combatting any new potential threats and in remaining applicable to advances in the technologies and solutions being applied.
-
-**Other information**
-
-Secure engineering principles can be applied to the design or configuration of a range of techniques, such as:
-
-- fault tolerance and other resilience techniques;
-- segregation (e.g. through virtualization or containerization);
-- tamper resistance.
-
-Secure virtualization techniques can be used to prevent interference between applications running on the same physical device. If a virtual instance of an application is compromised by an attacker, only that instance is affected. The attack has no effect on any other application or data.
-
-Tamper resistance techniques can be used to detect tampering of information containers, whether physical (e.g. a burglar alarm) or logical (e.g. a data file). A characteristic of such techniques is that there is a record of the attempt to tamper with the container. In addition, the control can prevent the successful extraction of data through its destruction (e.g. device memory can be deleted).
\ No newline at end of file
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.28_OT Secure coding.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.28_OT Secure coding.md
deleted file mode 100644
index e35e279..0000000
--- a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.28_OT Secure coding.md
+++ /dev/null
@@ -1,93 +0,0 @@
----
-tags:
- - iso27001/2022/EN
----
-
-| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains |
-| ------------ | ----------------------------------------- | ---------------------- | -------------------------------------------------- | ---------------- |
-| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Application_security #System_and_network_security | #Protection |
-
-## 8.28 Secure coding
-
-#### Control
-Secure coding principles should be applied to software development.
-#### Purpose
-To ensure software is written securely thereby reducing the number of potential information security vulnerabilities in the software.
-#### Guidance
-
-**General**
-
-The organization should establish organization-wide processes to provide good governance for secure coding. A minimum secure baseline should be established and applied. Additionally, such processes and governance should be extended to cover software components from third parties and open source software.
-
-The organization should monitor real world threats and up-to-date advice and information on software vulnerabilities to guide the organization’s secure coding principles through continual improvement and learning. This can help with ensuring effective secure coding practices are implemented to combat the fast-changing threat landscape.
-
-**Planning and before coding**
-
-Secure coding principles should be used both for new developments and in reuse scenarios. These principles should be applied to development activities both within the organization and for products and services supplied by the organization to others.
-
-Planning and prerequisites before coding should include:
-
-a) organization-specific expectations and approved principles for secure coding to be used for both in-house and outsourced code developments;
-b) common and historical coding practices and defects that lead to information security vulnerabilities;
-c) configuring development tools, such as integrated development environments (IDE), to help enforce the creation of secure code;
-d) following guidance issued by the providers of development tools and execution environments as applicable;
-e) maintenance and use of updated development tools (e.g. compilers);
-f) qualification of developers in writing secure code;
-g) secure design and architecture, including threat modeling;
-h) secure coding standards and where relevant mandating their use;
-i) use of controlled environments for development.
-
-**During coding**
-
-Considerations during coding should include:
-
-a) secure coding practices specific to the programming languages and techniques being used;
-b) using secure programming techniques, such as pair programming, refactoring, peer review, security iterations and test-driven development;
-c) using structured programming techniques;
-d) documenting code and removing programming defects, which can allow information security vulnerabilities to be exploited;
-e) prohibiting the use of insecure design techniques (e.g. the use of hard-coded passwords, unapproved code samples and unauthenticated web services).
-
-Testing should be conducted during and after development (see [[ISO_27002_OT 8.29 Security testing in development and acceptance|8.29]]). Static application security testing (SAST) processes can identify security vulnerabilities in software.
-
-Before software is made operational, the following should be evaluated:
-a) attack surface and the principle of least privilege;
-b) conducting an analysis of the most common programming errors and documenting that these have been mitigated.
-
-**Review and maintenance**
-
-After code has been made operational:
-
-a) updates should be securely packaged and deployed;
-b) reported information security vulnerabilities should be handled (see [[ISO_27002_OT 8.8 Management of technical vulnerabilities|8.8]]);
-c) errors and suspected attacks should be logged and logs regularly reviewed to make adjustments to the code as necessary;
-d) source code should be protected against unauthorized access and tampering (e.g. by using configuration management tools, which typically provide features such as access control and version control).
-
-If using external tools and libraries, the organization should consider:
-
-a) ensuring that external libraries are managed (e.g. by maintaining an inventory of libraries used and their versions) and regularly updated with release cycles;
-b) selection, authorization and reuse of well-vetted components, particularly authentication and cryptographic components;
-c) the licence, security and history of external components;
-d) ensuring that software is maintainable, tracked and originates from proven, reputable sources;
-e) sufficiently long-term availability of development resources and artefacts.
-
-Where a software package needs to be modified the following points should be considered:
-
-a) the risk of built-in controls and integrity processes being compromised;
-b) whether to obtain the consent of the vendor;
-c) the possibility of obtaining the required changes from the vendor as standard program updates;
-d) the impact if the organization becomes responsible for the future maintenance of the software as a result of changes;
-e) compatibility with other software in use.
-
-**Other** **information**
-
-A guiding principle is to ensure security-relevant code is invoked when necessary and is tamper- resistant. Programs installed from compiled binary code also have these properties but only for data held within the application. For interpreted languages, the concept only works when the code is executed on a server that is otherwise inaccessible by the users and processes that use it, and that its data is held in a similarly protected database. For example, the interpreted code can be run on a cloud service where access to the code itself requires administrator privileges. Such administrator access should be protected by security mechanisms such as just-in-time administration principles and strong authentication. If the application owner can access scripts by direct remote access to the server, so in principle can an attacker. Webservers should be configured to prevent directory browsing in such cases.
-
-Application code is best designed on the assumption that it is always subject to attack, through error or malicious action. In addition, critical applications can be designed to be tolerant of internal faults. For example, the output from a complex algorithm can be checked to ensure that it lies within safe bounds before the data is used in an application such as a safety or financial critical application. The code that performs the boundary checks is simple and therefore much easier to prove correctness.
-
-Some web applications are susceptible to a variety of vulnerabilities that are introduced by poor design and coding, such as database injection and cross-site scripting attacks. In these attacks, requests can be manipulated to abuse the webserver functionality.
-
-More information on ICT security evaluation can be found in the ISO/IEC 15408 series.
-# Related:
-- [[ISO_27002_PE 8.28 Secure coding]]
-- [[ISO_27002_OT 8.29 Security testing in development and acceptance]]
-- [[ISO_27002_OT 8.8 Management of technical vulnerabilities]]
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.7_OT Protection against malware.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.7_OT Protection against malware.md
deleted file mode 100644
index d8b221b..0000000
--- a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.7_OT Protection against malware.md
+++ /dev/null
@@ -1,57 +0,0 @@
-#iso27002/2022/EN
-
-# 8.7 Protection against malware
-
-| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains |
-| ---------------------------------- | ----------------------------------------- | ---------------------- | ---------------------------------------------------- | -------------------- |
-| #Preventive #Detective #Corrective | #Confidentiality #Integrity #Availability | #Protect #Detect | #System_and_network_security #Information_protection | #Protection #Defence |
-## Control
-Protection against malware should be implemented and supported by appropriate user awareness.
-## Purpose
-To ensure information and other associated assets are protected against malware.
-## Guidance
-Protection against malware should be based on malware detection and repair software, information security awareness, appropriate system access and change management controls. Use of malware detection and repair software alone is not usually adequate. The following guidance should be considered:
-
-a) implementing rules and controls that prevent or detect the use of unauthorized software \[e.g. application allowlisting (i.e. using a list providing allowed applications)] (see [[ISO_27002_OT 8.19 Installation of software on operational systems|8.19]] and [[ISO_27002_OT 8.32 Change management|8.32]])
-
-b) implementing controls that prevent or detect the use of known or suspected malicious websites (e.g. blocklisting);
-
-c) reducing vulnerabilities that can be exploited by malware \[e.g. through technical vulnerability management (see [[ISO_27002_OT 8.8 Management of technical vulnerabilities|8.8]] and [[ISO_27002_OT 8.19 Installation of software on operational systems|8.19]])];
-
-d) conducting regular automated validation of the software and data content of systems, especially for systems supporting critical business processes; investigating the presence of any unapproved files or unauthorized amendments;
-
-e) establishing protective measures against risks associated with obtaining files and software either from or via external networks or on any other medium;
-
-f) installing and regularly updating malware detection and repair software to scan computers and electronic storage media. Carrying out regular scans that include:
-
-1) scanning any data received over networks or via any form of electronic storage media, for malware before use;
-
-2) scanning email and instant messaging attachments and downloads for malware before use. Carrying out this scan at different places (e.g. at email servers, desktop computers) and when entering the network of the organization;
-
-3) scanning webpages for malware when accessed;
-
-g) determining the placement and configuration of malware detection and repair tools based on risk assessment outcomes and considering:
-
-1) defence in depth principles where they would be most effective. For example, this can lead to malware detection in a network gateway (in various application protocols such as email, file transfer and web) as well as user endpoint devices and servers;
-2) the evasive techniques of attackers (e.g. the use of encrypted files) to deliver malware or the use of encryption protocols to transmit malware;
-
-h) taking care to protect against the introduction of malware during maintenance and emergency procedures, which can bypass normal controls against malware;
-
-i) implementing a process to authorize temporarily or permanently disable some or all measures against malware, including exception approval authorities, documented justification and review date. This can be necessary when the protection against malware causes disruption to normal operations;
-
-j) preparing appropriate business continuity plans for recovering from malware attacks, including
-all necessary data and software backup (including both online and offline backup) and recovery measures (see [[ISO_27002_OT 8.13 Information backup|8.13]]);
-
-k) isolating environments where catastrophic consequences can occur;
-
-l) defining procedures and responsibilities to deal with protection against malware on systems, including training in their use, reporting and recovering from malware attacks;
-
-m) providing awareness or training (see [[ISO_27002_OT 6.3 Information security awareness, education and training|6.3]]) to all users on how to identify and potentially mitigate the receipt, sending or installation of malware infected emails, files or programs \[the information collected in n) and o) can be used to ensure awareness and training are kept up-to-date];
-
-n) implementing procedures to regularly collect information about new malware, such as subscribing to mailing lists or reviewing relevant websites;
-
-o) verifying that information relating to malware, such as warning bulletins, comes from qualified and reputable sources (e.g. reliable internet sites or suppliers of malware detection software) and is accurate and informative.
-
-## Other **information**
-
-It is not always possible to install software that protects against malware on some systems (e.g. some industrial control systems). Some forms of malware infect computer operating systems and computer firmware such that common malware controls cannot clean the system and a full reimaging of the operating system software and sometimes the computer firmware is necessary to return to a secure state.
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.8_OT Management of technical vulnerabilities.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.8_OT Management of technical vulnerabilities.md
deleted file mode 100644
index 72884b4..0000000
--- a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.8_OT Management of technical vulnerabilities.md
+++ /dev/null
@@ -1,130 +0,0 @@
-#iso27002/2022/EN
-## 8.8 Management of technical vulnerabilities
-
-| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains |
-| ------------ | ----------------------------------------- | ---------------------- | ------------------------------------ | ---------------------------------------------- |
-| #Preventive | #Confidentiality #Integrity #Availability | #Identify #Protect | #Threat_and_vulnerability_management | #Governance_and_Ecosystem #Protection #Defence |
-
-**Control**
-Information about technical vulnerabilities of information systems in use should be obtained, the organization’s exposure to such vulnerabilities should be evaluated and appropriate measures should be taken.
-
-**Purpose**
-To prevent exploitation of technical vulnerabilities.
-
-**Guidance**
-
-Identifying technical vulnerabilities
-
-The organization should have an accurate inventory of assets (see 5.9 to 5.14) as a prerequisite for effective technical vulnerability management; the inventory should include the software vendor, software name, version numbers, current state of deployment (e.g. what software is installed on what systems) and the person(s) within the organization responsible for the software.
-
-To identify technical vulnerabilities, the organization should consider:
-
-a\) defining and establishing the roles and responsibilities associated with technical vulnerability management, including vulnerability monitoring, vulnerability risk assessment, updating, asset tracking and any coordination responsibilities required;
-b\) for software and other technologies (based on the asset inventory list, see 5.9), identifying information resources that will be used for identifying relevant technical vulnerabilities and maintaining awareness about them. Updating the list of information resources based on changes in the inventory or when other new or useful resources are found;
-c\) requiring suppliers of information system (including their components) to ensure vulnerability reporting, handling and disclosure, including the requirements in applicable contracts (see 5.20);
-d\) using vulnerability scanning tools suitable for the technologies in use to identify vulnerabilities and to verify whether the patching of vulnerabilities was successful;
-e\) conducting planned, documented and repeatable penetration tests or vulnerability assessments by competent and authorized persons to support the identification of vulnerabilities. Exercising caution as such activities can lead to a compromise of the security of the system;
-f\) tracking the usage of third-party libraries and source code for vulnerabilities. This should be included in secure coding (see 8.28).
-
-The organization should develop procedures and capabilities to:
-
-a\) detect the existence of vulnerabilities in its products and services including any external component used in these;
-b\) receive vulnerability reports from internal or external sources.
-
-The organization should provide a public point of contact as part of a topic-specific policy on vulnerability disclosure so that researchers and others are able to report issues. The organization should establish vulnerability reporting procedures, online reporting forms and making use of appropriate threat intelligence or information sharing forums. The organization should also consider bug bounty programs where rewards are offered as an incentive to assist organizations in identifying vulnerabilities in order to appropriately remediate them. The organization should also share information with competent industry bodies or other interested parties.
-
-Evaluating technical vulnerabilities
-
-To evaluate identified technical vulnerabilities, the following guidance should be considered:
-
-a\) analyse and verify reports to determine what response and remediation activity is needed;
-b\) once a potential technical vulnerability has been identified, identifying the associated risks and the actions to be taken. Such actions can involve updating vulnerable systems or applying other controls.
-
-Taking appropriate measures to address technical vulnerabilities
-
-A software update management process should be implemented to ensure the most up-to-date approved patches and application updates are installed for all authorized software. If changes are necessary, the original software should be retained and the changes applied to a designated copy. All changes should be fully tested and documented, so that they can be reapplied, if necessary, to future software upgrades. If required, the modifications should be tested and validated by an independent evaluation body.
-
-The following guidance should be considered to address technical vulnerabilities:
-
-a\) taking appropriate and timely action in response to the identification of potential technical vulnerabilities; defining a timeline to react to notifications of potentially relevant technical vulnerabilities;
-b\) depending on how urgently a technical vulnerability needs to be addressed, carrying out the action according to the controls related to change management (see 8.32) or by following information security incident response procedures (see 5.26);
-c\) only using updates from legitimate sources (which can be internal or external to the organization);
-d\) testing and evaluating updates before they are installed to ensure they are effective and do not result in side effects that cannot be tolerated \[i.e. if an update is available, assessing the risks associated with installing the update (the risks posed by the vulnerability should be compared with the risk of installing the update)\];
-e\) addressing systems at high risk first;
-f\) develop remediation (typically software updates or patches);
-g\) test to confirm if the remediation or mitigation is effective;
-h\) provide mechanisms to verify the authenticity of remediation;
-
-i\) if no update is available or the update cannot be installed, considering other controls, such as:
-1\) applying any workaround suggested by the software vendor or other relevant sources;
-2\) turning off services or capabilities related to the vulnerability;
-3\) adapting or adding access controls (e.g. firewalls) at network borders (see 8.20to 8.22);
-4\) shielding vulnerable systems, devices or applications from attack through deployment of suitable traffic filters (sometimes called virtual patching);
-5\) increasing monitoring to detect actual attacks;
-6\) raising awareness of the vulnerability.
-
-For acquired software, if the vendors regularly release information about security updates for their software and provide a facility to install such updates automatically, the organization should decide whether to use the automatic update or not.
-
-
-
-Other considerations
-
-
-
-An audit log should be kept for all steps undertaken in technical vulnerability management.
-
-
-
-The technical vulnerability management process should be regularly monitored and evaluated in order to ensure its effectiveness and efficiency.
-
-
-
-An effective technical vulnerability management process should be aligned with incident management activities, to communicate data on vulnerabilities to the incident response function and provide technical procedures to be carried out in case an incident occurs.
-
-
-
-Where the organization uses a cloud service supplied by a third-party cloud service provider, technical vulnerability management of cloud service provider resources should be ensured by the cloud service provider. The cloud service provider’s responsibilities for technical vulnerability management should be part of the cloud service agreement and this should include processes for reporting the cloud service provider's actions relating to technical vulnerabilities (see 5.23). For some cloud services, there are respective responsibilities for the cloud service provider and the cloud service customer. For example, the cloud service customer is responsible for vulnerability management of its own assets used for the cloud services.
-
-
-
-**Other information**
-
-
-
-Technical vulnerability management can be viewed as a sub-function of change management and as such can take advantage of the change management processes and procedures (see 8.32).
-
-
-
-There is a possibility that an update does not address the problem adequately and has negative side effects. Also, in some cases, uninstalling an update cannot be easily achieved once the update has been applied.
-
-
-
-If adequate testing of the updates is not possible (e.g. because of costs or lack of resources) a delay in updating can be considered to evaluate the associated risks, based on the experience reported by other users. The use of ISO/IEC 27031 can be beneficial.
-
-
-
-Where software patches or updates are produced, the organization can consider providing an automated update process where these updates are installed on affected systems or products without the need for intervention by the customer or the user. If an automated update process is offered, it can allow the customer or user to choose an option to turn off the automatic update or control the timing of the installation of the update.
-
-
-
-Where the vendor provides an automated update process and the updates can be installed on affected systems or products without the need for intervention, the organization determines if it applies the automated process or not. One reason for not electing for automated update is to retain control over when the update is performed. For example, a software used for a business operation cannot be updated until the operation has completed.
-
-
-
-A weakness with vulnerability scanning is that it is possible it does not fully account for defence in depth: two countermeasures that are always invoked in sequence can have vulnerabilities that are masked by strengths in the other. The composite countermeasure is not vulnerable, whereas a vulnerability scanner can report that both components are vulnerable. The organization should therefore take care in reviewing and acting on vulnerability reports.
-
-
-
-Many organizations supply software, systems, products and services not only within the organization but also to interested parties such as customers, partners or other users. These software, systems, products and services can have information security vulnerabilities that affect the security of users.
-
-
-
-Organizations can release remediation and disclose information about vulnerabilities to users (typically through a public advisory) and provide appropriate information for software vulnerability database services.
-
-
-
-For mor e information relating to the management of technical vulnerabilities when using cloud computing, see the ISO/IEC 19086 series and ISO/IEC 27017.
-
-
-
-ISO/IEC 29147 provides detailed information on receiving vulnerability reports and publishing vulnerability advisories. ISO/IEC 30111 provides detailed information about handling and resolving reported vulnerabilities.
\ No newline at end of file
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.9_OT Configuration management.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.9_OT Configuration management.md
deleted file mode 100644
index 722e1a7..0000000
--- a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-1/ISO_27002_2022_8.9_OT Configuration management.md
+++ /dev/null
@@ -1,74 +0,0 @@
-#iso27002/2022/EN
-## 8.9 Configuration management
-| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains |
-| ------------ | ----------------------------------------- | ---------------------- | ------------------------ | ---------------- |
-| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Secure_configuration | #Protection |
-### Control
-Configurations, including security configurations, of hardware, software, services and networks should be established, documented, implemented, monitored and reviewed.
-### Purpose
-To ensure hardware, software, services and networks function correctly with required security settings, and configuration is not altered by unauthorized or incorrect changes.
-### Guidance
-
-#### General
-The organization should define and implement processes and tools to enforce the defined configurations (including security configurations) for hardware, software, services (e.g. cloud services) and networks, for newly installed systems as well as for operational systems over their lifetime.
-
-Roles, responsibilities and procedures should be in place to ensure satisfactory control of all configuration changes.
-#### Standard templates
-
-Standard templates for the secure configuration of hardware, software, services and networks should be defined:
-
-a) using publicly available guidance (e.g. pre-defined templates from vendors and from independent security organizations);
-
-b) considering the level of protection needed in order to determine a sufficient level of security;
-
-c) supporting the organization’s information security policy, topic-specific policies, standards and other security requirements;
-
-d) considering the feasibility and applicability of security configurations in the organization’s context.
-
-The templates should be reviewed periodically and updated when new threats or vulnerabilities need to be addressed, or when new software or hardware versions are introduced.
-
-The following should be considered for establishing standard templates for the secure configuration of hardware, software, services and networks:
-
-a) minimizing the number of identities with privileged or administrator level access rights;
-
-b) disabling unnecessary, unused or insecure identities;
-
-c) disabling or restricting unnecessary functions and services;
-
-d) restricting access to powerful utility programs and host parameter settings;
-
-e) synchronizing clocks;
-
-f) changing vendor default authentication information such as default passwords immediately after installation and reviewing other important default security-related parameters;
-
-g) invoking time-out facilities that automatically log off computing devices after a predetermined period of inactivity;
-
-h) verifying that license requirements have been met (see 5.32).
-#### Managing configurations
-Established configurations of hardware, software, services and networks should be recorded and a log should be maintained of all configuration changes. These records should be securely stored. This can be achieved in various ways, such as configuration databases or configuration templates.
-
-Changes to configurations should follow the change management process (see 8.32).
-
-Configuration records can contain as relevant:
-
-a) up-to-date owner or point of contact information for the asset;
-
-b) date of the last change of configuration;
-
-c) version of configuration template;
-
-d) relation to configurations of other assets.
-#### Monitoring configurations
-Configurations should be monitored with a comprehensive set of system management tools (e.g. maintenance utilities, remote support, enterprise management tools, backup and restore software) and should be reviewed on a regular basis to verify configuration settings, evaluate password strengths and assess activities performed. Actual configurations can be compared with the defined target templates. Any deviations should be addressed, either by automatic enforcement of the defined target configuration or by manual analysis of the deviation followed by corrective actions.
-### Other information
-Documentation for systems often records details about the configuration of both hardware and software.
-
-System hardening is a typical part of configuration management.
-
-Configuration management can be integrated with asset management processes and associated tooling.
-
-Automation is usually more effective to manage security configuration (e.g. using infrastructure as code).
-
-Configuration templates and targets can be confidential information and should be protected from unauthorized access accordingly.
-# Related:
-- [[ISO_27002_2022_8.9_MoC Configuration management|8.9 Configuration management]]
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-2/.DS_Store b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-2/.DS_Store
deleted file mode 100644
index 5008ddf..0000000
Binary files a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-2/.DS_Store and /dev/null differ
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-2/ISO_27002_2022_5.17_OT Authentication information.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-2/ISO_27002_2022_5.17_OT Authentication information.md
deleted file mode 100644
index 2c0bb5a..0000000
--- a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-2/ISO_27002_2022_5.17_OT Authentication information.md
+++ /dev/null
@@ -1,74 +0,0 @@
-#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 user’s identity. Other types of authentication information are cryptographic keys, data stored on hardware tokens (e.g. smart cards) that produce authentication codes and biometric data such as iris scans or fingerprints. Additional information can be found in the ISO/IEC 24760 series.
-
-Requiring frequent change of passwords can be problematic because users can get annoyed by the frequent changes, forget new passwords, note them down in unsafe places, or choose unsafe passwords. Provision of single sign on (SSO) or other authentication management tools (e.g. password vaults) reduces the amount of authentication information that users are required to protect and can thereby increase the effectiveness of this control. However, these tools can also increase the impact of disclosure of authentication information.
-
-Some applications require user passwords to be assigned by an independent authority. In such cases, a), c) and d) of "Password management system" do not apply.
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-2/ISO_27002_2022_5.19_OT Information security in supplier relationships.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-2/ISO_27002_2022_5.19_OT Information security in supplier relationships.md
deleted file mode 100644
index 11664ac..0000000
--- a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-2/ISO_27002_2022_5.19_OT Information security in supplier relationships.md
+++ /dev/null
@@ -1,71 +0,0 @@
-#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 supplier’s products or services.
-
-**Purpose**
-
-To maintain an agreed level of information security in supplier relationships.
-
-**Guidance**
-
-The organization should establish and communicate a topic-specific policy on supplier relationships to all relevant interested parties.
-
-The organization should identify and implement processes and procedures to address security risks associated with the use of products and services provided by suppliers. This should also apply to the organization’s use of resources of cloud service providers. These processes and procedures should include those to be implemented by the organization, as well as those the organization requires the supplier to implement for the commencement of use of a supplier’s products or services or for the termination of use of a supplier’s products and services, such as:
-
-a\) identifying and documenting the types of suppliers (e.g. ICT services, logistics, utilities, financial services, ICT infrastructure components) which can affect the confidentiality, integrity and availability of the organization's information;
-
-b\) establishing how to evaluate and select suppliers according to the sensitivity of information, products and services (e.g. with market analysis, customer references, review of documents, on-site assessments, certifications);
-
-c\) evaluating and selecting supplier’s products or services that have adequate information security controls and reviewing them; in particular, accuracy and completeness of controls implemented by the supplier that ensure integrity of the supplier’s information and information processing and hence the organization’s information security;
-
-d\) defining the organization’s information, ICT services and the physical infrastructure that suppliers can access, monitor, control or use;
-
-e\) defining the types of ICT infrastructure components and services provided by suppliers which can affect the confidentiality, integrity and availability of the organization's information;
-
-f\) assessing and managing the information security risks associated with:
- 1\) the suppliers’ use of the organization’s information and other associated assets, including risks originating from potential malicious supplier personnel;
- 2\) malfunctioning or vulnerabilities of the products (including software components and sub-components used in these products) or services provided by the suppliers;
-
-g\) monitoring compliance with established information security requirements for each type of supplier and type of access, including third-party review and product validation;
-
-h\) mitigating non-compliance of a supplier, whether this was detected through monitoring or by other means;
-
-i\) handling incidents and contingencies associated with supplier products and services including responsibilities of both the organization and suppliers;
-
-j\) resilience and, if necessary, recovery and contingency measures to ensure the availability of the supplier’s information and information processing and hence the availability of the organization’s information;
-
-k\) awareness and training for the organization’s personnel interacting with supplier personnel regarding appropriate rules of engagement, topic-specific policies, processes and procedures and behaviour based on the type of supplier and the level of supplier access to the organization’s systems and information;
-
-l\) managing the necessary transfer of information, other associated assets and anything else that needs to be changed and ensuring that information security is maintained throughout the transfer period;
-
-m\) requirements to ensure a secure termination of the supplier relationship, including:
-
- 1\) de-provisioning of access rights;
- 2\) information handling;
- 3\) determining ownership of intellectual property developed during the engagement;
- 4\) information portability in case of change of supplier or insourcing;
- 6\) records management;
- 7\) return of assets;
- 8\) secure disposal of information and other associated assets;
- 9\) ongoing confidentiality requirements;
-
-n\) level of personnel security and physical security expected from supplier's personnel and facilities.
-
-The procedures for continuing information processing in the event that the supplier becomes unable to supply its products or services (e.g. because of an incident, because the supplier is no longer in business, or no longer provides some components due to technology advancements) should be considered to avoid any delay in arranging replacement products or services (e.g. identifying an alternative supplier in advance or always using alternative suppliers).
-
-**Other information**
-
-In cases where it is not possible for an organization to place requirements on a supplier, the organization should:
-
-a\) consider the guidance given in this control in making decisions about choosing a supplier and its product or service;
-
-b\) implement compensating controls as necessary based on a risk assessment.
-
-Information can be put at risk by suppliers with inadequate information security management. Controls should be determined and applied to manage the supplier's access to information and other associated assets. For example, if there is a special need for confidentiality of the information, non-disclosure agreements or cryptographic techniques can be used. Another example is personal data protection risks when the supplier agreement involves transfer of, or access to, information across borders. The organization needs to be aware that the legal or contractual responsibility for protecting information remains with the organization.
-
-Risks can also be caused by inadequate controls of ICT infrastructure components or services provided by suppliers. Malfunctioning or vulnerable components or services can cause information security breaches in the organization or to another entity (e.g. they can cause malware infection, attacks or other harm on entities other than the organization).
-
-See ISO/IEC 27036-2 for more detail.
\ No newline at end of file
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-2/ISO_27002_2022_5.20_OT Addressing information security within supplier agreements.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-2/ISO_27002_2022_5.20_OT Addressing information security within supplier agreements.md
deleted file mode 100644
index 55e407d..0000000
--- a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-2/ISO_27002_2022_5.20_OT Addressing information security within supplier agreements.md
+++ /dev/null
@@ -1,72 +0,0 @@
-#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 organization’s classification scheme (see [[5.10]], [[5.12]], [[5.13]])
-
-c\) mapping between the organization’s own classification scheme and the classification scheme of the supplier;
-
-d\) legal, statutory, regulatory and contractual requirements, including data protection, handling of personally identifiable information (PII), intellectual property rights and copyright and a description of how it will be ensured that they are met;
-
-e\) obligation of each contractual party to implement an agreed set of controls, including access control, performance review, monitoring, reporting and auditing, and the supplier’s obligations to comply with the organization’s information security requirements;
-
-f\) rules of acceptable use of information and other associated assets, including unacceptable use if necessary;
-
-g\) procedures or conditions for authorization and removal of the authorization for the use of the organization’s information and other associated assets by supplier personnel (e.g. through an explicit list of supplier personnel authorized to use the organization’s information and other associated assets);
-
-h\) information security requirements regarding the supplier’s ICT infrastructure; in particular, minimum information security requirements for each type of information and type of access to serve as the basis for individual supplier agreements based on the organization’s business needs and risk criteria;
-
-i\) indemnities and remediation for failure of contractor to meet requirements;
-
-j\) incident management requirements and procedures (especially notification and collaboration during incident remediation);
-
-k\) training and awareness requirements for specific procedures and information security requirements (e.g. for incident response, authorization procedures);
-
-l\) relevant provisions for sub-contracting, including the controls that need to be implemented, such as agreement on the use of sub-suppliers (e.g. requiring to have them under the same obligations of the supplier, requiring to have a list of sub-suppliers and notification before any change);
-
-m\) relevant contacts, including a contact person for information security issues;
-
-n\) any screening requirements, where legally permissible, for the supplier’s personnel, including responsibilities for conducting the screening and notification procedures if screening has not been completed or if the results give cause for doubt or concern;
-
-o\) the evidence and assurance mechanisms of third-party attestations for relevant information security requirements related to the supplier processes and an independent report on effectiveness of controls;
-
-p\) right to audit the supplier processes and controls related to the agreement;
-
-q\) supplier’s obligation to periodically deliver a report on the effectiveness of controls and agreement on timely correction of relevant issues raised in the report;
-
-r\) defect resolution and conflict resolution processes;
-
-s\) providing backup aligned with the organization’s needs (in terms of frequency and type and storage location);
-
-t\) ensuring the availability of an alternate facility (i.e. disaster recovery site) not subject to the same threats as the primary facility and considerations for fall back controls (alternate controls) in the event primary controls fail;
-
-u\) having a change management process that ensures advance notification to the organization and the possibility for the organization of not accepting changes;
-
-v\) physical security controls commensurate with the information classification;
-
-w\) information transfer controls to protect the information during physical transfer or logical transmission;
-
-x\) termination clauses upon conclusion of the agreement including records management, return of assets, secure disposal of information and other associated assets, and any ongoing confidentiality obligations;
-
-y\) provision of a method of securely destroying the organization’s information stored by the supplier as soon as it is no longer required;
-
-z\) ensuring, at the end of the contract, handover support to another supplier or to the organization itself.
-
-The organization should establish and maintain a register of agreements with external parties (e.g. contracts, memorandum of understanding, information-sharing agreements) to keep track of where their information is going. The organization should also regularly review, validate and update their agreements with external parties to ensure they are still required and fit for purpose with relevant information security clauses.
-
-**Other information**
-The agreements can vary considerably for different organizations and among the different types of suppliers. Therefore, care should be taken to include all relevant requirements for addressing information security risks.
-
-For details on supplier agreements, see ISO/IEC 27036 series. For cloud service agreements, see ISO/IEC 19086 series.
\ No newline at end of file
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-2/ISO_27002_2022_5.21_OT Managing information security in the ICT supply chain.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-2/ISO_27002_2022_5.21_OT Managing information security in the ICT supply chain.md
deleted file mode 100644
index bed7514..0000000
--- a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-2/ISO_27002_2022_5.21_OT Managing information security in the ICT supply chain.md
+++ /dev/null
@@ -1,58 +0,0 @@
-#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 organization’s security requirements throughout the supply chain if they sub-contract for parts of the ICT service provided to the organization;
-
-c\) requiring that ICT products suppliers propagate appropriate security practices throughout the supply chain if these products include components purchased or acquired from other suppliers or other entities (e.g. sub-contracted software developers and hardware component providers);
-
-d\) requesting that ICT products suppliers provide information describing the software components used in products;
-
-e\) requesting that ICT products suppliers provide information describing the implemented security functions of their product and the configuration required for its secure operation;
-
-f\) implementing a monitoring process and acceptable methods for validating that delivered ICT products and services comply with stated security requirements. Examples of such supplier review methods can include penetration testing and proof or validation of third-party attestations for the supplier’s information security operations;
-
-g\) implementing a process for identifying and documenting product or service components that are critical for maintaining functionality and therefore require increased attention, scrutiny and further follow up required when built outside of the organization especially if the supplier outsources aspects of product or service components to other suppliers;
-
-h\) obtaining assurance that critical components and their origin can be traced throughout the supply chain;
-
-i\) obtaining assurance that the delivered ICT products are functioning as expected without any unexpected or unwanted features;
-
-j\) implementing processes to ensure that components from suppliers are genuine and unaltered from their specification. Example measures include anti-tamper labels, cryptographic hash verifications or digital signatures. Monitoring for out of specification performance can be an indicator of tampering or counterfeits. Prevention and detection of tampering should be implemented during multiple stages in the system development life cycle, including design, development, integration, operations and maintenance;
-
-k\) obtaining assurance that ICT products achieve required security levels, for example, through formal certification or an evaluation scheme such as the Common Criteria Recognition Arrangement;
-
-l\) defining rules for sharing of information regarding the supply chain and any potential issues and compromises among the organization and suppliers;
-
-m\) implementing specific processes for managing ICT component life cycle and availability and associated security risks. This includes managing the risks of components no longer being available due to suppliers no longer being in business or suppliers no longer providing these components due to technology advancements. Identification of an alternative supplier and the process to transfer software and competence to the alternative supplier should be considered.
-
-**Other information**
-
-The specific ICT supply chain risk management practices are built on top of general information security, quality, project management and system engineering practices but do not replace them.
-
-Organizations are advised to work with suppliers to understand the ICT supply chain and any matters that have an important effect on the products and services being provided. The organization can influence ICT supply chain information security practices by making clear in agreements with their suppliers the matters that should be addressed by other suppliers in the ICT supply chain.
-
-ICT should be acquired from reputable sources. The reliability of software and hardware is a matter of quality control. While it is generally not possible for an organization to inspect the quality control systems of its vendors, it can make reliable judgments based on the reputation of the vendor.
-
-ICT supply chain as addressed here includes cloud services.
-
-Examples of ICT supply chains are:
-
-a\) cloud services provisioning, where the cloud service provider relies on the software developers, telecommunication service providers, hardware providers;
-
-b\) IoT, where the service involves the device manufacturers, the cloud service providers (e.g. the IoT platform operators), the developers for mobile and web applications, the vendor of software libraries;
-
-c\) hosting services, where the provider relies on external service desks including first, second and third support levels.
\ No newline at end of file
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-2/ISO_27002_2022_5.2_OT Information security roles and responsibilities.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-2/ISO_27002_2022_5.2_OT Information security roles and responsibilities.md
deleted file mode 100644
index de3c53a..0000000
--- a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-2/ISO_27002_2022_5.2_OT Information security roles and responsibilities.md
+++ /dev/null
@@ -1,27 +0,0 @@
-#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 organization’s information and other associated assets.
-
-These responsibilities should be supplemented, where necessary, with more detailed guidance for specific sites and information processing facilities. Individuals with allocated information security responsibilities can assign security tasks to others. However, they remain accountable and should determine that any delegated tasks have been correctly performed.
-
-Each security area for which individuals are responsible should be defined, documented and communicated. Authorization levels should be defined and documented. Individuals who take on a specific information security role should be competent in the knowledge and skills required by the role and should be supported to keep up to date with developments related to the role and required in order to fulfil the responsibilities of the role.
-
-### Other information
-Many organizations appoint an information security manager to take overall responsibility for the development and implementation of information security and to support the identification of risks and mitigating controls.
-
-However, responsibility for resourcing and implementing the controls often remains with individual managers. One common practice is to appoint an owner for each asset who then becomes responsible for its day-to-day protection.
-
-Depending on the size and resourcing of an organization, information security can be covered by dedicated roles or duties carried out in addition to existing roles.
\ No newline at end of file
diff --git a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-2/ISO_27002_2022_5.4_OT Management responsibilities.md b/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-2/ISO_27002_2022_5.4_OT Management responsibilities.md
deleted file mode 100644
index e3e225a..0000000
--- a/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/batch-2/ISO_27002_2022_5.4_OT Management responsibilities.md
+++ /dev/null
@@ -1,32 +0,0 @@
-#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 fulfil their information security responsibilities.
-
-#### Guidance
-Management should demonstrate support of the information security policy, topic-specific policies, procedures and information security controls.
-
-Management responsibilities should include ensuring that personnel:
-
-a) are properly briefed on their information security roles and responsibilities prior to being granted access to the organization’s information and other associated assets;
-
-b) are provided with guidelines which state the information security expectations of their role within the organization;
-
-c) are mandated to fulfil the information security policy and topic-specific policies of the organization;
-
-d) achieve a level of awareness of information security relevant to their roles and responsibilities within the organization (see 6.3);
-
-e) compliance with the terms and conditions of employment, contract or agreement, including the organization’s information security policy and appropriate methods of working;
-
-f) continue to have the appropriate information security skills and qualifications through ongoing professional education;
-
-g) where practicable, are provided with a confidential channel for reporting violations of information security policy, topic-specific policies or procedures for information security (“whistleblowing”). This can allow for anonymous reporting, or have provisions to ensure that knowledge of the identity of the reporter is known only to those who need to deal with such reports;
-
-h) are provided with adequate resources and project planning time for implementing the organization’s security-related processes and controls.
-
-#### Other information
-No other information.
\ No newline at end of file