working on the RTP

Corpus/ISO 27002 Themes and Attributes.md

@@ -0,0 +1,67 @@
+# ISO 27002 Themes and Attributes
+
+## Themes
+
+In ISO 27002, controls are categorized into four main themes:
+*   **Organizational** (Clause 5 - all controls numbered 5.n)
+*   **People** (Clause 6 - all controls numbered 6.n)
+*   **Physical** (Clause 7 - all controls numbered 7.n)
+*   **Technological** (Clause 8 - all controls numbered 8.n)
+
+## Attributes
+
+Every control is associated with five attributes, which allow organizations to view and categorize the controls from different perspectives. The attributes and their possible values are:
+
+### Information Security Properties
+
+Views controls from the perspective of which characteristic of information the control contributes to preserving.
+*   Confidentiality
+*   Integrity
+*   Availability
+### Control Type
+
+Views controls from the perspective of when and how the control modifies risk regarding the occurrence of an information security incident.
+*   Preventive
+*   Detective
+*   Corrective
+
+
+### 3. Cybersecurity Concepts
+
+Based on the cybersecurity framework concepts defined in ISO/IEC TS 27110.
+
+|**Attribute**|**Description**|**Purpose**|**Control Examples**|
+|---|---|---|---|
+|**Identify**|Activities to understand the business context, the resources that support critical functions, and the related risks.|To develop the organizational understanding to manage risk to systems, assets, data, and capabilities.|Inventory of information (5.9), Risk assessment (5.1), Identification of legal requirements (5.31).|
+|**Protect**|Safeguards to ensure the delivery of critical infrastructure services and limit the impact of a potential security event.|To prevent or contain the impact of a potential cybersecurity event.|Access control (8.3), Information encryption (8.24), Secure authentication (8.5), Physical security (7.1).|
+|**Detect**|Activities to identify the occurrence of a cybersecurity event in a timely manner.|To enable timely discovery of security events to minimize damage.|Logging (8.15), Monitoring activities (8.16), Intrusion detection (8.1).|
+|**Respond**|Actions taken regarding a detected cybersecurity incident to contain its impact.|To take action once an incident is discovered to keep it from spreading or getting worse.|Incident response planning (5.24), Reporting events (5.25), Incident management (5.26).|
+|**Recover**|Activities to restore any capabilities or services that were impaired due to a cybersecurity incident.|To restore "business as usual" and support timely resilience.|Backup (8.13), ICT readiness for business continuity (5.30), Post-incident learning.|
+### 4. Operational Capabilities
+The Operational Capabilities help practitioners understand the functional area a control belongs to.
+
+|**Capability**|**Description**|
+|---|---|
+|**Governance**|Policies, frameworks, and management oversight.|
+|**Asset Management**|Identification and protection of information assets and hardware.|
+|**Information Protection**|Technical and organizational measures to keep data secure.|
+|**Human Resource Security**|Security relating to the lifecycle of employment (hiring to termination).|
+|**Physical Security**|Protecting physical premises, equipment, and facilities.|
+|**System and Network Security**|Hardening infrastructure, managing traffic, and securing connections.|
+|**Application Security**|Security within software development and business applications.|
+|**Secure Configuration**|Standardizing settings for hardware, software, and services.|
+|**Identity and Access Management**|Managing who can access what (IAM).|
+|**Threat and Vulnerability Management**|Identifying risks and patching security holes.|
+|**Continuity**|Resilience and recovery planning for disruptions.|
+|**Supplier Relationships Security**|Managing risks from third parties and the supply chain.|
+|**Legal and Compliance**|Meeting laws, regulations, and contractual obligations.|
+|**Information Security Assurance**|Auditing and monitoring to ensure controls are working.|
+|**Information Security Incident Management**|Detecting and responding to security events.|
+
+### 5. Security Domains
+
+Views controls from the perspective of four high-level information security domains.
+*   Governance_and_Ecosystem
+*   Protection
+*   Defence
+*   Resilience

Corpus/Obsidian Front Matter Syntax.md

