# ISMS Measurement Programme: [Organization name]

> Defines what the information security management system (ISMS) of
> [Organization name] monitors and measures, how, when, who collects the
> data and who analyses and evaluates the results. It supports ISO/IEC
> 27001:2022 + Amd 1:2024 clause 9.1 (monitoring, measurement, analysis
> and evaluation) and the objectives in clause 6.2, with guidance from
> ISO/IEC 27004:2016 (a revision is in progress; check for a newer
> edition). It contains metric definition cards and more than twenty
> *Example* metrics covering ISMS processes and control effectiveness.
> Replace every `[bracketed]` value and every row marked *Example*.

<!--
Guidance: How to use this template
- When to use: once the risk treatment plan and the objectives register
  exist, and at least three months before the first internal audit, so
  that the audit and the management review see real trend data.
- Fill first: section 2 (what the programme must answer), then the
  metric catalogue in section 5, starting with one metric per
  information security objective (DOC-ISMS-024).
- Main pitfall: measuring what the tools happen to report instead of
  what management needs to decide. Every metric needs an owner, a target
  and a decision it informs; delete metrics nobody acts on.
- Clause 9.1 is about knowing, with numbers you can show, whether your
  security is working and whether the ISMS itself is earning its keep;
  keep the results so an auditor can see them. This document is the method;
  the results live in the performance report (DOC-ISMS-081).
- Related templates: `isms/isms-performance-report`,
  `compliance/objectives-register`, `isms/isms-annual-calendar`,
  `isms/control-evidence-matrix`, `compliance/management-review`,
  `security/security-metrics-report`, `compliance/risk-register`.
-->

## Document control

<!-- Guidance: The measurement programme is a controlled document. Adding or retiring a metric that feeds an objective is a minor version; changing a target or formula that management relies on needs the approval of the objective owner. -->

| Field | Value |
|---|---|
| Document ID | [DOC-ISMS-080] |
| Version | [1.0] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@isms-manager] |
| Approvers/reviewers | [@ciso], [@coo], [@internal-audit] |
| Last updated | YYYY-MM-DD |
| Classification | [Internal] |
| Standard and edition | ISO/IEC 27001:2022 + Amd 1:2024 (clauses 6.2, 9.1); guidance ISO/IEC 27004:2016 |
| ISMS scope reference | [DOC-ISMS-002] |
| Objectives reference | [DOC-ISMS-024, objectives register version x.y] |
| Results reported in | [DOC-ISMS-081, ISMS performance report] |
| Measurement period | [Monthly collection, quarterly reporting] |
| Next scheduled review | YYYY-MM-DD |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| ISMS owner | [@isms-manager] | [Prepared] | YYYY-MM-DD |
| Chief information security officer | [@ciso] | [Reviewed] | YYYY-MM-DD |
| Top management | [@coo] | [Approved / Approved with changes] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change |
|---|---|---|---|
| 1.0 *(Example)* | YYYY-MM-DD | [@isms-manager] | First programme with 22 metrics (MET-001 to MET-022), approved before the first internal audit |
| 1.1 *(Example)* | YYYY-MM-DD | [@isms-manager] | MET-019 target raised from 90% to 95% after four quarters on target; MET-023 to MET-025 added (supplier reviews, repeat findings, certificate expiry) |
| [x.y] | YYYY-MM-DD | [@author] | [Change summary] |

## Contents

1. Purpose and scope
2. Information needs
3. Measurement principles and method
4. Roles and responsibilities
5. Metric catalogue
6. Metric definition cards
7. Collection, analysis and evaluation cycle
8. Thresholds, targets and escalation
9. Data quality and validity
10. Size tiers
11. Records and evidence
12. Review of the programme
13. References

## 1. Purpose and scope

<!-- Guidance: Say what the programme covers and what it is for. Questions to answer: which ISMS scope, which objectives, which management forums consume the results? Pitfall: a programme scoped to "security tooling" only, which leaves the ISMS processes (audit, review, training, risk) unmeasured. -->

