# Information Security Policy Framework and Policy Index: [Organization name]

> Defines how information security policies and related documents are
> structured, named, approved, reviewed, communicated, acknowledged and
> excepted, and lists every topic-specific policy, standard and procedure
> mapped to the Annex A controls it supports. It supports ISO/IEC
> 27001:2022 + Amd 1:2024 clause 5.2 (information security policy), clause
> 7.5 (documented information) and Annex A control A.5.1 (policies for
> information security), with guidance from ISO/IEC 27002:2022. Replace
> every `[bracketed]` value and every row marked *Example*.

<!--
Guidance: How to use this template
- Use it when you start writing ISMS policies, when the number of
  documents grows beyond what one person can track, and before an audit.
  A.5.1 is about a policy set that management stands behind, that the
  right people have actually seen and accepted, and that does not go
  stale. This framework sets the rules for that once, for all documents.
- Fill section 3 (naming and IDs) and section 4 (approval levels) first;
  then fill the index in section 9 with the documents you actually have,
  marking the rest as Planned.
- Main pitfall: too many policies. Put requirements that change often
  (technical settings, tool names) in standards and procedures, and keep
  policies short and stable. Second pitfall: policies without owners or
  review dates, which auditors find quickly.
- Related templates: `compliance/information-security-policy`,
  `isms/isms-documented-information-register`, `compliance/controlled-document`,
  `security/security-exception-request`, `isms/isms-roles-raci`,
  `compliance/statement-of-applicability`, `isms/control-evidence-matrix`.
-->

## Document control

<!-- Guidance: This framework is itself a topic-level document. Approval by top management or the steering committee gives the approval levels in section 4 their authority. -->

| Field | Value |
|---|---|
| Document ID | DOC-ISMS-005 |
| Version | [1.0] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@isms-manager] |
| Approvers/reviewers | [@ceo or steering committee chair], [@ciso], [@hr-lead], [@general-counsel] |
| Last updated | YYYY-MM-DD |
| Classification | [Internal] |
| Standard and edition | ISO/IEC 27001:2022 + Amd 1:2024 (clauses 5.2, 7.5; A.5.1, A.5.36, A.5.37); ISO/IEC 27002:2022 |
| Next scheduled review | YYYY-MM-DD (every [12] months) |
| Applies to | All ISMS policies, standards, procedures and records within DOC-ISMS-002 |
| Document repository | [Tool or location of master copies] |
| Related documents | DOC-ISMS-001 policy, DOC-ISMS-028 documented information register, DOC-ISMS-122 security exception request |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| ISMS manager (prepared by) | [@isms-manager] | [Prepared] | YYYY-MM-DD |
| CISO or security lead | [@ciso] | [Reviewed] | YYYY-MM-DD |
| Top management or steering committee | [@ceo] | [Approved] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change |
|---|---|---|---|
| 1.0 | YYYY-MM-DD | [@isms-manager] | First issue |
| [x.y] | YYYY-MM-DD | [@author] | [Change summary] |

## Contents