@@ -0,0 +1,77 @@
+# Obsidian Front Matter Syntax
+
+**Obsidian’s front matter follows YAML syntax**, with a few **important caveats**.
+### What works (standard YAML)
+
+Obsidian uses **YAML front matter** at the top of a note, delimited by `---`. Most standard YAML features work as expected, see this short example:
+
+```YAML
+---
+
+title: My Note
+
+tags:
+
+  - obsidian
+
+  - yaml
+
+published: true
+
+rating: 4.5
+
+created: 2026-04-21
+
+---
+```
+
+This includes:
+
+- Key–value pairs
+- Lists (arrays)
+- Booleans, numbers, strings, dates
+- Nested objects
+
+### Obsidian-specific limitations & quirks
+
+Although it’s YAML, Obsidian does **not support the full YAML spec equally everywhere**:
+
+1. **Tabs are not allowed**  
+    YAML requires spaces for indentation. Tabs can break parsing.
+    
+2. **Advanced YAML features may not be recognized** These may technically be valid YAML but are not reliably usable in Obsidian:
+    
+    - Anchors (`&` / `*`)
+    - Complex inline objects
+    - Multi-document YAML
+
+3. **Everything is treated as metadata, not logic** Obsidian doesn’t “execute” YAML — it just reads values for:
+    
+    - Properties panel
+    - Search
+    - Filters
+    - Plugins (e.g., Dataview)
+
+4. **Some plugins impose their own expectations** For example:
+    
+    - `tags` should usually be a list of strings
+    - Dates may need to be ISO-like (`YYYY-MM-DD`) for queries to work
+
+5. **Inline formatting is treated as plain text** Links or markdown inside front matter are just strings:
+    
+    `author: "[[Richard Kranendonk]]"`
+      ``
+    
+### ✅ Best practice
+
+Think of Obsidian front matter as:
+
+> **“Well-behaved, simple YAML meant for metadata, not configuration logic.”**
+
+Stick to:
+
+- Scalars (strings, numbers, booleans)
+- Lists
+- Simple nesting
+- Spaces (not tabs)
+

Corpus/Sparks/How to work the Kanban.md

@@ -18,7 +18,7 @@ There wil also be other project todos specific for the organization. Incorporate
 ## PDCA cycle
 Controls from Annex A 'come alive' by connecting them to a real world Risk. Next, a Policy had to be defined (we are going to mitigate this risk by ...), the implementation of the Control and its associated Measuring mechanism needs to be planned, then after the Implementation the measurements need to be Evaluated and additional actions need to be identified (and planned) for the next cycle. 
 
-Related: [About ISO27DIY Policy Cards](../Standards/ISO27x/legacy/About%20ISO27DIY%20Policy%20Cards.md)  
+Related: [About ISO27DIY Policy Cards](../Standards/ISO27x/legacy/iso27DIY%20mk%20I/About%20ISO27DIY%20Policy%20Cards.md)  
 
 
 ## Activities and Artifacts

Corpus/Standards/ISO27x/Risk Treatment Plan.md

