Cleaned up Literature folder

Corpus/ISMS/AI Threat Modeling.md

@@ -0,0 +1,7 @@
+# Using AI for Threat Modeling
+
+[Create a threat analysis chatbot](../Various/Create%20a%20threat%20analysis%20chatbot.md)
+
+
+[PLOT4AI](https://plot4.ai) (Privacy Library Of Threats 4 Artificial Intelligence): A threat modeling library to help you build responsible AI
+by [Isabel Barbéra](https://www.linkedin.com/in/isabelbarbera/)

Corpus/ISMS/About dealing with threats.md

@@ -0,0 +1,48 @@
+# About the connection between threat intelligence, analysis and modeling
+
+### 🔄 Interplay Overview
+
+|Concept|Role in Cybersecurity|How It Connects to the Others|
+|---|---|---|
+|**Threat Intelligence**|Collects and delivers data on threats|Feeds raw data into analysis and modelling|
+|**Threat Analysis**|Interprets and assesses threat data|Uses intelligence to evaluate risks and impact|
+|**Threat Modelling**|Maps out potential attack paths and scenarios|Uses analysis to simulate and prioritize threats|
+
+---
+
+### 🧠 Threat Intelligence → 🔍 Threat Analysis
+
+- Threat intelligence provides **real-time data** on threat actors, malware, vulnerabilities, and attack trends.
+- Analysts use this data to **identify patterns**, **assess relevance**, and **prioritize risks** based on the organization's context.
+
+### 🔍 Threat Analysis → 🧩 Threat Modelling
+
+- Analysis helps determine **which threats are most likely and impactful**.
+- This guides threat modelling to focus on **realistic attack scenarios**, not just theoretical ones.
+
+### 🧩 Threat Modelling → 🧠 Threat Intelligence
+
+- Threat modelling reveals **gaps in visibility** or **missing threat data**.
+- These insights can refine intelligence collection efforts, ensuring more targeted and useful data.
+
+---
+
+### 🛡️ Real-World Example
+
+Imagine a financial institution:
+
+1. **Threat Intelligence** detects a surge in phishing campaigns targeting banking apps.
+2. **Threat Analysis** reveals that attackers are exploiting MFA fatigue and targeting mobile users.
+3. **Threat Modelling** simulates how these attacks could bypass defenses and identifies weak points in mobile app authentication.
+
+This leads to:
+
+- Updating detection rules.
+- Strengthening MFA protocols.
+- Training users on phishing awareness.
+
+---
+
+Together, these disciplines create a **feedback loop** that strengthens an organization's ability to **predict, prevent, and respond** to cyber threats.
+
+Would you like a visual diagram or a case study to illustrate this further?

Corpus/ISMS/About implementation and proof.md

@@ -0,0 +1,5 @@
+# About implementation and proof
+
+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.
+
+

Corpus/ISMS/About policies controls and risks.md

@@ -0,0 +1,56 @@
+# About policies, controls, and risks
+
+`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.​​​​​​​​​​​​​​​​

Corpus/ISMS/About the Statement of Applicability.md

@@ -0,0 +1,12 @@
+# 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. 

Corpus/ISMS/Access Control Models.md

@@ -0,0 +1,130 @@
+See also:
+- [Authorization vs Access Control](Authorization%20vs%20Access%20Control.md)
+- [Identity and Access Management (IAM)](../Information%20Security/Identity%20and%20Access%20Management%20(IAM).md)
+- [RBAC Access levels](RBAC%20Access%20levels.md)
+- [CRUD Matrices](../Information%20Security/CRUD%20Matrices.md)
+
+
+Source: [](../Information%20Security/Certified%20Ethical%20Hacker%20Exam%20Guide%202021.pdf)
+
+- Mandatory Access Control (MAC):
+	- Every object gets a label
+		- Confidential, secret, top secret, etc
+	- The administrator decides who gets access to what security level; 
+	- Users cannot change these settings
+	- Used on old systems (e.g. Top Secret Gov. information)
+
+- Discretionary Access Control (DAC):
+	- Used in most OS
+	- Owner of the data defines access
+	- Very flexible access control; Very weak security
+
+- Role-based Access Control (RBAC):
+	- Access to resources is defines by a set of rules defined by a role in your organization/job function (Manager, Director etc)
+		- e.g., "Administrators can read, write, and delete all files," "Employees can only read certain files."
+	- Administrators provide access based on the role of the user
+		- Rights are gained implicitly instead of explicitly
+	- In Windows, use Groups to provide role-based access control
+		- e.g. Admin Groups --> Rights and Perms,
+		- Sales Group --> Rights and Perms
+
+Also found, with Gemini, 2 juni 2025:
+- Attribute-Based Access Control (ABAC):
+	- e.g., "Only users from the 'Finance' department located in 'Head Office' can access this financial report."
+- Relationship-Based Access Control (ReBAC)
+	- e.g., "Friends can view my photos."
+
+
+## Mandatory vs. Discretionary access control
+Source: Wikipedia, dec. 2024
+
+In mandatory access control (MAC), the security policy is centrally controlled by a policy administrator and is guaranteed (in principle) to be enforced for all users. Users cannot override the policy and, for example, grant access to files that would otherwise be restricted. 
+
+By contrast, discretionary access control (DAC) allows users the ability to make policy decisions or assign security attributes. The controls are discretionary in the sense that a subject with a certain access permission is capable of passing that permission (perhaps indirectly) on to any other subject (unless restrained by mandatory access control).
+
+Systems can implement both MAC and DAC simultaneously, where DAC refers to one category of access controls that subjects can transfer among each other, and MAC refers to a second category of access controls that imposes constraints upon the first.
+
+Occasionally, a system as a whole is said to have "discretionary" or "purely discretionary" access control when that system lacks mandatory access control.
+
+## Different access control models 
+
+Access control models govern how users are granted access to resources in a system. This document compares **RBAC (Role-Based Access Control)**, **ABAC (Attribute-Based Access Control)**, **NGAC (Next-Generation Access Control)**, and **PBAC (Policy-Based Access Control)**, outlining their differences, advantages, and disadvantages.
+
+### RBAC (Role-Based Access Control)
+
+- **Definition**: Access is granted based on roles assigned to users. A role represents a set of permissions, and users inherit permissions from their assigned roles. RBAC is policy-neutral in the sense that it can be used to implement MAC or DAC.
+- **Key Components**: Users, roles, and permissions.
+
+**Pros:**
+- Simple and intuitive to implement for organizations with clear hierarchical structures.
+- Reduces administrative overhead when managing permissions.
+- Well-suited for stable environments with predictable access needs.
+
+**Cons:**
+- Lacks flexibility; difficult to handle exceptions or dynamic contexts (e.g., time-based restrictions).
+- Role explosion: Managing a large number of roles becomes cumbersome as the system scales.
+- Not context-aware.
+
+### ABAC (Attribute-Based Access Control)
+
+- **Definition**: Access is granted based on attributes of users, resources, actions, and the environment. Attributes can include user roles, resource sensitivity, location, time, and more.
+- **Key Components**: Policies, attributes, and conditions.
+
+**Pros:**
+- Highly flexible and fine-grained access control.
+- Supports dynamic, context-aware decisions (e.g., granting access only during work hours or from specific locations).
+- Eliminates role explosion.
+
+**Cons:
+- Complex to implement and manage due to the need for a robust attribute infrastructure.
+- Policy authoring can be error-prone and challenging for administrators.
+- Requires real-time evaluation, which may impact performance.
+
+### NGAC (Next-Generation Access Control)
+
+- **Definition**: A standards-based approach that integrates various access control concepts, combining RBAC, ABAC, and policy-based models. It uses a graph-based structure to represent relationships between users, attributes, and policies.
+- **Key Components**: Graphs (users, attributes, and policies) and decision engines.
+
+**Pros:**
+- Flexible and adaptable to different access control needs.
+- Unified framework for managing diverse access control models.
+- Highly efficient for environments requiring a mix of models.
+
+ **Cons:
+- Complexity in setup and management.
+- Limited adoption and tooling support compared to RBAC or ABAC.
+  
+### PBAC (Policy-Based Access Control)
+
+- **Definition**: Access is managed through explicitly defined policies that dictate who can access what under which conditions. Often overlaps with ABAC.
+- **Key Components**: Policies, rules, and conditions.
+
+**Pros:**
+- Fine-grained control with a focus on clear, centralized policy definition.
+- Scalable for distributed systems or multi-tenant architectures.
+- Strongly aligned with regulatory compliance requirements.
+
+ **Cons:
+- Similar to ABAC, policy complexity can grow quickly.
+- Administrators require expertise to define and maintain accurate policies.
+- Performance overhead due to policy evaluation.
+
+## Summary Comparison
+
+| Feature / Model            | RBAC                      | ABAC            | NGAC        | PBAC           |
+| -------------------------- | ------------------------- | --------------- | ----------- | -------------- |
+| **Flexibility**            | Low                       | High            | High        |  High          |
+| **Complexity**             | Low                       | High            | Moderate    |  Moderate      |
+| **Context-Awareness**      | No                        | Yes             | Yes         |  Yes           |
+| **Scalability**            | Limited (role explosion)  | High            | High        |  High          |
+| **Ease of Implementation** | Easy                      | Difficult       | Moderate    |  Moderate      |
+| **Adoption**               | Widespread                | Increasing      | Emerging    |  Increasing    |
+
+## Choosing the Right Model
+
+- Use **RBAC** for environments with stable, well-defined roles and minimal need for contextual decisions.
+- Use **ABAC** or **PBAC** for systems requiring dynamic, context-aware, and fine-grained access control.
+- Consider **NGAC** if a unified, standards-based approach is necessary and you need to integrate multiple models.
+
+The decision depends on your organization's complexity, security needs, and resource availability.
+

Corpus/ISMS/Access Control in ISO 27001.md

@@ -0,0 +1,49 @@
+# Relevant articles for Access Control
+
+The prevention of unauthorized access to classified data is fundamentally supported by a comprehensive set of controls across organizational, physical, and technological domains, particularly those focusing on **Confidentiality** (one of the core Information Security Properties).
+
+The relevant clauses and controls, primarily derived from ISO/IEC 27002:2022 (referenced in Annex A of ISO/IEC 27001:2022), are detailed below:
+
+### 1. Controls Focused on Data Identification, Classification, and Handling
+
+To prevent unauthorized access to classified data, the data itself must first be identified and properly protected according to its sensitivity:
+
+- **5.12 Classification of information:** Information should be **classified according to the organization's information security needs based on confidentiality**, integrity, availability, and relevant interested party requirements. This helps ensure the identification and understanding of the protection needs of information.
+- **5.13 Labelling of information:** An appropriate set of procedures for **information labelling** should be developed and implemented in accordance with the adopted classification scheme. Labelling communicates the classification and supports automation of protection controls.
+- **5.10 Acceptable use of information and other associated assets:** Rules for the acceptable use and procedures for handling information and other associated assets should be identified, documented, and implemented. This involves **access restrictions supporting the protection requirements for each level of classification**.
+- **5.33 Protection of records:** Records must be protected from unauthorized access.
+- **5.34 Privacy and protection of PII:** The organization should identify and meet requirements regarding the **preservation of privacy and protection of Personally Identifiable Information (PII)** according to applicable laws, regulations, and contractual requirements, since PII is often considered sensitive or classified.
+- **7.7 Clear desk and clear screen:** **Clear desk rules** for papers and removable storage media and clear screen rules for information processing facilities should be defined and enforced to reduce the risk of unauthorized access or loss of information outside of normal working hours.
+
+### 2. Controls Related to Identity, Access Management, and Privileges
+
+These controls directly manage who (or what) is authorized to access resources and classified data:
+
+- **5.15 Access control:** **Rules to control physical and logical access** to information and other associated assets should be established and implemented based on business and information security requirements. Access rules should adhere to principles like "need-to-know".
+- **8.3 Information access restriction:** **Access to information and other associated assets should be restricted** in accordance with the established topic-specific policy on access control. Public or anonymous access should generally not be granted to storage locations containing sensitive information.
+- **8.2 Privileged access rights:** The allocation and use of **privileged access rights should be restricted and managed**. Inappropriate use of system administrator privileges is a major factor contributing to system failures or breaches.
+- **5.16 Identity management:** The **full life cycle of identities should be managed** to ensure unique identification of individuals and systems and enable appropriate assignment of access rights.
+- **5.17 Authentication information:** The allocation and management of authentication information (e.g., passwords, tokens) must be controlled by a management process, including advising personnel on appropriate handling, to ensure **proper entity authentication**.
+- **8.5 Secure authentication:** **Secure authentication technologies and procedures** (like multi-factor authentication) should be implemented based on information access restrictions and the access control policy.
+- **5.18 Access rights:** Access rights should be provisioned, reviewed, modified, and removed in accordance with the access control policy. This process ensures access is defined and authorized according to business needs.
+- **8.18 Use of privileged utility programs:** The use of utility programs capable of overriding system and application controls must be restricted and tightly controlled to ensure they do not harm information security.
+- **8.4 Access to source code:** Read and write access to source code, development tools, and software libraries should be appropriately managed to **maintain the confidentiality of valuable intellectual property**.
+
+### 3. Technological Controls for Data Protection and Leakage Prevention
+
+These technical measures actively protect classified data from disclosure:
+
+- **8.12 Data leakage prevention:** Measures should be applied to systems, networks, and devices that process, store, or transmit sensitive information **to detect and prevent unauthorized disclosure and extraction of information**.
+- **8.11 Data masking:** Data masking techniques (like pseudonymization or anonymization) should be used in accordance with access control policies and legal requirements **to limit the exposure of sensitive data**.
+- **8.24 Use of cryptography:** Rules for the effective use of cryptography, including key management, should be defined and implemented to protect the **confidentiality** and integrity of information.
+- **8.1 User endpoint devices:** Information stored on, processed by, or accessible via user endpoint devices must be protected against associated risks. This includes requirements for physical protection, storage device encryption, and logical access controls.
+- **6.7 Remote working:** Security measures must be implemented when personnel are working remotely to **protect information accessed, processed, or stored outside the organization’s premises**.
+
+### 4. Segregation and Operational Controls
+
+These controls prevent classified data from being compromised via unauthorized operational pathways or environments:
+
+- **8.31 Separation of development, test and production environments:** Development, testing, and production environments should be **separated and secured** to **protect the production environment and data from compromise**. This prevents the compromise of live production data by activities in development or testing.
+- **8.33 Test information:** Test information must be appropriately selected, protected, and managed. This typically involves using **access controls comparable to production** and avoiding the direct copying of sensitive production data into test environments unless masking is used.
+- **5.3 Segregation of duties:** Conflicting duties and responsibilities should be segregated to reduce the risk of bypassing information security controls.
+- **8.22 Segregation of networks:** Groups of services, users, and systems should be segregated in the organization’s networks to split the network into security boundaries and control traffic between them.

Corpus/ISMS/Access Control.md

@@ -0,0 +1,13 @@
+# Access Control
+
+While [authorization](../Standards/ISO27x/Authorization.md) is primarily concerned with establishing the policies and rules that dictate access (i.e. *what* a person or system is allowed to do), **access control** is the _system_ or _process_ that enforces those defined permissions.
+
+See:
+- [Gedachten over rechtenstructuren](../Information%20Security/Gedachten%20over%20rechtenstructuren.md)
+- [Authorization vs Access Control](Authorization%20vs%20Access%20Control.md)
+- [Access Control Models](Access%20Control%20Models.md)
+- [ISO 27001 A 9 Access control](../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001%20A%209%20Access%20control.md)
+- [a-5.15-Access-control](../Standards/ISO27x/OST/27002/EN/a-5.15-Access-control.md)
+
+
+

Corpus/ISMS/Asset Types in NIST.md

@@ -0,0 +1,33 @@
+# Asset Types in NIST
+
+Asked ChatGPT on  3 april 2024 
+
+The National Institute of Standards and Technology (NIST) defines several categories or types of assets under its guidelines for managing and protecting information systems. They include:
+
+Information: This includes all types of data or information, regardless of its format (electronic, print, etc.).
+
+Systems: This includes high-level applications, databases, networks, or systems that store, process, or transmit information.
+
+Devices and Media: This includes electronic devices, mobile devices, and storage media.
+
+Communications Networks: This includes wide area networks, local area networks, wireless networks, and virtual private networks.
+
+Software: This includes operating systems, applications, and firmware.
+
+Human Resources: This includes the information system's users and their user-level access to the system and data, including third-party users and customers.
+
+Physical plant: This includes physical or environmental protection like buildings, rooms, and facilities.
+
+Organizational assets: This includes reputation and value, intellectual property, organizational structure, supply chain information, and other resources related to organization mission and business functions.
+
+Services: This includes all types of services provided by the systems, like cloud services, security services, etc.
+
+Information security resources: This includes policies, procedures, standards, guidelines, security plans, user agreements, security awareness and training materials, security audit logs, and access reports.
+
+Please note that identified assets should be recorded in the organization's risk management and security assessment plan.
+
+**In which NIST document are these categories defined?**
+
+The categories or types of assets as defined by the National Institute of Standards and Technology (NIST) can be found in the NIST Special Publication 800-53, Revision 5, titled "Security and Privacy Controls for Information Systems and Organizations." 
+
+Additionally, NIST Special Publication 800-30, titled "Guide for Conducting Risk Assessments," provides guidelines for conducting risk assessments which encompasses identifying, categorizing, and prioritizing assets.

Corpus/ISMS/Asset lifecycle.md

@@ -0,0 +1,19 @@
+# Asset lifecycle
+
+## Asset mgt implementation
+Source: Defensive Security Handbook: Best Practices for Securing Infrastructure by Lee Brotherston, Amanda Berlin
+
+Each department or person involved in each step should understand when and how assets are tracked at every point of their lifecycles.
+
+* Procure
+* Deploy
+* Manage, e.g. moved to storage, upgraded, replaced, returned, or change of users, locations, or departments.
+* Decommission
+
+Track changes, monitor and report
+
+
+![](../Various/Business%20processes/secure_data_lifecycle.jpeg)
+
+
+

Corpus/ISMS/Assets Ownership and Risk Overview.md

@@ -0,0 +1,104 @@
+# Assets, Ownership, and Risk: Structured Overview
+
+## 1. Core Concept: What Is an Asset?
+
+An **information asset** is anything that has value to an organization. It can take many forms:
+
+- Printed or electronic documents
+- Intellectual property and proprietary knowledge
+- Personal data
+- Knowledge of processes
+- Physical items
+- Information systems that process, store, or transmit information
+
+**Selected definitions:**
+
+| Source                                                            | Definition                                                                                                                                                                                                                                                           |
+| ----------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| ISO/IEC 27000:2018                                                | Anything that has value to an organization (e.g. printed documents, electronic documents, intellectual property, personal data, knowledge of processes, physical items).                                                                                             |
+| NIST SP 800-53                                                    | Information and the information systems that process, store, and transmit that information.                                                                                                                                                                          |
+| DAMA-DMBOK                                                        | A resource of value that an organization uses to understand, operate, and innovate.                                                                                                                                                                                  |
+| Gartner IT Glossary                                               | A collection of information that is defined and managed as a standalone entity and is considered of value.                                                                                                                                                           |
+| (ISC)² CISSP Official Study Guide (Chapple, Stewart et al., p.64) | Anything within an environment that should be protected — anything used in a business process or task. If an organization places any value on an item and deems it important enough to protect, it is labeled an asset for purposes of risk management and analysis. |
+
+**Examples of assets (CISSP):** computer files, network services, system resources, processes, programs, products, IT infrastructure, databases, hardware devices, furniture, product recipes/formulas, intellectual property, personnel, software, facilities.
+
+**Consequences of asset loss or disclosure:**
+- Overall security compromise
+- Loss of productivity
+- Reduction in profits
+- Additional expenditures
+- Discontinuation of the organization
+- Numerous intangible consequences
+
+
+## 2. Assets in Relation to Vulnerabilities, Threats, and Risks
+
+The relationship between the four concepts can be summarized as:
+
+> A threat exploits an exposed vulnerability to damage an asset, which results in a risk to the organization.
+
+This relationship is known as the **Operations Security Triple** (assets, vulnerabilities, threats).
+
+**On risk materialization:**
+A risk can be seen as a theoretical threat scenario. When a risk "materializes," an anticipated or potential threat has actually taken place — exploiting a vulnerability, affecting an asset, and resulting in actual harm or loss.
+
+
+## 3. Asset Ownership
+
+### ISO 27001 Requirements
+
+ISO 27001 explicitly requires asset ownership in two controls:
+
+- **A.8.1.2** — Every asset should have an owner.
+- **A.9.2.5** — Asset owners must periodically evaluate access rights.
+
+### Determining Ownership: The RUMC Model
+
+*The following model was shared by Remco Landegge, Security Expert Radboud UMC (2 December 2024). Remove all references to Radboudumc before reusing.*
+
+When asset or process ownership is unclear, it can be determined by mapping the situation to one of four scenarios:
+
+
+![](rumc-eigenaarschap.png)
+
+
+
+**Situation 1 (B1): Asset/process used within a single organizational unit**
+
+The head or director of that organizational unit is the owner **(E1)**.
+
+*Note: for institutes, this applies only to assets/processes needed within their own unit — not to those required for the complete core task.*
+
+
+**Situation 2 (B2): Asset/process used across multiple departments, or a department and a centre**
+
+The director of the core task in which the asset/process is used is the owner **(E2)**. The owner operates independently and in a facilitating role, to ensure all stakeholders (across departments and/or centres) are involved in decisions about functionality, security, and service levels.
+
+
+**Situation 3 (B3): Asset/process used across multiple institutes**
+
+The directors of the institutes involved jointly determine who the owner is **(E3)**. The owner operates independently and in a facilitating role to ensure stakeholder involvement across institutes.
+
+
+**Situation 4 (B4): Asset/process spanning (virtually) all parts of the organization, with no owner claimed**
+
+First, determine whether the asset/process is actually needed. The three institute directors and directors of supporting services jointly decide **(E4)**. If no consensus is reached, the Board of Directors appoints an owner **(E4)**.
+
+---
+
+## Notes on Linked Content
+
+The source files reference the following related notes in the vault:
+
+- [Vulnerability](../Information%20Security/Risks/Vulnerability.md)
+- [Threats MoC](../Information%20Security/Risks/Threats%20MoC.md)
+- [Risks definitions](../Information%20Security/Risks/Risks%20definitions.md)
+- [Risk ownership](../Information%20Security/Risks/Risk%20ownership.md)
+- [Control ownership](Control%20ownership.md)
+- [Asset lifecycle](Asset%20lifecycle.md)
+- [How to develop an Asset Inventory](How%20to%20develop%20an%20Asset%20Inventory.md)
+
+
+ ![Asset classes](Asset%20classes.png)
+

Corpus/ISMS/Authorization vs Access Control.md

@@ -0,0 +1,33 @@
+---
+tags:  
+- infosec
+- type/explainer
+---
+
+# Authorization vs. Access Control
+
+[Authorization](../Standards/ISO27x/Authorization.md) defines _what_ a user (or system) is allowed to do, [access control ](Access%20Control.md) is the _system_ or _process_ that enforces those defined permissions.
+
+## Authorization
+
+- **What it is:** Authorization is the **process of determining what a verified user (or system) is allowed to do or access** once their identity has been confirmed (authenticated). It's about defining the **rights, privileges, or permissions** associated with a specific identity.
+- **The "Why":** It answers the question, "What can this person/system do?"
+- **Policy-driven:** Authorization is primarily concerned with establishing the policies and rules that dictate access. These policies can be based on various factors like Roles, Attributes or Relationships (see [Access Control Models](Access%20Control%20Models.md)).
+- **Examples:**
+    - A bank's policy stating that only the account holder can access their individual account online.
+    - A department head deciding that everyone in their department has access to a specific shared drive.
+    - Defining that a "guest" user has very limited access to a website.
+
+## Access Control
+
+- **What it is:** Access control is the **mechanism or system that enforces the authorization policies**. It's the technical implementation that actually grants or denies access to a resource based on the authorized permissions.
+- **The "How":** It answers the question, "How is the 'what' actually applied and managed?"
+- **Enforcement:** Access control is the act of putting those policies into practice. It involves:
+    - Checking a user's identity ([Authentication](../Standards/ISO27x/Authentication.md)).
+    - Consulting the pre-defined [Authorization](../Standards/ISO27x/Authorization.md)authorization rules.
+    - Granting or denying access to specific resources (files, applications, data, network segments, physical locations, etc.) or actions (read, write, delete, execute).
+- **Examples:**
+    - An Access Control List (ACL) on a file system that specifies which users or groups can read, write, or execute a particular file.
+    - A firewall rule that allows or denies traffic based on source IP address and port.
+    - A system that prompts for an administrator password before allowing software installation.
+    - Physical security systems like keycard readers that only grant entry to authorized personnel.

Corpus/ISMS/Basic ISMS governance model.md

@@ -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)

Corpus/ISMS/Belang van een BCP.md

@@ -0,0 +1,25 @@
+# Het belang van een Bedrijfscontinuïteitsplan
+
+Het hebben van een bedrijfscontinuïteitsplan (BCP) is cruciaal voor een organisatie om verschillende redenen:
+
+1. **Minimale Uitvaltijd:** Een BCP helpt ervoor te zorgen dat kritieke bedrijfsfuncties kunnen doorgaan tijdens en na een ramp of onverwachte gebeurtenis. Dit minimaliseert uitvaltijd en de bijbehorende financiële verliezen.
+
+2. **Risicobeheer:** Door potentiële risico’s te identificeren en hier van tevoren op voor te bereiden, kan een organisatie deze risico’s effectiever beheren en verminderen. Een BCP identificeert kwetsbaarheden en implementeert beschermingsmaatregelen en procedures om deze aan te pakken.
+
+3. **Bescherming van Data en Bezittingen:** Een uitgebreid BCP omvat strategieën om belangrijke data en organisatorische bezittingen te beschermen en te herstellen, waardoor het risico op dataverlies of -corruptie wordt verminderd en bedrijfsactiviteiten zonder significante verstoring kunnen doorgaan.
+
+4. **Behoud van Klantenvertrouwen:** Het snel en efficiënt reageren op een crisis helpt het vertrouwen van klanten, leveranciers en andere belanghebbenden te behouden, en toont aan dat de organisatie betrouwbaar en veerkrachtig is, zelfs onder uitdagende omstandigheden.
+
+5. **Zorg voor Naleving:** Veel sectoren zijn onderworpen aan wettelijke vereisten met betrekking tot rampenherstel en bedrijfscontinuïteit. Een formeel BCP zorgt voor naleving van deze voorschriften, wat helpt om juridische problemen en boetes te vermijden.
+
+6. **Bescherming van Medewerkers:** Een BCP geeft prioriteit aan de veiligheid van medewerkers door procedures te hebben voor communicatie, evacuatie en continuïteit van werk in een veilige omgeving. Het waarborgen van het welzijn van medewerkers bevordert loyaliteit en productiviteit.
+
+7. **Financiële Stabiliteit:** Door operationele verstoringen en financiële verliezen te minimaliseren, ondersteunt een BCP de financiële stabiliteit van een organisatie tijdens en na een onvoorziene gebeurtenis. Deze stabiliteit kan cruciaal zijn voor het nakomen van contractuele verplichtingen en het behouden van het vertrouwen van investeerders.
+
+8. **Concurrentievoordeel:** Organisaties die tijdens verstoringen operationeel kunnen blijven, hebben een concurrentievoordeel ten opzichte van degenen die dat niet kunnen. Deze betrouwbaarheid kan een onderscheidende factor zijn op de markt.
+
+9. **Faciliteren van Herstel:** Een BCP biedt een duidelijke routekaart voor herstel, met details over rollen, verantwoordelijkheden en procedures die moeten worden gevolgd na een verstoring, wat de terugkeer naar normale operaties versnelt.
+
+10. **Opbouwen van Organisatorische Veerkracht:** Het proces van het ontwikkelen en onderhouden van een BCP helpt bij het bevorderen van een cultuur van veerkracht, waardoor de organisatie beter is voorbereid op een breed scala aan potentiële bedreigingen en veranderingen in het zakelijke milieu.
+
+Al met al helpt een goed opgesteld bedrijfscontinuïteitsplan een organisatie om verstoringen te anticiperen, erop te reageren en ervan te herstellen, wat zorgt voor langdurige duurzaamheid en succes.

Corpus/ISMS/Business Impact Analysis (BIA).md

@@ -0,0 +1,24 @@
+# Business Impact Analysis (BIA)
+
+Business Impact Analysis (BIA) is an activity within the proces of Business Continuity Planning ([BCP](../📚️%20Literature%20notes/BCP_Bedrijfscontinuïteitsplanning.md)).
+
+The goal of a Business Impact Analysis (BIA) process is 
+
+A Business Impact Analysis (BIA) examines the potential impacts of disruptions, such as financial losses, reputational damage, regulatory penalties, and operational continuity.
+The outcomes help to prioritize business activities and resources to enable the resumption of product and service delivery after a (major) disruption[^1].
+
+Guidelines and tooling:
+- [Guidelines for business impact analysis ISO 22317](../Standards/ISO27x/ISO%2022317%20Guidelines%20for%20business%20impact%20analysis.md)
+- [Assessing reputational risks](../Various/Assessing%20reputational%20risks.md)
+- [BIA Workshop](../Standards/ISO27x/Implementation%20Products/BIA%20Workshop.md)
+- [TLP impact matrix](Data%20classification/Traffic%20Light%20Protocol%20TLP.md)
+- Afhankelijkheid tussen systemen/voorzieningen?
+	- Resource Breakdown Structure (RBS)
+	- Fishbone Diagram (Ishikawa/Cause and Effect): Useful for identifying root causes of dependencies and resource constraints in processes.
+
+ISO 27001 Controls:
+- [5.29:](../MoCs/ISO_27002_2022_5.29_MoC%20Information%20security%20during%20disruption.md) Information security during disruption
+- [5.30:](../Information%20Security/ICT%20readiness%20for%20business%20continuity.md) ICT readiness for business continuity
+- [5.9:](../MoCs/ISO_27002_2022_5.9_MoC%20Inventory%20of%20information%20and%20other%20associated%20assets.md) Inventory of information and other associated assets – regarding assets marked Critical on the Availability aspect 
+
+[^1]: See [Disaster Recovery Planning](Disaster%20Recovery%20Planning.md)

Corpus/ISMS/Challenges in auditing a one man company.md

@@ -0,0 +1,122 @@
+---
+tags:
+  - iso27001
+  - audit
+---
+# Challenges in auditing a one man company
+
+Compliance with the ISO 27001 standard presents unique challenges for a one-man company (or sole proprietor), primarily due to limited resources, expertise, and the need to fulfill all roles typically distributed among multiple staff members in larger organizations. Below are the specific challenges and practical strategies to overcome them.
+
+## Specific Challenges for a One-Man Company
+
+- **Limited Management Support and Involvement**
+  - In a one-man company, while the owner is both management and staff, the lack of a team can mean missing out on diverse perspectives and checks and balances. The owner may also struggle to balance daily operations with the demands of implementing and maintaining an ISMS[1].
+- **Resource Constraints**
+  - Sole proprietors often face tight budgets and limited time, making it difficult to allocate sufficient resources to compliance activities such as risk assessments, documentation, and ongoing monitoring[2][1].
+- **Complexity of Documentation**
+  - ISO 27001 requires comprehensive documentation, including policies, risk assessments, and records. Managing all documentation single-handedly can be overwhelming and time-consuming[2][1].
+- **Lack of Specialized Knowledge**
+  - The owner may lack expertise in information security, making it challenging to interpret and implement the standard’s requirements correctly[1].
+- **Continuous Monitoring and Improvement**
+  - Maintaining and improving the ISMS requires ongoing effort, including regular reviews, internal audits, and updates to controls. This is difficult for a sole proprietor who may already be stretched thin[3].
+- **Employee Awareness and Training**
+  - Although there are no employees, the owner must still ensure personal awareness and training, and may miss out on the benefits of peer learning and accountability[1][3].
+
+## Strategies to Overcome These Challenges
+
+- **Prioritize and Simplify Documentation**
+  - Focus on essential documents such as the Information Security Policy, Risk Treatment Plan, and Statement of Applicability. Use templates and streamline processes to reduce the documentation burden[1][3].
+- **Leverage External Expertise**
+  - Consider hiring an ISO 27001 consultant or using online tools and platforms designed for small businesses to guide you through the process and provide templates and checklists[3][4].
+- **Automate Where Possible**
+  - Use software solutions that automate risk assessments, documentation management, and compliance tracking. This can save time and reduce errors[4].
+- **Conduct Regular Self-Assessments**
+  - Schedule periodic reviews of your ISMS to ensure it remains effective and up to date. Treat these as mini-audits, checking against the standard’s requirements[3][5].
+- **Stay Informed and Trained**
+  - Invest in self-training through online courses, webinars, and resources specific to ISO 27001. This will help you understand the standard and stay current with best practices[1][5].
+- **Collaborate with Peers or Networks**
+  - Join professional networks or forums where you can share experiences, ask questions, and learn from others facing similar challenges[1].
+- **Use Open Source and Cost-Effective Tools**
+  - Implement open-source or affordable security tools to manage risks and controls within your budget constraints[2].
+
+## Summary Table: Challenges vs. Solutions
+
+| Challenge                        | Solution for One-Man Company                |
+|-----------------------------------|---------------------------------------------|
+| Limited management support        | Owner as both management and implementer    |
+| Resource constraints              | Prioritize, automate, and use consultants   |
+| Complex documentation             | Simplify, use templates, centralize records |
+| Lack of specialized knowledge     | Training, external expertise, peer networks |
+| Continuous monitoring             | Self-assessments, automation                |
+| Employee awareness/training       | Self-training, online resources             |
+
+By adopting these strategies, a one-man company can navigate the complexities of ISO 27001 compliance, build a robust information security posture, and demonstrate commitment to protecting sensitive data[2][1][3].
+
+Sources
+[1] Challenges and Solutions to Face - Implementing ISO 27001 in SMEs Safely https://www.linkedin.com/pulse/challenges-solutions-face-implementing-iso-27001-smes-soumyajit-das-2ihec
+[2] 10 Common ISO 27001 Challenges in Achieving Compliance https://compleye.io/articles/10-common-iso-27001-challenges-in-achieving-compliance/
+[3] ISO 27001 for small businesses - a detailed guide https://www.dataguard.com/blog/iso-27001-for-small-businesses-a-detailed-guide
+[4] A Guide to ISO 27001 for Small Business https://sprinto.com/blog/iso-27001-for-small-businesses/
+[5] ISO 27001 for Startups https://www.brightdefense.com/resources/iso-27001-for-startups/
+[6] ISO 27001 for Startups: Ten Best Practices https://drata.com/grc-central/get-started-iso-27001/iso-27001-for-startups
+[7] Is ISO 27001 possible for a small company? : r/sysadmin - Reddit https://www.reddit.com/r/sysadmin/comments/q1vb3h/is_iso_27001_possible_for_a_small_company/
+[8] Overcoming Common ISO 27001 Challenges for Small ... https://systemi.se/2025/01/19/iso-27001-challenges-for-small-companies/
+[9] Can a business with a single employee gain ISO27001 certification? https://security.stackexchange.com/questions/238533/can-a-business-with-a-single-employee-gain-iso27001-certification
+[10] 5 Challenges Your Business Must Overcome to Secure ISO 27001 Certification - MG Environmental Consulting https://mgenviro.com/5-challenges-your-business-must-overcome-to-secure-iso-27001-certification/
+[11] Key Challenges for Small Companies in ISO 27001 Certification https://www.genspark.ai/spark/key-challenges-for-small-companies-in-iso-27001-certification/9d5cabe6-c856-461a-9337-fd105d0e3d95
+[12] Common ISO 27001 Challenges & How to Overcome Them - Iseo Blue https://iseoblue.com/post/common-challenges-in-implementing-iso-27001-and-how-to-overcome-them/
+[13] ISO 27001 Solutions: Expert Guidance https://isocouncil.com.au/iso-27001-problems-solutions/
+[14] 3 Common ISO 27001 Implementation Challenges https://www.itgovernanceusa.com/blog/3-iso-27001-implementation-challenges-and-how-to-overcome-them
+[15] ISO 27001:2022 Transition Challenges and How to Use ... https://www.itgovernance.co.uk/blog/iso-27001-2022-transition-challenges-and-how-to-use-iso-27002
+[16] A Comprehensive Guide on ISO 27001 for Small Businesses - Socurely https://socurely.com/a-comprehensive-guide-on-iso-270001-for-small-business/
+[17] What is ISO 27001 Compliance? [Steps to Implement it] https://sprinto.com/blog/iso-27001-compliance/
+
+
+## Compliance challenges by Clause and Control
+
+For a one-person company pursuing ISO 27001 certification, specific clauses and controls present inherent compliance challenges due to structural requirements that conflict with a single-person operation. These difficulties arise from the standard's design for organizational segregation and oversight, not merely from resource constraints. Key challenges include:
+
+### 1. **Segregation of Duties (Annex A 5.3)**  
+   The control mandates separation of conflicting responsibilities (e.g., development vs. deployment, access authorization vs. usage) to prevent fraud or errors. A solo operator inherently cannot segregate duties, as one person performs all roles[1][2].  
+   *Overcoming it*: Document compensatory controls like automated approval workflows, third-party validations, or detailed activity logs to demonstrate oversight[2].
+
+### 2. **Internal Audits (Clause 9.2)**  
+   Requires independent audits of the ISMS. Self-auditing violates the independence principle[3][2].  
+   *Overcoming it*: Hire an external auditor for periodic checks, or use automated audit tools with third-party verification[5][3].
+
+### 3. **Management Review (Clause 9.3)**  
+   Demands formal reviews of the ISMS by management, separate from operational roles. A sole proprietor cannot separate these functions[3].  
+   *Overcoming it*: Maintain meticulous records of self-reviews, supplemented by external consultant assessments to add objectivity[4][3].
+
+### 4. **Employee Competence/Training (A.7.2.2)**  
+   Requires evidence of staff training and competence. With no employees, compliance is conceptually incongruous[4][3].  
+   *Overcoming it*: Document the owner’s training/certifications and outsource specialized tasks to certified professionals[3].
+
+### 5. **Incident Management (A.5.24)**  
+   Relies on reporting lines and escalation paths, which are absent in a one-person structure[3].  
+   *Overcoming it*: Implement automated incident detection tools and contract with third-party response services for escalation[3].
+
+### Structural vs. Effort-Based Challenges  
+These issues stem from the standard’s assumption of organizational hierarchy, not effort or cost:
+- **Segregation of Duties** and **Internal Audits** require role separation impossible for one person[1][2].  
+- **Management Review** lacks hierarchical separation[3].  
+- **Employee-focused controls** (e.g., training) become nonsensical without staff[4].  
+
+### Mitigation Strategies  
+- **Externalize critical functions**: Use consultants for audits, incident response, and specialized tasks[5][3][2].  
+- **Automate oversight**: Deploy tools for logging, approvals, and monitoring to simulate checks[4][2].  
+- **Document rigorously**: Compensate for structural gaps with exhaustive records of decisions, validations, and risk acceptances[4][3].  
+
+While achievable, certification requires creatively addressing these inherent conflicts through external support and technology, not merely scaling down larger-organization processes[5][2].
+
+Sources
+[1] ISO 27001:2022 Annex A 5.3 – Segregation of Duties https://www.isms.online/iso-27001/annex-a/5-3-segregation-of-duties-2022/
+[2] Can a business with a single employee gain ISO27001 ... https://security.stackexchange.com/questions/238533/can-a-business-with-a-single-employee-gain-iso27001-certification
+[3] ISO 27001 for small businesses - a detailed guide https://www.dataguard.com/blog/iso-27001-for-small-businesses-a-detailed-guide
+[4] How to Implement ISO 27001 Clause 4.1 and Pass The Audit https://hightable.io/iso-27001-clause-4-1-understanding-the-organisation-and-its-context/
+[5] Is ISO 27001 possible for a small company? : r/sysadmin https://www.reddit.com/r/sysadmin/comments/q1vb3h/is_iso_27001_possible_for_a_small_company/
+[6] What is ISO 27001? An easy-to-understand explanation. https://advisera.com/27001academy/what-is-iso-27001/
+[7] Challenges and Solutions to Face - Implementing ISO 27001 in SMEs Safely https://www.linkedin.com/pulse/challenges-solutions-face-implementing-iso-27001-smes-soumyajit-das-2ihec
+[8] Can an Individual Get ISO 27001 Certified? https://travasecurity.com/learn-with-trava/blog/can-an-individual-get-iso-27001-certified/
+[9] The Challenges of Adopting ISO 27001 Controls: A Comprehensive Guide for CISOs and IT Administrators https://heimdalsecurity.com/blog/iso-27001-controls-challenges/
+[10] Don't Make These 5 Mistakes When Implementing ISO 27001 https://insightassurance.com/dont-make-these-5-mistakes-when-implementing-iso-27001/

Corpus/ISMS/Classificatie van risico's.md

@@ -0,0 +1,70 @@
+# Classificatie van risico's
+
+Risico's kunnen worden ingedeeld in diverse categorieën, die elk een andere bron van gevaar vertegenwoordigen:
+
+- **Omgevingsrisico's**: Deze risico's ontstaan door natuurlijke en externe factoren waar je weinig controle over hebt. Denk hierbij aan natuurrampen zoals overstromingen, brand, aardbevingen, of extreme weersomstandigheden. Ook stroomuitval of een storing in de koeling van een serverruimte vallen hieronder.
+    
+- **Organisatorische risico's**: Deze risico's zijn gerelateerd aan de bedrijfsprocessen en -structuur. Voorbeelden zijn een gebrek aan duidelijke beleidsregels, onvoldoende budget voor beveiliging, of een slechte interne communicatie over beveiligingsincidenten. Ook het niet correct uitvoeren van procedures of het ontbreken van een noodplan kan leiden tot grote risico's.
+    
+- **Procesmatige risico's**: Deze risico's komen voort uit de dagelijkse operationele procedures. Dit omvat onder andere verouderde back-up procedures, het ontbreken van een strikte procedure voor het toekennen van toegangsrechten, of een ineffectief patch management-proces voor software.
+    
+- **Compliance- en juridische risico's**: Deze risico's zijn het gevolg van het niet voldoen aan wet- en regelgeving, zoals de Algemene Verordening Gegevensbescherming (AVG) of sector-specifieke regels. Een gebrek aan naleving kan leiden tot hoge boetes en reputatieschade.
+
+## Detaillering
+
+Informatiebeveiligingsrisico's kunnen op diverse manieren worden geclassificeerd. Een veelgebruikte methode is door ze in te delen op basis van de oorzaak. Deze classificatie helpt organisaties om een gestructureerde aanpak te hanteren bij het identificeren en mitigeren van bedreigingen.
+
+### Classificatie van Risico's op basis van Oorzaken
+
+Risico's voor de informatiebeveiliging kunnen in de volgende categorieën worden ingedeeld:
+
+---
+
+#### 1. Omgevingsrisico's
+
+Deze risico's zijn het gevolg van externe factoren en natuurverschijnselen die buiten de controle van een organisatie vallen. Ze kunnen de fysieke infrastructuur en daarmee ook de informatiesystemen bedreigen. Voorbeelden zijn:
+
+- **Natuurrampen**: Zoals overstromingen, branden, aardbevingen of extreme weersomstandigheden.
+    
+- **Stroomuitval**: Langdurige onderbrekingen in de stroomvoorziening kunnen leiden tot het uitvallen van servers en netwerken.
+    
+- **Fysieke storingen**: Denk aan storingen in koelsystemen van datacenters, wat kan leiden tot oververhitting van apparatuur.
+    
+
+---
+
+#### 2. Organisatorische Risico's
+
+Deze risico's vloeien voort uit de interne structuur en bedrijfscultuur van een organisatie. Ze zijn gerelateerd aan managementbeslissingen en het ontbreken van duidelijke richtlijnen. Voorbeelden zijn:
+
+- **Gebrek aan beleid**: Het ontbreken van duidelijke beveiligingsbeleidsregels of procedures.
+    
+- **Onvoldoende budget**: Een tekort aan financiële middelen voor de implementatie van beveiligingsmaatregelen.
+    
+- **Gebrekkige communicatie**: Slechte of onduidelijke communicatie over beveiligingsincidenten en risico's tussen verschillende afdelingen.
+    
+
+---
+
+#### 3. Procesmatige Risico's
+
+Deze risico's ontstaan door de dagelijkse operationele procedures en processen binnen een organisatie. Ze hebben te maken met de manier waarop taken worden uitgevoerd. Voorbeelden zijn:
+
+- **Verouderde procedures**: Procedures voor back-ups of herstel van data die niet regelmatig worden getest of geüpdatet.
+    
+- **Onjuiste configuratie**: Fouten in de configuratie van netwerken of software die onbedoelde kwetsbaarheden creëren.
+    
+- **Slechte toegangscontrole**: Het niet tijdig intrekken van toegangsrechten van voormalige medewerkers.
+    
+
+---
+
+#### 4. Compliance- en Juridische Risico's
+
+Deze risico's ontstaan door het niet naleven van wet- en regelgeving, contractuele verplichtingen of industriële normen. Het kan leiden tot aanzienlijke boetes, juridische problemen en reputatieschade. Voorbeelden zijn:
+
+- **Schending van de AVG**: Het verwerken van persoonsgegevens zonder de juiste juridische basis of beveiligingsmaatregelen.
+    
+- **Contractbreuk**: Het niet voldoen aan de beveiligingseisen die met klanten of partners zijn overeengekomen.
+    
+- **Niet voldoen aan standaarden**: Het negeren van sector-specifieke normen zoals de ISO 27001 voor informatiebeveiliging.

Corpus/ISMS/Classifying Integrity.md

@@ -0,0 +1,29 @@
+# Classifying Integrity
+
+See also: [Business Impact Analysis (BIA)](Business%20Impact%20Analysis%20(BIA).md), [A 8.2 Information Classification](../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001%20A%208.2%20Information%20classification.md#ISO%2027001%20A%208.2%20Information%20classification)
+
+Prompt to Perplexity AI on 2025-06-10: `In the field of information security, we identify and implement risk mitigating measures to safeguard the confidentiality, integrity, and availability of information. To establish levels of confidentiality, we use the instrument of data classification to establish levels of availability we can use business impact analysis. What instruments do we have to classify the necessity of integrity of information`
+
+Sources:
+[dataguard](https://www.dataguard.com/blog/classifying-information/)
+[CISecurity](https://www.cisecurity.org/-/media/project/cisecurity/cisecurity/data/media/files/uploads/2020/06/Information-Classification-Standard.docx)
+[Dataguard](https://www.dataguard.com/blog/classifying-information/)
+[CIO Platform Nederland](https://www.cio-platform.nl/l/en/library/download/urn:uuid:b095d62e-4915-4904-bec3-2d49ad94548f/2016+data+classification+guide+cio+platform+nederland+(eng).pdf?format=save_to_disk)
+[isms online](https://www.isms.online/iso-27002/control-5-12-classification-of-information/)
+
+To classify the necessity of integrity of information, organizations use instruments similar to those for confidentiality and availability, often integrated into data classification schemes based on the CIA triad (Confidentiality, Integrity, Availability). Specifically for integrity, classification levels typically reflect how critical it is that data remains accurate, consistent, and trustworthy throughout its lifecycle.
+
+## Instruments to Classify Integrity Necessity
+
+- **Integrity Classification Levels:** These define the impact of integrity loss on business processes and range from low to high, for example:
+	- *Unknown:* No extra integrity protection needed; breaches cause no consequential damage.
+	- *Low:* Some mistakes allowed; basic security required; breaches cause minor damage.
+	- *Middle:* Few mistakes allowed; integrity protection essential; breaches cause serious damage.
+	- *High:* No mistakes allowed; breaches cause very extensive damage [3](https://www.cio-platform.nl/l/en/library/download/urn:uuid:b095d62e-4915-4904-bec3-2d49ad94548f/2016+data+classification+guide+cio+platform+nederland+\(eng\).pdf?format=save_to_disk).
+- **Data Classification Standards:** Many organizations use classification standards that assign integrity levels alongside confidentiality and availability, ensuring tailored protection measures based on the risk and impact of integrity breaches [2](https://www.cisecurity.org/-/media/project/cisecurity/cisecurity/data/media/files/uploads/2020/06/Information-Classification-Standard.docx) [3](https://www.cio-platform.nl/l/en/library/download/urn:uuid:b095d62e-4915-4904-bec3-2d49ad94548f/2016+data+classification+guide+cio+platform+nederland+\(eng\).pdf?format=save_to_disk) [4](https://www.isms.online/iso-27002/control-5-12-classification-of-information/).
+- **Risk Assessment and Impact Analysis (BIA):** While BIA is often used for availability, it also helps assess the impact of integrity loss on business operations, reputation, and compliance, informing the classification and prioritization of integrity controls [6](https://www.neumetric.com/business-impact-analysis-incybersecurity/) [9](https://nvlpubs.nist.gov/nistpubs/ir/2022/NIST.IR.8286D.pdf).
+- **CIA-Based Classification Frameworks:** Frameworks like ISO 27001 and organizational policies define criteria and controls for integrity classification, often involving senior management ownership, periodic review, and training to ensure appropriate handling based on integrity requirements [1](https://www.dataguard.com/blog/classifying-information/) [4](https://www.isms.online/iso-27002/control-5-12-classification-of-information/) [7](https://en.wikipedia.org/wiki/Information_security).
+
+## Summary
+
+To classify the necessity of integrity, organizations use structured classification schemes that rate the importance of data accuracy and trustworthiness, supported by risk assessments and business impact analyses. These classifications guide the implementation of controls such as checksums, digital signatures, auditing, and version control to maintain data integrity [3](https://www.cio-platform.nl/l/en/library/download/urn:uuid:b095d62e-4915-4904-bec3-2d49ad94548f/2016+data+classification+guide+cio+platform+nederland+\(eng\).pdf?format=save_to_disk) [10](https://blog.riskrecon.com/the-cia-triad-securing-digital-information-and-data) [11](https://www.techtarget.com/whatis/definition/Confidentiality-integrity-and-availability-CIA).

Corpus/ISMS/Context analysis.md

@@ -0,0 +1,24 @@
+[ISO 27001 C 4.1](../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001_OT%20C%204%20Context%20of%20the%20organization.md#4%201%20Understanding%20the%20organization%20and%20its%20context) requires that "the organization shall determine external and internal issues that are relevant to its purpose and that affect its ability to achieve the intended outcome(s) of its information security management system."
+
+No form or method are specified, but there are some good accepted tools for this.
+
+Frequently mentioned are SWOT and PEST analyses (in one of it's forms, see [this](https://en.wikipedia.org/wiki/PEST_analysis) Wikipedia page).
+
+## PEST and variants
+PEST:
+- Political
+- Economic
+- Social (incl. cultural)
+- Technological
+
+PESTLE/PESTEL:
+- Legal (ISO C 4.2)
+- Environmental
+
+DESTEP:
+- Demographic
+- Ecological
+
+STEEPLED:
+- Ethical
+

Corpus/ISMS/Control ownership.md

@@ -0,0 +1,9 @@
+# Control ownership
+
+See also [Risk ownership](../Information%20Security/Risks/Risk%20ownership.md), [Asset ownership](Asset%20ownership.md)
+
+Principe: 
+> Control ownership can best be assigned to the individual or team that has both the resources and the skills to effectively implement the control. (And does not have conflicting interests)
+
+Indeling:
+> Control ownership: maak een matrix met categorieën controls vs. teams/rollen in de organisatie.

Corpus/ISMS/Cyber Security Governance Principles.md

@@ -0,0 +1,15 @@
+# Cyber Security Governance Principles
+
+by the Australian Institute of Company Directors and the Cyber Security Cooperative Research Centre, november 2024.
+
+The document outlines five key principles for governing organizational cyber resilience:
+
+1. Set clear roles and responsibilities.
+2. Develop, implement, and evolve a comprehensive cyber strategy.
+3. Embed cyber security in existing risk management practices.
+4. Promote a culture of cyber resilience.
+5. Plan for a significant cyber security incident.
+
+For each principle the document outlines key points and identifies 'red flags' that indicate low quality or non existent governance.
+
+![](Cyber%20Security%20Governance%20Principles.pdf)

Corpus/ISMS/Data breach procedure.md

@@ -0,0 +1,10 @@
+# Data breach procedure
+
+Previous work:
+- Post mortem Ultimaker LinkedIn Learning incident
+- Pixelpool Data breach procedure
+- CISSP cursus
+
+
+Relevant ISO 27001 clauses/controls:
+- [ISO 27001 A 16.1 Management of information security incidents and improvements](../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001%20A%2016.1%20Management%20of%20information%20security%20incidents%20and%20improvements.md)

Corpus/ISMS/Data classification/Data Classification.md

@@ -0,0 +1,64 @@
+# Data Classification
+
+**Definition:**
+"A *data classification* identifies the value of the data to the organization. Classification labels, the method by which they are assigned, and the required protection associated with the different labels, are identified in a policy." 
+Source: [CISSP_OSG_Chapter_5](../../Standards/CISSP/CISSP_OSG_Chapter_5.md#Defining%20data%20Classifications)
+
+Classification criteria should be risk based, for instance on potential damage to the organization, the privacy of individuals, national security, economic interests, or other critical concerns.
+
+## Examples from SANS forum
+
+Source: https://sth-community.sans.org/t/y4yt81n
+Retrieved:  2 september 2024
+
+Public
+Internal
+Confidential
+
+1. No risk - Open
+2. Some risk - Internal
+3. Significant risk - Confidential
+
+4. Unrestricted
+5. Restricted-External
+6. Restricted-Internal
+7. Confidential
+
+- Public
+- Internal
+- Confidential
+- Restricted
+
+Restricted, Confidential, Internal Use, and Public
+
+We have Confidential Information (CI) and Personal Information (PI). Both CI and PI are categorized as Red, Orange and Yellow for sensitivity (from most to least sensitive). Then there's Green Information, which is public.
+
+|   |   |
+|---|---|
+|General Use|Emails and documents with this label are not sensitive and can be shared both internally and externally with no risk of harm and without restriction.|
+|Confidential – Internal Use Only|This label applies to sensitive information that should not leave the organization but is not as critical as those under the "Highly Confidential" classification. Use this for information that if disclosed outside, could still cause harm but is primarily intended for internal stakeholders.|
+|Confidential – Third Party Authorized|This label applies to sensitive information that can be shared with third parties who have been vetted and authorized under specific conditions. This might include business partners or vendors who need access to certain information to provide services or support.|
+|Highly Confidential – Internal Use Only|This label applies to the most sensitive information that if disclosed, could result in severe damage to the organization. Access should be limited to a very select group of internal stakeholders, and it should not be shared outside the organization.|
+|Highly Confidential - Third Party Authorized|This label applies to extremely sensitive information that must sometimes be shared with third parties, under very strict controls and only when absolutely necessary. This could include sharing with legal counsel, auditors, or regulatory bodies who require access to fulfill their obligations to the organization.|
+
+Just before I left the Bank of England, we rebuilt our classification scheme - [https://www.bankofengland.co.uk/-/media/boe/files/about/human-resources/iscs-external-guidance.pdf](https://www.bankofengland.co.uk/-/media/boe/files/about/human-resources/iscs-external-guidance.pdf) is the reference. We had used UNCLASSIFIED, BANK CONFIDENTIAL, SECRET and TOP SECRET previously, but moved to OFFICIAL-BLUE, OFFICIAL-GREEN, OFFICIAL-AMBER and OFFICIAL-RED for the non SECRET levels - we wanted labels that were not using simple language as we found that using words like confidential were difficult to track in DLP systems, causing far too many false positives.  
+One of the reasons for the move was that the UK government was looking to change their scheme to a traffic light system also, so we moved to where they were heading.
+
+
+From a user perspective it is complex to figure out a classification. That's why some of our institutions reverse the process and start with the person and what they want to do.
+Leiden University has a tool picker that is publicly available, to help employees and students pick the correct tool (and indirectly the level of security and privacy that that tool offers).
+It does not solve the classification labeling problem if you have a single mandatory system in mind, but I can imagine that asking them about what goal they want to achieve makes it easier for employees to see classification as helpful and useful.
+[https://web.universiteitleiden.nl/assets/toolpicker/?lang=en](https://web.universiteitleiden.nl/assets/toolpicker/?lang=en)
+
+![](../Informatie_classificatie_matrix.xlsx)
+
+
+See also:
+[Datatags privacy oriented data classification system](Datatags%20privacy%20oriented%20data%20classification%20system.md)
+[Def_Sec_Handbook_Chapter_2](../../Literature/Defensive%20Security%20Handbook/Def_Sec_Handbook_Chapter_2.md#Information%20classification)
+[ISO 27002:2022 NL A5.12](../../Standards/ISO27x/OST/27002/NL/a-5.12-Classificeren-van-informatie.md)
+[Designing an information management scheme](../Designing%20an%20information%20management%20scheme.md)
+[Key Topics for a policy on handling classified information](../Policy%20examples/Key%20Topics%20for%20a%20policy%20on%20handling%20classified%20information.md)
+[Traffic Light Protocol (TLP)](Traffic%20Light%20Protocol%20TLP.md)
+
+

Corpus/ISMS/Data classification/Datatags privacy oriented data classification system.md

@@ -0,0 +1,37 @@
+ Sweeney L, Crosas M, Bar-Sinai M. Sharing Sensitive Data with Confidence: The DataTags System. Technology
+
+Science. 2015101601. October 16, 2015. http://techscience.org/a/2015101601; PDF version attached: [](techsci-datatags-sweeneycrosasbarsinai.pdf).
+
+Related:
+- [ISO 27001 A 8.2 Information classification](../../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001%20A%208.2%20Information%20classification.md)
+- [Privacy in ISO 27001](../../Standards/ISO27x/Privacy%20in%20ISO%2027001.md)
+
+Sweeney et all have developed a privacy oriented data classification system with six levels:
+
+![](Datatags%20classification%20table.jpg)
+*"Definitions for each of six datatags are introduced for demonstration purposes".*
+
+The classification is based on a five level scheme designed and adopted by Harvard University for storing and transmitting research data.
+
+The notion of datatags is introduced as a means of identifying handling and access requirements for a file.
+
+Privacy risks associated with each level:
+- Blue: zero risk for harm to individuals. This level is meant for non-confidential and non-personal information that can be stored and shared freely. 
+- Green: meant for unidentifiable personal data. No risk currently, but in the future a re-identification vulnerability may develop.
+- Orange: risk of material harm to individuals if disclosed.
+- Red: serious harm to individuals if disclosed, including the risk of serious social, psychological, reputational, financial, legal or other harm to an individual or group.
+- Crimson: non-authorized disclosure would cause severe harm to individuals
+
+
+The proposed application is "a repository capable of handling sensitive and non-sensitive files in accordance with different security requirements".
+
+A datatags-compliant repository satisfies the following conditions:
+
+> 1.  A datatag is a set of security features and access requirements for file handling. A datatags repository has a finite, partially ordered set of datatags, where the strictness and strength of datatags’ security features and access requirements dictate the ordering. A repository must have more than one datatag.
+>     
+> 2.  All files in the repository must have a datatag, and each file in the repository has one and only one datatag. A file may optionally have additional handling requirements, such as an audit trail log or an expiration date. A file may optionally require additional terms for a data use agreement or additional terms of access by a recipient of the file from the repository. A file may have attributes that further describe it for reporting purposes. None of the optional requirements may weaken or replace the security requirements for the file’s assigned datatag, and none may adjust a datatag’s security requirements to be the same as another datatag or stronger than a more restrictive datatag.
+>     
+> 3.  A recipient who receives a file from the repository must satisfy the file’s associated access requirements, produce sufficient credentials as requested, and agree to any terms of use required to acquire a copy of the file.
+>     
+> 4.  Technological guarantees exist that the requirements in 1 and 2 are satisfied for all files in the repository and for all accesses to those files from the repository. This imposes auditing obligations on transactions in the repository.
+

Corpus/ISMS/Data classification/Examples of TLP document classification for different industries.md

@@ -0,0 +1,12 @@
+# Examples of TLP document classification for different industries
+
+- [for information security](FIRST%20TLP%20labeled%20document%20examples%20for%20information%20security.md)
+- [for a commercial services organization](FIRST%20TLP%20labeled%20document%20examples%20commercial.md)
+- [for a childcare organization](FIRST%20TLP%20labeled%20document%20examples%20childcare.md)
+- [for a hospital](FIRST%20TLP%20labeled%20document%20examples%20hospital.md)
+- [for a national government organization](FIRST%20TLP%20labeled%20document%20examples%20national%20government.md)
+
+
+![](../../Information%20Security/Risks/TLP_Impact_matrix_NL.xlsx)
+
+

Corpus/ISMS/Data classification/Examples of measures for different TLP classifications.md

@@ -0,0 +1,72 @@
+# Examples of measures for different TLP classifications
+
+*Voor Nederlands, zie [hier](Voorbeelden%20van%20maatregelen%20bij%20verschillende%20TLP%20classificaties.md).*
+
+**TLP: CLEAR**
+- No measures
+- No restriction on the use of AI tools
+- Documents are labeled with TLP:CLEAR
+
+**TLP: GREEN**
+- Access limited to[^1] :
+	- the organization itself
+    - authorized external parties
+    - using MFA (Multi-Factor Authentication)
+- SharePoint/Teams/OneDrive:
+    - placement in folders that are broadly accessible internally is allowed
+    - sharing only with authorized external parties
+    - placement on your personal OneDrive is allowed
+- Cloud services and collaboration tools:
+    - only use solutions approved/managed by the organization
+- Emailing and sending:
+    - additional measures are not necessary (such as encrypted email or secure connections)
+- Use of Co-pilot is allowed
+    - Devices and locations:
+        - storage and access only via managed devices
+        - do not leave devices unattended
+        - printing only on approved/secure printers
+        - physical documents should only be kept in approved locations
+    - Documents are labeled with TLP:GREEN
+ 
+**TLP: AMBER (+STRICT)**
+*All measures/restrictions of TLP:GREEN apply, plus:*
+
+- Access limited to:
+    - specific teams and departments within the organization
+    - specific authorized persons from external parties, under a signed NDA (Non-Disclosure Agreement)
+- SharePoint/Teams/OneDrive:
+    - only place in folders that have limited internal access
+    - only specific external persons may be granted access
+    - placement on your personal OneDrive is _not_ allowed
+- Cloud services and collaboration tools:
+    - only use solutions managed by the organization (specify)
+    - only use services with strict security (such as DigiD or Bank-tokens)
+- Emailing and sending:
+    - only via secure connections, in encrypted form, or via a 'secure mailing' solution (such as Zivver)
+    - data transfer is monitored for abnormal patterns
+- Use of Co-pilot is _not_ allowed
+- Documents are labeled with TLP:AMBER
+
+
+**TLP: RED**
+*All measures/restrictions of TLP:AMBER apply, plus:*
+
+- Access limited to:
+    - specific persons within the organization
+- SharePoint/Teams/OneDrive:
+    - only place in folders accessible to specific employees
+    - external persons may _not_ be granted access
+    - placement on your personal OneDrive is _not_ allowed
+- Full monitoring of data transfer: control and logging of all data traffic
+- Cloud services and collaboration tools:
+    - usage is limited to ...
+- Emailing and sending:
+    - Not allowed
+    - Full and detailed logging of all activities
+- Devices and locations:
+    - no access with mobile phones
+    - printing not allowed
+    - physical documents are kept in locked locations with restricted access (specify)
+- Documents are labeled with TLP:RED
+
+[^1]: Controls [[ISO_27002_2022_NL_BT_5.19 Information security in supplier relationships|5.19]], [[ISO_27002_2022_NL_BT 6.6 Confidentiality or non-disclosure agreements|6.6]], [[ISO_27002_2022_NL_BT 7.2 Physical access security |7.2]]

Corpus/ISMS/Data classification/FIRST TLP labeled document examples childcare.md

@@ -0,0 +1,34 @@
+ChatGPT prompt, requested 6 januari 2025:
+`The FIRST TLP standard recognizes 4 labels, RED, AMBER, GREEN and CLEAR. For each label, give typical examples of the kinds of documents in a childcare organization
+
+In a childcare organization, the Traffic Light Protocol (TLP) can be used to manage and classify information based on its sensitivity and the appropriate sharing audience. Here's how the different TLP labels might be applied:
+
+1. **TLP:RED**
+   - **Examples of Documents:**
+     - Child protection reports or sensitive incident reports involving specific children or staff that are under investigation.
+     - Confidential parental complaints or legal documents involving the welfare of specific children.
+     - Emergency response plans detailing actions for critical incidents affecting child safety.
+     - Personal records of children and staff, such as health information or background checks, requiring high confidentiality.
+
+2. **TLP:AMBER**
+   - **Examples of Documents:**
+     - Internal assessments or evaluations regarding program effectiveness or staff performance that require restricted sharing.
+     - Reports on non-critical incidents involving children that need to be shared only with relevant staff and authorities.
+     - Draft policies or procedures under consideration that have not been finalized or publicly announced.
+     - Strategy documents for program development or expansions that are not for public release but may be shared with select partners or stakeholders.
+
+3. **TLP:GREEN**
+   - **Examples of Documents:**
+     - Staff training manuals and educational resources intended for internal use but could be shared with partners for collaborative learning.
+     - Updates on non-sensitive program changes or organizational developments shared internally among staff.
+     - General guidance or informational documents that support day-to-day operations and could be made available to partnership organizations.
+     - Documents outlining health and safety protocols that are not proprietary and can facilitate broader industry best practices.
+
+4. **TLP:CLEAR**
+   - **Examples of Documents:**
+     - Public newsletters and announcements about upcoming events or programs open to the community.
+     - Marketing materials, brochures, and digital content intended for parents and the general public.
+     - General policy documents and guidelines on topics such as enrolment, non-sensitive health practices, or general childcare tips.
+     - Information about community involvement activities or open days intended to engage and inform the public about the organization's work.
+
+These examples illustrate how the TLP can be an effective tool in a childcare organization to manage information sharing, protecting sensitive data and ensuring that information is shared with the appropriate audience.

Corpus/ISMS/Data classification/FIRST TLP labeled document examples commercial.md

@@ -0,0 +1,34 @@
+ChatGPT prompt, requested 6 januari 2025:
+`The FIRST TLP standard recognizes 4 labels, RED, AMBER, GREEN and CLEAR. For each label, give typical examples of the kinds of documents in a commercial services organization` 
+
+The Traffic Light Protocol (TLP) is a system for classifying sensitive information to facilitate information sharing. It consists of different color-coded labels, each indicating the level of sensitivity and the degree of sharing permitted. Here's how these might apply in a commercial services organization:
+
+1. **TLP:RED**
+   - **Examples of Documents:** 
+     - Internal reports on a severe data breach or security incident that is currently under investigation.
+     - Legal documents related to ongoing litigation or disputes.
+     - Executive communications containing strategic decisions that could significantly impact the company's operations or reputation if disclosed.
+     - Crisis management plans and tactics being deployed in real-time.
+
+2. **TLP:AMBER**
+   - **Examples of Documents:**
+     - Internal audit findings and potential vulnerabilities that need to be addressed.
+     - Draft versions of sensitive projects or product developments not yet publicly announced.
+     - Employee performance reviews and confidential HR investigations.
+     - Negotiation strategies or contract terms involving significant vendors or partners.
+
+3. **TLP:GREEN**
+   - **Examples of Documents:**
+     - Internal newsletters and policy updates meant for all employees but not for public or competitor knowledge.
+     - Market analysis reports or industry research intended to guide internal strategy but not yet published externally.
+     - Training materials and resources meant for internal skill-building and organizational development.
+     - Summary reports on non-critical projects or initiatives that may be shared with specific partners under NDA.
+
+4. **TLP:CLEAR**
+   - **Examples of Documents:**
+     - Press releases and publicly available company announcements.
+     - Marketing materials and brochures intended for public distribution.
+     - White papers and research reports approved for public or client distribution.
+     - General information about company policies and procedures that are not sensitive or proprietary.
+
+These examples serve to illustrate how TLP labeling can be employed within a commercial services organization to manage the dissemination of information effectively, depending on its sensitivity and intended audience.

Corpus/ISMS/Data classification/FIRST TLP labeled document examples for information security.md

@@ -0,0 +1,46 @@
+ChatGPT prompt, requested 6 januari 2025:
+`The FIRST TLP standard recognizes 4 labels, RED, AMBER, GREEN and CLEAR. For each label, give typical examples of the kinds of information found in the information security function of the organization and its systems` 
+
+### The FIRST TLP standard recognizes 4 labels, RED, AMBER, GREEN and CLEAR. For each label, give typical examples of the kinds of information found in the information security function of the organization and its systems
+
+The Traffic Light Protocol (TLP) is a system designed to facilitate sharing sensitive information by specifying what can be shared and with whom. Here are typical examples of information under each TLP label within an organization's information security function:
+
+1. **TLP:RED**
+   - **Example Information:** Detailed specifics on a newly discovered zero-day vulnerability affecting critical systems, incident investigation reports with sensitive details, personal data of incident responders or affected parties, or intelligence on imminent threats that could lead to significant harm.
+   - **Sharing Guidelines:** Intended for the named recipients only. Extreme caution is required due to the sensitive nature of the information. It should not be shared beyond the intended recipients without explicit permission.
+
+2. **TLP:AMBER**
+   - **Example Information:** Incident detection techniques, indicators of compromise (IOCs) that might be used by threat actors, internal security processes or system configurations, and vulnerabilities that are being actively exploited but are not publicly known.
+   - **Sharing Guidelines:** Restricted to individuals or groups within the recipient’s organization who need to know in order to prevent or mitigate the impact of incidents.
+
+3. **TLP:GREEN**
+   - **Example Information:** General threat intelligence reports, summaries of common attack vectors, security awareness materials, lessons learned from incidents (with sensitive details redacted), and industry best practices for various security processes.
+   - **Sharing Guidelines:** Information can be shared within the community or group but not publicly. It can be shared with peers and partner organizations within the same sector or community.
+
+4. **TLP:CLEAR**
+   - **Example Information:** Publicly available security advisories, general security policies, declassified information about previous incidents, and announcements that have already been made public.
+   - **Sharing Guidelines:** Information can be freely shared with anyone, including the general public. Offers the least restriction and encourages wide dissemination.
+
+Using TLP labels allows organizations to better control the dissemination of sensitive information, ensuring it reaches those who need it while preventing leakage to unintended parties.
+
+### Answer the same question, but now focus on information that would facilitate gaining access to systems and information of the organization
+
+When considering the potential for facilitating unauthorized access to an organization's systems and information, here’s how different types of sensitive information might be categorized under each TLP label:
+
+1. **TLP:RED**
+   - **Example Information:** Administrative credentials, passwords, or encryption keys for critical systems; architectural diagrams of the network including security solutions and defenses in place; detailed security vulnerability assessments and penetration testing results exposing critical vulnerabilities; and detailed incident reports that expose system weaknesses.
+   - **Sharing Guidelines:** This information is highly sensitive and should only be shared with specific, authorized individuals who require it for critical tasks. It must not be shared beyond these individuals without explicit permission due to the risk of compromise.
+
+2. **TLP:AMBER**
+   - **Example Information:** Configuration details of critical security systems (e.g., firewalls, intrusion detection/prevention systems), lists of known vulnerabilities within less critical systems, scripts or tools used for internal security checks, and access controls or user privilege levels of staff within the organization.
+   - **Sharing Guidelines:** Information should only be shared with personnel or departments directly involved in securing or maintaining systems. It should not be distributed beyond these necessary recipients within the organization.
+
+3. **TLP:GREEN**
+   - **Example Information:** General guidelines on password policies, which IT systems are in place along with their general functions but without exposing critical configurations, high-level security framework overviews, and anonymized metrics on system access attempts (e.g., frequency of login attempts).
+   - **Sharing Guidelines:** This information can be shared within the community or with partner organizations, enabling sharing of best practices or awareness of common challenges without exposing sensitive details that might facilitate system access.
+
+4. **TLP:CLEAR**
+   - **Example Information:** Public security policies, non-sensitive security training materials aimed at general staff awareness, historical data on resolved security incidents without sensitive details, and general announcements regarding security posture improvements.
+   - **Sharing Guidelines:** Such information can be freely shared with the public, including stakeholders outside the organization, since it does not directly compromise the security of systems or facilitate unauthorized access.
+
+By appropriately classifying information related to access facilitation, organizations can better protect their systems from unauthorized access while still disseminating necessary security information effectively.

Corpus/ISMS/Data classification/FIRST TLP labeled document examples hospital.md

@@ -0,0 +1,34 @@
+ChatGPT prompt, requested 6 januari 2025:
+`The FIRST TLP standard recognizes 4 labels, RED, AMBER, GREEN and CLEAR. For each label, give typical examples of the kinds of documents in a hospital 
+
+In a hospital setting, managing information sensitivity is crucial for maintaining patient confidentiality and operational integrity. Here's how the Traffic Light Protocol (TLP) might be applied:
+
+1. **TLP:RED**
+   - **Examples of Documents:**
+     - Detailed patient medical records containing sensitive personal health information.
+     - Incident reports related to severe patient safety issues or medical errors under investigation.
+     - Legal documents concerning ongoing malpractice litigation or sensitive negotiations.
+     - Emergency response plans or security protocols related to current high-risk situations.
+
+2. **TLP:AMBER**
+   - **Examples of Documents:**
+     - Internal audit reports assessing compliance with healthcare regulations like HIPAA.
+     - Strategic planning documents for upcoming service expansions or new medical programs.
+     - Internal memos detailing sensitive operational changes or staffing adjustments.
+     - Clinical trial results or research findings not yet published or publicly disclosed.
+
+3. **TLP:GREEN**
+   - **Examples of Documents:**
+     - Internal newsletters updating staff on non-sensitive policy changes or hospital initiatives.
+     - Training manuals for medical and administrative staff intended for internal distribution.
+     - Non-confidential aggregate data reports used for internal performance tracking or quality improvement.
+     - Educational materials for staff that might also be available for partner healthcare organizations under certain conditions.
+
+4. **TLP:CLEAR**
+   - **Examples of Documents:**
+     - Public health announcements or educational brochures available to patients and the public.
+     - Press releases about hospital achievements, new programs, or community events.
+     - General policy documents that are applicable and accessible to patients, such as visiting hours or parking information.
+     - Community engagement materials promoting health and wellness initiatives.
+
+These examples illustrate how a hospital can employ the TLP labeling system to appropriately safeguard sensitive information while facilitating necessary information sharing within and outside the organization.

Corpus/ISMS/Data classification/FIRST TLP labeled document examples national government.md

@@ -0,0 +1,32 @@
+ChatGPT prompt, requested 8 januari 2025:
+`The FIRST TLP standard recognizes 4 labels, RED, AMBER, GREEN and CLEAR. For each label, give typical examples of the kinds of documents in a national government organization
+
+### The FIRST TLP standard recognizes 4 labels, RED, AMBER, GREEN and CLEAR. For each label, give typical examples of the kinds of documents in a national government organization
+
+The FIRST Traffic Light Protocol (TLP) is used to facilitate greater sharing of information by indicating how sensitive information can be shared with others. Here are examples of documents for each label within a national government organization:
+
+1. **TLP:RED**
+   - Internal security breach reports that contain details of vulnerabilities in critical infrastructure.
+   - Discussions about ongoing covert operations or intelligence-gathering activities.
+   - Sensitive personnel files or internal investigations involving high-level officials.
+   - Drafts of international negotiation strategies or policies not yet finalized.
+
+2. **TLP:AMBER**
+   - Reports on potential threats or vulnerabilities identified in public systems or services.
+   - Situational updates on significant national security events that require coordination among specific agencies.
+   - Internal guidelines or procedures that affect multiple departments, but which are not publicly known.
+   - Inter-agency memos outlining preliminary assessments of security risks.
+
+3. **TLP:GREEN**
+   - General security awareness materials intended for public sector employees.
+   - Summaries of non-sensitive elements of public policy that require feedback from stakeholders.
+   - Internal training documents on best practices for cybersecurity.
+   - Notices on changes in protocol that affect government contractors.
+
+4. **TLP:CLEAR**
+   - Public press releases about government initiatives or newly passed legislation.
+   - Official statistical reports or economic forecasts available to the public.
+   - Public safety announcements or general tips for community readiness.
+   - Educational materials designed for broad public distribution on topics such as cyber hygiene.
+
+Each of these labels helps ensure that sensitive information is appropriately protected while allowing for necessary dissemination and collaboration within and across government entities and the broader public.

Corpus/ISMS/Data classification/Traffic Light Protocol TLP.md

@@ -0,0 +1,36 @@
+# About the Traffic Lights Protocol for labeling information 
+or: the FIRST TLP protocol
+
+[FIRST website](https://www.first.org/tlp/)
+
+TLP provides a simple and intuitive schema for indicating when and how sensitive information can be shared, facilitating more frequent and effective collaboration. It employs four colors to indicate expected sharing boundaries to be applied by the recipient(s). ([source](https://www.cisa.gov/news-events/news/traffic-light-protocol-tlp-definitions-and-usage))
+
+![](../../Information%20Security/Risks/TLP_Impact_matrix_NL.xlsx)
+
+
+[Examples of TLP document classification for different industries](Examples%20of%20TLP%20document%20classification%20for%20different%20industries.md)
+[Examples of measures for different TLP classifications](Examples%20of%20measures%20for%20different%20TLP%20classifications.md)
+[Voorbeelden van maatregelen bij verschillende TLP classificaties](Voorbeelden%20van%20maatregelen%20bij%20verschillende%20TLP%20classificaties.md)
+
+[Dataclassificatie volgens TLP](../../Standards/ISO27x/Implementation%20Products/Dataclassificatie%20volgens%20TLP.md)
+
+
+
+
+## Access Levels
+
+*ChatGPT, 14 februari 2025* 
+*Prompt: The FIRST.ORG TLP defines 4 levels of access to information. Describe each level in terms of individuals or groups to which access should be limited*
+
+**Answer**
+The Forum of Incident Response and Security Teams (FIRST) Traffic Light Protocol (TLP) defines four levels of access to information, each designed to facilitate secure and responsible sharing of sensitive information. Here's a description of each level:
+
+1. **TLP:RED** - This level indicates that the information is highly sensitive and should be shared only with specific individuals who are directly involved in making decisions or taking actions in an incident response. The access is strictly limited to the people present at the meeting or explicitly named recipients. This level ensures that the information is not shared beyond this restricted group.
+
+2. **TLP:AMBER** - Information classified under TLP:AMBER can be shared with individuals within a particular organization or group who need to know in order to mitigate risks. This level of access is typically restricted to a limited number of stakeholders within the organization and may include external parties if they are directly involved in the response or resolution.
+
+3. **TLP:GREEN** - This level allows the information to be shared with peers and partner organizations within the broader community but not publicly. It is intended to encourage collaboration and information exchange while maintaining a level of confidentiality that prevents public distribution.
+
+4. **TLP:CLEAR** (or formerly TLP:WHITE) - Information categorized under this level can be shared freely with the public. There are no restrictions on distribution, and the information can be shared with anyone, including the general public. This level is used for information that poses no direct security threat if widely disseminated.
+
+These levels facilitate appropriate information sharing while protecting sensitive data and ensuring that it is accessed only by those who need it to effectively respond to security incidents.

Corpus/ISMS/Data classification/Voorbeelden van maatregelen bij verschillende TLP classificaties.md

@@ -0,0 +1,70 @@
+# Voorbeelden van maatregelen bij verschillende TLP classificaties
+
+**TLP: CLEAR**
+* Geen maatregelen
+* Geen beperking op het gebruik van Al tools
+* Documenten worden gelabeld met TLP:CLEAR
+
+**TLP: GREEN**
+* Toegang beperkt tot[^1] :
+	* de eigen organisatie
+	* geautoriseerde externe partijen
+	* met gebruik van MFA
+* SharePoint/Teams/OneDrive:
+	* plaatsing in mappen die intern breed toegankelijk zijn is toegestaan
+	* delen alleen met geautoriseerde externe partijen
+	* plaatsing op je persoonlijke OneDrive is toegestaan
+* Cloud services en samenwerkingstools:
+	* Gebruik alleen door de organisatie goedgekeurde / beheerde oplossingen
+* Mailen en verzenden:
+	* aanvullende maatregelen niet nodig (zoals versleutelde mail of beveiligde verbindingen)
+* Gebruik van Co-pilot is toegestaan
+* Devices en locaties: 
+	* opslag en toegang alleen via managed devices
+	* devices niet onbeheerd achterlaten
+	* afdrukken alleen op goedgekeurde/beveiligde printers
+	* fysieke documenten alleen bewaren op goedgekeurde locaties
+* Documenten worden gelabeld met TLP:GREEN
+
+**TLP: AMBER (+STRICT)**
+*Alle maatregelen/beperkingen van TLP:GREEN, plus:*
+
+* Toegang beperkt tot:
+	* specifieke teams en afdelingen binnen de eigen organisatie
+	* specifieke geautoriseerde personen van externe partijen, onder een getekende NDA
+* SharePoint/Teams/OneDrive:
+	* alleen plaatsen in mappen die intern beperkt toegankelijk zijn
+	* alleen specifieke externe personen mogen toegang krijgen
+	* plaatsing op je persoonlijke OneDrive is *niet* toegestaan
+* Cloud services en samenwerkingstools:
+	* Gebruik alleen door de organisatie beheerde oplossingen (benoemen)
+	* Gebruik alleen services met strenge beveiliging (zoals DigiD of Bank-tokens)
+* Mailen en verzenden:
+	* alleen via beveiligde verbindingen, in versleutelde vorm of via een 'veilig mailen' oplossing (zoals Zivver)
+	* gegevensoverdracht wordt gemonitord op afwijkende patronen
+* Gebruik van Co-pilot is *niet* toegestaan
+* Documenten worden gelabeld met TLP:AMBER
+
+**TLP: RED**
+*Alle maatregelen/beperkingen van TLP:AMBER, plus:*
+
+* Toegang beperkt tot:
+	* specifieke personen binnen de eigen organisatie
+* SharePoint/Teams/OneDrive:
+	* alleen plaatsen in mappen die toegankelijk zijn voor specifieke medewerkers 
+	* externe personen mogen *geen* toegang krijgen
+	* plaatsing op je persoonlijke OneDrive is *niet* toegestaan
+* Volledige monitoring van gegevensoverdracht: controle en logging van al het dataverkeer.
+* Cloud services en samenwerkingstools:
+	* gebruik is beperkt tot ... 
+* Mailen en verzenden:
+	* Niet toegestaan
+	* Volledige en gedetailleerde logging van alle activiteiten
+- Devices en locaties: 
+	* geen toegang met mobiele telefoons
+	* afdrukken niet toegestaan
+	* fysieke documenten worden bewaard op afgesloten locaties met beperkte toegang (benoemen)
+* Documenten worden gelabeld met TLP:RED
+
+
+[^1]: Controls [5.19](../../Standards/ISO27x/OST/27002/NL/a-5.19-Informatiebeveiliging-in-leveranciersrelaties.md), [[ISO_27002_2022_NL_BT 6.6 Vertrouwelijkheids- of geheimhoudingsovereenkomsten|6.6]], [[ISO_27002_2022_NL_BT 7.2 Fysieke toegangsbeveiliging                                                     |7.2]]

Corpus/ISMS/Designing an information management scheme.md

@@ -0,0 +1,71 @@
+# Designing an information management scheme
+
+Related: [ISO_27002_2022_5.12_PE Classification of information](../../../iso27DIY-gis/reference/Paraphrased/ISO27002-2022-EN/ISO_27002_2022_5.12_PE%20Classification%20of%20information.md)
+
+Source: [ISMS Alliance](https://ismsalliance.com/trends/iso-27001-isms-risk-management/designing-an-information-management-scheme/)
+Retrieved: September 26, 2022
+
+The simplest form of an information management scheme consists of:
+- classification scheme: a list of classifications with definitions to allow people to consistently classify information.
+- labelling scheme: a way for documents and other information to be visibly associated with a classification.
+- handling rules: information on how to use and protect information with each of the defined classifications.
+- process which explains how to use the above three documents (e.g. how to decide who is responsible for classifying a given item of information).
+
+
+If the classification scheme is too complex, it will confuse people and may result in unintended disclosure and/or preventing intended disclosure.
+If the scheme is too simple, the same risks occur as it forces people to either over- or under-classify.
+The UK Government’s only has three classifications above unclassified: Official, Secret and Top Secret.
+
+When designing a classification scheme, decide how few different sets of information handling rules you need.
+
+Classification levels should be compatible with the Freedom of Information Act 2000 (FoIA), which groups information into three classes:
+
+- information that is routinely published
+- information that is disclosed, subject to a public interest test
+- information that is not disclosed.
+
+There may be some point in sub-dividing the third (and possibly the second) class, e.g. “does not leave the building” and “viewable from outside”.
+
+Note: this also applies to the Data Protection Act 1998.
+
+The UK Government uses Business Impact Levels (BILs). The author thinks the Impact Level tables are "likely to be too complex for practical information classification schemes", but suggests using them as a checklist.
+
+Classifications should take account the information’s requirements for **integrity** and **availability**, as well as **confidentiality**.
+
+## Labeling
+
+for digital documents or e-mails the label should be in a standard place in the digital content; for paper it should be on the file or envelope (double envelopes may be required if the actual classification needs to be protected); for on-line systems the label may need to be on a login page if it’s not possible to put it on every screen.
+
+Structured information (CMS, database) will be much easier to label than unstructured information (private folder system, mail, notebooks).
+
+One method for labelling information, which is simple but very effective, is to specify that everything in a particular system, or environment, is automatically of a particular classification.
+Make sure that information with a higher classification is not entered into the system, and that extracted data is labelled and handled effectively outside the system.
+
+Labelling related to confidentiality can also be used to indicate who should handle the information. When someone not entitled sees information not intended to him/her, they should report a security breach.
+
+## Handling
+Here is an example of a three-tier approach focused on confidentiality:
+
+![](Three-tier-information-handling-scheme.png)
+
+. | Classification 1 (no concern) | Classification 2 (slightly unsettled) | Classification 4 (genuinely scared)
+------- | ------------- | ------- | ------ | ------
+Store, process and transmit - where | Anywhere | Premises of organisation or trusted third party (can take work home with minor precautions) | High security location (can't take work home unless you live in a bunker)
+Store, process and transmit - how | Any method allowed | Only approved methods (e.g. encrypted, or via registered post) | Storage only in bunker. Processing with formal approval on high security systems. Hand transport by security personnel only. Face to face discussions only.
+
+Documenting the handling rules is best done by describing the risk the information should be protected against, an then list the measures that should be taken for the different classification levels, for example:
+
+Risk || Information should not be seen or heard by unauthorised people 
+--- | --- | ---
+. | Sensitive | Don't leave papers lying around; lock your screen when you leave it; don't have conversations or phone calls in public places.
+. | Highly Sensitive | Keep paper under lock and key; password-protect individual files; have conversations only in private offices.
+
+
+# Related
+
+Related ISO 27x:2022 controls:
+- 5.12 Classification of information
+- 5.10 Acceptable use of information and other associated assets
+- 5.13 Labelling of information
+- 5.14 Information transfer
+- 5.15 Access control

Corpus/ISMS/Disaster Recovery Planning.md

@@ -0,0 +1,9 @@
+# Disaster Recovery Planning
+
+See also:
+- [a-5.30-ICT-readiness-for-business-continuity](../Standards/ISO27x/OST/27002/EN/a-5.30-ICT-readiness-for-business-continuity.md)
+- [Business Continuity Planning (BCP)](../📚️%20Literature%20notes/BCP_Bedrijfscontinuïteitsplanning.md)
+- [SANS Incident Response step 5 Recovery](../Standards/SANS/SANS%20Incident%20Response%20step%205%20Recovery.md)
+- [Checklist for auditing Business Continuity and Disaster Recovery](../Literature/Checklists%20Gerardus%20Blokdyk/Checklist%20for%20auditing%20Business%20Continuity%20and%20Disaster%20Recovery.md)
+- [CISSP_OSG_Chapter_18](../Standards/CISSP/CISSP_OSG_Chapter_18.md)
+- [Def_Sec_Handbook_Chapter_6](../Literature/Defensive%20Security%20Handbook/Def_Sec_Handbook_Chapter_6.md)

Corpus/ISMS/Functiescheiding Typologie Starreveld.md

@@ -0,0 +1,11 @@
+# Functiescheiding: Typologie Starreveld
+
+Voor fysieke assets zou de Typologie Starreveld gebruikt kunnen worden
+https://www.typologiestarreveld.nl/controletechnische-functiescheiding/
+
+1. Een medewerker mag binnen een proces slechts een deel van de schakels beïnvloeden. Zo kan de *volgende* medewerker geen transactie doen, zonder dat er eerst geregistreerd is.
+2. Opdracht geven (’beschikken’) over waardevolle goederen moet gescheiden zijn van de bewarende functie (voorraadbeheer)
+3. De voorraad wordt gecontroleerd door een andere medewerker dan de ‘bewaarder’.
+
+M.m. Kan je dit ook toepassen op informatie. Als je de informatie asset ziet als het waardevolle goed en de logging als de registratie. Degene die toegang heeft tot de de database mag niet ook toegang hebben tot de ligging. 
+[Google](https://www.google.nl/search?q=accountancy+administrative+organization+principle+behind+segregation+of+duties&ie=UTF-8&oe=UTF-8&hl=en-nl&client=safari) op accountancy administrative organization principle behind segregation of duties

Corpus/ISMS/How to develop an Asset Inventory.md

@@ -0,0 +1,46 @@
+# How to develop an asset inventory
+
+https://www.isms.online/iso-27001/how-to-develop-an-asset-inventory-for-iso-27001/
+
+Relevant ISO 27001 clauses/controls:
+- [ISO 27001 A 8.1.1 Inventory of assets](../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001%20A%208.1.1%20Inventory%20of%20assets.md)
+- [ISO 27001 C 6.1.2 Information security risk assessment](../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001%20C%206.1.2%20Information%20security%20risk%20assessment.md)
+
+See also:
+- [Assets, Vulnerabilities, Threats, Risks](../Information%20Security/Risks/Assets,%20Vulnerabilities,%20Threats,%20Risks.md)
+
+
+# 3D Asset Inventory
+
+The criticality of an asset can be defined as the **impact of compromise** on the 3 aspects of Confidentiality, Integrity and Availability.
+
+E.g.:
+
+Asset | Confidentiality | Integrity | Availability
+----- | --- | --- | ---
+Public website | 0 | 2 | 3
+Password file | 3 | 2 | 3
+Debtors info | 3 | 3 | 1
+
+We can also assess the **probability of compromise**  on the same 3 aspects:
+
+Asset | Confidentiality | Integrity | Availability
+----- | --- | --- | ---
+Public website | 0 | 2 | 1
+Password file | 1 | 1 | 2
+Debtors info | 1 | 2 | 1
+
+Now we can calculate the Risk Score as Impact times Probability for each of the 3 aspects:
+
+Asset | Confidentiality | Integrity | Availability
+----- | --- | --- | ---
+Public website | 0 | 4 | 3
+Password file | 3 | 2 | 6
+Debtors info | 3 | 6 | 3
+
+
+This would lead to the following priority list for risk mitigation:
+1. Integrity of Debtors info
+2. Availability of Password file
+3. Integrity of Public website
+4. etc.

Corpus/ISMS/ISMS audit flags.md

@@ -0,0 +1,10 @@
+# ISMS audit flags
+
+This guideline supports practitioners conducting audits of Information Security Management Systems (ISMSs) built on ISO/IEC 27001. It provides practical reference material organised around two complementary audit tools: green flags — the evidence and documentation an auditor should expect to find in a functioning ISMS — and red flags — the indicators that signal a dysfunctional, failing, or nonconformant system.
+
+The guideline does not prescribe how to audit, nor does it address the content of individual security controls. Its scope is the management system itself: whether it is properly designed, genuinely operating, and delivering value to the organisation. Because ISO/IEC 27001 is deliberately broad in its requirements, this document fills the interpretive gap with experience-based guidance on what adequate evidence looks like in practice, and what warning signs are worth investigating further.
+
+Intended primarily for internal auditors and certification auditors working with ISO/IEC 27001-based ISMSs, it is also relevant to those assessing information service providers such as cloud and managed security vendors. The guidance draws on four decades of practitioner experience and is offered as a supplement to — not a replacement for — formal audit checklists and professional judgement.
+
+![](SecAware%20ISMS%20audit%20flags.docx)
+

Corpus/ISMS/Ideas about enforcement.md

@@ -0,0 +1,14 @@
+# 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)

Corpus/ISMS/Ideas on Risk Ownership.md

@@ -0,0 +1,28 @@
+# Ideas on Risk Ownership
+
+As far as conformity with '27001 goes, risk owners must be identified within the information security risk assessment process as per 6.1.2 c) 2), and risk owners must approve risk treatment plans and acceptance of residual risks as per 6.1.3 f).   
+
+However, 27001 does not specify how they are to be identified, nor what their obligations or expectations might be beyond those noted in 6.1.3 f).  
+
+So, aside from that, we have the discretion to do whatever works best for our organisations - perhaps formally define the role, nominate people or functions or departments, prepare a policy and procedure, or whatever we like really.  Or not: remember that if you have a policy or procedure within your ISMS, you are naturally expected to do what it says, consistently.  So, be careful with the wording, operation, oversight and assurance.
+
+This is a governance matter for senior management.  It is tricky for anyone other than them to insist that workers (including management generally) do anything, especially if it means they are personally accountable for any failings, and implies giving them the authority and resources to 'make it so'.  
+
+ISO/IEC 27005 defines 'risk owner' succinctly as the “Person or entity with the accountability and authority to manage a risk”, summing it up nicely.
+ISO 27005:2022 Clause 3.1.5: **risk owner =** person or entity with the accountability and authority to manage a _risk_
+
+I define 'risk owner' as the "Organisation, rôle or person who notionally ‘owns’ and may be held to account if a risk eventuates, causing unacceptable impacts, on the basis that they patently failed to ensure it was adequately treated e.g. mitigated with controls.  As the explicit or implicit owner of residual risk, they also have an interest in the incident management and business continuity arrangements."
+By the way, 'risk owner' is just one example or application of the general concept of 'ownership'.  Some others include: asset owner, control owner, data owner, information owner, infrastructure owner, network owner, process owner, system owner, service owner and problem owner.  SImilar considerations can apply to them all, particularly the ideas that the nominal owners should be (a) trusted agents or custodians for the true legal owners, acting on their behalf and protecting their interests; and (b) personally accountable for the associated decisions, actions or inactions etc., motivating them to achieve the true owners' expectations or requirements.  
+
+In specifying your ISMS-related governance arrangements, I would caution against going too far beyond the standard's requirements unless: 
+
+(a) you have good business reasons for doing so, 
+
+(b) management is fully aware of and agrees to the arrangements including the implications on resourcing, oversight, roles and responsibiltiies, accountability etc., and 
+
+(c) you are prepared to ensure that the arrangements are actually going to be used consistently as specified - in order to avoid nonconformities being raised by the auditors.        
+
+**Hinson tip**: using weasel-words such as "as appropriate", "if justified" or "should" rather than "shall" or "must" in your strategies, policies and procedures leaves a little room for management discretion to cope with particular circumstances, and yet still conform.  Reserve the "shalls" and "musts" for those situations where there really is absolutely no choice (although, even there, you _may_ have a mechanism for management to authorise specific exemptions, explicitly accepting the associated risks).   This approach also leaves _you_ some leeway to adjust the management controls later, tightening or relaxing them based on experience - all part of ISMS maturity.
+
+Kind regards/Ngā mihi,
+Gary

Corpus/ISMS/Implementing Segregation of Duties ISACA.md

@@ -0,0 +1,43 @@
+[Source](https://www.isaca.org/resources/isaca-journal/issues/2016/volume-3/implementing-segregation-of-duties-a-practical-experience-based-on-best-practices) [PDF download](https://www.isaca.org/-/media/files/isacadp/project/isaca/articles/journal/2016/volume-3/implementing-segregation-of-duties_joa_eng_0516.pdf)
+Article in ISACA Journal
+**Author:** Stefano Ferroni
+**Date Published:** 19 May 2016
+Retrieved: July 13, 2022
+
+See also:
+- [Roles and Responsibilities](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)
+
+The most widely adopted SoD model requires separation between authorization (AUT), custody (CUS), recording (REC) and verification (VER).
+
+Ideally, these duties are performed by different persons (or parties). 
+
+![](SOD%20functions%20diagram.jpg)
+
+This model is consistent with the COBIT 5 view of SoD issues (DSS06.03).
+
+This can be hard, or even impossible to implement in practice. 
+
+Often, agents may perform different duties on the same assets as long as they are authorized by a second person. An example is an accounts payable team receiving invoices (REC) *and* creating payment orders (CUS) after authorization by the manager (AUT). 
+
+In the example where an online recording operation creates an automatic payment, such segregation is simply impossible to achieve.
+
+An SOD framework should also make a distinction between management duties (e.g., granting and revoking rights, reporting, and managing exceptions) and governance duties (evaluating, directing and monitoring SoD rules and practices).
+
+### Risk assessment
+For risk assessment, a matrix can be constructed for every combination of conflicting duties, with associated risk scenario examples:
+
+![](SOD%20risk%20scenario%20matrix.jpg)
+
+### Scoping rules
+- Asset Scoping: different duties may be performed by the same person (or team), as long as they do not involve the same asset (or set of assets).
+- Process scoping: for any asset (or set of assets), processes that transform the status of that asset must be segregated. 
+
+### Role engineering
+For defining role-based privileges, as used in Role-based Access Control (RBAC) top-down and bottom-up approaches are used. Top-down means identifying the necessary privileges from the job description, bottom-up means inferring roles by examining existing permissions on systems and applications (also known as role mining).
+
+### Downloaded copy of document in Attachments folder
+
+![](Implementing%20Segregation%20of%20Duties%20ISACA%20PDF.pdf)
+

Corpus/ISMS/KPIs in Incident Response.md

@@ -0,0 +1,72 @@
+---
+tags:
+  - metrics
+Related:
+  - "[ISO_27002_2022_5.24_PE Information security incident management planning and preparation](../../../iso27DIY-gis/reference/Paraphrased/ISO27002-2022-EN/ISO_27002_2022_5.24_PE%20Information%20security%20incident%20management%20planning%20and%20preparation.md)"
+---
+# KPIs in Incident Response
+
+Here are 20 essential KPIs, with short definitions to guide your tracking and improvement efforts:
+
+1. Mean Time to Detect (MTTD): Avg. time taken to identify an incident.
+
+
+2. Mean Time to Respond (MTTR): Avg. time between detection and first mitigation action.
+
+
+3. Mean Time to Contain (MTTC): Avg. time to stop the incident from spreading.
+
+
+4. Mean Time to Resolve (MTTRv): Avg. time to fully fix and close the incident.
+
+
+5. Number of Incidents Detected: Total incidents identified in a time period.
+
+
+6. Percentage of Incidents by Severity Level: Distribution of incidents by criticality.
+
+
+7. First Response Time: Time from detection to initial analyst response.
+
+
+8. Number of Reopened Incidents: Count of incidents reopened after closure.
+
+
+9. False Positive Rate: Percentage of alerts flagged as incidents that weren’t real.
+
+
+10. Detection Accuracy: Ratio of true positives to total alerts.
+
+
+11. SLA Compliance Rate: % of incidents resolved within agreed SLA timelines.
+
+
+12. Incident Recurrence Rate: Rate at which similar incidents reoccur.
+
+
+13. User-Reported vs. System-Detected Incidents: Comparison of manually vs. automatically detected issues.
+
+
+14. Cost per Incident: Average financial impact of each incident.
+
+
+15. Time to Escalation: Time from detection to escalation to a higher tier/team.
+
+
+16. Incident Closure Rate: % of incidents resolved within a defined period.
+
+
+17. Incident Root Cause Categories: Classification of underlying causes.
+
+
+18. Volume of Phishing/Malware/Ransomware Incidents: Count of incidents by type.
+
+
+19. Percentage of Automated vs. Manual Responses: Share of responses handled automatically.
+
+
+20. Resolution SLA Breach Rate: % of incidents resolved after SLA deadlines.
+
+
+
+Tracking these helps teams reduce downtime, improve security posture, and meet business expectations.

Corpus/ISMS/Labeling of information in the digital domain.md

@@ -0,0 +1,37 @@
+[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]]
+
+[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]]

Corpus/ISMS/Mandatory documentation in ISO 27001.md

@@ -0,0 +1,14 @@
+In total there are 16 pieces of documented information that every ISMS must create and maintain in order to be eligible for certification.
+
+|   |   |   |   |   |   |
+|---|---|---|---|---|---|
+|Title|Type|Clause|Title|Type|Clause|
+|Scope of the ISMS|Mandatory|4.3|Results of information security risk treatment|Mandatory|8.3|
+|Information security policy|Mandatory|5.2|Results of monitoring and measurement|Mandatory|9.1|
+|Information security risk assessment process|Mandatory|6.1.2|Audit programme|Mandatory|9.2|
+|Information security risk treatment process|Mandatory|6.1.3|Audit results|Mandatory|9.2|
+|Statement of applicability (SoA)|Mandatory|6.1.3|Results of management reviews|Mandatory|9.3|
+|Information security objectives|Mandatory|6.2|Nature of nonconformities and any subsequent actions taken|Mandatory|10.2|
+|Evidence of competence|Mandatory|7.2|Results of any corrective action|Mandatory|10.2|
+|Evidence for processes being carried out as planned|Mandatory|8.1||||
+|Results of information security risk assessments|Mandatory|8.2|||   |

Corpus/ISMS/Metrics for Information Security.md

@@ -0,0 +1,28 @@
+# Metrics for Information Security
+
+[Security Metrics by Andrew Jaquith 2007](../Literature/Jaquith%20-%20Security%20Metrics/Security%20Metrics%20by%20Andrew%20Jaquith%202007.md)
+[Security Metrics that Count – for Twilio](../Literature/Jaquith%20-%20Security%20Metrics/Security%20Metrics%20that%20Count%20–%20for%20Twilio.md)
+[Austin Songer's List of Information Security Metrics to Track](https://songer.pro/list-of-information-security-metrics-to-track/)
+
+
+CISSP study guide (p. 88).:
+When a countermeasure or safeguard is implemented, security metrics should show a reduction in unwanted occurrences or an increase in the detection of attempts. Otherwise, the security mechanism is not providing the expected benefit. The act of measuring and evaluating security metrics is the practice of assessing the completeness and effectiveness of the security program. This should also include measuring it against common security guidelines and tracking the success of its controls. 
+
+Choosing to monitor or measure something the security staff has little control over or that is based on external drivers, can cause significant problems.
+
+W. Krag Brotby and Gary Hinson (PRAGMATIC Security Metrics, 2013) state metrics should be:
+
+- Predictive: They help us deal with situations, make decisions and improve things for the future;
+- Relevant: To the subject matter i.e. information security, governance, risk, compliance, control ...;
+- Actionable: They tell us things that we can actually do something about, apart from saying “Oh that’s nice”!;
+- Genuine: The numbers are fact-based and cannot easily be faked or manipulated for some hidden agenda;
+- Meaningful: To the intended audience/s, without creating a lot of head-scratching and hand-waving;
+- Accurate: Sufficiently true and precise to allow proportional control (not just stop/go but how fast?);
+- Timely: Security is a dynamic area, so we need up-to-date information at the point decisions have to be made;
+- Independent: Measured dispassionately and objectively, based on verifiable evidence; and
+- Cost-effective: Generate more value than they cost to gather, analyze, present and use.
+
+![](../Various/PRAGMATIC_security_metrics_examples.xlsx)
+
+Standards and Frameworks:
+- [ISO 27004](../Standards/ISO27x/ISO%2027004.md)

Corpus/ISMS/Policy examples/Cloud Service Approval Process.md

@@ -0,0 +1,290 @@
+# Cloud Service Approval Process
+
+This comprehensive cloud service approval process provides a structured, rigorous approach to evaluating and implementing cloud services. It balances thorough risk management with the need for technological innovation and operational efficiency.
+
+The process is designed to be:
+
+- Transparent
+- Comprehensive
+- Flexible
+- Collaborative
+
+## 1. Initial Assessment Stage
+
+### 1.1 Preliminary Evaluation Form
+
+Employees must complete a comprehensive initial assessment:
+
+- Detailed business need justification
+- Specific problem the service will solve
+- Current workaround or existing solution limitations
+- Estimated productivity or efficiency gains
+- Anticipated user base within the organization
+
+### 1.2 Initial Screening Criteria
+
+Mandatory initial checks:
+
+- Alignment with organizational strategic objectives
+
+- Compatibility with existing IT infrastructure
+
+- Preliminary compliance with data protection regulations
+
+- Basic security feature assessment
+
+  
+
+## 2. Detailed Risk Assessment
+
+  
+
+### 2.1 Security Evaluation Checklist
+
+Comprehensive security review including:
+
+- Data encryption standards (at rest and in transit)
+
+- Authentication mechanisms
+
+- Access control capabilities
+
+- Compliance certifications (GDPR, HIPAA, etc.)
+
+- Data residency and sovereignty details
+
+- Vendor security history and reputation
+
+  
+
+### 2.2 Financial and Operational Analysis
+
+Evaluation of:
+
+- Total cost of ownership
+
+- Scalability options
+
+- Integration capabilities
+
+- Service level agreements (SLAs)
+
+- Exit strategy and data portability
+
+- Long-term vendor viability
+
+  
+
+## 3. Formal Review Process
+
+  
+
+### 3.1 Review Committee Composition
+
+Cross-functional review team including:
+
+- IT Security Representative
+
+- Data Protection Officer
+
+- Finance Representative
+
+- Department Head
+
+- Compliance Officer
+
+  
+
+### 3.2 Detailed Review Stages
+
+1. Initial document review
+
+2. Vendor presentation and Q&A
+
+3. Technical demonstration
+
+4. Reference and background check
+
+5. Comprehensive risk scoring
+
+  
+
+## 4. Technical Evaluation
+
+  
+
+### 4.1 Technical Architecture Review
+
+Comprehensive technical assessment:
+
+- API and integration capabilities
+
+- Performance benchmarking
+
+- Compatibility testing
+
+- Security penetration testing
+
+- Data migration potential
+
+- Interoperability assessment
+
+  
+
+### 4.2 Technical Validation Criteria
+
+- Minimum security score threshold
+
+- Compliance with organizational technical standards
+
+- Minimal disruption to existing systems
+
+- Scalable and future-proof architecture
+
+  
+
+## 5. Compliance and Legal Verification
+
+  
+
+### 5.1 Regulatory Compliance Check
+
+Verification of:
+
+- Data protection regulations
+
+- Industry-specific compliance requirements
+
+- International data transfer regulations
+
+- Terms of service legal review
+
+  
+
+### 5.2 Data Handling Assessment
+
+Detailed examination of:
+
+- Data ownership clauses
+
+- Information sharing policies
+
+- User data management practices
+
+- Breach notification protocols
+
+  
+
+## 6. Decision-Making Framework
+
+  
+
+### 6.1 Risk Scoring Matrix
+
+Quantitative evaluation across dimensions:
+
+- Security risk (0-10 scale)
+
+- Compliance risk (0-10 scale)
+
+- Operational impact (0-10 scale)
+
+- Financial implications (0-10 scale)
+
+  
+
+### 6.2 Approval Thresholds
+
+- Total score requirements
+
+- Mandatory mitigation for high-risk areas
+
+- Conditional approval mechanisms
+
+  
+
+## 7. Implementation and Monitoring
+
+  
+
+### 7.1 Pilot Implementation
+
+- Limited initial deployment
+
+- Controlled user group testing
+
+- Continuous monitoring
+
+- Performance and security validation
+
+  
+
+### 7.2 Ongoing Compliance Monitoring
+
+- Quarterly security reassessment
+
+- Annual comprehensive review
+
+- Continuous vendor performance tracking
+
+  
+
+## 8. Documentation and Governance
+
+  
+
+### 8.1 Comprehensive Documentation
+
+- Detailed approval documentation
+
+- Risk mitigation strategies
+
+- Implementation plan
+
+- Ongoing monitoring protocol
+
+  
+
+### 8.2 Knowledge Management
+
+- Update organizational cloud service catalog
+
+- Share learning and insights
+
+- Maintain vendor performance records
+
+  
+
+## 9. Rejection and Appeal Process
+
+  
+
+### 9.1 Rejection Notification
+
+- Detailed explanation of decision
+
+- Specific improvement recommendations
+
+- Alternative solution suggestions
+
+  
+
+### 9.2 Appeal Mechanism
+
+- Formal appeal process
+
+- Additional information submission
+
+- Secondary review option
+
+  
+
+## Appendices
+
+- Detailed Evaluation Form Template
+
+- Risk Assessment Scoring Rubric
+
+- Compliance Verification Checklist
+
+- Vendor Performance Tracking Template

Corpus/ISMS/Policy examples/Cloud Service Employee Guidelines.md

@@ -0,0 +1,374 @@
+# Employee Guidelines for Cloud Service
+
+  
+
+These guidelines provide a comprehensive, employee-centric approach to cloud service management. The framework emphasizes:
+
+  
+
+Collaborative decision-making
+
+Robust security practices
+
+Continuous learning
+
+Organizational risk management
+
+  
+
+The guidelines position the IT department as a consultative partner, supporting employees through the entire cloud service lifecycle.
+
+  
+  
+
+## 1. Identification of Need
+
+  
+
+### 1.1 Initial Assessment
+
+Before seeking a cloud service, employees must:
+
+- Clearly define the specific business problem
+
+- Confirm no existing internal solution exists
+
+- Understand the precise requirements
+
+- Consult with team members about potential solutions
+
+  
+
+### 1.2 Preliminary Consultation
+
+- Schedule an initial discussion with IT department
+
+- Prepare a brief outlining:
+
+* Current workflow challenges
+
+* Desired functionality
+
+* Expected outcomes
+
+* Potential user group
+
+  
+
+## 2. Pre-Selection Research
+
+  
+
+### 2.1 Initial Exploration
+
+Employees should:
+
+- Conduct initial market research
+
+- Identify 3-5 potential cloud service solutions
+
+- Gather preliminary information about:
+
+* Core features
+
+* Pricing models
+
+* Basic security capabilities
+
+* User reviews and reputation
+
+  
+
+### 2.2 Preliminary IT Consultation
+
+- Share research findings with IT department
+
+- Seek initial guidance on potential solutions
+
+- Understand organizational technology landscape
+
+- Discuss integration possibilities
+
+  
+
+## 3. Detailed Evaluation
+
+  
+
+### 3.1 Comprehensive Assessment Criteria
+
+Evaluate potential services against:
+
+- Security capabilities
+
+- Data protection mechanisms
+
+- Compliance requirements
+
+- Integration potential
+
+- Total cost of ownership
+
+- Scalability
+
+- User experience
+
+  
+
+### 3.2 Documentation Requirements
+
+Prepare a detailed evaluation document including:
+
+- Detailed feature comparison
+
+- Potential risks and mitigations
+
+- Business case justification
+
+- Expected return on investment
+
+- Proposed implementation strategy
+
+  
+
+## 4. Approval Process
+
+  
+
+### 4.1 Formal Submission
+
+Submit a comprehensive proposal to IT department:
+
+- Completed evaluation document
+
+- Proposed solution
+
+- Detailed implementation plan
+
+- Risk mitigation strategies
+
+  
+
+### 4.2 Collaborative Review
+
+- Participate in review meetings
+
+- Provide additional context
+
+- Be prepared to discuss alternatives
+
+- Collaborate on refining the proposal
+
+  
+
+## 5. Onboarding and Implementation
+
+  
+
+### 5.1 Pre-Implementation Preparation
+
+Before service activation:
+
+- Attend mandatory training sessions
+
+- Complete security awareness briefing
+
+- Understand data handling protocols
+
+- Review service-specific guidelines
+
+  
+
+### 5.2 Initial Configuration
+
+Employees must:
+
+- Work with IT to configure service
+
+- Implement recommended security settings
+
+- Create service-specific access protocols
+
+- Document initial configuration
+
+  
+
+## 6. Ongoing Usage Guidelines
+
+  
+
+### 6.1 Data Handling
+
+Strict protocols for:
+
+- Protecting sensitive information
+
+- Avoiding unauthorized data sharing
+
+- Using only approved data fields
+
+- Maintaining confidentiality
+
+  
+
+### 6.2 Access Management
+
+- Use only authorized accounts
+
+- Implement strong authentication
+
+- Regularly review access permissions
+
+- Immediately report suspicious activities
+
+  
+
+### 6.3 Continuous Compliance
+
+- Stay informed about service updates
+
+- Attend periodic compliance training
+
+- Participate in regular security reviews
+
+- Report potential compliance risks
+
+  
+
+## 7. Performance Monitoring
+
+  
+
+### 7.1 Usage Tracking
+
+- Maintain usage logs
+
+- Participate in periodic reviews
+
+- Provide feedback on service effectiveness
+
+- Report performance issues promptly
+
+  
+
+### 7.2 Continuous Improvement
+
+- Suggest potential enhancements
+
+- Participate in optimization discussions
+
+- Share insights about workflow improvements
+
+  
+
+## 8. Decommissioning Process
+
+  
+
+### 8.1 Preliminary Evaluation
+
+Determine decommissioning need based on:
+
+- Changing business requirements
+
+- Performance issues
+
+- Cost-effectiveness
+
+- Technological obsolescence
+
+  
+
+### 8.2 Formal Decommissioning Procedure
+
+Steps for responsible service retirement:
+
+1. Notify IT department
+
+2. Conduct comprehensive data audit
+
+3. Develop data migration strategy
+
+4. Execute secure data extraction
+
+5. Confirm complete data removal
+
+6. Formally terminate service agreement
+
+  
+
+### 8.3 Knowledge Transfer
+
+- Document lessons learned
+
+- Share insights with team
+
+- Update organizational knowledge base
+
+  
+
+## 9. Potential Consequences of Non-Compliance
+
+  
+
+### 9.1 Risks of Unauthorized Usage
+
+- Potential security breaches
+
+- Compliance violations
+
+- Financial risks
+
+- Disciplinary actions
+
+  
+
+### 9.2 Escalation Process
+
+- Initial warning
+
+- Mandatory retraining
+
+- Potential access restrictions
+
+- Performance management implications
+
+  
+
+## 10. Support and Resources
+
+  
+
+### 10.1 IT Department Support
+
+- Dedicated support channels
+
+- Quick response mechanisms
+
+- Continuous guidance
+
+- Regular training opportunities
+
+  
+
+### 10.2 Additional Resources
+
+- Internal knowledge base
+
+- Regular workshops
+
+- Peer support networks
+
+- Comprehensive documentation
+
+  
+
+## Appendices
+
+- Evaluation Form Template
+
+- Risk Assessment Checklist
+
+- Approved Services List
+
+- Contact Information for Support

Corpus/ISMS/Policy examples/Cloud Service Risk Assessment Guide.md

@@ -0,0 +1,187 @@
+# Cloud Service Risk Assessment Guide
+
+  
+
+## Purpose
+
+This guide provides a simple, straightforward approach for non-technical employees to evaluate the safety and appropriateness of cloud services before use.
+
+  
+
+## The 10-Step Risk Assessment Checklist
+
+  
+
+### 1. Identify the Business Need
+
+- Clearly define why you need this service
+
+- Ask yourself: "Does this solve a specific work problem?"
+
+- Confirm no existing internal solution exists
+
+- Ensure the need is legitimate and work-related
+
+  
+
+### 2. Check Data Protection Basics
+
+- Identify what type of data you'll be storing
+
+- Assess sensitivity (personal, confidential, or public information)
+
+- Ask the provider: "How do you protect my data?"
+
+- Look for clear, understandable data protection statements
+
+  
+
+### 3. Verify Vendor Credibility
+
+- Research the company's reputation
+
+- Check how long they've been in business
+
+- Look for customer reviews from similar organizations
+
+- Investigate any past security incidents
+
+  
+
+### 4. Understand Data Ownership
+
+- Read the terms of service carefully
+
+- Confirm who owns the data you upload
+
+- Check if the vendor can use your data
+
+- Ensure you can retrieve or delete your data easily
+
+  
+
+### 5. Assess Access and Authentication
+
+- Evaluate login security features
+
+- Check if multi-factor authentication is available
+
+- Understand how access can be controlled
+
+- Verify you can manage user permissions
+
+  
+
+### 6. Compliance Check
+
+- Confirm the service meets relevant regulations
+
+- Check for industry-specific certifications
+
+- Verify data storage locations
+
+- Ensure compliance with organizational policies
+
+  
+
+### 7. Financial and Operational Transparency
+
+- Understand full cost implications
+
+- Check for hidden fees
+
+- Assess service reliability
+
+- Review service level agreements (SLAs)
+
+  
+
+### 8. Integration and Exit Strategy
+
+- Determine how the service fits with existing tools
+
+- Check data migration capabilities
+
+- Understand process for leaving the service
+
+- Ensure easy data export options
+
+  
+
+### 9. Consult IT Support
+
+- Share your findings with the IT department
+
+- Request a quick review
+
+- Be open to alternative solutions
+
+- Seek guidance on potential risks
+
+  
+
+### 10. Document and Review
+
+- Complete a brief risk assessment form
+
+- Document your justification
+
+- Keep records of your evaluation
+
+- Plan for periodic service reassessment
+
+  
+
+## Risk Assessment Outcome
+
+  
+
+### Low Risk Indicators
+
+- Clear business need
+
+- Strong data protection
+
+- Reputable vendor
+
+- Transparent terms
+
+- Compliance with policies
+
+  
+
+### High Risk Warning Signs
+
+- Vague data protection
+
+- Unclear ownership terms
+
+- Limited authentication
+
+- Compliance concerns
+
+- Unexpected costs
+
+  
+
+## Appendix: Quick Reference Checklist
+
+- ☐ Business need validated
+
+- ☐ Data protection verified
+
+- ☐ Vendor credibility checked
+
+- ☐ Data ownership understood
+
+- ☐ Access controls assessed
+
+- ☐ Compliance confirmed
+
+- ☐ Costs transparent
+
+- ☐ Integration potential evaluated
+
+- ☐ IT department consulted
+
+- ☐ Documentation completed

Corpus/ISMS/Policy examples/Cloud Service Risk Mitigation Roadmap.md

@@ -0,0 +1,335 @@
+# Cloud Service Risk Mitigation Roadmap
+
+  
+
+This comprehensive roadmap provides a structured, systematic approach to managing the risk associated with unmandated cloud services. The strategy balances:
+
+  
+
+Immediate risk mitigation
+
+Long-term governance
+
+Employee empowerment
+
+Organizational security
+
+  
+
+Key strengths of the approach include:
+
+  
+
+Detailed risk prioritization
+
+Phased implementation
+
+Continuous monitoring
+
+Emphasis on employee education
+
+  
+
+## 1. Discovery and Inventory Phase
+
+  
+
+### 1.1 Comprehensive Service Mapping
+
+- Conduct a full organizational audit to identify all existing cloud services
+
+- Methods of discovery:
+
+* Network traffic analysis
+
+* Employee surveys
+
+* Expense report review
+
+* Active directory and authentication log analysis
+
+* Collaboration with department heads
+
+  
+
+### 1.2 Detailed Inventory Creation
+
+For each identified service, document:
+
+- Service name and provider
+
+- Department of origin
+
+- Primary users
+
+- Data types processed
+
+- Current access mechanisms
+
+- Frequency of use
+
+- Account ownership details
+
+- Potential business criticality
+
+  
+
+## 2. Risk Prioritization Framework
+
+  
+
+### 2.1 Risk Scoring Methodology
+
+Develop a multi-dimensional risk assessment matrix:
+
+  
+
+#### Risk Dimensions (0-10 scale)
+
+1. **Data Sensitivity**
+
+- Personal identifiable information
+
+- Confidential organizational data
+
+- Regulatory compliance exposure
+
+  
+
+2. **Security Vulnerability**
+
+- Authentication mechanisms
+
+- Encryption standards
+
+- Vendor security track record
+
+- Potential data exposure risks
+
+  
+
+3. **Operational Impact**
+
+- Business criticality
+
+- User dependency
+
+- Workflow integration
+
+- Potential disruption risk
+
+  
+
+4. **Compliance Exposure**
+
+- Regulatory requirements
+
+- Data protection laws
+
+- Industry-specific regulations
+
+- Cross-border data transfer risks
+
+  
+
+### 2.2 Prioritization Matrix
+
+Calculate composite risk score:
+
+- High Risk (Score 27-40): Immediate Action Required
+
+- Medium Risk (Score 15-26): Planned Mitigation
+
+- Low Risk (Score 0-14): Monitor and Validate
+
+  
+
+## 3. Immediate Mitigation Strategies
+
+  
+
+### 3.1 High-Risk Services
+
+Urgent intervention steps:
+
+- Immediate access restrictions
+
+- Temporary service isolation
+
+- Rapid data migration
+
+- Emergency account consolidation
+
+- Potential service discontinuation
+
+  
+
+### 3.2 Medium-Risk Services
+
+Structured remediation approach:
+
+- Comprehensive security review
+
+- Implement additional access controls
+
+- Develop migration strategy
+
+- Negotiate improved terms with vendors
+
+- Create standardized usage guidelines
+
+  
+
+### 3.3 Low-Risk Services
+
+Monitoring and validation:
+
+- Periodic security reassessment
+
+- User necessity verification
+
+- Cost-benefit analysis
+
+- Potential consolidation opportunities
+
+  
+
+## 4. Implementation Roadmap
+
+  
+
+### 4.1 Phased Approach
+
+1. **Phase 1 (0-30 days)**
+
+- Complete initial inventory
+
+- Identify and isolate high-risk services
+
+- Develop emergency mitigation plan
+
+- Begin stakeholder communication
+
+  
+
+2. **Phase 2 (31-90 days)**
+
+- Implement access controls
+
+- Migrate critical data
+
+- Develop standardized service selection process
+
+- Conduct comprehensive security training
+
+  
+
+3. **Phase 3 (91-180 days)**
+
+- Complete service rationalization
+
+- Implement new governance framework
+
+- Develop long-term cloud service strategy
+
+- Establish continuous monitoring mechanism
+
+  
+
+## 5. Governance and Compliance
+
+  
+
+### 5.1 Centralized Management Approach
+
+- Create a Cloud Service Governance Committee
+
+- Develop comprehensive cloud service policy
+
+- Implement centralized procurement process
+
+- Establish ongoing review mechanisms
+
+  
+
+### 5.2 Continuous Monitoring
+
+- Quarterly comprehensive reviews
+
+- Automated discovery and tracking tools
+
+- Regular risk reassessment
+
+- Adaptive policy development
+
+  
+
+## 6. Employee Engagement and Education
+
+  
+
+### 6.1 Communication Strategy
+
+- Transparent communication about risks
+
+- Clear explanation of mitigation steps
+
+- Provide alternative, approved solutions
+
+- Create supportive transition environment
+
+  
+
+### 6.2 Training and Support
+
+- Comprehensive security awareness training
+
+- Workshops on responsible technology adoption
+
+- Develop internal knowledge base
+
+- Create support channels for technology selection
+
+  
+
+## 7. Financial Considerations
+
+  
+
+### 7.1 Cost Analysis
+
+- Consolidate existing service subscriptions
+
+- Negotiate enterprise-level agreements
+
+- Identify potential cost savings
+
+- Develop budget for approved services
+
+  
+
+### 7.2 Investment in Governance
+
+- Allocate resources for:
+
+* Monitoring tools
+
+* Training programs
+
+* Governance infrastructure
+
+* Security enhancement
+
+  
+
+## Appendices
+
+- Detailed Risk Assessment Template
+
+- Service Inventory Spreadsheet
+
+- Communication Plan
+
+- Training Materials
+
+- Governance Policy Draft

Corpus/ISMS/Policy examples/Drafting Policies.md

@@ -0,0 +1,6 @@
+# Drafting Policies
+
+[ISO_27002_2022_5.1_PE Policies for information security](../../../../iso27DIY-gis/reference/Paraphrased/ISO27002-2022-EN/ISO_27002_2022_5.1_PE%20Policies%20for%20information%20security.md)
+[Def_Sec_Handbook_Chapter_3](../../Literature/Defensive%20Security%20Handbook/Def_Sec_Handbook_Chapter_3.md)
+[DoD Cybersecurity Policy Chart webpage](https://csiac.org/resources/the-dod-cybersecurity-policy-chart/)
+[DoD Cybersecurity Policy Chart download](https://csiac.org/wp-content/uploads/2022/11/2022-11-21-csiac-dod-cybersecurity-policy-chart.pdf)

Corpus/ISMS/Policy examples/Drafting a Vendor and Product checklist.md

@@ -0,0 +1,27 @@
+# Drafting a Vendor and Product checklist
+
+Related: [Vendor security MoC](..//Vendor%20security%20MoC.md)
+
+ESCROW
+BOM
+
+From [ISO_27002_2022_5.19_PE Information security in supplier relationships](../../../../iso27DIY-gis/reference/Paraphrased/ISO27002-2022-EN/ISO_27002_2022_5.19_PE%20Information%20security%20in%20supplier%20relationships.md) (selection)
+- criteria and procedures for vendor selection, taking the sensitivity of products, services and the information they'll be working with into account. 
+- checking that the vendor has implemented adequate controls for information security, personnel security and physical security
+- processes and procedures the vendor needs to implement for implementing and terminating the product/service in your organization
+- continuity measures in case the vendor is no longer willing or able to supply its products or services
+- return of assets
+- the ownership of what has been developed during the relationship
+- continuation of non-disclosure/confidentiallity agreements
+
+From [ISO_27002_2022_5.21_PE Managing information security in the ICT supply chain](../../../../iso27DIY-gis/reference/Paraphrased/ISO27002-2022-EN/ISO_27002_2022_5.21_PE%20Managing%20information%20security%20in%20the%20ICT%20supply%20chain.md) (selection)
+
+- require that suppliers demand the same level of security for sub-contractors and product or component suppliers, as you demand of them
+- request a 'bill of materials' for third party software components they use
+- description of security functions in the product, and directions for the correct configuration thereof
+- rules for communicating issues and compromises in the supply chain
+- component lifecycle management, incl. availabilty risks and end-of-service
+- alternative suppliers, software and knowledge transfers
+
+
+

Corpus/ISMS/Policy examples/Dropbox Supplier Security Requirements.md

@@ -0,0 +1,105 @@
+Source: [Github](https://github.com/dropbox/vsmc/blob/master/model-contract.md)
+Retrieved: February 15, 2023
+
+# Dropbox Supplier Security Requirements
+
+These Supplier Security Requirements apply to Supplier when it provides services to Dropbox. Terms used here but not defined here are defined in the Agreement.
+
+
+## 1. Third Party Testing and Validation.
+
+### 1.1. General Testing.
+
+**a. Periodic Tests.** Supplier shall allow Dropbox, or Dropbox’s delegate, to periodically test the security of the Services. When testing Dropbox or its Delegate shall: (i) carefully conduct tests that are reasonably designed to safely uncover possible vulnerabilities without undue risk; and (ii) make commercially reasonable efforts to tailor the tests as needed to specifically achieve the purpose of the test.
+
+**b. Timing.**  Dropbox or its delegate may conduct the security tests in Section 1.1 at any time during the term of the Agreement. Dropbox will: (i) provide Supplier with reasonable notice prior to conducting the tests, (ii) promptly inform Supplier of any findings; and (iii) delay further disclosure until Supplier has had reasonable time to resolve issues identified in the findings.
+
+### 1.2. Vulnerability Disclosure Policy.
+
+**a. Generally.** Supplier shall publish a Vulnerability Disclosure Policy (“VDP”) on its public website. This VDP shall: (i) welcome arbitrary security research; (ii) include all internet facing assets in scope; (iii) provide safe harbor from CFAA and DMCA actions for all good faith research; and (iv) not place restrictions on disclosure. 
+
+**b. Contact and Service Level Agreement.** Supplier shall: (i) post a method by which the public can contact Supplier to report security vulnerabilities; and (ii) use best efforts to respond to these reported security vulnerabilities within a commercially reasonable period of time based on the severity and impact of the vulnerability.
+
+**c. Bug Bounty Program.** Supplier agrees that Dropbox may make deliverables or results of the Services subject to Dropbox’s Bug Bounty Program. Dropbox will notify Supplier of any material security-related vulnerabilities in the Services or deliverables identified through its Bug Bounty Program. Supplier understands that research and disclosures are governed by Dropbox's VDP, which requires good faith and responsible behavior by participants.
+
+### 1.3. Application and Network Penetration Testing.
+
+**a. Annual Testing.** Supplier shall, at least once per year, perform a suite of independent third-party tests. These tests will be performed upon: (i) the Services; (ii) all aspects of Supplier’s internet-facing perimeter; and (iii) Supplier’s internal corporate network and internal systems. Supplier will supply Dropbox with details of all third-party tests from the previous year, including names of third-party testers and number of person hours used.
+
+**b. Sharing Results.** Supplier shall, upon Dropbox’s request and under suitable non-disclosure obligations, share with Dropbox: (i) confirmation that the tests required by this Section 1.3 were performed; and (ii) the third party tests results from Sections 1.3(a)(i) and (ii) above.
+
+### 1.4. Fixing Issues.
+
+Supplier will fix all critical and high severity vulnerabilities that could affect the security of Dropbox Data, of which Supplier becomes aware, within sixty days of becoming aware of the vulnerability. If Supplier cannot fix the vulnerability within sixty days, Supplier will promptly inform Dropbox, including all details of the risk to Dropbox arising from Supplier’s inability to fix the vulnerability.
+
+## 2. Technical Security Measures.
+
+### 2.1. Transport Encryption.
+
+Supplier will maintain an SSL Labs rating (please see https://www.ssllabs.com) of at least “A” for any external website used to store or access Dropbox data. If Supplier’s rating falls below “A,” Supplier will: (a) notify Dropbox if this rating is below “A” for three months; and (b) have three months from the date it notifies Dropbox within which to increase its rating back to an “A.”
+
+### 2.2. Google G Suite Authentication Integration.
+
+If the Services include a SaaS service, Supplier will integrate the Services with Google G Suite authentication for Dropbox’s login needs. This Google G Suite authentication integration will be the only method by which Dropbox users log in to the Service.
+
+### 2.3. Multifactor Authentication.
+
+Supplier will use a multifactor authentication (“MFA”) login solution for the Services, provided that text or phone call are not acceptable factors. MFA must be used for: (a) any VPN connections into the Supplier’s internal networks; (b) any connections into Supplier’s production environment; (c) Supplier’s e-mail, if it can be accessed from the internet; and (d) any services Supplier uses that contain Dropbox Data.
+
+### 2.4. Patching.
+
+Supplier will promptly apply any high or critical severity security patches to their production servers, endpoints, and endpoint management systems. 
+
+### 2.5. Detection and Alerting.
+
+Supplier will proactively monitor, detect, and alert its internal security team regarding suspicious or malicious activity within Supplier’s production and corporate environments. 
+
+### 2.6. Scanning.
+
+Supplier will run regular automated scans against their internet facing perimeter, production perimeter, and internal network. Supplier will promptly fix high and critical severity findings.
+
+### 2.7. Environment Separation and Access.
+
+Supplier will maintain a boundary between its corporate and production environments. Supplier will maintain controls gating access into the production boundary, and Supplier will only provide production environment access to employees or contractors who must maintain the production environment.
+
+## 3. Policy and Compliance.
+
+### 3.1. Security Incidents.
+
+**a. Notification and Timing.** Supplier will notify Dropbox in writing of any Security Incident within seventy-two hours of Supplier becoming aware of the Security Incident. This notification is required even if Supplier has not conclusively established the nature or extent of the Security Incident. Supplier will not communicate with any third party regarding a Security Incident except as specified by Dropbox, or as required by law.
+
+**b. Required Information.** Supplier’s Security Incident notification will describe the known details of the incident, the status of Supplier’s investigation, and, if applicable, the potential number of persons affected. Supplier will be solely responsible for all costs associated with any security breach; which includes, if applicable, for notices to and credit monitoring for affected individuals.
+
+### 3.2. Compliance Certification.
+
+Supplier shall: (a) maintain compliance with at least one of the following: (i) SSAE 16/SOC 1; (ii) SOC 2; or (iii) ISO 27001; (b) provide audit reports or evidence of these certifications to Dropbox upon request; and (c) ensure that all Supplier subcontractors or third party delegates adhere to the same standards. 
+
+### 3.3. Secure Development Lifecycle.
+
+Supplier shall maintain and follow a Secure Development Lifecycle (“SDL”) for the development of its products and services. Supplier’s SDL will be supported by at least one full time security engineer. Supplier will provide Dropbox a copy of its SDL policy and process documents upon request.
+
+### 3.4. Supporting Information.
+
+Upon Dropbox’s request, Supplier will provide its policy and process documents relating to any of the security controls referenced in these Security Requirements to Dropbox.
+
+### 3.5. Handling of Dropbox Data.
+
+Supplier will not move Dropbox Data from Supplier’s production environment unless specifically asked to do so by Dropbox. Specifically, Dropbox Data must not be downloaded to phones or laptops, and must not be shared with third parties. Supplier will delete Dropbox Data permanently upon Dropbox’s request.
+
+## 4. Modifications.
+
+Dropbox may periodically update these Security Requirements by posting a new version. If Dropbox changes these Security Requirements in a manner that materially increases Supplier’s obligations, Dropbox will notify Supplier, and Supplier will have ninety days within which to object to the changes. If Supplier does not object within this timeframe, Supplier agrees to comply with the modified Security Requirements. If Supplier objects within this time frame, and Supplier and Dropbox cannot resolve the objection within thirty days, then Dropbox may terminate the Agreement immediately upon written notice to Supplier.
+
+  
+
+## 5. Definitions.
+
+“Agreement” means the executed Agreement between Supplier and Dropbox.
+
+“Dropbox Data” means any data that is provided to Supplier by Dropbox or on behalf of Dropbox.
+
+“Security Incident” means any: (i) breach or suspected breach of the security of the Services or the systems used to provide the Services that may have resulted in the compromise of Dropbox Data; or (ii) other unauthorized access to or use of Dropbox Data, or Supplier's reasonable belief that access or use may have occurred.
+
+“Services” means the products or services provided by Supplier to Dropbox.
+
+“Suppliers” means those vendors who provide services to Dropbox.

Corpus/ISMS/Policy examples/Example introduction for an Internal Privacy Policy.md

@@ -0,0 +1,19 @@
+From Ultimaker’s Internal Privacy Policy, p.3:
+
+“The Policy is based on the GDPR, which sets out seven principles in Article 5. These are:
+1. Lawfulness, fairness, and transparency
+2. Purpose limitation
+3. Data minimalization
+4. Accuracy
+5. Storage limitation
+6. Integrity and confidentiality (security)
+7. Accountability
+
+To ensure an appropriate level of data protection, we are committed to (p4):
+1. Restrict and monitor access to sensitive data
+2. Develop transparent data collection procedures
+3. Train employees in online privacy and security measures
+4. Build secure networks to protect online data from cyberattacks
+5. Establish clear procedures for reporting privacy breaches or data misuse
+6. Include contract clauses or communicate statements on how we handle data
+7. Establish data protection practices (document shredding, secure locks, data encryption, frequent backups, access authorization etc.)

Corpus/ISMS/Policy examples/Key Topics for a policy on handling classified information.md

@@ -0,0 +1,38 @@
+# Key Topics for a policy on handling classified information
+
+A comprehensive policy on handling classified information should address the following key topics to ensure its security and confidentiality:
+
+1. Classification Levels and Criteria:
+ * Definition of classification levels: Clearly define the different levels of classification (e.g., Top Secret, Secret, Confidential) and their corresponding sensitivity.
+ * Classification criteria: Establish specific criteria for classifying information, such as potential damage to national security, economic interests, or other critical concerns.
+ * Classification authority: Specify who has the authority to classify and declassify information.
+
+2. Access Controls:
+ * Need-to-know principle: Enforce the principle that access to classified information should be granted only to individuals with a genuine need to know.
+ * Security clearances: Implement a rigorous security clearance process to assess the trustworthiness and reliability of personnel handling classified information.
+ * Access controls: Establish robust access controls, including physical, logical, and administrative measures, to restrict access to authorized individuals.
+
+3. Handling and Storage:
+ * Secure handling procedures: Define procedures for handling classified information, such as proper storage, transportation, and destruction.
+ * Secure storage facilities: Specify requirements for secure storage facilities, including controlled access, surveillance, and environmental controls.
+ * Marking and labeling: Mandate clear and consistent marking and labeling of classified documents and electronic media.
+
+4. Communication and Dissemination:
+ * Authorized communication channels: Specify authorized channels for communicating classified information, such as secure networks, encrypted email, or secure physical delivery.
+ * Restrictions on dissemination: Limit the dissemination of classified information to authorized individuals and organizations.
+ * Foreign disclosure: Establish guidelines for disclosing classified information to foreign entities, including appropriate approvals and safeguards.
+
+5. Incident Response:
+ * Incident reporting: Define procedures for reporting security incidents involving classified information, including unauthorized access, loss, or compromise.
+ * Incident response plan: Develop a comprehensive incident response plan to address security breaches, including containment, investigation, and recovery measures.
+ * Damage assessment: Establish procedures for assessing the potential damage caused by a security incident.
+
+6. Training and Awareness:
+ * Mandatory training: Require all personnel with access to classified information to undergo regular security awareness and training.
+ * Training content: Cover topics such as classification levels, handling procedures, security threats, and incident response.
+ * Continuous education: Implement a program of continuous education to keep personnel updated on evolving security threats and best practices.
+
+7. Monitoring and Auditing:
+ * Regular monitoring: Conduct regular monitoring and auditing of systems and processes to identify and address security vulnerabilities.
+ * Access reviews: Periodically review and update access permissions to ensure continued need-to-know.
+ * Security audits: Conduct independent security audits to assess compliance with the policy and identify areas for improvement.

Corpus/ISMS/Policy examples/Shadow IT Policy for Responsible Technology Adoption.md

@@ -0,0 +1,241 @@
+# Shadow IT Policy for Responsible Technology Adoption
+
+  
+
+## 1. Purpose and Principles
+
+  
+
+### 1.1 Policy Objective
+
+This policy aims to:
+
+- Empower employees to make informed technology choices
+
+- Protect the organization's information security
+
+- Foster a culture of responsible technology adoption
+
+- Align technological innovation with organizational goals
+
+  
+
+### 1.2 Guiding Principles
+
+- Transparency
+
+- Collaboration
+
+- Continuous Learning
+
+- Shared Responsibility
+
+- Risk-Aware Decision Making
+
+  
+
+## 2. Employee Responsibilities
+
+  
+
+### 2.1 Technology Evaluation Process
+
+Employees must:
+
+- Conduct a preliminary assessment of any proposed cloud service or software
+
+- Complete a standardized Technology Evaluation Form before implementing new tools
+
+- Demonstrate how the proposed technology:
+
+* Addresses a specific business need
+
+* Improves operational efficiency
+
+* Complies with organizational standards
+
+  
+
+### 2.2 Risk Assessment
+
+Prior to adopting any new technology, employees must evaluate:
+
+- Data protection capabilities
+
+- Compliance with relevant regulations
+
+- Potential security vulnerabilities
+
+- Integration with existing systems
+
+- Total cost of ownership
+
+  
+
+### 2.3 Mandatory Consultation
+
+Employees must:
+
+- Consult with the IT department before implementing new technologies
+
+- Provide a comprehensive justification for the proposed solution
+
+- Participate in a collaborative review process
+
+- Be open to alternative recommendations
+
+  
+
+## 3. IT Department's Consultative Role
+
+  
+
+### 3.1 Support Framework
+
+The IT department will:
+
+- Provide guidance, not gatekeeping
+
+- Offer rapid response to technology adoption requests
+
+- Maintain a current catalog of approved and recommended tools
+
+- Develop clear, accessible guidelines for technology selection
+
+  
+
+### 3.2 Consultation Process
+
+IT will:
+
+- Review technology proposals within 5 business days
+
+- Provide constructive feedback
+
+- Suggest security and integration improvements
+
+- Collaborate on finding optimal solutions
+
+  
+
+### 3.3 Ongoing Support
+
+- Offer regular training on technology evaluation
+
+- Maintain an internal knowledge base of approved and vetted tools
+
+- Provide templates and checklist for technology assessment
+
+  
+
+## 4. Approval and Documentation
+
+  
+
+### 4.1 Documentation Requirements
+
+Employees must document:
+
+- Business justification
+
+- Detailed risk assessment
+
+- Proposed implementation strategy
+
+- Data handling and protection measures
+
+  
+
+### 4.2 Approval Workflow
+
+1. Employee completes Technology Evaluation Form
+
+2. Initial review by immediate supervisor
+
+3. Consultation with IT department
+
+4. Final approval by department head and IT representative
+
+  
+
+## 5. Continuous Improvement
+
+  
+
+### 5.1 Periodic Review
+
+- Quarterly review of adopted technologies
+
+- Annual policy and process refinement
+
+- Feedback collection from employees
+
+  
+
+### 5.2 Learning and Development
+
+- Regular workshops on technology trends
+
+- Sharing of best practices
+
+- Recognition of innovative technology solutions
+
+  
+
+## 6. Consequences of Non-Compliance
+
+  
+
+### 6.1 Potential Actions
+
+- Temporary suspension of unauthorized technology use
+
+- Mandatory retraining
+
+- Potential disciplinary action for repeated violations
+
+  
+
+### 6.2 Escalation Process
+
+- Written warning
+
+- Performance review impact
+
+- Potential removal of technology adoption privileges
+
+  
+
+## 7. Technology Adoption Incentives
+
+  
+
+### 7.1 Recognition Program
+
+- Acknowledge employees who:
+
+* Identify cost-effective solutions
+
+* Demonstrate thorough risk assessment
+
+* Innovate through responsible technology adoption
+
+  
+
+### 7.2 Career Development
+
+- Include technology evaluation skills in performance metrics
+
+- Create opportunities for technology champions
+
+  
+
+## Appendices
+
+- Technology Evaluation Form Template
+
+- Approved Tools List
+
+- Risk Assessment Checklist
+
+- Compliance Guideline References

Corpus/ISMS/Policy examples/Voorbeeld van een release script.md

@@ -0,0 +1,38 @@
+*Voorbeeld van een artefact voor [A8.25 Secure development life cycle](../../MoCs/ISO_27002_2022_8.25_MoC%20Secure%20development%20life%20cycle.md)*
+
+Bron: Normity
+
+Omdat we werken met Kanban bepalen we zelf wanneer we een release gaan laten plaatsvinden. Dit doen we eventueel in overleg met de stakeholders en wordt per release bepaald. Gemiddeld genomen doen we dit eenmaal per 4 weken met regelmatige tussentijdse kleinere releases. De PO bepaalt uiteindelijk wanneer de release plaatsvindt. Hotfixes volgen deze procedure niet, maar hebben een eigen release proces. Omdat deze over het algemeen zeer klein zijn, wordt dit van geval tot geval bepaald.
+
+Hoe gaat zo'n release nu in zijn werk?
+
+- Zorg dat alle issues die meegaan gemerged zijn naar Develop branch
+
+- Doe een laatste controle op de code:
+	- Hebben alle JSON taalbestanden hetzelfde aantal regels
+	- Zijn er geen dumps of aborts meer te vinden in de code
+	- Draai vertalingenControleren.cfm of vertalingen ontbreken
+
+- Maak de nieuwe Master branch
+
+- Controleer nu eerst of de benodigde omgevingen beschikbaar zijn:
+	- SQL Server toegang
+	- Royal TS toegang
+
+- Zorg er nu voor dat de code online komt te staan:
+	- Draai alle scripts in de SQL Server omgeving
+	- Doe een pull van de code op de server
+	- Herstart Normity (zowel demo als normity docker)
+	- Doe een korte controle
+
+- Is het een nieuw versienummer? Doe dan:
+	- Doorloop de stories uit de release
+	- Stel de release notes op
+	- Voeg die toe via de beheerschermen
+
+- Tenslotte nog even de code klaarmaken voor de nieuwe release:
+	- Maak Jira board gereed voor nieuwe release
+	- Verwijder overbodige feature branches
+	- Verplaats de bijbehorende SQL bestanden van _assets/scripts/features naar _assets/scripts/x.x.x/
+	- Maak een nieuwe branch aan voor de nieuwe release
+	- Wijzig eventueel het versienummer in Application.cfc

Corpus/ISMS/Policy examples/Vulnerability Disclosure Policy.md

@@ -0,0 +1,5 @@
+Having a permissive vulnerability disclosure policy (VDP) encourages security research, and is a key characteristic of a good, mature security program. It encourages transparency.
+
+For you as a vendor, it enhances [Vendor security MoC](../Vendor%20security%20MoC.md) towards your customers.
+As a customer, you may check for a VDP when creatingyour [Examples of vendor selection questionnaires](../../Information%20Security/Examples%20of%20vendor%20selection%20questionnaires.md).
+

Corpus/ISMS/Policy examples/WeWeb Security Pre-Launch Checklist.md

@@ -0,0 +1,105 @@
+# WeWeb Security Pre-Launch Checklist
+
+I've created a comprehensive security checklist that expands on each of your original items. The key principle throughout is that **security must be enforced server-side** - WeWeb (being a frontend no-code platform) can only provide the user interface, while your backend APIs and database must handle all the actual security enforcement.
+
+The most critical point is that you should never trust the client-side for security decisions. Even though WeWeb can hide UI elements or restrict navigation, a determined user could still make direct API calls to bypass these restrictions. That's why server-side validation and authorization are absolutely essential for each of these security measures.
+
+
+## ☐ Restrict User Access
+
+**What this means:** Limit who can access your application and specific features based on authentication status and user roles.
+
+**Implementation pointers:**
+- **Authentication Gates:** Set up proper login/logout flows using WeWeb's authentication workflows
+- **Protected Routes:** Configure page-level access restrictions in WeWeb's router settings
+- **Conditional Rendering:** Use WeWeb's conditional visibility settings to hide/show components based on user authentication status
+- **Session Management:** Implement proper session timeouts and renewal mechanisms
+- **Multi-factor Authentication:** Consider adding 2FA for sensitive applications
+- **IP Whitelisting:** For internal tools, restrict access by IP address ranges
+
+**WeWeb-specific tips:**
+- Use the built-in Auth0, Supabase, or Firebase authentication plugins
+- Set up global variables for user authentication state
+- Configure redirects for unauthenticated users to login pages
+
+---
+
+## ☐ Filter Sensitive Data Server-Side
+
+**What this means:** Never rely on client-side filtering to hide sensitive information. All data filtering must happen on your backend/API before sending to WeWeb.
+
+**Implementation pointers:**
+- **API Endpoint Security:** Create separate API endpoints for different user roles (e.g., `/api/admin/users` vs `/api/users`)
+- **Database Queries:** Use proper WHERE clauses and JOIN conditions to filter data at the database level
+- **Field Selection:** Only return necessary fields in API responses (avoid SELECT * queries)
+- **Data Masking:** For partially sensitive data (like phone numbers), mask on the server before sending
+- **Audit Logging:** Log all data access requests for security monitoring
+
+**WeWeb-specific tips:**
+- Configure your REST API or GraphQL collections with proper filtering parameters
+- Use WeWeb's data source authentication to pass user tokens to your backend
+- Set up different API collections for different user roles
+- Never store sensitive data in WeWeb's browser storage or global variables
+
+---
+
+## ☐ Enforce Access Control on User IDs
+
+**What this means:** Prevent users from accessing or modifying data belonging to other users by manipulating user IDs in requests.
+
+**Implementation pointers:**
+- **Server-Side Validation:** Always validate that the requesting user has permission to access the specified user ID
+- **Token-Based Authorization:** Use JWT tokens or similar to securely identify the current user
+- **Parameter Validation:** Never trust user IDs sent from the client - always cross-reference with authenticated session
+- **Resource Ownership Checks:** Verify that the authenticated user owns or has permission to access the requested resource
+- **Indirect Object References:** Use random tokens or UUIDs instead of sequential IDs where possible
+
+**WeWeb-specific tips:**
+- Pass authenticated user tokens in API headers, not as query parameters
+- Use WeWeb's user context variables to automatically include user IDs in API calls
+- Configure your backend to extract user ID from authenticated tokens, not from request parameters
+- Set up proper error handling for unauthorized access attempts
+
+---
+
+## ☐ Enforce Role-Based Permission Checks
+
+**What this means:** Implement a system where users can only perform actions and access resources appropriate to their assigned roles.
+
+**Implementation pointers:**
+- **Role Definition:** Clearly define roles (admin, user, moderator, etc.) and their associated permissions
+- **Permission Matrices:** Create a clear mapping of which roles can perform which actions
+- **Middleware Implementation:** Use backend middleware to check permissions before processing requests
+- **Granular Permissions:** Consider feature-level permissions (read, write, delete) rather than just role-based access
+- **Dynamic Role Assignment:** Allow for flexible role assignment and modification
+- **Principle of Least Privilege:** Grant users only the minimum permissions necessary for their role
+
+**WeWeb-specific tips:**
+- Store user roles in your backend database, not in WeWeb's local storage
+- Use WeWeb's conditional logic to show/hide UI elements based on user roles
+- Create reusable permission checking functions in WeWeb's custom functions
+- Set up role-based navigation menus and page access
+- Use WeWeb's workflow conditions to restrict form submissions and actions based on user roles
+
+---
+
+## Additional Security Considerations
+
+### Before Launch Checklist:
+- [ ] Test all authentication flows (login, logout, password reset)
+- [ ] Verify that unauthenticated users cannot access protected content
+- [ ] Test user impersonation scenarios (can users access other users' data?)
+- [ ] Validate that sensitive operations require appropriate permissions
+- [ ] Check that error messages don't leak sensitive information
+- [ ] Ensure HTTPS is enforced for all communications
+- [ ] Review and test all API endpoints for proper authorization
+- [ ] Validate input sanitization to prevent injection attacks
+- [ ] Test session management and timeout behaviors
+- [ ] Review third-party integrations for security compliance
+
+### Ongoing Security Practices:
+- Regular security audits and penetration testing
+- Monitor authentication logs for suspicious activity
+- Keep all dependencies and frameworks updated
+- Implement proper backup and disaster recovery procedures
+- Regular review and update of user permissions and roles

Corpus/ISMS/Qualifying vs quantifying risks.md

@@ -0,0 +1,13 @@
+# Qualifying vs quantifying risks
+
+**Qualifying risks** (qualitative risk assessment) involves describing and categorizing risks using descriptive scales or labels—such as rating likelihood as "low, medium, high" and impact as "minor, moderate, severe"—focusing on understanding the nature and relative severity of risks without precise numerical values.
+
+**Quantifying risks** (quantitative risk assessment) involves measuring risks using specific numerical values—such as calculating the probability as a percentage (e.g., 15% chance per year) and impact in monetary terms (e.g., €50,000 loss)—providing precise, measurable data that can be used for detailed cost-benefit analysis and statistical modeling.
+
+Clause 6.1.2 writes we should "assess the potential consequences" and "realistic likelihood" of risks occurring, but the standard doesn't say anything about *how* these should be established (just that that the chosen method must produce "consistent, valid and comparable results").
+
+The core _requirements_ in ISO/IEC 27001 remain method-agnostic as long as the steps above are met and results are consistent and comparable.
+
+The organization must set its own criteria for determining risk levels and risk acceptance criteria. The organization defines these elements based on its specific needs, size, structure, objectives, and risks.
+
+The standard does not say anything about if qualitative or quantitative risk assessment should be applied.

Corpus/ISMS/RASCI Matrix.md

@@ -0,0 +1,39 @@
+# RASCI matrix
+
+See also:
+- [a-5.2-Information-security-roles-and-responsibilities](../Standards/ISO27x/OST/27002/EN/a-5.2-Information-security-roles-and-responsibilities.md)
+- [a-5.3-Segregation-of-duties](../Standards/ISO27x/OST/27002/EN/a-5.3-Segregation-of-duties.md)
+
+## What is a RASCI matrix
+
+A RASCI matrix, also known as a responsibility assignment matrix, is a tool used in project management to clarify and define roles and responsibilities for tasks within a project or business process. RASCI is an acronym that stands for:
+
+1. **Responsible (R)**: The individual(s) who actually complete the task or deliver the work. There can be multiple responsible parties for a task.
+
+2. **Accountable (A)**: The person ultimately answerable for the correct and thorough completion of the deliverable or task. This person ensures the task is completed and is given the authority to approve work. There should only be one accountable party for each task to avoid confusion.
+
+3. **Supportive (S)**: Individuals or groups who provide help or resources to those responsible. Their role is usually to support the project through specific expertise or necessary resources.
+
+4. **Consulted (C)**: Those whose opinions are sought, typically subject matter experts, and with whom there is two-way communication.
+
+5. **Informed (I)**: Those who are kept up-to-date on progress, often only a one-way communication.
+
+The RASCI matrix helps ensure clarity in roles and responsibilities, eliminating confusion, reducing overlaps, and improving project efficiency and outcomes. It is typically presented in a table format, with tasks or deliverables listed in the rows and project team members listed in the columns, filling in the matrix with the appropriate letters (R, A, S, C, I) per task and participant.
+
+### Variants
+
+There are several well-known variants of the RASCI matrix, each adapted to suit different types of organizational needs and project requirements. For example:
+
+1. **RACI**: The most common variant, which omits the "Supportive" role. It includes only Responsible, Accountable, Consulted, and Informed.
+
+2. **RASIC**: Similar to RASCI but with "Support" and "Inform" roles combined. The roles are Responsible, Accountable, Supportive, Inform/Consult.
+
+3. **DACI**: Focuses on decisions with roles defined as Driver, Approver, Contributor, and Informed. This is often used in decision-making processes.
+
+4. **RAS**: A simplified version that includes Responsible, Approver (combination of Accountable and Consulted), and Supportive roles. This is used when communication is less complex.
+
+5. **CAIRO**: A variant that includes Consulted, Accountable, Informed, Responsible, and Omits. The "Omits" role denotes parties who are explicitly not part of the process.
+
+6. **RAPID**: Focuses on decision-making roles: Recommend, Agree, Perform, Input, and Decide. Typically used in business strategy and decision processes.
+
+Each variant serves a specific purpose and can be chosen based on the specific needs and complexity of the project or organization. The goal of these matrices is to clearly articulate roles, avoid confusion, and ensure efficiency in task completion and decision-making.

Corpus/ISMS/RBAC Access levels.md

@@ -0,0 +1,27 @@
+# RBAC Access levels
+
+In a Role-Based Access Control (RBAC) matrix, access levels are defined to specify what actions users can perform based on their assigned roles. The specific access levels may vary depending on the organization's needs and the complexity of its systems, but generally, the following access levels are commonly identified:
+
+**No Access:**
+The user has no permissions to view, modify, or interact with the data or resources. This is suitable for users who should not have any interaction with the particular system or data.
+
+**Read-Only Access:**
+The user can view data and resources but cannot make any changes. This is often granted to users who need to monitor information or generate reports without affecting the original data.
+
+**Read and Write Access:**
+The user has permissions to both view and modify data. However, they may not have the ability to delete or manage access controls. This level is appropriate for employees who need to update records or input data as part of their job function.
+
+**Execute Access:**
+The user can run or execute specific programs, scripts, or procedures but may not have the ability to alter the underlying code or configuration. This level of access is often used in systems where running tasks or jobs is required without modifying the application.
+
+**Create Access:**
+The user may create new data or resources but might not have permissions to modify or delete existing ones. This could apply to roles tasked with adding new entries to databases or content management systems.
+
+**Delete Access:**
+The user has permission to remove data or resources. This is a higher-level access often combined with other permissions and typically reserved for roles responsible for data lifecycle management.
+
+**Full Control/Admin Access:**
+The user has complete control over the system, including managing other users' access rights, modifying configurations, and managing data. This level is usually restricted to administrators or superusers who require comprehensive abilities to oversee and maintain the system.
+
+**Custom Access:**
+Some systems allow for custom access levels tailored to specific needs, combining various elements of the above-mentioned permissions. This could include access to certain features, modules, or datasets specific to the individual's role.

Corpus/ISMS/Responsibility assignment matrices.md

@@ -0,0 +1,32 @@
+# Responsibility assignment matrices
+## RACI model
+- Responsible – works to perform the activity
+- Accountable – final approving authority, only one per task, must also ensure ensures the prerequisites of the task are met
+- Consulted – provide recommendations or opinions, typically subject-matter experts
+- Informed – are kept updated on the progress and status of the activity
+
+## RASCI model
+- + Support – helps to complete the task
+
+## RACI-VS
+  - **Verifier**: The role responsible for checking that the product meets certain criteria or standards.
+  - **Signatory**: The role responsible for authorizing the work before it proceeds or is considered complete.
+
+## CLAM Model
+Another variation similar to RACI:
+  - **Contributes**: Those who contribute to or provide input for the activity.
+  - **Leads**: Those who lead and ensure the task is executed.
+  - **Approves**: Those who approve or review the work.
+  - **Monitors**: Those who monitor progress and ensure compliance and standards are met.
+
+## RAPID
+More geared towards clarify decision-making roles, seemingly in a consultancy workmode.
+
+- R = Recommend – gathers relevant input and proposes a course of action, possible alternatives, pros and cons
+- A = Agree – formal approval of a recommendation; A and R work together to come to a mutually satisfactory proposal for the Decider.
+- P = Perform – executes or implements the decision once it is made. Good practice is to involve them early in the process to gather input.
+- I = Input – provides relevant information to the Recommender and Decider. More narrow in scope than Recommenders, who should consider all input.
+- D = Decide – single person ultimately accountable for making the final decision, committing the group to action and ensuring the decision gets implemented.
+
+## Other variants
+See [this Wikipedia page](https://en.wikipedia.org/wiki/Responsibility_assignment_matrix).

Corpus/ISMS/Risk analysis methods.md

@@ -0,0 +1,18 @@
+# Risk analysis methods
+
+
+See also under [Threat](../📚️%20Literature%20notes/Threat.md)
+
+[Open Group Risk Analysis Standard (O-RA)](https://pubs.opengroup.org/security/o-ra/)
+[Open Group FAIR \ ISO 27005 Cookbook for Risk Assessment](../Standards/ISO27x/FAIR%20ISO%2027005%20Cookbook.pdf)
+
+[SURF Toolkit risicobeoordeling](../Standards/SURF%20Toolkit%20risicobeoordeling.md)
+	
+[](../Information%20Security/Risks/Risk_Assessment_Process.gif)
+
+Related: 
+- [Assets, Vulnerabilities, Threats, Risks](../Information%20Security/Risks/Assets,%20Vulnerabilities,%20Threats,%20Risks.md)
+- [Risk identification](../Information%20Security/Risks/Risk%20identification.md)
+- [Def_Sec_Handbook_Chapter_1](../Literature/Defensive%20Security%20Handbook/Def_Sec_Handbook_Chapter_1.md)
+- [Evaluating and Quantifying Cyber Risks using FAIR](https://www.protiviti.com/US-en/technology-consulting/cybersecurity/fair)
+- [Factor Analysis of Information Risk (FAIR)](../Information%20Security/Risks/Factor%20Analysis%20of%20Information%20Risk%20(FAIR).md)

Corpus/ISMS/Roles and Responsibilities.md

@@ -0,0 +1,11 @@
+See also:
+- [Roles in Information security management](../Information%20Security/Roles%20in%20Information%20security%20management.md)
+- [Roles in Identity and Access Management (IAM)](../Information%20Security/Roles%20in%20Identity%20and%20Access%20Management%20(IAM).md)
+- [Segregation of Duties](Segregation%20of%20Duties.md)
+- [RASCI Matrix](RASCI%20Matrix.md)
+- [a-5.2-Information-security-roles-and-responsibilities](../Standards/ISO27x/OST/27002/EN/a-5.2-Information-security-roles-and-responsibilities.md)
+- [a-5.3-Segregation-of-duties](../Standards/ISO27x/OST/27002/EN/a-5.3-Segregation-of-duties.md)
+
+
+# Ownership
+See: [Asset ownership](Asset%20ownership.md), [Control ownership](Control%20ownership.md), [Risk ownership](../Information%20Security/Risks/Risk%20ownership.md)

Corpus/ISMS/SWOT Analyses template.md

@@ -0,0 +1,6 @@
+# SWOT Analyses confrontation matrix  template
+
+![](SWOT%20confrontatiematrix.xlsx)
+
+
+![1000](SWOT%20Analyses%20confrontation%20matrix%20preview.png)

Corpus/ISMS/Samenhang tussen ISMS producten.md

@@ -0,0 +1,104 @@
+# Samenhang tussen ISMS producten
+
+- [ ] Verdere samenhang destilleren uit Humankind beleidsdocumenten
+
+Risico is de schade die kan ontstaan doordat de BVI van informatie gecompromitteerd wordt. 
+Dit kan door een dreiging die gebruik maakt van een kwetsbaarheid. 
+
+De volgende zaken moeten geïdentificeerd worden:
+- assets: weten wat je wil beschermen
+- dreigingen: mogelijke oorzaken van schade
+- Kwetsbaarheden: zwakke plekken 
+- Risico’s: waarschijnlijkheid en impact van dreigingen die gebruik maken van een kwetsbaarheden 
+- Maatregelen: kwetsbaarheden verminderen / kans op impact / ernst van impact 
+
+## Samenhang tussen producten
+
+* Risicobereidheid voedt Dataclassificatie
+* Assetinventarisatie voedt Dataclassificatie
+* TrafficLightsProtocol voedt Dataclassificatie
+* Dreigingsanalyse voedt Maatregelen
+* Kwetsbaarheden voedt Maatregelen
+* Maatregelen voedt Dataclassificatie
+* AssetInventarisatie voedt Dataclassificatie
+* Risicos voeden Maatregelen
+* MaatregelenVoorMDWprivacy voedt DigitaalGebruikersbeleid
+* PrivacyStatementMdwsSollicitanten voedt DigitaalGebruikersbeleid
+* Wachtwoordbeleid voedt DigitaalGebruikersbeleid
+* AlgemeenIBPbeleid voedt MaatregelenVoorMDWprivacy
+* WerknemersregelingPrivéDevices voedt DigitaalGebruikersbeleid
+* Bruikleenovereenkomst voedt DigitaalGebruikersbeleid
+* Dataclassificatie voedt GebruikSaaS
+* Dataclassificatie voedt SelectieImplementatieTechnologie
+* Digitaal Gebruikersbeleid voedt SelectieImplementatieTechnologie
+* Architectuurprincipes voedt SelectieImplementatieTechnologie
+* Architectuurprincipes voedt GebruikSaaS
+* Architectuurprincipes voedt Informatiebeveiligingsbeleid
+* Architectuurprincipes voedt ToegangsbeleidApplicaties
+* GebruikSaaS voedt SelectieImplementatieTechnologie
+- Dataclassificatie voedt Bedrijfscontinuïteitsplan
+- ITsolutionLifeCycle voedt SelectieImplementatieTechnologie
+- Informatiebeveiligingsbeleid voedt Detailbeleid
+- Informatiebeveiligingsbeleid voedt SelectieImplementatieTechnologie
+- Retentiebeleid voedt SelectieImplementatieTechnologie
+- Functieboek voedt ToegangsbeleidApplicaties
+- Processenboek voedt ToegangsbeleidApplicaties
+- Dataclassificatie voedt ToegangsbeleidApplicaties
+- RisicoInventarisatie voedt **X**
+- PenTest voedt **X**
+- Strategie voedt Informatiebeveiligingsbeleid
+- **APPLICATIELANDSCHAP** ?
+- **BIA** ?
+- **SoA ?**
+- **Architectuurprincipes is deels een Government model, deels richtinggevende architectuur eisen**
+- Beleidsdocument voedt de reviewcalendar
+- Systeemlandschap voedt Toegangsbeleid
+- Dataclassificatie voedt Toegangsbeleid
+
+
+``` mermaid
+graph TD
+    Risicobereidheid --> Dataclassificatie
+    Assetinventarisatie --> Dataclassificatie
+    TrafficLightsProtocol --> Dataclassificatie
+    Dreigingsanalyse --> Maatregelen
+    Kwetsbaarheden --> Maatregelen
+    Maatregelen --> Dataclassificatie
+    Risicos --> Maatregelen
+    MaatregelenVoorMDWprivacy --> DigitaalGebruikersbeleid
+    PrivacyStatementMdwsSollicitanten --> DigitaalGebruikersbeleid
+    Wachtwoordbeleid --> DigitaalGebruikersbeleid
+    AlgemeenIBPbeleid --> MaatregelenVoorMDWprivacy
+    WerknemersregelingPrivéDevices --> DigitaalGebruikersbeleid
+    Bruikleenovereenkomst --> DigitaalGebruikersbeleid
+    Dataclassificatie --> GebruikSaaS
+    Dataclassificatie --> SelectieImplementatieTechnologie
+    DigitaalGebruikersbeleid --> SelectieImplementatieTechnologie
+    Architectuurprincipes --> SelectieImplementatieTechnologie
+    Architectuurprincipes --> GebruikSaaS
+    Architectuurprincipes --> Informatiebeveiligingsbeleid
+    Architectuurprincipes --> ToegangsbeleidApplicaties
+    GebruikSaaS --> SelectieImplementatieTechnologie
+    Dataclassificatie --> Bedrijfscontinuïteitsplan
+    ITsolutionLifeCycle --> SelectieImplementatieTechnologie
+    Informatiebeveiligingsbeleid --> Detailbeleid
+    Informatiebeveiligingsbeleid --> SelectieImplementatieTechnologie
+    Retentiebeleid --> SelectieImplementatieTechnologie
+    Functieboek --> ToegangsbeleidApplicaties
+    Processenboek --> ToegangsbeleidApplicaties
+    Dataclassificatie --> ToegangsbeleidApplicaties
+    RisicoInventarisatie --> X
+    PenTest --> X
+    Strategie --> Informatiebeveiligingsbeleid
+```
+
+![](ISMS%20diagram.jpg)
+
+I’d put ‘policies and documentation’ on the right, business processes on the left, context, strategy and planning at the top, and controls at the bottom. RM/PDCA cycles at the center.
+
+### Principe achter SelectieImplementatieTechnologie
+
+1. Welke info assets ga je ermee verwerken?
+2. Hoe zijn die assets geclassificeerd?
+3. Welke risico’s ontstaan er? (Technische en niet-technische)
+4. Welke maatregelen zou je dan moeten treffen cf. de dataclassificatie?

Corpus/ISMS/Segregation of Duties in Auditing.md

@@ -0,0 +1,34 @@
+[Source](https://reciprocity.com/resources/what-is-segregation-of-duties-in-auditing/)
+Published July 2, 2020
+Retrieved July 13, 2022 
+
+- Segregation of duties is a fundamental element of internal controls. 
+- Principle: no one person or group of employees should be in a position to commit and conceal errors or fraud in their day-to-day jobs.
+- General concept: prevent one person from having access to assets as well as responsibility for maintaining the accountability of those assets.
+
+In a perfect system, no one person should handle more than one type of the following functions:
+
+1. Authorization (giving approval for a transaction)
+2. Custody (care and maintenance of assets)
+3. Record keeping (administration)
+4. Reconciliation (making accounts consistent)
+
+(COBIT 5 uses Verification instead of Reconciliation, see [this note](Implementing%20Segregation%20of%20Duties%20ISACA.md)).
+
+Different levels of SOD:
+- Individual: different people perform different duties, e.g. a manager authorizes an employee to make a payment.
+- Unit-level: different departments perform different duties, e.g. sales creates a project proposal, risk management approves it. 
+- Company-level: different entities perform operations, e.g. a holding company authorizes an investment of a subsidiary, or an accountancy firm performs a third-party audit.
+
+Examples of internal control mechanisms for enforcing segregation of duties:
+- Audit trails, to recreate the transaction flow from origin to registration in an audit file. The audit trail should provide information on:
+	- who initiated the transaction
+	- date and timeof entry
+	- type of entry
+	- fields of information it contained
+	- what files the transaction updated.
+- exception reports should be handled by supervisors
+- exceptions should be documented to prove proper and timely handling, the document should be signed by the author
+- Log should be kept or generated for all processed system commands or application transactions.
+- Independent reviews of reports and logs should be conducted.
+

Corpus/ISMS/Segregation of Duties.md

@@ -0,0 +1,40 @@
+# Segregation of Duties
+
+- [Implementing Segregation of Duties ISACA](Implementing%20Segregation%20of%20Duties%20ISACA.md)
+- [Segregation of Duties in Auditing](Segregation%20of%20Duties%20in%20Auditing.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)
+- [Functiescheiding Typologie Starreveld](Functiescheiding%20Typologie%20Starreveld.md)
+- [Trias Politica](../Various/Trias%20Politica.md)
+
+Segregation of Duties ensures no single person has enough authority or access to compromise the system or data on their own.
+
+**From a [dead blog](https://blogs.dnvgl.com/energy/separation-of-duties-and-it-security):**
+
+Two primary objectives:
+* prevention of conflict of interest (real or apparent), wrongful acts, fraud, abuse and errors. 
+* detection of control failures.
+
+There is an easy test for Separation of duties.
+	1. Can any one person exfiltrate classified information without detection?
+	2. Can any one person alter or destroy classified information without being detected?
+	3. Does any one person have influence over controls design, implementation and reporting of the effectiveness of the controls?
+
+The answers to all these questions should be “no.” 
+
+So:
+1. Determine what is sensitive information and label it
+2. Log access to sensitive information.
+3. Separate access rights (incl. modification and deletion) from the rights to modify controls or logging.
+4. Separate design and implementation of security controls from testing, auditing, monitoring and reporting.
+
+Responsibilities for controls (**DIME model**):
+* Design
+* Implementation
+* Monitoring / reporting
+* Evaluation
+* Auditing
+
+Also:
+* The security officer should not report to the CIO, as she is responsible for having no cybersecurity issues.
+* Use a third party to monitor security and conduct tests and audits. 

Corpus/ISMS/Setting up a Successful Security Program.md

@@ -0,0 +1,76 @@
+# Secrets of Successful Security Programs
+
+The original source consists of 2 blogposts, titled 'Secrets of Successful Security Programs' [Part 1](https://www.philvenables.com/post/secrets-of-successful-security-programs-part-1) and [Part 2](https://www.philvenables.com/post/secrets-of-successful-security-programs-part-2).
+
+Publication date Januray 15 and January 29, 2022
+Retrieved February 10, 2022
+
+Author: Phil Venables, @philvenables
+
+Relevant ISO 27001 clauses/controls:
+- [ISO 27001 C 5 Leadership](../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001%20C%205%20Leadership.md)
+- [ISO 27001 C 6 Planning](../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001%20C%206%20Planning.md)
+
+
+
+
+
+A successful security program has two distinct elements:
+
+1.  A series of episodic transformational improvements.
+2. A set of management practices for ongoing and effective risk mitigation and constant incremental improvement.
+
+
+According to the author, if you do only the first, the value of the improvements will taper off over time or will just yield some unconnected bright spots. If you do only the second, you will always be in reactive mode playing cath-up to reality.
+You need to do both in balance.
+
+Funding differs for effort type 1 (special, project based funding) and effort type 2 (annual operational budgets).
+
+## Episodic transformational improvements
+Plan for a grander change of scale. Objectives need to be "dramatic" to gain the necessary organizational commitment. 
+
+The objectives will often fall into these categories:
+
+- Implement conrols to mitigate *classes* of risks instead of single ones, e.g. instead of creating a software whitelist, implement a well-considered control framework for software whitelisting, for end points and production systems.
+- Eliminate pain – identify aspects of security that currently take a lot of effort and money
+- Improve effectiveness of existing controls – imagine existing controls as a stack or concentric circles. Assess the percentage of attacks penetrating each layer of defense. If an inner layer gets more pressure than an outer layer, improve the latter.
+- Reduce risk from configuration errors – find places where a single configuration error could yield catastrophic outcomes, and where multiple risky configurations fall under single-control.
+- Look for, and reduce, tensions between risks, e.g. security (least privilege) vs resilience (disaster recovery): narrow-set privileges to reduce insider risk may hinder disaster recovery, because of dependency on critical personnel. Also "look for single points of control failure such as if an outage of a control plane prevents the required access to fix that same issue." 
+- Find 'invariants' and assess their validity: what has to remain true to guarantee success or avoid failure? Implement activities to establish and sustain them.
+- Ensure that your strategy is compatible with contextual developments ('mega trends').
+- Prepare for emerging technology transformations, e.g. cloud, quantum, AI/ML
+
+Use these categories to define a series of ideas for whole leaps forward, either in terms of technology architecture, process overhauls (business and technology) or organization and management technique changes in and around the risk and security programs.
+
+### Examples
+The author lists the following examples of transformational efforts from his personal experience:
+- Security as an endless program, instead of a project
+- Security by Design, not as a late stage add-on
+- Replacing or augmenting passwords with strong two factor authentication, preferably for all access but at least for all remote access/connectivity, for high risk/privileged access use and for high risk transaction based step-up authentication.
+- Multi-Tier DMZs
+- Application Security Frameworks and Tools
+- Web Proxy Default Deny for user or application outbound web access
+- Identity Management: all resource access must be based on one common authenticated identity, and that identity be tightly coupled with a single reliable inventory/record of employees, contractors and customers (for external accesses). Any privilege that is not linked to that singular established source of identity, must be driven out.
+- Root out combinations of privilege that together break a separation of duties requirement or otherwise conspire to breach an information barrier. Implement a management proces to identify and eliminate these combinations, using access management databases. Use the findings also for improving the structuring of roles, and establishing the right rules in the privilege provisioning systems.
+- Create or outsource a 24x7 Security Operations Center (SOC) – these are almost by definition reactive in nature. Create an internal Threat Management Center to focus on the continued optimization of the SOC.
+
+## Practices for ongoing and effective risk mitigation
+### Establish Sources of Funding
+Drive for at least 4 lines of funding:
+1. Base operating funding to keep your operations going. Likely mandated by the CEO and approved by the CFO. Funding will be centrally sourced or from a required contribution from revenue / business units.
+2. Episodic investments for specific transformational improvements. Budget may be allocated outside the security team’s management. If it is, then some of the funding will need to be allocated to other areas responsible for their part of the work.
+3. Activity based / flexible funding from revenue / business units, related to activities that cuase extra risk, e.g. the implementation of e-Commerce activities that require extra work of the security team. Create awareness for a permanent operational budget to maintain baseline security post-project.
+4. Preventative maintenance
+
+### Build and Maintain an Effective Team
+You will either inherit or have to build a team. The mission changes all the time and so should the team. Establish a talent development program to build a solid leadership pipeline for the future.
+
+Related:
+- [Organizing Cybersecurity](../Sparks/Organizing%20Cybersecurity.md)
+
+### Build relationships
+- find and realize business benefits, be commercial and mission aligned to ensure support from business management 
+- Build relationships, see https://www.philvenables.com/post/the-seat-at-the-table-integrating-security-into-your-business and https://www.philvenables.com/post/relationship-management-for-the-infosec-program
+
+### Governance, Risk Committees and Board Engagement
+Read further, https://www.philvenables.com/post/secrets-of-successful-security-programs-part-2

Corpus/ISMS/Sources for the Context sessions.md

@@ -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](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)
+

Corpus/ISMS/Stakeholder Analysis.md

@@ -0,0 +1,9 @@
+See this [Wikipedia page](https://en.wikipedia.org/wiki/Stakeholder_analysis) on Stakeholder Analysis for different methods.
+
+
+## Examples of internal stakeholder interests
+Different stakeholders have 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
+- [ISO 27001_OT C 4 Context of the organization](../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001_OT%20C%204%20Context%20of%20the%20organization.md#4%202%20Understanding%20the%20needs%20and%20expectations%20of%20interested%20parties)
+- [ISO31000-5.4.1-Understanding-the-organization-and-its-context](../Standards/ISO27x/ISO31000-5.4.1-Understanding-the-organization-and-its-context.md)

Corpus/ISMS/Transfer in Risk Treatment.md

@@ -0,0 +1,7 @@
+There's a difference in transfering a Risk (i.e. transfering Risk Ownership) and transfering the responsibility for managing the risk.
+
+Who should be appointed as Risk Owner?
+
+Consider this example: the reception makes keys available to visitors, but says it isn't able to keep a proper administration because of lack of time.
+Reception argues it is the responsibility of Facilities.
+This begs the question: Who is responsible for granting access to rooms?

Corpus/ISMS/Triggers for Reviews of Policies.md

@@ -0,0 +1,68 @@
+# Triggers for Reviews of Policies
+
+**From [A 5.35](../Standards/ISO27x/OST/27002/EN/a-5.35-Independent-review-of-information-security.md), Independent review of information security:**
+
+The organization should consider conducting independent reviews when:
+
+a\) laws and regulations which affect the organization change;
+
+b\) significant incidents occur;
+
+c\) the organization starts a new business or changes a current business;
+
+d\) the organization starts to use a new product or service, or changes the use of a current product or service;
+
+e\) the organization changes the information security controls and procedures significantly.
+
+ISO/IEC 27007 and ISO/IEC TS 27008 provide guidance for carrying out independent reviews.
+
+
+## From NotebookLM
+
+The source documents specify several explicit triggers that necessitate the review and updating of an organization's policies, particularly the main information security policy and supporting topic-specific policies.
+
+Key triggers for policy review include:
+
+### 1. Significant Changes
+
+Both the overarching organizational information security policy and specific topic-specific policies must be reviewed when **significant changes occur**.
+
+Specifically, management should review and update information security policies in response to changes in:
+
+- **Regulations, statutes, legislation, and contracts**.
+- **The organization's business strategy**.
+- **The organization's technical environment**.
+- **Information security risks**.
+- **The current and projected information security threat environment**.
+- **The organization itself**, such as starting a new business or changing a current business.
+- **Products or services**, such as starting to use a new product or service, or changing the use of a current one.
+- **Information security controls and procedures**, if they change significantly.
+
+The requirement for independent review of the organization's approach to managing information security (which includes policies) is also triggered **when significant changes occur**.
+
+	### 2. Planned Intervals
+
+In addition to being reviewed when significant changes occur, policies must be reviewed at **planned intervals**.
+
+- The information security policy and topic-specific policies should be reviewed at **planned intervals**.
+- Confidentiality or non-disclosure agreements should be **regularly reviewed**.
+- The organization's approach to managing information security (which includes policies) should be reviewed independently at **planned intervals**.
+- Compliance with the organization’s policies, rules, and standards should be **regularly reviewed**.
+
+### 3. Incidents and Learning
+
+Feedback from incidents and assurance activities also triggers policy review:
+
+- The review should be built on **lessons learnt from information security incidents**.
+- Lessons learned from **information security events and incidents** should be taken into account during the review of the information security policy and topic-specific policies.
+- The evaluation of information gained from information security incidents should be used to update the organization's information security risk assessment and **determine and implement necessary additional controls**. This necessitates policy review if control changes are determined.
+- The organization should consider conducting independent reviews when **significant incidents occur**.
+
+### 4. Management Activities and Audits
+
+Policy reviews are integrated into the management system framework:
+
+- Review and update of policies should take the **results of management reviews and audits** into account.
+- The management review inputs include considering **changes in external and internal issues** (relevant to the ISMS scope), and **changes in needs and expectations of interested parties** (relevant to the ISMS), which inherently requires reviewing the policy for continuing suitability.
+
+When a policy is changed, review and updates of **other related policies** should be considered to maintain consistency.

Corpus/ISMS/Using a Kanban board for ISMS implementation.md

@@ -0,0 +1,29 @@
+# Using a Kanban board for ISMS implementation
+
+We start with all Clauses and controls on the Backlog. 
+At the end of each session we move controls from the backlog to 'to do' (and maybe some items can move to 'planned for Qn'). 
+
+Because every item is also tagged with a session number, I can generate an Epic timeline view. 
+
+I foresee a linear phase in which we go through the sessions sequentially, and then a number of cyclic iterations in which we expand and refine until we're ready for certification (of course the cycles continue after that). 
+Actually the linear phase can be seen as the first cycle. 
+
+There will be different frequencies/RPM's
+3 yr certification cycle, yearly, and the more frequent 'operational'.  
+These may be implemented by assigning a 'Review every n years/months/weeks' value to the Kanban item. A 'reviewed' button could trigger the population of a 'link to review' field and a 'next review date'. This could however be too complex for the video course. For the course the only use of the cycle frequency is to generate a Review Planning. 
+
+Now for the Risks. Finding a fitting Control is also a todo. But it's more a project item: it can not be pre-populated like the clauses and controls. 
+It must be clearly distinguishable from them. 
+There wil also be other project todos specific for the organization. Incorporate examples into the method. 
+
+
+## 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/iso27DIY%20mk%20I/About%20ISO27DIY%20Policy%20Cards.md)  
+
+
+## Activities and Artifacts
+We can distinguish Activities and Artifacts. Activities line up with 
+the PDCA cycle steps. Each activity needs to produce documented proof, or an 'Artifact'. 
+The planning, in the form of the Kanban board, is an artifact in itself. Other artifacts are for instance measuring reports and logs, meeting notes, policies, etc. 

Corpus/ISMS/Vendor security MoC.md

@@ -0,0 +1,37 @@
+# External suppliers and Vendor security
+
+"In the modern SaaS world, we must consider vendors to be within our security perimeter. As a security team, we need to be able to test their security posture in order to protect our users’ data". 
+
+**Relevant ISO 27002:2022 controls:**
+[5.19:](../MoCs/ISO_27002_2022_5.19_MoC%20Information%20security%20in%20supplier%20relationships.md) Information security in supplier relationships | 2013: 15.1.1
+[5.20:](../MoCs/ISO_27002_2022_5.20_MoC%20Addressing%20information%20security%20within%20supplier%20agreements.md) Addressing information security within supplier agreements | 2013: 15.1.2
+[5.21:](../MoCs/ISO_27002_2022_5.21_MoC%20Managing%20information%20security%20in%20the%20ICT%20supply%20chain.md) Managing information security in the ICT supply chain | 2013: 15.1.3
+[5.22:](../MoCs/ISO_27002_2022_5.22_MoC%20Monitoring,%20review%20and%20change%20management%20of%20supplier%20services.md) Monitoring, review and change management of supplier services | 2013: 15.2.1, 15.2.2
+[5.23:](../MoCs/ISO_27002_2022_5.23_MoC%20Information%20security%20for%20use%20of%20cloud%20services.md) Information security for use of cloud services | 2013: n/a
+[5.31:](../MoCs/ISO_27002_2022_5.31_MoC%20Legal,%20statutory,%20regulatory%20and%20contractual%20requirements.md) Legal, statutory, regulatory and contractual requirements | 2013: 18.1.1, 18.1.5
+[6.6:](../MoCs/ISO_27002_2022_6.6_MoC%20Confidentiality%20or%20non-disclosure%20agreements.md) Confidentiality or non-disclosure agreements | 2013: 13.2.4
+[8.26:](../MoCs/ISO_27002_2022_8.26_MoC%20Application%20security%20requirements.md) Application security requirements
+
+**Relevant CISSP topics:**
+- [1.11 Apply Risk-Based Management Concepts to the Supply Chain](../Standards/CISSP/CISSP_OSG8_D1_C1_1.11.md)
+- [1.8.4 Vendor, consultant, and contractor agreements and controls](../Standards/CISSP/CISSP_OSG8_D1_C2_1.8.4.md)
+- [Contracting and Procurement](../Standards/CISSP/CISSP_OSG8_D1_C4.md)
+
+See also: 
+- [Examples of vendor selection questionnaires](../Information%20Security/Examples%20of%20vendor%20selection%20questionnaires.md)
+- [Drafting a Vendor and Product checklist](Policy%20examples/Drafting%20a%20Vendor%20and%20Product%20checklist.md)
+- [Veiligheidseisen aan Leveranciers Junis](../../Clients/Junis/Veiligheidseisen%20aan%20Leveranciers%20Junis.md)
+- [Vulnerability Disclosure Policy](Policy%20examples/Vulnerability%20Disclosure%20Policy.md)
+- [Software due diligence](../Information%20Security/Software%20due%20diligence.md)
+- [Checklist for security product vendors assessment](../Literature/Checklists%20Gerardus%20Blokdyk/Checklist%20for%20security%20product%20vendors%20assessment.md)
+- [Checklist for auditing Vendor Management](../Literature/Checklists%20Gerardus%20Blokdyk/Checklist%20for%20auditing%20Vendor%20Management.md)
+- [Treating vendors as a risk](../Information%20Security/Risks/Treating%20vendors%20as%20a%20risk.md)
+
+Examples:
+- [Dropbox Supplier Security Requirements](Policy%20examples/Dropbox%20Supplier%20Security%20Requirements.md)
+- [Veiligheidseisen aan Leveranciers Junis](../../Clients/Junis/Veiligheidseisen%20aan%20Leveranciers%20Junis.md)
+- [Ubeoo ATS vendor selection Humankind](../../Clients/Humankind/Ubeoo%20ATS%20vendor%20selection%20Humankind.md)
+- [Selectie en implementatie van Technologie bij Humankind](../../Clients/Humankind/Selectie%20en%20implementatie%20van%20Technologie%20bij%20Humankind.md) 
+
+
+