- [1. Purpose and scope](#1-purpose-and-scope)
- [2. Document hierarchy](#2-document-hierarchy)
- [3. Naming and ID scheme](#3-naming-and-id-scheme)
- [4. Approval levels](#4-approval-levels)
- [5. Review cadence and triggers](#5-review-cadence-and-triggers)
- [6. Writing rules](#6-writing-rules)
- [7. Exceptions](#7-exceptions)
- [8. Communication and acknowledgement](#8-communication-and-acknowledgement)
- [9. Topic-specific policy index](#9-topic-specific-policy-index)
- [10. Compliance monitoring and enforcement](#10-compliance-monitoring-and-enforcement)
- [11. Size tiers](#11-size-tiers)
- [12. Records and evidence](#12-records-and-evidence)
- [13. References](#13-references)
- [Standard and licence note](#standard-and-licence-note)

## 1. Purpose and scope

<!-- Guidance: Say what the framework controls and what it does not (for example HR policies outside the ISMS). Questions to answer: which documents fall under this framework, and who maintains it? -->

This framework sets one set of rules for every information security
document of [Organization name], so that:

1. Every requirement has one home, at the right level, with an owner.
2. Every document is identified, approved, published, reviewed and
   retired in a controlled way (clause 7.5.2 and 7.5.3).
3. People know which documents apply to them and confirm they have read
   them (A.5.1).
4. Deviations go through one exception route with expiry dates.
5. Auditors and staff can find the document behind any Annex A control
   from one index (section 9).

| Item | Value |
|---|---|
| In scope | Information security policy, topic-specific policies, standards, procedures, guidelines and the records they produce, within DOC-ISMS-002 |
| Out of scope | [General HR, finance and quality documents not related to information security; they follow their own document control] |
| Owner of the framework | ISMS manager |
| Master list | Documented information register DOC-ISMS-028 (`isms/isms-documented-information-register`) |

## 2. Document hierarchy

<!-- Guidance: Each level answers a different question: why and what (policy), what exactly (standard), how (procedure), proof (record). Pitfall: technical settings in a policy, which then needs top management approval for every firewall change. -->

```mermaid
flowchart TD
  L1["Level 1: Information security policy (DOC-ISMS-001)"]
  L2["Level 2: Topic-specific policies"]
  L3["Level 3: Standards and baselines"]
  L4["Level 4: Procedures and operating instructions"]
  L5["Level 5: Records and evidence"]
  G["Guidelines (advisory, not mandatory)"]
  L1 --> L2
  L2 --> L3
  L3 --> L4
  L4 --> L5
  L2 -.-> G
```

| Level | Type | Answers | Content | Mandatory? | Typical length *(Example)* |
|---|---|---|---|---|---|
| 1 | Information security policy | Why and what in principle | Sets direction, gives objectives a starting point, commits to meeting obligations and to getting better (clause 5.2) | Yes | 2 to 4 pages |
| 2 | Topic-specific policy | What is required for a topic, by whom | Principles and rules for one topic (for example access control, backup), roles, compliance | Yes | 3 to 8 pages |
| 3 | Standard or baseline | What exactly, measurably | Settings, minimum values, approved technologies (for example key lengths, password length, hardening baselines) | Yes | As needed |
| 4 | Procedure or operating instruction | How, step by step | Steps, inputs, outputs, records produced (A.5.37) | Yes, for those who perform it | As needed |
| Guideline | Guidance | Recommended way | Advice and good practice | No | As needed |
| 5 | Record | Proof it happened | Logs, forms, reports, approvals | Kept per retention | Not applicable |

Rules:

1. A lower level never contradicts a higher one. If it does, the higher
   level wins and the lower document is corrected.
2. Each requirement is written once, at the lowest level that can hold it
   with the right approval. Other documents reference it.
3. Every topic-specific policy names the standards and procedures that
   implement it, and the records that prove it operates.

## 3. Naming and ID scheme

<!-- Guidance: One ID per document, never reused. The library uses DOC-ISMS-NNN for ISMS documents; you may keep your own scheme, but map it here and in the documented information register. -->

### 3.1 Document IDs

| Element | Rule | Example |
|---|---|---|
| Register ID | `DOC-ISMS-NNN`, three digits, assigned by the ISMS manager from DOC-ISMS-028, never reused after retirement | DOC-ISMS-041 |
| Type code (optional local prefix) | POL policy, TSP topic-specific policy, STD standard, PRC procedure, GDL guideline, FRM form | TSP-ACC |
| Title | Topic plus document type, no abbreviations | Access control policy |
| File name | `DOC-ISMS-NNN_short-title_vX.Y` | DOC-ISMS-041_access-control-policy_v1.2 |
| Version | Major.minor: major for changes in requirements, minor for editorial or role-holder changes | 1.2 |
| Record IDs | Prefix per record type plus year and sequence | ACC-REV-2027-004 (access review) |

### 3.2 Reserved ranges *(Example)*

| Range | Use |
|---|---|
| DOC-ISMS-001 to 039 | Core ISMS documents (scope, policy, roles, risk, SoA, objectives, support) |
| DOC-ISMS-040 to 079 | Topic-specific policies, standards, procedures and operational registers |
| DOC-ISMS-080 to 099 | Performance evaluation, improvement and certification documents |
| DOC-ISMS-100 to 119 | Family extensions, crosswalks and customer trust documents |
| DOC-ISMS-120 to 139 | Continuity and exception documents |

Documents in the index (section 9) that have no ID in the library register
are marked "[assign]": give them the next free number in the right range
and record it in DOC-ISMS-028.

## 4. Approval levels

<!-- Guidance: Keep these identical to the role model (DOC-ISMS-006 section 4) and the steering committee decision rights (DOC-ISMS-007 section 6). Questions to answer: who can approve a change at 18:00 when production is down? (Answer: procedures are approved by control owners, not the board.) -->

| Level | Prepared by | Reviewed by | Approved by | Approval record |
|---|---|---|---|---|
| 1 Information security policy | ISMS manager | CISO, legal, HR | Top management (clause 5.2) | Approval block and management minutes |
| 2 Topic-specific policy | Policy owner | ISMS manager, affected functions, legal where relevant | Steering committee | Committee decision ID in the approval block |
| 3 Standard or baseline | Control owner | ISMS manager, security engineer | CISO or ISMS manager | Approval block |
| 4 Procedure or operating instruction | Process or control owner | ISMS manager or peer | Process or control owner's manager | Approval block or document system workflow |
| Guideline | Author | ISMS manager | ISMS manager | Approval block |
| Editorial change (any level) | Owner | ISMS manager | ISMS manager | Revision history entry, minor version |

Rules:

1. A document is valid only once approved and published in the master
   location.
2. Approvers must not approve a document they authored alone; a second
   person reviews (segregation per A.5.3).
3. Emergency changes to a standard or procedure may be approved by the
   CISO and ratified at the next normal approval within [30] days.

## 5. Review cadence and triggers

<!-- Guidance: Under A.5.1 a policy must not go stale: review it on a fixed cycle and again whenever something big changes. A review that changes nothing still needs a record (date, reviewer, "no change"). -->

| Level | Planned review *(Example)* | Reviewed by |
|---|---|---|
| 1 Information security policy | Every 12 months | Top management, prepared by ISMS manager |
| 2 Topic-specific policies | Every 12 months | Policy owner |
| 3 Standards and baselines | Every 12 months, or 6 months for fast-changing technology | Control owner |
| 4 Procedures | Every 24 months, or after use in an incident or exercise | Process owner |
| Guidelines | Every 24 months | Author |

Triggers for an unplanned review:

- A significant incident, audit finding or exception pattern that points
  to the document.
- A change in law, regulation or contract recorded in DOC-ISMS-014.
- A change in scope, organisation, technology or supplier that affects the
  document.
- A risk assessment result that changes the required controls.
- An exception renewed more than [twice] for the same requirement.

The ISMS manager runs a monthly report of documents due for review in the
next [60] days from DOC-ISMS-028 and sends reminders to owners.

## 6. Writing rules

<!-- Guidance: Consistent wording makes requirements testable. Auditors check "must" statements against evidence. -->

| Rule | Detail |
|---|---|
| Requirement words | "must" for mandatory requirements, "should" for recommended practice with documented reasons for not following, "may" for options |
| Structure of a topic-specific policy | Purpose; scope; roles; requirements (numbered); exceptions; compliance and consequences; related documents; records produced |
| One requirement per numbered statement | So each can be audited and excepted on its own |
| Testable | Each "must" can be checked against a record or a system setting |
| Plain language | Short sentences; define terms in the document or link the glossary |
| No copied standard text | Paraphrase; cite clause or control numbers only |
| Accessibility | Readable on screen readers; tables with headers |
| Language versions | [English master; translations marked as such, master wins on conflict] |

## 7. Exceptions

<!-- Guidance: Exceptions are normal; untracked exceptions are a nonconformity. Use one route for all levels and give every exception an expiry date. Keep approval limits consistent with DOC-ISMS-006 and DOC-ISMS-007. -->

Any deviation from a mandatory requirement uses the security exception
request (DOC-ISMS-122, `security/security-exception-request`).

```mermaid
flowchart LR
  A["Requester raises exception request"] --> B["Control owner assesses risk and compensating controls"]
  B --> C{"Residual risk level"}
  C -->|"Low, up to 12 months"| D["Risk owner decides"]
  C -->|"Medium, up to 12 months"| E["Risk owner and department head decide"]
  C -->|"High, up to 6 months"| F["Top management decides, with a treatment decision"]
  C -->|"Critical"| X["Not approvable: treat or stop the activity"]
  D --> G["Exception register and expiry reminder"]
  E --> G
  F --> G
  G --> H{"Expired?"}
  H -->|"Reassess"| B
  H -->|"Close"| I["Requirement met; exception closed"]
```

| Rule | Value |
|---|---|
| Who may request | Any document owner, manager or project lead |
| Required content | Requirement excepted, reason, scope (systems, people), risk score per DOC-ISMS-010, compensating controls, expiry, owner |
| Approval authority | By residual risk band, as for risk acceptance in DOC-ISMS-010 section 2.4: Low by the risk owner; Medium by the risk owner plus the department head (top management if the category is Averse, DOC-ISMS-015 section 9 rule 1); High by top management with a treatment decision and a risk acceptance record (DOC-ISMS-019); Critical is not approvable as an exception. The CISO or ISMS manager assesses and advises, the steering committee reviews the register |
| Maximum duration *(Example)* | Low or Medium residual risk: 12 months. High residual risk: 6 months. At expiry the exception is reassessed; a renewal is a new decision at the authority for the new residual score |
| Consistency | Keep these limits identical to DOC-ISMS-006 section 4, DOC-ISMS-007 section 6 and the approver tiers in DOC-ISMS-122 |
| Register | Exception register within DOC-ISMS-122, reported to each steering committee meeting |
| Expiry | On expiry the requirement applies again unless renewed |
| Pattern review | Requirements with several exceptions are reviewed for change (section 5) |

## 8. Communication and acknowledgement

<!-- Guidance: A policy nobody has seen protects nothing, so A.5.1 looks for proof that the people concerned, inside and outside, received it and accepted it. Decide who must acknowledge which documents, and how you prove it. Pitfall: asking everyone to acknowledge every procedure, which trains people to click without reading. -->

| Audience | Documents | Channel | Acknowledgement | When |
|---|---|---|---|---|
| All staff and contractors | DOC-ISMS-001, DOC-ISMS-040 acceptable use policy, DOC-ISMS-073 employee security handbook, DOC-ISMS-054 remote working policy | Onboarding, intranet, learning platform | Electronic acknowledgement | On joining, on major change, annually |
| Administrators and engineers | DOC-ISMS-041 access control, DOC-ISMS-060 secure configuration, DOC-ISMS-065 secure development, `security/privileged-access-standard` | Team channel, role training | Electronic acknowledgement | On role assignment, on major change |
| Managers | DOC-ISMS-006 roles, DOC-ISMS-052 disciplinary process, DOC-ISMS-122 exceptions | Management briefing | Attendance record | Annually |
| Suppliers with access | Relevant policies or a supplier security summary | Contract schedule (DOC-ISMS-068) | Contract signature | On contract and renewal |
| Customers and other interested parties | Public policy summary | Website or trust centre (DOC-ISMS-116) | Not required | On publication |

Rules:

1. Published documents are available in [intranet or document system];
   superseded versions are withdrawn from use and archived.
2. A major version of an acknowledged document triggers re-acknowledgement
   within [30] days.
3. Acknowledgement completion is a KPI in the measurement programme
   (DOC-ISMS-080); target *(Example)*: at least 95% within 30 days.

## 9. Topic-specific policy index

<!-- Guidance: One row per document. Map each to the Annex A controls it supports and to the library template you used. Mark documents not yet written as Planned. Auditors use this index to find the document behind any SoA row; keep the control column consistent with DOC-ISMS-011. Documents without a library ID are marked [assign]. -->

Columns: **Level** 1 to 4 per section 2. **Status**: Approved, Draft,
Planned. Owners and review dates are examples; replace them.

### 9.1 Governance and organisation

| Topic | Document ID | Template | Level | Annex A or clause | Owner | Status |
|---|---|---|---|---|---|---|
| Information security policy | DOC-ISMS-001 | `compliance/information-security-policy` | 1 | 5.2; A.5.1 | Top management | [Approved] |
| Policy framework and index (this document) | DOC-ISMS-005 | `isms/isms-policy-framework` | 2 | 7.5; A.5.1, A.5.36, A.5.37 | ISMS manager | [Approved] |
| Roles, responsibilities and RACI | DOC-ISMS-006 | `isms/isms-roles-raci` | 2 | 5.3; A.5.2, A.5.3, A.5.4 | ISMS manager | [Approved] |
| Authorities and special interest group contacts | DOC-ISMS-069 | `isms/authority-special-interest-contacts` | 4 | A.5.5, A.5.6 | CISO | [Draft] |
| Threat intelligence procedure | DOC-ISMS-045 | `isms/threat-intelligence-procedure` | 4 | A.5.7 | Security operations lead | [Planned] |
| Project information security checklist | DOC-ISMS-046 | `isms/project-information-security-checklist` | 4 | A.5.8 | PMO lead | [Draft] |
| Independent security review checklist | DOC-ISMS-048 | `isms/independent-security-review-checklist` | 4 | A.5.35 | ISMS manager | [Planned] |
| Security operating procedure | DOC-ISMS-049 | `isms/security-operating-procedure` | 4 | A.5.37 | IT operations lead | [Draft] |
| Legal, regulatory and contractual register | DOC-ISMS-014 | `compliance/legal-register` | Record | A.5.31, A.5.32 | Legal lead | [Approved] |

### 9.2 Information and asset management

| Topic | Document ID | Template | Level | Annex A or clause | Owner | Status |
|---|---|---|---|---|---|---|
| Asset inventory | DOC-ISMS-012 | `compliance/asset-inventory` | Record | A.5.9 | IT operations lead | [Approved] |
| Acceptable use policy | DOC-ISMS-040 | `compliance/acceptable-use-policy` | 2 | A.5.10, A.5.11, A.5.32 | ISMS manager | [Approved] |
| Data classification policy | [assign] | `data/data-classification-policy` | 2 | A.5.12 | Data governance lead | [Approved] |
| Information labelling and handling procedure | DOC-ISMS-042 | `isms/information-labelling-handling-procedure` | 4 | A.5.13 | Data governance lead | [Draft] |
| Information transfer policy | DOC-ISMS-043 | `isms/information-transfer-policy` | 2 | A.5.14 | CISO | [Draft] |
| Data retention and deletion standard | [assign] | `data/data-retention-deletion-standard` | 3 | A.5.33, A.8.10 | Data governance lead | [Approved] |
| Data masking and DLP standard | DOC-ISMS-062 | `isms/data-masking-dlp-standard` | 3 | A.8.11, A.8.12 | Security engineer | [Planned] |
| Privacy and PII protection (PIMS scope and roles) | DOC-ISMS-100 | `isms/pims-27701-scope-roles` | 2 | A.5.34 | DPO or privacy lead | [Planned] |
| AI usage policy | [assign] | `ai-data/ai-usage-policy` | 2 | A.5.10 (topic added by the organisation) | CTO | [Draft] |

### 9.3 Access and identity

| Topic | Document ID | Template | Level | Annex A or clause | Owner | Status |
|---|---|---|---|---|---|---|
| Access control policy | DOC-ISMS-041 | `isms/access-control-policy` | 2 | A.5.15 to A.5.18, A.8.2, A.8.3, A.8.5 | CISO | [Approved] |
| Privileged access standard | [assign] | `security/privileged-access-standard` | 3 | A.8.2, A.8.18 | IT operations lead | [Approved] |
| Secrets management standard | [assign] | `security/secrets-management-standard` | 3 | A.5.17, A.8.24 | Platform lead | [Draft] |
| Access review procedure and records | [assign] | `ops/access-review` | 4 | A.5.18 | Asset owners | [Approved] |

### 9.4 Suppliers and cloud

| Topic | Document ID | Template | Level | Annex A or clause | Owner | Status |
|---|---|---|---|---|---|---|
| Supplier register | DOC-ISMS-066 | `isms/supplier-register` | Record | A.5.19, A.5.22 | Procurement lead | [Approved] |
| Supplier security assessment | DOC-ISMS-067 | `compliance/supplier-security-assessment` | 4 | A.5.19, A.5.21 | Procurement lead | [Approved] |
| Supplier security agreement | DOC-ISMS-068 | `isms/supplier-security-agreement-27036` | 3 | A.5.20, A.5.21 | Legal lead | [Draft] |
| Cloud services security policy | DOC-ISMS-044 | `isms/cloud-services-security-policy` | 2 | A.5.23 | CTO | [Approved] |
| Cloud exit plan | DOC-ISMS-076 | `isms/cloud-exit-plan` | 4 | A.5.23, A.5.30 | CTO | [Planned] |
| Outsourced development security requirements | DOC-ISMS-077 | `isms/outsourced-development-security` | 3 | A.8.30 | Engineering lead | [Planned] |
| SaaS productivity suite security baseline | DOC-ISMS-075 | `isms/saas-productivity-security-baseline` | 3 | A.5.23, A.8.9 | IT operations lead | [Draft] |

### 9.5 Incidents and continuity

| Topic | Document ID | Template | Level | Annex A or clause | Owner | Status |
|---|---|---|---|---|---|---|
| Incident response plan | DOC-ISMS-020 | `compliance/incident-response-plan` | 2 | A.5.24 to A.5.28 | CISO | [Approved] |
| Security event reporting procedure | DOC-ISMS-023 | `isms/security-event-reporting-procedure` | 4 | A.6.8, A.5.25 | Security operations lead | [Approved] |
| Business continuity plan | DOC-ISMS-121 | `compliance/business-continuity` | 2 | A.5.29 | BC manager | [Approved] |
| ICT readiness for business continuity plan | DOC-ISMS-047 | `isms/ict-readiness-business-continuity-plan` | 4 | A.5.30, A.8.14 | IT operations lead | [Draft] |
| Crisis management and communications plan | DOC-ISMS-078 | `isms/crisis-management-communications-plan` | 2 | A.5.29 | COO | [Planned] |
| Backup policy | DOC-ISMS-061 | `isms/backup-policy` | 2 | A.8.13 | IT operations lead | [Approved] |
| Disaster recovery plan | [assign] | `ops/disaster-recovery-plan` | 4 | A.5.30, A.8.14 | IT operations lead | [Approved] |

### 9.6 People

| Topic | Document ID | Template | Level | Annex A or clause | Owner | Status |
|---|---|---|---|---|---|---|
| Personnel screening procedure | DOC-ISMS-050 | `isms/personnel-screening-procedure` | 4 | A.6.1 | HR lead | [Approved] |
| Employee security handbook (terms of employment) | DOC-ISMS-073 | `isms/employee-security-handbook` | 2 | A.6.2, A.5.10 | HR lead | [Approved] |
| Security awareness programme | [assign] | `security/security-awareness-program` | 2 | A.6.3; clause 7.3 | ISMS manager | [Approved] |
| Phishing simulation plan | DOC-ISMS-074 | `isms/phishing-simulation-plan` | 4 | A.6.3 | ISMS manager | [Draft] |
| Disciplinary process for security breaches | DOC-ISMS-052 | `isms/security-disciplinary-process` | 4 | A.6.4 | HR lead | [Approved] |
| Offboarding security checklist | DOC-ISMS-053 | `isms/offboarding-security-checklist` | 4 | A.6.5, A.5.11 | HR lead | [Approved] |
| Confidentiality agreement | DOC-ISMS-051 | `isms/confidentiality-nda` | Form | A.6.6 | Legal lead | [Approved] |
| Remote working policy | DOC-ISMS-054 | `isms/remote-working-policy` | 2 | A.6.7 | HR lead | [Approved] |

### 9.7 Physical

| Topic | Document ID | Template | Level | Annex A or clause | Owner | Status |
|---|---|---|---|---|---|---|
| Physical security policy | DOC-ISMS-055 | `isms/physical-security-policy` | 2 | A.7.1 to A.7.6, A.7.8, A.7.11 to A.7.13 | Facilities lead | [Approved] |
| Clear desk and clear screen policy | DOC-ISMS-056 | `isms/clear-desk-clear-screen-policy` | 2 | A.7.7 | Facilities lead | [Approved] |
| Equipment disposal and reuse record | DOC-ISMS-057 | `isms/equipment-disposal-reuse-record` | Record | A.7.10, A.7.14 | IT operations lead | [Approved] |
| Data centre and colocation assessment | DOC-ISMS-079 | `isms/data-centre-colocation-assessment` | 4 | A.7.1 to A.7.5, A.7.11, A.5.22 | IT operations lead | [Planned] |

### 9.8 Technology

| Topic | Document ID | Template | Level | Annex A or clause | Owner | Status |
|---|---|---|---|---|---|---|
| Endpoint and BYOD policy | DOC-ISMS-058 | `isms/endpoint-device-byod-policy` | 2 | A.8.1, A.7.9 | IT operations lead | [Approved] |
| Malware protection standard | DOC-ISMS-059 | `isms/malware-protection-standard` | 3 | A.8.7 | Security engineer | [Approved] |
| Vulnerability management policy | [assign] | `security/vulnerability-management-policy` | 2 | A.8.8 | Security operations lead | [Approved] |
| Vulnerability remediation tracker | DOC-ISMS-072 | `isms/vulnerability-remediation-tracker` | Record | A.8.8 | Security operations lead | [Approved] |
| Secure configuration baseline | DOC-ISMS-060 | `isms/secure-configuration-baseline` | 3 | A.8.9, A.8.17, A.8.19 | IT operations lead | [Draft] |
| Capacity plan | [assign] | `ops/capacity-plan` | 4 | A.8.6 | Platform lead | [Approved] |
| Security logging standard | [assign] | `security/security-logging-standard` | 3 | A.8.15, A.8.17 | Security engineer | [Approved] |
| Security monitoring procedure | DOC-ISMS-064 | `isms/security-monitoring-procedure` | 4 | A.8.16 | Security operations lead | [Draft] |
| Network security standard | DOC-ISMS-063 | `isms/network-security-standard` | 3 | A.8.20 to A.8.23 | Network lead | [Approved] |
| Cryptography standard | [assign] | `security/cryptography-standard` | 3 | A.8.24 | Security architect | [Approved] |
| Cryptographic key and certificate register | DOC-ISMS-070 | `isms/cryptographic-key-register` | Record | A.8.24 | Security architect | [Approved] |
| Secure development policy | DOC-ISMS-065 | `isms/secure-development-policy` | 2 | A.8.4, A.8.25 to A.8.29, A.8.31, A.8.33 | Engineering lead | [Approved] |
| Secure coding standard | [assign] | `security/secure-coding-standard` | 3 | A.8.28 | Engineering lead | [Approved] |
| Change enablement policy | [assign] | `ops/change-enablement-policy` | 2 | A.8.32 | IT operations lead | [Approved] |
| Audit testing rules (in the internal audit programme) | DOC-ISMS-082 | `compliance/internal-audit-program` | 4 | A.8.34 | Internal auditor | [Approved] |

### 9.9 Coverage check

Every applicable Annex A control in the SoA (DOC-ISMS-011) must point to at
least one document in this index or to a record that proves it. Run this
check at each annual review and before certification audits.

A control counts as covered only when at least one of its documents is
Approved. A control whose documents are all Draft or Planned is a gap:
list it with the planned approval date and track it in the risk treatment
plan (DOC-ISMS-013). Result for the example statuses in sections 9.1 to
9.8, assuming all 93 controls are applicable in this example:

| Theme | Controls | Covered by an Approved document *(Example)* | Gaps *(Example)* |
|---|---|---|---|
| A.5 Organizational | 37 | 28 | 9: A.5.5, A.5.6, A.5.7, A.5.8, A.5.13, A.5.14, A.5.20, A.5.34, A.5.35 |
| A.6 People | 8 | 8 | 0 |
| A.7 Physical | 14 | 14 | 0 |
| A.8 Technological | 34 | 28 | 6: A.8.9, A.8.11, A.8.12, A.8.16, A.8.19, A.8.30 |
| **Total** | **93** | **78** | **15** |

## 10. Compliance monitoring and enforcement

<!-- Guidance: A.5.36 is about checking, on a regular cycle, that people and systems really follow the documents in this index. Say how you check, who reports, and what happens on a breach (A.6.4). -->

| Method | Covers | Who | Frequency *(Example)* | Output |
|---|---|---|---|---|
| Automated compliance checks | Configuration standards, endpoint, cloud posture | Control owners | Continuous, reported monthly | Compliance dashboard in DOC-ISMS-081 |
| Manager self-assessment | Topic-specific policies per department | Department heads | Annually | Self-assessment record |
| Internal audit | All levels | Internal auditor | Per audit programme (DOC-ISMS-082) | Audit report DOC-ISMS-084 |
| Independent review | ISMS approach and implementation (A.5.35) | Independent reviewer | Planned intervals and on significant change | DOC-ISMS-048 checklist |
| Exception register review | Open and expired exceptions | CISO | Every steering committee meeting | Committee minutes |

When non-compliance is found:

1. The finding is recorded as a nonconformity or observation
   (DOC-ISMS-087) and the owner corrects it.
2. Deliberate or repeated breaches by individuals follow the disciplinary
   process (DOC-ISMS-052), applied fairly and proportionately.
3. Patterns of non-compliance trigger a review of the document itself
   (section 5): the requirement may be wrong, unclear or impractical.

## 11. Size tiers

<!-- Guidance: The number of documents should match the organisation. Small organisations often combine several topic-specific policies into one document with clear sections; that is acceptable if each topic still has an owner and review date. These tiers are the library's working tiers, not official definitions. -->

| Topic | Small: Quillmere Analytics Ltd (46 staff) | Medium: Quillmere Health Systems (320 staff) | Large: Quillmere Group (2,400 staff, 6 sites) |
|---|---|---|---|
| Number of level 2 policies *(Example)* | 6 combined policies (for example one "IT and access" policy covering access, endpoint, backup and network topics) | 18 separate topic-specific policies | 22 group policies plus site-specific procedures for OT and physical security |
| Standards | Few; cloud provider and SaaS baselines carry most settings | Separate standards for cryptography, logging, configuration | Group standards with site annexes; OT standards per plant |
| Approval of level 2 | Monthly leadership meeting acting as steering committee | Steering committee | Group security council; sites approve local procedures |
| Document system | Shared drive with version history and a simple register | Document management system with approval workflow | Integrated document system shared with ISO 9001 and ISO 22301 |
| Acknowledgement | Learning platform or e-signature for 46 staff | Learning platform with role-based assignments | HR system with role- and site-based assignments, local language versions |
| Exceptions per year *(Example)* | About 5 | About 30 | About 120, reviewed per site and at group level |
| ISMS manager effort on the framework | Part of the 0.5 FTE role | Shared by the ISMS manager and the 3-person security team | A document controller in the 14-person security office |

## 12. Records and evidence

<!-- Guidance: List the records that prove the framework operates. Link each in the control evidence matrix (DOC-ISMS-033, `isms/control-evidence-matrix`). -->

| Record | Proves | Kept by | Where | Retention *(Example)* |
|---|---|---|---|---|
| Approval blocks and committee decision IDs for each document | Approved by the right level (A.5.1, 7.5.2) | Document owners, ISMS manager | Document system | Life of document plus [3] years |
| Documented information register (DOC-ISMS-028) | Documents identified, versioned, owned, located | ISMS manager | Register | Current plus yearly snapshots for [3] years |
| Review records (date, reviewer, outcome) | Planned reviews done | Document owners | Revision history | Life of document plus [3] years |
| Publication and withdrawal log | Current versions available, obsolete ones withdrawn (7.5.3) | ISMS manager | Document system history | [3] years |
| Acknowledgement reports | Policies communicated and acknowledged (A.5.1) | HR, ISMS manager | Learning platform or HR system | Employment plus [3] years |
| Exception register (DOC-ISMS-122) | Deviations controlled | CISO | Exception register | [3] years after closure |
| Compliance check results | Compliance reviewed (A.5.36) | Control owners | Dashboard exports, self-assessments | [3] years |
| Coverage check (section 9.9) | Every applicable control has a document | ISMS manager | This document or review note | [3] years |

## 13. References

<!-- Guidance: Cite the editions used and check them at every review. -->

| Reference | Edition | Use |
|---|---|---|
| ISO/IEC 27001:2022 + Amd 1:2024 | Current (https://www.iso.org/standard/82875.html, Amd 1: https://www.iso.org/standard/88435.html) | Clauses 5.2, 7.5; A.5.1, A.5.36, A.5.37 |
| ISO/IEC 27002:2022 | Current (https://www.iso.org/standard/75652.html) | Guidance on topic-specific policies and their review |
| ISO/IEC 27003:2017 | Current; a revision is in progress, check for a newer edition (https://www.iso.org/standard/63417.html) | Guidance on policy and documented information |
| ISO/IEC 27000:2026 | Current, 6th edition (https://www.iso.org/standard/84257.html) | Overview and vocabulary of the family |

Related templates: `compliance/information-security-policy`,
`isms/isms-documented-information-register`, `compliance/controlled-document`,
`security/security-exception-request`, `isms/isms-roles-raci`,
`isms/isms-steering-committee-charter`, `isms/isms-manual`,
`compliance/statement-of-applicability`, `isms/control-evidence-matrix`,
and every template listed in section 9.

## Standard and licence note

Structure aligned with ISO/IEC 27001:2022 + Amd 1:2024 (clauses 5.2 and
7.5, Annex A controls A.5.1, A.5.36 and A.5.37), with guidance from ISO/IEC
27002:2022 and ISO/IEC 27003:2017. The framework text, hierarchy, ID
scheme, index and examples are original. No ISO/IEC text is reproduced:
control numbers are cited with short labels written for this template, not
official titles or control text. Obtain the official standards from ISO,
IEC or your national standards body, and check the current edition before
use (ISO/IEC 27003 is under revision). Quillmere entities are fictional.

Template licence: MIT.