ISO/IEC 27001: Compliance Mapping
=================================

Purpose
-------

This document explains how **ISO/IEC 27001 requirements** are translated into
**practical technical controls, operating processes, and audit-ready evidence**
within modern cloud and software environments.

It is written for:

- Security and cloud architects
- Engineering leaders
- Assurance and audit teams
- Internal ISO 27001 programme owners

This is not a certification guide.
It is an **implementation and evidence mapping reference**.

---

Scope of ISO/IEC 27001
----------------------

ISO/IEC 27001 defines requirements for establishing, implementing,
maintaining, and continually improving an **Information Security Management
System (ISMS)**.

In practice, ISO 27001 requires organisations to demonstrate:

- Risk-based decision making
- Control implementation
- Operational effectiveness
- Continuous improvement
- Management oversight

Compliance must be **provable**, not assumed.

---

Mapping Approach
----------------

ISO 27001 requirements are mapped using the following structure:

1. **Clause / Control Objective**
2. **Risk Addressed**
3. **Technical and Organisational Controls**
4. **Operational Ownership**
5. **Evidence Produced**

This structure allows reuse of controls across:

- ISO 27001 surveillance audits
- Customer security assessments
- Tender responses
- Regulatory reviews

---

ISMS as an Operating Model
--------------------------

An effective ISMS is not a document repository.

It is an operating model that connects:

- Governance
- Engineering
- Operations
- Assurance

Key characteristics of a functional ISMS include:

- Defined ownership
- Embedded controls
- Measurable effectiveness
- Continuous evidence

---

Clause-to-Control Mapping (Examples)
------------------------------------

### Clause 6 – Planning (Risk Management)

**Objective**
Identify, analyse, and treat information security risks.

**Implementation Examples**
- Centralised risk register
- Risk acceptance workflows
- Control selection based on risk
- Management approval tracking

**Evidence**
- Risk assessment records
- Treatment decisions
- Approval artefacts
- Review timestamps

---

### Clause 8 – Operation

**Objective**
Ensure controls are implemented and operated as planned.

**Implementation Examples**
- CI/CD-enforced change management
- Infrastructure-as-code deployments
- Automated security checks
- Operational runbooks

**Evidence**
- Deployment logs
- Pipeline approvals
- Change tickets
- Monitoring outputs

---

### Clause 9 – Performance Evaluation

**Objective**
Monitor, measure, analyse, and evaluate ISMS performance.

**Implementation Examples**
- Security metrics dashboards
- Vulnerability trends
- Incident metrics
- Control effectiveness indicators

**Evidence**
- Dashboard exports
- KPI reports
- Review meeting records

---

### Clause 10 – Improvement

**Objective**
Continually improve the ISMS.

**Implementation Examples**
- Incident post-mortems
- Nonconformity tracking
- Corrective action workflows

**Evidence**
- Root cause analyses
- Remediation tickets
- Closure verification

---

Annex A Controls in Cloud Environments
--------------------------------------

Annex A controls must be adapted to modern architectures.

Typical mappings include:

- Access control → IAM policies and reviews
- Logging → centralised log pipelines
- Asset management → cloud inventories
- Supplier management → vendor assurance reviews
- Incident response → ticketed workflows

Controls must be **implemented in systems**, not only described.

---

Vendor-Hosted & Shared Responsibility
-------------------------------------

In cloud and managed environments:

- Some controls are inherited
- Some are shared
- Some remain customer-owned

ISO 27001 requires organisations to:

- Retain accountability
- Validate inherited controls
- Document responsibility boundaries
- Provide internal evidence for owned controls

Vendor certifications alone are not sufficient.

---

Evidence Expectations
---------------------

Auditors typically expect evidence that is:

- Objective
- Traceable
- Consistent
- Reproducible

Preferred evidence sources include:

- System-generated artefacts
- Configuration states
- Access reviews
- Logs and alerts
- Ticketing system records

Manual screenshots should be the exception, not the rule.

---

Common ISO 27001 Failure Patterns
---------------------------------

Common issues identified during audits include:

- Policies not reflected in implementation
- Undefined control ownership
- Inconsistent evidence
- One-time risk assessments
- Last-minute evidence collection

These issues indicate process gaps, not audit problems.

---

Relationship to Other Documentation
-----------------------------------

This mapping is supported by:

- :doc:`/whitepapers/iso27001-evidence-by-design`
- :doc:`/solutions/cloud-security-foundations`
- :doc:`/solutions/secure-software-lifecycle`
- :doc:`/evidence-library/control-to-proof`

---

Key Takeaway
------------

ISO/IEC 27001 compliance is strongest when:

- controls are embedded into systems
- ownership is explicit
- evidence is produced continuously

An ISMS succeeds when it operates **by design, not by exception**.