Initial commit
This commit is contained in:
commit
570d74d4dd
67 changed files with 4609 additions and 0 deletions
9
Drafts and Ideas/ISMS/About implementation and proof.md
Normal file
9
Drafts and Ideas/ISMS/About implementation and proof.md
Normal file
|
|
@ -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.
|
||||
|
||||
|
||||
63
Drafts and Ideas/ISMS/About policies controls and risks.md
Normal file
63
Drafts and Ideas/ISMS/About policies controls and risks.md
Normal file
|
|
@ -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.
|
||||
|
|
@ -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 ([[ISO_27001_2022_6.1.3_MoC Information security risk treatment|6.1.3a]]). 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 [[ISO_27001_2022_6.1.3_MoC Information security risk treatment|Clause 6.1.3d]], 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.
|
||||
Loading…
Add table
Add a link
Reference in a new issue