@@ -0,0 +1,97 @@
+# Risk Treatment Plan
+
+Find faults or omissions in my reasoning.
+
+The Canonical Form of a policy is: 
+>To mitigate the risk of R, control C will be implemented on asset A under the responsibility of asset owner AO. The effectiveness will be measured through method M and will be evaluated by risk owner RO, against established risk criteria RC. 
+
+**A Corrected Canonical Form (for a Risk Treatment Plan):**
+> "To treat risk R (evaluated against Risk Criteria RC), Control C will be implemented by assigned Actor [Control Implementer], to protect Asset A (owned by Asset Owner AO). The effectiveness of Control C will be measured by Actor [Evaluator] using Method M against established Objectives/Performance Criteria, producing Artifact [Evidence]. Finally, Risk Owner RO will review the evidence to approve the treatment plan and accept the residual risk."
+
+### Faults in your reasoning
+
+**1. Misclassification as a "Policy"** Your canonical form reads as a highly specific operational directive, which belongs in a **Risk Treatment Plan** or a **Statement of Applicability (SoA)**, not a policy.
+
+- **Policies** formally express the high-level intentions and direction of top management (e.g., "We will manage access to our servers"). They are general or high-level.
+- **Procedures** detail the _how_.
+- The **Risk Treatment Plan** is the formal document where the organization specifies how it will treat identified risks by linking them to necessary controls, while the **SoA** justifies their inclusion.
+
+**2. "Mitigate" vs. "Modify or Maintain"** You state the control is implemented "to _mitigate_ the risk". While mitigation is a common treatment option, ISO 27002 explicitly defines a **control** as a measure that **modifies or maintains risk**. Some controls (like an overarching policy) only _maintain_ risk at a known level, while compliance with that policy _modifies_ it. Mitigation is just one outcome; controls can also support risk avoidance or risk sharing.
+
+**3. Responsibility: Asset Owner vs. Control Owner/Implementer** You assert the control is implemented "under the responsibility of asset owner AO". This conflates asset ownership with control implementation.
+
+- The **Asset Owner** is responsible for the proper management of the asset over its whole life cycle, ensuring it is classified and that access restrictions correspond with that classification.
+- However, the responsibility for implementing specific **controls** (e.g., running backups, configuring firewalls) is allocated to various roles according to organizational needs. As illustrated in the TypeDB schema, an `actor` (like a specific IT manager or department) can play the `responsible-for` role for a control, independently of who owns the asset.
+
+**4. The Role of the Risk Owner in Evaluation** You state the effectiveness will be evaluated by the **Risk Owner (RO)**. This is a subtle fault in the division of duties.
+
+- Under ISO 27001, the organization must determine _who_ shall monitor and measure, and _who_ shall evaluate the results. This is often a security officer, an auditor, or an independent reviewer (as per control 5.35).
+- The explicit responsibility of the **Risk Owner** in the standard is to **approve the information security risk treatment plan and accept the residual information security risks**. They consume the evaluation data to make acceptance decisions, but they do not necessarily execute the evaluation of the measurement method.
+
+**5. Evaluating Effectiveness against "Risk Criteria"** You state effectiveness is evaluated against "established risk criteria RC". This mixes two different clauses of the standard.
+
+- **Risk criteria** (which include risk acceptance criteria) are established to evaluate and prioritize _risks_ during the risk assessment phase.
+- The **effectiveness of controls** and the ISMS itself is evaluated through monitoring and measurement methods to ensure the controls achieve their **information security objectives** and intended outcomes.
+- 
+### Omissions in your reasoning
+
+**1. Artifacts and Evidence** To prove that a control has been implemented and measured effectively, the standard requires documented information as evidence. According to the TypeDB schema, an **artifact** (like a record or log) must be captured and linked via a `serves-as-evidence-for` relationship to the control or process. Your form omits the requirement to generate and maintain evidence.
+
+**2. Traceability to Clauses and Requirements** Your form connects a control directly to a risk, which is correct. However, ISO 27001 and the TypeDB schema also mandate that controls address specific **Requirements** defined within the standard's **Clauses**. An organization implements controls not _just_ to treat a risk, but also to satisfy mandatory compliance, legal, or standard requirements (e.g., ISO 27001 Annex A).
+
+### A Corrected Canonical Form (for a Risk Treatment Plan)
+
+If adapted to accurately reflect the framework's data model and terminology, the canonical form for a **Risk Treatment entry** would be:
+
+**"To treat risk R (evaluated against Risk Criteria RC), Control C will be implemented by assigned Actor [Control Implementer], to protect Asset A (owned by Asset Owner AO), fulfilling Requirement Req. The effectiveness of Control C will be measured by Actor [Evaluator] using Method M against established Objectives/Performance Criteria, producing Artifact [Evidence]. Finally, Risk Owner RO will review the evidence to approve the treatment plan and accept the residual risk."**
+
+
+
+
+
+
+## Elements
+
+To establish the compliance of the implementation of a specific control to the ISO 27001 standard, the auditor will look for the following:
+- the risk that the control is supposed to mitigate
+- the risk owner
+- the scope of the control, in terms of organizational scope (certain business activities, organizational units) and asset(s) protected
+- the control owner
+- a description of the 'how' or the activities involved in the implementation, including roles and responsibilities
+- how the effectiveness of the control will be established, when, and by whom
+- how the effectiveness of the control will be evaluated, when, and by whom
+- possible exemptions to the policy
+- how exceptions will be handled
+- where all this is documented (policies, logs etc., evaluation)
+- for this documentation: Version information and who has authoured and signed off on the policy, Revision dates (+ next evaluation) 
+- what the change procedure is for a relevant policy
+
+
+
+**"Formally":**
+- A policy formally expresses the intentions and direction of management. Rather than detailing exactly _how_ a task should be executed, the overarching information security policy is supported by "topic-specific policies" **as needed** to mandate the implementation of controls for specific target groups or security areas (such as access control, physical security, or secure development).
+- **The Role of a Procedure (The "How"):** The specific steps on _how_ to carry out an activity or process are defined in a **procedure**. For example, Control 5.37 requires organizations to maintain "documented operating procedures" that provide personnel with the detailed, step-by-step instructions needed to ensure the correct and secure operation of information processing facilities
+- It is also important to note that a control is broadly defined as **any measure that modifies or maintains risk**. Therefore, a control itself can take the form of a policy, a procedure, a process, or a technical hardware/software function
+
+
+Version Control
+
+| Type            | Value |
+| --------------- | ----- |
+| Version number: | x.xx  |
+| Version date:   | x.xx  |
+| Document owner: | name  |
+| Approved by:    | name  |
+| Approved on:    | date  |
+| Next review:    | date  |
+
+The Document Owner is responsible for development and implementation of the policy.
+
+- [ ] Check Standard on documentation and ownership
+
+
+## Approved
+Name: | name
+--- | ---
+Signature: | signature
+Date: | date