This programme sets out how [Organization name] determines whether its
ISMS achieves its intended outcomes. It covers all processes and
controls inside the ISMS scope defined in [DOC-ISMS-002] and produces
the data used in the performance report (DOC-ISMS-081), the internal
audit programme (DOC-ISMS-082) and the management review (DOC-ISMS-085).

The programme answers two questions that clause 9.1 asks every ISMS to
answer:

- **Performance**: are the controls and processes doing what they were
  designed to do, at the level the organization decided?
- **Effectiveness**: is the ISMS as a whole achieving its objectives,
  treating risk to an acceptable level and improving over time?

Out of scope: [operational IT service metrics not related to security,
such as ticket volumes, unless they feed a security metric].

## 2. Information needs

<!-- Guidance: Start from the decisions management takes, not from the data available. Each information need should trace to an objective, a top risk, a legal or contractual commitment, or an interested party requirement from DOC-ISMS-003. An auditor will pick one objective and ask how you know whether it is met. -->

| Need ID | Information need | Source of the need | Decision it informs | Metrics |
|---|---|---|---|---|
| NEED-01 *(Example)* | Are critical vulnerabilities closed fast enough to stay within risk appetite? | Objective OBJ-02, RISK-011 | Add patching capacity or accept risk | MET-005, MET-006 |
| NEED-02 *(Example)* | Do people recognise and report phishing? | Objective OBJ-03, RISK-002 | Change awareness content or frequency | MET-012, MET-013, MET-014 |
| NEED-03 *(Example)* | Is access granted and removed on time? | Customer contracts, RISK-006 | Fix joiner and leaver workflow | MET-001, MET-002, MET-003 |
| NEED-04 *(Example)* | Can we restore critical services within the agreed recovery time? | Customer SLA, BIA (DOC-ISMS-120) | Invest in recovery or change commitments | MET-009, MET-010 |
| NEED-05 *(Example)* | Is the ISMS itself running to plan? | Clause 9.1, management review input | Reprioritise ISMS work or resources | MET-017 to MET-022 |
| [NEED-NN] | [need] | [source] | [decision] | [MET-NNN] |

## 3. Measurement principles and method

<!-- Guidance: Under clause 9.1 a number is only useful if it can be repeated and compared over time. Write down the formula, the data source and the counting rules so that a different person next quarter would get the same number. ISO/IEC 27004:2016 describes measurement types and how to build measures; use it as guidance, not as a checklist. -->

### 3.1 Principles

1. **Decision first.** A metric exists only if someone will act on it.
2. **Defined once.** Every metric has a definition card (section 6);
   the card, not the spreadsheet, is the authority.
3. **Comparable over time.** Do not change a formula silently. A change
   is a new version of the card, and the trend line is annotated.
4. **Automated where possible.** Prefer counts exported from systems of
   record (identity provider, ticketing, vulnerability scanner, learning
   platform) over manual estimates.
5. **Balanced.** Combine process metrics (are we doing the work?) with
   outcome metrics (is the risk lower?).
6. **Proportionate.** Start with fewer metrics that are reliable rather
   than many that are not.

### 3.2 Types of metric

| Type | Question | Example |
|---|---|---|
| Implementation | Is the control in place? | Percentage of endpoints enrolled in device management |
| Performance (process) | Is the activity done on time and to standard? | Access reviews completed by the due date |
| Effectiveness (outcome) | Does the control reduce risk? | Phishing report rate, repeat audit findings |
| ISMS management | Is the management system working? | Corrective actions closed on time, objectives on track |

### 3.3 How a metric is built

