removed emoji's in folders and links

2026-05-11 16:02:08 +02:00 · 2026-05-11 16:02:08 +02:00 · 9b7b3a3a85
commit 9b7b3a3a85
parent 6992777c0e
88 changed files with 1476 additions and 104 deletions
--- a/Disruption.md
+++ b/Disruption.md
@ -4,5 +4,5 @@
 [](../Attachments/TLP_Impact_matrix_NL.xlsx)
 [BCP_Bedrijfscontinuïteitsplanning](../📚️%20Literature%20notes/BCP_Bedrijfscontinuïteitsplanning.md)
-[Business Impact Analysis (BIA)](../🎇%20Sparks/Business%20Impact%20Analysis%20(BIA).md)
+[Business Impact Analysis (BIA)](..//Business%20Impact%20Analysis%20(BIA).md)
--- a/Corpus/Drafts
+++ b/Corpus/Drafts
@ -12,4 +12,4 @@ Articulate the risk appetite to:
 See [Topical InfoSec Kanban’s](../Literature%20notes/Topical%20InfoSec%20Kanban’s.md) for inspiration.
-See also [Risk tolerance](../🎇%20Sparks/Risk%20tolerance.md)
+See also [Risk tolerance](..//Risk%20tolerance.md)
--- a/Ideas/Vulnerability.md
+++ b/Ideas/Vulnerability.md
@ -4,8 +4,8 @@ A vulnerability is a weakness that exposes an asset to possible compromise. Weak
 See also:
- [Assets](../🎇%20Sparks/Assets.md)
+- [Assets](..//Assets.md)
- [Risks](../🎇%20Sparks/Risks.md)
+- [Risks](..//Risks.md)
 - [Threat](../📚️%20Literature%20notes/Threat.md)
 - [Vulnerability Disclosure Policy](../Sparks/Vulnerability%20Disclosure%20Policy.md)
 - [Dealing with a reported application vulnerability Log4j](Dealing%20with%20a%20reported%20application%20vulnerability%20Log4j.md)
--- a/Corpus/Information
+++ b/Corpus/Information
@ -5,71 +5,71 @@ Related:
 tags:
  - type/MoC
 ---
-[Assets](🎇%20Sparks/Assets.md)
+[Assets](/Assets.md)
 	[NIST Asset Types](📚️%20Literature%20notes/NIST%20Asset%20Types.md)
 	[Asset lifecycle](📚️%20Literature%20notes/Asset%20lifecycle.md)
-	[Asset ownership](🎇%20Sparks/Asset%20ownership.md)
+	[Asset ownership](/Asset%20ownership.md)
 	[[Asset ownership DEL]]
 	[Assets, Vulnerabilities, Threats, Risks](📚️%20Literature%20notes/Assets,%20Vulnerabilities,%20Threats,%20Risks.md)
-[Assets, Vulnerabilities, Threats, Risks](🎇%20Sparks/Assets,%20Vulnerabilities,%20Threats,%20Risks.md)
+[Assets, Vulnerabilities, Threats, Risks](/Assets,%20Vulnerabilities,%20Threats,%20Risks.md)
 [Attack Surface Analysis](📚️%20Literature%20notes/Attack%20Surface%20Analysis.md)
 [Authentication](Standards/ISO27x/Authentication.md)
-	[Multi-factor authentication](🎇%20Sparks/Multi-factor%20authentication.md) (MFA)
+	[Multi-factor authentication](/Multi-factor%20authentication.md) (MFA)
-	[Passwordless Authentication](🎇%20Sparks/Passwordless%20Authentication.md)
+	[Passwordless Authentication](/Passwordless%20Authentication.md)
-	[Risk-Based Authentication](🎇%20Sparks/Risk-Based%20Authentication.md)
+	[Risk-Based Authentication](/Risk-Based%20Authentication.md)
 	[Single Sign On (SSO)](📚️%20Literature%20notes/Single%20Sign%20On%20(SSO).md)
-	[Tokens](🎇%20Sparks/Tokens.md)
+	[Tokens](/Tokens.md)
 [Authorization](Standards/ISO27x/Authorization.md)
-	[Access Control](🎇%20Sparks/Access%20Control.md)
+	[Access Control](/Access%20Control.md)
-[Awareness](🎇%20Sparks/Awareness.md)
+[Awareness](/Awareness.md)
 [BCP_Bedrijfscontinuïteitsplanning](📚️%20Literature%20notes/BCP_Bedrijfscontinuïteitsplanning.md)
-	[Business Impact Analysis (BIA)](🎇%20Sparks/Business%20Impact%20Analysis%20(BIA).md)
+	[Business Impact Analysis (BIA)](/Business%20Impact%20Analysis%20(BIA).md)
-	[Disaster Recovery Planning](🎇%20Sparks/Disaster%20Recovery%20Planning.md)
+	[Disaster Recovery Planning](/Disaster%20Recovery%20Planning.md)
 [Change management MoC](MoCs/Change%20management%20MoC.md)
-[Classification](🎇%20Sparks/Classification.md)
+[Classification](/Classification.md)
-[Compliance](🎇%20Sparks/Compliance.md)
+[Compliance](/Compliance.md)
 [Data Breach](💡Permanent%20ideas/Data%20Breach.md)
 [Data Governance](📚️%20Literature%20notes/Data%20Governance.md)
 Frameworks
 	[ISO 27k family](../../iso27DIY-gis/reference/Examples/ISO%2027k%20family.md)
 	[NIST articles list](Standards/NIST/NIST%20articles%20list.md)
-[Governance](🎇%20Sparks/Governance.md)
+[Governance](/Governance.md)
 [[Hardening]]
-[Identity and Access Management (IAM)](💡Drafts%20and%20Ideas/Identity%20and%20Access%20Management%20(IAM).md)
+[Identity and Access Management (IAM)](Drafts%20and%20Ideas/Identity%20and%20Access%20Management%20(IAM).md)
-	[Identification](💡Drafts%20and%20Ideas/Identification.md)
+	[Identification](Drafts%20and%20Ideas/Identification.md)
 	[Authentication](Standards/ISO27x/Authentication.md)
 	[Authorization](Standards/ISO27x/Authorization.md)
 Impact
 	[Change management MoC](MoCs/Change%20management%20MoC.md)
-	[Impact of Disruption](💡Drafts%20and%20Ideas/Impact%20of%20Disruption.md)
+	[Impact of Disruption](Drafts%20and%20Ideas/Impact%20of%20Disruption.md)
-[Incidents](🎇%20Sparks/Incidents.md)
+[Incidents](/Incidents.md)
 [Maturity Models](📚️%20Literature%20notes/Maturity%20Models.md)
 [Metrics](📚️%20Literature%20notes/InfoSec%20Metrics.md)
-[Operational Technology](💡Drafts%20and%20Ideas/Operational%20Technology.md) or OT Security
+[Operational Technology](Drafts%20and%20Ideas/Operational%20Technology.md) or OT Security
 [Policies](📚️%20Literature%20notes/Policies.md)
 [[Posture Management]]
-[Ransomware](🎇%20Sparks/Ransomware.md)
+[Ransomware](/Ransomware.md)
-[Risks](🎇%20Sparks/Risks.md)
+[Risks](/Risks.md)
-	[Risk analysis](🎇%20Sparks/Risk%20analysis.md)
+	[Risk analysis](/Risk%20analysis.md)
-	[Risk appetite](💡Drafts%20and%20Ideas/Risk%20appetite.md)
+	[Risk appetite](Drafts%20and%20Ideas/Risk%20appetite.md)
-	[Risk inventories](🎇%20Sparks/Risk%20inventories.md)
+	[Risk inventories](/Risk%20inventories.md)
-	[Risk management](🎇%20Sparks/Risk%20management.md)
+	[Risk management](/Risk%20management.md)
-	[Risk ownership](🎇%20Sparks/Risk%20ownership.md)
+	[Risk ownership](/Risk%20ownership.md)
-	[Risk ownership](🎇%20Sparks/Risk%20ownership.md)
+	[Risk ownership](/Risk%20ownership.md)
-	[Risk prioritization](🎇%20Sparks/Risk%20prioritization.md)
+	[Risk prioritization](/Risk%20prioritization.md)
-	[Risk tolerance](🎇%20Sparks/Risk%20tolerance.md)
+	[Risk tolerance](/Risk%20tolerance.md)
-	[Risk treatment](🎇%20Sparks/Risk%20treatment.md)
+	[Risk treatment](/Risk%20treatment.md)
-	[Risks vs Threats vs Vulnerabilities](🎇%20Sparks/Risks%20vs%20Threats%20vs%20Vulnerabilities.md)
+	[Risks vs Threats vs Vulnerabilities](/Risks%20vs%20Threats%20vs%20Vulnerabilities.md)
-[Roles and Responsibilities](🎇%20Sparks/Roles%20and%20Responsibilities.md)
+[Roles and Responsibilities](/Roles%20and%20Responsibilities.md)
 [Threat](📚️%20Literature%20notes/Threat.md)
-	[Threat Intelligence](🎇%20Sparks/Threat%20Intelligence.md)
+	[Threat Intelligence](/Threat%20Intelligence.md)
 	[Security Threat Modeling](📚️%20Literature%20notes/Security%20Threat%20Modeling.md)
 	[Privacy Threat Modeling](📚️%20Literature%20notes/Privacy%20Threat%20Modeling.md)
-	[AI Threat Modeling](🎇%20Sparks/AI%20Threat%20Modeling.md)
+	[AI Threat Modeling](/AI%20Threat%20Modeling.md)
 	[Threat Catalogues](📚️%20Literature%20notes/Threat%20Catalogues.md)
-[Vendor security MoC](🎇%20Sparks/Vendor%20security%20MoC.md) or Supply chain security
+[Vendor security MoC](/Vendor%20security%20MoC.md) or Supply chain security
-[Vulnerability](💡Drafts%20and%20Ideas/Vulnerability.md)
+[Vulnerability](Drafts%20and%20Ideas/Vulnerability.md)
-	[Bug bounty program](🎇%20Sparks/Bug%20bounty%20program.md)
+	[Bug bounty program](/Bug%20bounty%20program.md)
 [Zero Trust](📚️%20Literature%20notes/Zero%20Trust.md)
--- a/Corpus/Literature
+++ b/Corpus/Literature
@ -8,10 +8,10 @@ A risk occurs when there's a chance of an asset being compromised, through the e
 Adapted from source: [Vigilant Software](https://www.vigilantsoftware.co.uk/blog/risk-terminology-understanding-assets-threats-and-vulnerabilities), retrieved December 8, 2021.
-[Assets](../🎇%20Sparks/Assets.md)
+[Assets](../Sparks/Assets.md)
-[Vulnerability](../💡Drafts%20and%20Ideas/Vulnerability.md)
+[Vulnerability](../Drafts%20and%20Ideas/Vulnerability.md)
 [Threat](Threat.md)
-[Risks](../🎇%20Sparks/Risks.md)
+[Risks](../Sparks/Risks.md)
--- a/notes/BCP_Bedrijfscontinuïteitsplanning.md
+++ b/notes/BCP_Bedrijfscontinuïteitsplanning.md
@ -14,7 +14,7 @@ Producten:
 Bedrijfscontinuïteitsplanning is een continu proces, met als doel het implementeren en onderhouden van beleid, procedures en processen om de impact van verstoringen te beheersen. Met andere woorden: bedrijfscontinuïteitsplanning richt zich op de continuïteit van bedrijfsprocessen, zo nodig met andere middelen.
-Belangrijke onderdelen van Bedrijfscontinuïteitsplanning zijn de Bedrijfsimpact Analyse ([BIA](../🎇%20Sparks/Business%20Impact%20Analysis%20(BIA).md)) en het Herstelplan ('Disaster Recovery Plan' / [DRP](../🎇%20Sparks/Disaster%20Recovery%20Planning.md)).
+Belangrijke onderdelen van Bedrijfscontinuïteitsplanning zijn de Bedrijfsimpact Analyse ([BIA](../Sparks/Business%20Impact%20Analysis%20(BIA).md)) en het Herstelplan ('Disaster Recovery Plan' / [DRP](..//Disaster%20Recovery%20Planning.md)).
 De BIA richt zich op het identificeren van de impact van verstoringen op de bedrijfsprocessen, en het Herstelplan richt zich op het herstel van de normale bedrijfsprocessen na een verstoring en de eventuele inzet van alternatieve middelen of werkwijzen .
 Zie ook: [Het belang van een Bedrijfscontinuïteitsplan](../Sparks/Belang%20van%20een%20BCP.md) / [The importance of having a business continuity plan](../Sparks/Importance%20of%20a%20BCP.md).
@ -34,7 +34,7 @@ Het proces (Beleid) volgens welke dit hele plan tot stand komt en beoordeeld/her
 ## Analyse
-Zie: [Business Impact Analysis (BIA)](../🎇%20Sparks/Business%20Impact%20Analysis%20(BIA).md)
+Zie: [Business Impact Analysis (BIA)](../Sparks/Business%20Impact%20Analysis%20(BIA).md)
 Stappen:
 - Bepalen bedrijfskritische processen (prioriteiten bepalen) en informatie-assets
@ -141,7 +141,7 @@ Scenario's opstellen o.b.v. risicoanalyse
 ## Links
 See also:
- [Disaster Recovery Planning](../🎇%20Sparks/Disaster%20Recovery%20Planning.md)
+- [Disaster Recovery Planning](..//Disaster%20Recovery%20Planning.md)
 - [Checklist for auditing Business Continuity and Disaster Recovery](Checklists%20Gerardus%20Blokdyk/Checklist%20for%20auditing%20Business%20Continuity%20and%20Disaster%20Recovery.md)
 - [Ransomware Playbook](../Sparks/Ransomware%20Playbook.md)
--- a/Corpus/Literature
+++ b/Corpus/Literature
@ -1,6 +1,6 @@
 Related:
 - [a-5.17-Authentication-information](../Standards/ISO27x/OST/27002/EN/a-5.17-Authentication-information.md)
- [Multi-factor authentication](../🎇%20Sparks/Multi-factor%20authentication.md)
+- [Multi-factor authentication](..//Multi-factor%20authentication.md)
 Daniel Miessler:
 - [The Consumer Authentication Strength Maturity Model (CASMM) V6](https://danielmiessler.com/blog/casmm-consumer-authentication-security-maturity-model/)
--- a/Corpus/Literature
+++ b/Corpus/Literature
@ -2,6 +2,6 @@ Ransomware Vulnerability Warning Pilot (RVWP) | CISA
 https://www.cisa.gov/stopransomware/Ransomware-Vulnerability-Warning-Pilot
 Related:
-[Assets, Vulnerabilities, Threats, Risks](../🎇%20Sparks/Assets,%20Vulnerabilities,%20Threats,%20Risks.md)
+[Assets, Vulnerabilities, Threats, Risks](..//Assets,%20Vulnerabilities,%20Threats,%20Risks.md)
-[Vulnerability](../💡Drafts%20and%20Ideas/Vulnerability.md)
+[Vulnerability](../Drafts%20and%20Ideas/Vulnerability.md)
--- a/Blokdyk/Checklist
+++ b/Blokdyk/Checklist
@ -9,7 +9,7 @@ Relevant ISO 27001 clauses/controls:
 - [ISO 27001 A 18 Compliance](../../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001%20A%2018%20Compliance.md)
 Related:
- [Identity and Access Management (IAM)](../../💡Drafts%20and%20Ideas/Identity%20and%20Access%20Management%20(IAM).md)
+- [Identity and Access Management (IAM)](../../Drafts%20and%20Ideas/Identity%20and%20Access%20Management%20(IAM).md)
 ## Organized by Key Themes: Identity, Access, Cloud, Security, Management, Data, Network, Risk, Development, Project:
--- a/Blokdyk/Checklist
+++ b/Blokdyk/Checklist
@ -11,7 +11,7 @@ All of them – just to link this note somewhere:
 - [ISO 27001 A 18 Compliance](../../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001%20A%2018%20Compliance.md)
 Related:
- [Vendor security MoC](../../🎇%20Sparks/Vendor%20security%20MoC.md)
+- [Vendor security MoC](../..//Vendor%20security%20MoC.md)
 - [ISO 27k family](../../../../iso27DIY-gis/reference/examples/ISO%2027k%20family.md): ISO 27017, ISO 27018
 ## Organized By Key Themes: Security, Management, Risk, Cloud, Data, Software, Development, Technology, Network and Project:
--- a/Blokdyk/Checklist
+++ b/Blokdyk/Checklist
@ -14,7 +14,7 @@ Relevant ISO 27002:2022 clauses/controls:
 - [a-5.7-Threat-intelligence](../../Standards/ISO27x/OST/27002/EN/a-5.7-Threat-intelligence.md)
 Related:
- [Threat Intelligence](../../🎇%20Sparks/Threat%20Intelligence.md)
+- [Threat Intelligence](../..//Threat%20Intelligence.md)
 ## Cyber Threat Intelligence: Ask This;
--- a/Blokdyk/Checklist
+++ b/Blokdyk/Checklist
@ -9,7 +9,7 @@ Relevant ISO 27001 clauses/controls:
 - [ISO 27001 A.14.2 Security in development and support processes](../../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001%20A.14.2%20Security%20in%20development%20and%20support%20processes.md)
 Related:
- [Operational Technology](../../💡Drafts%20and%20Ideas/Operational%20Technology.md)
+- [Operational Technology](../../Drafts%20and%20Ideas/Operational%20Technology.md)
 - [DevSecOps and ISO 27k](../../Sparks/DevSecOps%20and%20ISO%2027k.md)
 ## DevOps IoT: Ask This;
--- a/Blokdyk/Checklist
+++ b/Blokdyk/Checklist
@ -124,7 +124,7 @@ Administer and maintain security systems in the cybersecurity security operation
 How do you identify which assets are being compromised and what type of data is involved?
-Warrant that your organization is involved in network security environment (Security Operations Center, Security Incident Response Team, or Cyber Security Incident Response) investigating targeted intrusions through complex network segments or Be certain that your company is involved in [Operational Technology](../../💡Drafts%20and%20Ideas/Operational%20Technology.md) engineering and security concepts. 
+Warrant that your organization is involved in network security environment (Security Operations Center, Security Incident Response Team, or Cyber Security Incident Response) investigating targeted intrusions through complex network segments or Be certain that your company is involved in [Operational Technology](../../Drafts%20and%20Ideas/Operational%20Technology.md) engineering and security concepts. 
 Have external information aggregators been evaluated for value in API security operations?
--- a/Blokdyk/Checklist
+++ b/Blokdyk/Checklist
@ -398,7 +398,7 @@ Serve on a team of Cyber threat analysts responsible for the 24x7 analyses and r
-Do you actively share [Operational Technology](../../💡Drafts%20and%20Ideas/Operational%20Technology.md) threat related intelligence with your peers?
+Do you actively share [Operational Technology](../../Drafts%20and%20Ideas/Operational%20Technology.md) threat related intelligence with your peers?
 Maintain and drive the development of new reports of Cyber Threat Intelligence analysis to peers, management and (internal) customer teams for purposes of situational awareness and making threat intelligence actionable. 
--- a/Blokdyk/Checklist
+++ b/Blokdyk/Checklist
@ -7,7 +7,7 @@ Relevant ISO 27001 clauses/controls:
 - [ISO 27001 A.18.2 Information security reviews](../../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001%20A.18.2%20Information%20security%20reviews.md)
 Related:
- [Assets, Vulnerabilities, Threats, Risks](../../🎇%20Sparks/Assets,%20Vulnerabilities,%20Threats,%20Risks.md)
+- [Assets, Vulnerabilities, Threats, Risks](../..//Assets,%20Vulnerabilities,%20Threats,%20Risks.md)
 Author: [Gerardus Blokdyk](https://www.linkedin.com/in/gerardblokdijk/)
 Retrieved from [LinkedIn](https://www.linkedin.com/pulse/address-threat-management-challenges-ensuring-all-tied-blokdyk) on January 9, 2022
--- a/Blokdyk/Checklist
+++ b/Blokdyk/Checklist
@ -12,7 +12,7 @@ Relevant ISO 27002:2022 clauses/controls:
 - [a-5.7-Threat-intelligence](../../Standards/ISO27x/OST/27002/EN/a-5.7-Threat-intelligence.md)
 Related:
- [Threat Intelligence](../../🎇%20Sparks/Threat%20Intelligence.md)
+- [Threat Intelligence](../..//Threat%20Intelligence.md)
 ## Threat Modeling: Ask This;
--- a/Blokdyk/Checklist
+++ b/Blokdyk/Checklist
@ -10,7 +10,7 @@ Relevant ISO 27001 clauses/controls:
 - [ISO 27001 A 18 Compliance](../../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001%20A%2018%20Compliance.md)
 Related:
- [Vendor security MoC](../../🎇%20Sparks/Vendor%20security%20MoC.md)
+- [Vendor security MoC](../..//Vendor%20security%20MoC.md)
 ## Vendor Management: Ask This;
--- a/notes/Def_Sec_Handbook_Chapter_10.md
+++ b/notes/Def_Sec_Handbook_Chapter_10.md
@ -1,6 +1,6 @@
 # Chapter 10: Password Management and Multifactor Authentication
-See also: [Identity and Access Management (IAM)](../💡Drafts%20and%20Ideas/Identity%20and%20Access%20Management%20(IAM).md), [Roles in Identity and Access Management (IAM)](Roles%20in%20Identity%20and%20Access%20Management%20(IAM).md)
+See also: [Identity and Access Management (IAM)](../Drafts%20and%20Ideas/Identity%20and%20Access%20Management%20(IAM).md), [Roles in Identity and Access Management (IAM)](Roles%20in%20Identity%20and%20Access%20Management%20(IAM).md)
 ## Password practices
 Password complexity and brute force cracking:
--- a/Corpus/Literature
+++ b/Corpus/Literature
@ -1,4 +1,4 @@
-Related: [Vendor security MoC](../🎇%20Sparks/Vendor%20security%20MoC.md)
+Related: [Vendor security MoC](..//Vendor%20security%20MoC.md)
 ESCROW
 BOM
--- a/Corpus/Literature
+++ b/Corpus/Literature
@ -5,5 +5,5 @@ FAIR principles can be applied "to clarify organizational risk appetite and tole
 [Source](https://www.fairinstitute.org/blog/cyber-risk-management-establishing-a-blueprint-with-fair)
 Related:
- [Risk appetite](../💡Drafts%20and%20Ideas/Risk%20appetite.md)
+- [Risk appetite](../Drafts%20and%20Ideas/Risk%20appetite.md)
- [Risk tolerance](../🎇%20Sparks/Risk%20tolerance.md)
+- [Risk tolerance](..//Risk%20tolerance.md)
--- a/notes/Implementing
+++ b/notes/Implementing
@ -5,7 +5,7 @@ Article in ISACA Journal
 Retrieved: July 13, 2022
 See also:
- [Roles and Responsibilities](../🎇%20Sparks/Roles%20and%20Responsibilities.md)
+- [Roles and Responsibilities](../Sparks/Roles%20and%20Responsibilities.md)
 - [a-5.3-Segregation-of-duties](../Standards/ISO27x/OST/27002/EN/a-5.3-Segregation-of-duties.md)
 - [ISO_27002_2022_5.3_PE Segregation of duties](../../../iso27DIY-gis/reference/Paraphrased/ISO27002-2022-EN/ISO_27002_2022_5.3_PE%20Segregation%20of%20duties.md)
--- a/Corpus/Literature
+++ b/Corpus/Literature
@ -1,7 +1,9 @@
 ---
 Related:
-  - "[Risk management](../🎇%20Sparks/Risk%20management.md)"
+  - "[Risk management](../Sparks/Risk%20management.md)"
 ---
 # Managing Risks: A New Framework
 by Robert S. Kaplan and Anette Mikes, June 2012
 [Source](https://hbr.org/2012/06/managing-risks-a-new-framework)
--- a/Corpus/Literature
+++ b/Corpus/Literature
@ -9,9 +9,9 @@ For examples of defined roles, see:
 - [OrgFit Architectuurprincipes Humankind](../../Clients/Humankind/OrgFit%20Architectuurprincipes%20Humankind.md)
 Related:
- [Asset ownership](../🎇%20Sparks/Asset%20ownership.md)
+- [Asset ownership](../Sparks/Asset%20ownership.md)
 - [Control ownership](../Sparks/Control%20ownership.md)
- [Risk ownership](../🎇%20Sparks/Risk%20ownership.md)
+- [Risk ownership](../Sparks/Risk%20ownership.md)
 - [Segregation of Duties](Segregation%20of%20Duties.md)
 - [Access Control Models](../Sparks/Access%20Control%20Models.md)
--- a/Corpus/Literature
+++ b/Corpus/Literature
@ -20,7 +20,7 @@ For both users and IT administrators, securely handling thousands of accounts an
 ## SSO’s challenges
-   **Extra-strong passwords must be enforced.** If an SSO account is cracked, others under the same authentication can also be endangered. -> combine with [Multi-factor authentication](../🎇%20Sparks/Multi-factor%20authentication.md)
+-   **Extra-strong passwords must be enforced.** If an SSO account is cracked, others under the same authentication can also be endangered. -> combine with [Multi-factor authentication](../Sparks/Multi-factor%20authentication.md)
 -   **When SSO is down, access to all connected sites is stopped.** This is a big reason to exercise great care in choosing an SSO system. It must be exceptionally reliable and plans should be in place for dealing with breakdowns.
 -   **What’s more, when your identity provider goes down, your SSO does too.** The provider’s vulnerability to any kind of interruption becomes your vulnerability as well, and it is probably beyond your control. Once again, the choice of vendors is critical.
 -   **If a hacker breaches your identity provider user account, all your linked systems could be open to attack.** This can be a classic single point of failure and should be headed off in the planning process. On the plus side, high-quality identity providers have top-notch security.
--- a/Corpus/Literature
+++ b/Corpus/Literature
@ -1,4 +1,4 @@
-See also [Risk inventories](../🎇%20Sparks/Risk%20inventories.md)
+See also [Risk inventories](../Sparks/Risk%20inventories.md)
 https://cs4e.pages.labranet.jamk.fi/ooc/30-Cyber_Attack/01-Threats_and_Attacks/
--- a/Corpus/Literature
+++ b/Corpus/Literature
@ -1,6 +1,6 @@
-[Risks vs Threats vs Vulnerabilities](../🎇%20Sparks/Risks%20vs%20Threats%20vs%20Vulnerabilities.md)
+[Risks vs Threats vs Vulnerabilities](../Sparks/Risks%20vs%20Threats%20vs%20Vulnerabilities.md)
-[Threat Intelligence](../🎇%20Sparks/Threat%20Intelligence.md)
+[Threat Intelligence](../Sparks/Threat%20Intelligence.md)
 [Threat intelligence sources](../Sparks/Threat%20intelligence%20sources.md)
 [Threat Modeling](Security%20Threat%20Modeling.md)
 [Threat Catalogues](Threat%20Catalogues.md)
--- a/Corpus/Literature
+++ b/Corpus/Literature
@ -9,7 +9,7 @@ Miessler proposes treating vendors and vendor solutions as a risk and perform a
 Assume a breach will happen and take preventive measures to reduce the impact, by improving the risk visibility, and look for ways to reduce the scope, penetration, and access that the vendor tool has to minimum levels.
 Related:
- [Awareness](../🎇%20Sparks/Awareness.md)
+- [Awareness](../Sparks/Awareness.md)
- [Vendor security MoC](../🎇%20Sparks/Vendor%20security%20MoC.md)
+- [Vendor security MoC](../Sparks/Vendor%20security%20MoC.md)
- [Risk analysis](../🎇%20Sparks/Risk%20analysis.md)
+- [Risk analysis](../Sparks/Risk%20analysis.md)
--- a/Corpus/MoCs/ISO_27002_2022_5.29_MoC
+++ b/Corpus/MoCs/ISO_27002_2022_5.29_MoC
@ -4,5 +4,5 @@
 [[ISO_27002_2022_5.29_PE Information security during disruption \|Plain English]]
 ISO 27002:2013: 17.1.1, 17.1.2, 17.1.3
-[Business Impact Analysis (BIA)](../🎇%20Sparks/Business%20Impact%20Analysis%20(BIA).md)
+[Business Impact Analysis (BIA)](../Sparks/Business%20Impact%20Analysis%20(BIA).md)
--- a/Corpus/MoCs/ISO_27002_2022_5.30_MoC
+++ b/Corpus/MoCs/ISO_27002_2022_5.30_MoC
@ -7,6 +7,6 @@ ISO 27002:2013: n/a
 See also:
 - [BCP_Bedrijfscontinuïteitsplanning](../📚️%20Literature%20notes/BCP_Bedrijfscontinuïteitsplanning.md)
- [Business Impact Analysis (BIA)](../🎇%20Sparks/Business%20Impact%20Analysis%20(BIA).md)
+- [Business Impact Analysis (BIA)](../Sparks/Business%20Impact%20Analysis%20(BIA).md)
- [Disaster Recovery Planning](../🎇%20Sparks/Disaster%20Recovery%20Planning.md)
+- [Disaster Recovery Planning](../Sparks/Disaster%20Recovery%20Planning.md)
--- a/Corpus/MoCs/ISO_27002_2022_5.9_MoC
+++ b/Corpus/MoCs/ISO_27002_2022_5.9_MoC
@ -6,5 +6,5 @@ ISO 27002:2013: 08.1.1, 08.1.2
 [Brontekst](../ISO-27002-OST/ISO27002-NL-2022/a-5.9-Inventarisatie-van-informatie-en-andere-gerelateerde-bedrijfsmiddelen.md)
-The inventory serves as input for the [Business Impact Analysis (BIA)](../🎇%20Sparks/Business%20Impact%20Analysis%20(BIA).md)
+The inventory serves as input for the [Business Impact Analysis (BIA)](../Sparks/Business%20Impact%20Analysis%20(BIA).md)
 [ISO_27001_2022_00_MoC Index EXT](ISO_27001_2022_00_MoC%20Index%20EXT.md)
--- a/Corpus/Sparks/About
+++ b/Corpus/Sparks/About
@ -0,0 +1,9 @@
 This next part is about the iso 27001 industry and its actors. Correct the following text so that the proper terms are used. Expand with other actors and their roles if necessary. This is the text:
 - the standards organization develops the standard for a certain domain
 - the certification bureau checks if the standard is properly implemented within the organization and issues a certificate 
 - Clients, regulatory bodies and other stakeholders of the organization demand the organization to be certified to proof adequate risk control within the domain
 - the organization implements the standard to get certified
 - the implementation consultant helps the organization to implement the standard 
 - the internal auditor checks if the standard is properly implemented within the organization 
 - The external auditor works for the certification bureau 
--- a/Corpus/Sparks/About
+++ b/Corpus/Sparks/About
@ -0,0 +1,28 @@
 ---
 tags:  
 - project/iso27DIY/journey
 - type/explainer
 ---
 ## Journey
 We’ll start with analyzing the context of where the ISMS will operate. We’ll look at your organization, it’s structure and processes, important stakeholders and internal and external developments.
 From that we’ll help you identify risks and opportunities, and define risk mitigating measures.
 Together we will create policies, procedures and guidelines, and control implementation plans.
 Gradually, we’ll work towards your first internal audit.
 ++ increased understanding
 ++ actually improving your security posture
 We know that we need to get your organization along, so we’ll start with risks and opportunities that matter to your stakeholders.
 ## Timeline
 we will adapt to your pace, but we will actively coach you, like your sports watch would.
 ## Interaction model
 Work iteratively, you can always come back later
--- a/Corpus/Sparks/About
+++ b/Corpus/Sparks/About
--- a/iso27diy/Interactie
+++ b/iso27diy/Interactie
@ -0,0 +1,21 @@
 # Interactie met de gebruiker
 1. Gebruiker kiest een Lesmodule uit menu
 2. Content wordt getoond. Filmpje, tekst, afbeelding. 
 3. De gebruiker krijgt een ‘taak’. Hij/zij heeft de keuze die nu uit te voeren, of te parkeren in de persoonlijke Takenlijst[^1] (onderdeel van GRC). De taak bevat een verwijzing naar de content, zodat die later weer opgepakt kan worden. 
 4. De taak kan bestaan uit bijv:
   5. het uploaden van een document
   6. het invullen van een vragenlijst
   7. het vullen van een tabel (simpele spreadsheet met rij/kolom totalen bijv)
 8. Wat de gebruiker toevoegt wordt opgeslagen in de GRC-module
 9. De input van de gebruiker wordt gebruikt om nieuwe content te genereren, bijv. een beleidsdocument. Dit kan gebeuren met templates, logische regels, of LLM. 
 10. Gegenereerde content wordt ter controle aangeboden aan de gebruiker. Die moet daar wijzigingen in aan kunnen brengen en uiteindelijk de productie akkoord verklaren. 
 11. Na akkoord is er een wijziging in het ‘volwassenheidsniveau’ van het ISMS. Deze komt tot uitdrukking in het ‘Implementatie Dashboard’ (onderdeel van GRC). – kan dynamisch gegenereerd worden
 - [ ] Uitwerken: Er zit onderlinge afhankelijkheid in: soms kun je stap 3 pas nemen als je stap 1 gedaan.
 - [ ] Volwassenheidsniveaus benoemen.
 [^1]: in een latere versie kunnen taken toegewezen worden aan een andere gebruiker.
--- a/Corpus/Sparks/About
+++ b/Corpus/Sparks/About
@ -0,0 +1,417 @@
 # The Merchant Vessel's Voyage: An ISMS Implementation Story
 ## **The Premise**
 You're the captain of a merchant trading vessel, transporting valuable cargo across established trade routes. Your mission: deliver precious goods safely to distant ports while building a reputation for reliability and security that will sustain your trading company for years to come.
 ---
 ## **Episode 1: Charting the Destination** (Setting the Goals)
 Before leaving port, you gather your officers and backers around the navigation table. What defines success for this voyage?
 - **The cargo's safe arrival**: Your hold contains valuable spices, silk, medical herbs, fine instruments - goods that merchants await
 - **The crew's safe return**: A ship without seasoned sailors is just expensive timber
 - **Maintaining your reputation**: In the trading world, trust is currency
 - **Regulatory compliance**: You must satisfy the Harbor Master's requirements and international maritime codes to operate legally
 - **Sustainable operations**: This isn't a single voyage - you're building a trading enterprise
 You define your **scope**: Which routes will you sail? Which ports are included? What cargo types will you carry?
 Your **security objectives** become clear: confidentiality (cargo manifests and trade secrets), integrity (goods arrive uncontaminated and authentic), availability (reliable delivery schedules).
 You announce these goals to all stakeholders - the ship's owners, the crew, the merchants whose goods you carry.
 ---
 ## **Episode 2: Reading the Waters** (External Issues)
 Before you can plan your route, you must understand the world through which you'll sail:
 - **Pirate activity**: Which waters are most dangerous? What are their tactics? Are they after cargo, ransom, or the ship itself?
 - **Weather patterns**: Monsoon seasons, hurricane zones, fog-prone straits
 - **Geopolitical tensions**: Which nations are at war? Where are trade embargoes? Which flags grant safe passage where?
 - **Port regulations**: Different harbors have different requirements - quarantine rules, inspection protocols, docking fees
 - **Competition**: Other trading companies, their routes, their security measures
 - **Technology changes**: New navigation instruments, faster ships, encrypted communication methods between trading houses
 - **Economic conditions**: Which goods are in demand? Where are prices best?
 You gather intelligence from:
 - Harbor masters' reports
 - Returning captains' debriefings
 - Maritime insurance underwriters
 - Coastal watchtowers' signals
 - Trading guild bulletins
 This **external context** shapes every decision you'll make.
 ---
 ## **Episode 3: Knowing Your Vessel** (Internal Issues, Assets, Strengths & Weaknesses)
 Now you turn your attention inward. What are you working with?
 ### **Your Assets to Protect:**
 - **The cargo** (your primary information assets): Spices in the forward hold, medicinal herbs requiring cool storage, sealed letters of credit, navigation charts showing profitable routes
 - **The ship itself**: Hull integrity, sail condition, water-tightness of hatches
 - **Your crew**: The navigator's expertise, the surgeon's knowledge, the carpenter's skills
 - **Your reputation and relationships**: Trust with merchants, favorable insurance rates, preferential port access
 - **Supporting systems**: The ship's boat (your backup), fresh water supplies, repair materials
 ### **Strengths:**
 - Experienced first mate who's sailed these waters for 20 years
 - Recently reinforced hull
 - Disciplined crew with low turnover
 - Strong relationships with key ports
 ### **Weaknesses:**
 - The navigator is brilliant but aging, with no clear successor trained
 - Your encryption methods for sensitive documents are known by former crew who now sail for competitors
 - The starboard cargo hold has a persistent leak
 - Only two crew members can operate the new navigational instruments
 - Your emergency procedures exist mostly in the captain's head
 You conduct a thorough **inventory and assessment**: Who has access to what? Where are critical vulnerabilities? What depends on single points of failure?
 ---
 ## **Episode 4: Mapping the Dangers** (Risk Assessment)
 With your destination set, external conditions understood, and internal capabilities assessed, you now systematically identify what could go wrong:
 ### **Risk Identification:**
 - **Pirates in the Straits of Malacca**: High likelihood, severe impact (loss of cargo and possible crew)
 - **Storm season in the South China Sea**: Medium likelihood, catastrophic impact
 - **Crew illness/scurvy**: Medium likelihood, major impact on operations
 - **Cargo contamination from hold leak**: High likelihood, moderate impact
 - **Navigator incapacitation**: Low likelihood, severe impact
 - **Insider threat** (disgruntled crew revealing routes to competitors): Low likelihood, moderate impact
 - **Port authority seizure** due to paperwork errors: Medium likelihood, major impact
 - **Fire in the cargo hold**: Low likelihood, catastrophic impact
 ### **Risk Analysis:**
 For each risk, you assess:
 - **Likelihood**: Based on historical data (ships lost in these waters), current intelligence (pirate activity reports), ship conditions (that leaky hold)
 - **Impact**: What happens if this occurs? Loss of cargo value? Crew lives? Ship itself? Reputation damage?
 - **Existing controls**: What are you already doing? You have fire buckets, a daily inspection routine, experienced crew
 ### **Risk Evaluation:**
 You plot these on a risk matrix with your officers. Which risks are acceptable for a merchant vessel? Your risk appetite is moderate - you're not running military secrets that require extreme measures, but you can't afford frequent losses either.
 You prioritize: High likelihood + high impact risks must be addressed immediately. Low likelihood + low impact risks you'll accept.
 ---
 ## **Episode 5: Plotting the Course** (Risk Treatment - Identifying Measures)
 For each significant risk, you now decide your strategy:
 ### **Avoid:**
 - **Don't sail during peak storm season**: Delay departure by three weeks
 - **Avoid notorious pirate waters entirely**: Take the longer, safer route
 ### **Reduce:**
 - **Pirate encounters**: Sail in convoy with other merchants, hire additional armed crew, reinforce the captain's cabin (where valuables are stored), establish communication signals between convoy ships
 - **Cargo contamination**: Repair the hold leak, use sealed containers, implement daily inspection rounds
 - **Navigation failure**: Train two junior officers in advanced navigation, maintain duplicate charts stored separately, establish position verification protocols
 - **Fire**: Implement strict rules about open flames, station fire watch, conduct monthly fire drills, store water barrels strategically
 ### **Transfer:**
 - **Cargo loss**: Purchase maritime insurance (though it's expensive and has limitations)
 - **Crew injury**: Contract with a maritime medical service in major ports
 ### **Accept:**
 - **Minor cargo spoilage**: Some loss of spice potency is inevitable over long voyages; build this into pricing
 - **Wear on sails and rigging**: Routine deterioration; maintain replacement supplies
 You create a **Statement of Applicability** - essentially a ship's security manifest that lists all maritime security controls, which ones you're implementing, which you're not, and why.
 ---
 ## **Episode 6: The Ship's Standing Orders** (Policies and Procedures)
 Now you formalize how your ship will operate. These aren't just the captain's whims - they're documented protocols that ensure consistency even when you're sleeping:
 ### **Access Control Policy** ("Who Goes Where"):
 - **Cargo holds**: Only the quartermaster and captain have keys; entry logged in the ship's book
 - **Captain's cabin** (sensitive documents): Captain only; first mate has sealed emergency key
 - **Navigation room**: Navigator and trained officers only
 - **Critical supplies** (medical stores, emergency rations): Surgeon and quartermaster access; usage logged
 ### **Watch Standing Procedures** (Continuous Monitoring):
 - Four-hour watches with clear handoff protocols
 - What to look for: other ships, weather changes, coastal landmarks
 - How to sound alarms for different threats
 - Night signal procedures
 ### **Cargo Handling Protocols**:
 - Inspection upon loading (verify against manifest)
 - Daily hold inspections (check for water, pests, shifting)
 - Verification before unloading (ensure seals intact)
 - Chain of custody documentation
 ### **Emergency Response Procedures**:
 - **Fire**: Specific roles assigned, equipment locations, communication signals
 - **Pirate attack**: Battle stations, valuable cargo disposal procedures (if necessary), surrender signals (if absolutely necessary)
 - **Man overboard**: Stop signals, rescue boat launch, recovery procedures
 - **Taking on water**: Damage assessment, pumping priorities, emergency port protocols
 ### **Navigation Protocols**:
 - Position verification twice daily
 - Cross-checking between celestial navigation and known landmarks
 - Backup navigation methods
 - How to handle disagreement between navigator and captain
 ### **Communication Security**:
 - How to encode sensitive messages
 - Which information can be shared in port
 - Procedures when crew members depart
 - How to verify identity of ships claiming to be friendly
 ### **Maintenance Standards**:
 - Daily inspections (rigging, hull, pumps)
 - Weekly maintenance (sail repairs, deck treatment)
 - Monthly drills (fire, abandon ship, battle)
 - Equipment testing schedules
 ### **Crew Management**:
 - Hiring procedures (background checks with previous captains)
 - Security training for new crew
 - Disciplinary procedures
 - Departure protocols (what they can take, what they must return)
 Each policy answers: **What** must be done, **Why** it matters, **Who** is responsible, **When** and **How** it's done, and **What to do if** something goes wrong.
 ---
 ## **Episode 7: Casting Off** (Implementation)
 The planning is complete. Now comes the actual voyage - putting your measures into action:
 ### **Pre-Departure:**
 - Reinforce the cargo hold (that leak must be fixed)
 - Install the new secure storage in the captain's cabin
 - Conduct security training for the crew on the new protocols
 - Brief all hands on the voyage plan and their roles
 - Load cargo with new inspection procedures
 - Verify all equipment is aboard and functional
 ### **Underway:**
 - The watch rotation begins according to standing orders
 - Daily hold inspections reveal the repairs are holding
 - You drill the crew on emergency procedures weekly
 - Navigation protocols are followed - the junior officers are learning
 - Access logs are maintained for all sensitive areas
 - Incident reports are filed when protocols aren't followed (the cook accessed medical supplies without the surgeon present - why? turns out for a legitimate minor burn, but the procedure needs clarification)
 ### **Continuous Adjustment:**
 - Three days out, you receive signals that pirates have been sighted ahead; you adjust course and increase watches
 - A storm forces you to secure cargo differently than planned - you document the new method
 - One crew member proves unreliable at watch; they're reassigned and additional training provided to their replacement
 Implementation means **living** the procedures daily, not just having them written down.
 ---
 ## **Episode 8: Keeping the Ship Supplied** (Resources and Competence)
 A ship doesn't sail on good intentions. Throughout the voyage, you must ensure:
 ### **Financial Resources:**
 - Budget for unexpected port fees
 - Reserve funds for emergency repairs
 - Insurance premiums
 - Crew wages (security depends on crew loyalty)
 ### **Human Resources:**
 - Adequate crew size for watch rotations
 - Specialized skills: navigator, surgeon, carpenter, sailmaker
 - Training time - you can't expect new crew to know complex procedures instantly
 - Succession planning - you're actively training that junior navigator
 ### **Physical Resources:**
 - Spare rigging and sails
 - Repair materials (timber, pitch, nails)
 - Security equipment (weapons, locks, sealing wax)
 - Safety equipment (fire buckets, rescue lines, ship's boat)
 - Extra supplies beyond minimum (because delays happen)
 ### **Knowledge Resources:**
 - Navigation charts (and backups)
 - Ship's library of maritime procedures
 - Current intelligence from ports
 - Documentation of your own procedures and lessons learned
 ### **Time:**
 - Adequate voyage timeline (rushing leads to cutting security corners)
 - Maintenance windows (you must occasionally heave-to for repairs)
 - Training time during long passages
 - Rest for crew (exhausted sailors make mistakes)
 You establish **competence requirements**: What must each role know? The first mate must be able to take command. The quartermaster must know cargo handling. All crew must know basic emergency procedures.
 You track **awareness**: Does everyone understand why these security measures matter? They'll follow procedures better if they understand they're protecting their own interests (cargo arrives = they get paid; ship is safe = they live).
 ---
 ## **Episode 9: The Ship's Log** (Documentation)
 From the moment you leave port, you maintain meticulous records. In the maritime world, if it's not in the log, it didn't happen:
 ### **The Master Log:**
 - Daily entries: position, weather, course, significant events
 - All decisions and why they were made
 - All incidents and how they were handled
 - Changes to procedures
 ### **Specialized Logs:**
 - **Cargo manifest**: What's aboard, where it's stored, condition checks
 - **Watch log**: Who was on duty when, what they observed
 - **Maintenance log**: Repairs, inspections, equipment status
 - **Incident reports**: Anything unusual, even if minor
 - **Training records**: Who's been trained on what procedures
 - **Access logs**: Who entered sensitive areas when
 ### **Charts and Plans:**
 - Navigation charts with your actual route (vs. planned)
 - Cargo stowage plans
 - Emergency evacuation plans
 - Crew roster with roles and competencies
 ### **Why This Matters:**
 - **Learning**: What worked? What didn't? Your next voyage will be safer
 - **Accountability**: If something goes wrong, you can trace what happened
 - **Compliance**: Port authorities and insurers require documentation
 - **Continuity**: If you're incapacitated, your first mate needs to know everything
 - **Evidence**: If crew or cargo disputes arise, you have records
 - **Improvement**: You can't improve what you don't measure
 The ship's log is your organizational memory - it outlasts any single voyage.
 ---
 ## **Episode 10: Harbor Master's Inspection** (Audit and Review)
 ### **Internal Reviews (Ongoing):**
 Throughout the voyage, you conduct regular self-assessments:
 - **Daily bridge briefings**: What happened in the last 24 hours? What's ahead? Are procedures being followed?
 - **Weekly officer meetings**: Deeper review of security effectiveness, crew morale, equipment status
 - **Incident reviews**: Whenever something goes wrong (or almost goes wrong), you gather the relevant crew and analyze: What happened? Why? What will we do differently?
 - **Monthly drills**: Testing emergency procedures and evaluating performance
 ### **Port Audits (External):**
 When you reach port, several inspections occur:
 **Harbor Master's Security Inspection:**
 - Are your cargo manifests accurate?
 - Are dangerous goods properly stored and documented?
 - Does your crew have proper credentials?
 - Are your safety and security measures adequate?
 - Do you meet international maritime security codes?
 The Harbor Master is like your ISO 27001 auditor - they verify you're following established maritime security standards.
 **Cargo Survey:**
 - Merchants' representatives inspect their goods
 - Verifying seals are intact
 - Checking condition matches manifest
 - This proves your controls worked (or reveals where they didn't)
 **Insurance Assessment:**
 - Your insurer may inspect to verify you followed security protocols
 - This affects future premiums and coverage
 ### **Post-Voyage Review (Management Review):**
 After reaching your destination, you conduct a comprehensive review with your officers and the ship's owners:
 **What Worked:**
 - The convoy strategy - no pirate encounters despite sailing through risky waters
 - Junior navigator training - you now have backup capability
 - Daily hold inspections caught problems early
 **What Didn't:**
 - The new watch rotation led to gaps in dawn coverage twice
 - Access logging was inconsistently followed (people got busy)
 - Fire drill times were too slow - crew needs more practice
 **Metrics Analysis:**
 - Incidents logged: 12 (down from 18 last voyage)
 - Security procedure compliance: 94% (target was 95%)
 - Cargo loss: 0.5% (within acceptable range)
 - On-time arrival: 2 days early (good)
 - Crew injuries: 1 minor (excellent)
 **Risk Reassessment:**
 - Are the risks you identified still accurate?
 - Did new risks emerge? (You encountered fog banks that weren't in your initial assessment)
 - Have external conditions changed? (Political tensions have eased in certain waters)
 - Are your controls still appropriate?
 **Decisions for Next Voyage:**
 - Adjust watch rotation based on lessons learned
 - Implement new access control procedure to improve compliance
 - Conduct more frequent fire drills
 - Update risk assessment to include fog navigation
 - Invest in better equipment for certain controls
 ### **Continuous Improvement:**
 The voyage doesn't truly end when you reach port. You've learned from this journey, updated your procedures, and you're already preparing for the next departure. The ship's standing orders are now revised - Version 2.0 - incorporating everything you've learned.
 You share lessons with other captains in your trading company. Best practices spread through the fleet.
 **ISO Certification Parallel:** This comprehensive review - with documented evidence from your logs, demonstrated effectiveness of controls, and commitment to continuous improvement - is what convinces the Harbor Master (auditor) to certify your ship as meeting international security standards. The certificate isn't the end goal; it's recognition that you operate a secure, reliable, continuously improving operation.
 ---
 ## **The Journey Continues**
 Unlike a fortress that, once built, stands static, your merchant vessel is always in motion. The sea changes. Threats evolve. Crews turn over. New ports open. Technology advances.
 Your ISMS is the same - not a project with an end, but an operational discipline. The standing orders (policies) guide daily operations. The log (documentation) captures your organizational memory. The crew (your people) execute with competence and awareness. The inspections (audits) verify effectiveness. And the voyage (your business) continues, safer and more resilient because of the system you've built.
 **The ISO 27001 certificate is your Letter of Marque** - official recognition that your vessel meets the standards required to trade safely in international waters, protecting the valuable cargo (information) entrusted to your care.
--- a/Corpus/Sparks/About
+++ b/Corpus/Sparks/About
@ -0,0 +1,37 @@
 # iso27DYI: How this works
 ## Structure
 We've divided the ISMS implementation into a number of Episodes.
 - setting the goals
 - what's the lay of the land (relevant external issues)
 - how's our equipe, our assets that need to be protected (internal issues, strengths and weaknesses)
 - knowing the risks
 - identifying measures to mitigate the risks
 - creating the recipes (policies) for resilience in different areas / domains
 - implementing the risk mitigating measures
 - ensuring resources to implement and maintain everything
 - all the while documenting stuff as we go allong
 - audit and review how we're doing.
 For every element of the ISO 27001 you need to be able to tell the auditor:
 - what your method is for implementing the requirement
 - how and when you monitor the results of your implementation
 - how and when you evaluate the results and identify possible improvements
 - when you are planning to implement these improvements
 - who's involved and who's responsible for each of these steps.
 In ISO27DIY we deal with this by providing Policy Cards for every Clause and Control of the ISO 27001. 
 There's always our Controls Library with everything in Plain English, support by our consultants. When the time is ready, you can plan a preliminiary audit.
 ## Principles
 - work with what you got - keep doing what you do but make it 'compliant'
 - work iteratively - you can always come back later
 # Metadata
 - which 'slots' this scene fills
--- a/Corpus/Sparks/Access
+++ b/Corpus/Sparks/Access
@ -1,6 +1,6 @@
 See also:
 - [Authorization vs Access Control](Authorization%20vs%20Access%20Control.md)
- [Identity and Access Management (IAM)](../💡Drafts%20and%20Ideas/Identity%20and%20Access%20Management%20(IAM).md)
+- [Identity and Access Management (IAM)](../Drafts%20and%20Ideas/Identity%20and%20Access%20Management%20(IAM).md)
 - [RBAC Access levels](../Literature%20notes/RBAC%20Access%20levels.md)
 - [CRUD Matrices](CRUD%20Matrices.md)
--- a/Corpus/Sparks/Assets,
+++ b/Corpus/Sparks/Assets,
@ -3,7 +3,7 @@
 * The relationship between assets, vulnerabilities, and threats is often called the Operations Security Triple.
 [Assets](Assets.md)
-[Vulnerability](../💡Drafts%20and%20Ideas/Vulnerability.md)
+[Vulnerability](../Drafts%20and%20Ideas/Vulnerability.md)
 [Threat](../📚️%20Literature%20notes/Threat.md)
 [Risks](Risks.md)
--- a/Corpus/Sparks/Context,
+++ b/Corpus/Sparks/Context,
@ -0,0 +1,38 @@
 # Sources for the Context sessions
 ## PECB Lead Auditor Training
 [PECB 27001 LA S05 E01a - Context of the organization](../../Standards/ISO27x/PECB-Lead-Auditor-Training/PECB%2027001%20LA%20S05%20E01a%20-%20Context%20of%20the%20organization.md)
 ## Sparks
 [The ISMS in its context](The%20ISMS%20in%20its%20context.md)
 [Context analysis](../../Literature%20notes/Context%20analysis.md)
 ## Mark I content
 [ISO27DIY Video A.4 Context and Scope - Internal issues](../../Standards/ISO27x/legacy/iso27DIY%20mk%20I/ISO27DIY%20Video%20A.4%20Context%20and%20Scope%20-%20Internal%20issues.md)
 [ISO27DIY Video A.2 Context and Scope - Stakeholders](../../Standards/ISO27x/legacy/iso27DIY%20mk%20I/ISO27DIY%20Video%20A.2%20Context%20and%20Scope%20-%20Stakeholders.md)
 [ISO27DIY Video A.3 Context and Scope - Regulations and Contracts](../../Standards/ISO27x/legacy/iso27DIY%20mk%20I/ISO27DIY%20Video%20A.3%20Context%20and%20Scope%20-%20Regulations%20and%20Contracts.md)
 ## Standard
 [ISO_27001_2022_4.1_MoC Understanding the organization and its context](../../Corpus/Standards/MoCs/ISO_27001_2022_4.1_MoC%20Understanding%20the%20organization%20and%20its%20context.md)
 [ISO_27001_2022_4.2_MoC Understanding the needs and expectations of interested parties](../../Corpus/Standards/MoCs/ISO_27001_2022_4.2_MoC%20Understanding%20the%20needs%20and%20expectations%20of%20interested%20parties.md)
 [ISO_27001_2022_4.3_MoC Determining the scope of the information security management system](../../Corpus/Standards/MoCs/ISO_27001_2022_4.3_MoC%20Determining%20the%20scope%20of%20the%20information%20security%20management%20system.md)
 [ISO_27001_2022_4.4_MoC Information security management system](../../Corpus/Standards/MoCs/ISO_27001_2022_4.4_MoC%20Information%20security%20management%20system.md)
 ## From the 'canvas'
 Besturingsmodel (4.1)
 Functiehuis (4.1)
 Organogram (4.1)
 Bedrijfsprocessen (4.1)
 SWOT (4.1)
 - [SWOT Analyses template](../SWOT%20Analyses%20template.md)
 DESTEP (4.2)
 Stakeholder analyse (4.2)
 Wet- en regelgeving (4.2, A5.31-A5.34)
 ## Further research
 - [ ] Assets?
 - [ ] Impactbepaling uit [Dataclassificatie Humankind](../../../Clients/Humankind/Dataclassificatie%20Humankind.md)
--- a/Corpus/Sparks/Context,
+++ b/Corpus/Sparks/Context,
@ -0,0 +1,7 @@
 # The ISMS in its context
 The primary purpose of the ISMS is to Control information security risks, that may impede on the organization achieving its goals.
 The ISMS does not exist in a vacuum. It interacts with the internal and external context of the organization.  
 An effective ISMS relies on a relationship between / the interplay of organizational goals, its context, threats and risks to the CIA of information, and available resources.
--- a/Corpus/Sparks/Controls/Create
+++ b/Corpus/Sparks/Controls/Create
@ -0,0 +1,30 @@
 ---
 tags:
  - llm
 ---
 [Source](https://www.linkedin.com/posts/mbundgaard_cyber-threat-landscape-analysis-activity-7274406690442149888-Pf-X), retrieved 20-12-24 
 Create your own cyber threat analysis GenAI chatbot in 30 minutes.  
 Free of cost and code.  
 1) Don't waste your time manually collecting every report from different websites behind forms. Go to [Jacob Wilson](https://www.linkedin.com/in/jacobdjwilson/)'s [github repo](https://github.com/jacobdjwilson/awesome-annual-security-reports/tree/main/) that's updated with all relevant and current reports. 
 2) Don't waste time reading through 20-40 reports that are almost identical. Instead, upload them to [notebooklm.google.com](http://notebooklm.google.com/) and let AI do the heavy lifting.  
 3) Remember to upload/link to your infosec taxonomy. I recommend [VERISframework.org](https://verisframework.org) as it is used by Cyentia Institute and Verizon.
 4) Don't use any old GPT. Prompt your notebook to get actual references and prevent hallucinations.  
 5) Don't return to the same sources with annotation and manual review. Instead, write and adjust prompts to your specific purposes.  
 You now have your very own reliable cyber threat chat bot to help your analyze any problem.
 **Prompt suggestion:**
 `Context: Doing an annual analysis of the threat landscape surrounding a specific enterprise.`
 `The enterprise is a [region][industry][services] company. It has around [number] employees and annual revenue of [your annual revenue].`
 `Please provide a two-part analysis:`
 1. `A summary of the relevant industry research. The summary must adhere to the [taxonomy] framework. Each section must include examples from the source material and/or statistics such as forecasting or historical changes.`
 2. `A list of the 5-10 most relevant threat scenarios to be included in a subsequent risk assessment. Provide the scenarios in a table format. The table must include the following columns [column 1], [column 2], [column 3] [etc] and strictly adhere to [taxonomy).`  
   For columns I suggest Threat actor, activity and attribute.
--- a/Corpus/Sparks/Dealing
+++ b/Corpus/Sparks/Dealing
@ -0,0 +1,47 @@
 # Context
 A vulnerability in a widely used open source library is published.
 This is based on the Log4j vulnerability, december 2021, [CVE-2021-44228](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228)
 Log4j is a Java library maintained by the Apache Foundation, and the most popular logging library for Java.
 The vulnerability is: user input containing JNDI Lookups is allowed, will be logged and evaluated, making an RCE attack possible. Disabling logging, while as a rule undesirable, plugs the hole.
 Source: https://logging.apache.org/log4j/2.x/
 This vulnerability allows an attacker to run commands from a web server, unauthenticated (i.e. without needing to login).
 # Steps
 ## 1. Identifying exposure
 - search your source code repositories for the name of the library
 - use dependency tools (also called Software Composition Analysis or SCA) to identify indirect use of the affected library , like GitHub's dependencyGraph, Snyk,[OWASP Dependency-Check](https://owasp.org/www-project-dependency-check/), White source, etc.
 - not all versions may be affected, so check which version of the library you are using
 - find out if you are actually deploying the code that uses the vulnerability; if not, mark the code as "do not deploy". If it has, find out where.
 ## 2. Stopping the gap
 - If the vulnerability is deployed behind a Web Application Firewall (WAF) or Content Delivery Network (CDN), or if you are using Runtime Application Self-Protection (RASP), add the rules your vendor provides to prevent RCE. 
 - If your vendor doesn't have rules available, search for them on the internet or write regex that blocks the attack. 
 - Monitor to make shure it's working.
 - Update/patch the library containing the vulnerability as soon as it becomes available. 
 ## 3. If you can't stop the gap
 Do an impact analyses and identify a treatment:
 - Option 1: Accept the Risk, keep monitoring the situation, spend your efforts on releasing the upgraded version of your software a.s.a.p.
 - Option 2: Avoid the risk, by shutting down the vulnerable systems immediately — In this example (log4j), stop logging temporarily. 
 - Option 3: Mitigate the risk, by going through your code base, remove the dependency and comment out the code that calls it (uncomment it when the upgrade/patch has been applied). 
 ## Relevant ISO 27001 controls
 The main control of interest here is [ISO 27001 A 12.6.1 Management of technical vulnerabilities](../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001%20A%2012.6.1%20Management%20of%20technical%20vulnerabilities.md), which ensures timely awareness of vulnerabilities through [ISO 27001 A 6.1.4 Contact with special interest groups](../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001%20A%206.1.4%20Contact%20with%20special%20interest%20groups.md), evaluation of an organization’s exposure, and having set [ISO 27001 A 16.1.1 Responsibilities and procedures](../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001%20A%2016.1.1%20Responsibilities%20and%20procedures.md) to enable a quick and effective response.
 Stopping the gap:
 - [[ISO 27001 A 13.1.1 Network controls]]
 - [[ISO 27001 A 13.1.2 Security of network services]]
 - [ISO 27001 A 12.5.1 Installation of software on operational systems](../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001%20A%2012.5.1%20Installation%20of%20software%20on%20operational%20systems.md)
 Preventative measures:
 - [ISO 27001 A 12.6.2 Restrictions on software installation](../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001%20A%2012.6.2%20Restrictions%20on%20software%20installation.md)
 - [[ISO 27001 A 14.1.1 Information security requirements analysis and specification]]
 - [[ISO 27001 14.2.1 Secure development policy]]
 - [[ISO 27001 A 14.2.7 Outsourced development]]
 - [ISO 27001 A 18 Compliance](../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001%20A%2018%20Compliance.md) of systems
--- a/domeindeskundigen.md
+++ b/domeindeskundigen.md
@ -0,0 +1,16 @@
 This note relates to the [ISO27DIY Business model](../Standards/ISO27x/legacy/iso27DIY%20mk%20I/ISO27DIY%20Business%20model.md)
 Probleem: de GRC software wordt aangekocht om een operationeel probleem van de compliance officer op te lossen.
 De software komt meestal pas later (en wordt pas gevuld als de kennis van wat ISO is en van het proces er al is, als het jargon al is ingesleten)
 Eerst komt de consultant uitleggen hoe ISO werkt en wordt hulp geboden bij Wat je Waar moet documenteren, en Hoe (denk aan de risico-identificatie en de stakeholder-analyse: wat is een in-scope risico, hoe verwoordt je het precies. Wat is een stakeholder, wat is zijn in-scope belang, etc.).
 Dan ontstaat de documentatie, meestal in Excel en Word documenten.
 Dan de realisering dat het onhandig is en niet schaalt.
 Dan wordt software geselecteerd en geïmplementeerd.
 Pas dan wordt de software daadwerkelijk gebruikt, en meestal door een deskundige staffunctionaris.
 Inmiddels staat het dan zover af van de dagelijkse praktijk op de werkvloer, dat de heilige graal van security by design en in de haarvaten van de organisatie, niet gehaald kan worden.
 Voor iedere (interne) audit is extra effort nodig om te graven in de operationele documentatie om de audit documentatie naar boven te krijgen.
 Wat nu als je de documentatie kun genereren op het moment dat relevante feiten (identificatie en weging van risico’s, keuze van maatregelen, bewaken van de implementatie, monitoren van de resultaten en bijsturen) plaatsvinden? Door ze voorafgaand aan een SCRUM, Team- of afdelingsoverleg of ontwerpmeeting te agenderen, en ze in de notulen te ‘marken’? Door operationele reports en logs te koppelen naar de ISO-administratie?
--- a/Corpus/Sparks/ISMS/About
+++ b/Corpus/Sparks/ISMS/About
@ -0,0 +1,9 @@
 ---
 tags:  
 - project/iso27DIY
 - type/explainer
 ---
 The auditor will require proof of the implementation of the ISMS and all it’s individual controls. Proper implementation means a control is risk-based, there’s a policy describing the why and how of it’s implementation, it’s results are monitored or measured, it’s effectiveness is evaluated, and possible improvements to the implementation of the control are identified.
--- a/Corpus/Sparks/ISMS/About
+++ b/Corpus/Sparks/ISMS/About
@ -0,0 +1,63 @@
 ---
 tags:
  - iso27001
  - policy
  - control
  - risk
 ---
 `Within a ISO 27001 compliant ISMS, is it possible to implement a control without having a policy for that control?`
 `Claude Sonnet 4:`
 In an ISO 27001 compliant ISMS, implementing a control without having a policy for that control is technically possible but not recommended and may create compliance issues.
 Here’s why this creates problems:
 **Policy Requirements**: ISO 27001 requires documented information for information security policies, and Annex A controls often reference the need for established policies. The standard expects that controls should be guided by appropriate policies that define the organization’s approach and requirements.
 **Documentation and Evidence**: During certification audits, auditors will look for evidence that controls are properly governed. A control implemented without supporting policy documentation may be seen as ad hoc or insufficiently managed, potentially leading to non-conformities.
 **Control Effectiveness**: Policies provide the framework for consistent implementation and operation of controls. Without them, you risk:
 - Inconsistent application across the organization
 - Lack of clear responsibilities and accountabilities
 - Difficulty in measuring effectiveness
 - Challenges in maintaining the control over time
 **Best Practice Approach**: The recommended structure is:
 1. **Policy** - High-level statement of intent and requirements
 2. **Procedures** - Detailed steps for implementation
 3. **Controls** - Actual security measures and technical implementations
 4. **Records** - Evidence of operation and effectiveness
 While you might temporarily operate a control without formal policy documentation, you should establish the appropriate policy framework to ensure long-term compliance and effectiveness. This approach aligns with ISO 27001’s emphasis on a systematic, risk-based approach to information security management.
 `Does each control need an associated risk?`
 `Claude Sonnet 4:`
 No, each control does not need an associated risk in an ISO 27001 compliant ISMS. This is a common misconception about how the risk-based approach works.
 **How Risk and Controls Actually Relate:**
 **Risk-Driven Control Selection**: Controls should be selected based on your risk assessment outcomes. You identify risks, evaluate them, and then select controls to treat those risks. However, the relationship is typically many-to-many:
 - One risk may require multiple controls to adequately treat it
 - One control may address multiple different risks
 - Some controls may be implemented for compliance or operational reasons beyond specific risk treatment
 (so far, so good …)
 (if you interpret the following as: specific to your organization, there’s a point somewhere)
 **Baseline Controls**: Organizations often implement baseline security controls (like basic access controls, antivirus, firewalls) that address general security risks rather than being tied to specific identified risks (???). These are considered good security hygiene.
 **Compliance-Driven Controls**: Some controls may be implemented to meet regulatory requirements, contractual obligations, or industry standards, even if they don’t directly correspond to a specific risk you’ve identified in your risk assessment.
 **Control Objectives**: What’s important is that your overall control framework addresses your identified risks and supports your risk treatment decisions. The traceability should be at the risk treatment level, not necessarily at the individual control level.
 **Documentation Expectations**: Your ISMS documentation should demonstrate how your control selection relates to your risk assessment and treatment decisions, but this doesn’t require a one-to-one mapping of every control to a specific risk.
 The key is ensuring your control selection is justified and supports your overall risk management strategy, whether through direct risk treatment, baseline security posture, or compliance requirements.
--- a/Corpus/Sparks/ISMS/About
+++ b/Corpus/Sparks/ISMS/About
@ -0,0 +1,17 @@
 ---
 tags:  
 - project/iso27DIY
 - type/explainer
 ---
 ## About the Statement of Applicability
 In essence, the Statement of Applicability shows the outcome of the risk treatment process ([6.1.3a](../../Corpus/Standards/MoCs/ISO_27001_2022_6.1.3_MoC%20Information%20security%20risk%20treatment.md)). It is usually presented as a table of Annex A controls, together with a short explanation for the selection *or* exclusion of each, and its implementation status.
 This follows directly from [Clause 6.1.3d](../../Corpus/Standards/MoCs/ISO_27001_2022_6.1.3_MoC%20Information%20security%20risk%20treatment.md), that demands that the Statement of Applicability contains:
 * the controls that are **necessary** to implement the chosen risk treatments, including the rationale for their selection
 * the **status** of their implementation *("whether the necessary controls are implemented or not")*
 * the reason for exclusion of any and all other controls from Annex A.
 Though ISO 27002 offers guidelines for the implementation of the controls from Annex, the organization is free in their design.  The organization is also free to identify them "from any source", so you could also include controls from for instance XXX or YYY.
 One is generally advised to "Comply or Explain", which means you implement *all* controls from Annex A in some form, or you explain why you don't need to, based on your risk analysis and chosen risk treatment. 
--- a/Corpus/Sparks/ISMS/Basic
+++ b/Corpus/Sparks/ISMS/Basic
@ -0,0 +1,99 @@
 # ISMS Governance Model
 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.*
 ## Policy Lifecycle: Who Does What
 ### Key Players
 **Top Management**
 The buck stops here. They don't write policies, but they commission them, approve them, and make sure there's budget for security.
 **Security Manager/CISO**
 The person who actually writes the policies, keeps them updated, and knows what they're talking about. They might bring in outside experts when needed.
 **Line Managers**
 The bridge between policy and practice. They make sure their teams know what's expected and actually follow through.
 **Everyone Else**
 Read the policies, acknowledge them, follow them.
 ### How Policies Get Made
 | Step | Who's Responsible |
 |:-----|:-----------------|
 | **Commission** | Top management says "we need a policy for X" |
 | **Draft** | Security manager writes it |
 | **Consult** | Subject matter experts review it (legal, HR, IT) |
 | **Approve** | Top management signs off (or delegates for specific policies) |
 | **Communicate** | Security/HR publishes it where people can actually find it |
 | **Acknowledge** | Everyone confirms they've read it |
 | **Review** | Security manager revisits it regularly or after incidents |
 Think of it like passing a law: the mayor commissions it, lawyers draft it, city council approves it, district captains enforce it, and citizens follow it.
 ## Key Roles in ISO 27001
 **Top Management**
 Sets direction, assigns responsibilities, reviews the whole system periodically.
 **Risk Owners**
 Own specific risks. They approve how risks get handled and accept whatever risk remains after controls are in place.
 **Asset Owners**
 Responsible for protecting specific assets throughout their lifecycle. They classify data, set access rules, and authorize disposal. They can delegate tasks but remain accountable.
 **Security Function**
 Usually a CISO or security manager. Makes sure the ISMS actually works and reports on its performance.
 **Other Roles You'll Need**
 - Privacy officer (if handling personal data)
 - Project managers (to bake security into projects)
 - Internal auditors (to check if things actually work)
 - System administrators (the people with the keys to the kingdom)
 ## Who Does What with Controls
 Controls are the actual security measures you implement. Here's who handles them:
 **Top Management**
 Provides resources, assigns reporting responsibilities, reviews everything at management meetings.
 **Risk Owners**
 Approve which controls get implemented and accept leftover risk.
 **Asset Owners**
 Make sure assets are properly protected and periodically check that access controls still make sense.
 **Line Managers**
 Enforce policies with their teams, check compliance regularly, fix problems when they find them.
 **CISO/Security Manager**
 Oversees implementation, helps identify risks, supports monitoring activities.
 **Internal Auditors**
 Check if controls actually work and if the ISMS meets requirements. They don't implement anything—they just verify.
 **Everyone**
 Follow the rules and report security issues when they spot them.
 ### Quick Reference
 | Role | Implementing | Monitoring | Evaluating |
 |:-----|:------------|:-----------|:-----------|
 | Top Management | Fund it | Review reports | Annual reviews |
 | Risk Owner | Approve treatment plans | Accept residual risk | Check risk status |
 | Asset Owner | Protect the assets | Review access periodically | Verify inventory |
 | Line Manager | Enforce with staff | Regular compliance checks | Report findings |
 | Internal Auditor | — | — | Test if it works |
 ### Simple Analogy
 Think city infrastructure:
 - **Top Management** = City Council (budget for road safety, review annual reports)
 - **Risk Owner** = City Planner (decides that intersection needs a traffic light)
 - **Asset Owner** = Road Maintenance (installs and maintains the lights)
 - **Line Manager** = Police Captain (makes sure officers enforce traffic laws)
 - **Internal Auditor** = Inspector General (checks if lights meet codes and tickets are being issued)
--- a/Corpus/Sparks/Ideas
+++ b/Corpus/Sparks/Ideas
@ -0,0 +1,13 @@
 # Ideas about enforcement
 The coverage of [[Enforcement tooling]] will not be complete, if only because their implementation will always be one step behind organizational reality. There will be information assets out of scope, by choice or accident.
 There will be situations where the improper handling of assets is not prevented by such tooling, and employees would need to be aware of, or deduce from content, the classification of those assets, and make an informed decission on the proper handling.
 The underlying idea is that I personally prefer that people have freedom of choice and be supported in making informed decissions.
 that is not only morally preferable, but it's a necessigty precisely because there will always be situations in which they *need* to decide for themselves.
 There's also a link here to different stakeholders with different interests. Think of your stereotypical IT Guy, who wants to screw everything down, and Marketing Guy, who wants maximum freedom in the data lake.
 Related:
 - [Labeling of information in the digital domain](Labeling%20of%20information%20in%20the%20digital%20domain.md).
 - [Stakeholder Analysis](Stakeholder%20Analysis.md)
--- a/Corpus/Sparks/Identification.md
+++ b/Corpus/Sparks/Identification.md
@ -0,0 +1,7 @@
 # Identification
 Identification is the claim of a subject of its identity. 
 See also:
 - [Authentication](../Standards/ISO27x/Authentication.md)
 - [Authorization](../Standards/ISO27x/Authorization.md)
 - [Identity and Access Management (IAM)](Identity%20and%20Access%20Management%20(IAM).md)
--- a/Corpus/Sparks/Identity
+++ b/Corpus/Sparks/Identity
@ -0,0 +1,14 @@
 ## How IAM works
 With IAM, you manage access control by defining _who_ (identity) has _what access_ (role) for _which resource_. For example, Compute Engine virtual machine instances, Google Kubernetes Engine (GKE) clusters, and Cloud Storage buckets are all Google Cloud resources. The organizations, folders, and projects that you use to organize your resources are also resources.
 In IAM, permission to access a resource isn't granted _directly_ to the end user. Instead, permissions are grouped into _roles_, and roles are granted to authenticated _principals_. (In the past, IAM often referred to principals as _members_. Some APIs still use this term.)
 An _allow policy_, also known as an _IAM policy_, defines and enforces what roles are granted to which principals. Each allow policy is attached to a resource. When an authenticated principal attempts to access a resource, IAM checks the resource's allow policy to determine whether the action is permitted.
 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"
 - [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)](../Literature%20notes/Roles%20in%20Identity%20and%20Access%20Management%20(IAM).md)
--- a/Corpus/Sparks/Impact
+++ b/Corpus/Sparks/Impact
@ -0,0 +1,8 @@
 ## Impact of Disruption
 [](../Attachments/TLP_Impact_matrix_NL.xlsx)
 [BCP_Bedrijfscontinuïteitsplanning](../📚️%20Literature%20notes/BCP_Bedrijfscontinuïteitsplanning.md)
 [Business Impact Analysis (BIA)](../Sparks/Business%20Impact%20Analysis%20(BIA).md)
--- a/Corpus/Sparks/Information
+++ b/Corpus/Sparks/Information
@ -0,0 +1,3 @@
 - [Information security concepts MoC](../Information%20security%20concepts%20MoC.md)
 - [🗃 Standards and Regulations for information security](../Standards/other/🗃%20Standards%20and%20Regulations%20for%20information%20security.md)
--- a/Corpus/Sparks/Labeling
+++ b/Corpus/Sparks/Labeling
@ -0,0 +1,18 @@
 [ISO 27001 A 8.2.2 Labelling of information](../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001%20A%208.2.2%20Labelling%20of%20information.md) makes procedures for information labelling in accordance with the classification scheme mandatory.
 For physical assets it’s straightforward: a ‘restricted area’ sign on the door to the server room, a ‘classified’ mark on a folder, a ‘privacy sensitive’ sticker on a backup tape, etc.  
 But how would you implement labeling in the digital domain of databases, file systems, SaaS environments, etc.?
 Brahman Thiyagalingham suggested in [this LinkedIn thread](https://www.linkedin.com/feed/update/urn:li:activity:6878704465160007680/?commentUrn=urn%3Ali%3Acomment%3A(groupPost%3A67493-6878704464929316864%2C6878973141931094016)&replyUrn=urn%3Ali%3Acomment%3A(groupPost%3A67493-6878704464929316864%2C6879367802243866624)) that, to ensure the proper handling of (digital) information assets, you would rely on "something like a proper RBAC model, Identity Access solution with a PAM, DRM and DLP". Implying the concept of labeling has been replaced by applying these tools.
 It could be said that these tools apply labeling implicitely, because effective implementation of these solutions requires that the solution ’knows’ what forms of protection each information asset needs.
 That means classifying information assets (control 8.2.1) and determining acceptable use (control 8.1.3). 
 Labeling of digital information assets ‘close to the source’ – e.g. assign a classification-label to a database column – will help create a consistent approach across individual solutions.
 Looking at it that way, any metadata that helps ensure the acceptable use and proper handling of information assets could be identified as ‘labeling’. A data dictionary that contains classification information could also be considered to use labeling. 
 Related:
 - [ISO 27001 A 8.2.1 Classification of information](../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001%20A%208.2.1%20Classification%20of%20information.md)
 - [ISO 27001 A 8.1.3 Acceptable use of assets](../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001%20A%208.1.3%20Acceptable%20use%20of%20assets.md)
 - [[Enforcement tooling]]
--- a/Corpus/Sparks/List
+++ b/Corpus/Sparks/List
@ -0,0 +1,4 @@
 - [The Art of Service](The%20Art%20of%20Service.md) offers topical InfoSec Kanban boards
 - 'Certificeringsadvies' offers independent external audits, they were employed by Networking4all
 - [Muddassir via Gumroad](https://community.gumroad.com/c/share-your-wins/boring-fields-like-supply-chains-can-be-creative-enough-to-sell-digital-products?login_token=RyhWoyqXw2kT5de2eNp6RYjL6U4NY1aKLPmS#comment_wrapper_4014940). Runs a site on SCM and has offered to cross post content.
--- a/Corpus/Sparks/Measures
+++ b/Corpus/Sparks/Measures
@ -0,0 +1,290 @@
 # Measures vs Workability: least privilege, need-to-know 
 *Hypothesis: security frameworks promote least privilege and need-to-know for access control, while common data‑classification schemes and real‑world practices frequently result in minimal or inconsistent protective measures until incidents or regulations force stricter controls.*
 What is least privilege, need-to-know. and why is it important?
 - The least privilege principle us defined as giving users only the access they need to perform their job, explicitly to reduce attack surface and limit damage if accounts are compromised. 
 - Excessive permissions and broad access are repeatedly identified as drivers of breaches in cloud environments, where over‑privileged accounts magnify the blast radius of attacks, underscoring how least‑privilege is supposed to be a maximally conservative control principle, not a minimal one.
 - Security organizations and vendors explicitly promote least‑privilege and need‑to‑know as foundational, proactive principles to minimize risk.
 - Because of cost‑effective management, scalability, and operational efficiency, organizations choose to reserve stronger measures for only the highest sensitivity classes, and apply only baseline controls to the classes.
 - Implementations often rely on subjective, user‑driven decisions about how to classify information, which is acknowledged as inconsistent and prone to human error; this can lead to sensitive data being misclassified and not receiving appropriate protection until problems are discovered.
 - Cloud‑security analyses highlight misconfigurations and overly permissive identity and access management as primary causes of data breaches, showing that data is frequently more exposed than its intended classification or policy would suggest, especially when default or “internal” classifications are used with weak enforcement.
 - Studies and policy critiques of government secrecy note pervasive over‑classification of documents, which paradoxically strains controls and leads to mishandling and inconsistent protection because staff cannot realistically maintain high‑grade measures for everything labeled sensitive.
 - This dynamic supports the idea that classification is often used in a coarse, administrative way, with either over‑broad “classified” labels or broad “internal/public” buckets, and the actual security measures tend to converge on what is minimally workable in practice rather than what the maxim of least privilege would prescribe.
 - data‑classification guidance and breach analyses show that: lower classes are defined to warrant minimal controls, classification is inconsistently applied, and misconfigurations and over‑privileged access remain dominant breach causes—together indicating that classification outcomes often default to minimal measures unless regulatory or incident pressure requires more.
 *Hypothesis: the least privilege tends to be implemented more rigorously and systematically for technical/admin roles than for access to business information.*
 - Modern Privileged Access Management (PAM) practices are explicitly built around least‑privilege: discover all privileged accounts, strip rights down to the minimum, enforce just‑in‑time elevation, and avoid privilege creep.
 - Vendors and best‑practice guides describe mature patterns such as time‑bound admin elevation, granular role‑based admin roles, session recording, and centralized approval workflows, which directly optimize and monitor admin rights rather than leaving them broadly assigned.
 ## Persistent over‑privilege for business data
 - Data‑centric security and DSPM literature repeatedly stresses that over‑privileged access to business data (files, SaaS content, analytics datasets) is widespread, with the majority of granted permissions unused and many of them high‑risk.[2]
 - Case studies for SaaS data protection highlight “internal overexposure” as a primary issue: collaborative tools make it easy to share information widely, while security teams lack visibility to enforce “need to know” on everyday business documents, HR data, and customer information.[4][2]
 ## Indicators that least privilege is better enforced on IT/admin side
 - PAM guidance calls least privilege “fundamental” and prescribes concrete control patterns (role‑based admin levels, just‑in‑time access, automatic revocation, monitoring) that are often implemented as dedicated tools and processes for admin accounts.[6][1][3]
 - Insider‑threat and privilege‑risk reports emphasize reducing privileged admin accounts and entitlement sprawl as key risk‑reduction goals, showing sustained focus and investment in tightening admin rights, especially in directories and infrastructure platforms.[7][8][9]
 ## Business information access lagging behind
 - In contrast, protection of business information often reacts to discovered overexposure: organizations deploy DSPM or SaaS access‑governance tools *because* they find that users can access far more data than they need, not because least‑privilege was consistently applied from the outset.[2][4]
 - Guidance notes that collaboration platforms “lack capabilities” for teams to “properly protect” sensitive content, forcing retroactive clean‑up of oversharing rather than proactive definition and enforcement of narrow, need‑to‑know scopes.[4]
 ## Overall pattern
 - For admin/IT privileges, least privilege is operationalized via specialized tooling, distinct lifecycle processes, and strong monitoring, so the principle is closer to how it is stated in theory.[1][3][5][6]
 - For access to business information, evidence of entitlement sprawl, unused permissions, and internal overexposure indicates that the effective norm is still broad access with minimal restriction, with least privilege applied selectively or after issues surface.[8][7][2][4]
 Sources
 [1] 10 Steps to Successful Privileged Access Management https://gotyto.com/thought-leadership/10-steps-to-successful-privileged-access-management/
 [2] How DSPM Prevents Data Exposure from Overprivileged ... https://www.zscaler.com/blogs/product-insights/how-dspm-helps-prevent-data-exposure-overprivileged-access
 [3] Privileged access management: Best practices, ... https://heimdalsecurity.com/blog/privileged-access-management-best-practices-implementation-and-tools/
 [4] Data Access Controls for SaaS | Case Study: Vox Media https://www.docontrol.io/case-studies/vox-media
 [5] PAM Lifecycle: In-depth Guide to Managing Privileged ... https://www.securden.com/blog/pam-lifecycle.html
 [6] What is the Principle of Least Privilege? https://www.wallix.com/blogpost/what-is-the-principle-of-least-privilege-and-how-do-you-implement-it-2/
 [7] The Business Risks of Excessive Privileged Access in ... https://www.lepide.com/blog/risks-of-excessive-privileged-access-in-active-directory/
 [8] Insider Attacks Climb Sharply in 2024 Data Report https://www.cybersecurity-insiders.com/2024-insider-threat-report/
 [9] 2024 Insider Threat Report: Key Risks and Cybersecurity ... https://cyberstrategyinstitute.com/2024-insider-threat-report-key-risks-and-cybersecurity-insights/
 [10] How common is overly strict access to data in your org. https://www.reddit.com/r/datascience/comments/19aedoc/how_common_is_overly_strict_access_to_data_in/
 # Google Gemini 1
 *Hypothesis: “In cybersecurity we have the maxim ‘least privilege, need to know’, which translates as granting people the minimum of access rights needed for their job. Yet with data classification the result is often the minimum of measures, unless absolutely necessary”. Find supporting evidence for this claim.* 
 This hypothesis touches on a fundamental tension in cybersecurity: **Access Control** (which is restrictive by nature) versus **Data Classification** (which is often seen as an administrative burden).
 While the principle of "Least Privilege" is a technical cornerstone enforced by systems, "Data Classification" relies heavily on human behavior and business costs, often leading to a "minimum viable effort" approach.
 ---
 ## 1. The Enforcement Gap
 The primary reason for this discrepancy is how these two concepts are implemented.
 - **Least Privilege (Restrictive):** This is often hard-coded into Identity and Access Management (IAM) systems. It is "fail-secure," meaning if you don't have the permission, you simply cannot perform the action.
 - **Data Classification (Permissive):** Classification is often manual or semi-automated. Because over-classifying data (e.g., marking everything "Top Secret") creates massive operational friction and storage costs, organizations default to the lowest classification level unless a specific regulatory trigger (like PCI-DSS or GDPR) forces their hand.
 ## 2. Supporting Evidence for "Minimum Measures"
 ### The "Default to Public" Bias
 Studies in organizational behavior suggest that employees view classification as a secondary task. According to various industry reports (such as the _Verizon Data Breach Investigations Report_), a significant portion of data breaches occur because sensitive data was stored in an unclassified or "General" folder. Organizations often apply the **minimum measure** of "Internal Use Only" to avoid the rigorous encryption and audit requirements of "Restricted" or "Confidential" tiers.
 ### Cost and Complexity of Controls
 Data classification isn't just a label; it’s a commitment to a set of controls.
 - **Storage Costs:** Highly classified data often requires expensive, redundant, and encrypted storage.
 - Usability: Measures like Digital Rights Management (DRM) or strict Data Loss Prevention (DLP) rules can break workflows.
    To maintain productivity, leadership often signs off on the "minimum necessary" classification to keep the business moving, effectively prioritizing availability over confidentiality.
 ### Compliance-Driven Security (The "Checklist" Mentality)
 Many organizations treat data classification as a compliance checkbox rather than a security strategy.
 - **Evidence:** In frameworks like ISO 27001, organizations are required to define classification levels. However, they often define them so broadly that the vast majority of data falls into a category with minimal protection.
 - **The Result:** If a regulation doesn't specifically demand a measure (like per-file encryption), it is rarely implemented.
 ---
 ## 3. Comparing the Two Mindsets
 |**Feature**|**Least Privilege (Access)**|**Data Classification (Protection)**|
 |---|---|---|
 |**Primary Goal**|Minimize the attack surface.|Categorize for handling.|
 |**Default State**|Deny All.|Open/General (often).|
 |**Friction Level**|High (but expected).|High (and often resisted).|
 |**Implementation**|Technical/Automated.|Policy/Behavioral.|
 ---
 ## Summary of the Tension
 The maxim "Least Privilege" is a **shield**, while Data Classification is often treated as a **filing system**. Because the latter requires constant manual effort and incurs operational costs, the "minimum of measures" becomes the path of least resistance. This creates a "security debt" where access is tight, but the data itself is poorly protected once an authorized user (or a compromised account) handles it.
 # Google Gemini 2
 Yes, your observation is supported by a significant "implementation gap" in modern cybersecurity. In short: **IT resources are protected by a "Shield" (Hard Enforcement), while Business Information is protected by a "Policy" (Soft Enforcement).**
 The evidence for why "least privilege" is better implemented for IT admins compared to business data access boils down to three core drivers:
 ---
 ## 1. Technical Tooling: The PAM vs. Governance Gap
 The industry has developed highly mature, automated tools for IT administration that do not yet have a seamless equivalent for everyday business data.
 - **For IT Admins:** Tools like **Privileged Access Management (PAM)** (e.g., CyberArk, BeyondTrust) enable **Just-in-Time (JIT)** access. An IT admin has zero standing privileges; they must request "Domain Admin" rights for a specific window (e.g., 2 hours). Once the task is done, the system automatically strips the rights.
 - **For Business Users:** Access to "Financial Projections" or "HR Records" usually relies on **Identity Governance and Administration (IGA)**. These are often static. Once a user is added to a "Finance" group, they stay there until a manual (and often "rubber-stamped") quarterly review happens. There is rarely a JIT system for reading a spreadsheet.
 ## 2. Risk Clarity: "Systemic" vs. "Incremental" Damage
 Cybersecurity teams prioritize what they can clearly quantify.
 - **IT Infrastructure (Systemic Risk):** A compromised admin account is an "extinction-level event" (e.g., ransomware deployment across the entire network). Because the **Blast Radius** is so high, management is willing to accept the friction of least privilege.
 - **Business Data (Incremental Risk):** The theft of a single client list is damaging but rarely crashes the company's entire infrastructure. Because the damage feels "contained," organizations are less willing to slow down business operations with strict access hurdles.
 ## 3. The "Productivity Tax" and Culture
 IT staff are culturally conditioned to work within restrictive environments (using "Service Accounts" or "Sudo"). Business users, however, often view security hurdles as an impediment to their primary job.
 - **The Help Desk Effect:** Research shows that when IT restricts a business user’s access to a folder they _might_ need, the user calls the Help Desk immediately. To reduce ticket volume, Help Desks often default to "over-provisioning"—granting broader access than necessary just to ensure the user doesn't call back.
 - **Admin Consistency:** IT admins are few in number and their roles are clearly defined (Network Admin, Database Admin). Business roles are fluid and "cross-functional," making it technically difficult to define what "least privilege" even looks like for a Marketing Manager who also assists with Product and Sales.
 ---
 ### Comparison Summary: The Implementation Gap
 |**Feature**|**IT Admin Privileges**|**Business Data Access**|
 |---|---|---|
 |**Control Model**|**Zero Standing Privilege** (ZSP)|**Persistent Access** (Group-based)|
 |**Enforcement**|Automated/Technical|Manual/Policy-based|
 |**Auditability**|High (Session recording common)|Low (Hard to see who read what)|
 |**Implementation**|**Mature** (PAM is a standard)|**Emerging** (Data Governance is often messy)|
 ---
 ## Conclusion
 Your hypothesis is correct: "Least privilege" is a technical reality for IT admins because we have the tools to automate it. For business data, it remains an aspirational goal because it requires human judgment and manual classification—both of which naturally trend toward the "minimum of measures" to keep the business moving.
 **Would you like me to look into "Zero Trust Data Access" (ZTDA) technologies, which are the industry's attempt to bring IT-level strictness to business document access?**
 ---
 Hypothesis: *Can we also see the ‘least privilege’ principle being better implemented when it comes to various levels of admin privileges for IT resources, vs access to business information?*
 ---
 Yes, there is significant evidence that the **Least Privilege** principle is much more rigorously applied to **IT infrastructure and admin rights** than to **business data**.
 The reason for this "implementation gap" is the difference between technical governance (managing _systems_) and cultural governance (managing _information_).
 ---
 ## 1. Technical Enforcement vs. Behavioral Expectation
 IT resources are managed through **Privileged Access Management (PAM)** and **Identity & Access Management (IAM)** tools. These systems allow for "hard" enforcement.
 - **IT Infrastructure (The Admin Level):** Removing "Local Admin" rights from laptops or "Domain Admin" from IT staff is a common, measurable goal. Tools can automatically rotate passwords and provide **Just-in-Time (JIT)** access. If an admin needs to change a server setting, they request access for one hour, and it is automatically revoked.
 - **Business Information (The Data Level):** Access to "Financial Reports" or "Project Strategy" is much "fuzzier." Because business roles are fluid, managers often grant broad access ("Just give them access to the whole folder") to avoid slowing down work. There is rarely a JIT system for "reading a PDF."
 ---
 ## 2. The "Blast Radius" Metric
 Security teams prioritize IT admin rights because the **Blast Radius** is objective and catastrophic.
 - **IT Admin:** A compromised "Superuser" can take down the entire network, install ransomware globally, or delete backups. The risk is **Systemic**.
 - **Business Data:** A compromised "Sales Manager" can steal customer lists. While damaging, it is rarely "existential" for the IT infrastructure. Therefore, companies invest heavily in PAM tools for admins while leaving business data in broad, "Internal Use Only" buckets.
 ### Comparison: Admin vs. Business Data
 |**Feature**|**IT Admin Privileges**|**Business Information Access**|
 |---|---|---|
 |**Control Tool**|PAM (e.g., CyberArk, BeyondTrust)|Shared Drives, SharePoint, Teams|
 |**Enforcement**|Hard (Access is blocked by default)|Soft (Access is often granted by peers/managers)|
 |**Audit Frequency**|High (Often daily/weekly)|Low (Quarterly "Access Reviews" often rubber-stamped)|
 |**Philosophy**|**Least Privilege** (Zero by default)|**Need to Know** (Often "Assume they need it")|
 ---
 ## 3. The "Rubber Stamp" Phenomenon
 Evidence for your claim can be found in User Access Reviews (UAR).
 In technical environments, engineers are used to justified access requests. However, in business departments, access reviews are often seen as an administrative chore.
 > **Research Insight:** Studies show that business managers have a high rate of "Access Creep." When asked to review who has access to a folder, they often approve everyone "just in case" to avoid interrupting someone's work. In contrast, IT departments use automated scripts to prune unused admin accounts because an unused admin account is a massive, clear liability.
 ---
 ## 4. Supporting Your Claim
 Your original hypothesis is supported by the fact that **Data Classification** (the "minimum measures" problem) is the weakest link. Even if an IT admin has "Least Privilege" over the server, if the data on that server is classified as "General" when it should be "Restricted," the technical controls on the admin are irrelevant—the data is already under-protected.
 ---
 *Do we see a difference between implementation of access restrictions between document storage and SaaS solutions?*
 ---
 There is a profound difference between the two, primarily driven by a shift from **"Centralized Governance"** to **"User-Led Decentralization."**
 While traditional document storage often feels like a "Fortress," SaaS solutions frequently resemble a "Wild West." This shift reinforces your hypothesis: when the burden of security moves from the system (IT) to the user (Business), the "minimum of measures" usually wins.
 ---
 ## 1. Document Storage: The "Fortress" Model
 In traditional environments (On-premise file shares, SharePoint), access is managed via **Hierarchical Permissions**.
 - **Implementation:** IT or "Data Owners" set permissions at the folder level. These are often static and reviewed during annual audits.
 - **The Least Privilege Reality:** It is easier to enforce here because the structure is rigid. If you aren't in the "Finance" group, you can't enter the "Finance" folder.
 - **The Classification Fail:** Even in this rigid system, your "minimum measures" claim holds true: people often dump sensitive files into "General" folders simply because they don't want to deal with the permission request process to get into a restricted one.
 ## 2. SaaS Solutions: The "Liquid" Model
 SaaS (Google Drive, Slack, Salesforce, Figma) introduces **Object-Level Sharing**, which shatters the traditional perimeter.
 - **The "Link-Sharing" Trap:** SaaS thrives on speed. Most SaaS apps allow users to "Share with anyone with the link."1 This is the ultimate "minimum measure"—it bypasses least privilege entirely to ensure productivity isn't hindered.
 - **SaaS Sprawl:** Because SaaS is decentralized, IT often loses visibility.2 Research indicates that up to **90% of SaaS applications in an enterprise are unmanaged** (Shadow IT).3 In these cases, there is _no_ least privilege; there is only "User Discretion."
 - **Identity vs. Access:** In SaaS, identity is often managed (SSO), but _what_ that identity can do inside the app is often left to the user. A user might be granted "Editor" rights to a whole workspace because the "Viewer" role was too restrictive for a five-minute task, and the permission is never revoked.
 ---
 ## 3. Comparison of Implementation Gaps
 |**Feature**|**Document Storage (Legacy)**|**SaaS Solutions (Modern)**|
 |---|---|---|
 |**Control Unit**|The Folder (Group-based)|The File/Object (User-based)|
 |**Primary Risk**|"Access Creep" (Too many folders)|"Oversharing" (Public links/Guest access)|
 |**Visibility**|High (IT can see the whole tree)|Low (Siloed within individual apps)|
 |**Least Privilege**|Enforced by IT Admins|Delegated to end-users|
 |**Classification**|Often ignored (Manual labeling)|Frequently non-existent|
 ---
 ## 4. Why SaaS Validates Your Hypothesis
 SaaS environments prove your point that we default to the "minimum of measures" for the sake of necessity.
 - **The Productivity Tax:** Implementing true "Least Privilege" in a tool like Slack or Teams (e.g., private channels for everything) is so administratively heavy that teams almost always opt for "Public Channels" by default.
 - **The "Shadow" Effect:** When security measures (like classification or restricted access) become too burdensome in a corporate document store, users migrate data to a personal SaaS account (Dropbox/Gmail) to "just get the job done."
 > **Key takeaway:** In SaaS, the "Least Privilege" principle is often sacrificed at the altar of **collaboration speed**.
--- a/Corpus/Sparks/Modules,
+++ b/Corpus/Sparks/Modules,
@ -0,0 +1,22 @@
 See also [Three user modes for AuditGlue](Three%20user%20modes%20for%20AuditGlue.md)
 # Guided implementation mode
 The 'guided implementation mode' will (roughly) resemble the structure and sequence of the [📼 ISO27DIY Video Series](../Standards/ISO27x/legacy/iso27DIY%20mk%20I/📼%20ISO27DIY%20Video%20Series.md). This will be the reference for now.
 # Operational mode
 Here's the ISMS tool structure created in cooperation with Nedap: [Nedap ISMS tool structure](Nedap%20ISMS%20tool%20structure.md).
 There's also this [ISO 27001 structure diagram](../Standards/ISO27x/legacy/iso27DIY%20mk%20I/ISO%2027001%20structure%20diagram.md).
 See also the ISMS Tool and Overzicht beveiliging Excel sheets created for NHC:
 - ![](NHC%20ISMS%20tool_template%20nieuw.xlsx)
 - ![](Overzicht%20beveiliging%20nieuw.xlsx)
 # Audit mode
 ![](../Attachments/ISO%2027001%20Implementatie%20dashboard%20Annex%20A.xlsx)
--- a/Corpus/Sparks/Most
+++ b/Corpus/Sparks/Most
@ -0,0 +1,18 @@
 # Most Challenging Clauses in ISO 27001
 Professionals cite difficulties with:
 * **Clause 4: Context of the Organization**
  * defining the organization’s boundaries
  * determining relevant interested parties
  * documenting the complex interrelationships among processes required by Clause 4.4.  Show how processes interact and link to business needs
 * **Clause 6: Planning (Risk Assessment and Objectives)**
  * identifying, evaluating, and treating risks
  * choosing a risk methodology
  * ensuring risk assessments meet auditor expectations
 * **Clause 9: Performance Evaluation**
  * Monitoring, measurement, analysis, and evaluation (especially Clause 9.1), esp. establish meaningful objectives, gather relevant metrics, and provide evidence of improvement.
 * **Clause 10: Improvement (Nonconformity and Corrective Action)**
  * a systematic approach to identifying, investigating, and tracking corrective actions. 
 * **Annex A Control Mapping and Statement of Applicability**
  * The breadth of required controls and the need to justify inclusions/exclusions create confusion
--- a/Corpus/Sparks/NHC
+++ b/Corpus/Sparks/NHC
--- a/Corpus/Sparks/Nedap
+++ b/Corpus/Sparks/Nedap
@ -0,0 +1,32 @@
 ### CONTEXT
 Stakeholderanalyse
 Wet- en regelgeving
 Ontwikkelingen, trends, thema's
 SWOT
 Strategie organisatie
 Doelstellingen/KPI's
 ### MIDDELEN, RISICO'S EN MAATREGELEN
 - Bedrijfsprocessen
 - Assets (middelen)
 - Methode risicoanalyse en -management (RAM)
 - Risicoanalyse en -management (RAM)
 - Maatregelen
 	- Implementation planning; for inspiration, see [Topical InfoSec Kanban’s](../Literature%20notes/Topical%20InfoSec%20Kanban’s.md)
 - Monitoren en meten
 ### STRUCTUUR ISMS
 - Rollen
 - ISMS planning
 	- for inspiration, see [Topical InfoSec Kanban’s](../Literature%20notes/Topical%20InfoSec%20Kanban’s.md)
 Interne audit planning
 ### OPERATIONEEL PROCES
 Regulier Security Overleg
 Review van risico's en maatregelen
 Beoordelen van metingen
 Incidenten
 Wijzigingsbeheer
 **Actielijst**
--- a/Corpus/Sparks/Operational
+++ b/Corpus/Sparks/Operational
@ -0,0 +1,20 @@
 Operational Technology Security – or OT Security
 [Fortinet article](https://www.fortinet.com/solutions/industries/scada-industrial-control-systems/what-is-ot-security)
 Mentions "Industrial Internet of Things (IIOT) Devices" and SCADA (see CISSP book)
 Relationship to ISO 27k:
 - most obvious to [ISO 27001 A 13 Communications security](../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001%20A%2013%20Communications%20security.md) 
 - also ISA/IEC 62443 series – wasn't that the thing at Ultimaker?
 - Detailled Google Groups [post](https://groups.google.com/g/iso27001security/c/DhgybAN7pxk?pli=1) mentions:
 	- [Generic SCADA Risk Management Framework](https://www.tisn.gov.au/Documents/SCADA-Generic-Risk-Management-Framework.pdf)
 	- [ISO 27019 Information security controls for the energy utility industry]([https://www.iso.org/standard/68091.html](https://www.iso.org/standard/68091.html))
 	- [Presentation]([https://isms.jp/csms/doc/JIP-CSMS120E-10.pdf](https://isms.jp/csms/doc/JIP-CSMS120E-10.pdf)) on the relation between 27001 (ISMS Implementation) and IEC 62443 (CSMS Implementation)
 See also:
 - [](../Standards/SANS/SANS_CIS_poster_Winter2016_CSCs.pdf)
 - [](../Standards/other/CIS_Controls_V7_Poster.pdf)
 - AuditScripts-CIS-Controls-Master-Mappings-v7.1c.xlsx (in the Attachments folder, linking in editor to this file type is not supported)
--- a/Corpus/Sparks/Overzicht
+++ b/Corpus/Sparks/Overzicht
--- a/Corpus/Sparks/Perverse
+++ b/Corpus/Sparks/Perverse
@ -0,0 +1,4 @@
 - Nodeloos complex geformuleerde norm, vereist consultants om hem begrijpbaar te maken
 - Consultants zijn er niet bij gebaat om de eenvoud te laten zien (want minder uren)
 - Bestaande software vereist diepgaande domeinkennis om het te implementeren en te bedienen. Wordt veelal verkocht via ‘partner kanalen’ (ISO 27001 consultants).
 - Certificerende Instanties doen het voorkomen dat ze objectief toetsen t.o.v. Een norm die maar op één manier kan worden uitgelegd, maar in de praktijk wil geen CI bekend staan als de strengste partij met het laagste slagingspercentage.
--- a/Corpus/Sparks/Privacy.md
+++ b/Corpus/Sparks/Privacy.md
@ -0,0 +1,7 @@
 [Core concepts of Privacy](Core%20concepts%20of%20Privacy.md)
 [AVG GDPR resources](../Standards/AVG/AVG%20GDPR%20resources.md)
 Privacy in ISO 27001:
 - [ISO 27001 A 18 Compliance](../Standards/ISO27x/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)
--- a/Corpus/Sparks/Problems
+++ b/Corpus/Sparks/Problems
@ -0,0 +1,4 @@
 De problemen:
 1. Bedrijven hebben vaak de maatregelen getroffen, maar het voorafgaande proces niet gedocumenteerd
 2. De ISO administratie wordt achteraf gevuld door deskundigen en bestaat als een separaat orakel, dat alleen voor de audits geraadpleegd wordt door diezelfde deskundigen.
--- a/Corpus/Sparks/Risk
+++ b/Corpus/Sparks/Risk
@ -0,0 +1,15 @@
 Risk appetite is "The types and amount of risk, on a broad level, an organization is willing to accept in its pursuit of value." – [NIST](https://csrc.nist.gov/glossary/term/risk_appetite)
 According to the PMBOK® Guide [(source)](http://cybersecurity-materiality.com/):
 - Risk Tolerance is the _"specified range of acceptable results."_
 - Risk Threshold is the _"level of risk exposure above which risks are addressed and below which risks may be accepted."_
 - Risk Appetite is the _"degree of uncertainty an organization or individual is willing to accept in anticipation of a reward."_
 Articulate the risk appetite to:
 - help guide risk and reward decision-making
 - help to embed the right risk culture
 See [Topical InfoSec Kanban’s](../Literature%20notes/Topical%20InfoSec%20Kanban’s.md) for inspiration.
 See also [Risk tolerance](../Sparks/Risk%20tolerance.md)
--- a/Corpus/Sparks/Risk
+++ b/Corpus/Sparks/Risk
@ -6,5 +6,5 @@ NIST gives [several definitions](https://csrc.nist.gov/glossary/term/risk_tolera
 "The level of risk or the degree of uncertainty that is acceptable to an organization."
-See also [Risk appetite](../💡Drafts%20and%20Ideas/Risk%20appetite.md)
+See also [Risk appetite](../Drafts%20and%20Ideas/Risk%20appetite.md)
--- a/Corpus/Sparks/Risks.md
+++ b/Corpus/Sparks/Risks.md
@ -1,12 +1,12 @@
 [Assets, Vulnerabilities, Threats, Risks](Assets,%20Vulnerabilities,%20Threats,%20Risks.md)
-[Vulnerability](../💡Drafts%20and%20Ideas/Vulnerability.md)
+[Vulnerability](../Drafts%20and%20Ideas/Vulnerability.md)
 [Information security concepts MoC](../Information%20security%20concepts%20MoC.md)
 [Assets, Vulnerabilities, Threats, Risks](../📚️%20Literature%20notes/Assets,%20Vulnerabilities,%20Threats,%20Risks.md)
 See also slide decks made for workshop sessions. Those for Kaliber, Nedap and Networking4AL are the most recent.
-See also [Risk appetite](../💡Drafts%20and%20Ideas/Risk%20appetite.md)
+See also [Risk appetite](../Drafts%20and%20Ideas/Risk%20appetite.md)
 See also [Classificatie van risico's obv Oorzaken](Classificatie%20van%20risico's%20obv%20Oorzaken.md)
 ## Definitions
--- a/Corpus/Sparks/Service
+++ b/Corpus/Sparks/Service
--- a/Corpus/Sparks/The
+++ b/Corpus/Sparks/The
@ -0,0 +1,7 @@
 The Art of Service is a company offering knowledge resources for organizations that don't want to use external consultants.
 See their [Topical InfoSec Kanban’s](../Literature%20notes/Topical%20InfoSec%20Kanban’s.md) for an example.
 This is their [website](https://theartofservice.com).
 Managed by Gerard Blokdyk ([@blokdykg](https://twitter.com/blokdykg)) and Ivanka Menken ([@ivankamenken](https://twitter.com/ivankamenken)).
--- a/Corpus/Sparks/Three
+++ b/Corpus/Sparks/Three
@ -0,0 +1,5 @@
 I foresee different user modes for AuditGlue:
 - Guided implementation: the novice user is taken step by step through the process of setting up the ISMS, including the identification of risks and the definition of controls. There is a lot of content (text, animations, video's) explaining the process and ISO 27001.
 - Operational: aimed at users with ISO 27001 domain knowledge and experience. Offers traditional GRC software forms and dashboards
 - Audits: offers an interface to facilitate internal and external audits. Based on a matrix with the ISO 27001 clauses and controls, against columns for identified risks, defined controls, stated policies, implementation (planned or achieved), measurements, monitoring activities, and evaluation outcomes. Each cell contains (links to) proofs.
--- a/Corpus/Sparks/Toegevoegde
+++ b/Corpus/Sparks/Toegevoegde
@ -0,0 +1,4 @@
 - Zorgen dat het managen van Infosec risico’s een natuurlijk onderdeel wordt van alle activiteiten rond informatieverwerking.
 - Bedrijven laten zien dat ze dit zelf kunnen. Ze doen het al voor een groot deel maar hebben nooit geleerd de administratie goed te voeren
 - Een stuk software bieden waarmee ze de administratie zelf kunnen opzetten en gaandeweg leren hun informatierisico’s norm-conform te beheersen.
--- a/Corpus/Sparks/Verantwoordelijkheid
+++ b/Corpus/Sparks/Verantwoordelijkheid
@ -0,0 +1,4 @@
 Een universiteit biedt onderzoeksafdelingen de mogelijkheid om vrijelijk hun applicaties en databases op te tuigen binnen hun eigen Kubernetes containers. Daarbij zijn ze zelf verantwoordelijk voor de informatiebeveiliging daarvan. Het is vervolgens aan de IT afdeling om de containers te ‘deployen’. Daarbij ontdekken ze dat veel containers / applicaties / databases onveilig geconfigureerd zijn, oude versies van software met bekende kwetsbaarheden herbergen, etc.
 Mijn stelling is dat er voor het succesvolle delegeren van de verantwoordelijk voor informatiebeveiliging in ieder geval nodig is: een drive om het ook goed te doen (bijv. niet in beheer nemen, kosten in rekening brengen, kwaliteit van de beveiliging als KPI van de afdeling), en kennis en resources het uit te voeren (of financiele middelen om het te laten doen).
 Is er literatuur beschikbaar over deze kwestie? Zijn er andere succesvoorwaarden bekend?
--- a/processvolwassenheid.md
+++ b/processvolwassenheid.md
@ -0,0 +1,15 @@
 Het CMM (Capability Maturity Model) streeft naar hogere procesvolwassenheid omdat volwassener processen een aantal concrete voordelen opleveren:
 **Voorspelbaarheid** — je weet wat een proces oplevert, hoe lang het duurt en wat het kost. Verrassingen nemen af naarmate processen herhaalbaarder worden.
 **Beheersbaarheid** — je kunt bijsturen omdat je meet en begrijpt wat er gebeurt. Bij lage volwassenheid stuur je op gevoel of incident.
 **Kwaliteitsborging** — hogere volwassenheid betekent dat kwaliteit ingebakken zit in het proces, niet afhankelijk is van de individuele medewerker die het uitvoert.
 **Schaalbaarheid** — gedocumenteerde en herhaalbare processen zijn overdraagbaar en schaalbaar, onafhankelijk van sleutelpersonen.
 **Continu verbeteren wordt mogelijk** — je kunt pas structureel verbeteren als je een baseline hebt. Zonder gedefinieerde processen verbeter je ad hoc, niet systematisch.
 **Auditbaarheid** — je kunt aantonen wat je doet en hebt gedaan, wat essentieel is voor certificering, compliance en vertrouwen bij klanten of toezichthouders.
 De ironie is dat dit vrijwel exact de drie peilers zijn die jij voor ISO 27001 beschrijft — risicomanagement (beheersbaarheid), continue verbetering, en borging (aantoonbaarheid). CMM en ISO 27001 adresseren in essentie hetzelfde probleem, alleen vanuit een andere invalshoek.
--- a/Corpus/Sparks/Vulnerability.md
+++ b/Corpus/Sparks/Vulnerability.md
@ -0,0 +1,18 @@
 # Vulnerability
 A vulnerability is a weakness that exposes an asset to possible compromise. Weaknesses can be organizational, logical, physical, or human.
 See also:
 - [Assets](../Sparks/Assets.md)
 - [Risks](../Sparks/Risks.md)
 - [Threat](../📚️%20Literature%20notes/Threat.md)
 - [Vulnerability Disclosure Policy](Vulnerability%20Disclosure%20Policy.md)
 - [Dealing with a reported application vulnerability Log4j](Dealing%20with%20a%20reported%20application%20vulnerability%20Log4j.md)
 - [Software vulnerability databases](../Literature%20notes/Software%20vulnerability%20databases.md)
 - (https://www.google.nl/search?q=software+vulnerability+databases)
 - [API Endpoint Vulnerabilities](https://www.reblaze.com/blog/api-security/how-hackers-attack-your-mobile-apps-part-3-api-endpoint-vulnerabilities/)
 - [NSA and CISA publish hardening guides](https://www.nsa.gov/Press-Room/News-Highlights/Article/Article/2716980/nsa-cisa-release-kubernetes-hardening-guidance/utm_source/nsa-cisa-release-kubernetes-hardening-guidance/)
 - [ISO 27001 A 12.6 Technical vulnerability management](../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001%20A%2012.6%20Technical%20vulnerability%20management.md)
 - [a-8.8-Management-of-technical-vulnerabilities](../Standards/ISO27x/OST/27002/EN/a-8.8-Management-of-technical-vulnerabilities.md)
--- a/Corpus/Standards/ISO27x/Authentication.md
+++ b/Corpus/Standards/ISO27x/Authentication.md
@ -6,7 +6,7 @@ Authentication is the proof of identity that is achieved through providing crede
 See also:
 - [a-8.5-Secure-authentication](OST/27002/EN/a-8.5-Secure-authentication.md)
 - [Authentication Methods Used for Network Security](../../Literature%20notes/Authentication%20Methods%20Used%20for%20Network%20Security.md)
- [Identity and Access Management (IAM)](../../💡Drafts%20and%20Ideas/Identity%20and%20Access%20Management%20(IAM).md)
+- [Identity and Access Management (IAM)](../../Drafts%20and%20Ideas/Identity%20and%20Access%20Management%20(IAM).md)
 - [Authorization](Authorization.md)
- [Identification](../../💡Drafts%20and%20Ideas/Identification.md)
+- [Identification](../../Drafts%20and%20Ideas/Identification.md)
--- a/Corpus/Standards/ISO27x/Authorization.md
+++ b/Corpus/Standards/ISO27x/Authorization.md
@ -5,9 +5,9 @@ See also:
 - [Authorization vs Access Control](../../Sparks/Authorization%20vs%20Access%20Control.md)
 - [Access Control Models](../../Sparks/Access%20Control%20Models.md)
 - [Authentication](Authentication.md)
- [Identification](../../💡Drafts%20and%20Ideas/Identification.md)
+- [Identification](../../Drafts%20and%20Ideas/Identification.md)
 - [CASSM Consumer Authentication Strength Maturity Model](../../Literature%20notes/CASSM%20Consumer%20Authentication%20Strength%20Maturity%20Model.md)
- [Identity and Access Management (IAM)](../../💡Drafts%20and%20Ideas/Identity%20and%20Access%20Management%20(IAM).md)
+- [Identity and Access Management (IAM)](../../Drafts%20and%20Ideas/Identity%20and%20Access%20Management%20(IAM).md)
 - [a-5.15-Access-control](OST/27002/EN/a-5.15-Access-control.md) ???
--- a/Corpus/Standards/ISO27x/Implementation
+++ b/Corpus/Standards/ISO27x/Implementation
@ -7,7 +7,7 @@ Voorbeelden:
 [Verbeterlijst](Verbeterlijst%20Producten.md#BIA%20Workshop)
 Literature notes:
- [Business Impact Analysis (BIA)](../../../🎇%20Sparks/Business%20Impact%20Analysis%20(BIA).md)
+- [Business Impact Analysis (BIA)](../../../Sparks/Business%20Impact%20Analysis%20(BIA).md)
 **Doel:**
--- a/Corpus/Standards/ISO27x/Implementation
+++ b/Corpus/Standards/ISO27x/Implementation
@ -5,7 +5,7 @@ Voorbeelden:
 - [BIA en DRP Sessies HK](../../../../Clients/Humankind/BIA%20en%20DRP%20Sessies%20HK.md)
 Literatuur:
- [Disaster Recovery Planning](../../../🎇%20Sparks/Disaster%20Recovery%20Planning.md)
+- [Disaster Recovery Planning](../../../Sparks/Disaster%20Recovery%20Planning.md)
 Doelen:
 - RPO – Recovery Point Objective (assets) – acceptable data loss; the point in time that you wish to recover to (maar wellicht ook een maat voor hoe vaak je een noodvoorziening (als een print-out van een rooster) moet verversen)
--- a/Corpus/Standards/ISO27x/MoC
+++ b/Corpus/Standards/ISO27x/MoC
@ -11,9 +11,9 @@ Recent:
 - [m400-more-governance](../../../../iso27DIY-gis/guide/m400/m400-more-governance.md)
 Older:
- [Roles and Responsibilities](../../🎇%20Sparks/Roles%20and%20Responsibilities.md)
+- [Roles and Responsibilities](../../Sparks/Roles%20and%20Responsibilities.md)
- [Risk ownership](../../🎇%20Sparks/Risk%20ownership.md)
+- [Risk ownership](../../Sparks/Risk%20ownership.md)
 - [Ideas on Risk Ownership](../../Sparks/Ideas%20on%20Risk%20Ownership.md)
- [Asset ownership](../../🎇%20Sparks/Asset%20ownership.md)
+- [Asset ownership](../../Sparks/Asset%20ownership.md)
 - [Procuratieregeling](../../Various/Procuratieregeling.md)
 - [Control ownership](../../Sparks/Control%20ownership.md)
--- a/Corpus/Standards/ISO27x/OST/27002/EN/a-5.7-Threat-intelligence.md
+++ b/Corpus/Standards/ISO27x/OST/27002/EN/a-5.7-Threat-intelligence.md
@ -74,5 +74,5 @@ c)  as input to the information security test processes and techniques.
 The organization should share threat intelligence with other organizations on a mutual basis in order to improve overall threat intelligence.
 # Related:
- [Threat Intelligence](../../../../../🎇%20Sparks/Threat%20Intelligence.md)
+- [Threat Intelligence](../../../../../Sparks/Threat%20Intelligence.md)
 - [[ISO_27002_PE 5.7 Threat intelligence]]
--- a/Corpus/Standards/ISO27x/legacy/AuditGlue
+++ b/Corpus/Standards/ISO27x/legacy/AuditGlue
@ -1 +1 @@
-[Concurrenten](../../../../../💡Permanent%20ideas/Concurrenten.md)
+[Concurrenten](../../../../../Permanent%20ideas/Concurrenten.md)
--- a/Corpus/Standards/ISO27x/legacy/iso27DIY
+++ b/Corpus/Standards/ISO27x/legacy/iso27DIY
@ -175,7 +175,7 @@ Again, don't loose yourself in academic discussions on the exact likelihoods of
 Also, don't try to create the 'Complete list of risks': start with the top-of-mind risks and expand and refine in the next iterations.
-See also [Assets, Vulnerabilities, Threats, Risks](../../../../🎇%20Sparks/Assets,%20Vulnerabilities,%20Threats,%20Risks.md).
+See also [Assets, Vulnerabilities, Threats, Risks](../../../../Sparks/Assets,%20Vulnerabilities,%20Threats,%20Risks.md).
 Next, you need to decide on Risk Treatment.
--- a/Corpus/Standards/ISO27x/legacy/iso27DIY
+++ b/Corpus/Standards/ISO27x/legacy/iso27DIY
@ -5,7 +5,7 @@ Pivoting away from 'guided implementation management' to:
 Related:
 - [Three user modes for AuditGlue](../../../../Drafts%20and%20Ideas/Three%20user%20modes%20for%20AuditGlue.md)
- [Distributed usage of AuditGlue](../../../../../../💡Permanent%20ideas/Distributed%20usage%20of%20AuditGlue.md)
+- [Distributed usage of AuditGlue](../../../../../../Permanent%20ideas/Distributed%20usage%20of%20AuditGlue.md)
 - [Modules, Screens and Content](../../../../Drafts%20and%20Ideas/Modules,%20Screens%20and%20Content.md)
 - [AuditGlue ERD](../AuditGlue%20ERD.md)
 - [AuditGlue Business model](../AuditGlue%20Business%20model.md)
--- a/Corpus/Standards/NIST/NIST
+++ b/Corpus/Standards/NIST/NIST
@ -6,4 +6,4 @@
 Comparable to ISO/IEC 23894:2023 ?
-See [Risk management](../../🎇%20Sparks/Risk%20management.md)
+See [Risk management](../../Sparks/Risk%20management.md)
--- a/Corpus/Standards/other/C2M2
+++ b/Corpus/Standards/other/C2M2
@ -8,5 +8,5 @@ Documentation, tools, practices and self-evaluation tools can be found through [
 ![](C2M2%20Version%202.1%20June%202022.pdf)
 Related:
- [Operational Technology](../../💡Drafts%20and%20Ideas/Operational%20Technology.md)
+- [Operational Technology](../../Drafts%20and%20Ideas/Operational%20Technology.md)
 - [IEC 62443 Cybersecurity for operational technology in automation and control systems](IEC%2062443%20Cybersecurity%20for%20operational%20technology%20in%20automation%20and%20control%20systems.md)
--- a/Corpus/Standards/other/OWASP
+++ b/Corpus/Standards/other/OWASP
@ -27,4 +27,4 @@ Laatste retrieval date:  5 februari 2025
 [CICD-SEC-10](https://owasp.org/www-project-top-10-ci-cd-security-risks/CICD-SEC-10-Insufficient-Logging-And-Visibility): Insufficient Logging and Visibility
-related: [Risk management](../../🎇%20Sparks/Risk%20management.md)
+related: [Risk management](../../Sparks/Risk%20management.md)
--- a/Corpus/Standards/other/SCF
+++ b/Corpus/Standards/other/SCF
@ -11,6 +11,6 @@ More detail in Security & Privacy Risk Management Model (SP-RMM) Overview
 Related:
 - [Secure Controls Framework](../../Literature%20notes/Secure%20Controls%20Framework.md)
- [Risk analysis](../../🎇%20Sparks/Risk%20analysis.md)
+- [Risk analysis](../../Sparks/Risk%20analysis.md)
- [Risk inventories](../../🎇%20Sparks/Risk%20inventories.md)
+- [Risk inventories](../../Sparks/Risk%20inventories.md)
--- a/Corpus/Standards/other/SCF
+++ b/Corpus/Standards/other/SCF
@ -7,8 +7,8 @@ https://securecontrolsframework.com/risk-management-model/
 Related:
 - [Secure Controls Framework](../../Literature%20notes/Secure%20Controls%20Framework.md)
- [Threat Intelligence](../../🎇%20Sparks/Threat%20Intelligence.md)
+- [Threat Intelligence](../../Sparks/Threat%20Intelligence.md)
- [Assets, Vulnerabilities, Threats, Risks](../../🎇%20Sparks/Assets,%20Vulnerabilities,%20Threats,%20Risks.md)
+- [Assets, Vulnerabilities, Threats, Risks](../../Sparks/Assets,%20Vulnerabilities,%20Threats,%20Risks.md)
 Secure Controls Framework
`@ -12,4 +12,4 @@ Articulate the risk appetite to:`

	`See [Topical InfoSec Kanban’s](../Literature%20notes/Topical%20InfoSec%20Kanban’s.md) for inspiration.`	`See [Topical InfoSec Kanban’s](../Literature%20notes/Topical%20InfoSec%20Kanban’s.md) for inspiration.`

	`See also [Risk tolerance](../🎇%20Sparks/Risk%20tolerance.md)`	`See also [Risk tolerance](..//Risk%20tolerance.md)`
`@ -398,7 +398,7 @@ Serve on a team of Cyber threat analysts responsible for the 24x7 analyses and r`



	`Do you actively share [Operational Technology](../../💡Drafts%20and%20Ideas/Operational%20Technology.md) threat related intelligence with your peers?`	`Do you actively share [Operational Technology](../../Drafts%20and%20Ideas/Operational%20Technology.md) threat related intelligence with your peers?`

	`Maintain and drive the development of new reports of Cyber Threat Intelligence analysis to peers, management and (internal) customer teams for purposes of situational awareness and making threat intelligence actionable.`	`Maintain and drive the development of new reports of Cyber Threat Intelligence analysis to peers, management and (internal) customer teams for purposes of situational awareness and making threat intelligence actionable.`
`@ -1,4 +1,4 @@`
	`See also [Risk inventories](../🎇%20Sparks/Risk%20inventories.md)`	`See also [Risk inventories](../Sparks/Risk%20inventories.md)`

	`https://cs4e.pages.labranet.jamk.fi/ooc/30-Cyber_Attack/01-Threats_and_Attacks/`	`https://cs4e.pages.labranet.jamk.fi/ooc/30-Cyber_Attack/01-Threats_and_Attacks/`
		`@ -0,0 +1,3 @@`
							`- [Information security concepts MoC](../Information%20security%20concepts%20MoC.md)`
							`- [🗃 Standards and Regulations for information security](../Standards/other/🗃%20Standards%20and%20Regulations%20for%20information%20security.md)`
`@ -6,5 +6,5 @@ NIST gives [several definitions](https://csrc.nist.gov/glossary/term/risk_tolera`

	`"The level of risk or the degree of uncertainty that is acceptable to an organization."`	`"The level of risk or the degree of uncertainty that is acceptable to an organization."`

	`See also [Risk appetite](../💡Drafts%20and%20Ideas/Risk%20appetite.md)`	`See also [Risk appetite](../Drafts%20and%20Ideas/Risk%20appetite.md)`
`@ -1 +1 @@`
	`[Concurrenten](../../../../../💡Permanent%20ideas/Concurrenten.md)`	`[Concurrenten](../../../../../Permanent%20ideas/Concurrenten.md)`
`@ -6,4 +6,4 @@`

	`Comparable to ISO/IEC 23894:2023 ?`	`Comparable to ISO/IEC 23894:2023 ?`

	`See [Risk management](../../🎇%20Sparks/Risk%20management.md)`	`See [Risk management](../../Sparks/Risk%20management.md)`
`@ -27,4 +27,4 @@ Laatste retrieval date: 5 februari 2025`
	`[CICD-SEC-10](https://owasp.org/www-project-top-10-ci-cd-security-risks/CICD-SEC-10-Insufficient-Logging-And-Visibility): Insufficient Logging and Visibility`	`[CICD-SEC-10](https://owasp.org/www-project-top-10-ci-cd-security-risks/CICD-SEC-10-Insufficient-Logging-And-Visibility): Insufficient Logging and Visibility`


	`related: [Risk management](../../🎇%20Sparks/Risk%20management.md)`	`related: [Risk management](../../Sparks/Risk%20management.md)`