ISMS Measurement Programme Template (ISO/IEC 27001 9.1, 27004)
Clause 9.1 measurement method: information needs, roles, 25 example metrics, definition cards, collection cycle, thresholds, data quality, size tiers
Як використовувати: Use it when the objectives register and risk treatment plan exist and you need trend data before the first internal audit. Fill the information needs and one metric per objective first, with definition cards. The main pitfall is measuring what tools report instead of what management decides on.
Перегляд
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.
Document control
| 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
- Purpose and scope
- Information needs
- Measurement principles and method
- Roles and responsibilities
- Metric catalogue
- Metric definition cards
- Collection, analysis and evaluation cycle
- Thresholds, targets and escalation
- Data quality and validity
- Size tiers
- Records and evidence
- Review of the programme
- References
1. Purpose and scope
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
| 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
3.1 Principles
- Decision first. A metric exists only if someone will act on it.
- Defined once. Every metric has a definition card (section 6); the card, not the spreadsheet, is the authority.
- Comparable over time. Do not change a formula silently. A change is a new version of the card, and the trend line is annotated.
- Automated where possible. Prefer counts exported from systems of record (identity provider, ticketing, vulnerability scanner, learning platform) over manual estimates.
- Balanced. Combine process metrics (are we doing the work?) with outcome metrics (is the risk lower?).
- 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.
4. Roles and responsibilities
| 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
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
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
| 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) |
8. Thresholds, targets and escalation
| 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
- 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
| 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
| 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
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
| 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.
Схожі шаблони
Access Control Policy Template (ISO/IEC 27001 A.5.15)
Access principles, role catalogue, joiner mover leaver SLAs, MFA and NIST SP 800-63B-4 password rules, privileged and service accounts, reviews, metrics
СУІБ та ISO/IEC 27001Annex A Organizational Controls Guide Template (ISO/IEC 27001 A.5)
A.5.1 to A.5.37 in own words: intent, typical implementation, tier notes, evidence auditors sample, pitfalls, linked templates, self-check, study record
СУІБ та ISO/IEC 27001Annex A People and Physical Controls Guide Template (ISO/IEC 27001 A.6, A.7)
A.6.1 to A.6.8 and A.7.1 to A.7.14 in own words: intent, tier notes, evidence, pitfalls, physical boundary decision for cloud and colocation, self-check, study record