cleaning up Sparks

Content Factory/Scratch file/Example of ISO 27001 mystique.md

@@ -0,0 +1,9 @@
+# Example of ISO 27001 mystique
+
+ISO 27001 is a framework, and you cannot successfully implement it by treating the text of the standard as a series of instructions to be followed in the order in which they were printed. If you try that, things will become very confusing very quickly.
+
+For example, the requirement of having an information security policy is first (?) mentioned in [Chapter 5.1](../../Corpus/MoCs/ISO_27001_2022_5.1_MoC%20Leadership%20and%20commitment.md), "Leadership and commitment", where it says that top management must have it established, *together* with information security objectives. Then in [Chapter 5.2](../../Corpus/Standards/ISO27x/OST/27001/EN/c-5.2-Policy.md), 'Policy', it states that these objectives form *part of* the information security policy, referencing forward to  [Chapter 6.2](../../Corpus/MoCs/ISO_27001_2022_6.2_MoC%20Information%20security%20objectives%20and%20planning%20to%20achieve%20them.md), "Information security objectives and planning to achieve them", which demands that organizations should set objectives consistent with the  policy. Of course there's also a corresponding Control called "Policies for information security" ([5.1](../../Corpus/Standards/ISO27x/legacy/iso27DIY%20mk%20I/ISO_27002_2022_5.1_MoC%20Policies%20for%20information%20security.md)), which explains that there will be an information security policy at the highest level of the organization, including objectives "or the framework for setting objectives", and further "topic-specific policies as needed", which of course need their own objectives.
+
+Programmers may love this kind of recursiveness when it's in coding exercises.
+
+

Content Factory/Scratch file/GRC software is geschreven voor domeindeskundigen.md

@@ -0,0 +1,16 @@
+This note relates to the [ISO27DIY Business model](../../Corpus/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?