Each metric combines one or more raw counts (for example "leavers in the
month" and "leavers whose access was removed within one working day")
into a calculated value (a percentage, a mean or a duration), which is
compared with a target and thresholds to produce a status (green, amber,
red). The definition card records each step.

```mermaid
flowchart LR
  A["Information need"] --> B["Raw counts from data source"]
  B --> C["Calculated value (formula)"]
  C --> D{"Compare with target and thresholds"}
  D -- "Green" --> E["Report and monitor"]
  D -- "Amber" --> F["Owner explains and plans"]
  D -- "Red" --> G["Escalate and raise action"]
  E --> H["Performance report (DOC-ISMS-081)"]
  F --> H
  G --> H
```

## 4. Roles and responsibilities

<!-- Guidance: Clause 9.1 needs named people for both jobs: gathering the numbers and judging what they mean. Name roles, not departments, and keep collection separate from evaluation where the size of the organization allows it. -->

| Role | Responsibility |
|---|---|
| Metric owner | Accountable for the metric: data quality, explanation of variances, actions when off target |
| Data collector | Extracts the raw counts on the collection date and stores the extract |
| ISMS manager | Maintains this programme, consolidates results, checks calculations, prepares the performance report |
| CISO or security lead | Analyses trends across metrics and proposes conclusions for management |
| Top management | Evaluates the results in management review and decides on actions and resources |
| Internal audit | Tests a sample of metrics for accuracy and reproducibility |

## 5. Metric catalogue

<!-- Guidance: List every metric in one table so gaps are visible. Each metric links to at least one objective, risk or control. The rows below are worked examples for a medium organisation; keep the ones that fit, change the targets to your own risk appetite and delete the rest. Do not copy targets as if they were benchmarks: they are illustrations. -->

Status thresholds use three bands: **Green** at or better than target,
**Amber** within the tolerance stated, **Red** worse than tolerance.

| ID | Metric | Type | Link (objective, risk, control) | Formula | Frequency | Target | Tolerance (amber) | Owner |
|---|---|---|---|---|---|---|---|---|
| MET-001 *(Example)* | Leaver access removed within 1 working day | Performance | OBJ-04, A.5.18 | removed on time / leavers x 100 | Monthly | 98% | 95% to 97.9% | [@it-ops-lead] |
| MET-002 *(Example)* | Quarterly access reviews completed on time | Performance | A.5.18, A.8.2 | reviews done by due date / reviews scheduled x 100 | Quarterly | 100% | 90% to 99.9% | [@it-ops-lead] |
| MET-003 *(Example)* | Privileged accounts with phishing-resistant MFA | Implementation | A.8.2, A.8.5 | privileged accounts with such MFA / privileged accounts x 100 | Monthly | 100% | 97% to 99.9% | [@iam-lead] |
| MET-004 *(Example)* | Endpoints compliant with baseline | Implementation | A.8.1, A.8.9 | compliant endpoints / managed endpoints x 100 | Monthly | 97% | 93% to 96.9% | [@endpoint-lead] |
| MET-005 *(Example)* | Critical vulnerabilities remediated within SLA | Performance | OBJ-02, A.8.8, RISK-011 | closed within SLA / critical due in period x 100 | Monthly | 95% | 90% to 94.9% | [@vuln-lead] |
| MET-006 *(Example)* | Mean days to remediate high and critical vulnerabilities | Effectiveness | A.8.8 | sum of days open / number closed | Monthly | 14 days or fewer | 15 to 21 days | [@vuln-lead] |
| MET-007 *(Example)* | Cloud configuration findings open beyond 30 days | Effectiveness | A.5.23, A.8.9 | count | Monthly | 0 high, 5 or fewer medium | 1 to 2 high | [@cloud-lead] |
| MET-008 *(Example)* | Backup jobs successful | Performance | A.8.13 | successful jobs / scheduled jobs x 100 | Weekly | 99% | 97% to 98.9% | [@it-ops-lead] |
| MET-009 *(Example)* | Restore tests meeting recovery time objective | Effectiveness | A.8.13, A.5.30 | tests within RTO / tests performed x 100 | Quarterly | 100% | 75% to 99.9% | [@it-ops-lead] |
| MET-010 *(Example)* | Disaster recovery or continuity exercises held as planned | Performance | A.5.29, A.5.30 | exercises held / exercises planned x 100 | Half-yearly | 100% | none | [@bc-lead] |
| MET-011 *(Example)* | Security awareness training completion | Performance | OBJ-03, A.6.3 | staff completed / staff required x 100 | Monthly | 95% | 90% to 94.9% | [@hr-lead] |
| MET-012 *(Example)* | Phishing simulation click rate | Effectiveness | OBJ-03, A.6.3, RISK-002 | users who clicked / users who received x 100 | Quarterly | 5% or lower | 5.1% to 8% | [@awareness-lead] |
| MET-013 *(Example)* | Phishing simulation report rate | Effectiveness | A.6.8 | users who reported / users who received x 100 | Quarterly | 60% or higher | 45% to 59.9% | [@awareness-lead] |
| MET-014 *(Example)* | Real suspicious e-mails reported by staff | Effectiveness | A.6.8 | count per month | Monthly | Trend up | none (trend only) | [@soc-lead] |
| MET-015 *(Example)* | Security incidents by severity | Effectiveness | A.5.24 to A.5.27 | count by severity | Monthly | 0 severity 1 | 1 severity 1 with review done | [@incident-manager] |
| MET-016 *(Example)* | Mean time to contain severity 1 and 2 incidents | Effectiveness | A.5.26 | sum of hours to contain / incidents | Quarterly | 8 hours or less | 8.1 to 24 hours | [@incident-manager] |
| MET-017 *(Example)* | Internal audit programme delivered as planned | ISMS management | Clause 9.2 | audits completed / audits planned to date x 100 | Quarterly | 100% | 80% to 99.9% | [@internal-audit] |
| MET-018 *(Example)* | Corrective actions closed by due date | ISMS management | Clause 10.2 | actions closed on time / actions due x 100 | Monthly | 90% | 80% to 89.9% | [@isms-manager] |
| MET-019 *(Example)* | Policies reviewed within their review date | ISMS management | A.5.1, clause 7.5 | policies in date / policies in register x 100 | Quarterly | 95% | 85% to 94.9% | [@isms-manager] |
| MET-020 *(Example)* | Risk treatment actions on schedule | ISMS management | Clause 6.1.3, 8.3 | actions on schedule / open actions x 100 | Monthly | 85% | 70% to 84.9% | [@isms-manager] |
| MET-021 *(Example)* | Risks outside appetite without approved treatment | Effectiveness | Clause 6.1.2, 8.2 | count | Monthly | 0 | none | [@isms-manager] |
| MET-022 *(Example)* | Information security objectives on track | ISMS management | Clause 6.2 | objectives green / objectives x 100 | Quarterly | 80% | 60% to 79.9% | [@ciso] |
| MET-023 *(Example)* | Critical suppliers with current security review | Performance | A.5.19, A.5.22 | suppliers reviewed in 12 months / critical suppliers x 100 | Quarterly | 100% | 90% to 99.9% | [@procurement-lead] |
| MET-024 *(Example)* | Repeat findings at internal or external audit | Effectiveness | Clause 10.1 | count of findings raised again within 12 months | Per audit | 0 | 1 | [@isms-manager] |
| MET-025 *(Example)* | Certificates and keys expiring within 30 days without a renewal ticket | Performance | A.8.24 | count | Weekly | 0 | none | [@platform-lead] |
| [MET-NNN] | [metric] | [type] | [link] | [formula] | [frequency] | [target] | [tolerance] | [@owner] |

## 6. Metric definition cards

<!-- Guidance: Write one card per metric. The card is what makes the result reproducible: an auditor may ask a second person to recompute last quarter's figure from the stored extract. Include the counting rules for edge cases (contractors, accounts created and removed in the same month, duplicate scanner findings). -->

### 6.1 Card format

| Field | Content |
|---|---|
| Metric ID and name | [MET-NNN, name] |
| Information need and objective link | [NEED-NN, OBJ-NN, RISK-NNN, control] |
| Definition | [what is counted, in one sentence] |
| Formula | [calculation, units] |
| Counting rules | [inclusions, exclusions, edge cases] |
| Data source | [system of record and report name] |
| Collection method | [automated export / manual count / sample] |
| Collection frequency and date | [e.g. first working day of the month] |
| Reporting frequency and forum | [e.g. quarterly, performance report and steering committee] |
| Target and tolerance | [green, amber, red] |
| Owner and collector | [@owner], [@collector] |
| Analysis and evaluation | [who analyses, who evaluates, where] |
| Action when red | [escalation and expected response] |
| Card version | [x.y, date] |

### 6.2 Worked card: MET-001 *(Example)*

| Field | Content |
|---|---|
| Metric ID and name | MET-001, leaver access removed within 1 working day |
| Information need and objective link | NEED-03, OBJ-04, RISK-006, A.5.18 |
| Definition | Share of leavers whose identity provider account and all privileged accounts were disabled no later than the end of the next working day after their last day |
| Formula | leavers removed on time / all leavers in the month x 100, rounded to one decimal place |
| Counting rules | Includes employees and contractors. Excludes internal transfers (mover access is checked through the access reviews in MET-002). A leaver counts in the month of the last working day |
| Data source | HR system leaver report joined with the identity provider audit log |
| Collection method | Automated export, reconciled by the collector |
| Collection frequency and date | Monthly, third working day |
| Reporting frequency and forum | Quarterly in DOC-ISMS-081 |
| Target and tolerance | Green 98% or higher, amber 95% to 97.9%, red below 95% |
| Owner and collector | [@it-ops-lead], [@service-desk-analyst] |
| Analysis and evaluation | ISMS manager analyses the trend; steering committee evaluates quarterly |
| Action when red | Root cause per late case, corrective action in DOC-ISMS-087 if two consecutive months are red |
| Card version | 1.0, YYYY-MM-DD |

Worked result *(Example)*: over one quarter (three monthly counts
combined) 27 people left and 26 were removed on time, so MET-001 =
26 / 27 x 100 = 96.3%, which is amber. The late case was a contractor whose end date was not recorded in the HR
system; the action was to add contractor end dates to the HR workflow.

### 6.3 Worked card: MET-005 *(Example)*

| Field | Content |
|---|---|
| Metric ID and name | MET-005, critical vulnerabilities remediated within SLA |
| Information need and objective link | NEED-01, OBJ-02, RISK-011, A.8.8 |
| Definition | Share of critical vulnerabilities whose remediation due date fell in the period and which were fixed or formally excepted by that date |
| Formula | closed or excepted by due date / critical due in period x 100 |
| Counting rules | SLA as set in the vulnerability management policy (*Example*: 14 days for critical). One finding per asset and vulnerability. An approved exception (DOC-ISMS-122) counts as on time only if approved before the due date |
| Data source | Vulnerability remediation tracker (DOC-ISMS-072) |
| Collection method | Automated export from the scanner and tracker |
| Collection frequency and date | Monthly, second working day |
| Reporting frequency and forum | Quarterly in DOC-ISMS-081 |
| Target and tolerance | Green 95% or higher, amber 90% to 94.9%, red below 90% |
| Owner and collector | [@vuln-lead], [@security-analyst] |
| Analysis and evaluation | Security lead analyses ageing and blockers; steering committee evaluates quarterly |
| Action when red | Review capacity and blockers with system owners; report to steering committee |
| Card version | 1.0, YYYY-MM-DD |

Worked result *(Example)*: in a quarter 64 critical findings fell due
and 61 were closed or excepted on time, so MET-005 = 61 / 64 x 100 =
95.3%, which is green.

## 7. Collection, analysis and evaluation cycle

<!-- Guidance: Clause 9.1 needs a timetable for both collecting the numbers and reviewing them. Put the dates in the annual calendar (DOC-ISMS-032) so they happen. Pitfall: collecting monthly but analysing only once a year before the audit. -->

| Step | When | Who | Output |
|---|---|---|---|
| 1. Collect raw counts | [Monthly, by working day 3] | Data collectors | Stored extracts in the metrics folder |
| 2. Calculate and validate | [Monthly, by working day 5] | ISMS manager | Metrics workbook updated, anomalies queried |
| 3. Owner commentary | [Monthly, by working day 8] | Metric owners | Explanation for every amber or red value |
| 4. Analyse trends | [Quarterly] | CISO or security lead | Trend analysis, links between metrics, conclusions |
| 5. Report | [Quarterly] | ISMS manager | Performance report (DOC-ISMS-081) |
| 6. Evaluate and decide | [Quarterly steering committee, annual management review] | Top management | Decisions and actions recorded in minutes |
| 7. Act | [As decided] | Action owners | Corrective actions (DOC-ISMS-087), improvements (DOC-ISMS-088) |

```mermaid
flowchart TD
  A["1. Collect raw counts"] --> B["2. Calculate and validate"]
  B --> C["3. Owner commentary"]
  C --> D["4. Analyse trends"]
  D --> E["5. Report (DOC-ISMS-081)"]
  E --> F["6. Evaluate and decide"]
  F --> G["7. Act: corrective action or improvement"]
  G --> H["Review the programme (section 12)"]
  H --> A
```

## 8. Thresholds, targets and escalation

<!-- Guidance: Targets come from risk appetite (DOC-ISMS-015) and objectives (DOC-ISMS-024). Write what happens at each status so a red value leads to action rather than discussion. An auditor checks that red values in past reports have a recorded response. -->

| Status | Meaning | Required response | Time limit *(Example)* |
|---|---|---|---|
| Green | At or better than target | Report; no action required | Not applicable |
| Amber | Within tolerance but below target | Owner explains cause and planned recovery in the commentary | Next monthly cycle |
| Red | Worse than tolerance | Owner raises an action; ISMS manager informs the CISO; steering committee reviews | Action raised within 10 working days |
| Red for 2 consecutive periods | Persistent failure | Nonconformity or risk review, as appropriate; top management informed | Next steering committee |

Targets are reviewed once a year. Raise a target that has been green for
four consecutive quarters if the risk still justifies effort; lower one
only with a written reason and the objective owner's approval.

## 9. Data quality and validity

<!-- Guidance: A metric is only as good as its data. Record known limitations next to the value rather than hiding them. Internal audit should re-perform a sample each year. -->

- **Completeness**: confirm the data source covers the full population
  in scope (for example all endpoints, not only those reporting to the
  console). Record coverage as a percentage when it is below 100%.
- **Accuracy**: reconcile automated counts with a manual sample of at
  least [5] items per metric each quarter.
- **Timeliness**: use the collection dates in section 7 so periods are
  comparable.
- **Integrity**: store each extract read-only with its collection date;
  calculations must be traceable from the extract to the reported value.
- **Changes**: when a data source or formula changes, keep the old
  series, mark the break in the trend and state the impact.

| Known limitation | Metric | Effect | Mitigation |
|---|---|---|---|
| Scanner does not cover the colocation network segment *(Example)* | MET-005, MET-006 | Coverage 92% | Agent rollout due YYYY-MM-DD, coverage reported with value |
| [limitation] | [MET-NNN] | [effect] | [mitigation] |

## 10. Size tiers

<!-- Guidance: The number of metrics, the tooling and the reporting rhythm change with size. The settings below are fictional examples used across the library; choose the column closest to your organisation and adjust. -->

| Aspect | Small: Quillmere Analytics Ltd *(Example)* | Medium: Quillmere Health Systems *(Example)* | Large: Quillmere Group *(Example)* |
|---|---|---|---|
| Profile | 46 staff (38 employees, 8 contractors), SaaS on one public cloud in two regions | 320 staff, two offices and one colocation suite | 2,400 staff, 6 sites in 4 countries, IT and OT |
| Number of metrics | 10 to 12, one per objective plus core controls | 20 to 25, as in section 5 | 30 to 40 at group level plus site metrics |
| Who collects | Part-time ISMS manager (0.5 FTE, Head of Engineering Operations) with exports from the identity provider and cloud tooling | Security team of 3 with named collectors in IT and HR | Site security coordinators feed the 14-person security office |
| Tooling | Shared spreadsheet with extracts stored in the document system | Spreadsheet or GRC tool with automated exports | GRC platform and dashboards integrated with the existing ISO 9001 and ISO 22301 performance reporting |
| Reporting rhythm | Quarterly to the leadership team | Monthly to the security steering group, quarterly to the executive | Monthly per site, quarterly group roll-up to the integrated management system review |
| Specific metrics | Leaver access, MFA, cloud configuration, backups, training | Adds supplier reviews, colocation access, privacy requests | Adds OT patch exposure per plant, site audit coverage, multi-site comparison |
| Independent check | Internal auditor from outside engineering samples 3 metrics a year | Internal audit samples 6 metrics a year | Group internal audit samples per site in the audit programme |

## 11. Records and evidence

<!-- Guidance: Clause 9.1 results must be kept so you can show them later. Name the records, where they live and how long you keep them. Link each record type in the control evidence matrix. -->

| Record | Proves | Kept by | Location | Retention *(Example)* |
|---|---|---|---|---|
| Approved measurement programme (this document) | Method defined and approved | ISMS manager | Document management system | Current plus superseded versions for 3 years |
| Metric definition cards | Reproducible methods | ISMS manager | Metrics folder | Life of the metric plus 3 years |
| Raw data extracts with collection dates | Results are traceable | Data collectors | Metrics folder, read-only | 3 years (one certification cycle) |
| Metrics workbook or dashboard snapshots | Calculated values and status | ISMS manager | Metrics folder or GRC tool | 3 years |
| Owner commentary on amber and red values | Analysis performed | Metric owners | Workbook comments | 3 years |
| Performance reports (DOC-ISMS-081) | Results reported and evaluated | ISMS manager | Document management system | 3 years |
| Steering committee and management review minutes | Evaluation and decisions by top management | Committee secretary | Minutes repository | 3 years or as set in DOC-ISMS-028 |
| Internal audit re-performance results | Data quality tested | Internal audit | Audit files | 3 years |

Map each record to clause 9.1 in the control evidence matrix
(`isms/control-evidence-matrix`, DOC-ISMS-033) and to the
documented information register (DOC-ISMS-028).

## 12. Review of the programme

<!-- Guidance: Review the programme itself, not only the numbers. Questions: did any metric drive a decision this year? Are any metrics always green and therefore uninformative? Did a new risk or objective appear without a metric? -->

Review this programme at least once a year before the management review
and also when:

- objectives in DOC-ISMS-024 are added, changed or closed;
- the risk assessment identifies a new High or Critical risk;
- the ISMS scope changes (new site, service or legal entity);
- a data source is replaced or a tool is retired;
- an audit finds that a metric cannot be reproduced.

Record the review outcome (metrics added, retired or changed) in the
revision history and present it as an input to the management review.

## 13. References

<!-- Guidance: Cite editions exactly and use the official text when you set methods. ISO/IEC 27004 is being revised; check for a newer edition before your next review. -->

| Reference | Edition | Use |
|---|---|---|
| ISO/IEC 27001:2022 + Amd 1:2024 | https://www.iso.org/standard/82875.html ; https://www.iso.org/standard/88435.html | Clauses 6.2 and 9.1 |
| ISO/IEC 27004:2016 | https://www.iso.org/standard/64120.html | Measurement guidance; a revision is in progress |
| ISO/IEC 27002:2022 | https://www.iso.org/standard/75652.html | Control guidance used to choose control metrics |
| NIST SP 800-55 Vol. 1 and Vol. 2, Measurement Guide for Information Security | December 2024 | Optional public guidance on selecting measures and running a measurement programme |
| NIST Cybersecurity Framework 2.0 (CSWP 29) | February 2024 | Optional mapping of metrics to framework outcomes |

Related templates: `isms/isms-performance-report` (DOC-ISMS-081),
`compliance/objectives-register` (DOC-ISMS-024),
`isms/isms-annual-calendar` (DOC-ISMS-032),
`isms/control-evidence-matrix` (DOC-ISMS-033),
`compliance/internal-audit-program` (DOC-ISMS-082),
`compliance/management-review` (DOC-ISMS-085),
`isms/isms-risk-appetite-criteria` (DOC-ISMS-015),
`security/security-metrics-report`.

## Standard and licence note

Structure aligned with ISO/IEC 27001:2022 + Amd 1:2024 clauses 6.2 and
9.1, with guidance concepts from ISO/IEC 27004:2016. The text, metric
examples, targets and worked results are original and illustrative; no
ISO or IEC text, tables or definitions are reproduced, and you need the
official standards to apply them. ISO and IEC standards are copyrighted
and sold by ISO, IEC and national standards bodies. Check the current
edition and amendments before use: ISO/IEC 27004 is under revision.
Template licence: MIT.