4 KiB
| tags | ||||
|---|---|---|---|---|
|
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:
- Policy - High-level statement of intent and requirements
- Procedures - Detailed steps for implementation
- Controls - Actual security measures and technical implementations
- 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.