Corpus/Standards/ISO27x/legacy/iso27DIY mk I/About ISO27DIY Policy Cards.md

@@ -1,8 +1,8 @@
 # About ISO27DIY Policy Cards
 
-Policies are part of the collection of [Advised Documents for ISO 27001](../../../../../iso27DIY-gis/reference/Advised%20Documents%20for%20ISO%2027001.md).
+Policies are part of the collection of [Advised Documents for ISO 27001](../../../../../../iso27DIY-gis/reference/Advised%20Documents%20for%20ISO%2027001.md).
 
-These could have the shape of 'Policy Cards', produced at the end of each session of the [📼 ISO27DIY Video Series](iso27DIY%20mk%20I/📼%20ISO27DIY%20Video%20Series.md).
+These could have the shape of 'Policy Cards', produced at the end of each session of the [📼 ISO27DIY Video Series](📼%20ISO27DIY%20Video%20Series.md).
 
 Because the policies produced at the end of a session need to be expanded and adapted to the organization, there will be a corresponding action in the ISMS planning.
 
@@ -15,18 +15,18 @@ After the Risk and Assets phase – more specifically, after the asset categorie
 
 Policy Cards are generated from risks identified and controls defined. They are not editable. They *can* be exported to an (editable) document. 
 
-A Policy Card has a fixed format, see [ISO27DIY Policy Card template](iso27DIY%20mk%20I/📒%20Templates/ISO27DIY%20Policy%20Card%20template.md). 
+A Policy Card has a fixed format, see [ISO27DIY Policy Card template](📒%20Templates/ISO27DIY%20Policy%20Card%20template.md). 
 
 ISO 27002:2013 offers the following guidance for A 5.1.1 Policies for information security: “These policies should be communicated to employees and relevant external parties in a form that is relevant, accessible and understandable to the intended reader, e.g. in the context of an ‘information security awareness, education and training programme’ ”.
 
 Related ISO clauses and controls:
-- [ISO 27001 A 5.1.1 Policies for information security](ISO%2027001%202013/ISO%2027001%20A%205.1.1%20Policies%20for%20information%20security.md)
-- [ISO_27001_OT C 5.2 Policy](ISO%2027001%202013/ISO_27001_OT%20C%205.2%20Policy.md)
+- [ISO 27001 A 5.1.1 Policies for information security](../ISO%2027001%202013/ISO%2027001%20A%205.1.1%20Policies%20for%20information%20security.md)
+- [ISO_27001_OT C 5.2 Policy](../ISO%2027001%202013/ISO_27001_OT%20C%205.2%20Policy.md)
 
 
 Related ideas:
