diff --git a/Corpus/Standards/SurveyJS.md b/AuditGlue/System alternative/SurveyJS.md similarity index 100% rename from Corpus/Standards/SurveyJS.md rename to AuditGlue/System alternative/SurveyJS.md diff --git a/AuditGlue/iso27DIY-MoC.md b/AuditGlue/iso27DIY-MoC.md index e74fa0b..84cafd0 100644 --- a/AuditGlue/iso27DIY-MoC.md +++ b/AuditGlue/iso27DIY-MoC.md @@ -54,6 +54,6 @@ tags: [Application architecture](System%20alternative/Application%20architecture.md) [iso27DYI architecture with LLM](System%20alternative/iso27DYI%20architecture%20with%20LLM.md) [iso27DIY stack deployment](System%20alternative/iso27DIY%20stack%20deployment.md) -[SurveyJS](../Corpus/Standards/SurveyJS.md) +[SurveyJS](System%20alternative/SurveyJS.md) [WeWeb Security Pre-Launch Checklist](../Corpus/ISMS/Policy%20examples/WeWeb%20Security%20Pre-Launch%20Checklist.md) diff --git a/Corpus/ISMS/Access Control.md b/Corpus/ISMS/Access Control.md index 1de5f55..cfd2c31 100644 --- a/Corpus/ISMS/Access Control.md +++ b/Corpus/ISMS/Access Control.md @@ -1,6 +1,6 @@ # Access Control -While [authorization](../Standards/ISO27x/Authorization.md) is primarily concerned with establishing the policies and rules that dictate access (i.e. *what* a person or system is allowed to do), **access control** is the _system_ or _process_ that enforces those defined permissions. +While [authorization](../Standards/ISO27x/about/Authorization.md) is primarily concerned with establishing the policies and rules that dictate access (i.e. *what* a person or system is allowed to do), **access control** is the _system_ or _process_ that enforces those defined permissions. See: - [Gedachten over rechtenstructuren](../Information%20Security/Gedachten%20over%20rechtenstructuren.md) diff --git a/Corpus/ISMS/Authorization vs Access Control.md b/Corpus/ISMS/Authorization vs Access Control.md index e4cf7ea..f908cc9 100644 --- a/Corpus/ISMS/Authorization vs Access Control.md +++ b/Corpus/ISMS/Authorization vs Access Control.md @@ -6,7 +6,7 @@ tags: # Authorization vs. Access Control -[Authorization](../Standards/ISO27x/Authorization.md) defines _what_ a user (or system) is allowed to do, [access control ](Access%20Control.md) is the _system_ or _process_ that enforces those defined permissions. +[Authorization](../Standards/ISO27x/about/Authorization.md) defines _what_ a user (or system) is allowed to do, [access control ](Access%20Control.md) is the _system_ or _process_ that enforces those defined permissions. ## Authorization @@ -23,8 +23,8 @@ tags: - **What it is:** Access control is the **mechanism or system that enforces the authorization policies**. It's the technical implementation that actually grants or denies access to a resource based on the authorized permissions. - **The "How":** It answers the question, "How is the 'what' actually applied and managed?" - **Enforcement:** Access control is the act of putting those policies into practice. It involves: - - Checking a user's identity ([Authentication](../Standards/ISO27x/Authentication.md)). - - Consulting the pre-defined [Authorization](../Standards/ISO27x/Authorization.md)authorization rules. + - Checking a user's identity ([Authentication](../Standards/ISO27x/about/Authentication.md)). + - Consulting the pre-defined [Authorization](../Standards/ISO27x/about/Authorization.md)authorization rules. - Granting or denying access to specific resources (files, applications, data, network segments, physical locations, etc.) or actions (read, write, delete, execute). - **Examples:** - An Access Control List (ACL) on a file system that specifies which users or groups can read, write, or execute a particular file. diff --git a/Corpus/ISMS/Basic ISMS governance model.md b/Corpus/ISMS/Basic ISMS governance model.md index 9601bc3..4e79e1b 100644 --- a/Corpus/ISMS/Basic ISMS governance model.md +++ b/Corpus/ISMS/Basic ISMS governance model.md @@ -2,7 +2,7 @@ A straightforward governance structure for your Information Security Management System based on ISO 27001 and ISO 27002. -*Based on [Governance model for Policies and Controls](../Standards/ISO27x/Governance%20model%20for%20Policies%20and%20Controls.md), which contains the references to the Standard.* +*Based on [Governance model for Policies and Controls](../Standards/ISO27x/about/Governance%20model%20for%20Policies%20and%20Controls.md), which contains the references to the Standard.* ## Policy Lifecycle: Who Does What ### Key Players diff --git a/Corpus/ISMS/Business Impact Analysis (BIA).md b/Corpus/ISMS/Business Impact Analysis (BIA).md index 0e8b081..30528db 100644 --- a/Corpus/ISMS/Business Impact Analysis (BIA).md +++ b/Corpus/ISMS/Business Impact Analysis (BIA).md @@ -8,7 +8,7 @@ A Business Impact Analysis (BIA) examines the potential impacts of disruptions, The outcomes help to prioritize business activities and resources to enable the resumption of product and service delivery after a (major) disruption[^1]. Guidelines and tooling: -- [Guidelines for business impact analysis ISO 22317](../Standards/ISO27x/ISO%2022317%20Guidelines%20for%20business%20impact%20analysis.md) +- [Guidelines for business impact analysis ISO 22317](../Standards/ISO27x/about/ISO%2022317%20Guidelines%20for%20business%20impact%20analysis.md) - [Assessing reputational risks](../Various/Assessing%20reputational%20risks.md) - [BIA Workshop](../Standards/ISO27x/Implementation%20Products/BIA%20Workshop.md) - [TLP impact matrix](Data%20classification/Traffic%20Light%20Protocol%20TLP.md) diff --git a/Corpus/ISMS/Data classification/Datatags privacy oriented data classification system.md b/Corpus/ISMS/Data classification/Datatags privacy oriented data classification system.md index ad787c0..42743e8 100644 --- a/Corpus/ISMS/Data classification/Datatags privacy oriented data classification system.md +++ b/Corpus/ISMS/Data classification/Datatags privacy oriented data classification system.md @@ -4,7 +4,7 @@ Science. 2015101601. October 16, 2015. http://techscience.org/a/2015101601; PDF Related: - [ISO 27001 A 8.2 Information classification](../../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001%20A%208.2%20Information%20classification.md) -- [Privacy in ISO 27001](../../Standards/ISO27x/Privacy%20in%20ISO%2027001.md) +- [Privacy in ISO 27001](../../Standards/ISO27x/about/Privacy%20in%20ISO%2027001.md) Sweeney et all have developed a privacy oriented data classification system with six levels: diff --git a/Corpus/ISMS/Metrics for Information Security.md b/Corpus/ISMS/Metrics for Information Security.md index 0158172..d1fec86 100644 --- a/Corpus/ISMS/Metrics for Information Security.md +++ b/Corpus/ISMS/Metrics for Information Security.md @@ -25,4 +25,4 @@ W. Krag Brotby and Gary Hinson (PRAGMATIC Security Metrics, 2013) state metrics ![](../Various/Privacy/PRAGMATIC_security_metrics_examples.xlsx) Standards and Frameworks: -- [ISO 27004](../Standards/ISO27x/ISO%2027004.md) +- [ISO 27004](../Standards/ISO27x/about/ISO%2027004.md) diff --git a/Corpus/ISMS/Risk analysis methods.md b/Corpus/ISMS/Risk analysis methods.md index 89f0274..a09b504 100644 --- a/Corpus/ISMS/Risk analysis methods.md +++ b/Corpus/ISMS/Risk analysis methods.md @@ -4,9 +4,9 @@ See also under [Threat](../📚️%20Literature%20notes/Threat.md) [Open Group Risk Analysis Standard (O-RA)](https://pubs.opengroup.org/security/o-ra/) -[Open Group FAIR \ ISO 27005 Cookbook for Risk Assessment](../Standards/ISO27x/FAIR%20ISO%2027005%20Cookbook.pdf) +[Open Group FAIR \ ISO 27005 Cookbook for Risk Assessment](../Standards/ISO27x/about/FAIR%20ISO%2027005%20Cookbook.pdf) -[SURF Toolkit risicobeoordeling](../Standards/SURF%20Toolkit%20risicobeoordeling.md) +[SURF Toolkit risicobeoordeling](../Standards/SURF/SURF%20Toolkit%20risicobeoordeling.md) [](../Information%20Security/Risks/Risk_Assessment_Process.gif) diff --git a/Corpus/ISMS/Stakeholder Analysis.md b/Corpus/ISMS/Stakeholder Analysis.md index cee3bbc..b79461f 100644 --- a/Corpus/ISMS/Stakeholder Analysis.md +++ b/Corpus/ISMS/Stakeholder Analysis.md @@ -6,4 +6,4 @@ Different stakeholders have different interests. Think of your stereotypical IT ## Related - [ISO 27001_OT C 4 Context of the organization](../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001_OT%20C%204%20Context%20of%20the%20organization.md#4%202%20Understanding%20the%20needs%20and%20expectations%20of%20interested%20parties) -- [ISO31000-5.4.1-Understanding-the-organization-and-its-context](../Standards/ISO27x/ISO31000-5.4.1-Understanding-the-organization-and-its-context.md) +- [ISO31000-5.4.1-Understanding-the-organization-and-its-context](../Standards/ISO27x/about/ISO31000-5.4.1-Understanding-the-organization-and-its-context.md) diff --git a/Corpus/Information Security/BCP_Bedrijfscontinuïteitsplanning.md b/Corpus/Information Security/BCP_Bedrijfscontinuïteitsplanning.md index ea119c9..3da626c 100644 --- a/Corpus/Information Security/BCP_Bedrijfscontinuïteitsplanning.md +++ b/Corpus/Information Security/BCP_Bedrijfscontinuïteitsplanning.md @@ -8,7 +8,7 @@ Producten: ## Literatuur - BCP.mindnode op iCloud > Best Practices -- evt. [CIS Controls](../Standards/CIS%20Controls.md) als raamwerk +- evt. [CIS Controls](../Standards/CIS/CIS%20Controls.md) als raamwerk - ISO-22301-2019 'Business continuity management systems' en ISO-22313-2020 'Guidance on the use of ISO 22301' - [CISSP, Chapter 3](../Standards/CISSP/CISSP_OSG_Chapter_3.md) diff --git a/Corpus/Information Security/Identification.md b/Corpus/Information Security/Identification.md index c02b29e..9a887d0 100644 --- a/Corpus/Information Security/Identification.md +++ b/Corpus/Information Security/Identification.md @@ -3,14 +3,14 @@ Identification is the claim of a subject of its identity. See also: -- [Authentication](../Standards/ISO27x/Authentication.md) -- [Authorization](../Standards/ISO27x/Authorization.md) +- [Authentication](../Standards/ISO27x/about/Authentication.md) +- [Authorization](../Standards/ISO27x/about/Authorization.md) - [Identity and Access Management (IAM)](Identity%20and%20Access%20Management%20(IAM).md) # Identification Identification is the claim of a subject of its identity. See also: -- [Authentication](../Standards/ISO27x/Authentication.md) -- [Authorization](../Standards/ISO27x/Authorization.md) +- [Authentication](../Standards/ISO27x/about/Authentication.md) +- [Authorization](../Standards/ISO27x/about/Authorization.md) - [Identity and Access Management (IAM)](Identity%20and%20Access%20Management%20(IAM).md) diff --git a/Corpus/Information Security/Identity and Access Management (IAM).md b/Corpus/Information Security/Identity and Access Management (IAM).md index c00f387..cad0af1 100644 --- a/Corpus/Information Security/Identity and Access Management (IAM).md +++ b/Corpus/Information Security/Identity and Access Management (IAM).md @@ -8,8 +8,8 @@ An _allow policy_, also known as an _IAM policy_, defines and enforces what ro See: - [Identification](Identification.md) – "This is who I am" -- [Authentication](../Standards/ISO27x/Authentication.md) – "This is how I prove it" -- [Authorization](../Standards/ISO27x/Authorization.md) – "... then this is what you get access to" +- [Authentication](../Standards/ISO27x/about/Authentication.md) – "This is how I prove it" +- [Authorization](../Standards/ISO27x/about/Authorization.md) – "... then this is what you get access to" - [CISSP_Domain_5_1](../Standards/CISSP/CISSP_Domain_5_1.md), [CISSP_Domain_5_2](../Standards/CISSP/CISSP_Domain_5_2.md) - [Roles in Identity and Access Management (IAM)](Roles%20in%20Identity%20and%20Access%20Management%20(IAM).md) @@ -23,7 +23,7 @@ An _allow policy_, also known as an _IAM policy_, defines and enforces what ro See: - [Identification](Identification.md) – "This is who I am" -- [Authentication](../Standards/ISO27x/Authentication.md) – "This is how I prove it" -- [Authorization](../Standards/ISO27x/Authorization.md) – "... then this is what you get access to" +- [Authentication](../Standards/ISO27x/about/Authentication.md) – "This is how I prove it" +- [Authorization](../Standards/ISO27x/about/Authorization.md) – "... then this is what you get access to" - [CISSP_Domain_5_1](../Standards/CISSP/CISSP_Domain_5_1.md), [CISSP_Domain_5_2](../Standards/CISSP/CISSP_Domain_5_2.md) - [Roles in Identity and Access Management (IAM)](Roles%20in%20Identity%20and%20Access%20Management%20(IAM).md) \ No newline at end of file diff --git a/Corpus/Information Security/Zero Trust.md b/Corpus/Information Security/Zero Trust.md index 4716687..703c0e7 100644 --- a/Corpus/Information Security/Zero Trust.md +++ b/Corpus/Information Security/Zero Trust.md @@ -10,5 +10,5 @@ Zero trust is an approach to cybersecurity that assumes that no one is trusted b Zero trust can consist of monitoring all network communications, avoiding default configurations, tracking all devices, and implementing multifactor authentication. Related: -- [Zero Trust and ISO 27001](../Standards/ISO27x/Zero%20Trust%20and%20ISO%2027001.md) +- [Zero Trust and ISO 27001](../Standards/ISO27x/about/Zero%20Trust%20and%20ISO%2027001.md) - [Checklist for auditing Zero Trust approach](../Literature/Checklists%20Gerardus%20Blokdyk/Checklist%20for%20auditing%20Zero%20Trust%20approach.md) \ No newline at end of file diff --git a/Corpus/Information Security/_Information security concepts MoC.md b/Corpus/Information Security/_Information security concepts MoC.md index f2be12f..5be10c7 100644 --- a/Corpus/Information Security/_Information security concepts MoC.md +++ b/Corpus/Information Security/_Information security concepts MoC.md @@ -15,19 +15,19 @@ tags: [Assets, Vulnerabilities, Threats, Risks](📚️%20Literature%20notes/Assets,%20Vulnerabilities,%20Threats,%20Risks.md) [Assets, Vulnerabilities, Threats, Risks](/Assets,%20Vulnerabilities,%20Threats,%20Risks.md) [Attack Surface Analysis](📚️%20Literature%20notes/Attack%20Surface%20Analysis.md) -[Authentication](../Standards/ISO27x/Authentication.md) +[Authentication](../Standards/ISO27x/about/Authentication.md) [Multi-factor authentication](/Multi-factor%20authentication.md) (MFA) [Passwordless Authentication](/Passwordless%20Authentication.md) [Risk-Based Authentication](/Risk-Based%20Authentication.md) [Single Sign On (SSO)](📚️%20Literature%20notes/Single%20Sign%20On%20(SSO).md) [Tokens](/Tokens.md) -[Authorization](../Standards/ISO27x/Authorization.md) +[Authorization](../Standards/ISO27x/about/Authorization.md) [Access Control](/Access%20Control.md) [Awareness](/Awareness.md) [BCP_Bedrijfscontinuïteitsplanning](📚️%20Literature%20notes/BCP_Bedrijfscontinuïteitsplanning.md) [Business Impact Analysis (BIA)](/Business%20Impact%20Analysis%20(BIA).md) [Disaster Recovery Planning](/Disaster%20Recovery%20Planning.md) -[Change management Change Management in ISO 27002](../Standards/ISO27x/Change%20management%20Change%20Management%20in%20ISO%2027002.md) +[Change management Change Management in ISO 27002](../Standards/ISO27x/about/Change%20management%20Change%20Management%20in%20ISO%2027002.md) [Classification](/Classification.md) [Compliance](/Compliance.md) [Data Breach](💡Permanent%20ideas/Data%20Breach.md) @@ -39,10 +39,10 @@ Frameworks [[Hardening]] [Identity and Access Management (IAM)](Identity%20and%20Access%20Management%20(IAM).md) [Identification](Identification.md) - [Authentication](../Standards/ISO27x/Authentication.md) - [Authorization](../Standards/ISO27x/Authorization.md) + [Authentication](../Standards/ISO27x/about/Authentication.md) + [Authorization](../Standards/ISO27x/about/Authorization.md) Impact - [Change management Change Management in ISO 27002](../Standards/ISO27x/Change%20management%20Change%20Management%20in%20ISO%2027002.md) + [Change management Change Management in ISO 27002](../Standards/ISO27x/about/Change%20management%20Change%20Management%20in%20ISO%2027002.md) [Impact of Disruption](Sparks/Impact%20of%20Disruption.md) [Incidents](/Incidents.md) [Maturity Models](📚️%20Literature%20notes/Maturity%20Models.md) diff --git a/Corpus/Literature/Checklists Gerardus Blokdyk/Checklist for auditing GRC.md b/Corpus/Literature/Checklists Gerardus Blokdyk/Checklist for auditing GRC.md index c2fc8a9..5f38aa0 100644 --- a/Corpus/Literature/Checklists Gerardus Blokdyk/Checklist for auditing GRC.md +++ b/Corpus/Literature/Checklists Gerardus Blokdyk/Checklist for auditing GRC.md @@ -9,7 +9,7 @@ Relevant ISO 27001 clauses/controls: Related: [External audits](../../Sparks/External%20audits.md) -[ISO 27001 audit process](../../Standards/ISO27x/ISO%2027001%20audit%20process.md) +[ISO 27001 audit process](../../Standards/ISO27x/about/ISO%2027001%20audit%20process.md) 1. Can you assess the impact any pending regulatory change will have on your business including governance, compliance and risk management frameworks? diff --git a/Corpus/Standards/CIS Controls Mappings to other frameworks.xlsx b/Corpus/Standards/CIS/CIS Controls Mappings to other frameworks.xlsx similarity index 100% rename from Corpus/Standards/CIS Controls Mappings to other frameworks.xlsx rename to Corpus/Standards/CIS/CIS Controls Mappings to other frameworks.xlsx diff --git a/Corpus/Standards/CIS Controls and Safeguards.png b/Corpus/Standards/CIS/CIS Controls and Safeguards.png similarity index 100% rename from Corpus/Standards/CIS Controls and Safeguards.png rename to Corpus/Standards/CIS/CIS Controls and Safeguards.png diff --git a/Corpus/Standards/CIS Controls.md b/Corpus/Standards/CIS/CIS Controls.md similarity index 99% rename from Corpus/Standards/CIS Controls.md rename to Corpus/Standards/CIS/CIS Controls.md index 6363761..fe43023 100644 --- a/Corpus/Standards/CIS Controls.md +++ b/Corpus/Standards/CIS/CIS Controls.md @@ -31,7 +31,7 @@ IG3 assets contain sensitive information or functions that are subject to regula Safeguards selected for IG3 must abate targeted attacks from a sophisticated adversary and reduce the impact of zero-day attacks. -![](../ISMS/Asset%20classes.png) +![](../../ISMS/Asset%20classes.png) Source: CIS Controls v8.1 PDF, pp 8-12 ![](CIS%20Controls%20and%20Safeguards.png) diff --git a/Corpus/Standards/CIS safeguards effectiveness.png b/Corpus/Standards/CIS/CIS safeguards effectiveness.png similarity index 100% rename from Corpus/Standards/CIS safeguards effectiveness.png rename to Corpus/Standards/CIS/CIS safeguards effectiveness.png diff --git a/Corpus/Standards/ISO27x/Authentication.md b/Corpus/Standards/ISO27x/Authentication.md deleted file mode 100644 index 99e4926..0000000 --- a/Corpus/Standards/ISO27x/Authentication.md +++ /dev/null @@ -1,12 +0,0 @@ -# Authentication -Authentication is the proof of identity that is achieved through providing credentials to the access control mechanism. - - - -See also: -- [a-8.5-Secure-authentication](OST/27002/EN/a-8.5-Secure-authentication.md) -- [Authentication Methods Used for Network Security](../../Information%20Security/Authentication%20Methods%20Used%20for%20Network%20Security.md) -- [Identity and Access Management (IAM)](../../Information%20Security/Identity%20and%20Access%20Management%20(IAM).md) -- [Authorization](Authorization.md) -- [Identification](../../Information%20Security/Identification.md) - diff --git a/Corpus/Standards/ISO27x/Authorization.md b/Corpus/Standards/ISO27x/Authorization.md deleted file mode 100644 index 4727410..0000000 --- a/Corpus/Standards/ISO27x/Authorization.md +++ /dev/null @@ -1,13 +0,0 @@ -# Authorization -Authorization is the mechanism that determines the access level(s) of the subjects to the objects. - -See also: -- [Authorization vs Access Control](../../ISMS/Authorization%20vs%20Access%20Control.md) -- [Access Control Models](../../ISMS/Access%20Control%20Models.md) -- [Authentication](Authentication.md) -- [Identification](../../Information%20Security/Identification.md) -- [CASSM Consumer Authentication Strength Maturity Model](../../Information%20Security/CASSM%20Consumer%20Authentication%20Strength%20Maturity%20Model.md) -- [Identity and Access Management (IAM)](../../Information%20Security/Identity%20and%20Access%20Management%20(IAM).md) -- [a-5.15-Access-control](OST/27002/EN/a-5.15-Access-control.md) ??? - - diff --git a/Corpus/Standards/ISO27x/ISO 27k standards overview.md b/Corpus/Standards/ISO27x/ISO 27k standards overview.md deleted file mode 100644 index e88daba..0000000 --- a/Corpus/Standards/ISO27x/ISO 27k standards overview.md +++ /dev/null @@ -1,54 +0,0 @@ ---- -tags: - - iso27001 - - iso27002 - - type/MoC - - nen7510 ---- -# ISO and NEN security standards -## ISO 27001 & 27002 - -Indexes: -- [ISO 27001:2022 EN](ISO_27001_2022_Index.md) -- [ISO 27002:2022 EN](ISO_27001_2022_Index%20EXT.md) – Includes references to 2013 version! -- [ISO 27001:2023 NL](OST/ISO_27001_2023_NL_Index.md) -- [ISO 27002:2022 NL](OST/ISO_27002_2022_NL_Index.md) -- [Vertaaltabel Engels-Nederlands](ISO_27002_2022_Vertaaltabel_Engels_Nederlands.md) - -EN source tekst: -- ISO 27001:2022 [PDF](OST/27001/EN/ISO_27001_2022_EN.pdf) -- ISO 27002:2022 [PDF](OST/27002/EN/ISO_27002_2022_EN.pdf) - -NL brontekst: -- ISO 27001:2023 [PDF](OST/27001/NL/ISO_27001_2023_NL_PDF.md) -- ISO 27002:2022 [PDF](OST/ISO_27002_2022_NL_PDF.md) - - -See also: -- [Plain English ISO IEC 27002 2005 from Praxiom](https://www.praxiom.com/iso-17799-objectives.htm) -- [Changes in ISO 27001:2022 (table)](OST/27001/Detailed%20comparison%20between%202017%20and%202022.md) -- [[ISO 27002 2022 What's New]] -- [ISO_27001_2023_NL_Aanpassingen](OST/ISO_27001_2023_NL_Aanpassingen.md) -- [Changes in ISO 27001_2022_Advisera](../../../../iso27DIY-gis/reference/Changes%20in%20ISO%2027001_2022_Advisera.md) -- [IBB op hoofdlijnen](OST/IBB%20op%20hoofdlijnen.md) -- [ISO 27001 2023 Processen en Artefacten](OST/ISO%2027001%202023%20Processen%20en%20Artefacten.md) -- [Advised Documents for ISO 27001](../../../../iso27DIY-gis/reference/Advised%20Documents%20for%20ISO%2027001.md) -- [Types of Controls](Types%20of%20Controls.md) - -Depreciated: -[ISO_27001_2013_EN_Index](legacy/ISO%2027001%202013/ISO_27001_2013_EN_Index.md) -[ISO_27001_2017_NL_Index](legacy/ISO%2027001%202017%20NL/ISO_27001_2017_NL_Index.md) - -## Related ISO standards -- [ISO 27k family](../../../../iso27DIY-gis/reference/Examples/ISO%2027k%20family.md) - - [ISO 27000](ISO%2027000%20MoC.md) - - [ISO 27005](ISO%2027005.md) -- NEN 7510 - - [NEN 7510-1:2024](OST/7510/NEN7510_2024_NL_1.md) - - [NEN 7510-2:2024](OST/7510/NEN7510_2024_NL_2.md) - - [NEN 7510-1:2024 Bijlage A](OST/7510/NEN7510_2024_NL_1_A.md) - - [NEN 7510-1:2024 Bijlage B](OST/7510/NEN7510_2024_NL_1_B.md) - - [NEN 7510-1:2024 Bijlage C](OST/7510/NEN7510_2024_NL_1_C.md) - - [NEN 7510-1:2024 vs. ISO 27001:2022](OST/7510/NEN%207510%20vs%20ISO%2027001.md) - - [Lijst met relevante risico's](OST/7510/NEN7510%20Risicos.md) - diff --git a/Corpus/Standards/ISO27x/ISO_27001_2022_Index.md b/Corpus/Standards/ISO27x/ISO_27001_2022_Index.md deleted file mode 100644 index 061815a..0000000 --- a/Corpus/Standards/ISO27x/ISO_27001_2022_Index.md +++ /dev/null @@ -1,52 +0,0 @@ -#iso27001/2022/EN -# ISO 27001:2022 EN Index - -| Clause | Title | -| ---------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| **F** | **[Foreword](../ISO-27001-OST/ISO27001-EN-2022/ISO_27001_OT%20F%20Foreword.md)** | -| **0** | **[Introduction](../ISO-27001-OST/ISO27001-EN-2022/c-0-Introduction.md)** | -| **1** | **[Scope](../ISO-27001-OST/ISO27001-EN-2022/c-1-Scope.md)** | -| **2** | **[Normative references](../ISO-27001-OST/ISO27001-EN-2022/c-2-Normative-references.md)** | -| **3** | **[Terms and definitions](../ISO-27001-OST/ISO27001-EN-2022/ISO_27001_OT%20Terms%20and%20definitions.md)** | -| **4** | **[Context of the organization](ISO_27001_2022_4_MoC%20Context%20of%20the%20organization.md)** | -| 4.1 | [Understanding the organization and its context ](../../MoCs/ISO_27001_2022_4.1_MoC%20Understanding%20the%20organization%20and%20its%20context.md) | -| 4.2 | [Understanding the needs and expectations of interested parties ](../../MoCs/ISO_27001_2022_4.2_MoC%20Understanding%20the%20needs%20and%20expectations%20of%20interested%20parties.md) | -| 4.3 | [Determining the scope of the information security management system ](../../MoCs/ISO_27001_2022_4.3_MoC%20Determining%20the%20scope%20of%20the%20information%20security%20management%20system.md) | -| 4.4 | [Information security management system ](../../MoCs/ISO_27001_2022_4.4_MoC%20Information%20security%20management%20system.md) | -| **5** | **[Leadership](../../MoCs/ISO_27001_2022_5_MoC%20Leadership.md)** | -| 5.1 | [Leadership and commitment ](../../MoCs/ISO_27001_2022_5.1_MoC%20Leadership%20and%20commitment.md) | -| 5.2 | [Policy ](../../MoCs/ISO_27001_2022_5.2_MoC%20Policy.md) | -| 5.3 | [Organizational roles, responsibilities and authorities ](../../MoCs/ISO_27001_2022_5.3_MoC%20Organizational%20roles,%20responsibilities%20and%20authorities.md) | -| **6** | **[Planning](../../MoCs/ISO_27001_2022_6_MoC%20Planning.md)** | -| 6.1 | [Actions to address risks and opportunities ](../../MoCs/ISO_27001_2022_6.1_MoC%20Actions%20to%20address%20risks%20and%20opportunities.md) | -| 6.1.1 | [General ](../../MoCs/ISO_27001_2022_6.1.1_MoC%20General.md) | -| 6.1.2 | [Information security risk assessment ](../../ISMS/Qualifying%20vs%20quantifying%20risks.md) | -| 6.1.3 | [Information security risk treatment ](../../MoCs/ISO_27001_2022_6.1.3_MoC%20Information%20security%20risk%20treatment.md) | -| 6.2 | [Information security objectives and planning to achieve them ](../../MoCs/ISO_27001_2022_6.2_MoC%20Information%20security%20objectives%20and%20planning%20to%20achieve%20them.md) | -| 6.3 | [Planning of changes ](../../MoCs/ISO_27001_2022_6.3_MoC%20Planning%20of%20changes.md) | -| **7** | **[Support](../../MoCs/ISO_27001_2022_7_MoC%20Support.md)** | -| 7.1 | [ Resources ](../../MoCs/ISO_27001_2022_7.1_MoC%20Resources.md) | -| 7.2 | [ Competence ](../../MoCs/ISO_27001_2022_7.2_MoC%20Competence.md) | -| 7.3 | [ Awareness ](../../MoCs/ISO_27001_2022_7.3_MoC%20Awareness.md) | -| 7.4 | [ Communication ](../../MoCs/ISO_27001_2022_7.4_MoC%20Communication.md) | -| 7.5 | [ Documented information ](../../MoCs/ISO_27001_2022_7.5_MoC%20Documented%20information.md) | -| 7.5.1 | General ↑ | -| 7.5.2 | Creating and updating ↑ | -| 7.5.3 | Control of documented information ↑ | -| **8** | **[Operation](../../MoCs/ISO_27001_2022_8_MoC%20Operation.md)** | -| 8.1 | [Operational planning and control ](../../MoCs/ISO_27001_2022_8.1_MoC%20Operational%20planning%20and%20control.md) | -| 8.2 | [Information security risk assessment ](../../MoCs/ISO_27001_2022_8.2_MoC%20Information%20security%20risk%20assessment.md) | -| 8.3 | [Information security risk treatment ](../../MoCs/ISO_27001_2022_8.3_MoC%20Information%20security%20risk%20treatment.md) | -| **9** | **[Performance evaluation](../../MoCs/ISO_27001_2022_9_MoC%20Performance%20evaluation.md)** | -| 9.1 | [Monitoring, measurement, analysis and evaluation ](../../MoCs/ISO_27001_2022_9.1_MoC%20Monitoring,%20measurement,%20analysis%20and%20evaluation.md) | -| 9.2 | [Internal audit ](../../MoCs/ISO_27001_2022_9.2_MoC%20Internal%20audit.md) | -| 9.2.1 | General ↑ | -| 9.2.2 | Internal audit programme ↑ | -| 9.3 | [Management review ](../../MoCs/ISO_27001_2022_9.3_MoC%20Management%20review.md) | -| 9.3.1 | General ↑ | -| 9.3.2 | Management review inputs ↑ | -| 9.3.3 | Management review results ↑ | -| **10** | **[Improvement](../../MoCs/ISO_27001_2022_10_MoC%20Improvement.md)** | -| 10.1 | [Continual improvement ](../../MoCs/ISO_27001_2022_10.1_MoC%20Continual%20improvement.md) | -| 10.2 | [Nonconformity and corrective action ](../../MoCs/ISO_27001_2022_10.2_MoC%20Nonconformity%20and%20corrective%20action.md) | -| **[Annex A](ISO_27001_2022_Index%20EXT.md)** | **Information security controls reference** | diff --git a/Corpus/Standards/ISO27x/Implementation Products/Informatiebeveiligingsbeleid ISO 27001.md b/Corpus/Standards/ISO27x/Implementation Products/Informatiebeveiligingsbeleid ISO 27001.md index 790f2b6..1b2bc09 100644 --- a/Corpus/Standards/ISO27x/Implementation Products/Informatiebeveiligingsbeleid ISO 27001.md +++ b/Corpus/Standards/ISO27x/Implementation Products/Informatiebeveiligingsbeleid ISO 27001.md @@ -13,7 +13,7 @@ | Volgende herzieningsdatum | [Datum] | | Status | [Concept/Goedgekeurd] | -*Noot: Oorspronkelijke versie gebaseerd op ISO/IEC 27001:2013; [Toevoegingen IBB ISO27001-2022](../Toevoegingen%20IBB%20ISO27001-2022.md) zijn hierin verwerkt.* +*Noot: Oorspronkelijke versie gebaseerd op ISO/IEC 27001:2013; [Nieuwe beheersmaatregelen in ISO 27001-2022](../about/Nieuwe%20beheersmaatregelen%20in%20ISO%2027001-2022.md) zijn hierin verwerkt.* ## Inhoudsopgave diff --git a/Corpus/Standards/ISO27x/MoC Roles and responsibilities in ISO 27001.md b/Corpus/Standards/ISO27x/MoC Roles and responsibilities in ISO 27001.md deleted file mode 100644 index 04c3b51..0000000 --- a/Corpus/Standards/ISO27x/MoC Roles and responsibilities in ISO 27001.md +++ /dev/null @@ -1,19 +0,0 @@ -# MoC Roles and responsibilities in ISO 27001 - -**See**: - -Recent: -- [Explicitly mentioned roles in ISO 27001](Explicitly%20mentioned%20roles%20in%20ISO%2027001.md) -- [ISO 27001 Leadership Responsibilities](ISO%2027001%20Leadership%20Responsibilities.md) -- [ISO 27001 Top Management responsibilities](ISO%2027001%20Top%20Management%20responsibilities.md) -- [Governance model for Policies and Controls](Governance%20model%20for%20Policies%20and%20Controls.md) -- [Basic ISMS governance model](../../ISMS/Basic%20ISMS%20governance%20model.md) -- [m400-more-governance](../../../../iso27DIY-gis/guide/m400/m400-more-governance.md) - -Older: -- [Roles and Responsibilities](../../ISMS/Roles%20and%20Responsibilities.md) -- [Risk ownership](../../Information%20Security/Risks/Risk%20ownership.md) -- [Ideas on Risk Ownership](../../ISMS/Ideas%20on%20Risk%20Ownership.md) -- [Asset ownership](../../Sparks/Asset%20ownership.md) -- [Procuratieregeling](../../Various/Procuratieregeling.md) -- [Control ownership](../../ISMS/Control%20ownership.md) diff --git a/Corpus/Standards/ISO27x/OST/27001/Detailed comparison between 2017 and 2022.md b/Corpus/Standards/ISO27x/OST/27001/Detailed comparison between 2017 and 2022.md index 2290207..98db8b9 100644 --- a/Corpus/Standards/ISO27x/OST/27001/Detailed comparison between 2017 and 2022.md +++ b/Corpus/Standards/ISO27x/OST/27001/Detailed comparison between 2017 and 2022.md @@ -2,7 +2,7 @@ According to [Mark Bernard](https://www.linkedin.com/posts/markesbernard_the-changes-to-isoiec-27001-isms-are-not-activity-7344467878198329344-nZN7) , 28 juni 2025, "The changes to ISO/IEC 27001 ISMS are not straightforward. Some believe that the total number of controls was reduced; however, the truth is that new controls were added while existing controls were consolidated and streamlined." -![](../../Changes%20in%20ISO%2027001-2022%20table.jpeg) +![](../../about/Changes%20in%20ISO%2027001-2022%20table.jpeg) ## New ISMS Control Objectives - ISO 27001:2022 CLAUSE 4 TO 10 diff --git a/Corpus/Standards/ISO27x/OST/27001/EN/c-3-Terms-and-definitions.md b/Corpus/Standards/ISO27x/OST/27001/EN/c-3-Terms-and-definitions.md index ce18537..cad6dac 100644 --- a/Corpus/Standards/ISO27x/OST/27001/EN/c-3-Terms-and-definitions.md +++ b/Corpus/Standards/ISO27x/OST/27001/EN/c-3-Terms-and-definitions.md @@ -15,4 +15,4 @@ status: active For the purposes of this document, the terms and definitions given in ISO/IEC 27000 apply. -[ISO 27000 MoC](../../../ISO%2027000%20MoC.md) \ No newline at end of file +[ISO 27000 MoC](../../../about/ISO%2027000%20MoC.md) \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/OST/27001/EN/c-4.1-Understanding-the-organization-and-its-context.md b/Corpus/Standards/ISO27x/OST/27001/EN/c-4.1-Understanding-the-organization-and-its-context.md index d36ed28..da0f532 100644 --- a/Corpus/Standards/ISO27x/OST/27001/EN/c-4.1-Understanding-the-organization-and-its-context.md +++ b/Corpus/Standards/ISO27x/OST/27001/EN/c-4.1-Understanding-the-organization-and-its-context.md @@ -15,5 +15,5 @@ status: active The organization shall determine external and internal issues that are relevant to its purpose and that affect its ability to achieve the intended outcome(s) of its information security management system. -NOTE Determining these issues refers to establishing the external and internal context of the organization considered in [Clause 5.4.1](../../../ISO31000-5.4.1-Understanding-the-organization-and-its-context.md) of ISO 31000:2018. +NOTE Determining these issues refers to establishing the external and internal context of the organization considered in [Clause 5.4.1](../../../about/ISO31000-5.4.1-Understanding-the-organization-and-its-context.md) of ISO 31000:2018. diff --git a/Corpus/Standards/ISO27x/ISO 27001_2022_EN.docx b/Corpus/Standards/ISO27x/OST/ISO 27001_2022_EN.docx similarity index 100% rename from Corpus/Standards/ISO27x/ISO 27001_2022_EN.docx rename to Corpus/Standards/ISO27x/OST/ISO 27001_2022_EN.docx diff --git a/Corpus/Standards/ISO27x/ISO 27002_2022_EN_complete.md b/Corpus/Standards/ISO27x/OST/ISO 27002_2022_EN_complete.md similarity index 100% rename from Corpus/Standards/ISO27x/ISO 27002_2022_EN_complete.md rename to Corpus/Standards/ISO27x/OST/ISO 27002_2022_EN_complete.md diff --git a/Corpus/Standards/ISO27x/OST/Index to the original texts of ISO 27001.md b/Corpus/Standards/ISO27x/OST/ISO_27001_2022_EN_Index.md similarity index 77% rename from Corpus/Standards/ISO27x/OST/Index to the original texts of ISO 27001.md rename to Corpus/Standards/ISO27x/OST/ISO_27001_2022_EN_Index.md index 6306c93..6dcddab 100644 --- a/Corpus/Standards/ISO27x/OST/Index to the original texts of ISO 27001.md +++ b/Corpus/Standards/ISO27x/OST/ISO_27001_2022_EN_Index.md @@ -1,53 +1,53 @@ # Index to the original texts of ISO 27001 2022 version -| Clause | Title | -| ----------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| **F** | **[Foreword](27001/EN/c-f-Foreword.md)** | +| Clause | Title | +| ----------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| **F** | **[Foreword](27001/EN/c-f-Foreword.md)** | | **0** | **[Introduction](27001/EN/c-0-Introduction.md)** | | **1** | **[Scope](27001/EN/c-1-Scope.md)** | | **2** | **[Normative references](27001/EN/c-2-Normative-references.md)** | | **3** | **[Terms and definitions](27001/EN/c-3-Terms-and-definitions.md)** | -| **4** | **Context of the organization** | +| **4** | **Context of the organization** | | 4.1 | [Understanding the organization and its context ](27001/EN/c-4.1-Understanding-the-organization-and-its-context.md) | | 4.2 | [Understanding the needs and expectations of interested parties ](27001/EN/c-4.2-Understanding-the-needs-and-expectations-of-interested-parties.md) | | 4.3 | [Determining the scope of the information security management system ](27001/EN/c-4.3-Determining-the-scope-of-the-information-security-management-system.md) | | 4.4 | [Information security management system ](27001/EN/c-4.4-Information-security-management-system.md) | -| **5** | **Leadership** | +| **5** | **Leadership** | | 5.1 | [Leadership and commitment ](27001/EN/c-5.1-Leadership-and-commitment.md) | | 5.2 | [Policy ](27001/EN/c-5.2-Policy.md) | | 5.3 | [Organizational roles, responsibilities and authorities ](27001/EN/c-5.3-Organizational-roles-responsibilities-and-authorities.md) | -| **6** | **Planning** | -| 6.1 | Actions to address risks and opportunities *(no content)* | +| **6** | **Planning** | +| 6.1 | Actions to address risks and opportunities *(no content)* | | 6.1.1 | [General ](27001/EN/c-6.1.1-General.md) | | 6.1.2 | [Information security risk assessment ](27001/EN/c-6.1.2-Information-security-risk-assessment.md) | | 6.1.3 | [Information security risk treatment ](27001/EN/c-6.1.3-Information-security-risk-treatment.md) | | 6.2 | [Information security objectives and planning to achieve them ](27001/EN/c-6.2-Information-security-objectives-and-planning-to-achieve-them.md) | | 6.3 | [Planning of changes ](27001/EN/c-6.3-Planning-of-changes.md) | -| **7** | **Support** | +| **7** | **Support** | | 7.1 | [ Resources ](27001/EN/c-7.1-Resources.md) | | 7.2 | [ Competence ](27001/EN/c-7.2-Competence.md) | | 7.3 | [ Awareness ](27001/EN/c-7.3-Awareness.md) | | 7.4 | [ Communication ](27001/EN/c-7.4-Communication.md) | | 7.5 | [ Documented information ](27001/EN/c-7.5-Documented-information.md) | -| 7.5.1 | General ↑ | -| 7.5.2 | Creating and updating ↑ | -| 7.5.3 | Control of documented information ↑ | -| **8** | **Operation** | +| 7.5.1 | General ↑ | +| 7.5.2 | Creating and updating ↑ | +| 7.5.3 | Control of documented information ↑ | +| **8** | **Operation** | | 8.1 | [Operational planning and control ](27001/EN/c-8.1-Operational-planning-and-control.md) | | 8.2 | [Information security risk assessment ](27001/EN/c-8.2-Information-security-risk-assessment.md) | | 8.3 | [Information security risk treatment ](27001/EN/c-8.3-Information-security-risk-treatment.md) | -| **9** | **Performance evaluation** | +| **9** | **Performance evaluation** | | 9.1 | [Monitoring, measurement, analysis and evaluation ](27001/EN/c-9.1-Monitoring-measurement-analysis-and-evaluation.md) | | 9.2 | [Internal audit ](27001/EN/c-9.2-Internal-audit.md) | -| 9.2.1 | General ↑ | -| 9.2.2 | Internal audit programme ↑ | +| 9.2.1 | General ↑ | +| 9.2.2 | Internal audit programme ↑ | | 9.3 | [Management review ](27001/EN/c-9.3-Management-review.md) | -| 9.3.1 | General ↑ | -| 9.3.2 | Management review inputs ↑ | -| 9.3.3 | Management review results ↑ | -| **10** | **Improvement** | +| 9.3.1 | General ↑ | +| 9.3.2 | Management review inputs ↑ | +| 9.3.3 | Management review results ↑ | +| **10** | **Improvement** | | 10.1 | [Continual improvement ](27001/EN/c-10.1-Continual-improvement.md) | | 10.2 | [Nonconformity and corrective action ](27001/EN/c-10.2-Nonconformity-and-corrective-action.md) | -| **Annex A** | **[Information security controls reference ](Index%20to%20the%20original%20texts%20of%20ISO%2027002.md)** | +| **Annex A** | **[Information security controls reference ](ISO_27002_2022_EN_Index.md)** | diff --git a/Corpus/Standards/ISO27x/OST/Index to the original texts of ISO 27002.md b/Corpus/Standards/ISO27x/OST/ISO_27002_2022_EN_Index.md similarity index 100% rename from Corpus/Standards/ISO27x/OST/Index to the original texts of ISO 27002.md rename to Corpus/Standards/ISO27x/OST/ISO_27002_2022_EN_Index.md diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/PECB 27001 LA S05 E02a - Risk assessment and analysis.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/PECB 27001 LA S05 E02a - Risk assessment and analysis.md index 5f76194..3119087 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/PECB 27001 LA S05 E02a - Risk assessment and analysis.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/PECB 27001 LA S05 E02a - Risk assessment and analysis.md @@ -32,7 +32,7 @@ A very important thing to bring up early, is **risk ownership**. We need to be c As an auditor I expect to see a clearly defined and understandable risk assessment process, and evidence for its execution, by maybe getting somebody to take me through risk assessments that have been performed. -Although Clause 6.1.2 tells you what should be considered when doing risk assessments, it does not tell you *how* to conduct a risk assessment. It doesn't tell you to use a risk calculation scale of 1 to 10, or high, medium and low, or using some other kind of formula, and neither does the ISO 27002 implementation guidance, of the [ISO 27005](../ISO%2027005.md) (Guidance on managing information security risks). +Although Clause 6.1.2 tells you what should be considered when doing risk assessments, it does not tell you *how* to conduct a risk assessment. It doesn't tell you to use a risk calculation scale of 1 to 10, or high, medium and low, or using some other kind of formula, and neither does the ISO 27002 implementation guidance, of the [ISO 27005](../about/ISO%2027005.md) (Guidance on managing information security risks). What it *does* tell us, is that we need to have an agreed way of conducting risk assessments, and that we need predefined risk acceptance criteria. diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/PECB 27001 LA S05 E03a - Risk treatment.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/PECB 27001 LA S05 E03a - Risk treatment.md index ee37322..b341dba 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/PECB 27001 LA S05 E03a - Risk treatment.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/PECB 27001 LA S05 E03a - Risk treatment.md @@ -33,7 +33,7 @@ This was previously called risk transfer, but this term was dropped because you ### Risk modification by implementing controls -Clause 8.3 of [ISO 27005](../ISO%2027005.md), the guidance document on risk management[^1], says that we shall select controls in order to address risks. These can be preventative, detective or corrective in nature. +Clause 8.3 of [ISO 27005](../about/ISO%2027005.md), the guidance document on risk management[^1], says that we shall select controls in order to address risks. These can be preventative, detective or corrective in nature. Which controls will be implemented by the organization, is specified in the Statement of Applicability (6.1.3d). diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/CleanShot 2026-06-05 at 17.14.11.png b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/CleanShot 2026-06-05 at 17.14.11.png new file mode 100644 index 0000000..5756c9c Binary files /dev/null and b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/CleanShot 2026-06-05 at 17.14.11.png differ diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/CleanShot 2026-06-05 at 20.42.44.png b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/CleanShot 2026-06-05 at 20.42.44.png new file mode 100644 index 0000000..f31d8c2 Binary files /dev/null and b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/CleanShot 2026-06-05 at 20.42.44.png differ diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/CleanShot 2026-06-05 at 21.19.48.png b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/CleanShot 2026-06-05 at 21.19.48.png new file mode 100644 index 0000000..92b5f69 Binary files /dev/null and b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/CleanShot 2026-06-05 at 21.19.48.png differ diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/CleanShot 2026-06-05 at 21.36.38.png b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/CleanShot 2026-06-05 at 21.36.38.png new file mode 100644 index 0000000..4274af3 Binary files /dev/null and b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/CleanShot 2026-06-05 at 21.36.38.png differ diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/CleanShot 2026-06-05 at 21.41.14.png b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/CleanShot 2026-06-05 at 21.41.14.png new file mode 100644 index 0000000..268dca9 Binary files /dev/null and b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/CleanShot 2026-06-05 at 21.41.14.png differ diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/CleanShot 2026-06-05 at 21.41.41.png b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/CleanShot 2026-06-05 at 21.41.41.png new file mode 100644 index 0000000..9d6db32 Binary files /dev/null and b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/CleanShot 2026-06-05 at 21.41.41.png differ diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/CleanShot 2026-06-05 at 21.56.32.png b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/CleanShot 2026-06-05 at 21.56.32.png new file mode 100644 index 0000000..ee836a1 Binary files /dev/null and b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/CleanShot 2026-06-05 at 21.56.32.png differ diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/CleanShot 2026-06-05 at 22.22.09.png b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/CleanShot 2026-06-05 at 22.22.09.png new file mode 100644 index 0000000..87e557d Binary files /dev/null and b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/CleanShot 2026-06-05 at 22.22.09.png differ diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/CleanShot 2026-06-05 at 22.22.58.png b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/CleanShot 2026-06-05 at 22.22.58.png new file mode 100644 index 0000000..bd15f27 Binary files /dev/null and b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/CleanShot 2026-06-05 at 22.22.58.png differ diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/CleanShot 2026-06-05 at 22.31.35.png b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/CleanShot 2026-06-05 at 22.31.35.png new file mode 100644 index 0000000..c1368f2 Binary files /dev/null and b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/CleanShot 2026-06-05 at 22.31.35.png differ diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/CleanShot 2026-06-06 at 12.43.00.png b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/CleanShot 2026-06-06 at 12.43.00.png new file mode 100644 index 0000000..d084965 Binary files /dev/null and b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/CleanShot 2026-06-06 at 12.43.00.png differ diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/CleanShot 2026-06-06 at 14.53.58.png b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/CleanShot 2026-06-06 at 14.53.58.png new file mode 100644 index 0000000..e01248f Binary files /dev/null and b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/CleanShot 2026-06-06 at 14.53.58.png differ diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/CleanShot 2026-06-06 at 15.06.49.png b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/CleanShot 2026-06-06 at 15.06.49.png new file mode 100644 index 0000000..b4c47fb Binary files /dev/null and b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/CleanShot 2026-06-06 at 15.06.49.png differ diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/CleanShot 2026-06-06 at 15.33.55.png b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/CleanShot 2026-06-06 at 15.33.55.png new file mode 100644 index 0000000..110a3b9 Binary files /dev/null and b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/CleanShot 2026-06-06 at 15.33.55.png differ diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/CleanShot 2026-06-06 at 15.55.57.png b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/CleanShot 2026-06-06 at 15.55.57.png new file mode 100644 index 0000000..3ceed38 Binary files /dev/null and b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/CleanShot 2026-06-06 at 15.55.57.png differ diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/CleanShot 2026-06-06 at 16.10.12.png b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/CleanShot 2026-06-06 at 16.10.12.png new file mode 100644 index 0000000..184e61f Binary files /dev/null and b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/CleanShot 2026-06-06 at 16.10.12.png differ diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/CleanShot 2026-06-06 at 20.00.09.png b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/CleanShot 2026-06-06 at 20.00.09.png new file mode 100644 index 0000000..1beb7a1 Binary files /dev/null and b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/CleanShot 2026-06-06 at 20.00.09.png differ diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/CleanShot 2026-06-06 at 20.10.02.png b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/CleanShot 2026-06-06 at 20.10.02.png new file mode 100644 index 0000000..d4eec97 Binary files /dev/null and b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/CleanShot 2026-06-06 at 20.10.02.png differ diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S01-Course-objectives-and-structure.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S01-Course-objectives-and-structure.md index 1bce928..4ad1aa1 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S01-Course-objectives-and-structure.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S01-Course-objectives-and-structure.md @@ -7,6 +7,7 @@ tags: - PECB-LA isotags: [] status: active +processed: true --- # S01 Course objectives and structure diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S02.1-Introduction-to-management-systems-and-ISO-27000-family-of-standards.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S02.1-Introduction-to-management-systems-and-ISO-27000-family-of-standards.md index 36842ae..4cc4369 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S02.1-Introduction-to-management-systems-and-ISO-27000-family-of-standards.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S02.1-Introduction-to-management-systems-and-ISO-27000-family-of-standards.md @@ -7,6 +7,7 @@ tags: - PECB-LA isotags: [] status: active +processed: true --- # S02.1 Introduction to management systems and ISO 27000 family of standards diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S02.2-Introduction-to-management-systems-and-ISO-27000-family-of-standards.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S02.2-Introduction-to-management-systems-and-ISO-27000-family-of-standards.md index 8155eb2..d9d701a 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S02.2-Introduction-to-management-systems-and-ISO-27000-family-of-standards.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S02.2-Introduction-to-management-systems-and-ISO-27000-family-of-standards.md @@ -7,6 +7,7 @@ tags: - PECB-LA isotags: [] status: active +processed: true --- # S02.2 Introduction to management systems and ISO 27000 family of standards diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S02.3-Introduction-to-management-systems-and-ISO-27000-family-of-standards.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S02.3-Introduction-to-management-systems-and-ISO-27000-family-of-standards.md index a61d12a..68e55eb 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S02.3-Introduction-to-management-systems-and-ISO-27000-family-of-standards.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S02.3-Introduction-to-management-systems-and-ISO-27000-family-of-standards.md @@ -7,6 +7,7 @@ tags: - PECB-LA isotags: [] status: active +processed: true --- # S02.3 Introduction to management systems and ISO 27000 family of standards diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S03-Certification-process.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S03-Certification-process.md index 8f30388..70d008a 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S03-Certification-process.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S03-Certification-process.md @@ -7,6 +7,7 @@ tags: - PECB-LA isotags: [] status: active +processed: true --- # S03 Certification process diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S04.1-Fundamental-concepts-and-principles-of-information-security.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S04.1-Fundamental-concepts-and-principles-of-information-security.md index db456ae..a7dddc8 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S04.1-Fundamental-concepts-and-principles-of-information-security.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S04.1-Fundamental-concepts-and-principles-of-information-security.md @@ -7,6 +7,7 @@ tags: - PECB-LA isotags: [] status: active +processed: true --- # S04.1 Fundamental concepts and principles of information security @@ -18,4 +19,50 @@ This session introduces core information security concepts from the ISO 27001 pe So in this section we're going to look at something we've called the fundamental concepts and principles of information security. -Now of course I appreciate that many people looking at this training may well have a security background already, maybe you've you've got a lot of experience or other certifications and so forth. And the idea of this section isn't to sort of repeat what you may already know or to reteach the same thing. The idea is is to make sure that we're all speaking the same language and in particular from an ISO perspective. So the idea of this section is to introduce the sort of terminology and meanings, if you like, that uh ISO 27001 contains so that as we go forward When we start talking about auditing a management system, we can all understand the meaning of different terminology. So what we're going to look at in this section is the concept of information assets and information security according to ISO 20. The three tenants of security that ISO 27001 speaks about, which is confidentiality, integrity and availability. And we'll also look at the risk terminology, things like vulnerabilities, threats and consequences and how all these relate to the topic of risk. We'll also have a look at security controls because as you know the standard has annex A with multiple controls and we'll talk about how those controls can be classified and thought of. And we'll also examine the topics of cybersecurity and information privacy because you'll have noticed in the title of the standard it does refer to both cybersecurity and privacy and information privacy. So what do those things mean and how do they fit into the ISO information security concept? So let's start with information and asset then because one thing that ISO 27001 says is that we're trying to protect our information assets. So we can get the official definition of these two words from ISO 9000, basically a quality management series of standards, and ISO 55000, which is the asset management series of standards. So I think most of us would accept hopefully that information is meaningful data, that is to say data that we can do something with. So if I've got a customer database. containing customer records, you know, names, addresses, order histories, etc. That has some meaning, some use and some purpose. And an asset, we we typically say an asset is something that has value Now when I say value, that might be a financial value, something you can sell an asset for, for example, but it can also mean value in terms of usefulness and service to the organization. And most people, I would imagine, if I asked them what an asset was, would probably think of something tangible, you know, a c a computer, a building, some equipment, etc. And they'd be correct But also assets can be intangible. So actually the people who work for your organization are assets and ideas and intellectual property and of course information And even if I can't sell information for a you know a dollar, euro uh fee, so to speak, it still has uh a value to the organisation, hence the term asset So ultimately an ISMS based on ISO 27001 is about identifying those assets, those pieces of information, those you know, uh data sets, etc. , working out how valuable they are, and then essentially protecting them accordingly Now when we think about information assets and we think about running an information security management system, there are some other terms that we just need to be familiar with. The concept of document specifications and records. Now of course it might sound a little bit odd to uh tell you what a document is, I'm sure many people can imagine that, but there is a general saying which is a document is the information and the medium upon which it's contained. So yes, you could be thinking about a traditional Microsoft Word document here, but equally a confluence or a wiki page with information that we follow would also, in ISO speak, be considered to be a document. And of course some of the documents that we create or use in an ISMS will state very clear requirements. You know, maybe I've got a document that states things like secure coding standards requirements. for example or a document that says how a network device should be configured. And we would call that in ISO terminology a specification. And when an organization runs an ISMS and follows the requirements laid out in some of these documents. then essentially they end up generating records. So let's say for example you're running an ISMS and you have a process for reporting information security incidents. And let's imagine somebody follows it and they report an incident through whatever reporting channel. Of course then there'd be a record, there'd be some evidence that that process has been used. If you had a specification about how backups should be done and those backups run, of course there'd be logs generated, those logs would be records because they would serve as evidence that that activity is taking place. And records are very important in an ISMS, not just because the server's an audit trail, which is important. uh and certainly as auditors we'll be looking at records but also the fact is that records can be in their own right sensitive and need a certain level of protection. So an ISMS will concern itself with protecting documents specifically. and records. So it probably makes sense at this point to answer the question, what is information security? But more importantly, what is information security according to ISO 27000? And we have the uh the definition here which says Information security is the preservation of confidentiality, integrity and availability of information. And I'll come to that. And explore that in a little bit more depth in just a moment. Now the other thing that we we we say or ISO says about this is that information security is about determining what information needs to be protected. how it should be protected and from what. Now that would imply when you read that that that means that when we set up an ISMS we'll need to identify the kind of information we have. Trying to protect. And we'd need to do some kind of study or research into the potential risks that that information faces. So in other words, when we implement an ISMS, if I had two organizations implementing an ISMS They may protect their information very differently depending on the type of information we're speaking about and the type of risks they face. So the standard is flexible enough so you tailor your controls as needed. Now the other thing that's important in the definition about information security is the fact that it covers information in all formats. Now this is interesting. A little bit later in the section we're going to talk about this concept called cybersecurity. And certainly what I've noticed over the last few years when you look at job descriptions and you know, what a lot of people talk about. You hear a lot about cyber. And cyber of course is focusing very much on the technology aspects, you know, protecting the technical systems that will store and process information. And of course that makes sense because the vast majority of information today is indeed processed electronically. But it's not all processed electronically. It is still possible to have information in paper format, in video format, in spoken word, etc. So information security concerns itself with protecting that information regardless of format. And maybe a very quick example I could give. I recall having a train journey where on that particular train there was a solicitor from a law firm having a conversation with a client. uh quite openly for the entire carriage on the train to hear and s in and discussing some quite sensitive topics. It was actually discussing a divorce case with a client uh and basically pretty much with the phone on loudspeaker uh to you know revealing uh people's names, addresses, dates of birth, salaries, you know, a lot of very sensitive information which Let's say I or somebody else in that carriage was a cyber criminal, for example, or a fraudster, we could have gathered plenty of information to conduct things like identity theft. and so on. The point of that story is to say that organization for all I know, I don't know them, but for all I know they might have extremely strong cybersecurity. They may have, you know, um robust networks, strong application security, etc. But they've obviously still got some weak links in their information security program. In this case maybe the awareness of some of the employees who work for them So information security will concern itself with all those things. And ultimately the last thing to say before we look at this confidentiality, integrity and availability bit is of course when we look think about information security what ISO says is we're always focusing on the business objectives There is a saying that information security should be an enabler, not a disabler. So in other words, we're not implementing security to stop the organisation operating and achieving what it needs to achieve. What we want is the organization to achieve. to achieve what it's aiming to achieve but in a secure manner essentially. So let's have a look at this confidentiality integrity and availability bit and I just want to run through those and again I realize people have been in security for quite some time should be already familiar with this but again let's just make sure we're on the same page Now the first thing is that ISO says that these are the three pillars of security, the three tenets of security. But I must stress that when you set up an ISMS, you're not limited to just thinking about these three. things. These are the minimum three things you would think about. So just for those who might be in other industries, for example, if you're in a regulated industry where you need to have strong audit trails of activity and you're concerned about accountability, for example. There's no reason why we cannot implement controls and manage that through an ISMS. If you're an organization that's producing products or services and you're concerned about you know counterfeiting or piracy and risks like that. Um your controls to ensure authenticity, your digital rights management. authenticity management, etc. , can be considered. And similarly, if you're in the business of doing transactions and you don't want people to be able to deny activities, so you're concerned about non-repudiation those things can be considered. So my point is just because they're not explicitly called out by ISO doesn't mean that they don't matter or can't be thought about. But let's focus on the first three, the confidentiality, integrity and ability So what I typically tell people is imagine if you went outside and stopped somebody in the street who doesn't really know much about information security. Somebody who's not really in that space, and I asked them what is information security, probably I imagine the answer I would get back would be something like stopping unauthorized access to data or you know, um only allowing people access who should have access, something like that. I imagine the vast majority of people would probably focus on confidentiality, says the most obvious one. So indeed confidentiality is is exactly that, about limiting access to information to only those people who need it, about having control over information and and who can access it. And of course organisations can achieve that in many ways by implementing robust authentication for example, establishing a clear data access policy, having proper access control, perhaps using things like encryption or data masking, all of these are confidentiality techniques. But of course, whilst confidentiality is important, if we're building the argument that information is an asset because we use it to make business decisions, to respond to uh uh various problems and challenges, then we surely want some confidence that the information is actually trustworthy, up to date, accurate, and so forth. And that's where we concern ourselves with integrity. So integrity is about implementing controls that reduce the risk of unauthorized changes to data, data corruption. helps us ensure minimum data quality so that when we do come to rely on a system or the information it contains we can have a confidence within it. And whilst we were talking about confidentiality a moment ago, confidentiality is all well and good and we could achieve it by locking down all kinds of things, but it's not much use if Those people in an organization who need access can't gain access. So there's a balance and that's where we look at availability. So availability and the principle of it is about making sure information and systems are available as required when required by the right audience and of course some organizations will have very important um commitments on this you know maybe you have a commitment as an organization to ensure certain systems are available for a certain amount of time. So this is all about focusing on things like system resilience, ensuring that there's Where necessary, there's failover in place, so that we have disaster recovery and business continuity plans in place. Now whilst ISO says we should uh focus on those three things I think it's important to point out one point. It doesn't tell us which one of those is more important. This depends on the context of your organization and looking at risk. And a couple of very quick examples I can give on two two totally different industries. So of course I mentioned in my introduction that I spent some time working with the health service in the UK. So in that context Obviously confidentiality was very high on our radar, you know, respecting the patient's right to privacy, protecting very sensitive medical records. was right up there. But equally integrity was. You know, I always say to people, imagine a doctor treating a patient with inaccurate medical records or data that's been corrupted. You know, the consequence could be extremely significant. Separately, I did some work for an electricity distributor, so think of it like a national grid organization. And on that project we were doing an industrial control system security project. So what we were interested in was protecting essentially computer systems that controlled electricity substations on the on the uh power grid. Now for that there wasn't really a lot of confidential information. you know there's no patient records or customer data. Maybe the designs of the system were probably the confidential information we wanted to protect. Our focus was very much on system integrity, controls to prevent or reduce the risk of people tampering with those systems And of course availability. You know, if somebody could do a denial of service attack and bring one of those systems down, they could cause significant disruption in the country that we're speaking about. So that project was much more focused on availability. My point being, n neither of them are right or wrong. Both of them are perfectly compatible under ISO twenty seven thousand and one and it's all about focusing in the right areas and looking at the organisation priorities. Just speaking of availability, um this diagram here just tries to pin together the relationship between information availability versus confidentiality and integrity. So of course we have on the side here it says information security. So information security is supported by uh data confidentiality controls and integrity. If we think about availability, what we should say is availability isn't just about a system being up and running. It's about other things as well. A system may be up and running, but is it reliable? In other words, if I go to use the system, you know, is it still going to function correctly And timeliness and performance are all part of that. You know, let's say I'm um I'm an online customer going to a website, uh that website might well be there, but if I can't make, for example, a purchase because because of performance issues, then I still wouldn't argue that the system is available. And there are multiple things that support system availability. So the there are those things that prevent systems going offline in the first place, such as housing those systems in an environment with adequate physical security, your professional data center with fire suppression and um you know air conditioning and uh monitoring and all of those things. Having effective security policies in place which reduce the risk of actions being taken that could bring systems offline Designing systems in such a way that they're what we call redundant. So let's imagine we have a a hardware failure, that we don't just lose the system because of one hardware failure, that another piece of hardware Where um that kicks in. So even with networking, you can do that with firewalls, you know, you can have failover firewalls, for example. Uh making sure there's adequate monitoring. So these are all preventative things, hopefully to stop the loss of availability when things go wrong. And then of course in worst case scenarios, having adequate business continuity plans which lay out how we would recover. if something significant happened in terms of interruption and also thinking about backups and having adequate backups in place so we could recover from a trusted uh backup. Now one thing to say about all of the things I've mentioned, because I've mentioned them at a very high level, when we look at ISO 2701, uh how rigorous we need to be in each of these areas comes back to your risk assessment. So for example, ISO 27001 is not sitting. For every piece of hardware you must have an equal and uh uh opposite duplicate for example or that you must have two power feeds into your data centre etc you might determine that your availability needs are so high that that makes absolute sense and you need to invest in those controls. In other environments where the availability requirement may be less, then you can make different decisions. So ISO is not dictating here, but what it is saying is these are the areas to think about when it comes to availability So ultimately, yes, yes we're about protecting confidentiality and integrity, but we also want to make sure we have information systems we can trust and have a confidence in and have a confidence. That they'll be there when we need to use them. \ No newline at end of file +The idea of this section is to introduce the sort of terminology and meanings that ISO 27001 contains so that as we go forward with talking about auditing a management system, we can all understand the meaning of different terminology. + +- information and asset +- information security +- confidentiality, integrity and availability +- vulnerability, threat and consequence +- information security risk +- classification of security controls +- cybersecurity +- information privacy + +Let's start with **information and asset**, because one thing that ISO 27001 says is that we're trying to protect our information assets. We can get the official definition of these two words from ISO 9000, basically a quality management series of standards, and ISO 55000, which is the asset management series of standards. + +**Information** is meaningful data, that is to say data that we can do something with. If I've got a customer database. containing customer records, names, addresses, order histories, etc., that has some meaning, some use, and some purpose. We typically say that an **asset** is something that has value. That might be a financial value, or value in terms of usefulness and service to the organization. Assets can be tangible, like a computer, a building, some equipment, etc., or intangible, like the people who work for your organization, ideas and intellectual property, and information. + +So ultimately an ISMS based on ISO 27001 is about identifying those assets, those pieces of information, those data sets, etc., working out how valuable they are, and then essentially protecting them accordingly. Now when we think about information assets there are some other terms we need to be familiar with. The concept of **document specifications** and **records**. A document is the information and the medium upon which it's contained. That could be a traditional Microsoft Word document, but equally a Confluence or a Wiki page with information could be considered a document, in ISO speak. + +Some documents can state very clear requirements, like a document that says how a network device should be configured. In ISO terminology, that is called a **specification**. When an organization runs an ISMS and follows the requirements laid out in some of these documents, they end up generating **records**. For example, in your ISMS you have a process for reporting information security incidents. Somebody follows it and reports an incident through whatever reporting channel. Then there'd be a record: some evidence that that process has been used. +If you had a specification about how backups should be done and those backups run, of course there'd be logs generated, those logs would be records because they would serve as *evidence that the activity is taking place*. +Records are very important in an ISMS, because they serve as an audit trail, and also because records can contain sensitive information in their own right, and need a certain level of protection. So an ISMS will concern itself with protecting documents and records. + +So what is **information security** according to ISO 27000? The definition says "Information security is the preservation of confidentiality, integrity and availability of information" (Clause 3.28). Information security also means determining what information needs to be protected, how it should be protected, and from what. So we need to identify the kind of information we are trying to protect. And we need to do some research into the potential risks that that information faces. + +So different organizations implementing an ISMS may protect their information very differently depending on the type of information we're speaking about and the type of risks they face. The standard is flexible enough to tailor your controls as needed. + +Another thing that's important in the definition of about information security, is that it covers information in all formats. There's a lot of talk about cyber and cybersecurity, and that is focusing very much on the technology aspects of protecting the technical systems that will store and process information. That makes sense because the vast majority of information today is indeed processed electronically. But it's not *all* processed electronically. It is still possible to have information in paper format, in video format, in spoken word, etc. So information security concerns itself with protecting that information regardless of format. + +The last thing to say before we move on, is when we look at information security in the ISO context, we're always focusing on the business objectives Information security should be an enabler, not a disabler. In other words, we're implementing security to enable the organization to achieve it's goals. + +ISO says that the three pillars, or tenets, of information security are **confidentiality, integrity and availability**. It's important to note that when you set up an ISMS, you're not limited to just these three. They are the *minimum* three things you would think about. In a regulated industry, for example, you need to have strong audit trails of activity and you're concerned about accountability. If your organization is producing products or services and that you're concerned about being counterfeited or pirated, you need controls for digital rights management, authenticity management, etc. If you're in the business of doing transactions and you don't want people to be able to deny activities, you're concerned about non-repudiation. The point is that, just because they're not explicitly called out by ISO, doesn't mean that they don't matter or can't be thought about. + +But let's focus on the first three, the confidentiality, integrity and availability. **Confidentiality** is about limiting access to information to only those people who need it, about having control over information, and who can access it. Organizations can achieve that in many ways by implementing robust authentication for example, establishing a clear data access policy, having proper access control, and using things like encryption or data masking — all of these are confidentiality techniques. + +But if information is an asset because we use it to make business decisions, to respond to problems and challenges, etc., then we want some confidence that the information is actually trustworthy, up to date, accurate, and so forth. That is where we concern ourselves with **integrity**. So integrity is about implementing controls that reduce the risk of unauthorized changes to data, data corruption. It helps us ensure minimum data quality so that when we do come to rely on a system, or the information it contains, we can have confidence within it. + +Now confidentiality is not much use if the people in an organization who need access, can't get it. So there's a balance here with locking things down for confidentiality's sake, and keeping information available. So the principle of **availability** is about making sure information and systems are available as required, when required, by the right audience. Some organizations will have very important commitments to ensure certain systems are available for a certain amount of time. So this is all about focusing on things like system resilience, ensuring that there's failover in place where necessary, so that we have disaster recovery and business continuity plans in place. + +Now whilst ISO says we should focus on those three things, it doesn't tell us which one of those is more important. That will depend on the context of the organization and the risks. For the UK Health Service, confidentiality is obviously very high on the radar –, respecting the patient's right to privacy, protecting very sensitive medical records – but integrity also is. Imagine a doctor treating a patient with inaccurate medical records or data that's been corrupted: the consequence could be extremely significant. On the other hand, an electricity distributor doesn't really have a lot of confidential information, but it will focus on system integrity, controls to prevent or reduce the risk of people tampering with those systems, and of course availability. An attack that would bring one of those systems down, could cause significant disruption in the country we're speaking about. An organization like that is much more focused on availability. It's all about focusing on the right areas and looking at the organization's priorities. + +This diagram tries to pin together the relationship between information availability versus confidentiality and integrity: + +![](CleanShot%202026-06-05%20at%2017.14.11.png) + + +On the right here it says 'information security'. Information security is supported by data confidentiality and data integrity. Now availability isn't just about a system being up and running, it's also about . It's about other things like **reliability**, **timeliness** and **performance**. If a customer goes to a shopping website, that website might well be online, but if you can't make a purchase due to performance issues, then you couldn't well argue that the system is available. There are multiple things that support system availability. Things that prevent systems going offline in the first place, such as housing those systems in an environment with adequate **physical security**, your professional data center with fire suppression, air conditioning, and climate control. Having effective **security policies** in place which reduce the risk of actions being taken that could bring systems offline. Designing systems in such a way that they're what we call redundant. You can have **redundancy** for hardware failure, networking, firewalls, etc. By making sure there's adequate **system monitoring** and **operational controls**. These are all preventative things, to prevent the loss of availability when things go wrong. And then in worst case scenarios, having adequate **business continuity plans**, which lay out how we would recover if something significant happened in terms of interruption, and also thinking about having adequate backups in place so we could recover. + +Now one thing to find out about all of these things, is how rigorous we need to be in each of these areas. This comes back to your risk assessment. ISO 27001 is not saying that for every piece of hardware you must have an equal and opposite duplicate, or that you must have two power feeds into your data centre, etc. You might determine that your availability needs are so high, that that makes absolute sense and you need to invest in those controls. In other environments where the availability requirement may be less, you can make different decisions. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S04.2-Fundamental-concepts-and-principles-of-information-security.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S04.2-Fundamental-concepts-and-principles-of-information-security.md index d61dfd3..6295f0e 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S04.2-Fundamental-concepts-and-principles-of-information-security.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S04.2-Fundamental-concepts-and-principles-of-information-security.md @@ -7,6 +7,7 @@ tags: - PECB-LA isotags: [] status: active +processed: true --- # S04.2 Fundamental concepts and principles of information security @@ -16,4 +17,71 @@ This session covers risk-related terminology central to ISO 27001 auditing. It d ## Transcription -So now that we've talked about confidentiality, integrity, and availability. We just need to focus on some other terminology that ISO brings to us, which is related to the topic of risk, because ultimately managing information security risk is what having an ISMS is all about. So let's just have a look at these terms again just to make sure we're all on the same page, so to speak. And the first one of those I wanted to speak about was the term vulnerability. And we'll look straight away here at the ISO definition of the term vulnerability, which says the following. A weakness of an asset or control that can be exploited by one or more threats. So what I tell people generally if I'm talking about vulnerability is exactly that, the definition, weakness. Let's go with a very simple example of vulnerability. Let's imagine I go out the house in the morning and leave my door unlocked uh you could argue that we have a security vulnerability. There is a weakness in security in that case. If I was to connect my laptop to the internet without any uh firewall or without any anti-malware control, I would have a series of vulnerabilities. or weaknesses. Now for those of you who've been in information security for some time and maybe have worked in the technical part of security, maybe you've done things like vulnerability scans using tools like Aqualis or OpenVAS and S's something like that. And of course if you've done that, you'd be very familiar with a lot of common technical vulnerabilities, you know, missing patches, misconfigurations. you know, default manufacturer passwords left on systems and various things. And you'd be correct to point out that all those things would be weaknesses or vulnerabilities. But I must point out that vulnerabilities are not just technical when we think about an ISMS. We can have vulnerabilities in multiple places. So if for example we have an organization that uh has flaws in its background checking process when it hires people, that would be a vulnerability. If I have an organization that has gaps in its physical security, in its buildings and premises, those would also be vulnerabilities. So what we've got here is a a table from ISO 27005, well more to the point, an extract from ISO 27005 So ISO 27005 is a guidance document on information security risk management. And when you look up a vulnerability in that guidance document, you can see there's a number of categories and some examples of vulnerability. Now this is not of course an exhaustive list, it's just there to help you understand the terminology. So we can see examples of vulnerabilities in multiple areas in hardware, software, networks, with people with buildings, etc. And so the real thing is in the the real world when we're looking at an ISMS we'll be looking at where we have vulnerabilities in an organization. Now one key thing I always tell people on this about wording is you can work out if something's a vulnerability by the kind of language we use. So this is true for the real world and if you're taking the exam and you see any questions that might ask you about vulnerabilities, for example, the key words we're looking for there is usually words like, as you can see, insufficient. missing, absent, uncontrolled, poorly controlled, etc. If I hear things like that, that typically tells me those are my weaknesses or my vulnerabilities Now, of course the question is from a practical point of view in the real world how do organizations identify vulnerabilities Well for non-technical vulnerabilities like say flaws in the human resource processes or physical security there may be specific assessments and reviews of processes that can reveal that. But if we think about technology, the security testing and evaluation is where we might look at particular components, let's say in a network. network equipment so let's take a switch or a firewall and we basically have uh some experts sort of take a look at that and identify weaknesses So for example, one piece of work I sometimes do for organizations is exactly that. So we'll take a firewall and we're not going to try and break into that firewall, for example. in this example but we're going to take a look at the rule set. We're going to look for potential holes if you like traffic that that's being allowed through that possibly shouldn't be. Perhaps we'll look for misconfigurations that we can see that may be open to manipulation or misuse. So security testing and evaluation is one way of doing that. We can also do more deep dive tests, you know, as well as doing vulnerability scans, we can try and prove whether vulnerabilities exist For vendors who are producing products that they're selling, they can go through quite a rigorous process of security testing and evaluation. One particular scheme that you may be familiar with is something called Common Criteria. So Common Criteria is a global standard. It's based on an ISO standard called ISO 15408. What this is, is a security testing and evaluation process. So let's take a vendor. So take one at random, let's say a company like Cisco, for example. So let's say that they produce a new firewall that they want to sell, and maybe they want to sell it to very specific sectors like healthcare or government, etc. They may make a number of claims about the security of that device. They can then take that device to a common criteria lab and there are a number of those listed, an official lab, and that lab will set about doing a number of very rigorous tests to validate the claims that are being made and at the end of those tests we'll produce a report and also an i an evaluation level rating. And the evaluation level rating isn't necessarily about how good the security is, it's more about the level of tests that have been done. done. But the vendor, assuming it's successful, can then state our product is listed on the Common Criteria Portal and it's had this level of evaluation. And a customer can then go and look at the report and understand what testing's been done and what vulnerabilities may or may not have been addressed. So that's Obviously a very specific example. There are other schemes out there like that. So you can do your own testing, but there are independent security tests available. Another way that organizations discover vulnerabilities, not so much in products like the example I've given there, but in their environments more widely, is through a topic of what we call penetration testing. Now penetration testing is is worthy of uh possibly many hours of discussion, but I'll try and keep this as uh brief and to the point as I can. So in penetration testing This is where an organisation will invite qualified professionals to come and essentially probe their systems and essentially attempt to act in a similar way to a potential attacker. So not only will they ask the penetration tester to try and find vulnerabilities, they'll actually ask that test team to see if they can exploit those vulnerabilities. To then give advice on how we might remove those vulnerabilities to stop a real-world attacker taking advantage. There are different types of pen tests that can be done. depending on what you're trying to understand. And you may have heard of the term white box and black box penetration testing. So for example in a black box test This is where you might be concerned about, let's say, an unauthenticated attacker on the internet who doesn't have any existing access to your systems. So you're asking the tester to see what they can do without any information, without any credential. That's one extreme. On the other extreme where we talk about white box testing, that's where you give the testers information about your system. maybe even standard login credentials because what you're doing in a white box test is maybe looking at the system from an internal perspective. You know, so could somebody who already has access, legitimately or not, for example, elevate their privilege or do something that um they shouldn't be doing. So you choose which scenario is appropriate. You can also think about does the security team that are monitoring networks, for example, need to know about the the test? In other words, do we want them to be aware so they can be aware that when there's strange logs, etc. that's something Something's happening. Or are we using the pen test to test their capability to detect? A lot of organizations now are good are using this idea in something you may have heard of called red and blue teaming, for example where you've got the blue team that essentially defends the network and systems and the red team which is essentially pro-bring and testing all of the time There's a lot more we could say about that. The only thing I'd say right now is we need to be very careful with pen testing to make sure that we get best value from it by focusing it on those systems. that need that level of scrutiny and making sure we select testers who are competent. So maybe having a look at whether your testers are uh properly registered under schemes such as Crest or Tiger. There's many of other other schemes out there. So you can be sure that when they are giving you a report that there's a level of accuracy around it. The only limitation I would tell people about Pentel testing as well before I move off this is of course a pen tester has a limited amount of time because you buy their time based on a budget. A real-world attacker is not limited by a number of days, a number of hours, etc. So that's always something to bear in mind. But certainly security testing of products, doing your own security reviews and vulnerability tests and penetration testing can all come together to help us understand the kind of vulnerability. We have from a technical perspective. Now, of course, that all being said, we could produce lots of reports about all the vulnerabilities that exist, and some people would be correct to say, well Why is that an issue? Is somebody really going to take advantage of those vulnerabilities, etcetera? And that's where we move on to the concept of threat The ISO definition of threat, the potential cause of an information security incident that can result in damage to a system or harm to an organization. So think of the threat or threats as things that will potentially take advantage of those vulnerabilities. Now what I tell people before we have a look at the list from ISO is that you could break threats down really into three categories. You've got your deliberate or malicious. So this is groups of people who are deliberately aiming to gain unauthorized access, conduct any denial of service, conduct fraud, wherever it might be. So the deliberate and malicious threats We've got our accidental threats and there's plenty of those. So that's you know things like human errors. Imagine the employee who accidentally sends confidential data to the wrong email address or you know, copies data to Dropbox by mistake or something silly like that, but still extremely serious, but just not malicious, accidental threats. And then of course from the availability point of view we might have natural threats, things like fires, floods, weather events, etc. So we do need to think about all of them And if we take a look at this table from ISO 27005, again an extract from the table, this gives us some examples of threat. And you can see that they're bunched into multiple areas. And also you can see this column that talks about risk sources. So within ISO 27005, a risk source is basically saying where essentially a risk comes from So for example, you know, if you had a building and in that building you're you're um storing lots of um let's say dangerous chemicals, for example, that's that's a source of risk. That those are there give rise to risk. Now, one thing I'd like to say is if you're doing this in the real world and thinking about threats, you might want to think very carefully, particularly about the deliberate threats about the source of those threats. So you might want to think just for a moment about as an organization based on the type of organization you are and the type of data you're processing How interesting might your organization or its business be to certain threat sources? So for example, we could say threat sources are things like organized criminal groups, competitors. foreign governments or intelligence services, media outlets and journalists, and so on. And we could we could add many more to that list. And what you want to ask yourself is, well, do are we doing anything or do we have anything that might be interesting with those groups and how capable and how motivated are they? Now I can't just come up with the answer to that out of thin air. Often we'd need to look at the threat intelligence, we'd need to to do a lot of research around this. So why bother to do that? Well if we do that, then we understand the kind of threats we face, of course we can can uh put in a level of protection that's suitable, you know, protecting yourself from a determined advanced persistent threat. such as a foreign intelligence service, is a very different matter to protecting yourself against, let's say, your trivial technical hackers. They're both uh offer a level of threat, but those levels of threat are very different. So I do think it's worth thinking that through. It's also worth thinking through uh threat scenarios, that is to say, how maybe a s a threat source could influence what we call a threat actor. And I always just use a real-world incident just to just to call this out. And it's it's a little dated one, but I think it still really helps. This was a real-world story of a bank based in London uh quite quite some time ago now, but long story short, a um organised crime group who were looking to commit fraud and essentially They basically bribed a cleaner who had access to the office after hours unsupervised. They bribed this cleaner to install keylogger devices on a number of machines. Now today that attack probably wouldn't work because you would imagine most organisations would then put restrictions in place around USB, etc. But at the time restrictions weren't there. And then essentially with the login details they'd gleaned through these keyloggers, they were able to log in and basically commit large amounts of um data transfers. So but the point about that story is is that you have different people involved. You have a threat source uh essentially uh affecting the behaviour of an insider in this case. So that's a threat scenario. So it is worth thinking about that in the real world and really sort of doing some work to get under the hood as to how threats might you know manifest themselves in reality. We could say a lot more about that, but we'll park that there for the moment because beyond that we're getting into the realms of threat hunting, threat intelligence. etc. But what I want to just uh sort of point to here on this table is the relationship between vulnerability and threat. Now we've deliberately done it here as more of a one-to-one mapping just so that the the you know it's understandable. Like the first line, if we have a warehouse that's unprotected without surveillance, that's a vulnerability that could be exploited through theft. Or if we're using pirated software, then that software might be vulnerable to malware and other such things like that. In real life it can of course be a lot more complex than this. You know, one vulnerability might be exploited by multiple threats, or the other way around, you know, a threat might attempt in order to launch its attack to attack several vulnerabilities. However, for the sake of where we are now, these are the things that we need to be clear about. So let's imagine then, just uh hypothetically, a threat takes advantage of a vulnerability. When that happens and an incident takes place, we have what we call a consequence. Now here I'm not talking about business consequences like cost or legal action or reputational damage. First, we're going to talk about the consequences to the three tenants of security. So is the scenario affecting or could it affect availability of bringing a system offline? interrupting uh performance. Could it be a consequence on confidentiality, you know, a data leak, unauthorized access to data, unauthorized sharing of data Or could it be something that has an integrity impact? You corrupts data, allows people to make changes without authorisation, allows fraud, for example, to take place. And the reason we're bringing this up is when we think about risk in ISA 27001, this is what we're trying to look at each time. Now there may be some scenarios that affect all three tenants of security some that are very specific, but of course understanding that can allow you to think very carefully about the prioritization of risks And in this next table, now you've got the vulnerability and threat and the consequence in the column here as well. So if we had the unsupervised warehouse and we had theft, of course we would suffer from a financial loss. If we were transferring passwords across a network in the clear and we had some kind of eavesdropper or hacker, whatever their motivation, you know, intercepting that traffic, we could have potential information thing. I would argue we could have a lot more problems as well. But the idea is there's a relationship between all of these. And when we look later on at risk management, This is the important aspect. Now as an auditor, um you're not necessarily conducting the risk assessment for the organization, but what you are doing is validating that their risk scenarios make sense. So to be familiar with these things These concepts is really important. So the final thing to say on these terminologies is these all play into the concept of risk. And according to Weissot 27005, the definition of risk, information security risk, is the effect of uncertainty on objectives. So what we mean is um Risk is something that hasn't happened yet. It's an uncertain situation. And the study of risk is to try and think about the likelihood of some of these scenarios that we're talking about playing out. and the impact of them, the damage that can be done. And we have further discussion here based on the the NIST standards, the special publication 830 And it has a definition of information security risk which says the risks of organizational operations, organisational assets, individuals, other organisations and the name the nation in this case, due to the potential for unauthorised access, use, disclosure, disruption, modification, or destruction of information and or information system That's quite a long definition, but in a nutshell, what it's saying is it is the uncertainty related to the potential compromise of information. Now in this case where it mentions the nation, just to be clear on that, that's because NIST is a federal government standard in the US that focuses not just on organisational security. But national security, but even if you're not concerned about in your organization national security, I think everything else in that definition is absolutely perfect. So that's what we're trying to do in an ISMS And as an auditor, we're trying to validate that the organisation has got their approach right and they really do understand these issues and they really have identified the right kind of risks that's relevant to them. \ No newline at end of file +So now that we've talked about confidentiality, integrity, and availability. We just need to focus on some other terminology that ISO brings to us, which is related to the topic of risk, because ultimately managing information security risk is what having an ISMS is all about. + +The first one of those I wanted to speak about was the term **vulnerability**. The ISO definition of the term vulnerability is: "a weakness of an asset or control that can be exploited by one or more threats". Or in other words, a weakness. Let's go with a very simple example of vulnerability. If go out the house in the morning and leave my door unlocked uh you could argue that we have a security vulnerability. There is a weakness in security in that case. If I was to connect my laptop to the internet without any uh firewall or without any anti-malware control, I would have a series of vulnerabilities. or weaknesses. Now for those of you who've been in information security for some time and maybe have worked in the technical part of security, maybe you've done things like vulnerability scans using tools like a QoLIS or OpenVAS, a Nessus and something like that, and of course if you've done that, you'd be very familiar with a lot of common technical vulnerabilities, you know, missing patches, misconfigurations. you know, default manufacturer passwords left on systems and various things. And you'd be correct to point out that all those things would be weaknesses or vulnerabilities. + +But I must point out that **vulnerabilities are not just technical when we think about an ISMS**. We can have vulnerabilities in multiple places. So if for example we have an organization that has flaws in its background checking process when it hires people, that would be a vulnerability. If I have an organization that has gaps in its physical security, in its buildings and premises, those would also be vulnerabilities. + +![](CleanShot%202026-06-05%20at%2020.42.44.png) + +So what we've got here is an extract from ISO 27005, a guidance document on information security risk management. And when you look up a vulnerability in that guidance document, you can see there's a number of categories and some examples of vulnerability. Now this is not of course an exhaustive list, it's just there to help you understand the terminology. So we can see examples of vulnerabilities in multiple areas in hardware, software, networks, with people with buildings, etc. And so the real thing is in the the real world when we're looking at an ISMS we'll be looking at where we have vulnerabilities in an organization. + +Now one key thing I always tell people on this about wording is you can work out if something's a vulnerability by the kind of language we use. So this is true for the real world and if you're taking the exam and you see any questions that might ask you about vulnerabilities, for example, the key words we're looking for there is usually words like, as you can see, insufficient, missing, absent, uncontrolled, poorly controlled, etc. If I hear things like that, that typically tells me those are my weaknesses or my vulnerabilities. + +Now, of course the question is from a practical point of view in the real world how do organizations identify vulnerabilities. Well for non-technical vulnerabilities like say flaws in the human resource processes or physical security there may be specific assessments and reviews of processes that can reveal that. But if we think about technology, the security testing and evaluation is where we might look at particular components, let's say in a network. Let's take network equipment, like a switch or a firewall, and basically we have some experts take a look at that and identify weaknesses. For example, by taking a look at the rule set. We're going to look for potential holes like traffic that's being allowed through, that possibly shouldn't be. Perhaps we'll look for misconfigurations that may be open to manipulation or misuse. So security testing and evaluation is one way of doing that. We can also do more deep dive tests, like vulnerability scans, to prove whether vulnerabilities exist. Vendors who are producing products that they're selling, can go through quite a rigorous process of security testing and evaluation. + +One particular scheme that you may be familiar with is something called **Common Criteria**. So Common Criteria is a global standard, based on ISO 15408, which is a security testing and evaluation process. So let's take a vendor like Cisco, and say that they have a new firewall that they want to sell to very specific sectors like healthcare or government. They may make a number of claims about the security of that device. They can then take that device to a common criteria lab and there are a number of those listed, an official lab, and that lab will set about doing a number of very rigorous tests to validate the claims that are being made, and at the end of those tests we'll produce a report, and also an **evaluation level rating**. And the evaluation level rating isn't necessarily about how good the security is, it's more about the level of tests that have been done. But the vendor, assuming it's successful, can then state 'our product is listed on the Common Criteria Portal and it's had this level of evaluation'. And a customer can then go and look at the report and understand what testing's been done and what vulnerabilities may or may not have been addressed. + +Another way that organizations discover vulnerabilities, not so much in products like in the previous example, but in their environments more widely, is through what we call **penetration testing**. Now penetration testing is is worthy of possibly many hours of discussion, but I'll try and keep this as brief and to the point as I can. So in penetration testing an organization will invite qualified professionals to come and probe their systems and attempt to act in a similar way as a potential attacker would. So not only will they ask the penetration tester to try and **find vulnerabilities**, and ask that test team to **see if they can exploit them**. To then give advice on how we might remove those vulnerabilities to stop a real-world attacker taking advantage. There are different types of pen tests that can be done. depending on what you're trying to understand. + +And you may have heard of the term white box and black box penetration testing. In a **black box test**, the tester will take the role of an unauthenticated attacker on the internet **without any existing access to your systems**. So you're asking the tester to see what they can do without any information, without any credentials. That's one extreme. On the other extreme where we talk about **white box testing**, that's where the **testers are given information about your systems**, and maybe even standard login credentials, because what you're doing in a white box test is looking at the system from an internal perspective. Could somebody who already has access, legitimately or not, **elevate their privilege** or do something that they shouldn't be doing. You choose which scenario is appropriate. + +You can also think about does the security team that are monitoring networks, for example, need to know about the test? In other words, do we want them to be aware of the testing, so when they see strange logs, etc., they do, or don't, interrupt the test. Are we using the pen test to find just technical vulnerabilities, or the security team's capability to detect? A lot of organizations are now using the method of **red and blue teaming**, where the blue team essentially defends the network and systems, and the red team is probing and testing for vulnerabilities all the time. + +We get best value from pen testing by focusing it on those systems that need that level of scrutiny, and making sure we select testers who are competent. So maybe having a look at whether your testers are properly registered under schemes such as Crest or TIGER. There's many of other other schemes out there. So you can be sure that when they are giving you a report that there's a level of accuracy around it. The only limitation I would tell people about pen testing as well before I move off this, is a pen tester has a limited amount of time because you buy their time based on a budget, where a real-world attacker is not limited by a number of days, a number of hours, etc. + +But certainly security testing of products, doing your own security reviews and vulnerability tests and penetration testing can all come together to help us understand the kind of vulnerability we have from a technical perspective. + +Now, of course, that all being said, we could produce lots of reports about all the vulnerabilities that exist, and some people would be correct to say: well, why is that an issue? Is somebody really going to take advantage of those vulnerabilities, etcetera? And that's where we move on to the concept of threat. The ISO definition of **threat**: "the potential cause of an information security incident that can result in damage to a system or harm to an organization". So think of the threat or threats as things that will potentially take advantage of those vulnerabilities. + +You could break threats down into three categories: +- **deliberate** or **malicious**. So this is groups of people who are deliberately aiming to gain unauthorized access, conduct any denial of service, conduct fraud, wherever it might be. +- We've got our **accidental threats** and there's plenty of those. So that's you know things like human errors. Imagine the employee who accidentally sends confidential data to the wrong email address or you know, copies data to Dropbox by mistake or something silly like that, but still extremely serious, but just not malicious, accidental threats. +- And then from the availability point of view we might have **natural threats**, things like fires, floods, weather events, etc. + +So we do need to think about all of them. This extract from the table from ISO 27005, this gives us some examples of threats. + +![](CleanShot%202026-06-05%20at%2021.19.48.png) + + +And you can see that they're bunched into multiple categories, and there's a column that mentions **risk sources**. Within ISO 27005, a risk source is basically saying where essentially a risk comes from So for example, you know, if you had a building and in that building you're storing lots of dangerous chemicals, that's a source of risk. + +Now, one thing I'd like to say is if you're doing this in the real world and thinking about threats, you might want to think very carefully, particularly about the source of deliberate threats, based on the type of organization you are and the type of data you're processing. How interesting might your organization or its business be to certain threat sources? So for example, we could say **threat sources** are things like organized criminal groups, competitors, foreign governments or intelligence services, media outlets and journalists, and so on. And we could we could add many more to that list. And what you want to ask yourself is, are we doing anything or do we have anything that might be interesting to those groups, and how capable and how motivated are they? + +Now I can't just come up with the answer to that out of thin air. Often we'd need to look at the threat intelligence, we'd need to to do a lot of research around this. So why bother to do that? Well if we do that, then we understand the kind of threats we face, of course we can put in a level of protection that's suitable. Protecting yourself from a *determined advanced persistent threat*, such as a foreign intelligence service, is a very different matter to protecting yourself against, let's say, your trivial technical hackers. They offer very different levels of threat. + +It's also worth thinking through **threat scenarios**, that is to say, how maybe a **threat source** could influence what we call a **threat actor**. And I always just use a real-world incident just to just to call this out. This was a real-world story of a bank based in London quite some time ago, and an organized crime group who were looking to commit fraud. They bribed a cleaner who had unsupervised access to the office after hours, to install keylogger devices on a number of machines. With the login details they'd gleaned through these keyloggers, they were able to log in and commit large amounts of data transfers. The point about that story is that you have different people involved. You have a threat source affecting the behavior of an insider. So that's a threat scenario. + +So it is worth thinking about that in the real world and really sort of doing some work to get under the hood as to how threats might manifest themselves in reality. We could say a lot more about that, but we'll park that there for the moment because beyond that we're getting into the realms of threat hunting, threat intelligence. etc. But what I want to point to here, is the relationship between vulnerability and threat. + +![](CleanShot%202026-06-05%20at%2021.36.38.png) + +Now we've deliberately done it here as more of a one-to-one mapping just so that the the you know it's understandable. Like the first line, if we have a warehouse that's unprotected without surveillance, that's a vulnerability that could be exploited through theft. Or if we're using pirated software, then that software might be vulnerable to malware and other such things like that. In real life it can of course be a lot more complex than this. You know, one vulnerability might be exploited by multiple threats, or the other way around, you know, a threat might attempt in order to launch its attack to attack several vulnerabilities. However, for the sake of where we are now, these are the things that we need to be clear about. + +So let's imagine then, just hypothetically, **a threat takes advantage of a vulnerability**. When that happens and an **incident** takes place, we have what we call a **consequence**. Now here I'm not talking about business consequences like cost or legal action or reputational damage. First, we're going to talk about the **consequences to the three tenants of security**. So is the scenario affecting availability by bringing a system offline or interrupting performance? Could it be a consequence on confidentiality, like a data leak, unauthorized access to data, unauthorized sharing of data? Or could it be something that has an integrity impact? Like corrupting data, allowing people to make changes without authorization, committing fraud. And the reason we're bringing this up is when we think about risk in ISA 27001, this is what we're trying to look at each time. + +![](CleanShot%202026-06-05%20at%2021.41.14.png) + +Now there may be some scenarios that affect all three tenants of security some that are very specific, but of course understanding that can allow you to think very carefully about the prioritization of risks. And in this next table, now you've got the vulnerability and threat and the consequence in the column here as well. + +![](CleanShot%202026-06-05%20at%2021.41.41.png) + +So if we had the unsupervised warehouse and we had theft, of course we would suffer from a financial loss. If we were transferring passwords across a network in the clear and we had some kind of eavesdropper or hacker, whatever their motivation, you know, intercepting that traffic, we could have potential information theft. I would argue we could have a lot more problems as well. But the idea is there's a relationship between all of these. And when we look later on at risk management, this is the important aspect. + +Now as auditor, you're not necessarily conducting the risk assessment for the organization, but what you are doing is validating that their risk scenarios make sense. So to be familiar with these concepts is really important. + +So the final thing to say on these terminologies is these all play into the concept of risk. And according to ISO 27005, the definition of risk, information security **risk is the effect of uncertainty on objectives**. A risk is something that hasn't happened yet. It's an uncertain situation. And the study of risk is to try and think about the likelihood of some of these scenarios that we're talking about playing out, and the impact of them, the damage that can be done. And we have further discussion here based on the NIST standards, NIST SP 800-30 has a definition of information security risk which says: “The risk to organizational operations (including mission, functions, image, reputation), organizational assets, individuals, other organizations, and the Nation due to the potential for unauthorized access, use, disclosure, disruption, modification, or destruction of information and/or information systems.” +That's quite a long definition, but in a nutshell, NIST SP 800-30 is saying it is the **uncertainty related to the potential compromise of information**. Now in this case where it mentions the nation, just to be clear on that, that's because NIST is a federal government standard in the US that focuses not just on organizational security. But national security, but even if you're not concerned about in your organization national security, I think everything else in that definition is absolutely perfect. So that's what we're trying to do in an ISMS. And as an auditor, we're trying to validate that the organization has got their approach right and they really do understand these issues and they really have identified the right kind of risks that's relevant to them. + +![](CleanShot%202026-06-05%20at%2022.22.09.png) diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S04.3-Fundamental-concepts-and-principles-of-information-security.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S04.3-Fundamental-concepts-and-principles-of-information-security.md index a6ba183..d92eab8 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S04.3-Fundamental-concepts-and-principles-of-information-security.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S04.3-Fundamental-concepts-and-principles-of-information-security.md @@ -7,6 +7,7 @@ tags: - PECB-LA isotags: [] status: active +processed: true --- # S04.3 Fundamental concepts and principles of information security @@ -15,5 +16,48 @@ status: active This session covers security control types and functions within an ISMS context. Controls are categorized by type (technical, administrative, managerial, legal) and by function (preventative, detective, corrective). The session emphasizes the importance of detective controls, noting industry data suggesting organizations take six to seven months on average to detect a breach. It explains the layered relationship between ISO 27001 clause requirements, Annex A controls, and underlying technical implementations. The session concludes by distinguishing information security, cybersecurity, and privacy, explaining that cybersecurity is a subset of information security and that privacy protection requires additional ethical and procedural considerations beyond pure security controls. ## Transcription +https://mypecb.com/content/e-learnings/571 -So as we we know, we as part of an ISMS expect an organization to understand its risk and to To understand the risk scenarios. And in response to those risks, an organization will be implementing various security controls. And if we look at Annex A of the standard, we know there's 93 security controls in there. And of course they can add others as well. But controls all have a different purpose. So we're just going to look at security controls by type and function. So let's start by type first of all. We could categorize security controls. According to what they do and their purpose. So we have some controls that you might call technical controls. So technical controls in information security is where we implement some kind of technology to restore respond to a problem. So if we implemented a multi-factor authentication system or a firewall or an intrusion detection system, for example, these would all be pieces of technology designed to achieve some kind of objective, a technical context. control and there's a variety of them that we could have. But I think most people would accept, even with really good technical controls, that a lot of them are dependent on good processes and uh that are followed by an organization. And this is where we talk about administrative controls. So administrative controls are where organizations bring in certain processes to manage risk. So you could have things around people like segregation of duties, job rotations, proper approval processes, your change management processes. These would all be example of administrative controls. But also having adequate procedures in place to manage technical controls. So for example, let's say we introduced a a security incident and event monitoring tool, which is a technical control, we'd probably have a bunch of administrative controls to go with it, such as stating how often the reviews of those logs have having a process that would be followed if we detected something suspicious. Those would be administrative processes. So often these will go hand in hand. And when we think about setting up an ISMS, we also have managerial controls. So managerial controls are very focused on people and management of people within the organization. So having things like management reviews, training and awareness programs, having proper internal audits to check that policy, etc. has been followed properly, disciplinary processes, etc. These would all fit under the the banner of managerial controls. And then we also have legal controls and there's two points of view on that. Legal controls are controls we would implement in order to fulfil our obligations under laws and regulations. And also where we use legal instruments to protect our information and information systems. So for example, if we asked people to sign a non-disclosure agreement, providing it's you know legally sound, that would be a legal control. Or let's imagine you have a supplier and you expect that supplier to meet certain security requirements and that's specified in contract. then that contract is essentially a legal instrument, it's a legal control that's helping to protect us. But as well as talking about the types of security controls, we also need to think about the function and the purpose of different securities. security controls. Now in this course we present this as three different functions, preventative, detective and corrective. I'm aware that in some other security studies etc you might have even more categories But for these we we keep it at three. And I just want to run through those three. The first one then, preventative control, is basically a control that we will implement to avoid or prevent the occurrence of a risk as best we possibly can. So for example, if I put strong access control in place on a system with multi-factor authentication, the objective there is hopefully to prevent unauthorised access. If I put a robust firewall at the perimeter of my network again, you would argue that's a preventative control. Or in the physical world, you know, if we put a you know, a vehicle barrier in place or a a strong entry control, these would all be there for the purpose of preventing things. Also, anything that's there to deter people, what you might call a deterrent, I would put in the preventative book it as well. So if I put signage up outside the building saying we're monitoring you with CCTV or a login warning banner that says you're about to log into a confidential system, you've been monitored. Now some people might say, well that doesn't prevent anything. People can just ignore those things. Well of course they can, but they're still there to to to with an effort to deter the attack Now all of this being said, there is plenty of studies to show that pretty much every preventative control that exists can, with enough time, enough motivation, potentially be compromised. Now I don't say that to frighten people or to imply that preventative controls aren't needed. Of course they are, absolutely they are The point I'm trying to make is that we need to think very carefully, going back to my point earlier, about threat. How capable and how motivated are the threats that you face? Because the larger, the bigger capability and motivation they have, the more we're going to need to do on the preventative front. One of my colleagues puts it like this. He says You're never 100% stopping an attack. What you're trying to do is raise the bar so high that the effort required to compromise those preventative controls is so great that the attackers maybe go somewhere else. Essentially that's what you Trying to do. So all of that being said, yes, we need absolutely robust preventative controls in place, without a doubt. But knowing that some preventative controls could be with enough effort and energy and time be compromised, we need the ability to actually spot when preventative controls have been compromised. And that moves us into detective controls. So detective controls are controls that allow us to see that. So things like monitoring and auditing, a security incident and event monitoring tool. our threat hunting activities, intrusion detection, file integrity monitoring, etc. These are all examples of detective controls Now, personally speaking, as somebody in the security business, I'm very focused in this area because um because of various industry statistics and publications etc. And I wanted to draw your attention to a couple of those. So uh over the last couple of years the National Cybersecurity Centre in the UK uh and totally separately uh HP so the um the the large infrastructure Company HP both did separate studies and without getting into too much detail they both implied that there was essentially a significant gap in general between organizations having a security compromise and spotting it. So approximately, and I'm not quoting the days exactly here, but in the ballpark of uh NCSC has suggested around six months things HP is at seven, you know, give or take a few days here and there. But the point is, um these studies are suggesting that organizations on average are taking six to seven months to notice that a security compromise has happened. Now of course you might be watching this and saying, well that's not true for my organizers, you know, you're we we we're much better organized. And that and if that's true, that's Fantastic. But clearly in the industry at large there is a challenges here. So what's that telling us? It's telling us that some organizations at least have blind spots. So investing in detective controls for me is super important to having an effective ISMS. There was a um a saying that a chief information security officer was quoted as saying that I think the RSA Security Conference when they said it's not a case of if you've been compromised, it's a case of you have, but have you detected it? And I don't say these words again to to frighten anybody or anything like that, but it's just to get you thinking about let's not overlook the importance of detective controls. When anybody tells me we've never had a security incident, I would say I'm quite sceptical and my question is well okay what detective controls do you have and how are you using them. Now equally if we are capable of detecting and we are detecting things or things are happening, then of course we need the ability to respond to that. And that's what a corrective control is. So corrective control seeks to respond to identified problems. So things like disaster recovery plans, business continuity plans. plans, um incident management processes, all of these uh root cause analysis processes, all of these would be good examples of corrective controls. And we'd expect to see again a good mix of those in an ISMS. Now one thing that's really interesting actually to talk about is this slide here which gives you layers of control and I think this is this is really interesting to explain what ISO 27001 gives an organization and what it doesn't. So let me just try and clarify this. So we can see essentially three layers in this diagram. At the top, controls that an organization would implement based on clauses 4 to 10. So you can see those controls are all quite managerial in nature, you know, having proper risk management. having a proper policy in place, conducting management reviews, looking at security from a strategic standpoint. And then of course we have annex A. Now we will say that Annex A are general controls. What I mean by that is When I look in Annex A of ISO 27001, it's not going to tell me how to configure security settings in Microsoft Azure or in AWS or on a Cisco firewall. What it's going to give me is a general set of controls and principles that we need to think about as an organization. What's not in there but still needs to be thought about is then how you apply specific technical controls at the technical level. Now what's this got to do with auditing an ISMS then? So let's imagine I come along as an ISMS auditor and you tell me that you have an access control policy and you require multi-factor authentication. Well of course as an auditor I need to get some assurance that that multi-factor authentication in this example is implemented in an effective manner. That means I'm going to have to take a look at the technology that's being used in your state, whether it's Microsoft Azure, AWS, something like that. completely different and look under the hood. And I need to understand that your organization, who I'm auditing, has uh the necessary technical controls at those levels. So what I'm saying is a good auditor isn't just familiar with the content of ISO 27001. You or somebody in your team will of course need to be familiar with the underlying technology. Otherwise it's going to be difficult to have a reasonable assurance that control those controls are implemented properly. So that's the part that requires you, I guess, outside of this course to get familiar with different technology environments and so forth. But just to sum all of this up, we've got a good slide here that might look a bit busy at first glance but is really trying to explain the relationship between all of these things. So in the bottom corner there we've got assets. In the end, the whole purpose of an ISMS is to protect information assets. And what we're saying, or we're trying to explain here, is that risks can of course cause damage, can harm assets And risks are caused by what? They're caused by vulnerabilities and weaknesses that are being exploited by threats. Now, and of course we respond to this by implementing controls, all the different types I've just been talking about. So some controls will reduce vulnerabilities, that's their purpose. Some can be implemented to reduce the amount of damage that can be done, reduce the impact, and or both. But it is worth noting, as it shows you in this diagram here, that controls themselves can have vulnerabilities. You know, I always say if you can fix one problem, could you be creating another one? So let's say for example we decide to introduce an intrusion prevention system for network security. because we have a number of vulnerabilities. So great, we go and implement this intrusion prevention system which when it detects something suspicious starts dropping network traffic Now if we get that properly tuned and implemented correctly, that's excellent. But what happens if it's not tuned very well and it starts dropping network traffic And causing a denial of service problem. So essentially we could create a new problem by fixing an old problem. So we call that secondary risk. So we're simply saying here, do think about that. When you're responding to risk. think very carefully about any new vulnerabilities that might be being introduced. So this is always in an organization an ongoing thought process. Now the last couple of concepts we wanted to introduce you to in this section were based on the fact that the title of the standard talks about setting up an information security management system. with a focus on cybersecurity and privacy. And sometimes the difference between information security, cybersecurity and privacy can cause a little bit of confusion. So we just want to make sure that we're all sort of on the same. same page. So ultimately cyber security based on ISO's definition of it is this safeguarding of people, society, organisations and nations from cyber risks What we mean by cyber risks, essentially they're technical risks. And if you look at ISO standards, they'll they'll still talk about a concept that I remember being talked about a long time ago called cyberspace. And cyberspace is basically think of it as the internet if you like. So any technologically connected system that processes information for faces potential cyber risks. So for the avoidance of any doubt When we set up an ISMS and we do everything in there that we should be and we implement those technical controls, we are and we should be addressing cybersecurity as part of it. So cybersecurity is not a separate thing from information security. Cybersecurity is an element of information security, protecting the technology, the infrastructure, the applications that form part of it. Information privacy, on the other hand, is also mentioned in the standard. And from ISO's perspective, that's about protecting what they call PII, personally identifiable information. So personally identifiable information is anything that will reveal the identity of a living individual. So of course there's obvious things, your your name, address, telephone number. date of birth, etcetera as PII. But even more subtle things. So things like let's say the the IP address you're using when you're connecting to let's say an online service, if that could potentially reveal your identity. In some cases that potentially could be PII. What we're interested in when we look at privacy is a little bit different to security. So bear with me on this. So obviously security is relevant for privacy, but if we look at look beyond ISO and we look at a definition for say for example from GDPR And it talks about privacy being uh essentially protecting the rights and freedoms of individuals. So there's a subtle difference. Of course, in order to ensure somebody's privacy to respect the rights and freedoms of an individual, we need to have adequate security. We need to protect that data. But privacy goes beyond that a little bit. And I always just try to use a very quick example of a project I worked on some time ago to distinguish between the two. So this project in brief was a road tolling project I was working on a project for a a UK project for a bridge essentially where they wanted to change the road tolling system. So previously people could drive to this bridge, uh pay in cash and drive across across it And the the organization behind that wanted to change to an automated system to stop queues basically. What they wanted was that people could drive across that bridge. have a picture taken of their number plate, automated number plate recognition, and then basically be asked to pay the bill online. So you could pay beforehand, you could pay afterwards If you crossed regularly you could even buy a transponder to put in your car and every time you crossed, there'd be an amount debited off that. So let's think about that. I was on that project as the security architect or one of the security architects. So of course my focus there is very much about the security of the network, the applications, you know, the whole sort of operation. And we had separately to that a privacy officer And the privacy officer did the um the privacy impact assessment. And the discussion in that, yes, there was definitely discussion about security of the system, security of the data, but they were then also looking at rights and freedoms and ethical issues. You know, now we're moving from a system where you could drive relatively anonymously across this bridge to one where there is a footprint, there is a record. And what could the impact be on an individual if uh those records were shared? You know, maybe certain people don't want. people to know that they were travelling on that road at that point in time during the day. So the questions start to become how long should we keep that data for? How much should we keep Who should we be sharing it with? What happens if somebody wants to access that data? You know, so a lot of procedural and ethical questions. And does that get included in ISO 27001? It does. There are some controls in there about that, which is why we bring it up. So all we're saying is if you're processing PIR, you need to think beyond just pure security, we do need to build privacy thinking into our ISMS. If you want further guidance on that, you can extend your ISMS to cover privacy in further depth with an extension standard called ISO 27701. which basically takes everything we have in ISO 27001 and adds further controls from a privacy point of view. But even without ISO 27701 there are some privacy controls. within the standard. So in summary, what we've tried to make sure is here that we're speaking the same language when it comes to security in the world of an ISMS So we know that information is meaningful data. That is an asset to the organization. We are building a management system to protect those assets. We at least focus on the three pillars of confidentiality, integrity and availability. We can go beyond that. We focus when building an ISMS on risk by understanding the threats and vulnerabilities that are relevant to us and the consequences if those threats were to exploit vulnerabilities. We can implement controls in response to that, preventative, detective and corrective controls, with a mix of legal, administrative, technical and managerial controls, or blend of controls to manage risk. And we will take care of both cybersecurity and privacy as part of the overall ISMS. So hopefully this has given you a good flavour of all the things we need to think about. And as we move forward, we'll start to examine as auditors how do we really test whether these things are effectively implemented. \ No newline at end of file +So as we we know, we as part of an ISMS expect an organization to understand its risk and to understand the risk scenarios. And in response to those risks, an organization will be implementing various security controls. And if we look at Annex A of the standard, we know there's 93 security controls in there. And of course they can add others as well. But controls all have a different purpose. + +So we're just going to look at security controls by type and function. So let's start by type first of all. We could categorize security controls according to what they do and their purpose. + +![](CleanShot%202026-06-05%20at%2021.56.32.png) + +So we have some controls that you might call **technical controls**. So technical controls in information security is where we implement some kind of technology to restore respond to a problem. So if we implemented a multi-factor authentication system or a firewall or an intrusion detection system, for example, these would all be pieces of technology designed to achieve some kind of objective, a technical context. + +**Categorizing controls by what they do** + +But I think most people would accept, even with really good technical controls, that a lot of them are dependent on good processes that are followed by an organization. And this is where we talk about **administrative controls**. So administrative controls are where organizations bring in certain *processes to manage risk*. So you could have things around people like segregation of duties, job rotations, proper approval processes, your change management processes. These would all be example of administrative controls. But also having adequate procedures in place to manage technical controls. So for example, let's say we introduced a a security incident and event monitoring tool, which is a technical control, we'd probably have a bunch of administrative controls to go with it, such as stating how often the reviews of those logs have having a process that would be followed if we detected something suspicious. Those would be administrative processes. So often these will go hand in hand. And when we think about setting up an ISMS, we also have managerial controls. So **managerial controls are focused on people, and management of people** within the organization. So having things like management reviews, training and awareness programs, having proper internal audits to check that policy, etc. has been followed properly, disciplinary processes, etc. These would all fit under the the banner of managerial controls. + +And then we also have **legal controls** and there's two points of view on that. Legal controls are controls we would implement in order to fulfill our obligations under laws and regulations. And also where we use legal instruments to protect our information and information systems. So for example, if we asked people to sign a non-disclosure agreement, providing it's legally sound, that would be a legal control. Or let's imagine you have a supplier and you expect that supplier to meet certain security requirements and that's specified in contract, then that contract is essentially a legal instrument, it's a legal control that's helping to protect us. + +**Categorizing controls by their purpose** + +But as well as talking about the types of security controls, we also need to think about the function and the purpose of different security controls. Now in this course we present this as three different functions: **preventative**, **detective** and **corrective**. I'm aware that in some other security studies you might have even more categories, but for these we we keep it at three. And I just want to run through those three. The first one then, **preventative control**, is basically a control that we will implement to **avoid or prevent the occurrence of a risk** as best we possibly can. So for example, if I put strong access control in place on a system with multi-factor authentication, the objective there is hopefully to prevent unauthorized access. If I put a robust firewall at the perimeter of my network again, you would argue that's a preventative control. Or in the physical world, if we put a vehicle barrier in place or a a strong entry control, these would all be there for the purpose of preventing things. Also, anything that's there to deter people, what you might call a deterrent, I would put in the preventative book it as well. So if I put signage up outside the building saying we're monitoring you with CCTV or a login warning banner that says you're about to log into a confidential system, you've been monitored. Now some people might say, well that doesn't prevent anything. People can just ignore those things. Well of course they can, but they're still there to to to with an effort to deter the attack. Now all of this being said, there is plenty of studies to show that pretty much every preventative control that exists can, with enough time, enough motivation, potentially be compromised. Now I don't say that to frighten people or to imply that preventative controls aren't needed. Of course they are, absolutely they are. The point I'm trying to make is that we need to think very carefully, going back to my point earlier, about threat. How capable and how motivated are the threats that you face? Because the larger, the bigger capability and motivation they have, the more we're going to need to do on the preventative front. One of my colleagues puts it like this. He says you're never 100% stopping an attack. What you're trying to do is raise the bar so high that the effort required to compromise those preventative controls is so great that the attackers maybe go somewhere else. Essentially that's what you're trying to do. So all of that being said, yes, we need absolutely robust preventative controls in place, without a doubt. + +The effort you put into preventative controls should be related to the strength of the threat: it's capability and motivation. + +Knowing that any preventative can be compromised, given enough effort, energy and time, we need the ability to spot when that happens. And that moves us into detective controls. So **detective controls** allow us to see when preventative controls have been compromised. So things like monitoring and auditing, a security incident and event monitoring tool. our threat hunting activities, intrusion detection, file integrity monitoring, etc. These are all examples of detective controls. Now, personally speaking, as somebody in the security business, I'm very focused in this area because of various industry statistics and publications etc. And I wanted to draw your attention to a couple of those. So over the last couple of years the National Cybersecurity Centre in the UK, and totally separately the large infrastructure company HP, both did separate studies and they both implied that there was essentially a significant gap in general between organizations having a security compromise and spotting it. +So the NCSC has suggested approximately six months and HP is at seven. The point is, these studies are suggesting that organizations on average are taking six to seven months to notice that a security compromise has happened. +Now of course you might be watching this and saying, well that's not true for my organization, you know, we're much better organized. And if that's true, that's fantastic. But clearly in the industry at large there is a challenge here. So what's that telling us? It's telling us that some organizations at least have blind spots. So investing in detective controls for me is super important to having an effective ISMS. A chief information security officer was quoted as saying that it's not a case of if you've been compromised (you have), but have you detected it? So let's not overlook the importance of detective controls. When anybody tells me we've never had a security incident, I would say I'm quite skeptical and my question is well okay what detective controls do you have and how are you using them. + +Now equally if we are capable of detecting, we need the ability to respond. And that's what a **corrective control** is. So corrective control seeks to respond to identified problems. So things like disaster recovery plans, business continuity plans, incident management processes, root cause analysis processes, all of these would be good examples of corrective controls. And we'd expect to see again a good mix of those in an ISMS. Now one thing that's really interesting actually to talk about is this slide here, which gives you layers of control, and I think this helps to explain what ISO 27001 gives an organization and what it doesn't. + +![](CleanShot%202026-06-05%20at%2022.22.58.png) + +We can see essentially three layers in this diagram. At the top, controls that an organization would implement based on clauses 4 to 10. These controls are all quite managerial in nature: having proper risk management, having proper policies in place, conducting management reviews, looking at security from a strategic standpoint. And then of course we have annex A, which contains general controls, meaning that they are not going to tell me how to configure security settings in Microsoft Azure or in AWS or on a Cisco firewall. What it's going to give me is a general set of controls and principles that we need to think about as an organization. + +What's not in there but still needs to be thought about, is how you apply specific controls at the technical level. Now what's this got to do with auditing an ISMS? Let's imagine I come along as an ISMS auditor and you tell me that you have an access control policy and you require multi-factor authentication. As an auditor I need to get some assurance that that multi-factor authentication is implemented in an effective manner. That means I'm going to have to take a look at the technology that's being used in your state, whether it's Microsoft Azure, AWS, something like that. completely different and look under the hood. And I need to understand that your organization, who I'm auditing, has uh the necessary technical controls at those levels. +So what I'm saying is a good auditor isn't just familiar with the content of ISO 27001. You or somebody in your team will need to be familiar with the underlying technology. Otherwise it's going to be difficult to have a reasonable assurance that controls are implemented properly. So that's the part that requires you, I guess, outside of this course to get familiar with different technology environments and so forth. But just to sum all of this up, we've got a good slide here that might look a bit busy at first glance but is really trying to explain the relationship between all of these things. + +![](CleanShot%202026-06-05%20at%2022.31.35.png) + +So in the bottom right corner we've got assets. In the end, the whole purpose of an ISMS is to protect information assets. And what we're trying to explain here, is that risks can cause damage, can harm assets, and risks are caused by vulnerabilities and weaknesses that are being exploited by threats. + +Now, and of course we respond to this by implementing controls. Some controls will reduce vulnerabilities. Some can be implemented to reduce the amount of damage that can be done, reduce the impact, and or both. It is worth noting, as it shows you in this diagram here, that **controls themselves can have vulnerabilities**. You know, I always say if you can fix one problem, could you be creating another one? So let's say for example we decide to introduce an intrusion prevention system for network security. because we have a number of vulnerabilities. So great, we go and implement this intrusion prevention system which when it detects something suspicious starts dropping network traffic. Now if we get that properly tuned and implemented correctly, that's excellent. But what happens if it's not tuned very well and it starts dropping network traffic, causing a denial of service problem. So essentially we could create a new problem by fixing an old problem. That's what we call a secondary risk. So we're simply saying here, do think about that when you're responding to risk. Think very carefully about any new vulnerabilities that might be introduced. + +Now the last couple of concepts we wanted to introduce you to in this section were based on the fact that the title of the standard talks about setting up an information security management system, with a focus on **cybersecurity and privacy**. And sometimes the difference between information security, cybersecurity and privacy can cause a little bit of confusion. So we just want to make sure that we're all on the same page. +ISO's definition of cyber security is safeguarding of people, society, organizations and nations from **cyber risks, essentially meaning technical risks**. And if you look at ISO standards, they still talk about a concept from a long time ago called cyberspace. And cyberspace is basically the Internet. So any technologically connected system that processes information faces potential cyber risks. So cybersecurity is not a separate thing from information security. Cybersecurity is an element of information security, protecting the technology, the infrastructure, the applications that form part of it. Information privacy, on the other hand, is also mentioned in the standard. And from ISO's perspective, that's about protecting what they call PII, personally identifiable information. So personally identifiable information is anything that will reveal the identity of a living individual. So of course there's obvious things, your your name, address, telephone number. date of birth, etcetera as PII. But even more subtle things. So things like let's say the the IP address you're using when you're connecting to let's say an online service, if that could potentially reveal your identity. In some cases that potentially could be PII. What we're interested in when we look at privacy is a little bit different to security. So bear with me on this. So obviously security is relevant for privacy, but if we look at look beyond ISO and we look at a definition for say for example from GDPR, and it talks about privacy being essentially protecting the rights and freedoms of individuals. So there's a subtle difference. Of course, in order to ensure somebody's privacy to respect the rights and freedoms of an individual, we need to have adequate security. We need to protect that data. But privacy goes beyond that a little bit. And I always just try to use a very quick example of a project I worked on some time ago to distinguish between the two. So this project in brief was a road tolling project I was working on a project for a a UK project for a bridge essentially where they wanted to change the road tolling system. So previously people could drive to this bridge, uh pay in cash and drive across across it And the the organization behind that wanted to change to an automated system to stop queues basically. What they wanted was that people could drive across that bridge, have a picture taken of their number plate, automated number plate recognition, and then basically be asked to pay the bill online. So you could pay beforehand, you could pay afterwards If you crossed regularly you could even buy a transponder to put in your car and every time you crossed, there'd be an amount debited off that. So let's think about that. I was on that project as the security architect or one of the security architects. So of course my focus there is very much about the security of the network, the applications, you know, the whole sort of operation. And we had separately to that a privacy officer And the privacy officer did the privacy impact assessment. And the discussion in that, yes, there was definitely discussion about security of the system, security of the data, but they were then also looking at rights and freedoms and ethical issues. You know, now we're moving from a system where you could drive relatively anonymously across this bridge to one where there is a footprint, there is a record. And what could the impact be on an individual if uh those records were shared? You know, maybe certain people don't want. people to know that they were travelling on that road at that point in time during the day. So the questions start to become how long should we keep that data for? How much should we keep Who should we be sharing it with? What happens if somebody wants to access that data? You know, so a lot of procedural and ethical questions. And does that get included in ISO 27001? It does. There are some controls in there about that, which is why we bring it up. So all we're saying is if you're processing PII, you need to think beyond just pure security, we do need to build privacy thinking into our ISMS. If you want further guidance on that, you can extend your ISMS to cover privacy in further depth with an extension standard called ISO 27701. which basically takes everything we have in ISO 27001 and adds further controls from a privacy point of view. But even without ISO 27701 there are some privacy controls. within the standard. + +So in summary, what we've tried to make sure is here that we're speaking the same language when it comes to security in the world of an ISMS So we know that information is meaningful data. That is an asset to the organization. We are building a management system to protect those assets. We at least focus on the three pillars of confidentiality, integrity and availability. We can go beyond that. We focus when building an ISMS on risk by understanding the threats and vulnerabilities that are relevant to us and the consequences if those threats were to exploit vulnerabilities. We can implement controls in response to that, preventative, detective and corrective controls, with a mix of legal, administrative, technical and managerial controls, or blend of controls to manage risk. And we will take care of both cybersecurity and privacy as part of the overall ISMS. So hopefully this has given you a good flavour of all the things we need to think about. And as we move forward, we'll start to examine as auditors how do we really test whether these things are effectively implemented. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S05.1-Overview-of-ISO-27001-requirements.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S05.1-Overview-of-ISO-27001-requirements.md index 01c7e0e..4f47f86 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S05.1-Overview-of-ISO-27001-requirements.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S05.1-Overview-of-ISO-27001-requirements.md @@ -12,6 +12,7 @@ isotags: - C.5.2 - C.5.3 status: active +processed: true --- # S05.1 Overview of ISO 27001 requirements @@ -21,4 +22,54 @@ This session provides an auditor-focused overview of ISO 27001 clauses 4 and 5. ## Transcription -What we're going to do in this section is take a close look at the requirements of ISO 27001. So as an auditor of course we need to be familiar with all of the clauses of the standard and the annex to be able to add. Ask the right questions and conduct our audit. So basically, what we're going to do here is take you through clauses four to ten and also describe a little bit about annex A as well. Now before I start this, I think it's important to point out That we're not as we go through these teaching you to implement these or how to audit these things yet at this stage. We will be getting into how to audit and assess these things. What we're trying to do is just keep you a good broad overview of the requirements. So I like to call this section a bit of a helicopter tour of the standard. So by the time we've sort of finished this you'll have a good idea of some of the points within So let's start off with clause four, context of the organization. So this is broken down into four different subclauses, and essentially it's all about making sure the organization understands itself if you like in order to build an ISMS that's fit for purpose, that's tailored to the needs of the organisation. So when we use the word context, context basically means what is the organization about and from two perspectives, both what we call an internal context and an external context. So for example, an internal context is all about what's happening inside the organisation, such as how is it structured, who makes decisions, you know, what's the governance and oversight look like, what's the capability and maturity of the organisation. Whereas the external context is about what's happening in the outside world. You know, what's the legal and regulatory landscape look like? What part of the world are you operating in? What's the economic landscape look like? What's the demands of your customs, etc. So what we're saying is when we build an ISMS, an organization shouldn't just be building an ISMS out of the blue, but essentially should be taking all of these considerations. into account. And clause 4. 2 sort of expands on that because what it says is that we should understand the needs and expectations of interested parties. So in an ISMS, interested parties can be both internal and external. So external interested parties parties, maybe things like customers, regulators, business partners, suppliers as examples. Internal can be people like senior management. your user base, different teams and departments. And the idea is when an organization builds an ISMS, it should be examining what the needs and requirements of all these different parties are again so it can build an ISMS to respond. So maybe a quick example of that I can give. I remember at one point I worked for a training company that provided services to a government department And there was a requirement, so they were our customer in the contract which said if we discover any compromise of data relating to them, we must report it within four hours of detection 24-7. So that tells us that we need an incident response capability. That's 24-7 that has that response time built into it. ISO doesn't tell us that. but the expectation of our customer does. So we'd need to build the ISMS with that expectation in mind. And we'd also as an organization build an ISMS based on a scope. So One of the things to say is that when an organization puts an ISMS together, they don't necessarily implement it in the entire organization. They can choose which part of the organization it applies to or which business processes are in scope or which particular systems are in scope. And when an organization determines the scope, it should be credible based on the work done in clause 4. 1 and 4. 1 So as an auditor when I'm coming along and talking to an organization and I'm asking them about the scope, it's not so much that I'm there to tell them whether the scope is right or wrong. It's more about have they done the groundwork? Can they logically explain why the scope that they have makes sense? And then we have clause 4. 4 which talks about operating the information security management system. Now in reality, although this is a standalone or it's a subclause, that can only be fulfilled if the ISMS is actually fully established so that all the other clauses and relevant controls are implemented. So as we'll speak about a little bit later, as an auditor, we'll answer the question as to whether 4. 4 is fulfilled after we've looked at some of the other areas. So just elaborating a little bit on the understanding the organization in its context part, so let's think about a typical organisation. An organization, all organisations, whether they're a government agency, a non-profit or a profit-making business, all in the end have a mission, they have a purpose. So a Razondetterie, you might say a reason for existing. And maybe an organization has a mission statement or something like that that we can look at to understand. understand them. All organizations have objectives, things that they're looking to achieve. So if it's a say a a profit-making enterprise they might have objectives over the next X number of uh years for example to expand by a certain amount to launch new products in a new market whatever it might be If it's a non-profit like a government agency, they might have objectives in improving efficiency or improving quality of service or whatever it might be. But the point is organizations should have objectives and most organizations will have strategies. That describes how they are going to reach those objectives over a period of time. So, why is this relevant to a discussion on ISO 2701? Well, let's imagine an organization is implementing ISO 277. 27001, it needs to formulate its information security policy and its objectives. So the last thing it wants to do is create a set of objectives that are contrary to the mission or objectives of the organization. And let me try and give sort of a really good example, I think, of where an organization did this really well. So it was an organization I worked with some time ago. They were an IT service provider. And they'd called us in actually to help them implement an ISMS because they had a contractual duty. There's a contract that they'd won which said you need to have an ISMS and you need to be certified by a certain date. Now as the implementer in this case, not the auditor, as the implementer in this case, we could have easily gone in and just kind of done what we needed to do to get them compliant with that contract, get them certified and leave it there. But early on I had a conversation with some of the directors. I had a good relationship with the finance director at the time and I started asking him about the longer-term objectives of the organization And in that conversation, he kind of revealed that their aim was to start d expanding into the defence sector. They wanted to start selling various services into Ministry of Defence and other defence organizations around the world. And the conversation I had with him based at a very high level went along the lines of, well, in order to be able to achieve that, you're going to need to have a certain security capability. a certain level of maturity to be able to get into that kind of supply chain. Long story short, that led to the formulation of a security strategy which didn't just focus on getting ISO 27001 certified but it focused on building the organization's security capabilities so they were in a position to win business in the defense sector. So what I'm trying to say is we produced a security strategy that was aligned with the strategy of the organization. This is the kind of thing that clause 4. 1 is talking about. We're not building an ISMS just to tick some boxes off for the sake of it. We're trying to build an ISMS so the organisation should be to achieve its longer term objectives. So as an auditor, if I'm wearing my auditor hat, that's what I want to understand when I'm talking to the organisation. What is this delivering for you? When we talk about understanding the needs and expectations of interested parties, as I said a few moments ago, there are many interested parties. that might be affected by an ISMS. There are those who might be directly affected, you know, for example internally, if we start implementing security controls in order to fulfill requirements You know, those that will see that first hand, like users and employees, etc. And then may maybe those who are less affected but are nonetheless interested. You know, somebody like a regulator, for example, might not be seeing your ISMS on a day-to-day basis, but might be So it is a important thing that the organization takes its time to map out its interested parties and to map out what the requirements are. Now in some cases requirements might be explicit. So like the example I gave a little bit earlier on about that training company, it was clearly stated in the contract that we shall report these incidents within four hours of detection. Section. That was non-negotiable. That's a requirement. There may be cases where interested parties don't have a written explicit requirement But a an implied requirement exists nonetheless. So for example, if your organization is selling goods or services to the general public, you might not have a written contract specifying all the security controls you need to have in place. But you'd still say there's an expectation, you know, the members of the public would still have a certain expectation about how you process and store their data, as well as obviously the legal and regulatory aspect. The other thing that's important when an organisation does this is have they identified their legal, regulatory and contractual obligations. So as an auditor very early on in the audit this is a question I ask and I like to see has the organisation spot spotted that And if you're thinking about organizations that operate globally, then of course that might be even more complex. But what I want to find out is have they took these points into account. It wouldn't be a particularly useful ISMS if they've overlooked key legal obligations in the end. An organization needs to determine the scope of its ISMS, and the standard says the following: the organisation shall determine the boundaries and applicability of the ISMS to establish its scope. But as we can see, it's not just establishing any scope from anywhere. We should take into account A the internal and external issues we've just been talking about. The requirements referred to in 4. 2, that is to say the requirements of your interested parties, and this is an interesting one as well. Interfaces and dependencies between activities performed by the organisation. and those performed by other organizations. So let's take an example. Let's say we've got an organization, pretty much every organization I could give this for now, and it uses cloud services. So let's say you use a SaaS platform, software as a service platform provided by a cloud service provider. So I think we could all agree that a lot of the technical delivery of that service would be the responsibility of the cloud service provider. And the organization isn't necessarily going to put the cloud service provider and all its activity inside the scope of their ISMS But the management and oversight of that cloud service provider and the processes for that would be in scope. So we've got to look at what I I actually call it the reliance scope to some degree. degree. In other words, who or what are you reliant on? And if we drew dru do draw a boundary around that, how do you have some assurance and oversight? So this is an important point. And it says that the scope shall be available as documented information. So as I've said a little bit earlier on, as an auditor, I want to see the scope document and I really want to understand how the organisation arrived at the scope and And as I've said before, it's not about whether I agree or like the scope or don't like the scope, it's more does it make logical sense in terms of how they've got there. And 4. 4 is that the organization should establish and maintain and continually improve their ISMS. Well, in the end The fact of the matter is in an audit that's what we're trying to work out at the end of the audit, I want to really be able to say, is this clause fulfilled? Have I seen enough evidence of other stuff going on to say whether or not they have an effect? So let's move on to clause five then. Clause five is entitled Leadership and it has three controls, leadership and commitment, policy organization roles, responsibilities and accountabilities. So clause five, when we use the term leadership This is all about making sure that there is support and commitment from what ISO calls top management to run and operate an ISMS in the long term. So when we see this term top management This basically means that senior leadership within an organization should be overseeing and supporting the implementation of an ISMS. Now who top management are might vary depending on the type of organization we're talking about. So often when I ask this in a classroom, I'll say, well, what do you think top management is? A lot of people say things like directors, C level, you know, executives, etc. etc. And by and large that would be absolutely true. Now, obviously it's context driven to some degree. So I remember working with a uh a large global IT service provider helping them implement an ISMS But the ISMS scope was limited to some services specifically in the UK in this case. So I wouldn't expect the global chief executive necessary. necessarily to be involved in this case, but certainly the UK directors who were accountable for that business unit in that case were our top management. In a small business Very small business, it could even be the owner of the organization. So it will kind of vary uh vary depending on the organization. But what does the standard expect? Well, without going through each and every requirement A to H, because you're so you can read through those um in detail but I'll give you sort of a summary. What the standard is expecting is that those people in those leadership permissions support the ISMS in a number of ways. And some of them that are important are making sure the security objectives that we decide Define and the scope and so forth is aligned with the objectives of the organization, a bit like we were talking about earlier in clause four They should be ensuring that we have the necessary resources to run and operate that ISMS, not just to implement it. but to run it and operate it in the long term. Those resources might be financial, technological, it might be people. Now I'm not arguing here that management must have an open checkbook. and no budget, but what I'm saying is provide adequate justified resources to run the management system. Another key role that top management plays making sure that people in the organization are aware that this is actually a top management concern. So getting involved in communication, sharing. uh information with the wider organization. So people can see in reality that this isn't coming from an IT department or isn't a technical thing, but it's a concern of top management. And the more likely people see that, the more likely we're going to get back. in and also top management should be proactively reviewing the management system, ensuring that we are driving in continual improvement. This is why separately in clause 9. 3 we have this concept of management review. which we'll come to a little bit later. Now one way that top management can demonstrate their commitment is of course by establishing an information security policy So according to ISO, a policy is the formal intent and direction as expressed by an organization's top management. So, clause 5. 2 says we shall have an information security policy that does a number of things that's appropriate to the purpose of the organization. That includes the security objectives or if not includes them provides reference essentially. to those objectives. Includes a commitment to continual improvement and a commitment of satisfying applicable requirements. That could be legal, regulatory, contractual. requirements. Now usually what I would say here is an information security policy would be a fairly short document, maybe one or two pages that everybody in the organisation can see. It's setting the tone and direction. It's saying, okay, we top management take security seriously, therefore we're going to commit to the following things. For example, we're going to commit to implementing appropriate training. We're going to commit to ensuring risks are properly assessed and treated. We're going to ensure that we're going to monitor our ISMS, etc. There might be other policies produced later that are topic-specific, you know, topic tech technical topics like cryptography or network security or application security but we'll talk about them in annex A because there's a particular control in the there for that. For now, this is about top management showing that there is commitment and setting the tone and direction in policy. And of course we can't have an effective ISMS or argue that there's top management commitment unless people are appointed to actually run and operate the ISMS. And that's what clause 5. 3 is all about. establishing organizational roles, responsibilities and authorities. So who does what when it comes to running the ISMS? And who's authorized to do what? So, you know, who's doing the risk assessments? Who is it who's going to create policy? Who's responsible for handling incidents or conducting internal audits? We'd want to answer all of those questions And it clearly says in the standard, top management shall assign the responsibility in authority for ensuring the ISMS conforms to the requirements of this document. to the standard and reporting on performance to top management. So top management can't just allocate roles and then just forget about it. and there needs to be a link between whoever's performing those roles, for example an information security manager or CISO and top management. Note that the standard does not give us a list of job titles or qualifications or anything like that. Every organization will be different, but it should be very clear who is doing what. Those people should be aware of their roles and be formally authorised to do that. Based on the um authority of top management. \ No newline at end of file +What we're going to do in this section is take a close look at the requirements of ISO 27001. So as an auditor of course we need to be familiar with all of the clauses of the standard and the annex to be able to add. Ask the right questions and conduct our audit. So basically, what we're going to do here is take you through clauses 4 to 10 and also describe a little bit about annex A as well. Now before I start this, I think it's important to point out That we're not as we go through these teaching you to implement these or how to audit these things yet at this stage. We will be getting into how to audit and assess these things. What we're trying to do is just keep you a good broad overview of the requirements. So I like to call this section a bit of a helicopter tour of the standard. So by the time we've sort of finished this you'll have a good idea of some of the points within. + +So let's start off with **clause 4, Context of the organization**. This is broken down into four different subclauses: + +- 4.1: Understanding the organization and its context +- 4.2: Understanding the needs and expectations of interested parties +- 4.3: Determining the scope of the information security management system +- 4.4: Information security management system + +Essentially it's all about making sure the organization understands itself, in order to build an ISMS that's fit for purpose, that's tailored to the needs of the organization. When we use the word context, we mean what the organization is about from two perspectives: internal and external context. An **internal context** is all about what's happening inside the organization, such as how is it structured, who makes decisions, what's the governance and oversight look like, what's the capability and maturity of the organization. + +The **external context** is about what's happening in the outside world. What does the legal and regulatory landscape look like? What part of the world are you operating in? What's the economic landscape look like? What's the demands of your customs, etc. So what we're saying is when we build an ISMS, an organization shouldn't just be building an ISMS out of the blue, but essentially should be taking all of these considerations. into account. + +And **clause 4. 2** sort of expands on that because what it says is that we should understand the **needs and expectations of interested parties**. So in an ISMS, interested parties can be both internal and external. So external interested parties parties, maybe things like customers, regulators, business partners, suppliers as examples. Internal can be people like senior management. your user base, different teams and departments. And the idea is when an organization builds an ISMS, it should be examining what the needs and requirements of all these different parties are again so it can build an ISMS to respond. So maybe a quick example of that I can give. I remember at one point I worked for a training company that provided services to a government department And there was a requirement, so they were our customer in the contract which said if we discover any compromise of data relating to them, we must report it within four hours of detection 24-7. So that tells us that we need an incident response capability. That's 24-7 that has that response time built into it. ISO doesn't tell us that, but the expectation of our customer does. So we'd need to build the ISMS with that expectation in mind. + +And we'd also as an organization build an ISMS based on a **scope** (4.3). So one of the things to say is that when an organization puts an ISMS together, they don't necessarily implement it in the entire organization. They can choose which part of the organization it applies to or which business processes are in scope or which particular systems are in scope. And when an organization determines the scope, it should be credible based on the work done in clause 4. 1 and 4.2. So as an auditor when I'm coming along and talking to an organization and I'm asking them about the scope, it's not so much that I'm there to tell them whether the scope is right or wrong. It's more about have they done the groundwork? Can they logically explain why the scope that they have makes sense based on 4. 1 and 4.2 (resp. context and interested parties)? + +So just elaborating a little bit on the understanding the organization in its **context** part (clause 4.1), so let's think about a typical organization. An organization, all organizations, whether they're a government agency, a non-profit or a profit-making business, all in the end have a mission, they have a purpose. So a raison d'être, you might say: a reason for existing. And maybe an organization has a mission statement or something like that that we can look at to understand them. All organizations have objectives, things that they're looking to achieve. So if it's a profit-making enterprise they might have objectives over the next X number of years to expand by a certain amount, to launch new products in a new market, whatever it might be. If it's a non-profit like a government agency, they might have objectives in improving efficiency or improving quality of service or whatever it might be. + +![](CleanShot%202026-06-06%20at%2012.43.00.png) + +But the point is: organizations should have objectives and most organizations will have strategies, that describe how they are going to reach those objectives over a period of time. So, why is this relevant to a discussion on ISO 27001? Well, let's imagine an organization is implementing ISO 27001, it needs to formulate its information security policy and its objectives. So the last thing it wants to do is create a set of objectives that are contrary to the mission or objectives of the organization. And let me try and give an example of where an organization did this really well. So it was an organization I worked with some time ago, they were an IT service provider. And they'd called us in actually to help them implement an ISMS because they had a contractual duty. There's a contract that they'd won which said you need to have an ISMS and you need to be certified by a certain date. + +Now as the implementer in this case, we could have easily gone in and just kind of done what we needed to do to get them compliant with that contract, get them certified and leave it there. But early on I had a conversation with some of the directors. I had a good relationship with the finance director at the time and I started asking him about the longer-term objectives of the organization. And in that conversation, he kind of revealed that their aim was to start expanding into the defense sector. They wanted to start selling various services into Ministry of Defense and other defense organizations around the world. And the conversation I had with him based at a very high level went along the lines of, well, in order to be able to achieve that, you're going to need to have a certain security capability, a certain level of maturity to be able to get into that kind of supply chain. Long story short, that led to the formulation of a security strategy which didn't just focus on getting ISO 27001 certified, but it focused on building the organization's security capabilities so they were in a position to win business in the defense sector. + +So what I'm trying to say is we produced a security strategy that was aligned with the strategy of the organization. This is the kind of thing that clause 4. 1 is talking about. We're not building an ISMS just to tick some boxes off for the sake of it. We're trying to build an ISMS so the organization should be to achieve its longer term objectives. So as an auditor, if I'm wearing my auditor hat, that's what I want to understand when I'm talking to the organization. What is this delivering for you? + +When we talk about understanding the **needs and expectations of interested parties** (4.2), as I said a few moments ago, there are many interested parties that might be affected by an ISMS. There are those who might be directly affected, you know, for example internally, if we start implementing security controls in order to fulfill requirements, you know, those that will see that first hand, like users and employees, etc. And then may maybe those who are less affected but are nonetheless interested. You know, somebody like a regulator, for example, might not be seeing your ISMS on a day-to-day basis, but might be briefed or to be aware that this is being implemented. So it is a important thing that the organization takes its time to map out its interested parties and to map out what the requirements are. + +Now in some cases requirements might be explicit. So like the example I gave a little bit earlier on about that training company, it was clearly stated in the contract that we shall report these incidents within four hours of detection. Section. That was non-negotiable. That's a requirement. There may be cases where interested parties don't have a written explicit requirement, but a an implied requirement exists nonetheless. So for example, if your organization is selling goods or services to the general public, you might not have a written contract specifying all the security controls you need to have in place. But you'd still say there's an expectation, you know, the members of the public would still have a certain expectation about how you process and store their data, as well as obviously the legal and regulatory aspect. + +The other thing that's important when an organisation does this, is have they identified their **legal, regulatory and contractual obligations**. So as an auditor very early on in the audit I like to seethe organization has spotted that. And if you're thinking about organizations that operate globally, then of course that might be even more complex. But what I want to find out is have they took these points into account. It wouldn't be a particularly useful ISMS if they've overlooked key legal obligations in the end. + +An organization needs to determine the **scope** of its ISMS, and the standard says the following: "the organisation shall determine the boundaries and applicability of the ISMS to establish its scope". But as we can see, it's not just establishing any scope from anywhere. We should take into account a) the internal and external issues we've just been talking about. The requirements referred to in 4.2, that is to say the requirements of your interested parties, and this is an interesting one as well. Interfaces and dependencies between activities performed by the organization, and those performed by other organizations. So let's take an example. Let's say we've got an organization, pretty much every organization I could give this for now, and it uses cloud services. So let's say you use a SaaS platform, software as a service platform provided by a cloud service provider. So I think we could all agree that a lot of the technical delivery of that service would be the responsibility of the cloud service provider. And the organization isn't necessarily going to put the cloud service provider and all its activity inside the scope of their ISMS, but the management and oversight of that cloud service provider and the processes for that would be in scope. So we've got to look at what I actually call the **reliance scope** to some degree. In other words, who or what are you reliant on? And if we draw a boundary around that, how do you have some assurance and oversight? So this is an important point. And it says that the scope shall be available as documented information. + +So as I've said a little bit earlier on, as an auditor, I want to see the scope document and I really want to understand how the organization arrived at the scope, and as I've said before, it's not about whether I agree or like the scope or don't like the scope, it's more does it make logical sense in terms of how they've got there. + +And then we have clause 4.4, which talks about operating the **information security management system**. It says that the organization should establish and maintain and continually improve their ISMS. Now in reality, this subclause can only be fulfilled if the ISMS is actually fully established, when all the other clauses and relevant controls are implemented. That's what we're trying to work out at the end of the audit. I want to really be able to say, is this clause fulfilled? Have I seen enough evidence of other stuff going on to say whether or not they have an effect? + +So let's move on to clause 5 then. Clause 5 is entitled **Leadership** and it has three controls: leadership and commitment, policy, and organization roles, responsibilities and accountabilities. So clause 5, when we use the term leadership, this is all about making sure that there is support and commitment from what ISO calls 'top management' to run and operate an ISMS in the long term. So when we see this term top management, this basically means that senior leadership within an organization should be overseeing and supporting the implementation of an ISMS. Now who top management are might vary depending on the type of organization we're talking about. So often when I ask this in a classroom, I'll say, well, what do you think top management is? A lot of people say things like directors, C level, you know, executives, etc. etc. And by and large that would be absolutely true. Now, obviously it's context driven to some degree. So I remember working with a large global IT service provider helping them implement an ISMS. But the ISMS scope was limited to some services specifically in the UK in this case. So I wouldn't expect the global chief executive necessarily to be involved in this case, but certainly the UK directors who were accountable for that business unit, in that case they were our top management. In a small business it could even be the owner of the organization. So it will kind of vary depending on the organization. + +But what does the standard expect? Well, without going through each and every requirement A to H, because you can read through those in detail, but I'll give you sort of a summary. What the standard is expecting is that those people in those leadership permissions, support the ISMS in a number of ways. And some of them that are important are: making sure the security objectives that we define, and the scope and so forth, is aligned with the objectives of the organization, a bit like we were talking about earlier in clause 4. +They should be ensuring that we have the **necessary resources** to run and operate that ISMS, not just to implement it, but to run it and operate it in the long term. Those resources might be financial, technological, it might be people. Now I'm not arguing here that management must have an open checkbook, and no budget, but what I'm saying is provide *adequate justified resources* to run the management system. + +Another key role that top management plays making sure that people in the organization are aware that this is actually a top management concern. So getting involved in **communication**, and sharing information with the wider organization, so people can see in reality that this isn't coming from an IT department or isn't a technical thing, but it's a concern of top management. And the more likely people see that, the more likely we're going to get buy-in. +And also top management should be proactively **reviewing** the management system, ensuring that we are driving in continual improvement. This is why separately in clause 9.3 we have this concept of management review, which we'll come to a little bit later. + +Now one way that top management can demonstrate their commitment is of course by establishing an **information security policy**. So according to ISO, a policy is the formal intent and direction as expressed by an organization's top management. So, clause 5.2 says we shall have an information security policy that does a number of things that's appropriate to the purpose of the organization. That includes the security objectives, or if not includes them, provides reference to those objectives. It includes a commitment to continual improvement and a commitment of satisfying applicable requirements. That could be legal, regulatory, or contractual requirements. Now usually what I would say here is an information security policy would be a fairly short document, maybe one or two pages that everybody in the organization can see. It's setting the tone and direction. It's saying, okay, we top management take security seriously, therefore we're going to commit to the following things. For example, we're going to commit to implementing appropriate training. We're going to commit to ensuring risks are properly assessed and treated. We're going to ensure that we're going to monitor our ISMS, etc. +There might be other policies produced later that are topic-specific, you know, topic tech technical topics like cryptography or network security or application security but we'll talk about them in annex A because there's a particular control in there for that. For now, this is about top management showing that there is commitment and setting the tone and direction in policy. + +And of course we can't have an effective ISMS or argue that there's top management commitment unless people are appointed to actually run and operate the ISMS. And that's what clause 5. 3 is all about: establishing **organizational roles, responsibilities and authorities**. So who does what when it comes to running the ISMS? And who's authorized to do what? So, you know, who's doing the risk assessments? Who is it who's going to create policy? Who's responsible for handling incidents or conducting internal audits? We'd want to answer all of those questions. And it clearly says in the standard, top management shall assign the responsibility in authority for ensuring the ISMS conforms to the requirements of this document (the standard) and reporting on performance to top management. So top management can't just allocate roles and then just forget about it. And there needs to be a link between whoever's performing those roles, for example an information security manager or CISO, and top management. Note that the standard does not give us a list of job titles or qualifications or anything like that. Every organization will be different, but it should be very clear who is doing what. Those people should be aware of their roles and be formally authorized to do that, based on the authority of top management. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S05.2-Overview-of-ISO-27001-requirements.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S05.2-Overview-of-ISO-27001-requirements.md index def8057..07c8979 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S05.2-Overview-of-ISO-27001-requirements.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S05.2-Overview-of-ISO-27001-requirements.md @@ -9,6 +9,7 @@ isotags: - C.6.1.1 - C.6.1.2 status: active +processed: true --- # S05.2 Overview of ISO 27001 requirements @@ -18,4 +19,65 @@ This session covers ISO 27001 clause 6, focusing on planning. It distinguishes b ## Transcription -Let's have a look at the next clause in the standard, clause six planning. Now this is broken down into three particular parts, the actions to address risks and opportunities, information security objectives and planning to achieve them planning of changes. So let's start on this first one, actions to address risks and opportunities. We see this in clause 6. 1. 1 and something I want to really draw your attention to here because often there's a little bit of confusion about this. 6. 1. 1 isn't specifically about information security risk We'll come to that shortly. It's about something slightly different. So let's just have a look at the words and then I'll try and explain my point here. So what we see is the following that when planning for the ISMS that the organisation shall consider the issues referred to in 4. 1 and the requirements referred to in 4. 2. So remember that's context of the organisation, the needs and expectations of interest. parties and then it says and determine the risks and opportunities that need to be addressed to ensure the ISMS can achieve its intended outcomes prevent or reduce undesired effects and achieve continual improvement. So what's this speaking about? This isn't necessarily speaking about identifying information security risks to particular systems or particular information. This is about risks to the ISMS itself. So let me try and explain this. So let's think about a project. Any project for that matter. You imagine a project manager would usually do a risk assessment. When they're doing a risk assessment, they're not focusing on security or any other matter. What they're focusing on is what's the risk of the project failing You know, could the project overrun? Could it uh go over budget? Could it completely fail to deliver? Well this is a similar story here. What we're looking at is when we're thinking about establishing an ISMS, are there any situations, risks, etc. that could affect the ability of the ISMS to work as expected. ? So for example, if we identified that we had a resource shortage, that would be a risk to the ISMS itself. There might be a chance that the ISMS cannot fulfil its objectives. If we didn't have appropriate support from management, we'd have a risk to the ISMS. On the flip side, an opportunity is indeed the chance to potentially improve something or or uh gain some benefit. So the opportunity of establishing an ISMS could be it could open the doors to more commercial opportunities for example Or one of the opportunities in an ISMS could be that we're going to conduct detailed risk analysis and we'll identify opportunities to drive efficiency in certain processes or remove duplication, etc. So 6. 1. 1 wants us to focus on those particular risks and opportunities. Now that doesn't mean that we're going to ignore information security risk. quite the opposite. That's why there's a separate clause on that, clause 612. And clause 612, and I won't read it all out line by line, again I'll just give you the sort of summary. The organization shall define and apply an information security risk assessment process that does a number of things. The first one establishes and maintains information security risk criteria. Information security risk criteria, think of criteria as rules, are the rules we're going to use to understand our risk. So for example, we might lay out things like risk acceptance criteria. That is to say when a risk is identified, how do we decide? whether or not that's acceptable to the organisation. Now we might have an answer to that because the organisation may already have some general rules or criteria. And the criteria for performing those risk assessments, so when do we need to perform an information security risk assessment Is it at the start of a new project, during a project? Do we trigger an at risk assessment again if we have some kind of incident? Do we do them every so often? These are the questions that will answer in a documented risk assessment process. We then talk about the fact that it should ensure repeatable results. I'll get into that a little bit later in this section where we talk about having a proper risk assessment. assessment method and then we will do a number of things including identifying information security risks and something I want to draw your attention to right now which I think is important right at the start identifying risk owners so risk owners are individuals in the organization who have a let's say a level of authority, a level of trust to make risk decisions. It's very important that we know who those risk owners are early on. Because when we start to identify risks, we're going to have to consult with those owners to make decisions on what we're going to do with risks. If we don't have risk owners, then the process could come grinding to a halt. So this is an important uh point that the standard. that is calling out. And in a risk assessment, as we'll see in just a moment, we have three stages in a risk assessment, the risk identification, analysis and evaluation. So we expect to see according to clause 612 a very clearly defined, understandable risk assessment process. So as an auditor, when I'm coming in to look at this, I'll be looking at is the process defined, and then I'll be looking at evidence by getting somebody to maybe take me through risk assessments. that have been performed. But let's talk about some important factors then about a risk assessment approach. So there are three sort of things to cover off here which you can see in mentioned in the slide. here that we need to identify a methodology. So let me explain this very clearly. So clause 612 tells us what should be considered when doing risk assessment It does not tell us how to conduct a risk assessment. It doesn't say you shall calculate your risks on a scale of 1 to 10 or high, medium, and low, or using some other kind of formula. Nor does the guidance document, I suppose. 2705. What does that is what we call a methodology and I'll talk in a moment a little bit more about methodologies, but we need to have an agreed way of conducting those risk assessments As well as having an agreed way to conduct those assessments, we must have predefined risk acceptance criteria. So let me give you an example. I was working with an organization. I spent that they didn't have such a process in place. We were trying to get this set up. I spent some time with the finance director. And we started to come up with some ways we could calculate risk. So we had what's called an impact table. So we had five levels of impact. So when we're calculating the damage that could be done, we could place it on a scale. And I sat with the finance director and I remember him pointing out a particular number on this scale and he basically said to me If as part of these risk assessments we identify any risk that could result in the loss of this amount of money, and he mentioned a specific figure, or more And the likelihood of that happening is medium or above, that cannot be accepted by the Information Security Committee. This needs to come to the board for review So in this case he's given me, involuntarily you might say, some criteria, in this case risk escalation criteria. And these are the kind of conversations that an organization should be having to define this. And an organization should be identifying the overall level of acceptable risk. When it comes to information security. Now ultimately that is set by top management. And the level of acceptable risk will vary, of course, depending on organisation. And sometimes when we talk about risk, we talk about this concept of risk appetite. And risk appetite is the amount of risk that senior management or directors or or company owners are willing to take in certain circumstances. That might influence the answer here. So for example, I've worked in organizations that have very different risk appetites. So I've worked in um Your government entities that might have a low risk appetite because they are looking for stability. They don't want to take unnecessary risk Whereas if you go into say a venture capitalist organization that's looking for rapid growth, they might have a much higher risk appetite because indeed that's That's what they're doing. They want to innovate and take risks, but not reckless risks, but risks to grow. And again, as an auditor It's not for me to say what is right or wrong here or to enforce my preferences on the organisation but I do want to understand have they defined these things and why and does it have the appropriate support from top management. Now there is a note here which says the following. The organisation must ensure that the risk assessment generates comparable and reproducible results. So how does an organization ensure comparable and reproducible results and what does that actually mean? Well what it basically means is let's say that there's two of us doing risk assessments for an organization and I come along and do some and you know you come along and do another one that we both approach the problem in the same way and that means basically we should have a defined methodology And there are a few things an organization should think about when they're choosing a risk assessment methodology. Now the first thing I would say here is there are many methodologies available for assessing information security risk. Some of them very simple, some of them very, very detail-oriented and extremely complicated. It's also possible to design your own methodology. So ISO doesn't dictate what methodology to use. So how can an organisation settle on one that makes sense? Well there are a few things that the organisation should think about. The first, compatibility with the requirements of 27001, that's relatively easy because basically as long as the methodology considers threat and vulnerability impact and likelihood and the three tenants of security pretty much that that that part's answered straight away so as long as your method does those three things that's point number one So what else might an organisation want to take into account when thinking about this? Well other things that are important, vocabulary of the method, in other words, the way it's written Does the language make sense? I don't mean language as is as in is it in English or French or German? What I mean is um does the terminology make sense? So if it refers to the concept of threat, for example Do we understand the work that word in the same way? So when we get output from these assessments, will it be understandable Now I'm not going to go 1, 2, 3, 4, 5, 6, 7 here, because actually for me the next one, which I want to talk about, number 5 on here, ease and use and pragmatism of the method. Let me explain what I'm saying here So there are some methods that are extremely rigorous and extremely complex and are really good for deep dive risk assessment. So I can think, for example, spending time in government departments, there are some methods we would use and one risk assessment of one information system could take 50 days or more because we're really looking under the hood at a lot of technical detail, but in that circumstance that's justified because of the type of systems and information we're trying to protect But that wouldn't necessarily be very useful if I took that method and tried to apply that in a small sort of startup company or commercial business It it it would be rigorous, yes, but it probably wouldn't be practical. So this is not me, I'm not trying to argue that we don't need to be rigorous. What I'm trying to say is we set up a method that is suitable for the organisation at that time. An example I can give, I worked with a very small organisation not too long ago. They had nothing in place for this at the time. They weren't overly familiar with this idea, so they didn't it's not like they had a team of risk professionals in the organization. So we started with something simple. We actually built an Excel spreadsheet with some very simple to use steps. Now is that the end game? Is that where I want them to be long term? Of course it isn't. We can get more sophisticated and we will over time as the organization matures. So let's make sure we pick something that's fit for purpose. Now if we are using a relatively complicated method, then there might be good questions in points three and four. Is there any software that the organisation can use to aid their risk assessments. The only caveat I would give to that point is that software tools are only as good as the person operating them So you can have the best security tools available, but the person using it still needs to be familiar with the method to be able to explain the output. And that also speaks to point four. If we're going to select a method, are we selecting one that's well used, that other organizations use? that's properly documented where we can get training or professional support if we need it rather than something that's a little bit more obscure for example. And we can also think, last couple of points, about cost to utilisation. That's very similar with ease and pragmatism. You know, how much time does it take to conduct this risk assessment? Do you need to bring in a specialist to do it, etc. We want to get that balance right. So all of these things can help. And whilst I don't promote any particular risk assessment method, just to maybe point you in a direction a little bit, there are methods out there you can think about So some that I've seen in this space are things like Octave, for example, from Carnegie Mellon University. There is actually Octave S and Allegro that's targeted at smaller organizations, things like um IRAM from the Information Security Forum is a really good example of a risk assessment methodology, platforms like VS Risk or a Rambuffer, etc. None of these are me promoting anything in particular, but just some examples that might help you to start looking and thinking about risk assessment methodologies. But there are plenty out there if you do that research But all risk assessment methodologies, regardless of how complex or not they are, go through a series of stages and they should follow the stages that are laid out in ISO 20 the guidance document that is there to support conformity with these particular clauses. So the first risk identification So risk identification is the step of identifying risk scenarios. This is not about likelihood and impact, this is about simply identifying potential scenarios, working with risk owners and other experts in the organization to see what risks might be relevant And there are typically two ways we can set about identifying risk in an organization. Now, firstly I would say this is never done by one individual on their own. Often it's a collection of people. From a given part of the organization. So you might have a facilitator, a risk expert, but then other experts who can contribute. And we can do either an event-based or asset-based approach or both. But let's say an event-based risk assessment. or risk identification I should say is where we talk about specific events in general. So let's say for example ransomware we could have a general discussion about the risk related to ransomware in our organization and think about that event and think about how that event might play out. That's quite a generalized thing. But an asset-based approach is where we take the asset, we look at the asset and we look at potential vulnerabilities and threats. So let's say one of the assets is a CRM system So in an asset-based risk assessment, we'd take that CRM system, we would look at the design, the build, all the details we can, and then we'd say, okay, does this system have any vulnerabilities? What do they look like? How could they be exploited? And from that, we would identify a set of risks that would be quite specific to that asset. So an event-based approach gives you a good organizational overview, but then the asset-based very specific. So let's take the ransomware example. Let's say we look at ransomware in general Hitting the organization. And then when we do our asset-based assessment, we can say, okay, how would that ransomware scenario play out for this system system because it might play out differently in one environment to how it does in another. So for me, if you want to be really rigorous, I would say both approaches probably need to be done hand in hand. Now again I caveat that with that depends on the um importance of the assets, the level of rigor you need to go to. ISO 27001 does not demand this, but I think if you want to do risk assessment, or risk identification rather well, a combination of the two approaches would be really helpful. Now one of the things that sometimes I found comes up in risk identification workshops, for example are people saying things like, uh well that scenario is uh never going to happen, so we shouldn't really talk about it, and things like this. And I always argue in risk identification Let's not have that argument now, let's have that argument in the next phase. And that next phase is risk analysis and evaluation. So risk analysis is where we can have that debate, because what do we do in risk analysis? That's where we look at the potential consequences if this scenario played out and the likelihood And there are multiple ways of doing this. Likelihood can be arrived at by looking at events and how frequently they might occur. It can be worked out potentially by looking at previous historical events, if not in our organization but in others. But with the absence of that information, let's go back to the conversation we had in the previous section about threat and vulnerability. And the way I think about it is if you've got an environment that has vulnerabilities The question is, how easy are those vulnerabilities to exploit? So some vulnerabilities will be very trivial to exploit. Some will require possibly a lot of uh insider knowledge, a lot of expertise, a lot of determination and motivation to exploit. And then you ask yourself the question Well how motivated and capable are our threat sources? If you've done your threat analysis properly, you can answer this question. So logically speaking If I've got vulnerabilities that are easy to exploit and highly motivated and capable threat sources, logic would tell you that the likelihood of that risk playing out is probably a lot higher than the opposite way around. If I've got a vulnerability which yes could be exploited but requires hours of effort insider knowledge and various other things And I'm not facing sophisticated threats, let's say, from foreign intelligence services or organized crime groups. It might be a less of a likelihood Now again there's a lot more we can say about that, but for now what I'm looking for from an audit point of view is does the organization calculate likelihoods and consequences and does it have a proper system for doing so And risk evaluation is then taking those things, determining the level of risk, so usually by looking at a combination of the likelihood and consequence. And then making a decision about prioritization, and that often happens by looking at the results of the risk analysis Looking at the risk criteria, the risk criteria are the rules we use to prioritize, a bit like the finance director example I gave earlier, you know This is a level where something needs to be escalated, for example, and then prioritizing risks and deciding which ones might need treatment. and treatment comes where we decide that risks are unacceptable and action needs to be taken. And that decision should be being made by the risk owner. And as we'll see shortly, the risk owner is the one who should be approving the risk treatment plan and validating that risk treatment is taking place. \ No newline at end of file +Let's have a look at the next clause in the standard, **clause 6: Planning**. Now this is broken down into three particular parts, the actions to address risks and opportunities, information security objectives and planning to achieve them, and planning of changes. + +So let's start on this first one, actions to address risks and opportunities. We see this in clause 6.1.1 and something I want to really draw your attention to here because often there's a little bit of confusion about this: 6.1.1 isn't specifically about information security risk. We'll come to that shortly. It's about something slightly different. So let's just have a look at the words and then I'll try and explain my point here. So what we see is the following: when planning for the ISMS that the organization shall consider the issues referred to in 4.1 (context of the organization) and the requirements referred to in 4.2 (needs and expectations of interested parties). And then it says: and determine the risks and opportunities that need to be addressed *to ensure the ISMS can achieve its intended outcomes, prevent or reduce undesired effects and achieve continual improvement*. So what's this speaking about? This isn't necessarily speaking about identifying information security risks to particular systems or particular information. **This is about risks to the ISMS itself**. + +So let me try and explain this. So let's think about a project. Any project for that matter. You imagine a project manager would usually do a risk assessment. When they're doing a risk assessment, they're not focusing on security or any other matter. What they're focusing on is what's the risk of the project failing. You know, could the project overrun? Could it uh go over budget? Could it completely fail to deliver? Well this is a similar story here. What we're looking at is when we're thinking about establishing an ISMS, are there any situations, risks, etc. that could affect the ability of the ISMS to work as expected? +So for example, if we identified that we had a resource shortage, that would be a risk to the ISMS itself. There might be a chance that the ISMS cannot fulfill its objectives. If we didn't have appropriate support from management, we'd have a risk to the ISMS. +On the flip side, an opportunity is indeed the chance to potentially improve something or gain some benefit. So the opportunity of establishing an ISMS could be: it could open the doors to more commercial opportunities for example. Or one of the opportunities in an ISMS could be that we're going to conduct detailed risk analysis and we'll identify opportunities to drive efficiency in certain processes or remove duplication, etc. +So 6. 1. 1 wants us to focus on those particular risks and opportunities. + +Now that doesn't mean that we're going to ignore information security risk – quite the opposite. That's why there's a separate clause on that, clause 6.1.2. And clause 6.1.2, and I won't read it all out line by line, again I'll just give you the sort of summary. The organization shall define and apply an **information security risk assessment process** that does a number of things. The first one establishes and maintains **information security risk criteria**. Information security risk criteria, think of criteria as rules, are the rules we're going to use to understand our risk. So for example, we might lay out things like **risk acceptance criteria**. That is to say when a risk is identified, how do we decide? whether or not that's acceptable to the organization. Now we might have an answer to that because the organization may already have some general rules or criteria. +And the **criteria for performing those risk assessments**, so when do we need to perform an information security risk assessment: is it at the start of a new project, during a project? Do we trigger a risk assessment again if we have some kind of incident? Do we do them every so often? These are the questions that will answer in a documented risk assessment process. + +We then talk about the fact that it should **ensure repeatable results**. I'll get into that a little bit later in this section where we talk about having a proper risk assessment method, and then we will do a number of things including identifying information security risks. + +Something I want to draw your attention to right now, which I think is important right at the start, **identifying risk owners**. Risk owners are individuals in the organization who have a level of authority, a level of trust, to make risk decisions. It's very important that we know who those risk owners are early on. Because when we start to identify risks, we're going to have to consult with those owners to make decisions on what we're going to do with risks. If we don't have risk owners, then the process could come grinding to a halt. So this is an important point that the standard is calling out. + +We have **three stages** in a risk assessment: the **risk identification, analysis and evaluation**. So we expect to see according to clause 6.1.2 a very clearly defined, understandable risk assessment process. So as an auditor, when I'm coming in to look at this, I'll be looking at if the process is defined, and then I'll be looking at evidence by getting somebody to maybe take me through risk assessments that have been performed. + +Let's talk about some important factors in a risk assessment approach. There are three sorts of things we need to cover here. We need to identify a **methodology**. Let me explain this very clearly. Clause 6.1.2 tells us what should be considered when doing risk assessment. It does not tell us *how* to conduct a risk assessment. It doesn't say you shall calculate your risks on a scale of 1 to 10 or high, medium, and low, or using some other kind of formula. Nor does the guidance document, ISO 27005. We'll need to choose or define a methodology for that. We need to have an agreed way of conducting risk assessments (to **ensure repeatable results**). As well as having an agreed way to conduct those assessments, we must have predefined **risk acceptance criteria**. + +So let me give you an example. I was working with an organization, that didn't have such a process in place. We were trying to get this set up. I spent some time with the finance director. And we started to come up with some ways we could calculate risk. So we had what's called an **impact table**. So we had five levels of impact. So when we're calculating the damage that could be done, we could place it on a scale. And I sat with the finance director and I remember him pointing out a particular number on this scale and he basically said to me, if as part of these risk assessments we identify any risk that could result in the loss of this amount of money, and he mentioned a specific figure, or more, and the likelihood of that happening is medium or above, that cannot be accepted by the Information Security Committee. This needs to come to the board for review. So in this case he's given me, involuntarily you might say, some criteria, in this case **risk escalation criteria**. And these are the kind of conversations that an organization should be having to define this. And an organization should be identifying the overall level of **acceptable risk**. When it comes to information security. Now ultimately that is set by top management. And the level of acceptable risk will vary, of course, depending on organization. + +And sometimes when we talk about risk, we talk about this concept of **risk appetite**. And risk appetite is the amount of risk that senior management or directors or or company owners are willing to take in certain circumstances. That might influence the answer here. So for example, I've worked in organizations that have very different risk appetites. So I've worked in government entities that might have a low risk appetite because they are looking for stability. They don't want to take unnecessary risk. Whereas if you go into say a venture capitalist organization that's looking for rapid growth, they might have a much higher risk appetite because indeed that's what they're doing. They want to innovate and take risks to grow. And again, as an auditor It's not for me to say what is right or wrong here, or to enforce my preferences on the organization, but I do want to understand have they defined these things and why, and does it have the appropriate support from top management. + +Now there is a note here which says the following: The organization must ensure that the risk assessment generates **comparable and reproducible results**. So how does an organization ensure comparable and reproducible results and what does that actually mean? Well what it basically means is let's say that there's two of us doing risk assessments for an organization and I come along and do some and you know you come along and do another one that we both approach the problem in the same way and that means basically we should have a defined methodology. And there are a few things an organization should think about when they're **choosing a risk assessment methodology**. Now the first thing I would say here is there are many methodologies available for assessing information security risk. Some of them very simple, some of them very, very detail-oriented and extremely complicated. It's also possible to design your own methodology. So ISO doesn't dictate what methodology to use. So how can an organization settle on one that makes sense? + +![](CleanShot%202026-06-06%20at%2014.53.58.png) + +Well, there are a few things that the organization should think about. The first, **compatibility with the requirements of 27001**, that's relatively easy because basically, as long as the methodology considers threat and vulnerability, impact and likelihood, and the three tenants of security, then that part's pretty much answered straight away. + +Other things that are important are the way it's written, or the **vocabulary of the method**. Does the language make sense? Does the terminology make sense? So if it refers to the concept of threat, for example, do we understand the work that word in the same way? So when we get output from these assessments, will it be understandable? + +Another important one is number 5, **ease and use and pragmatism of the method**. There are some methods that are extremely rigorous and extremely complex and are really good for deep dive risk assessment. So I can think, for example, spending time in government departments, there are some methods we would use and one risk assessment of one information system could take 50 days or more because we're really looking under the hood at a lot of technical detail, but in that circumstance that's justified because of the type of systems and information we're trying to protect. But that wouldn't necessarily be very useful if I took that method and tried to apply that in a small startup company or commercial business. It would be rigorous, yes, but it probably wouldn't be practical. So I'm not trying to argue that we don't need to be rigorous. What I'm trying to say is we set up a method that is suitable for the organization at that time. An example I can give, I worked with a very small organization not too long ago. They had nothing in place for this at the time. They weren't overly familiar with this idea, so they didn't it's not like they had a team of risk professionals in the organization. So we started with something simple. We actually built an Excel spreadsheet with some very simple to use steps. Now is that the end game? Is that where I want them to be long term? Of course it isn't. We can get more sophisticated and we will over time as the organization matures. So let's make sure we pick something that's **fit for purpose**. + +Now if we are using a relatively complicated method, then there might be good questions in points three and four. Is there any **software** that the organisation can use to aid their risk assessments. The only caveat I would give to that point is that software tools are only as good as the person operating them. So you can have the best security tools available, but the person using it still needs to be familiar with the method to be able to explain the output. + +And that also speaks to point four. Are **documentation, training, support and competent personnel** available to implement and execute the method? If we're going to select a method, are we selecting one that's well used, that other organizations use? A method that's properly documented where we can get training or professional support if we need it, rather than something that's a little bit more obscure for example. + +And we can also think, last couple of points, about **cost to utilization**. That's very similar with ease and pragmatism. You know, how much time does it take to conduct this risk assessment? Do you need to bring in a specialist to do it, etc. We want to get that balance right. + +So all of these things can help. And whilst I don't promote any particular risk assessment method, just to maybe point you in a direction a little bit, there are methods out there you can think about. So some that I've seen in this space are things like Octave, for example, from Carnegie Mellon University. There is actually Octave S and Allegro that's targeted at smaller organizations, things like IRAM from the Information Security Forum is a really good example of a risk assessment methodology, platforms like VS Risk or a RAM buffer, etc. None of these are me promoting anything in particular, but just some examples that might help you to start looking and thinking about risk assessment methodologies. But there are plenty out there if you do that research. + +All risk assessment methodologies, regardless of how complex or not they are, go through a series of stages, and they should follow the stages that are laid out in ISO 27005, the guidance document that is there to support conformity with these particular clauses. + +![](CleanShot%202026-06-06%20at%2015.06.49.png) + + +So the first is **risk identification**. This is the step of identifying **risk scenarios**, not about likelihood and impact. This is about identifying potential scenarios, working with risk owners and other experts in the organization, to see what risks might be relevant And there are typically two ways we can set about identifying risk in an organization. Now, firstly I would say, this is never done by one individual on their own. Often it's a collection of people from a given part of the organization. So you might have a facilitator, a risk expert, but then other experts who can contribute. And we can do either an event-based approach, or asset-based approach, or both. +In **event-based risk identification**, we talk about specific events in general. So for example, we could have a general discussion about the risk related to ransomware in our organization, and think about that event, and think about how that event might play out. That's quite a generalized thing. +In **asset-based risk identification**, we take the asset, we look at that asset, and we look at potential vulnerabilities and threats. So let's say one of the assets is a CRM system. We take that CRM system, we look at the design, the build, all the details we can, and then we'd say, okay, does this system have any vulnerabilities? What do they look like? How could they be exploited? And from that, we would identify a set of risks that would be quite specific to that asset. + +So where an event-based approach gives you a good organizational overview, the asset-based approach is very specific. So let's take the ransomware example. When we do our asset-based assessment, we look at how that ransomware scenario would play out for this particular system, because it might differ from one environment to the other. If you want to be really rigorous, both approaches probably need to be done hand in hand. But the level of rigor you need to go to depends on the importance of the assets. ISO 27001 does not demand this, but I think if you want to do risk identification well, a combination of the two approaches would be really helpful. + +Now one of the things that sometimes I found comes up in risk identification workshops, for example, are people saying things like: well, that scenario is never going to happen, so we shouldn't really talk about it. And I always say, let's not have that argument now, in the risk identification phase, let's have that argument in the next phase. + +And that next phase is **risk analysis and evaluation**. So risk analysis is where we can have that debate, because what do we do in risk analysis? That's where we look at the **potential consequences** of a scenario playing out, and the **likelihood** of it. There are multiple ways of doing this. Likelihood can be arrived at by looking at events and how frequently they might occur. It can be worked out potentially by looking at previous historical events, if not in our organization but in others. But with the absence of that information, let's go back to the conversation we had in the previous section about threat and vulnerability. And the way I think about it, is if you've got an environment that has vulnerabilities, the question is, how easy are those vulnerabilities to exploit? Some vulnerabilities will be very trivial to exploit. Some will require possibly a lot of insider knowledge, a lot of expertise, a lot of determination and motivation to exploit. And then you ask yourself the question: well, *how motivated and capable are our threat sources*? If you've done your threat analysis properly, you can answer this question. + +So logically speaking, if I've got vulnerabilities that are easy to exploit and highly motivated and capable threat sources, logic would tell you that the likelihood of that risk playing out is probably a lot higher than the opposite way around. If I've got a vulnerability which could be exploited, but requires hours of effort and insider knowledge and various other things, and I'm not facing sophisticated threats from foreign intelligence services or organized crime groups, it might be a less of a likelihood. + +Now again there's a lot more we can say about that, but for now what I'm looking for from an audit point of view, is *does the organization calculate likelihoods and consequences, and does it have a proper system for doing so*. + +And **risk evaluation** is then taking those things, determining the level of risk, so usually by looking at a combination of the likelihood and consequence, and then making a decision about prioritization. That decision often happens by looking at the results of the risk analysis, and applying the risk criteria – the rules we use to prioritize. Like a level above where something needs to be escalated, for example, and then prioritizing risks and deciding which ones might need treatment. **Treatment** comes where we decide that risks are unacceptable, and action needs to be taken. And that decision should be being made by the risk owner. And as we'll see shortly, the risk owner is the one who should be approving the risk treatment plan, and validating that risk treatment is taking place. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S05.3-Overview-of-ISO-27001-requirements.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S05.3-Overview-of-ISO-27001-requirements.md index 6e626de..06d0e83 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S05.3-Overview-of-ISO-27001-requirements.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S05.3-Overview-of-ISO-27001-requirements.md @@ -9,6 +9,7 @@ isotags: - C.6.1.3 - C.6.2 status: active +processed: true --- # S05.3 Overview of ISO 27001 requirements @@ -18,4 +19,67 @@ This session covers ISO 27001 clause 6.1.3 (risk treatment) and 6.2 (information ## Transcription -So let's imagine an organization has took the time to identify risk and to analyse risk. According to clause 613 We then move into the need to do risk treatment. And risk treatment is all about choosing risk treatment options. Which we'll have a look at here in just a moment, and also determining which controls we might implement to respond to that risk. And we know that in Annex A, there are a list of 93 security controls that we can choose from. which you're not limited to, remember that. And we will need to state which of these we're going to implement or not in a document called the statement of applicability. That's all part of risk treatment. So we'll certainly run through in just a moment creating a statement of applicability. And also what's important in 613. f. Formulate an information risk security risk treatment plan. Also what's important is point F, obtaining the risk owners approval for the risk treatment plan and the acceptance of residual risk. That's the risk that's going to be left. after the treatment has took place. This is vitally important. This is one that sometimes I have identified as being a problem as an auditor where I've seen very good risk processes but then a disconnect between the process and the risk owner. So I'm always looking to see that the risk owner was involved and ultimately made that final decision. But before we look at the statement of applicability and a risk treatment plan We need to talk generally about the different risk treatment options that exist. So let's imagine an information security risk has been identified and we want to do something about it I'll go through a few different options. Now first one, risk modification. Risk modification means changing the circumstances around a risk. So that might be about implementing controls to reduce vulnerability. So let's say for example I have a network architecture and we identify the way in which the network segregated leaves its vulnerable to the attack. So we propose you know more granular segregation and introducing some kind of firewalling technology. We'd be doing a risk modification. To reduce the vulnerability and the likelihood. Or let's imagine we want to reduce impact. A very simple example of that. Let's think about organizations that use mobile devices like laptops if they do if they apply whole disk encryption to that laptop. It doesn't reduce the likelihood of the laptop being lost or stolen, but it does reduce the potential impact when that happens because we have more of a confidence, that confidential data isn't being disclosed. Both of those would be taking risk modification actions. Now the reason ISO calls it modification rather than reduction is In theory, we could allow risk to go the other way. If we identify, for example, we're spending a lot of time and money on a security control that's keeping a risk really low, you're well be well below the risk tolerance level, it may be a case that We can remove security controls to some degree, allowing an increase of risk, as long as it's managed, to assign that budget, time, etc. , somewhere else. So ISO does leave it as very flexible. hence the term risk modification. Other things an organization could do, risk avoidance, risk avoidance is where we take a decision to deliberately as you as you gathered there, avoid the risk scenario uh either partially or to some degree. So for example, um if we were selling goods online and we were seeing a particular amount of credit card fraud, let's say coming from a particular particular territory, we could take the view to stop taking card payments from that particular territory. Now that might be commercially a bad decision, possibly, but it is a theoretical example at least of risk avoidance Or if we said we will not use a particular type of technology because we're concerned about the risk level, you're taking a risk avoidance step. That's not always practical, but it is an option. Another potentially practical option to deal with risk is what we call risk sharing. In previous guidance and in other books, you might read this as risk transfer. ISO deliberately stopped using the word transfer. Because we're not passing a risk to somebody else. Risk sharing is where two organizations of people might share the burden. So let me try and give an example. Outsourcing is a good example of risk sharing. So let's say we have a particular problem, we share that with a third party, the risk still rests with us. I'll give two sort of worked examples on this. So one, I worked with one organisation that identified that it had quite a number of network security problems. And the organisation openly said, look, we don't have the expertise in-house to address some of this stuff And therefore they took a decision to enter into a partnership with a s a company who would maintain their network equipment for them. And they were very transparent about the vulnerabilities they had. And it was therefore the responsibility of the network service provider. to deal with some of these security vulnerabilities. But it's a shared risk because my client can't just then say, ah well, it's managed by somebody else if there's a security breach, an incident, etc. It would still be my client answering to the regulator, answering to the customer, but they have shared the workload, obviously with due diligence, with that third party. You often see this as well. Another example is with card payments, so websites that take card payment online. Some companies will say, well, rather than us take the risk of processing those credit card details ourselves We'll have a module that's run by a trusted third party, usually a PCI DSS service provider, and we'll share the burden with them. So they're going to deliver the service obviously for a fee, but the risk is shared. Now there may be cases where none of those options are practical or affordable. It could be that the cost of implementing modification is prohibitive or technically not feasible. There might not be a partner you can share it with and maybe risk avoidance just doesn't make sense At this point we might be into the realms of what ISA would call risk retention. That is to say that we have to accept that risk. That doesn't mean accept it forever. We might accept it for a period of time until better options come along. But accepting risk is something that ISO allows, providing that it's done as part of a proper process. in in in line with your risk management process and providing it's not just the default go-to option so we can't just say well uh we've got a long list of risks let's just sign everything off and hope the auditor uh is happy with that But where it makes sense those decisions can be made. But let's talk about risks where the treatment will be to implement controls. So according to clause 8. 3 of ISO 27005, the guidance document on risk management, it says that we shall select controls in order to address risk And those controls can be preventative, detective or corrective in nature. So we mentioned that in uh in the earlier section in the course and the difference between them. But practically speaking, we will find the controls that are very relevant here in annex A of ISO 27001. So let me just mention a couple of things about Annex A. So as we've said earlier, there are 93 security controls in there. It is not mandatory to implement every single one of those controls. An organization will need to run through them and decide which ones are applicable and which are not. Where a control is not applicable, the organization will need to mention this in a document called the Statement of Applicability and basically give a justification. You also need to justify the controls you've included by the way as well are marked as applicable. But when it comes to things that are not applicable, wearing my audit hat, I'll often talk the organization to say, okay, how have you come to the That conclusion. And sometimes it might be that a control isn't needed because the process isn't in place. For example, there are controls in Annex A about software development. Well, if your organization doesn't do software development or it's not in scope of the ISMS, that might make sense to mark that control as not applicable. And we'll have a look at that in a bit more detail in just a moment. But one thing I always like to tell people about Annex A is when you look at those 93 controls and try and read them, they're often described in no more than a sentence or a couple of sentences at best. And whilst you know you could read them and they probably make some sense, it doesn't give you a lot of implementation guidance as an organization. Let's take A5. 7 on threat intelligence. It simply says, you know, threat intelligence shall be gathered and processed by the organization or something along those lines. Not with a lot of detail in it. Now let's imagine I'm the implementer here and not the auditor. Then I might want some greater advice and guidance on how I'm going to fulfill that control. Well, that's where ISO 27002 comes in. So what ISO 27002 does is it's a document, a guidance document. It takes all the requirements of Annex A, or all the controls I should say, of Annex A, and for each and every one of those gives an explanation. So let's say let's take A5. 7. It's numbered the same in ISO 27002. You could go to that section and it will explain the control and its purpose or the objectives of such control. control is. It will give some implementation guidance and examples of things to think about and some additional reading what we call supplementary information. Now the key thing is about ISO 27002, it is there to help the implementer. Now as an auditor, I still look at ISO 27002. to make sure I'm familiar with the control, to make sure I'm asking the right questions as an auditor. However, I am not auditing an organization against ISO 2702 because it's not a set of requirements. So I cannot raise a finding to say you've not done something where the word should is used Because the word should is guidance. But at least if I've read it, I understand what the control is about. It puts you in a better position as an auditor to ask the right questions. But as an implementer, I would argue 27,002 is absolutely vital Now, there's a diagram we've included here, this sort of thing that looks a bit like a wheel, if you like. And this is for people who may be familiar or may have worked with the 2013 version of the standard. and want to see the comparison between the Annex there and Annex A in the newer standard, the newest version being the 20th So in the 2013 version of the standard, and some organizations are still aligned to that because they've got till the uh I think the end of uh October in 2024 to try transition so maybe some of us still sort of uh using that. That had in the annex 114 security controls grouped into areas which were called control objectives A5 through A18, covering many topics. And what we've seen in the new version is an effort to simplify that. to put 93 controls into four distinct areas. And people certainly have their opinions on what they prefer, but that's where we are today. And of course, the logical question I get asked is, hang on, we've gone from 114 controls to 93, so surely the newer version of the standard isn't quite as strong. That's not actually true at all because None of the controls from 2013 have been deleted as such. What's happened is in the newer version in 2022 quite a few of those controls have been merged. So in other words, where you had separate controls. describing something that have been brought together. And actually there's new controls in Annex A of the 2022 version. Things like threat intelligence, data loss prevention, data masking and information deletion. and configuration management, web filtering, those are a few that I can name, that have been added. So believe it or not, actually you've now got more control in the annex than you did in the previous version. There are plenty of documents out there that do show a mapping as well available online that if you want to see the mapping between the two annexes So, with all of this in mind, we need to create a document called a statement of applicability. As a when I say we need to create it, the organisation implementing the ISMS needs to to create it. We as auditors will of course review it. And as I've said, this SOA statement of applicability is a document that lists all 93 controls And the organization will state whether they apply or not. If they do, why? If they don't, why not? Usually if they do, though the answer to that will be to address risk, to address a legal or regulatory requirement. fulfill the customer requirement. Our job as auditors is to review that SOA and make sure, as we'll see in a second, that those controls and those selections are justified. If an organization decides it's going to add other controls into its ISMS, so let's say we have a company that needs to follow PCI DSS because it's processing credit card data and they include those controls, those controls should also be spoken about in the statement of applicability. So let's just explore that a little bit further. Let's imagine you're looking at a statement of applicability and an organization has marked some controls as applicable. So they've said yes, they need it We need to see the justification. Why does it apply? So they can't just say, yes, because you know we're just ticking a box. There's got to be a reason. So let's take this uh example on the slide here, uh which is related to A5. 20. Relevant information security requirements shall be established and agreed with each supplier based on the type of supplier relationship. And they've said They want to implement this control because they want to ensure security across all IT components. A number of IT components are being used or delivered by suppliers. This is perfectly fine justification. As I say, they could have said we've identified a risk in this area and therefore we need this control to address risk X, Y, and Z. They could have said we have a legal and regulatory obligation to monitor our supply chain, therefore the supplies, or we have a customer uh requirement in our contract if that was applicable. So there's many ways there, depending on what the right answer is, to justify it. But they've given an explainer. Note that that explainer is only a paragraph. We don't need as I like to say to people, war and peace in here. You can show me other more detailed technical documents separately, but just enough of a summary would be sufficient On the flip side, excluding a control, we've got a few examples here, of A6. 1, an organization deciding not to implement that because it violates legal or contractual requirements. Now in reality it's probably a partial uh answer to that because I'm sure there's still some background checking they could do. But anyway, if a control was at odds with a law or a regulation We could exclude it. Or if it's just not relevant, like remote working, if we don't actually have people working remotely or software development if we're not doing that in-house, those are perfectly sensible reasons to exclude exclude controls. As an auditor our job is really to look at especially those excluded controls make sure the organization has fully understood them and fully their their reasoning makes sense So here we have a simple example of a statement of applicability. Obviously, there's only two controls in it, a real one would have 93. And this is just to show typically how an SOA is laid out So you can see in here two controls. One is marked as applicable, yes, with a description and a justification. And then we have the one there on remote working, applicable no. justification. One thing to say is this is a living breathing document. The organization should always be adjusting and updating its statement of application. Is necessary. And the last thing to say about a statement of applicability is when an organization is certified on their certificate, it will refer to the statement of applicability version and anybody who's looking at the certificate is entitled to ask to see a version of the SOA. In other words, if I'm doing due diligence on an organization and they tell me they're certified to ISO 27001 as well as understanding the scope of the ISMS, I would want to know which controls they've implemented and which ones they haven't. And it would be perfectly reasonable to ask that question. The last part of clause six is also worth mentioning here as well, is not so much about risk, but objectives. It says the title of it is the information security objectives and planning to achieve them. So all organizations should have information security objectives. Some of those objectives might be derived from the risk assessment we've done, hence why 6. 2 for that. 6. 1. Some objectives may be derived from commercial objectives, you know, things we want to achieve. But of course the whole point of having an ISMS is to fulfill certain objectives. just have an ISMS for the sake of having one. And what the standard says here is the information security objectives that the organization does identify shall, as we see, be consistent with the information security policy. which would make sense, be measurable, if practicable, I'll come back to that in a second. Take into account applicable information security requirements. and results from the risk assessment which we've just been talking about and those objectives shall be communicated and updated as appropriate. So what this means Is depending on the work you've done in clause four, understanding the needs and expectations of interested parties Depending on the work we've done in clause 6. 1, understanding our risk, depending on the discussions we've had with our management, we'd put together a set of objectives Now some security objectives might be very high level, you know, basically long-term. You know, you might say an organization might say they have an objective to ensure ongoing legal and regulatory compliance, for example. But some may have shorter term, much more measurable objectives. So if you said, well, based on our understanding, we want to improve our security incident management response time by X percent in the next 12 months. That would be a very clear short-term objective. But what we're looking for is not that the organization just has a list of objectives, but are there clear plans that really specify how they will achieve them. Because in the end, from an audit point of view, the judgment we're making is not only Does this ISMS conform to the requirements of the standard? The other big one is does this ISMS allow the organisation to achieve its objectives? Because that's the whole thing. purpose so of course they can only achieve it with adequate plans in place. \ No newline at end of file +So let's imagine an organization has took the time to identify risk and to analyse risk. According to clause 6.1.3, we then move into the need to do risk treatment. And risk treatment is all about choosing risk treatment options. Which we'll have a look at here in just a moment, and also determining which controls we might implement to respond to that risk. + +And we know that in Annex A, there are a list of 93 security controls that we can choose from, which you're not limited to, remember that, And we will need to state which of these we're going to implement or not in a document called the statement of applicability. That's all part of risk treatment. So we'll certainly run through in just a moment creating a statement of applicability. And also what's important in 6.1.3. f. Formulate an information risk security risk treatment plan. + +Also what's important is point f, obtaining the risk owners approval for the risk treatment plan and the acceptance of residual risk. That's the risk that's going to be left after the treatment has took place. This is vitally important. This is one that sometimes I have identified as being a problem as an auditor, where I've seen very good risk processes, but then a disconnect between the process and the risk owner. So I'm always looking to see that the risk owner was involved and ultimately made that final decision. + +But before we look at the statement of applicability, and a risk treatment plan, we need to talk generally about the different risk treatment options that exist. So let's imagine an information security risk has been identified and we want to do something about it. I'll go through a few different options. +![](CleanShot%202026-06-06%20at%2015.33.55.png) + +**Risk modification** means changing the circumstances around a risk. So that might be about implementing controls to reduce vulnerability. So let's say for example I have a network architecture and we identify the way in which the network segregated leaves its vulnerable to the attack. So we propose more granular segregation and introducing some kind of firewalling technology. We'd be doing a risk modification to **reduce the vulnerability and the likelihood**. + +Or let's imagine we want to **reduce impact**. A very simple example of that. Let's think about organizations that use mobile devices like laptops and they apply whole disk encryption to those laptops. It doesn't reduce the likelihood of the laptop being lost or stolen, but it does reduce the potential impact when that happens because we have more of a confidence, that confidential data isn't being disclosed. Both of those would be taking risk modification actions. + +Now the reason ISO calls it modification rather than reduction is, in theory, we could allow risk to go the other way. If we identify, for example, we're spending a lot of time and money on a security control that's keeping a risk really low, well below the risk tolerance level, it may be a case that we can remove security controls to some degree, allowing an increase of risk, as long as it's managed, to assign that budget, time, etc., somewhere else. So ISO does leave it as very flexible, hence the term risk modification. + + +**Risk avoidance** is where we take a decision to deliberately to avoid the risk scenario either partially or to some degree. So for example, if we were selling goods online and we were seeing a particular amount of credit card fraud coming from a particular territory, we could take the view to stop taking card payments from that particular territory. Now that might be commercially a bad decision, possibly, but it is a theoretical example of risk avoidance. Or if we said we will not use a particular type of technology because we're concerned about the risk level, you're taking a risk avoidance step. That's not always practical, but it is an option. + +Another option to deal with risk is **risk sharing**. In previous guidance this was read as 'risk transfer'. ISO deliberately stopped using the word transfer, because we're not passing a risk to somebody else. Risk sharing is where two organizations of people might share the burden. So let me try and give an example. *Outsourcing is a good example of risk sharing*. So let's say we have a particular problem, we share that with a third party, the risk still rests with us. +I'll give two sort of work examples on this. So one, I worked with one organization that identified that it had quite a number of network security problems. And the organization openly said, look, we don't have the expertise in-house to address some of this stuff. And therefore they took a decision to enter into a partnership with a company who would maintain their network equipment for them. And they were very transparent about the vulnerabilities they had. And it was therefore the responsibility of the network service provider to deal with some of these security vulnerabilities. But it's a shared risk because my client can't just then say if there's a security breach, an incident, etc., ah well, it's managed by somebody else. It would still be my client answering to the regulator, answering to the customer, but they have shared the workload, obviously with due diligence, with that third party. +Another example is with card payments, so websites that take card payment online. Some companies will say, well, rather than us take the risk of processing those credit card details ourselves, we'll have a module that's run by a trusted third party, usually a PCI DSS service provider, and we'll share the burden with them. So they're going to deliver the service obviously for a fee, but the risk is shared. + +Now there may be cases where none of those options are practical or affordable. It could be that the cost of implementing modification is prohibitive or technically not feasible. There might not be a partner you can share it with and maybe risk avoidance just doesn't make sense. At this point we might be into the realms of what ISO would call **risk retention**. That is to say that we have to accept that risk. That doesn't mean accept it forever. We might accept it for a period of time until better options come along. But accepting risk is something that ISO allows, providing that it's done as in line with your risk management process, and providing it's not just the default go-to option. So we can't just say: we've got a long list of risks let's just sign everything off and hope the auditor is happy with that. But where it makes sense those decisions can be made. + +Let's talk about risks where the treatment will be to implement controls. So according to clause 8.3 of ISO 27005, the guidance document on risk management, it says that we shall select controls in order to address risk, and those controls can be preventative, detective or corrective in nature. So we mentioned that in the earlier section in the course, and the difference between them. Practically speaking, we will find the controls that are very relevant here in annex A of ISO 27001. + +So let me just mention a couple of things about Annex A. So as we've said earlier, there are 93 security controls in there. It is not mandatory to implement every single one of those controls. An organization will need to run through them and decide which ones are applicable and which are not. Where a control is not applicable, the organization will need to mention this in a document called the Statement of Applicability and basically give a justification. You also need to justify the controls you've included, by the way, as well are marked as applicable. But when it comes to things that are not applicable, wearing my audit hat, I'll often talk the organization to say, okay, how have you come to that conclusion. And sometimes it might be that a control isn't needed because the process isn't in place. + +For example, there are controls in Annex A about software development. Well, if your organization doesn't do software development, or it's not in scope of the ISMS, that might make sense to mark that control as not applicable. And we'll have a look at that in a bit more detail in just a moment. But one thing I always like to tell people about Annex A is, when you look at those 93 controls and try and read them, they're often described in no more than a sentence or a couple of sentences at best. And whilst you know you could read them and they probably make some sense, it doesn't give you a lot of implementation guidance as an organization. + +Let's take A5.7 on threat intelligence. It simply says threat intelligence shall be gathered and processed by the organization or something along those lines. Not with a lot of detail in it. Now let's imagine I'm the implementer here and not the auditor. Then I might want some greater advice and guidance on how I'm going to fulfill that control. That's where ISO 27002 comes in. ISO 27002 is a guidance document. It takes all the requirements of Annex A, or all the controls I should say, of Annex A, and for each and every one of those gives an explanation. So let's say let's take A5.7. It's numbered the same in ISO 27002. You could go to that section and it will explain the control and its purpose, what the objective of such a control is. It will give some implementation guidance and examples of things to think about and some additional reading what we call supplementary information. Now the key thing is about ISO 27002, it is there to help the implementer. +Now as an auditor, I still look at ISO 27002, to make sure I'm familiar with the control, and to make sure I'm asking the right questions as an auditor. However, I am not auditing an organization against ISO 27002 because it's not a set of requirements. So I cannot raise a finding to say you've not done something where the word *should* is used, because the word should is guidance. But at least if I've read it, I understand what the control is about. It puts you in a better position as an auditor to ask the right questions. But as an implementer, I would argue 27002 is absolutely vital. + +![](CleanShot%202026-06-06%20at%2015.55.57.png) + + +Now, there's a diagram we've included here, this sort of thing that looks a bit like a wheel, if you like. And this is for people who may be familiar or may have worked with the 2013 version of the standard. and want to see the comparison between the Annex there and Annex A in the newer standard, the newest version being the 20th So in the 2013 version of the standard, and some organizations are still aligned to that because they've got till the uh I think the end of uh October in 2024 to try transition so maybe some of us still sort of uh using that. That had in the annex 114 security controls grouped into areas which were called control objectives A5 through A18, covering many topics. And what we've seen in the new version is an effort to simplify that, to put 93 controls into four distinct areas. And people certainly have their opinions on what they prefer, but that's where we are today. And of course, the logical question I get asked is, hang on, we've gone from 114 controls to 93, so surely the newer version of the standard isn't quite as strong. +That's not actually true at all because none of the controls from 2013 have been deleted as such. What's happened is in the newer version in 2022 quite a few of those controls have been merged. So in other words, where you had separate controls, describing something that have been brought together. And actually there's new controls in Annex A of the 2022 version. Things like threat intelligence, data loss prevention, data masking and information deletion, configuration management, web filtering, those are a few that I can name, that have been added. So believe it or not, actually you've now got more controls in the annex than you did in the previous version. There are plenty of documents out there that do show a mapping as well available online that if you want to see the mapping between the two annexes + +So, with all of this in mind, the organization implementing the ISMS needs to to create a document called a **statement of applicability**. This SoA, statement of applicability, is a document that lists all 93 controls, and the organization will state whether they apply or not. If they do, why? And if they don't, why not? + +Usually if they do, the answer to that will be to address risk, to address a legal or regulatory requirement, to fulfill the customer requirement, etc.. Our job as auditors is to review that SoA and make sure, as we'll see in a second, that those controls and those selections are justified. +If an organization decides it's going to add other controls into its ISMS, so let's say we have a company that needs to follow PCI DSS because it's processing credit card data and they include those controls, those controls should also be spoken about in the statement of applicability. +Let's explore that a little bit further. Let's imagine you're looking at a statement of applicability and an organization has marked some controls as applicable. So they've said yes, they need it. We need to see the justification – why does it apply? So they can't just say, yes, because you know we're just ticking a box. There's got to be a reason. + +So here's an example which is related to A5.20: "Relevant information security requirements shall be established and agreed with each supplier based on the type of supplier relationship". And the organization said they want to implement this control because they want to ensure security across all IT components, as a number of IT components are being used or delivered by suppliers. This is perfectly fine justification. As I say, they could have said we've identified a risk in this area and therefore we need this control to address risk X, Y, and Z. They could have said we have a legal and regulatory obligation to monitor our supply chain, therefore the supplies, or we have a customer requirement in our contract if that was applicable. So there's many ways there, depending on what the right answer is, to justify it. But they've given an explainer. Note that that explainer is only a paragraph. We don't need as I like to say to people, war and peace in here. You can show me other more detailed technical documents separately, but just enough of a summary would be sufficient. + +On the flip side, excluding a control, we've got a few examples here, of A6.1 Screening, an organization deciding not to implement that because it violates legal or contractual requirements. Now in reality it's probably a partial answer to that, because I'm sure there's still some background checking they could do. But anyway, if a control was at odds with a law or a regulation, we could exclude it. Or if it's just not relevant, like remote working, if we don't actually have people working remotely or software development if we're not doing that in-house, those are perfectly sensible reasons to exclude exclude controls. + +As an auditor our job is really to look at especially those excluded controls and make sure the organization has fully understood them, and their reasoning makes sense. + +![](CleanShot%202026-06-06%20at%2016.10.12.png) + +So here we have a simple example of a statement of applicability. Obviously, there's only two controls in it, a real one would have 93. And this is just to show typically how an SoA is laid out. So you can see in here two controls. One is marked as applicable, yes, with a description and a justification. And then we have the one there on remote working, applicable no, justification. One thing to say is this is a living breathing document. The organization should always be adjusting and updating its statement of applicability. Is necessary. + +And the last thing to say about a statement of applicability is, when an organization is certified, on their certificate it will refer to the statement of applicability version, and anybody who's looking at the certificate is entitled to ask to see a version of the SOA. In other words, if I'm doing due diligence on an organization and they tell me they're certified to ISO 27001 as well as understanding the scope of the ISMS, I would want to know which controls they've implemented and which ones they haven't. And it would be perfectly reasonable to ask that question. + +Clause 6.2, information security objectives and planning to achieve them, is also worth mentioning here. It's not so much about risk, but **objectives**. All organizations should have information security objectives. Some of those objectives might be derived from the risk assessment we've done, hence why 6.2 (information security objectives) follows 6.1 (actions to address risks and opportunities). Some objectives may be derived from commercial objectives, things we want to achieve. The whole point of having an ISMS is to fulfill certain objectives. just have an ISMS for the sake of having one. + +And what the standard says here is the **information security objectives** that the organization does identify shall, as we see, be consistent with the information security policy, be measurable, if practicable (I'll come back to that in a second), take into account applicable information security requirements and results from the risk assessment, and those objectives shall be communicated and updated as appropriate. So what this means is, depending on the work you've done in clause 4, understanding the needs and expectations of interested parties, and on the work we've done in clause 6. 1, understanding our risk, and depending on the discussions we've had with our management, we'd put together a set of objectives. Now some security objectives might be very high level and long-term, like ensure ongoing legal and regulatory compliance. But some may have shorter term, much more measurable objectives. + +So you might want to improve your security incident management response time by X percent in the next 12 months. That would be a very clear short-term objective. What we're looking for is not that the organization just has a list of objectives, but **are there clear plans that really specify how they will achieve those objectives?** + +Because in the end, from an audit point of view, the judgment we're making is not only: does this ISMS conform to the requirements of the standard? The other big one is does this ISMS allow the organization to achieve its objectives? Because that's the whole thing. purpose so of course they can only achieve it with adequate plans in place. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S05.4-Overview-of-ISO-27001-requirements.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S05.4-Overview-of-ISO-27001-requirements.md index 317b0ef..9bd3699 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S05.4-Overview-of-ISO-27001-requirements.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S05.4-Overview-of-ISO-27001-requirements.md @@ -12,6 +12,7 @@ isotags: - C.7.4 - C.7.5.1 status: active +processed: true --- # S05.4 Overview of ISO 27001 requirements @@ -21,4 +22,50 @@ This session covers ISO 27001 clause 7 (Support), which establishes the building ## Transcription -So next let's take a look at clause seven. So clause seven in the standard is entitled support and it covers five distinct areas from resources to documented information. So before we sort of look through these what I describe clause 7 as is the building blocks of the management system. In other words, these are all the things that would need to be in place in any organization for a management system to work effectively. So let's just take a run through and understand what the standard is requiring and some of the things we should be thinking about. So clause 7. 1 then says the following. It says that the organisation shall determine and provide the resources needed for the establishment, implementation, maintenance and continual improvement of the ISMS Now when we say the resources needed, these resources could be human resources, as in people, financial resources, so appropriate budgets. tools and technologies, you know, physical workspace if that's relevant. This is what we mean by resources. So what we're looking for is that the organization has Planned the resource requirements has a proper resource plan in place. They should be thinking longer term as well So one question I always like to ask is, you know, if you expand, for example, over the let's say coming 12 months, if that's in the organisation's plans, have they thought about how they'll ensure that there's adequate resource provision in this case? Particularly relevant with roles and responsibilities as well, do those resources have enough time? So there was a case with one organization where it was a relatively small business And the IT director was also named as the information security manager. And this person was perfectly able to do that job, except for the fact that they didn't really have time. Their IT director duties were so large if you like they didn't have the time to do that that would point to me as a resource problem. So have they properly planned that resource out over the long term Now if we focus specifically on human resources, not only do human resources the people need to have time, they also according to the standard in clause 7. 2 need to be what we call competent. And clause 7. 2 states that, without necessarily reading out every line, that the organisation shall determine the necessary competence of persons doing work under its control that affects security performance. That the organisation should ensure that those people are competent on the basis of what this is, education, training, or experience And where applicable, in other words, where there are situations where we need to improve competence, that those gaps are essentially plugged. And there should be evidence of that. So let's think about that practically speaking. So this means when an organization establishes roles and responsibilities for security, this should also establish the kind of skill sets that those people fulfilling those roles should meet. Now you won't find anything in the standard saying that somebody in a certain position needs to have X amount of experience or you need to hire somebody with this qualification. it's down to the organisation to determine that. A really good example of that I saw on a real world audit was a quite a large organization and they had a large cybersecurity function and they had what they called a competence matrix. So basically on on in this matrix they basically had one axis which was all the job roles in the cybersecurity function from SOC analyst to red team test right through to sort of uh your governance risk and compliance roles, so real variety And then across the top axis they had a bunch of skills described there from networking knowledge to application security to risk management. And each area on the map on the axis you could sort of plot it had a number assigned to it and that number was basically the required skill level for that role. from a level one, which they said was introductory or basic knowledge, through to level five, which was subject matter expert knowledge in this case And so the idea was you could look at any role and say what are the kind of skills and knowledge that the an individual within that role needs to have. And that organization used that to first of all develop its own internal employees so it could work with their staff to see where they might want to enhance their skills and provide them with training and support. They also used it as a career development mechanism. So if you were in one position and wanted to move or progress, you could see the kind of learning path you would need to take, the training path you'd need to take to get there And they also used that when they were onboarding new employees because they could actually then test somebody's competency through not just looking at their qualifications but maybe getting them to do some tests or competence-based activities in their interviews. So being clear about what the skill set requirements are is going to be important. Because you imagine running an ISMS and having individuals who might not have the required skills that could undermine things very easily. Let's take software development, for example. Let's say I have software developers who are not familiar with secure coding, for example, then you know that could potentially then lead to vulnerabilities which otherwise wouldn't have been present. So ensuring competence across the board is important. There's a lot we can say about that, but at this level, this is what clause 7. 2 is asking us to think about. Now that's slightly different to awareness, which is a much more broad thing. So when we look at clause 7. 3 it says The persons doing work under the organization's control, so that can be both employees, freelancers, contractors or even suppliers. shall be aware of the information security policy, their contribution to the effectiveness of the ISMS and the implications of not conforming to the requirements of the ISMS. Now many organisations tackle this by having quite a broad awareness program for both new employees joining the organization and for people there longer term. So you might think see things like e-learning activities, you know, awareness training sessions and so forth. But what we're looking for is what efforts are the organization making to really drive the right security behaviours in the organization Longer term that might be about building a strong security culture where people think about security almost as just being a normal part of their duties, not as a sort of a separate discipline. And again a bit later in the course we'll talk about as an auditor the kind of evidence you can seek out in this area. For example, looking at training records, I often as an auditor we'll choose a sample of employees and I'll interview those employees during the uh the audit. Not to catch them out or anything like that, but just to understand what are they aware of when it comes to security. Do they recall what training they had? Do they you know what do they think the most significant security issues are often just those kind of questions could soon tell you uh what levels of awareness are generally in place in the organization Now another thing that clause 7 focuses on is this topic of communication. So let's think about what we said in clause 4. We said in clause 4 that the organization should identify its interested parties, both internal and external. But it's not just a case of identifying them. Obviously to run an effective management system the organization and those running the management system would need to have regular communication with different interested parties. And there might be different reasons for that regular communication. It might be about giving interested parties an assurance when it comes to security. So for example customers, we might want to keep customers appraised of what we're doing to give them or instill and maintain confidence. It might be about support. We might be regularly communicating with our top management in order to get the ongoing buy-in and commitment that we need. Or we might be regularly talking to users in order to encourage the right behaviours. So for every interested party, there might be different reasons and purpose. for communicating. But what the standard says is we should essentially come up with a plan laying out on what we're going to communicate to who, so what kind of topics, how frequently we're going to do that and the methods we're going to use. Because every interested party, the way in which we communicate may need to vary depending on their level, their purpose, what they need to know. And so there should be a strong communication strategy and plan. And obviously from an audit point of view, I would want to see that plan, I'd want to see the examples of communication. And not only that What are the organisation then doing with that? In other words, is the communication effective? So, you know, it's great, for example, to send a let's say a report to top management every month on how we're performing from a security point of view But what impact is that having? In other words, is that leading to the desired effect of, in this case, let's say more buy-in? What sort of feedback are they the organization getting and are they adjusting it? But what we're looking for is on that ongoing communication. And one thing I should maybe just add to this is that the examples I've given there might seem a bit one way, like I'm talking about the organisation talking to its interested parties. Obviously communication comes back the other way as well and so how does the organisation manage that? So for example, let's say an employee in the organisation has a question about security and wants some help. Well, how can they go about seeking that? How responsive is the organization to that? Because if you could see gaps there, that could be a potential problem. You know, if people are coming for advice and not receiving it very quickly it might happen happen the next time round that they say well I won't bother I'll just skip that particular step. So we're looking for the overall communication plan and approach Now in any ISO standard, any management system standard, of course, there is always talk about documentation or documented information as ISO would put it. And I've heard sort of some myths if you like about ISO standards when it comes to things like this. I've heard people saying things like, well all ISO standards are documenting what you do or you need to create loads of documents in order to meet the requirements of an ISO standard. So two things to tell you there. It's not just about documenting what you do. Because ultimately you could be documenting things that you do that aren't particularly very good. So the point is it's about creating documentation that's needed to support the organization in doing tasks um well and doing tasks in a consistent manner. Also it's not true to say that you need to you need to create mountains of documents for the sake of it. So let's actually have a look at what's what the standard actually says and then we can work this out. So it says the following in clause 7. 51. The organization's information security management system shall include documented information required by this document. That's quite a mouthful isn't it? But basically documented information required by the standard So it is true that there are some minimum documents that need to be created when implementing ISO 2701, but there's not a huge amount of them. The main documents, I won't necessarily be able to recite every single one of them, but the main ones that spring to mind here are things like the scope. Of course, the scope needs to be documented the information security policy, the risk management process, the statement of applicability, the resource requirements. These kind of things you would expect to see, the internal audit process, you'd expect to see those documented. And how do you know if something is required? Well when you read the standard, if you see the words this shall be available as documented information, that's point A. But the myth bit about creating lots of documents is the bit in B, point B, 751B, which says documented information determined by the organization as being necessary, key word, for the effectiveness of the ISMS. So what you've sometimes see and I've certainly witnessed in real life and I shouldn't criticize consultants because I am one myself but I sometimes see consultants who are going to an organization They'll look up clauses 4 to 10, all 93 security controls and write a document for each one. Well there you are, here's a huge bunch of documents for you and guess what happens? Those documents don't get read. You might end up calling them shelfware. You might have heard of that term before, just documentation that isn't looked at. So that's not what the target is here. We've got to determine what documentation we need. So if we're in a complex environment with a complex task, let's say a system administration task that we need the system administrators to do consistently in detail, then of course something like that you'd expect to see a detailed document with step-by-step instructions. Maybe for simpler tasks, lower risk tasks, where we have a highly competent workforce, the level of documentation won't be quite the same. An example from an audit I actually give when I teach this course is the following one. I did an audit of an IT company that had 15, that's 1-5, employees. Uh and in this audit I um spoke to the uh the basic the owner of the company and we were talking about HR security and I asked him about the leavers process. So I said, can you take me through what happens when somebody leaves And how do you ensure that you remove all system access when they've gone? And he said, well, being honest with you, in the last five years I've only had two people leave the organisation, but here's what we do, and he talked me through it And I checked the uh all the uh the various systems, the Active Directory, a few other applications. I could see that those accounts had been removed. I'd seen an email to the administrator confirming this. So I was happy that the two individuals we're speaking about had had their access remote So I asked him, I said, if you're not here, given that you know the process, well what would happen then? And he explained how his colleague also would cover this and I interviewed that colleague separately. So long story short, by the time I'd done those interviews and looked at that evidence, I was satisfied that they had managed those levers effectively. But I asked the classic question, which is, you've verbally explained this procedure to me and I've seen evidence that it's happening. But have you documented it? And the answer that came back was no we haven't. We haven't written a document. And then I have a decision to make as an auditor. Well the standard doesn't actually say, believe it or not, that there shall be a document So in that organisation I took the view that what I've seen is effective. I did raise an opportunity for improvement and I said to them, if you grow and there's more people involved then this is more complex. You probably ought to document this, but certainly it's not a mandatory requirement. Now had I have been told that story in a company with a a thousand or two thousand employees, I would have taken a very different view because the lack of documentation could mean that the process would be ineffective. So this is the point about point B. Every organization is different and especially as an auditor you just need to think about the proportionality. Documentation should always add value, not just be there for the sake of ticking boxes. Now one thing that is important for the documentation that is created, whether that's created in Word documents, on wiki pages, in products like Confluence or wherever it might be is that the organisation has what we call a document life cycle. There should be some rules that specify how documents are created and who can create them. So maybe some levels of authorisation There should be some information about how the organisation will identify those documents. Is it a policy, is it a procedure, including the classification and security level. So in other words, is this a document that is limited to internal use only, limited to a certain audience? Does it have a certain level of sensitivity? If the answer to those are yes, obviously I would expect to see security handling rules in an audit, we'd be testing that as well to see if those security rules have been followed. What are the rules about modifying documents? So do we have access restrictions to stop people simply making changes to documented information unless they're authorized? And I'd want to understand the approval process. Now approval processes may differ. A corporate policy may need a different approval channel to a let's say a local procedure in a given department. But how does that work? I'd also want to understand how documents are actually distributed. It's one thing to have good quality documents, but how do the people who are meant to use them know that they're there? So how do we share them with people And of course we can test that in real life during an audit by looking at the documentation people are using, asking them questions about it So recent audit I did, for example, the organization had launched a new AI policy just a few weeks before the audit. So when I did my awareness interviews, I asked a number of people, I just said, have you seen the AI policy? Where would you find it? And I wasn't grilling them on their knowledge, it was more about could they find it, did they know it existed, you know, could they consult it if they needed it. How does the organisation check whether the documents are being used adequately or not? Again, in other words, are people actually referring to them? Are they actually following what's stated in these documents? That can be discovered through things like monitoring and metrics, through the internal audit process perhaps. These are all relevant points. And then the last two bits, archiving and disposal. Depending on the information or data retention policies of the organisation, there might be a point in time when organisations archive documents, that is to say keep them, but just store them for the longer term. And there may be a point when they actually decide to destroy or dispose of those documents. Again, I'd want to understand what the rules are about that From an archiving point of view, are there any security rules? How are those archives protected? Now thankfully the vast majority of documentation today is electronic and there are electronic archiving solutions Back when we had a lot of paper documents, I'd have to concern myself with physical archive storage, for example, and how secure or well protected that might be. And then disposal, the way in which data is destroyed, might vary depending on sensitivity. So there's no right or wrongs for all of these, but there is an expectation that all of these points can be answered. Now typically that would be answered in a document management policy. So an organization really ought to have a document management policy that answers all of these. The last point I want to make on this is if an organization who is implementing ISO 27001 has another management system in place, let's say 9001 for quality it might be that they already have these processes in place and could essentially reuse them because all ISO management systems have the same demands so that's always something to explore as well. \ No newline at end of file +So next let's take a look at clause 7. So clause 7 in the standard is entitled **support** and it covers five distinct areas from resources to documented information. So before we sort of look through these what I describe clause 7 as is **the building blocks of the management system**. In other words, these are all the things that would need to be in place in any organization for a management system to work effectively. So let's just take a run through and understand what the standard is requiring and some of the things we should be thinking about. + +So clause 7. 1 then says the following. It says that the organization shall **determine and provide the resources needed** for the establishment, implementation, maintenance and continual improvement of the ISMS. Now when we say the resources needed, these resources could be human resources, as in people, financial resources, so appropriate budgets. tools and technologies, you know, physical workspace if that's relevant. This is what we mean by resources. So what we're looking for is that the organization has planned the resource requirements, has a proper resource plan in place. They should be thinking longer term as well. + +So if expanding or growth, for example, is in the organization's plans over the let's say coming 12 months, have they thought about how they'll ensure that there's adequate resource provision in this case? This is particularly relevant with roles and responsibilities as well, do those resources have enough time? + +So there was a case with one organization where it was a relatively small business, and the IT director was also named as the information security manager. And this person was perfectly able to do that job, except for the fact that they didn't really have time. Their IT director duties were so large if you like they didn't have the time to do that that would point to me as a resource problem. So have they properly planned that resource out over the long term. + +Now if we focus specifically on human resources, not only do human resources the people need to have time, they also according to the standard in clause 7.2 need to have what we call **competence**. And clause 7.2 states that the organisation shall determine the necessary competence of persons doing work under its control that affects security performance. That the organization should ensure that those people are competent on the basis of what this is, education, training, or experience. And where there are situations where we need to improve competence, that those gaps are essentially plugged. And there should be evidence of that. + +So let's think about that practically speaking. This means when an organization establishes roles and responsibilities for security, this should also establish the kind of skill sets that those people fulfilling those roles should meet. Now you won't find anything in the standard saying that somebody in a certain position needs to have X amount of experience or you need to hire somebody with this qualification. it's down to the organization to determine that. + +A really good example of that I saw on a real world audit was a quite a large organization and they had a large cybersecurity function and they had what they called a competence matrix. So in this matrix they had one axis which was all the job roles in the cybersecurity function, from SOC analyst to red team test, right through to your governance risk and compliance roles. And across the top axis they had a bunch of skills described there, from networking knowledge to application security to risk management. And each area on the map it had a number assigned to it, and that number was basically the required skill level for that role. From level one, which they said was introductory or basic knowledge, through to level five, which was subject matter expert knowledge. And so the idea was you could look at any role and say what are the kind of skills and knowledge that the an individual within that role needs to have. And that organization used that, to first of all develop its own internal employees, so it could work with their staff to see where they might want to enhance their skills and provide them with training and support. They also used it as a career development mechanism. So if you were in one position and wanted to move or progress, you could see the kind of learning path you would need to take, the training path you'd need to take to get there. And they also used that when they were onboarding new employees because they could actually then test somebody's competency through not just looking at their qualifications, but maybe getting them to do some tests or competence-based activities in their interviews. So being clear about what the skill set requirements are is going to be important. Because you imagine running an ISMS and having individuals who might not have the required skills, that could undermine things very easily. + +Let's take software development, for example. Let's say I have software developers who are not familiar with secure coding, for example, then you know that could potentially then lead to vulnerabilities which otherwise wouldn't have been present. So ensuring competence across the board is important. There's a lot we can say about that, but at this level, this is what clause 7.2 is asking us to think about. + +Now that's slightly different to **awareness**, which is a much more broad thing. So when we look at clause 7.3 it says: the persons doing work under the organization's control, so that can be both employees, freelancers, contractors or even suppliers, shall be aware of the information security policy, their contribution to the effectiveness of the ISMS, and the implications of not conforming to the requirements of the ISMS. Now many organizations tackle this by having quite a broad awareness program for both new employees joining the organization and for people there longer term. So you might see things like e-learning activities, you know, awareness training sessions and so forth. + +But what we're looking for, is what efforts are the organization making to really drive the right security behaviors in the organization in the longer term. That might be about building a strong security culture where people think about security almost as just being a normal part of their duties, not as a sort of a separate discipline. As an auditor, for example, I will be looking at training records, and I'll choose a sample of employees and interview those employees during the audit. Not to catch them out or anything like that, but just to understand what are they aware of when it comes to security. Do they recall what training they had? Do they you know what do they think the most significant security issues are often just those kind of questions could soon tell you what levels of awareness are generally in place in the organization. + +Now another thing that clause 7 focuses on is this topic of **communication**. So let's think about what we said in clause 4. We said in clause 4 that the organization should identify its interested parties, both internal and external. But it's not just a case of identifying them. Obviously to run an effective management system the organization, and those running the management system, would need to have regular communication with different interested parties. And there might be different reasons for that regular communication. It might be about giving interested parties an assurance when it comes to security. So for example customers, we might want to keep customers appraised of what we're doing to give them or instill and maintain confidence. It might be about management support. We might be regularly communicating with our top management in order to get the ongoing buy-in and commitment that we need. Or we might be regularly talking to users in order to encourage the right behaviors. So for every interested party, there might be different reasons and purpose for communicating. + +What the standard says is we should essentially come up with a plan laying out on what we're going to communicate to who, so what kind of topics, how frequently we're going to do that, and the methods we're going to use. Because the way in which we communicate may need to vary depending on the interested party's level, their purpose, and what they need to know. So there should be a strong communication strategy and plan. And obviously from an audit point of view, I would want to see that plan, I'd want to see the examples of communication. And what are the organization then doing with that? In other words, is the communication effective? So it's great, for example, to send a report to top management every month on how we're performing from a security point of view, but what impact is that having? In other words, is that leading to the desired effect of, in this case, let's say more buy-in? What sort of feedback are they the organization getting and are they adjusting it? What we're looking for is that ongoing communication. + +And one thing I should maybe just add to this is that the examples I've given there might seem a bit one way, like I'm talking about the organization talking to its interested parties. Obviously communication comes back the other way as well, and so how does the organization manage that? So for example, let's say an employee in the organization has a question about security and wants some help, how can they go about seeking that? How responsive is the organization to that? Because if you could see gaps there, that could be a potential problem. If people are coming for advice and not receiving it very quickly, it might happen happen the next time round that they say well I won't bother I'll just skip that particular step. So we're looking for the overall communication plan and approach. + +Now in any ISO standard, any management system standard, of course, there is always talk about **documentation** or **documented information** as ISO would put it. And I've heard sort of some myths if you like about ISO standards when it comes to things like this. I've heard people saying things like, well all ISO standards are, are documenting what you do, or: you need to create loads of documents in order to meet the requirements of an ISO standard. So two things to tell you there. It's not just about documenting what you do. Because ultimately you could be documenting things that you do that aren't particularly very good. So the point is it's about *creating documentation that's needed to support the organization in doing tasks well and doing tasks in a consistent manner*. Also it's not true to say that you need to you need to create mountains of documents for the sake of it. So let's have a look atwhat the standard actually says, and then we can work this out. + +So it says the following in clause 7.5.1: The organization's information security management system shall include documented information required by this document. So basically that's the documented information required by the standard. So it is true that there are some minimum documents that need to be created when implementing ISO 27001, but there's not a huge amount of them. The main documents, I won't necessarily be able to recite every single one of them, but the main ones that spring to mind here are things like the scope. Of course, the scope needs to be documented. The information security policy, the risk management process, the statement of applicability, the resource requirements. These kind of things you would expect to see, the internal audit process, you'd expect to see those documented. And how do you know if something is required? Well when you read the standard, if you see the words this *shall be available as documented information*, that's point A. But the myth bit about creating lots of documents is the bit in B, point B, 7.5.1 B, which says *documented information determined by the organization as being necessary for the effectiveness of the ISMS*. So what you've sometimes see, and I've certainly witnessed in real life, is consultants going to an organization, looking up clauses 4 to 10, all 93 security controls, and write a document for each one. Well there you are, here's a huge bunch of documents for you and guess what happens? Those documents don't get read. You might end up calling them shelfware. You might have heard of that term before, just documentation that isn't looked at. So that's not what the target is here. + +We've got to determine what documentation we need. So if we're in a complex environment with a complex task, let's say a system administration task that we need the system administrators to do consistently in detail, then of course something like that you'd expect to see a detailed document with step-by-step instructions. Maybe for simpler tasks, lower risk tasks, where we have a highly competent workforce, the level of documentation won't be quite the same. An example from an audit I actually give when I teach this course is the following one. I did an audit of an IT company that had 15 employees. And in this audit I spoke to the owner of the company, and we were talking about HR security and I asked him about the leavers process. So I said, can you take me through what happens when somebody leaves, and how do you ensure that you remove all system access when they've gone? And he said, well, being honest with you, in the last five years I've only had two people leave the organization, but here's what we do, and he talked me through it. And I checked all the various systems, the Active Directory, a few other applications. I could see that those accounts had been removed. I'd seen an email to the administrator confirming this. So I was happy that the two individuals we're speaking about had had their access revoked. So I asked him, I said, if you're not here, given that you know the process, well what would happen then? And he explained how his colleague also would cover this and I interviewed that colleague separately. So long story short, by the time I'd done those interviews and looked at that evidence, I was satisfied that they had managed those levers effectively. But I asked the classic question, which is, you've verbally explained this procedure to me and I've seen evidence that it's happening. But have you documented it? And the answer that came back was no we haven't. We haven't written a document. And then I have a decision to make as an auditor. Well the standard doesn't actually say that there shall be a document. So in that organization I took the view that what I've seen is effective. I did raise an opportunity for improvement and I said to them, if you grow and there's more people involved then this is more complex. You probably ought to document this, but certainly it's not a mandatory requirement. Now had I have been told that story in a company with a a thousand or two thousand employees, I would have taken a very different view because the lack of documentation could mean that the process would be ineffective. + +So this is the point about point B. Every organization is different and especially as an auditor you just need to think about the proportionality. Documentation should always add value, not just be there for the sake of ticking boxes. + +Now one thing that is important for the documentation that is created, whether that's created in Word documents, on wiki pages, in products like Confluence or wherever it might be is that the organization has what we call a **document life cycle**. There should be some rules that specify how documents are **created** and who can create them. Maybe some levels of authorization There should be some information about how the organization will **identify** those documents: is it a policy, is it a procedure, including the **classification and security level**. So in other words, is this a document that is limited to internal use only, limited to a certain audience? Does it have a certain level of sensitivity? If the answer to those are yes, obviously I would expect to see security handling rules in an audit, we'd be testing that as well to see if those security rules have been followed. What are the rules about **modifying** documents? So do we have access restrictions to stop people simply making changes to documented information unless they're authorized? And I'd want to understand the **approval** process. + +Now approval processes may differ. A corporate policy may need a different approval channel to a local procedure in a given department. But how does that work? I'd also want to understand how documents are actually distributed. + +It's one thing to have good quality documents, but how do the people who are meant to use them know that they're there? So how do we **share** them with people. And of course we can test that in real life during an audit by looking at the documentation people are using, asking them questions about it. So a recent audit I did, for example, the organization had launched a new AI policy just a few weeks before the audit. So when I did my awareness interviews, I asked a number of people, I just said, have you seen the AI policy? Where would you find it? And I wasn't grilling them on their knowledge, it was more about could they find it, did they know it existed, you know, could they consult it if they needed it. + +How does the organization check whether the documents are being **used** adequately or not? Again, in other words, are people actually referring to them? Are they actually following what's stated in these documents? That can be discovered through things like monitoring and metrics, through the internal audit process perhaps. These are all relevant points. + +And then the last two bits, **archiving** and **disposal**. Depending on the information or data retention policies of the organization, there might be a point in time when organizations archive documents, that is to say keep them, but just store them for the longer term. And there may be a point when they actually decide to destroy or dispose of those documents. Again, I'd want to understand what the rules are about that. From an archiving point of view, are there any security rules? How are those archives protected? + +Now thankfully the vast majority of documentation today is electronic and there are electronic archiving solutions. Back when we had a lot of paper documents, I'd have to concern myself with physical archive storage, for example, and how secure or well protected that might be. And then disposal, the way in which data is destroyed, might vary depending on sensitivity. + +So there's no right or wrongs for all of these, but there is an expectation that all of these points can be answered. Now typically that would be answered in a document management policy. So an organization really ought to have a **document management policy** that answers all of these. The last point I want to make on this is if an organization who is implementing ISO 27001 has another management system in place, let's say 9001 for quality, it might be that they already have these processes in place and could essentially reuse them because all ISO management systems have the same demands so that's always something to explore as well. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S05.5-Overview-of-ISO-27001-requirements.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S05.5-Overview-of-ISO-27001-requirements.md index 667bf21..e6ecb3e 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S05.5-Overview-of-ISO-27001-requirements.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S05.5-Overview-of-ISO-27001-requirements.md @@ -13,6 +13,7 @@ isotags: - C.10.1 - C.10.2 status: active +processed: true --- # S05.5 Overview of ISO 27001 requirements @@ -22,4 +23,51 @@ This session completes the overview of ISO 27001 requirements, covering clauses ## Transcription -Let's take a look at the next clause, clause eight operation. And that has three parts to it, operational planning and control, information security risk assessment, and information security risk treatment. So let's have a look at operational planning and controls. So what this is about in clause 8. 1 is we've said that when we establish an ISMS we'll implement security controls from Annex A and various processes. But of course an organization should think very carefully about how to roll out those controls and processes so that when they are implemented, they're implemented effectively in what I would call a sustainable manner. In other words, they're there to last. speak. So this means thinking through how those processes will be defined by having clear criteria to say this is what what success looks like and having a level of planning. So for example, let's imagine an organization was going to deploy, let's say, a log management solution to monitor and that they're going to use to capture logs, maybe monitor for suspension. Well what you'd expect is there'd be a series of um series of things done. The organization would specify the need for such a lock management. management system, you know what sort of functionality should it have, what sort of events and logs should it capture, what sort of capacity it should have, all of these things. It would specify some criteria before actually making that decision. The organization would specify how that's going to be used, you know, what's the processes to be followed to review those logs. how does that process link to the incident management process of the organisation and so on. They'd probably want to think about the resource requirements to operate that control effectively. Do they need a dedicated member of staff or a team. They might want to think about whether there's any training requirements that are needed before it's rolled out. how that might be communicated to the wider organization. So there'd be all these things essentially thought about before the deployment. And that's what we mean by operational planning and control. So that we have a confidence that what we roll out is going to be effective. Now there is an interesting point in here as well, which says that the organisation shall ensure that externally provided processes, products and services that are relevant to the ISMS are controlled. What this means is is if the organisation is depending on let's say a service provider or some some um process from the outside that this is still managed. So for example if we said right we're going to use a a SaaS platform, a software as a service platform to let's say for let's say for risk management. Well we're not just going to just buy the platform and just start using it even if we argue that the the actual tool is provided by a SAS provider We as the purchaser of that, the implementer of ISO 27001, would still need to make sure that that service provider meets our requirements you know offers the functionality that's required, offers the level of service, maybe availability, the level of security that's required. And it would still be part of the ISMS to monitor the activities of those kind of service providers or outsourcers. There is a separate ISO standard document that might help here which is not security specific but it does look on look at um outsourcing and it's called ISO 37500 it's called guidance on outsourcing Certainly isn't a requirement to look at that for this particular aspect, but it might help in giving you some guidance on how to have proper governance and oversight of um organizations like service providers and outsourcers. So that's what 8. 1 is speaking about. Now you might when you've looked at the beginning of this section have thought, what's this about information security assessment and risk treatment? Surely we've already spoken about that and looked at it in clause six And that's true. And this isn't telling us to do anything different, but essentially what we're arguing is you implement your risk management processes as per clause six. essentially 612 and 613 and then you in clause 8 the do phase of the plan due checkup cycle you execute those things So that this is confirming that those risk assessments are actually being carried out, that the risk treatment plans are actually being implemented. So essentially you're moving from the plan stage of risk assessment and treatment in six to the actually doing it in cloud. So there's nothing different here other than we have to execute the stuff we plan to execute in clause six. And that then feeds into implementing controls and planning them properly, which is what 8. 1 is talking about Now when we think about an ISMS and going through a series of steps, at some point when we've implemented controls, the organization needs to be checking whether those controls work effectively. And that's what clause nine tackles. Clause 9 is performance evaluation broken down into three areas, the monitoring, measurement, analysis and evaluation, basically metrics. Internal audit and management review. So let's just have a look at those and what they mean and some of the key points. So clause 9. 1 talks about this concept of monitoring, measurement, analysis and evaluation. What that means in a practical sense is deciding what parts of the ISMS the organization would like to monitor on a regular basis in order to identify its performance essentially and to evaluate performance. Now the ISO standard itself does not say which controls or which processes to monitor and what performance evaluation targets to have So what we typically say here that's up to the organisation to select. But the important point is we don't expect an organization to take clauses 4 to 10 and take every control in the annex and try and have a measurement or performance evaluation for everyone. Instead we expect them to focus on key things. And the big one for me would be security objectives. So an organization should be looking at what security objectives it has and then asking the question how will it measure and check whether those objectives are being fulfilled. That's the primary priority here. Other things an organization might want to measure regularly might be things like legal and regulatory compliance. It might be about measuring controls that are implemented to deal with significant risks. Because obviously if those controls aren't working as expected, then risk may be higher than it should be. And what we want to see is not just a list of things that will be measured, but some information on how frequently those measurements will take place. um how practical they are, you know, who's doing it and so forth and what action is going to be taken in response. Now when it comes to performance evaluation, in other words deciding based on these measures what good looks like. The ISO standard doesn't say this to us. So it doesn't say, for example, with patch latency, how long it takes to apply patches that we shall do that in five days or ten days or something like that. The organisation will set its own targets. Those targets might come from contractual obligations, legal obligations. obligations and other standards or it might come through its own setting its own KPIs. So what we're looking at when I say KPIs key performance indicators when an organization designs and implements an ISMS it will want to identify early on what those key performance indicators are. From an audit point of view we want to make sure that the organisation is checking those things regularly. Now the other thing an organization should be doing to validate whether its ISMS is working effectively is to be conducting its own internal audits. So when we deliver this course, we're talking about this from an external auditor's perspective. That being said, everything we teach in this course can be applied by people who are doing internal audits as well. So if you're an internal auditor Everything you learn here you can still apply. But basically the standard requires that internal audits are performed at what it says regular intervals And the purpose of internal audits is to validate whether the ISMS meets the requirements of ISO 27001, but also to validate whether the ISMS is actually effectively implemented, maintained, is it set up in a way to help the organisation fulfil its objectives and so forth. Now there's a few points to make about internal audit that are important. As we'll describe in audit principles Independence is a very important part of audit. Now, internal auditors aren't necessarily independent of the organisation, but they still need to be independent of the work they're assessing. So we need to make sure that whoever's working as an internal auditor is not auditing areas under their control. They're not essentially auditing their own work. We need to make sure those auditors are in a position wherever they sit in the organization. to be able to openly make honest observations based on the evidence that they see. We also want to validate that internal auditors have the necessary competence We mentioned competence in clause 7. 2. We will go through a little bit later on the specific competence requirements for auditors. We need to make sure the internal auditors have those skills to perform them. And we also need to make sure that the organisation doesn't just do a one-off audit, but they have what we call an audit programme in place. An audit programme means there'll be a series of audits over a period of time. In some organizations, rather than doing sort of one ISO 27001 internal audit every year, they might spread that work out over a period of time, perhaps doing deeper dive audits into particularly critical areas. A quick example is I work with a software as a service provider who they have quite a unique product. They develop all the software themselves and therefore one of the critical areas is secure software development. So their internal audit programme includes many reviews of software development practices, possibly more reviews in that area than others because they see that as a critical area to be more closely monitored. So some of those audits focus regularly on that as part of a bigger audit program. And then in clause 9 we also have what's called the management review. So the management review is the opportunity for top management, which we talked about earlier on. It's their opportunity to see what is happening with the management system. So a management review does not have to be a meeting called management review, although that can happen that way, but at regular intervals top management need to get together, whether it's physically, online, or wherever it might be. to take a look at the management system. Now usually this would be facilitated by a security manager or a CISA or whoever's sort of overseeing the ISMS And in management review, it's important to point out is usually looking at strategic aspects. In other words, does the management system meet the requirements of the organisation? Is it aligned to objectives? Does the scope of the management system need to change in any way? Does it need to be updated to respond to risk or legal and regulatory requirements? And some people ask, well, what should be on the agenda in these management reviews? You know, what should we talk about and what should we cover? Well the answer to that is I don't need to give you an agenda because you've actually got it here as you can see on the slide, A through G, the management review shall include consideration of all of these points. Whenever I conduct an audit we always comment on whether all of those points have been covered. The point about a management review though is it's not just a meeting where these things get discussed. It is a place where decisions can be made about how we continue to operate the ISMS going forward. So management review should be an effective program for top management to have an influence and an oversight of the management system Now, given that those three things we've talked about are all to do with checking how well the management system is actually working. Clause 10 then is focused on what we do in response to those things or what the organization does in response to those things. So there are two things in clause 10. 10. 1, continual improvement. and 10. 2 non-conformity and corrective action. So if we talk generally about continual improvement, 10. 1 This is one of the requirements which basically has a one, well almost like a one-paragraph requirement, which basically says the organization shall continually improve the suitability, adequacy and effectiveness of the ISMS. That's literally all it says. So suitability, is the ISMS fit for purpose? Adequacy, is it meeting the minimum requirements that need to be met by the organisation? and effectiveness, is it working to the organization's needs? So the issue with this as an auditor is you might ask well how do you even check this? And there's two things. If this is an initial audit, that is to say this is the first time we've ever been to see the organisation and the ISMS implementation is relatively new. There might not be lots of different improvements that the organisation can point at to prove this is in place, but what they could point at is how they're going to measure and what mechanisms they've got in place to respond. As an example, I did a recent audit. and the chief information security officer showed me an analysis that the organisation had done. So they took all these areas of security, they called them capability areas, like incident management, education and awareness, risk management. and so on. And for each area that identified where they currently were in terms of maturity. And basically the seesaw had set. a strategy for the year ahead saying these are the improvements we expect to see and every month they were checking their metrics to see are they on the right track So even if not everything is in place that they want to have in place, they're demonstrating a culture of continual improvement. Over time, when an organisation gets certified, of course, every year, as we'll get to, we do what's called surveillance audits, and in a surveillance audit we're always looking for examples of continual improvement. Now this is slightly different to clause 10. 2, non-conformity and corrective action. So in brief in non-conformity is the non-fulfilment of a requirement. So in other words when a requirement of the standard or requirement of the organisation's own requirements is not being met and the organisation know that it's not being met, whether they've detected that through metrics an incident or through the audit process, clause 10. 2 requires that action is taken to address it and to prevent a recurrence in this case. So this is where we just need to quickly draw a distinction between a correction and a corrective action. Both of them are important but they're both slightly different. And this is an audit example I can give. So I did an audit of an organization and we found that on their network there were a number of devices that had not had their software patches applied for over 12 months. And the organization openly said, look, this is an oversight, this is a mistake. So it wasn't a risk-based decision. They basically had a number of flaws and problems. And they said, ah, well what we'll do immediately is we'll apply all the missing patches. will pretty much do that straight away. Now that's obviously a good thing. I'm not going to discourage that. That's what we call a correction. They're taking action to address the symptoms of a particular problem. But the question is, what gave rise to these machines having missing patches for over 12 months in the first place? And what's the chances when I come back in three, six, twelve months time, that I'm going to find the same problem again? So they need to do some kind of root cause analysis to get to the bottom of it and then take action to prevent the recurrence. And in their case, they'd found a number of problems with their process. They'd update in response they updated their patch management process. They did a lot more close monitoring. They made somebody particularly responsible for that process. And eventually that addressed the problem and stopped it recurring. And what we've described in the latter part of that example is a corrective action plan And that's what this slide here is showing you with the steps involved in a corrective action process. So in any case where a non-conformity is detected. We would expect an organization to describe that non-conformity, conduct a root cause analysis, maybe they've got a root cause analysis process. An organization I spoke to recently about this demonstrated an example to me called the five wise analysis which basically asks you to as it says look at a problem through multiple angles and at least five times ask each uh for each answer to each question we keep asking why until we get to a root cause. An organization needs to evaluate and select solutions to that problem but and then implement them, but not just implement the solution and assume it's worked. they will monitor for a period of time has that action worked. So like that organization I was just telling you about with their patch management, they didn't just rewrite the process and say, well, let's close the non conformity, they monitored that for a period of time and over several months they could see that they were no we were no longer falling behind on their patch management cycles So in summary what we've tried to do in this section is give you sort of an overview of an ISMS. by doing a bit of a helicopter tour of clauses 4 to 10. All of those are worthy of much more discussion and please be assured we will be digging into some of these a lot more as we go through here But all of clauses 4 to 10 are mandatory in order to achieve ISO 2701 certification Based on risk, an organization will then choose which controls from Annex A to implement as well, and they can decide which are applicable and which are not. And ultimately at the heart of ISO 27001 is risk management. So what I would say is the part clause six where we talk about Identifying, analysing, evaluating and treating risk is fundamental because that then influences everything else that we see in clauses four to ten. \ No newline at end of file +Let's take a look at the next clause, clause 8: **operation**. And that has three parts to it, operational planning and control, information security risk assessment, and information security risk treatment. + +So let's have a look at **operational planning and control**. So what this is about in clause 8.1 is, we've said that when we establish an ISMS we'll implement security controls from Annex A and various processes. But of course an organization should think very carefully about how to roll out those controls and processes, so that when they are implemented, they're implemented effectively in what I would call a sustainable manner. In other words, they're there to last. So this means thinking through how those processes will be defined, by having clear criteria to say this is what what success looks like, and having a level of planning. So for example, let's imagine an organization was going to deploy, let's say, a log management solution to monitor, and that they're going to use to capture logs, maybe monitor for suspicious activity. Well what you'd expect is there'd be a series of things done. The organization would specify the need for such a log management system, what sort of functionality should it have, what sort of events and logs should it capture, what sort of capacity it should have, all of these things. It would specify some criteria before actually making that decision. The organization would specify how it's going to be used, what the processes are to be followed to review those logs, how does that process link to the incident management process, and so on. They'd probably want to think about the resource requirements to operate that control effectively. Do they need a dedicated member of staff or a team. They might want to think about whether there's any training requirements that are needed before it's rolled out. How that might be communicated to the wider organization. So there'd be all these things essentially to be thought about before the deployment. And that's what we mean by operational planning and control. So that we have a confidence that what we roll out is going to be effective. + +Now there is an interesting point in here as well, which says that the organization shall ensure that externally provided processes, products and services that are relevant to the ISMS, are controlled. What this means is is if the organization is depending on a service provider or some process from the outside, that this is still managed. So for example if we said we're going to use a SaaS platform for risk management, we as the purchaser of that, the implementer of ISO 27001, would still need to make sure that that service provider meets our requirements: the functionality that's required, the level of service, maybe availability, the level of security. And it would still be part of the ISMS to monitor the activities of those kind of service providers or outsourcers. There is a separate ISO guidance document on outsourcing, ISO 37500, that might help in giving you some guidance on how to have proper governance and oversight of organizations like service providers and outsourcers. So that's what 8.1 is speaking about. + +Now you might when you've looked at the beginning of this section have thought, what's this about information security assessment and risk treatment? Surely we've already spoken about that and looked at it in clause 6. And that's true. And this isn't telling us to do anything different, but essentially what we're arguing is, if you implement your risk management processes as per clause 6, essentially 6.1.2 and 6.1.3, and then in clause 8 you have the Do phase of the plan-do-check-act cycle, you execute those things. So than this is confirming that those risk assessments are actually being carried out, that the risk treatment plans are actually being implemented. + +So essentially you're moving from the Plan stage of risk assessment and treatment in clause 6, to the actually doing it in clause 8. So there's nothing different here other than we have to execute the stuff we plan to execute in clause 6. And that then feeds into implementing controls and planning them properly, which is what 8.1 is talking about. + +Now when we think about an ISMS and going through a series of steps, at some point when we've implemented controls, the organization needs to be checking whether those controls work effectively. And that's what clause 9 tackles. Clause 9 is **performance evaluation** broken down into three areas: metrics ('monitoring, measurement, analysis and evaluation'), the internal audit, and the management review. So let's just have a look at those and what they mean and some of the key points. + +So clause 9.1 talks about this concept of **monitoring, measurement, analysis and evaluation**. What that means in a practical sense is deciding what parts of the ISMS the organization would like to monitor on a regular basis, in order to identify its performance and to evaluate performance. Now the ISO standard itself does not say which controls or which processes to monitor, and what performance evaluation targets to have So what we typically say here that's up to the organization to select. But the important point is we don't expect an organization to take clauses 4 to 10 and take every control in the annex and try and have a measurement or performance evaluation for everyone. Instead we expect them to **focus on key things**. And the big one for me would be security objectives. So an organization should be looking at what security objectives it has, and then asking the question how will it measure and check whether those objectives are being fulfilled. That's the primary priority here. + +Other things an organization might want to measure regularly might be things like legal and regulatory compliance. It might be about measuring controls that are implemented to deal with **significant risks**. Because obviously if those controls aren't working as expected, then risk may be higher than it should be. And what we want to see is not just a list of things that will be measured, but some information on how frequently those measurements will take place, how practical they are, who's doing it, and what action is going to be taken in response. + +Now when it comes to performance evaluation, you need to decide what good looks like. The ISO standard doesn't say this to us. So it doesn't say, for example, with patch latency, how long it takes to apply patches that we shall do that in five days or ten days or something like that. The organization will set its own targets, or **performance indicators**. Those targets might come from contractual obligations, legal obligations, and other standards, or it might come through setting its own KPIs (key performance indicators). When an organization designs and implements an ISMS, it will want to identify early on what those key performance indicators are. From an audit point of view, we want to make sure that the organization is checking those things regularly. + +Now the other thing an organization should be doing to validate whether its ISMS is working effectively, is to be conducting its own **internal audits**. So when we deliver this course, we're talking about this from an external auditor's perspective. That being said, everything we teach in this course can be applied by people who are doing internal audits as well. So if you're an internal auditor, everything you learn here you can still apply. But basically the standard requires that internal audits are performed at what it says regular intervals. And the purpose of internal audits is to validate whether the ISMS meets the requirements of ISO 27001, but also to validate whether the ISMS is actually effectively implemented, maintained, is set up in a way to help the organization fulfill its objectives, and so forth. + +Now there's a few points to make about internal audits that are important. As we'll describe in audit principles, **independence** is a very important part of audit. Now, internal auditors aren't necessarily independent of the organization, but they still need to be independent of the work they're assessing. So we need to make sure that whoever's working as an internal auditor, is not auditing areas under their control. They're not, essentially, auditing their own work. We need to make sure those auditors are in a position, wherever they sit in the organization, to be able to openly make honest observations based on the evidence that they see. We also want to validate that internal auditors have the necessary **competence**. We mentioned competence in clause 7.2. We will go through a little bit later on the specific competence requirements for auditors. We need to make sure the internal auditors have those skills to perform them. And we also need to make sure that the organization doesn't just do a one-off audit, but they have what we call an **audit programme** in place. An audit programme means there'll be a series of audits over a period of time. In some organizations, rather than doing one ISO 27001 internal audit every year, they might spread that work out over a period of time, perhaps doing deeper dive audits into particularly critical areas. A quick example is, I work with a software as a service provider who have quite a unique product. They develop all the software themselves and therefore one of the critical areas is secure software development. So their internal audit programme includes many reviews of software development practices, possibly more reviews in that area than others because they see that as a critical area to be more closely monitored. So some of those audits focus regularly on that as part of a bigger audit program. + +And then in clause 9 we also have what's called the **management review**. So the management review is the opportunity for top management, which we talked about earlier on, to see what is happening with the management system. So a management review does not have to be a meeting called 'management review', although that can happen that way, but at regular intervals top management need to get together, whether it's physically, online, or wherever it might be, to take a look at the management system. Now usually this would be facilitated by a security manager or a CISO or whoever's sort of overseeing the ISMS. And in management review, we're usually looking at strategic aspects. In other words, does the management system meet the requirements of the organization? Is it aligned to objectives? Does the scope of the management system need to change in any way? Does it need to be updated to respond to risk or legal and regulatory requirements? + +And some people ask, well, what should be on the agenda in these management reviews? You know, what should we talk about and what should we cover? Well the answer to that is I don't need to give you an agenda because you've actually got it here on the slide. + +![](CleanShot%202026-06-06%20at%2020.00.09.png) + +The management review shall include consideration of all of these points. Whenever I conduct an audit we always comment on whether all of those points have been covered. The point about a management review though is it's not just a meeting where these things get discussed. It is a place where **decisions** can be made about how we continue to operate the ISMS going forward. So management review should be an effective program for top management to have an influence and an oversight of the management system. + +Now, given that those three things we've talked about are all to do with checking how well the management system is actually working. Clause 10 then, **Improvement**, is focused on what we do in response to those things, or what the organization does in response to those things. So there are two things in clause 10: 10.1, continual improvement, and 10.2 non-conformity and corrective action. + +Clause 10.1, **continual improvement**, is one of those requirements which basically has a one-paragraph requirement, which basically says the organization shall continually improve the suitability, adequacy and effectiveness of the ISMS. **Suitability**, is the ISMS fit for purpose? **Adequacy**, is it meeting the minimum requirements that need to be met by the organization? And **effectiveness**, is it working to the organization's needs? So the issue with this as an auditor is you might ask well how do you even check this? And there's two things. If this is an initial audit, that is to say this is the first time we've ever been to see the organization and the ISMS implementation is relatively new. There might not be lots of different improvements that the organization can point at to prove this is in place, but what they could point at is how they're going to measure and what mechanisms they've got in place to respond. + +As an example, I did a recent audit, and the chief information security officer showed me an analysis that the organization had done. So they took all these areas of security, they called them capability areas, like incident management, education and awareness, risk management, and so on. And for each area they identified where they currently were in terms of maturity. And basically the CISO had set a strategy for the year ahead, saying these are the improvements we expect to see, and every month they were checking their metrics to see are they on the right track. So even if not everything is in place that they want to have in place, they're demonstrating a culture of continual improvement. + +Over time, when an organization gets certified, of course, every year, as we'll get to, we do what's called surveillance audits, and in a surveillance audit we're always looking for examples of continual improvement. + +Now this is slightly different to clause 10.2, **non-conformity and corrective action**. So in brief in non-conformity is the non-fulfillment of a requirement. So in other words when a requirement of the standard or requirement of the organization's own requirements is not being met, and the organization knows that it's not being met, whether they've detected that through metrics, an incident, or through the audit process, clause 10.2 requires that action is taken to address it, and to prevent a recurrence in this case. So this is where we just need to quickly draw a distinction between a **correction**, and a **corrective action.** Both of them are important, but they're both slightly different. + +![](CleanShot%202026-06-06%20at%2020.10.02.png) + +And this is an audit example I can give. So I did an audit of an organization and we found that on their network there were a number of devices that had not had their software patches applied for over 12 months. And the organization openly said, look, this is an oversight, this is a mistake. So it wasn't a risk-based decision. They basically had a number of flaws and problems. And they said, ah, well what we'll do immediately is we'll apply all the missing patches. We'll pretty much do that straight away. Now that's obviously a good thing. I'm not going to discourage that. That's what we call a **correction:** they're taking action to address the symptoms of a particular problem. + +But the question is, what gave rise to these machines having missing patches for over 12 months in the first place? And what's the chances when I come back in three, six, twelve months time, that I'm going to find the same problem again? So they need to do some kind of root cause analysis to get to the bottom of it, and then take action to prevent the recurrence. And in their case, they'd found a number of problems with their process. In response they updated their patch management process. They did a lot more close monitoring. They made somebody particularly responsible for that process. And eventually that addressed the problem and stopped it recurring. And what we've described in the latter part of that example is a **corrective action plan.** And that's what this slide here is showing you, with the steps involved in a corrective action process. So in any case where a non-conformity is detected, or **identified,** we would expect an organization to **describe** that non-conformity, and conduct a **root cause analysis**, preferably through a root cause analysis process. An organization I spoke to recently about this demonstrated an example to me called the Five Why's Analysis, which basically asks you to look at a problem through multiple angles, and at least five times keep asking Why? until we get to a root cause. +An organization needs to **evaluate** and **select solutions** to that problem, **implement** them, **follow-up** by monitoring for a period of time if that action has worked, and **review** the effectiveness of the corrective action. So like that organization I was just telling you about with their patch management, they didn't just rewrite the process and say, well, let's close the non conformity, they monitored that for a period of time and over several months they could see that they were no we were no longer falling behind on their patch management cycles. + +So in summary what we've tried to do in this section, is give you sort of an overview of an ISMS, by doing a bit of a helicopter tour of clauses 4 to 10. All of those are worthy of much more discussion, and please be assured we will be digging into some of these a lot more as we go through here. But all of clauses 4 to 10 are mandatory in order to achieve ISO 2701 certification. Based on risk, an organization will then choose which controls from Annex A to implement as well, and they can decide which are applicable and which are not. And ultimately at the heart of ISO 27001 is **risk management**. So what I would say is the part of Clause 6, where we talked about identifying, analyzing, evaluating and treating risk, is fundamental, because that then influences everything else that we see in clauses 4 to 10. \ No newline at end of file diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S06.1-Fundamental-audit-concepts-and-principles.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S06.1-Fundamental-audit-concepts-and-principles.md index 07959c9..118e86a 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S06.1-Fundamental-audit-concepts-and-principles.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S06.1-Fundamental-audit-concepts-and-principles.md @@ -7,6 +7,7 @@ tags: - PECB-LA isotags: [] status: active +processed: false --- # S06.1 Fundamental audit concepts and principles diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S06.2-Fundamental-audit-concepts-and-principles.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S06.2-Fundamental-audit-concepts-and-principles.md index a317bf1..7253501 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S06.2-Fundamental-audit-concepts-and-principles.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S06.2-Fundamental-audit-concepts-and-principles.md @@ -7,6 +7,7 @@ tags: - PECB-LA isotags: [] status: active +processed: false --- # S06.2 Fundamental audit concepts and principles diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S06.3-Fundamental-audit-concepts-and-principles.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S06.3-Fundamental-audit-concepts-and-principles.md index 7e1f68f..4eec584 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S06.3-Fundamental-audit-concepts-and-principles.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S06.3-Fundamental-audit-concepts-and-principles.md @@ -7,6 +7,7 @@ tags: - PECB-LA isotags: [] status: active +processed: false --- # S06.3 Fundamental audit concepts and principles diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S06.4-Fundamental-audit-concepts-and-principles.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S06.4-Fundamental-audit-concepts-and-principles.md index d967a07..1eab2c1 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S06.4-Fundamental-audit-concepts-and-principles.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S06.4-Fundamental-audit-concepts-and-principles.md @@ -7,6 +7,7 @@ tags: - PECB-LA isotags: [] status: active +processed: false --- # S06.4 Fundamental audit concepts and principles diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S06.5-Fundamental-audit-concepts-and-principles.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S06.5-Fundamental-audit-concepts-and-principles.md index 80ea983..45c1598 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S06.5-Fundamental-audit-concepts-and-principles.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S06.5-Fundamental-audit-concepts-and-principles.md @@ -7,6 +7,7 @@ tags: - PECB-LA isotags: [] status: active +processed: false --- # S06.5 Fundamental audit concepts and principles diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S06.6-Fundamental-audit-concepts-and-principles.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S06.6-Fundamental-audit-concepts-and-principles.md index f48dd72..3de9f7d 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S06.6-Fundamental-audit-concepts-and-principles.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S06.6-Fundamental-audit-concepts-and-principles.md @@ -7,6 +7,7 @@ tags: - PECB-LA isotags: [] status: active +processed: false --- # S06.6 Fundamental audit concepts and principles diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S07.1-The-impact-of-trends-and-technology-in-auditing.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S07.1-The-impact-of-trends-and-technology-in-auditing.md index ff05c98..c290794 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S07.1-The-impact-of-trends-and-technology-in-auditing.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S07.1-The-impact-of-trends-and-technology-in-auditing.md @@ -7,6 +7,7 @@ tags: - PECB-LA isotags: [] status: active +processed: false --- # S07.1 The impact of trends and technology in auditing diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S07.2-The-impact-of-trends-and-technology-in-auditing.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S07.2-The-impact-of-trends-and-technology-in-auditing.md index b2e59fa..b777515 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S07.2-The-impact-of-trends-and-technology-in-auditing.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S07.2-The-impact-of-trends-and-technology-in-auditing.md @@ -7,6 +7,7 @@ tags: - PECB-LA isotags: [] status: active +processed: false --- # S07.2 The impact of trends and technology in auditing diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S08.1-Evidence-based-auditing.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S08.1-Evidence-based-auditing.md index 4dafec2..8b8d13f 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S08.1-Evidence-based-auditing.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S08.1-Evidence-based-auditing.md @@ -7,6 +7,7 @@ tags: - PECB-LA isotags: [] status: active +processed: false --- # S08.1 Evidence based auditing diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S08.2-Evidence-based-auditing.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S08.2-Evidence-based-auditing.md index a3a31eb..8369dd6 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S08.2-Evidence-based-auditing.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S08.2-Evidence-based-auditing.md @@ -7,6 +7,7 @@ tags: - PECB-LA isotags: [] status: active +processed: false --- # S08.2 Evidence based auditing diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S09-Risk-based-audit.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S09-Risk-based-audit.md index e074fe8..075a459 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S09-Risk-based-audit.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S09-Risk-based-audit.md @@ -7,6 +7,7 @@ tags: - PECB-LA isotags: [] status: active +processed: false --- # S09 Risk based audit diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S10.1-Initiation-of-the-audit-process.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S10.1-Initiation-of-the-audit-process.md index 5ff76e8..cd66af9 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S10.1-Initiation-of-the-audit-process.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S10.1-Initiation-of-the-audit-process.md @@ -7,6 +7,7 @@ tags: - PECB-LA isotags: [] status: active +processed: false --- # S10.1 Initiation of the audit process diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S10.2-Initiation-of-the-audit-process.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S10.2-Initiation-of-the-audit-process.md index 8172fbe..17e4c7c 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S10.2-Initiation-of-the-audit-process.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S10.2-Initiation-of-the-audit-process.md @@ -7,6 +7,7 @@ tags: - PECB-LA isotags: [] status: active +processed: false --- # S10.2 Initiation of the audit process diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S10.3-Initiation-of-the-audit-process.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S10.3-Initiation-of-the-audit-process.md index 352fdc6..0b29e0f 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S10.3-Initiation-of-the-audit-process.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S10.3-Initiation-of-the-audit-process.md @@ -7,6 +7,7 @@ tags: - PECB-LA isotags: [] status: active +processed: false --- # S10.3 Initiation of the audit process diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S11.1-Stage-1-audit.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S11.1-Stage-1-audit.md index 430a0e8..46bbfd9 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S11.1-Stage-1-audit.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S11.1-Stage-1-audit.md @@ -7,6 +7,7 @@ tags: - PECB-LA isotags: [] status: active +processed: false --- # S11.1 Stage 1 audit diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S11.2-Stage-1-audit.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S11.2-Stage-1-audit.md index 41413d9..994ff4a 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S11.2-Stage-1-audit.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S11.2-Stage-1-audit.md @@ -7,6 +7,7 @@ tags: - PECB-LA isotags: [] status: active +processed: false --- # S11.2 Stage 1 audit diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S12.1-Preparing-for-stage-2-audit.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S12.1-Preparing-for-stage-2-audit.md index 9bced3a..75623f2 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S12.1-Preparing-for-stage-2-audit.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S12.1-Preparing-for-stage-2-audit.md @@ -7,6 +7,7 @@ tags: - PECB-LA isotags: [] status: active +processed: false --- # S12.1 Preparing for stage 2 audit diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S12.2-Preparing-for-stage-2-audit.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S12.2-Preparing-for-stage-2-audit.md index 514ddd3..670eccb 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S12.2-Preparing-for-stage-2-audit.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S12.2-Preparing-for-stage-2-audit.md @@ -7,6 +7,7 @@ tags: - PECB-LA isotags: [] status: active +processed: false --- # S12.2 Preparing for stage 2 audit diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S13.1-Stage-2-audit.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S13.1-Stage-2-audit.md index f119ff2..64e8ba5 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S13.1-Stage-2-audit.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S13.1-Stage-2-audit.md @@ -7,6 +7,7 @@ tags: - PECB-LA isotags: [] status: active +processed: false --- # S13.1 Stage 2 audit diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S13.2-Stage-2-audit.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S13.2-Stage-2-audit.md index 394aeca..78f08fa 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S13.2-Stage-2-audit.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S13.2-Stage-2-audit.md @@ -7,6 +7,7 @@ tags: - PECB-LA isotags: [] status: active +processed: false --- # S13.2 Stage 2 audit diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S14.1-Communication-during-the-audit.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S14.1-Communication-during-the-audit.md index 20d8740..de26775 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S14.1-Communication-during-the-audit.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S14.1-Communication-during-the-audit.md @@ -7,6 +7,7 @@ tags: - PECB-LA isotags: [] status: active +processed: false --- # S14.1 Communication during the audit diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S14.2-Communication-during-the-audit.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S14.2-Communication-during-the-audit.md index b0c9e43..2a01227 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S14.2-Communication-during-the-audit.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S14.2-Communication-during-the-audit.md @@ -7,6 +7,7 @@ tags: - PECB-LA isotags: [] status: active +processed: false --- # S14.2 Communication during the audit diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S15.1-Audit-procedures.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S15.1-Audit-procedures.md index ce97a4e..45d79ec 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S15.1-Audit-procedures.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S15.1-Audit-procedures.md @@ -7,6 +7,7 @@ tags: - PECB-LA isotags: [] status: active +processed: false --- # S15.1 Audit procedures diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S15.2-Audit-procedures.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S15.2-Audit-procedures.md index 94dd5e2..d3136b8 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S15.2-Audit-procedures.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S15.2-Audit-procedures.md @@ -7,6 +7,7 @@ tags: - PECB-LA isotags: [] status: active +processed: false --- # S15.2 Audit procedures diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S15.3-Audit-procedures.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S15.3-Audit-procedures.md index 94b841d..b7a0d48 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S15.3-Audit-procedures.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S15.3-Audit-procedures.md @@ -7,6 +7,7 @@ tags: - PECB-LA isotags: [] status: active +processed: false --- # S15.3 Audit procedures diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S15.4-Audit-procedures.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S15.4-Audit-procedures.md index 28aa121..3df119e 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S15.4-Audit-procedures.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S15.4-Audit-procedures.md @@ -7,6 +7,7 @@ tags: - PECB-LA isotags: [] status: active +processed: false --- # S15.4 Audit procedures diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S15.5-Audit-procedures.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S15.5-Audit-procedures.md index 47c9247..9625abc 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S15.5-Audit-procedures.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S15.5-Audit-procedures.md @@ -7,6 +7,7 @@ tags: - PECB-LA isotags: [] status: active +processed: false --- # S15.5 Audit procedures diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S16.1-Creating-audit-test-plans.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S16.1-Creating-audit-test-plans.md index d6cf7fa..6193d06 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S16.1-Creating-audit-test-plans.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S16.1-Creating-audit-test-plans.md @@ -10,6 +10,7 @@ isotags: - C.4.2 - C.7.5.3 status: active +processed: false --- # S16.1 Creating audit test plans diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S16.2-Creating-audit-test-plans.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S16.2-Creating-audit-test-plans.md index 7e7e3a8..d069b04 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S16.2-Creating-audit-test-plans.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S16.2-Creating-audit-test-plans.md @@ -25,6 +25,7 @@ isotags: - C.10.1 - C.10.2 status: active +processed: false --- # S16.2 Creating audit test plans diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S17.1-Drafting-audit-findings-and-nonconformity-reports.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S17.1-Drafting-audit-findings-and-nonconformity-reports.md index 5c433c2..5b12b44 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S17.1-Drafting-audit-findings-and-nonconformity-reports.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S17.1-Drafting-audit-findings-and-nonconformity-reports.md @@ -7,6 +7,7 @@ tags: - PECB-LA isotags: [] status: active +processed: false --- # S17.1 Drafting audit findings and nonconformity reports diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S17.2-Drafting-audit-findings-and-nonconformity-reports.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S17.2-Drafting-audit-findings-and-nonconformity-reports.md index 11b1e05..c591f55 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S17.2-Drafting-audit-findings-and-nonconformity-reports.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S17.2-Drafting-audit-findings-and-nonconformity-reports.md @@ -7,6 +7,7 @@ tags: - PECB-LA isotags: [] status: active +processed: false --- # S17.2 Drafting audit findings and nonconformity reports diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S18-Audit-documentation-and-quality-review.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S18-Audit-documentation-and-quality-review.md index 282d553..e0f4c6f 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S18-Audit-documentation-and-quality-review.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S18-Audit-documentation-and-quality-review.md @@ -8,6 +8,7 @@ tags: isotags: - C.7.5.2 status: active +processed: false --- # S18 Audit documentation and quality review diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S19.1-Closing-of-the-audit.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S19.1-Closing-of-the-audit.md index 309366c..c9fb555 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S19.1-Closing-of-the-audit.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S19.1-Closing-of-the-audit.md @@ -7,6 +7,7 @@ tags: - PECB-LA isotags: [] status: active +processed: false --- # S19.1 Closing of the audit diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S19.2-Closing-of-the-audit.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S19.2-Closing-of-the-audit.md index 9a4fed8..6b3dbb4 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S19.2-Closing-of-the-audit.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S19.2-Closing-of-the-audit.md @@ -7,6 +7,7 @@ tags: - PECB-LA isotags: [] status: active +processed: false --- # S19.2 Closing of the audit diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S20-Evaluation-of-action-plans-by-the-auditor.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S20-Evaluation-of-action-plans-by-the-auditor.md index 140861e..dfbf59f 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S20-Evaluation-of-action-plans-by-the-auditor.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S20-Evaluation-of-action-plans-by-the-auditor.md @@ -7,6 +7,7 @@ tags: - PECB-LA isotags: [] status: active +processed: false --- # S20 Evaluation of action plans by the auditor diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S21.1-Beyond-the-initial-audit.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S21.1-Beyond-the-initial-audit.md index e07092c..0b6aa85 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S21.1-Beyond-the-initial-audit.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S21.1-Beyond-the-initial-audit.md @@ -7,6 +7,7 @@ tags: - PECB-LA isotags: [] status: active +processed: false --- # S21.1 Beyond the initial audit diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S21.2-Beyond-the-initial-audit.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S21.2-Beyond-the-initial-audit.md index 4c6be70..08f5109 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S21.2-Beyond-the-initial-audit.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S21.2-Beyond-the-initial-audit.md @@ -7,6 +7,7 @@ tags: - PECB-LA isotags: [] status: active +processed: false --- # S21.2 Beyond the initial audit diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S22.1-Managing-an-internal-audit-program.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S22.1-Managing-an-internal-audit-program.md index 37a51ea..461e01f 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S22.1-Managing-an-internal-audit-program.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S22.1-Managing-an-internal-audit-program.md @@ -7,6 +7,7 @@ tags: - PECB-LA isotags: [] status: active +processed: false --- # S22.1 Managing an internal audit program diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S22.2-Managing-an-internal-audit-program.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S22.2-Managing-an-internal-audit-program.md index f62684e..d184d90 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S22.2-Managing-an-internal-audit-program.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S22.2-Managing-an-internal-audit-program.md @@ -8,6 +8,7 @@ tags: isotags: - C.10.2 status: active +processed: false --- # S22.2 Managing an internal audit program diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S23.1-Closing-of-the-training-course.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S23.1-Closing-of-the-training-course.md index 4a0f5e3..9f7197f 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S23.1-Closing-of-the-training-course.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S23.1-Closing-of-the-training-course.md @@ -7,6 +7,7 @@ tags: - PECB-LA isotags: [] status: active +processed: false --- # S23.1 Closing of the training course diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S23.2-Closing-of-the-training-course.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S23.2-Closing-of-the-training-course.md index 5e90276..f67fdc2 100644 --- a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S23.2-Closing-of-the-training-course.md +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/S23.2-Closing-of-the-training-course.md @@ -7,6 +7,7 @@ tags: - PECB-LA isotags: [] status: active +processed: false --- # S23.2 Closing of the training course diff --git a/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/_transcriptions-index.md b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/_transcriptions-index.md new file mode 100644 index 0000000..fadca52 --- /dev/null +++ b/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions/_transcriptions-index.md @@ -0,0 +1,16 @@ +# PECB Lead Auditor Training — Transcriptions Index + +```dataviewjs +const files = dv.pages('"iso27diy-corp/Corpus/Standards/ISO27x/PECB-Lead-Auditor-Training/transcriptions"') + .where(p => p.file.name !== "index") + .sort(p => p.file.name, "asc"); + +dv.table( + ["#", "Read", "Transcription"], + files.map((p, i) => [ + i + 1, + p.processed ? "✅" : "⬜", + p.file.link + ]) +); +``` diff --git a/Corpus/Standards/ISO27x/Privacy in ISO 27001.md b/Corpus/Standards/ISO27x/Privacy in ISO 27001.md deleted file mode 100644 index e34ebb9..0000000 --- a/Corpus/Standards/ISO27x/Privacy in ISO 27001.md +++ /dev/null @@ -1,9 +0,0 @@ -# Privacy in ISO 27001 - -[Core concepts of Privacy](Core%20concepts%20of%20Privacy.md) -[AVG GDPR resources](../AVG/AVG%20GDPR%20resources.md) - -Privacy in ISO 27001: -- [ISO 27001 A 18 Compliance](legacy/ISO%2027001%202013/ISO%2027001%20A%2018%20Compliance.md#A%2018%201%204%20Privacy%20and%20protection%20of%20personally%20identifiable%20information) - -[Personal Health Train | Health-RI](https://www.health-ri.nl/initiatives/personal-health-train) diff --git a/Corpus/Standards/ISO27x/Zero Trust and ISO 27001.md b/Corpus/Standards/ISO27x/Zero Trust and ISO 27001.md deleted file mode 100644 index 0cc371f..0000000 --- a/Corpus/Standards/ISO27x/Zero Trust and ISO 27001.md +++ /dev/null @@ -1,4 +0,0 @@ -# Zero Trust and ISO 27001 - -[Zero Trust](../📚️%20Literature%20notes/Zero%20Trust.md) is a security principle that can be applied to systems and processes. [ISO 27001 A.13.2 Information transfer](legacy/ISO%2027001%202013/ISO%2027001%20A.13.2%20Information%20transfer.md) is a method to manage security risks. - diff --git a/Corpus/Standards/ISO27x/About A-5.33 Protection of records.md b/Corpus/Standards/ISO27x/about/About A-5.33 Protection of records.md similarity index 100% rename from Corpus/Standards/ISO27x/About A-5.33 Protection of records.md rename to Corpus/Standards/ISO27x/about/About A-5.33 Protection of records.md diff --git a/Corpus/Standards/ISO27x/About Control 8.3 Information access restriction.md b/Corpus/Standards/ISO27x/about/About Control 8.3 Information access restriction.md similarity index 100% rename from Corpus/Standards/ISO27x/About Control 8.3 Information access restriction.md rename to Corpus/Standards/ISO27x/about/About Control 8.3 Information access restriction.md diff --git a/Corpus/Standards/ISO27x/about/Authentication.md b/Corpus/Standards/ISO27x/about/Authentication.md new file mode 100644 index 0000000..c5e8805 --- /dev/null +++ b/Corpus/Standards/ISO27x/about/Authentication.md @@ -0,0 +1,12 @@ +# Authentication +Authentication is the proof of identity that is achieved through providing credentials to the access control mechanism. + + + +See also: +- [a-8.5-Secure-authentication](../OST/27002/EN/a-8.5-Secure-authentication.md) +- [Authentication Methods Used for Network Security](../../../Information%20Security/Authentication%20Methods%20Used%20for%20Network%20Security.md) +- [Identity and Access Management (IAM)](../../../Information%20Security/Identity%20and%20Access%20Management%20(IAM).md) +- [Authorization](Authorization.md) +- [Identification](../../../Information%20Security/Identification.md) + diff --git a/Corpus/Standards/ISO27x/about/Authorization.md b/Corpus/Standards/ISO27x/about/Authorization.md new file mode 100644 index 0000000..3d23029 --- /dev/null +++ b/Corpus/Standards/ISO27x/about/Authorization.md @@ -0,0 +1,13 @@ +# Authorization +Authorization is the mechanism that determines the access level(s) of the subjects to the objects. + +See also: +- [Authorization vs Access Control](../../../ISMS/Authorization%20vs%20Access%20Control.md) +- [Access Control Models](../../../ISMS/Access%20Control%20Models.md) +- [Authentication](Authentication.md) +- [Identification](../../../Information%20Security/Identification.md) +- [CASSM Consumer Authentication Strength Maturity Model](../../../Information%20Security/CASSM%20Consumer%20Authentication%20Strength%20Maturity%20Model.md) +- [Identity and Access Management (IAM)](../../../Information%20Security/Identity%20and%20Access%20Management%20(IAM).md) +- [a-5.15-Access-control](../OST/27002/EN/a-5.15-Access-control.md) ??? + + diff --git a/Corpus/Standards/ISO27x/Change management Change Management in ISO 27002.md b/Corpus/Standards/ISO27x/about/Change management Change Management in ISO 27002.md similarity index 100% rename from Corpus/Standards/ISO27x/Change management Change Management in ISO 27002.md rename to Corpus/Standards/ISO27x/about/Change management Change Management in ISO 27002.md diff --git a/Corpus/Standards/ISO27x/Changes in ISO 27001-2022 table.jpeg b/Corpus/Standards/ISO27x/about/Changes in ISO 27001-2022 table.jpeg similarity index 100% rename from Corpus/Standards/ISO27x/Changes in ISO 27001-2022 table.jpeg rename to Corpus/Standards/ISO27x/about/Changes in ISO 27001-2022 table.jpeg diff --git a/Corpus/Standards/ISO27x/Explicitly mentioned roles in ISO 27001.md b/Corpus/Standards/ISO27x/about/Explicitly mentioned roles in ISO 27001.md similarity index 100% rename from Corpus/Standards/ISO27x/Explicitly mentioned roles in ISO 27001.md rename to Corpus/Standards/ISO27x/about/Explicitly mentioned roles in ISO 27001.md diff --git a/Corpus/Standards/ISO27x/FAIR ISO 27005 Cookbook.pdf b/Corpus/Standards/ISO27x/about/FAIR ISO 27005 Cookbook.pdf similarity index 100% rename from Corpus/Standards/ISO27x/FAIR ISO 27005 Cookbook.pdf rename to Corpus/Standards/ISO27x/about/FAIR ISO 27005 Cookbook.pdf diff --git a/Corpus/Standards/ISO27x/Governance model for Policies and Controls.md b/Corpus/Standards/ISO27x/about/Governance model for Policies and Controls.md similarity index 97% rename from Corpus/Standards/ISO27x/Governance model for Policies and Controls.md rename to Corpus/Standards/ISO27x/about/Governance model for Policies and Controls.md index 9545df3..7139545 100644 --- a/Corpus/Standards/ISO27x/Governance model for Policies and Controls.md +++ b/Corpus/Standards/ISO27x/about/Governance model for Policies and Controls.md @@ -2,7 +2,7 @@ Based on ISO 27001 and ISO 27002, a governance model for your ISMS should be structured around **Top Management's accountability** while delegating the **tactical execution** to specific information security roles. -*See [Basic ISMS governance model](../../ISMS/Basic%20ISMS%20governance%20model.md) for a compacted version* +*See [Basic ISMS governance model](../../../ISMS/Basic%20ISMS%20governance%20model.md) for a compacted version* ## Related to the Policies Lifecycle Here is a suggested governance model mapping the lifecycle of security policies (commissioning, drafting, approving, etc.) to the specific roles mandated by the standards. @@ -16,7 +16,7 @@ In the ISO 27001 framework, Top Management holds the ultimate accountability. Th - **Signing Off / Approving:** They must formally approve the information security policy. Any changes to the high-level policy must also be approved by them. - **Resourcing:** They are responsible for ensuring the resources needed for the ISMS are available. -– see [C.5.1](../../MoCs/ISO_27001_2022_5.1_MoC%20Leadership%20and%20commitment.md), [A.5.1](legacy/iso27DIY%20mk%20I/ISO_27002_2022_5.1_MoC%20Policies%20for%20information%20security.md) +– see [C.5.1](../../MoCs/ISO_27001_2022_5.1_MoC%20Leadership%20and%20commitment.md), [A.5.1](../legacy/iso27DIY%20mk%20I/ISO_27002_2022_5.1_MoC%20Policies%20for%20information%20security.md) ### **2. Information Security Manager / Competent Personnel** **Primary Mandate:** _Drafting, Advising, and Reviewing._ @@ -58,7 +58,7 @@ To operationalize this model, you can organize your governance activities into t | **5. Communicating** | **Security Manager/HR** publishes the policy in a format accessible to all employees and relevant external parties. | | **6. Acknowledging** | **All Personnel** sign or digitally acknowledge that they have read and understood the policy. | | **7. Reviewing** | **Security Manager** re-evaluates the policy at planned intervals or after significant changes (e.g., a security incident). | -These can be deducted from [C.5.1](../../MoCs/ISO_27001_2022_5.1_MoC%20Leadership%20and%20commitment.md), [A.5.1](legacy/iso27DIY%20mk%20I/ISO_27002_2022_5.1_MoC%20Policies%20for%20information%20security.md), C.0.1, and C.0.2 +These can be deducted from [C.5.1](../../MoCs/ISO_27001_2022_5.1_MoC%20Leadership%20and%20commitment.md), [A.5.1](../legacy/iso27DIY%20mk%20I/ISO_27002_2022_5.1_MoC%20Policies%20for%20information%20security.md), C.0.1, and C.0.2 ### **Analogy: The Legislative Process** diff --git a/Corpus/Standards/ISO27x/ISO 17021 Conformity assessment.md b/Corpus/Standards/ISO27x/about/ISO 17021 Conformity assessment.md similarity index 100% rename from Corpus/Standards/ISO27x/ISO 17021 Conformity assessment.md rename to Corpus/Standards/ISO27x/about/ISO 17021 Conformity assessment.md diff --git a/Corpus/Standards/ISO27x/ISO 22317 Guidelines for business impact analysis.md b/Corpus/Standards/ISO27x/about/ISO 22317 Guidelines for business impact analysis.md similarity index 100% rename from Corpus/Standards/ISO27x/ISO 22317 Guidelines for business impact analysis.md rename to Corpus/Standards/ISO27x/about/ISO 22317 Guidelines for business impact analysis.md diff --git a/Corpus/Standards/ISO27x/ISO 27000 MoC.md b/Corpus/Standards/ISO27x/about/ISO 27000 MoC.md similarity index 100% rename from Corpus/Standards/ISO27x/ISO 27000 MoC.md rename to Corpus/Standards/ISO27x/about/ISO 27000 MoC.md diff --git a/Corpus/Standards/ISO27x/ISO 27000 Overview and Vocabulary.md b/Corpus/Standards/ISO27x/about/ISO 27000 Overview and Vocabulary.md similarity index 100% rename from Corpus/Standards/ISO27x/ISO 27000 Overview and Vocabulary.md rename to Corpus/Standards/ISO27x/about/ISO 27000 Overview and Vocabulary.md diff --git a/Corpus/Standards/ISO27x/ISO 27000 PDF.md b/Corpus/Standards/ISO27x/about/ISO 27000 PDF.md similarity index 100% rename from Corpus/Standards/ISO27x/ISO 27000 PDF.md rename to Corpus/Standards/ISO27x/about/ISO 27000 PDF.md diff --git a/Corpus/Standards/ISO27x/ISO 27001 Approaching Annex A.md b/Corpus/Standards/ISO27x/about/ISO 27001 Approaching Annex A.md similarity index 100% rename from Corpus/Standards/ISO27x/ISO 27001 Approaching Annex A.md rename to Corpus/Standards/ISO27x/about/ISO 27001 Approaching Annex A.md diff --git a/Corpus/Standards/ISO27x/ISO 27001 Certification audit.md b/Corpus/Standards/ISO27x/about/ISO 27001 Certification audit.md similarity index 100% rename from Corpus/Standards/ISO27x/ISO 27001 Certification audit.md rename to Corpus/Standards/ISO27x/about/ISO 27001 Certification audit.md diff --git a/Corpus/Standards/ISO27x/ISO 27001 Eigenaarschap van Documentatie.md b/Corpus/Standards/ISO27x/about/ISO 27001 Eigenaarschap van Documentatie.md similarity index 95% rename from Corpus/Standards/ISO27x/ISO 27001 Eigenaarschap van Documentatie.md rename to Corpus/Standards/ISO27x/about/ISO 27001 Eigenaarschap van Documentatie.md index 082bfe2..a00105d 100644 --- a/Corpus/Standards/ISO27x/ISO 27001 Eigenaarschap van Documentatie.md +++ b/Corpus/Standards/ISO27x/about/ISO 27001 Eigenaarschap van Documentatie.md @@ -6,7 +6,7 @@ De norm geeft specifieke richtlijnen over waar de verantwoordelijkheid voor de v **1. Het overkoepelende Informatiebeveiligingsbeleid** Dit is het document op het hoogste niveau. De norm eist expliciet dat de verantwoordelijkheid voor het vaststellen en goedkeuren van dit beleid uitsluitend bij het **topmanagement (de directie)** ligt. -**2. Onderwerpspecifieke beleidsregels** Voor meer gedetailleerde of specifieke beleidsregels (zoals beleid voor toegangsbeveiliging, cryptografie of werken op afstand) ligt de verantwoordelijkheid voor het ontwikkelen, beoordelen en goedkeuren bij **relevant personeel op basis van een passend bevoegdheidsniveau en technische bekwaamheid**. Dit betekent dat het eigenaarschap hier doorgaans bij de systeemeigenaren, security officers of afdelingsmanagers ligt (het "passende managementniveau", zie [A.5.1](legacy/iso27DIY%20mk%20I/ISO_27002_2022_5.1_MoC%20Policies%20for%20information%20security.md)). +**2. Onderwerpspecifieke beleidsregels** Voor meer gedetailleerde of specifieke beleidsregels (zoals beleid voor toegangsbeveiliging, cryptografie of werken op afstand) ligt de verantwoordelijkheid voor het ontwikkelen, beoordelen en goedkeuren bij **relevant personeel op basis van een passend bevoegdheidsniveau en technische bekwaamheid**. Dit betekent dat het eigenaarschap hier doorgaans bij de systeemeigenaren, security officers of afdelingsmanagers ligt (het "passende managementniveau", zie [A.5.1](../legacy/iso27DIY%20mk%20I/ISO_27002_2022_5.1_MoC%20Policies%20for%20information%20security.md)). **3. Gedocumenteerde bedieningsprocedures** Voor werkinstructies en bedieningsprocedures (zoals omschreven in [A.5.37](../../MoCs/ISO_27002_2022_5.37_MoC%20Documented%20operating%20procedures.md)) eist de norm dat in de documentatie zélf expliciet wordt gespecificeerd **welke personen verantwoordelijk zijn** voor de in de procedure beschreven activiteiten. diff --git a/Corpus/Standards/ISO27x/ISO 27001 Leadership Responsibilities.md b/Corpus/Standards/ISO27x/about/ISO 27001 Leadership Responsibilities.md similarity index 97% rename from Corpus/Standards/ISO27x/ISO 27001 Leadership Responsibilities.md rename to Corpus/Standards/ISO27x/about/ISO 27001 Leadership Responsibilities.md index d9d74fe..a7a972d 100644 --- a/Corpus/Standards/ISO27x/ISO 27001 Leadership Responsibilities.md +++ b/Corpus/Standards/ISO27x/about/ISO 27001 Leadership Responsibilities.md @@ -25,7 +25,7 @@ Top management is responsible for establishing an information security policy th - **Approval:** The policy must be formally approved by top management. - **Changes:** Any changes to the policy must be approved by top management. -This is described in [Clause 5.2](../../MoCs/ISO_27001_2022_5.2_MoC%20Policy.md) and [Control 5.1](legacy/iso27DIY%20mk%20I/ISO_27002_2022_5.1_MoC%20Policies%20for%20information%20security.md). +This is described in [Clause 5.2](../../MoCs/ISO_27001_2022_5.2_MoC%20Policy.md) and [Control 5.1](../legacy/iso27DIY%20mk%20I/ISO_27002_2022_5.1_MoC%20Policies%20for%20information%20security.md). ### 3. Organizational Roles and Authorities (ISO 27001) Top management must ensure that responsibilities and authorities for roles relevant to information security are assigned and communicated within the organization. specifically, they must assign the responsibility and authority for: diff --git a/Corpus/Standards/ISO27x/ISO 27001 Statement of Applicability.md b/Corpus/Standards/ISO27x/about/ISO 27001 Statement of Applicability.md similarity index 100% rename from Corpus/Standards/ISO27x/ISO 27001 Statement of Applicability.md rename to Corpus/Standards/ISO27x/about/ISO 27001 Statement of Applicability.md diff --git a/Corpus/Standards/ISO27x/ISO 27001 Top Management responsibilities.md b/Corpus/Standards/ISO27x/about/ISO 27001 Top Management responsibilities.md similarity index 100% rename from Corpus/Standards/ISO27x/ISO 27001 Top Management responsibilities.md rename to Corpus/Standards/ISO27x/about/ISO 27001 Top Management responsibilities.md diff --git a/Corpus/Standards/ISO27x/ISO 27001 audit calculatie.md b/Corpus/Standards/ISO27x/about/ISO 27001 audit calculatie.md similarity index 100% rename from Corpus/Standards/ISO27x/ISO 27001 audit calculatie.md rename to Corpus/Standards/ISO27x/about/ISO 27001 audit calculatie.md diff --git a/Corpus/Standards/ISO27x/ISO 27001 audit process.md b/Corpus/Standards/ISO27x/about/ISO 27001 audit process.md similarity index 100% rename from Corpus/Standards/ISO27x/ISO 27001 audit process.md rename to Corpus/Standards/ISO27x/about/ISO 27001 audit process.md diff --git a/Corpus/Standards/ISO27x/ISO 27001 enumerated list of controls.md b/Corpus/Standards/ISO27x/about/ISO 27001 enumerated list of controls.md similarity index 100% rename from Corpus/Standards/ISO27x/ISO 27001 enumerated list of controls.md rename to Corpus/Standards/ISO27x/about/ISO 27001 enumerated list of controls.md diff --git a/Corpus/Standards/ISO27x/ISO 27001 examples of scope statements.md b/Corpus/Standards/ISO27x/about/ISO 27001 examples of scope statements.md similarity index 100% rename from Corpus/Standards/ISO27x/ISO 27001 examples of scope statements.md rename to Corpus/Standards/ISO27x/about/ISO 27001 examples of scope statements.md diff --git a/Corpus/Standards/ISO27x/ISO 27001 stage 1 audit.md b/Corpus/Standards/ISO27x/about/ISO 27001 stage 1 audit.md similarity index 100% rename from Corpus/Standards/ISO27x/ISO 27001 stage 1 audit.md rename to Corpus/Standards/ISO27x/about/ISO 27001 stage 1 audit.md diff --git a/Corpus/Standards/ISO27x/ISO 27003.md b/Corpus/Standards/ISO27x/about/ISO 27003.md similarity index 100% rename from Corpus/Standards/ISO27x/ISO 27003.md rename to Corpus/Standards/ISO27x/about/ISO 27003.md diff --git a/Corpus/Standards/ISO27x/ISO 27004.md b/Corpus/Standards/ISO27x/about/ISO 27004.md similarity index 100% rename from Corpus/Standards/ISO27x/ISO 27004.md rename to Corpus/Standards/ISO27x/about/ISO 27004.md diff --git a/Corpus/Standards/ISO27x/ISO 27005.md b/Corpus/Standards/ISO27x/about/ISO 27005.md similarity index 100% rename from Corpus/Standards/ISO27x/ISO 27005.md rename to Corpus/Standards/ISO27x/about/ISO 27005.md diff --git a/Corpus/Standards/ISO27x/ISO 27017.md b/Corpus/Standards/ISO27x/about/ISO 27017.md similarity index 100% rename from Corpus/Standards/ISO27x/ISO 27017.md rename to Corpus/Standards/ISO27x/about/ISO 27017.md diff --git a/Corpus/Standards/ISO27x/ISO 27018.md b/Corpus/Standards/ISO27x/about/ISO 27018.md similarity index 100% rename from Corpus/Standards/ISO27x/ISO 27018.md rename to Corpus/Standards/ISO27x/about/ISO 27018.md diff --git a/Corpus/Standards/ISO27x/ISO 27028.md b/Corpus/Standards/ISO27x/about/ISO 27028.md similarity index 100% rename from Corpus/Standards/ISO27x/ISO 27028.md rename to Corpus/Standards/ISO27x/about/ISO 27028.md diff --git a/Corpus/Standards/ISO27x/ISO 27034 MoC.md b/Corpus/Standards/ISO27x/about/ISO 27034 MoC.md similarity index 100% rename from Corpus/Standards/ISO27x/ISO 27034 MoC.md rename to Corpus/Standards/ISO27x/about/ISO 27034 MoC.md diff --git a/Corpus/Standards/ISO27x/ISO 27034-5.md b/Corpus/Standards/ISO27x/about/ISO 27034-5.md similarity index 100% rename from Corpus/Standards/ISO27x/ISO 27034-5.md rename to Corpus/Standards/ISO27x/about/ISO 27034-5.md diff --git a/Corpus/Standards/ISO27x/ISO 27701.md b/Corpus/Standards/ISO27x/about/ISO 27701.md similarity index 100% rename from Corpus/Standards/ISO27x/ISO 27701.md rename to Corpus/Standards/ISO27x/about/ISO 27701.md diff --git a/Corpus/Standards/ISO27x/about/ISO 27k standards overview.md b/Corpus/Standards/ISO27x/about/ISO 27k standards overview.md new file mode 100644 index 0000000..18e768c --- /dev/null +++ b/Corpus/Standards/ISO27x/about/ISO 27k standards overview.md @@ -0,0 +1,54 @@ +--- +tags: + - iso27001 + - iso27002 + - type/MoC + - nen7510 +--- +# ISO and NEN security standards +## ISO 27001 & 27002 + +Indexes: +- [ISO 27001:2022 EN](ISO_27001_2022_Index.md) +- [ISO 27002:2022 EN](ISO_27001_2022_Index%20EXT.md) – Includes references to 2013 version! +- [ISO 27001:2023 NL](../OST/ISO_27001_2023_NL_Index.md) +- [ISO 27002:2022 NL](../OST/ISO_27002_2022_NL_Index.md) +- [Vertaaltabel Engels-Nederlands](ISO_27002_2022_Vertaaltabel_Engels_Nederlands.md) + +EN source tekst: +- ISO 27001:2022 [PDF](../OST/27001/EN/ISO_27001_2022_EN.pdf) +- ISO 27002:2022 [PDF](../OST/27002/EN/ISO_27002_2022_EN.pdf) + +NL brontekst: +- ISO 27001:2023 [PDF](OST/27001/NL/ISO_27001_2023_NL_PDF.md) +- ISO 27002:2022 [PDF](../OST/ISO_27002_2022_NL_PDF.md) + + +See also: +- [Plain English ISO IEC 27002 2005 from Praxiom](https://www.praxiom.com/iso-17799-objectives.htm) +- [Changes in ISO 27001:2022 (table)](../OST/27001/Detailed%20comparison%20between%202017%20and%202022.md) +- [[ISO 27002 2022 What's New]] +- [ISO_27001_2023_NL_Aanpassingen](../OST/ISO_27001_2023_NL_Aanpassingen.md) +- [Changes in ISO 27001_2022_Advisera](../../../../iso27DIY-gis/reference/Changes%20in%20ISO%2027001_2022_Advisera.md) +- [IBB op hoofdlijnen](../OST/IBB%20op%20hoofdlijnen.md) +- [ISO 27001 2023 Processen en Artefacten](../OST/ISO%2027001%202023%20Processen%20en%20Artefacten.md) +- [Advised Documents for ISO 27001](../../../../iso27DIY-gis/reference/Advised%20Documents%20for%20ISO%2027001.md) +- [Types of Controls](Types%20of%20Controls.md) + +Depreciated: +[ISO_27001_2013_EN_Index](../legacy/ISO%2027001%202013/ISO_27001_2013_EN_Index.md) +[ISO_27001_2017_NL_Index](../legacy/ISO%2027001%202017%20NL/ISO_27001_2017_NL_Index.md) + +## Related ISO standards +- [ISO 27k family](../../../../iso27DIY-gis/reference/Examples/ISO%2027k%20family.md) + - [ISO 27000](ISO%2027000%20MoC.md) + - [ISO 27005](ISO%2027005.md) +- NEN 7510 + - [NEN 7510-1:2024](../OST/7510/NEN7510_2024_NL_1.md) + - [NEN 7510-2:2024](../OST/7510/NEN7510_2024_NL_2.md) + - [NEN 7510-1:2024 Bijlage A](../OST/7510/NEN7510_2024_NL_1_A.md) + - [NEN 7510-1:2024 Bijlage B](../OST/7510/NEN7510_2024_NL_1_B.md) + - [NEN 7510-1:2024 Bijlage C](../OST/7510/NEN7510_2024_NL_1_C.md) + - [NEN 7510-1:2024 vs. ISO 27001:2022](../OST/7510/NEN%207510%20vs%20ISO%2027001.md) + - [Lijst met relevante risico's](../OST/7510/NEN7510%20Risicos.md) + diff --git a/Corpus/Standards/ISO27x/ISO Certification Structure and Process.md b/Corpus/Standards/ISO27x/about/ISO Certification Structure and Process.md similarity index 100% rename from Corpus/Standards/ISO27x/ISO Certification Structure and Process.md rename to Corpus/Standards/ISO27x/about/ISO Certification Structure and Process.md diff --git a/Corpus/Standards/ISO27x/ISO IEC 27003-2017 ISMS Guidance.pdf b/Corpus/Standards/ISO27x/about/ISO IEC 27003-2017 ISMS Guidance.pdf similarity index 100% rename from Corpus/Standards/ISO27x/ISO IEC 27003-2017 ISMS Guidance.pdf rename to Corpus/Standards/ISO27x/about/ISO IEC 27003-2017 ISMS Guidance.pdf diff --git a/Corpus/Standards/ISO27x/ISO IEC 27004-2016 Monitoring and measuring.pdf b/Corpus/Standards/ISO27x/about/ISO IEC 27004-2016 Monitoring and measuring.pdf similarity index 100% rename from Corpus/Standards/ISO27x/ISO IEC 27004-2016 Monitoring and measuring.pdf rename to Corpus/Standards/ISO27x/about/ISO IEC 27004-2016 Monitoring and measuring.pdf diff --git a/Corpus/Standards/ISO27x/ISO IEC 27005-2022 Guidance on managing risks.pdf b/Corpus/Standards/ISO27x/about/ISO IEC 27005-2022 Guidance on managing risks.pdf similarity index 100% rename from Corpus/Standards/ISO27x/ISO IEC 27005-2022 Guidance on managing risks.pdf rename to Corpus/Standards/ISO27x/about/ISO IEC 27005-2022 Guidance on managing risks.pdf diff --git a/Corpus/Standards/ISO27x/ISO-27002-2022-Controls-categorized.pdf b/Corpus/Standards/ISO27x/about/ISO-27002-2022-Controls-categorized.pdf similarity index 100% rename from Corpus/Standards/ISO27x/ISO-27002-2022-Controls-categorized.pdf rename to Corpus/Standards/ISO27x/about/ISO-27002-2022-Controls-categorized.pdf diff --git a/Corpus/Standards/ISO27x/ISO31000-5.4.1-Understanding-the-organization-and-its-context.md b/Corpus/Standards/ISO27x/about/ISO31000-5.4.1-Understanding-the-organization-and-its-context.md similarity index 100% rename from Corpus/Standards/ISO27x/ISO31000-5.4.1-Understanding-the-organization-and-its-context.md rename to Corpus/Standards/ISO27x/about/ISO31000-5.4.1-Understanding-the-organization-and-its-context.md diff --git a/Corpus/Standards/ISO27x/ISO_22317_Guidelines for business impact analysis.pdf b/Corpus/Standards/ISO27x/about/ISO_22317_Guidelines for business impact analysis.pdf similarity index 100% rename from Corpus/Standards/ISO27x/ISO_22317_Guidelines for business impact analysis.pdf rename to Corpus/Standards/ISO27x/about/ISO_22317_Guidelines for business impact analysis.pdf diff --git a/Corpus/Standards/ISO27x/ISO_27001_2022_Index EXT.md b/Corpus/Standards/ISO27x/about/ISO_27001_2022_Index EXT.md similarity index 98% rename from Corpus/Standards/ISO27x/ISO_27001_2022_Index EXT.md rename to Corpus/Standards/ISO27x/about/ISO_27001_2022_Index EXT.md index 21dcc55..261eac5 100644 --- a/Corpus/Standards/ISO27x/ISO_27001_2022_Index EXT.md +++ b/Corpus/Standards/ISO27x/about/ISO_27001_2022_Index EXT.md @@ -15,7 +15,7 @@ | 4.2 | [[ISO_27002_OT_4.2 Themes and attributes \| Themes and attributes ]] | | | 4.3 | [[ISO_27002_OT_4.3 Control layout \| Control layout ]] | | | **5** | **Organizational controls** | | -| 5.1 | [Policies for information security ](legacy/iso27DIY%20mk%20I/ISO_27002_2022_5.1_MoC%20Policies%20for%20information%20security.md) | 05.1.1, 05.1.2 | +| 5.1 | [Policies for information security ](../legacy/iso27DIY%20mk%20I/ISO_27002_2022_5.1_MoC%20Policies%20for%20information%20security.md) | 05.1.1, 05.1.2 | | 5.2 | [Information security roles and responsibilities ](../../MoCs/ISO_27002_2022_5.2_MoC%20Information%20security%20roles%20and%20responsibilities.md) | 06.1.1 | | 5.3 | [Segregation of duties ](../../MoCs/ISO_27002_2022_5.3_MoC%20Segregation%20of%20duties.md) | 06.1.2 | | 5.4 | [Management responsibilities ](../../MoCs/ISO_27002_2022_5.4_MoC%20Management%20responsibilities.md) | 07.2.1 | @@ -31,7 +31,7 @@ | 5.14 | [Information transfer ](../../MoCs/ISO_27002_2022_5.14_MoC%20Information%20transfer.md) | 13.2.1, 13.2.2, 13.2.3 | | 5.15 | [Access control ](../../MoCs/ISO_27002_2022_5.15_MoC%20Access%20control.md) | 09.1.1, 09.1.2 | | 5.16 | [Identity management ](../../MoCs/ISO_27002_2022_5.16_MoC%20Identity%20management.md) | 09.2.1 | -| 5.17 | [Authentication information ](../../Information%20Security/Authentication%20information.md) | 09.2.4, 09.3.1, 09.4.3 | +| 5.17 | [Authentication information ](../../../Information%20Security/Authentication%20information.md) | 09.2.4, 09.3.1, 09.4.3 | | 5.18 | [Access rights ](../../MoCs/ISO_27002_2022_5.18_MoC%20Access%20rights.md) | 09.2.2, 09.2.5, 09.2.6 | | 5.19 | [Information security in supplier relationships ](../../MoCs/ISO_27002_2022_5.19_MoC%20Information%20security%20in%20supplier%20relationships.md) | 15.1.1 | | 5.20 | [Addressing information security within supplier agreements ](../../MoCs/ISO_27002_2022_5.20_MoC%20Addressing%20information%20security%20within%20supplier%20agreements.md) | 15.1.2 | @@ -44,7 +44,7 @@ | 5.27 | [Learning from information security incidents ](../../MoCs/ISO_27002_2022_5.27_MoC%20Learning%20from%20information%20security%20incidents.md) | 16.1.6 | | 5.28 | [Collection of evidence ](../../MoCs/ISO_27002_2022_5.28_MoC%20Collection%20of%20evidence.md) | 16.1.7 | | 5.29 | [Information security during disruption ](../../MoCs/ISO_27002_2022_5.29_MoC%20Information%20security%20during%20disruption.md) | 17.1.1, 17.1.2, 17.1.3 | -| 5.30 | [ICT readiness for business continuity ](../../Information%20Security/ICT%20readiness%20for%20business%20continuity.md) | New | +| 5.30 | [ICT readiness for business continuity ](../../../Information%20Security/ICT%20readiness%20for%20business%20continuity.md) | New | | 5.31 | [Legal, statutory, regulatory and contractual requirements ](../../MoCs/ISO_27002_2022_5.31_MoC%20Legal,%20statutory,%20regulatory%20and%20contractual%20requirements.md) | 18.1.1, 18.1.5 | | 5.32 | [Intellectual property rights ](../../MoCs/ISO_27002_2022_5.32_MoC%20Intellectual%20property%20rights.md) | 18.1.2 | | 5.33 | [Protection of records ](About%20A-5.33%20Protection%20of%20records.md) | 18.1.3 | diff --git a/Corpus/Standards/ISO27x/ISO_27002_2022_Vertaaltabel_Engels_Nederlands.md b/Corpus/Standards/ISO27x/about/ISO_27002_2022_Vertaaltabel_Engels_Nederlands.md similarity index 100% rename from Corpus/Standards/ISO27x/ISO_27002_2022_Vertaaltabel_Engels_Nederlands.md rename to Corpus/Standards/ISO27x/about/ISO_27002_2022_Vertaaltabel_Engels_Nederlands.md diff --git a/Corpus/Standards/ISO27x/ISO_27002_2022_What's_New.md b/Corpus/Standards/ISO27x/about/ISO_27002_2022_What's_New.md similarity index 100% rename from Corpus/Standards/ISO27x/ISO_27002_2022_What's_New.md rename to Corpus/Standards/ISO27x/about/ISO_27002_2022_What's_New.md diff --git a/Corpus/Standards/ISO27x/ISO_27005_2022_EN.pdf b/Corpus/Standards/ISO27x/about/ISO_27005_2022_EN.pdf similarity index 100% rename from Corpus/Standards/ISO27x/ISO_27005_2022_EN.pdf rename to Corpus/Standards/ISO27x/about/ISO_27005_2022_EN.pdf diff --git a/Corpus/Standards/ISO27x/ISO_IEC-27002_2022-Controls_I.jpg b/Corpus/Standards/ISO27x/about/ISO_IEC-27002_2022-Controls_I.jpg similarity index 100% rename from Corpus/Standards/ISO27x/ISO_IEC-27002_2022-Controls_I.jpg rename to Corpus/Standards/ISO27x/about/ISO_IEC-27002_2022-Controls_I.jpg diff --git a/Corpus/Standards/ISO27x/ISO_IEC-27002_2022-Controls_II.jpg b/Corpus/Standards/ISO27x/about/ISO_IEC-27002_2022-Controls_II.jpg similarity index 100% rename from Corpus/Standards/ISO27x/ISO_IEC-27002_2022-Controls_II.jpg rename to Corpus/Standards/ISO27x/about/ISO_IEC-27002_2022-Controls_II.jpg diff --git a/Corpus/Standards/ISO27x/ISO_IEC_27000_2018_EN_Vocabulary.pdf b/Corpus/Standards/ISO27x/about/ISO_IEC_27000_2018_EN_Vocabulary.pdf similarity index 100% rename from Corpus/Standards/ISO27x/ISO_IEC_27000_2018_EN_Vocabulary.pdf rename to Corpus/Standards/ISO27x/about/ISO_IEC_27000_2018_EN_Vocabulary.pdf diff --git a/Corpus/Standards/ISO27x/ISO_IEC_27701_2019_EN.pdf b/Corpus/Standards/ISO27x/about/ISO_IEC_27701_2019_EN.pdf similarity index 100% rename from Corpus/Standards/ISO27x/ISO_IEC_27701_2019_EN.pdf rename to Corpus/Standards/ISO27x/about/ISO_IEC_27701_2019_EN.pdf diff --git a/Corpus/Standards/ISO27x/about/MoC Roles and responsibilities in ISO 27001.md b/Corpus/Standards/ISO27x/about/MoC Roles and responsibilities in ISO 27001.md new file mode 100644 index 0000000..7cd8f55 --- /dev/null +++ b/Corpus/Standards/ISO27x/about/MoC Roles and responsibilities in ISO 27001.md @@ -0,0 +1,19 @@ +# MoC Roles and responsibilities in ISO 27001 + +**See**: + +Recent: +- [Explicitly mentioned roles in ISO 27001](Explicitly%20mentioned%20roles%20in%20ISO%2027001.md) +- [ISO 27001 Leadership Responsibilities](ISO%2027001%20Leadership%20Responsibilities.md) +- [ISO 27001 Top Management responsibilities](ISO%2027001%20Top%20Management%20responsibilities.md) +- [Governance model for Policies and Controls](Governance%20model%20for%20Policies%20and%20Controls.md) +- [Basic ISMS governance model](../../../ISMS/Basic%20ISMS%20governance%20model.md) +- [m400-more-governance](../../../../../iso27DIY-gis/guide/m400/m400-more-governance.md) + +Older: +- [Roles and Responsibilities](../../../ISMS/Roles%20and%20Responsibilities.md) +- [Risk ownership](../../../Information%20Security/Risks/Risk%20ownership.md) +- [Ideas on Risk Ownership](../../../ISMS/Ideas%20on%20Risk%20Ownership.md) +- [Asset ownership](../../Sparks/Asset%20ownership.md) +- [Procuratieregeling](../../../Various/Procuratieregeling.md) +- [Control ownership](../../../ISMS/Control%20ownership.md) diff --git a/Corpus/Standards/ISO27x/NEN-EN-ISO_IEC 27018_2020 en.pdf b/Corpus/Standards/ISO27x/about/NEN-EN-ISO_IEC 27018_2020 en.pdf similarity index 100% rename from Corpus/Standards/ISO27x/NEN-EN-ISO_IEC 27018_2020 en.pdf rename to Corpus/Standards/ISO27x/about/NEN-EN-ISO_IEC 27018_2020 en.pdf diff --git a/Corpus/Standards/ISO27x/NEN-ISO-IEC 27017-2015 en.pdf b/Corpus/Standards/ISO27x/about/NEN-ISO-IEC 27017-2015 en.pdf similarity index 100% rename from Corpus/Standards/ISO27x/NEN-ISO-IEC 27017-2015 en.pdf rename to Corpus/Standards/ISO27x/about/NEN-ISO-IEC 27017-2015 en.pdf diff --git a/Corpus/Standards/ISO27x/NEN-ISO-IEC 27034-5-2017 en.pdf b/Corpus/Standards/ISO27x/about/NEN-ISO-IEC 27034-5-2017 en.pdf similarity index 100% rename from Corpus/Standards/ISO27x/NEN-ISO-IEC 27034-5-2017 en.pdf rename to Corpus/Standards/ISO27x/about/NEN-ISO-IEC 27034-5-2017 en.pdf diff --git a/Corpus/Standards/ISO27x/NIS_2_and_ISO_27001_2022.pdf b/Corpus/Standards/ISO27x/about/NIS_2_and_ISO_27001_2022.pdf similarity index 100% rename from Corpus/Standards/ISO27x/NIS_2_and_ISO_27001_2022.pdf rename to Corpus/Standards/ISO27x/about/NIS_2_and_ISO_27001_2022.pdf diff --git a/Corpus/Standards/ISO27x/Toevoegingen IBB ISO27001-2022.md b/Corpus/Standards/ISO27x/about/Nieuwe beheersmaatregelen in ISO 27001-2022.md similarity index 93% rename from Corpus/Standards/ISO27x/Toevoegingen IBB ISO27001-2022.md rename to Corpus/Standards/ISO27x/about/Nieuwe beheersmaatregelen in ISO 27001-2022.md index 642d42b..ea7b2a3 100644 --- a/Corpus/Standards/ISO27x/Toevoegingen IBB ISO27001-2022.md +++ b/Corpus/Standards/ISO27x/about/Nieuwe beheersmaatregelen in ISO 27001-2022.md @@ -1,7 +1,7 @@ # Nieuwe beheersmaatregelen in ISO 27001:2022 -Gebaseerd op [Aanpassingen in ISO 27001:2023](OST/ISO_27001_2023_NL_Aanpassingen.md#Nieuwe%20beheersmaatregelen%20in%20Annex%20A) -Verwerkt in [Informatiebeveiligingsbeleid ISO 27001](Implementation%20Products/Informatiebeveiligingsbeleid%20ISO%2027001.md) +Gebaseerd op [Aanpassingen in ISO 27001:2023](../OST/ISO_27001_2023_NL_Aanpassingen.md#Nieuwe%20beheersmaatregelen%20in%20Annex%20A) +Verwerkt in [Informatiebeveiligingsbeleid ISO 27001](../Implementation%20Products/Informatiebeveiligingsbeleid%20ISO%2027001.md) | Maatregel | **Paragraaf** | | :------------------------------------------------------------ | :--------------------------------------------------------------------------------- | diff --git a/Corpus/Standards/ISO27x/Normity Template Intern auditrapport.docx b/Corpus/Standards/ISO27x/about/Normity Template Intern auditrapport.docx similarity index 100% rename from Corpus/Standards/ISO27x/Normity Template Intern auditrapport.docx rename to Corpus/Standards/ISO27x/about/Normity Template Intern auditrapport.docx diff --git a/Corpus/Standards/ISO27x/Physical security in ISO 27001.md b/Corpus/Standards/ISO27x/about/Physical security in ISO 27001.md similarity index 100% rename from Corpus/Standards/ISO27x/Physical security in ISO 27001.md rename to Corpus/Standards/ISO27x/about/Physical security in ISO 27001.md diff --git a/Corpus/Standards/ISO27x/about/Privacy in ISO 27001.md b/Corpus/Standards/ISO27x/about/Privacy in ISO 27001.md new file mode 100644 index 0000000..c067568 --- /dev/null +++ b/Corpus/Standards/ISO27x/about/Privacy in ISO 27001.md @@ -0,0 +1,9 @@ +# Privacy in ISO 27001 + +[Core concepts of Privacy](Core%20concepts%20of%20Privacy.md) +[AVG GDPR resources](../../AVG/AVG%20GDPR%20resources.md) + +Privacy in ISO 27001: +- [ISO 27001 A 18 Compliance](../legacy/ISO%2027001%202013/ISO%2027001%20A%2018%20Compliance.md#A%2018%201%204%20Privacy%20and%20protection%20of%20personally%20identifiable%20information) + +[Personal Health Train | Health-RI](https://www.health-ri.nl/initiatives/personal-health-train) diff --git a/Corpus/Standards/ISO27x/Privacy in ISO 27k.md b/Corpus/Standards/ISO27x/about/Privacy in ISO 27k.md similarity index 100% rename from Corpus/Standards/ISO27x/Privacy in ISO 27k.md rename to Corpus/Standards/ISO27x/about/Privacy in ISO 27k.md diff --git a/Corpus/Standards/ISO27x/Risk Treatment Plan.md b/Corpus/Standards/ISO27x/about/Risk Treatment Plan.md similarity index 100% rename from Corpus/Standards/ISO27x/Risk Treatment Plan.md rename to Corpus/Standards/ISO27x/about/Risk Treatment Plan.md diff --git a/Corpus/Standards/ISO27x/Risk Treatment in ISO 27001.md b/Corpus/Standards/ISO27x/about/Risk Treatment in ISO 27001.md similarity index 100% rename from Corpus/Standards/ISO27x/Risk Treatment in ISO 27001.md rename to Corpus/Standards/ISO27x/about/Risk Treatment in ISO 27001.md diff --git a/Corpus/Standards/ISO27x/Risk assessment and treatment at two levels.md b/Corpus/Standards/ISO27x/about/Risk assessment and treatment at two levels.md similarity index 86% rename from Corpus/Standards/ISO27x/Risk assessment and treatment at two levels.md rename to Corpus/Standards/ISO27x/about/Risk assessment and treatment at two levels.md index 78e0fe9..0c1ec31 100644 --- a/Corpus/Standards/ISO27x/Risk assessment and treatment at two levels.md +++ b/Corpus/Standards/ISO27x/about/Risk assessment and treatment at two levels.md @@ -6,7 +6,7 @@ Risk assessment and risk treatment are discussed both in Chapter 6 and in Chapte The relationship between , (Information security risk assessment), and (Information security risk treatment) hinges on their roles within the Information Security Management System (ISMS) framework defined by ISO/IEC 27001:2022. -In essence, Clauses [6.1.2](../../ISMS/Qualifying%20vs%20quantifying%20risks.md) and [6.1.3](../../MoCs/ISO_27001_2022_6.1.3_MoC%20Information%20security%20risk%20treatment.md) (Information security risk assessment and risk treatment) define the _processes_ and _criteria_ for risk management within the planning stage, while Clauses [8.2](../../MoCs/ISO_27001_2022_8.2_MoC%20Information%20security%20risk%20assessment.md) and [8.3](../../MoCs/ISO_27001_2022_8.3_MoC%20Information%20security%20risk%20treatment.md) define the _operational execution_ and _timing_ for applying those established processes. +In essence, Clauses [6.1.2](../../../ISMS/Qualifying%20vs%20quantifying%20risks.md) and [6.1.3](../../MoCs/ISO_27001_2022_6.1.3_MoC%20Information%20security%20risk%20treatment.md) (Information security risk assessment and risk treatment) define the _processes_ and _criteria_ for risk management within the planning stage, while Clauses [8.2](../../MoCs/ISO_27001_2022_8.2_MoC%20Information%20security%20risk%20assessment.md) and [8.3](../../MoCs/ISO_27001_2022_8.3_MoC%20Information%20security%20risk%20treatment.md) define the _operational execution_ and _timing_ for applying those established processes. ### 1. Risk Processes Defined (Planning: Clause 6) diff --git a/Corpus/Standards/ISO27x/Secure Software Development with ISO 27001.md b/Corpus/Standards/ISO27x/about/Secure Software Development with ISO 27001.md similarity index 100% rename from Corpus/Standards/ISO27x/Secure Software Development with ISO 27001.md rename to Corpus/Standards/ISO27x/about/Secure Software Development with ISO 27001.md diff --git a/Corpus/Standards/ISO27x/Tokens.md b/Corpus/Standards/ISO27x/about/Tokens.md similarity index 100% rename from Corpus/Standards/ISO27x/Tokens.md rename to Corpus/Standards/ISO27x/about/Tokens.md diff --git a/Corpus/Standards/ISO27x/Types of Controls.md b/Corpus/Standards/ISO27x/about/Types of Controls.md similarity index 100% rename from Corpus/Standards/ISO27x/Types of Controls.md rename to Corpus/Standards/ISO27x/about/Types of Controls.md diff --git a/Corpus/Standards/ISO27x/Typical ISO 27001 certification costs.md b/Corpus/Standards/ISO27x/about/Typical ISO 27001 certification costs.md similarity index 100% rename from Corpus/Standards/ISO27x/Typical ISO 27001 certification costs.md rename to Corpus/Standards/ISO27x/about/Typical ISO 27001 certification costs.md diff --git a/Corpus/Standards/ISO27x/about/Zero Trust and ISO 27001.md b/Corpus/Standards/ISO27x/about/Zero Trust and ISO 27001.md new file mode 100644 index 0000000..6bac24b --- /dev/null +++ b/Corpus/Standards/ISO27x/about/Zero Trust and ISO 27001.md @@ -0,0 +1,4 @@ +# Zero Trust and ISO 27001 + +[Zero Trust](../📚️%20Literature%20notes/Zero%20Trust.md) is a security principle that can be applied to systems and processes. [ISO 27001 A.13.2 Information transfer](../legacy/ISO%2027001%202013/ISO%2027001%20A.13.2%20Information%20transfer.md) is a method to manage security risks. + diff --git a/Corpus/Standards/ISO27x/legacy/iso27DIY mk I/ISO 27001 in 27000 words.md b/Corpus/Standards/ISO27x/legacy/iso27DIY mk I/ISO 27001 in 27000 words.md index 17dd0a4..00cea7c 100644 --- a/Corpus/Standards/ISO27x/legacy/iso27DIY mk I/ISO 27001 in 27000 words.md +++ b/Corpus/Standards/ISO27x/legacy/iso27DIY mk I/ISO 27001 in 27000 words.md @@ -107,7 +107,7 @@ For example: The scope of the ISMS is also the scope of your ISO 27001 certification, and as such will be visible to your stakeholders. Relevant literature notes: -- [ISO 27001 examples of scope statements](../../ISO%2027001%20examples%20of%20scope%20statements.md) +- [ISO 27001 examples of scope statements](../../about/ISO%2027001%20examples%20of%20scope%20statements.md) # Leadership, roles and responsibilities ISO 27001 demands that top management must show leadership and commitment with regards to the ISMS, by: @@ -200,8 +200,8 @@ The idea is that you apply each and every one of them, unless you can convincing You need to write down which controls from Annex A are, or will be applied by your organisation, in the so called Statement of Applicability. Relevant notes: -- [ISO 27001 Approaching Annex A](../../ISO%2027001%20Approaching%20Annex%20A.md) -- [ISO 27001 Statement of Applicability](../../ISO%2027001%20Statement%20of%20Applicability.md) +- [ISO 27001 Approaching Annex A](../../about/ISO%2027001%20Approaching%20Annex%20A.md) +- [ISO 27001 Statement of Applicability](../../about/ISO%2027001%20Statement%20of%20Applicability.md) # Documenting the ISMS This picture of the ISMS was in one of the first slides: @@ -276,7 +276,7 @@ The certificate is valid for a period of 3 years, during which there will be 2 ' External audits should be performed by accredited certification bodies, listed on the International Accreditation Forum's website. -See [ISO 27001 Certification audit](../../ISO%2027001%20Certification%20audit.md) +See [ISO 27001 Certification audit](../../about/ISO%2027001%20Certification%20audit.md) # Closing diff --git a/Corpus/Standards/ISO27x/legacy/iso27DIY mk I/ISO27DIY Video A.2 Context and Scope - Stakeholders.md b/Corpus/Standards/ISO27x/legacy/iso27DIY mk I/ISO27DIY Video A.2 Context and Scope - Stakeholders.md index 1a63e38..454cab7 100644 --- a/Corpus/Standards/ISO27x/legacy/iso27DIY mk I/ISO27DIY Video A.2 Context and Scope - Stakeholders.md +++ b/Corpus/Standards/ISO27x/legacy/iso27DIY mk I/ISO27DIY Video A.2 Context and Scope - Stakeholders.md @@ -8,7 +8,7 @@ In this video you'll learn how to create a stakeholder analysis, identifying the > C 4.2: interested parties relevant to the ISMS, and their requirements relevant to information security, including legal, regulatory and contractual obligations. - [ISO 31000 5.4.1](../../ISO31000-5.4.1-Understanding-the-organization-and-its-context.md): + [ISO 31000 5.4.1](../../about/ISO31000-5.4.1-Understanding-the-organization-and-its-context.md): > Examine "external stakeholders’ relationships, perceptions, values, needs and expectations" diff --git a/Corpus/Standards/ISO27x/legacy/iso27DIY mk I/ISO27DIY Video A.3 Context and Scope - Regulations and Contracts.md b/Corpus/Standards/ISO27x/legacy/iso27DIY mk I/ISO27DIY Video A.3 Context and Scope - Regulations and Contracts.md index 0db2b7f..a4bd70f 100644 --- a/Corpus/Standards/ISO27x/legacy/iso27DIY mk I/ISO27DIY Video A.3 Context and Scope - Regulations and Contracts.md +++ b/Corpus/Standards/ISO27x/legacy/iso27DIY mk I/ISO27DIY Video A.3 Context and Scope - Regulations and Contracts.md @@ -8,7 +8,7 @@ In this video you'll learn ... > C 4.2: interested parties relevant to the ISMS, and their requirements relevant to information security, including legal, regulatory and contractual obligations. > -> See also [ISO 31000 5.4.1](../../ISO31000-5.4.1-Understanding-the-organization-and-its-context.md) +> See also [ISO 31000 5.4.1](../../about/ISO31000-5.4.1-Understanding-the-organization-and-its-context.md) diff --git a/Corpus/Standards/ISO27x/legacy/iso27DIY mk I/ISO27DIY Video A.4 Context and Scope - Internal issues.md b/Corpus/Standards/ISO27x/legacy/iso27DIY mk I/ISO27DIY Video A.4 Context and Scope - Internal issues.md index 64d2e28..28723da 100644 --- a/Corpus/Standards/ISO27x/legacy/iso27DIY mk I/ISO27DIY Video A.4 Context and Scope - Internal issues.md +++ b/Corpus/Standards/ISO27x/legacy/iso27DIY mk I/ISO27DIY Video A.4 Context and Scope - Internal issues.md @@ -8,7 +8,7 @@ In this video you'll learn how to document the *internal* issues in your organiz > C 4.1: external and internal issues relevant to organizational goals and the performance of the ISMS > ->See also [ISO 31000 5.4.1](../../ISO31000-5.4.1-Understanding-the-organization-and-its-context.md): +>See also [ISO 31000 5.4.1](../../about/ISO31000-5.4.1-Understanding-the-organization-and-its-context.md): > >Examining the organization’s internal context may include, but is not limited to: > - vision, mission and values; diff --git a/Corpus/Standards/ISO27x/legacy/iso27DIY mk I/ISO27DIY Video A.5 Context and Scope - Scope statement.md b/Corpus/Standards/ISO27x/legacy/iso27DIY mk I/ISO27DIY Video A.5 Context and Scope - Scope statement.md index f293c04..b5242cb 100644 --- a/Corpus/Standards/ISO27x/legacy/iso27DIY mk I/ISO27DIY Video A.5 Context and Scope - Scope statement.md +++ b/Corpus/Standards/ISO27x/legacy/iso27DIY mk I/ISO27DIY Video A.5 Context and Scope - Scope statement.md @@ -6,7 +6,7 @@ > > The scope shall be available as documented information. > -> See also [ISO 31000 5.4.1](../../ISO31000-5.4.1-Understanding-the-organization-and-its-context.md) +> See also [ISO 31000 5.4.1](../../about/ISO31000-5.4.1-Understanding-the-organization-and-its-context.md) You've now covered Clause 4.3: [Determining the scope of the ISMS](../ISO%2027001%202013/ISO%2027001_OT%20C%204%20Context%20of%20the%20organization.md#4%203%20Determining%20the%20scope%20of%20the%20information%20security%20management%20system). diff --git a/Corpus/Standards/ISO27x/legacy/iso27DIY mk I/ISO27DIY Video B.1 Processes and Assets - Business processes.md b/Corpus/Standards/ISO27x/legacy/iso27DIY mk I/ISO27DIY Video B.1 Processes and Assets - Business processes.md index 6e1046d..29215ac 100644 --- a/Corpus/Standards/ISO27x/legacy/iso27DIY mk I/ISO27DIY Video B.1 Processes and Assets - Business processes.md +++ b/Corpus/Standards/ISO27x/legacy/iso27DIY mk I/ISO27DIY Video B.1 Processes and Assets - Business processes.md @@ -6,7 +6,7 @@ > > The scope shall be available as documented information. > -> See also [ISO 31000 5.4.1](../../ISO31000-5.4.1-Understanding-the-organization-and-its-context.md) +> See also [ISO 31000 5.4.1](../../about/ISO31000-5.4.1-Understanding-the-organization-and-its-context.md) You've now PARTIALLY covered Clause 4.3: [Determining the scope of the ISMS](../ISO%2027001%202013/ISO%2027001_OT%20C%204%20Context%20of%20the%20organization.md#4%203%20Determining%20the%20scope%20of%20the%20information%20security%20management%20system). diff --git a/Corpus/Standards/ISO27x/legacy/iso27DIY mk I/ISO27DIY Video B.2 Processes and Assets - Interfaces and dependencies.md b/Corpus/Standards/ISO27x/legacy/iso27DIY mk I/ISO27DIY Video B.2 Processes and Assets - Interfaces and dependencies.md index 029db8b..8be628d 100644 --- a/Corpus/Standards/ISO27x/legacy/iso27DIY mk I/ISO27DIY Video B.2 Processes and Assets - Interfaces and dependencies.md +++ b/Corpus/Standards/ISO27x/legacy/iso27DIY mk I/ISO27DIY Video B.2 Processes and Assets - Interfaces and dependencies.md @@ -6,7 +6,7 @@ > > The scope shall be available as documented information. > -> See also [ISO 31000 5.4.1](../../ISO31000-5.4.1-Understanding-the-organization-and-its-context.md) +> See also [ISO 31000 5.4.1](../../about/ISO31000-5.4.1-Understanding-the-organization-and-its-context.md) diff --git a/Corpus/Standards/NIS 2 Cbw/NIS 2 Directive and ISO 27001-2022.md b/Corpus/Standards/NIS 2 Cbw/NIS 2 Directive and ISO 27001-2022.md index 9b568e7..94e0270 100644 --- a/Corpus/Standards/NIS 2 Cbw/NIS 2 Directive and ISO 27001-2022.md +++ b/Corpus/Standards/NIS 2 Cbw/NIS 2 Directive and ISO 27001-2022.md @@ -2,4 +2,4 @@ Relevant articles of the NIS 2 are linked to clauses and controls of the ISO 27001:2022 -![](../ISO27x/NIS_2_and_ISO_27001_2022.pdf) \ No newline at end of file +![](../ISO27x/about/NIS_2_and_ISO_27001_2022.pdf) \ No newline at end of file diff --git a/Corpus/Standards/NIS 2 Cbw/NIS 2 Index.md b/Corpus/Standards/NIS 2 Cbw/NIS 2 Index.md index 00378c3..453cc6f 100644 --- a/Corpus/Standards/NIS 2 Cbw/NIS 2 Index.md +++ b/Corpus/Standards/NIS 2 Cbw/NIS 2 Index.md @@ -8,7 +8,7 @@ [NIS 2 maatregelen en ISO 27002/BIO](https://www.digitaleoverheid.nl/overzicht-van-alle-onderwerpen/nis2-richtlijn/mapping-nis2-maatregelen/) – Digitale overheid -[PDF](../ISO27x/NIS_2_and_ISO_27001_2022.pdf): NIS 2 Directive and ISO 27001 – Andrey Prozorov +[PDF](../ISO27x/about/NIS_2_and_ISO_27001_2022.pdf): NIS 2 Directive and ISO 27001 – Andrey Prozorov [PDF](NIS2_EN.pdf): NIS 2 Original Text EN [PDF](NIS2_NL.pdf): NIS 2 Brontekst diff --git a/Corpus/Standards/SURF Handreiking risicobeoordeling 2.0.pdf b/Corpus/Standards/SURF/SURF Handreiking risicobeoordeling 2.0.pdf similarity index 100% rename from Corpus/Standards/SURF Handreiking risicobeoordeling 2.0.pdf rename to Corpus/Standards/SURF/SURF Handreiking risicobeoordeling 2.0.pdf diff --git a/Corpus/Standards/SURF Toolkit risicobeoordeling kaartjes workshop.docx b/Corpus/Standards/SURF/SURF Toolkit risicobeoordeling kaartjes workshop.docx similarity index 100% rename from Corpus/Standards/SURF Toolkit risicobeoordeling kaartjes workshop.docx rename to Corpus/Standards/SURF/SURF Toolkit risicobeoordeling kaartjes workshop.docx diff --git a/Corpus/Standards/SURF Toolkit risicobeoordeling.md b/Corpus/Standards/SURF/SURF Toolkit risicobeoordeling.md similarity index 92% rename from Corpus/Standards/SURF Toolkit risicobeoordeling.md rename to Corpus/Standards/SURF/SURF Toolkit risicobeoordeling.md index 38a3c4a..0c6ae83 100644 --- a/Corpus/Standards/SURF Toolkit risicobeoordeling.md +++ b/Corpus/Standards/SURF/SURF Toolkit risicobeoordeling.md @@ -10,7 +10,7 @@ Bron: [SURF website](https://sec.surf.nl/asset/toolkit-risicobeoordeling/) ![Workshop slides](SURF%20risicobeoordeling%20workshop%20slides.pptx) **Excel template risicobeoordeling** -![](../ISMS/template%20risicobeoordeling.xlsx) +![](../../ISMS/template%20risicobeoordeling.xlsx) Met tabbladen voor: - Kroonjuwelen - Risico scenario's diff --git a/Corpus/Standards/SURF risicobeoordeling workshop slides.pptx b/Corpus/Standards/SURF/SURF risicobeoordeling workshop slides.pptx similarity index 100% rename from Corpus/Standards/SURF risicobeoordeling workshop slides.pptx rename to Corpus/Standards/SURF/SURF risicobeoordeling workshop slides.pptx diff --git a/Corpus/Standards/ISO27x/SURFaudit toetsingskader.md b/Corpus/Standards/SURF/SURFaudit toetsingskader.md similarity index 100% rename from Corpus/Standards/ISO27x/SURFaudit toetsingskader.md rename to Corpus/Standards/SURF/SURFaudit toetsingskader.md diff --git a/Corpus/Standards/other/Infosec frameworks and regulations.md b/Corpus/Standards/other/Infosec frameworks and regulations.md index 3f8caec..a569068 100644 --- a/Corpus/Standards/other/Infosec frameworks and regulations.md +++ b/Corpus/Standards/other/Infosec frameworks and regulations.md @@ -21,9 +21,9 @@ See also: - [ISO 27k family](../../../../iso27DIY-gis/reference/Examples/ISO%2027k%20family.md) - [ISO_27001_2013_EN_Index](../ISO27x/legacy/ISO%2027001%202013/ISO_27001_2013_EN_Index.md) - [ISO_27001_2017_NL_Index](../ISO27x/legacy/ISO%2027001%202017%20NL/ISO_27001_2017_NL_Index.md) -- [ISO_27001_2022_Index EXT](../ISO27x/ISO_27001_2022_Index%20EXT.md) +- [ISO_27001_2022_Index EXT](../ISO27x/about/ISO_27001_2022_Index%20EXT.md) - [ISO_27002_2022_NL_Index](../ISO27x/OST/ISO_27002_2022_NL_Index.md) -- [ISO31000-5.4.1-Understanding-the-organization-and-its-context](../ISO27x/ISO31000-5.4.1-Understanding-the-organization-and-its-context.md) +- [ISO31000-5.4.1-Understanding-the-organization-and-its-context](../ISO27x/about/ISO31000-5.4.1-Understanding-the-organization-and-its-context.md) - [NEN7510 Risicos](../ISO27x/OST/7510/NEN7510%20Risicos.md) - [NIST CSF 2.0](../NIST/NIST%20CSF%202.0.md) - [Secure Controls Framework SCF](Secure%20Controls%20Framework%20SCF.md) diff --git a/Corpus/Standards/other/Privacy frameworks list.md b/Corpus/Standards/other/Privacy frameworks list.md index 710b044..1de635d 100644 --- a/Corpus/Standards/other/Privacy frameworks list.md +++ b/Corpus/Standards/other/Privacy frameworks list.md @@ -2,7 +2,7 @@ [BC_5701_Hoofstukken_Normtekst](../BC%205701/BC_5701_Hoofstukken_Normtekst.md) [NIST Privacy Framework (PF)](../NIST/NIST%20Privacy%20Framework%20(PF).md) -[Privacy in ISO 27k](../ISO27x/Privacy%20in%20ISO%2027k.md) +[Privacy in ISO 27k](../ISO27x/about/Privacy%20in%20ISO%2027k.md) Related: - [Privacy protection in Databases](../../../Marketing/publications/Scratch%20file/Privacy%20protection%20in%20Databases.md) diff --git a/Corpus/Standards/other/Standards and Regulations for information security.md b/Corpus/Standards/other/Standards and Regulations for information security.md index ce02741..88f4a7c 100644 --- a/Corpus/Standards/other/Standards and Regulations for information security.md +++ b/Corpus/Standards/other/Standards and Regulations for information security.md @@ -1,6 +1,6 @@ [ISO 27k family](../../../../iso27DIY-gis/reference/Examples/ISO%2027k%20family.md) [ISO_27001_2013_EN_Index](../ISO27x/legacy/ISO%2027001%202013/ISO_27001_2013_EN_Index.md) - [ISO_27001_2022_Index EXT](../ISO27x/ISO_27001_2022_Index%20EXT.md) + [ISO_27001_2022_Index EXT](../ISO27x/about/ISO_27001_2022_Index%20EXT.md) [IEC 62443 Cybersecurity for operational technology in automation and control systems](IEC%2062443%20Cybersecurity%20for%20operational%20technology%20in%20automation%20and%20control%20systems.md) **EU regulations:** diff --git a/business-server/Easy-Appointments.md b/business-server/Easy-Appointments.md new file mode 100644 index 0000000..fcd3762 --- /dev/null +++ b/business-server/Easy-Appointments.md @@ -0,0 +1,67 @@ +# Easy!Appointments docker-compose.yaml example + +https://github.com/alextselegidis/easyappointments + +``` +services: + easyappointments: + image: alextselegidis/easyappointments:${APP_VERSION} + restart: always + ports: + - ${APP_PORT}:80 + environment: + - BASE_URL=${SITE_URL} + - DEBUG_MODE=FALSE + - DB_HOST=mysql + - DB_NAME=easyappointments + - DB_USERNAME=${DB_USER} + - DB_PASSWORD=${DB_PASS} + - MAIL_PROTOCOL=mail + - MAIL_SMTP_DEBUG=0 + - MAIL_SMTP_AUTH=0 + - MAIL_SMTP_HOST=${EMAIL_SMTP_HOST} + - MAIL_SMTP_USER=${EMAIL_SMTP_USER} + - MAIL_SMTP_PASS=${EMAIL_SMTP_PASS} + - MAIL_SMTP_CRYPTO=tls + - MAIL_SMTP_PORT=${EMAIL_SMTP_PORT} + - MAIL_FROM_ADDRESS=${EMAIL_SMTP_FROM} + - MAIL_FROM_NAME=${EMAIL_SMTP_FROM} + - MAIL_REPLY_TO_ADDRESS=${EMAIL_SMTP_FROM} + + mysql: + image: mysql:8.4 + restart: always + command: [ + '--mysql-native-password=ON', + ] + environment: + - MYSQL_ROOT_PASSWORD=${DB_PASS} + - MYSQL_DATABASE=easyappointments + - MYSQL_USER=${DB_USER} + - MYSQL_PASSWORD=${DB_PASS} + volumes: + - mysql:/var/lib/mysql + + db-backup: + image: tiredofit/db-backup + volumes: + - db_backup:/backup + environment: + - CONTAINER_ENABLE_MONITORING=false + - DB_HOST=mysql + - DB_TYPE=mariadb + - DB_NAME=easyappointments + - DB_USER=${DB_USER} + - DB_PASS=${DB_PASS} + - DEFAULT_DB_DUMP_FREQ=1440 + - DEFAULT_DB_DUMP_BEGIN=0000 + - DEFAULT_COMPRESSION=BZ + - DB_CLEANUP_TIME=8640 + - MD5=TRUE + - DEFAULT_BACKUP_BEGIN=+1 + restart: always + +volumes: + mysql: + db_backup: +``` \ No newline at end of file diff --git a/vps@hostinger/Hostinger How-to's.md b/business-server/Hostinger How-to's.md similarity index 100% rename from vps@hostinger/Hostinger How-to's.md rename to business-server/Hostinger How-to's.md diff --git a/business-server/Only-Office.md b/business-server/Only-Office.md new file mode 100644 index 0000000..b6017fe --- /dev/null +++ b/business-server/Only-Office.md @@ -0,0 +1,34 @@ +Here’s a **Docker Compose** file for ONLYOFFICE Workspace Community Edition, configured to work with your existing nginx setup and avoiding ports 3000/3001. This setup uses ports **3002** (for the Community Server) and **3003** (for the Document Server), which you can proxy via nginx to `docs.iso27diy.com`. + +```yaml +version: '3.8' + +services: + onlyoffice-community-server: + image: onlyoffice/communityserver:latest + container_name: onlyoffice-community-server + restart: always + environment: + - DOCUMENT_SERVER_PORT_3003=3003 + volumes: + - ./community-data:/var/www/onlyoffice/Data + - ./community-logs:/var/log/onlyoffice + ports: + - "3002:80" + depends_on: + - onlyoffice-document-server + + onlyoffice-document-server: + image: onlyoffice/documentserver:latest + container_name: onlyoffice-document-server + restart: always + environment: + - JWT_SECRET=your_jwt_secret_here # Change this to a secure random string + volumes: + - ./document-data:/var/www/onlyoffice/Data + - ./document-logs:/var/log/onlyoffice + ports: + - "3003:80" + cap_add: + - SYS_ADMIN +``` diff --git a/vps@hostinger/VPS administration.md b/business-server/VPS administration.md similarity index 100% rename from vps@hostinger/VPS administration.md rename to business-server/VPS administration.md diff --git a/vps@hostinger/VPS install playbook.md b/business-server/VPS install playbook for Umami.md similarity index 100% rename from vps@hostinger/VPS install playbook.md rename to business-server/VPS install playbook for Umami.md diff --git a/vps@hostinger/VPS security.md b/business-server/VPS security.md similarity index 100% rename from vps@hostinger/VPS security.md rename to business-server/VPS security.md diff --git a/vps@hostinger/VPS specs.md b/business-server/VPS specs.md similarity index 94% rename from vps@hostinger/VPS specs.md rename to business-server/VPS specs.md index 8f87b0e..49b1c7b 100644 --- a/vps@hostinger/VPS specs.md +++ b/business-server/VPS specs.md @@ -1,4 +1,4 @@ -# VPS configuratie +# VPS specificaties - srv1119777.hstgr.cloud - ssh root@72.61.188.15 @@ -23,6 +23,6 @@ Docker draait ook, natuurlijk - [ ] regelmatig updates en backups draaien - [ ] logs draaien voor afwijkingen -## Samenvatting 11 april 2026 + diff --git a/vps@hostinger/VPS stack.md b/business-server/VPS stack.md similarity index 100% rename from vps@hostinger/VPS stack.md rename to business-server/VPS stack.md diff --git a/marketing/publications/Scratch file/Data classification - how to make labels stick.md b/marketing/publications/Scratch file/Data classification - how to make labels stick.md index ac96efa..31fa50d 100644 --- a/marketing/publications/Scratch file/Data classification - how to make labels stick.md +++ b/marketing/publications/Scratch file/Data classification - how to make labels stick.md @@ -2,5 +2,5 @@ Data travels; how to make labels stick? -Links to the [Privacy in ISO 27001](../../../Corpus/Standards/ISO27x/Privacy%20in%20ISO%2027001.md) issue of [Data Provenance](../../../Corpus/Standards/AVG/Data%20Provenance.md) . +Links to the [Privacy in ISO 27001](../../../Corpus/Standards/ISO27x/about/Privacy%20in%20ISO%2027001.md) issue of [Data Provenance](../../../Corpus/Standards/AVG/Data%20Provenance.md) .