removed emoji from filenames, Obsidian changed all relevant links

Corpus/Drafts and Ideas/ISMS/About implementation and proof.md

@@ -0,0 +1,9 @@
+---
+tags:  
+- project/iso27DIY
+- type/explainer
+---
+
+The auditor will require proof of the implementation of the ISMS and all it’s individual controls. Proper implementation means a control is risk-based, there’s a policy describing the why and how of it’s implementation, it’s results are monitored or measured, it’s effectiveness is evaluated, and possible improvements to the implementation of the control are identified.
+
+

Corpus/Drafts and Ideas/ISMS/About policies controls and risks.md

@@ -0,0 +1,63 @@
+---
+tags:
+  - iso27001
+  - policy
+  - control
+  - risk
+---
+
+
+`Within a ISO 27001 compliant ISMS, is it possible to implement a control without having a policy for that control?`
+
+`Claude Sonnet 4:`
+
+In an ISO 27001 compliant ISMS, implementing a control without having a policy for that control is technically possible but not recommended and may create compliance issues.
+
+Here’s why this creates problems:
+
+**Policy Requirements**: ISO 27001 requires documented information for information security policies, and Annex A controls often reference the need for established policies. The standard expects that controls should be guided by appropriate policies that define the organization’s approach and requirements.
+
+**Documentation and Evidence**: During certification audits, auditors will look for evidence that controls are properly governed. A control implemented without supporting policy documentation may be seen as ad hoc or insufficiently managed, potentially leading to non-conformities.
+
+**Control Effectiveness**: Policies provide the framework for consistent implementation and operation of controls. Without them, you risk:
+
+- Inconsistent application across the organization
+- Lack of clear responsibilities and accountabilities
+- Difficulty in measuring effectiveness
+- Challenges in maintaining the control over time
+
+**Best Practice Approach**: The recommended structure is:
+
+1. **Policy** - High-level statement of intent and requirements
+2. **Procedures** - Detailed steps for implementation
+3. **Controls** - Actual security measures and technical implementations
+4. **Records** - Evidence of operation and effectiveness
+
+While you might temporarily operate a control without formal policy documentation, you should establish the appropriate policy framework to ensure long-term compliance and effectiveness. This approach aligns with ISO 27001’s emphasis on a systematic, risk-based approach to information security management.​​​​​​​​​​​​​​​​
+
+`Does each control need an associated risk?`
+
+`Claude Sonnet 4:`
+
+No, each control does not need an associated risk in an ISO 27001 compliant ISMS. This is a common misconception about how the risk-based approach works.
+
+**How Risk and Controls Actually Relate:**
+
+**Risk-Driven Control Selection**: Controls should be selected based on your risk assessment outcomes. You identify risks, evaluate them, and then select controls to treat those risks. However, the relationship is typically many-to-many:
+
+- One risk may require multiple controls to adequately treat it
+- One control may address multiple different risks
+- Some controls may be implemented for compliance or operational reasons beyond specific risk treatment
+
+(so far, so good …)
+(if you interpret the following as: specific to your organization, there’s a point somewhere)
+
+**Baseline Controls**: Organizations often implement baseline security controls (like basic access controls, antivirus, firewalls) that address general security risks rather than being tied to specific identified risks (???). These are considered good security hygiene.
+
+**Compliance-Driven Controls**: Some controls may be implemented to meet regulatory requirements, contractual obligations, or industry standards, even if they don’t directly correspond to a specific risk you’ve identified in your risk assessment.
+
+**Control Objectives**: What’s important is that your overall control framework addresses your identified risks and supports your risk treatment decisions. The traceability should be at the risk treatment level, not necessarily at the individual control level.
+
+**Documentation Expectations**: Your ISMS documentation should demonstrate how your control selection relates to your risk assessment and treatment decisions, but this doesn’t require a one-to-one mapping of every control to a specific risk.
+
+The key is ensuring your control selection is justified and supports your overall risk management strategy, whether through direct risk treatment, baseline security posture, or compliance requirements.​​​​​​​​​​​​​​​​

Corpus/Drafts and Ideas/ISMS/About the Statement of Applicability.md

@@ -0,0 +1,17 @@
+---
+tags:  
+- project/iso27DIY
+- type/explainer
+---
+## About the Statement of Applicability
+
+In essence, the Statement of Applicability shows the outcome of the risk treatment process ([6.1.3a](../../Corpus/Standards/MoCs/ISO_27001_2022_6.1.3_MoC%20Information%20security%20risk%20treatment.md)). It is usually presented as a table of Annex A controls, together with a short explanation for the selection *or* exclusion of each, and its implementation status.
+
+This follows directly from [Clause 6.1.3d](../../Corpus/Standards/MoCs/ISO_27001_2022_6.1.3_MoC%20Information%20security%20risk%20treatment.md), that demands that the Statement of Applicability contains:
+* the controls that are **necessary** to implement the chosen risk treatments, including the rationale for their selection
+* the **status** of their implementation *("whether the necessary controls are implemented or not")*
+* the reason for exclusion of any and all other controls from Annex A.
+
+Though ISO 27002 offers guidelines for the implementation of the controls from Annex, the organization is free in their design.  The organization is also free to identify them "from any source", so you could also include controls from for instance XXX or YYY.
+
+One is generally advised to "Comply or Explain", which means you implement *all* controls from Annex A in some form, or you explain why you don't need to, based on your risk analysis and chosen risk treatment. 

Corpus/Drafts and Ideas/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)