-- [ISO27DIY Recipe for Policy Cards](iso27DIY%20mk%20I/ISO27DIY%20Recipe%20for%20Policy%20Cards.md)
-- [BC5701_Training_Tab_03_MS](../../BC%205701/BC5701_Training_Tab_03_MS.md#Beleid)
-- [Modules, Screens and Content](../../../Drafts%20and%20Ideas/Modules,%20Screens%20and%20Content.md)
-- [🧰 Resource portal](iso27DIY%20mk%20I/🧰%20Resource%20portal.md)
-- [Topical InfoSec Kanban’s](../../../Literature%20notes/Topical%20InfoSec%20Kanban’s.md)
+- [ISO27DIY Recipe for Policy Cards](ISO27DIY%20Recipe%20for%20Policy%20Cards.md)
+- [BC5701_Training_Tab_03_MS](../../../BC%205701/BC5701_Training_Tab_03_MS.md#Beleid)
+- [Modules, Screens and Content](../../../../Drafts%20and%20Ideas/Modules,%20Screens%20and%20Content.md)
+- [🧰 Resource portal](🧰%20Resource%20portal.md)
+- [Topical InfoSec Kanban’s](../../../../Literature%20notes/Topical%20InfoSec%20Kanban’s.md)

Corpus/Standards/ISO27x/legacy/iso27DIY mk I/ISO27DIY Implementation method.md

@@ -71,7 +71,7 @@ Take into consideration that there are specific requirements for 'documented inf
 
 
 ## Tooling provisions
-- [About ISO27DIY Policy Cards](../About%20ISO27DIY%20Policy%20Cards.md)
+- [About ISO27DIY Policy Cards](About%20ISO27DIY%20Policy%20Cards.md)
 - [ISO27DIY Kanban board](ISO27DIY%20Kanban%20board.md)
 
 ## Related

Corpus/Standards/ISO27x/legacy/iso27DIY mk I/Working back from the Annex A dashboard.md

@@ -1,5 +1,5 @@
 Start with the [](../../../../Attachments/ISO%2027001%20Implementatie%20dashboard%20Annex%20A.xlsx) as a framework.
 Every cell gets one or more corresponding [ISO27DIY Kanban board](ISO27DIY%20Kanban%20board.md) items. So they are all linked to at least one of the ISO 27001 controls or ISO 27001 clauses.
 
-Note that in this approach all [About ISO27DIY Policy Cards](../About%20ISO27DIY%20Policy%20Cards.md), [Advised Documents for ISO 27001](../../../../../../iso27DIY-gis/reference/Advised%20Documents%20for%20ISO%2027001.md), and identified risks and controls will appear on the Kanban board, directly or indirectly.
+Note that in this approach all [About ISO27DIY Policy Cards](About%20ISO27DIY%20Policy%20Cards.md), [Advised Documents for ISO 27001](../../../../../../iso27DIY-gis/reference/Advised%20Documents%20for%20ISO%2027001.md), and identified risks and controls will appear on the Kanban board, directly or indirectly.
 

Corpus/_Corpus-metadata.md

@@ -1,21 +1,87 @@
 # Corpus Metadata
 
-- All notes in this Obsidian vault need metadata.
-- These metadata need to follow the [Obsidian Front Matter Syntax](../../Content%20Factory/Obsidian%20Front%20Matter%20Syntax.md). 
-- Every note will get a field ’notetype’ in its front matter – see below for possible values.
+- All notes in this Obsidian vault need metadata. 
+- These metadata need to follow the [Obsidian Front Matter Syntax](Obsidian%20Front%20Matter%20Syntax.md). 
+- Obsidian calls metadata key-value pairs 'Properties'
+- In this Corpus we use General properties (every note should have them) and Specific properties (depending on the kind of note, can be inferred from other properties)
 
-## Notetypes for Obsidian Corpus
+## General metadata
 
-Every note will get a field ’notetype’ in its front matter.
+### Notetype
 
-The field will have one of the following values:
-- guide: guided, hands-on lessons, learning by doing, interactive lessons
-- explanation: background and context to the standards, paraphrases of the original standard texts, opinion, discussion, underlying principles, interpretation
-- application: steps to solve a specific, real-world problem. Implementing the standard in real world environments, implementation aids, implementation examples, templates, etc.
-- reference: for original standard texts, dictionaries, terms and definitions.
-- other: for all notes that, by there content, cannot be placed in one for the previous categories.
+The `notetype` field will have one of the following values:
+- `guide`: guided, hands-on lessons, learning by doing, interactive lessons
+- `explanation`: background and context to the standards, paraphrases of the original standard texts, opinion, discussion, underlying principles, interpretation
+- `application`: steps to solve a specific, real-world problem. Implementing the standard in real world environments, implementation aids, implementation examples, templates, etc.
+- `reference`: for original standard texts, dictionaries, terms and definitions.
+- `other`: for all notes that, by there content, cannot be placed in one for the previous categories.
 
 Note:
-- The original standard texts in the OST folder and subfolders are also tagged with “sourcetext”. The body of these notes must never be changed!
-- Notes in the iso27DIY-gis/guide folder and subfolders are typically of the guide type.
-- Notes in iso27DIY-gis/reference and subfolders are typically of the explanation or application type.
+- Notes in the iso27DIY-gis/guide folder and subfolders are typically of the `guide` type.
+- Notes in iso27DIY-gis/reference and subfolders are typically of the `explanation` or `application` type.
+
+### Language
+For the language property we use the language code as defined in ISO 639-1.
+
+
+## Metadata for ISO 27001 and 27002 Original Standard Texts
+- The original texts of the ISO 27001 and ISO 27002 standards can be found in the OST folder and subfolders. 
+- These notes are tagged with “sourcetext”. 
+- The body of these notes must never be changed!
+- Specific properties for ISO 27002 OST notes are deduced from chapter 4 of the standard ("Themes and Attributes"). They are: `theme`, `control_type`, `information_security_properties`, `cybersecurity_concepts`, `operational_capabilities`, and `security_domains`. 
+- For the possible values of these properties, see [ISO 27002 Themes and Attributes](ISO%2027002%20Themes%20and%20Attributes.md).
+
+
+## Phases for ISMS implementation
+
+
+
+# Enrichment Prompt Examples
+
+## Adding front matter to original ISO clauses and controls
+
+- We are going to add front matter to the files in folder iso27diy-corp/Corpus/Standards/ISO27x/OST/27002/EN.
+- To do this, you will need access to this folder and its contents. Check that you have access, and if not, stop the process immediately and get into contact with the user to fix the problem.
+- You also need to be able to read the [Original Standard Text](../iso27diy-corp/Corpus/Standards/ISO27x/OST/27002/EN/ISO%2027002_2022_EN.docx). If you cannot access or read this document, stop the process immediately and get into contact with the user to fix the problem.
+- See [_Corpus-metadata](../iso27diy-corp/Corpus/_Corpus-metadata.md) for instructions on adding metadata.
+- Each note in this folder (with a few exceptions) represents an ISO 27002 Control.
+- Additionally to what is described in the Corpus Metadata note, each control will get metadata fields according to [ISO 27002 Themes and Attributes](ISO%2027002%20Themes%20and%20Attributes.md) - note can be found in the Content Factory folder.
+
+Additionally, you will add the following metadata key-value pairs:
+```YAML
+notetype: sourcetext
+standard: ISO 27002
+version: 2022
+language: EN
+type: control
+id: A.<x.yy>
+title: <control title>
+```
+
+- The `<x.yy>` part of the `id` and the `<control title>` can often be found in the content of the markdown note as a level 2 header.  
+- THIS IS MOST IMPORTANT: Do not make up or infer any of these themes, attributes and values. If you cannot extract them from the note itself, refer to the Original Standard Text.
+- When you cannot extract the information from the note itself, or from the Original Standard Text, mark the note with the tag REVIEW.
+
+## Adding more front matter
+We are now going to work on files in iso27diy-corp/Corpus/Standards/ISO27x/OST/27001/NL/
+
+Write a simple program or script to add properly formatted YAML front matter (for Obsidian) to the markdown files in the iso27diy-corp/Corpus/Standards/ISO27x/OST/27001/NL/ directory. 
+
+Here is an example for c-6.3-Planning-van-wijzigingen.md:
+```
+notetype: reference
+standard: ISO 27001
+version: 2023
+language: NL
+type: clause
+id: "C.6.3"
+title: "Planning van wijzigingen"
+tags:
+- iso27001/2023/EN
+- sourcetext
+status: active
+```
+
+`id` and `title` are specific to the file, the other kv-pairs are the same for all files.
+
+Do a test run to see if your program has the intended effect. Check back with the user if you encounter exceptions.