Metrics Data Collection & Quality Workbook
Collects metric inputs per period with completeness, freshness and plausibility checks before anything is reported.
Available soon
- Format
- Excel
- Size
- 93 KB
- Length
- 12 sheets
- Version
- 1.1
- Updated
What's inside
What changed
- 1.1
MC-35 shows the ordering platform's monthly restore check (P10 EA-04): 0 of 4.
- 1.0
Published.
Preview
The workbook's sheets as you will receive them, with its example rows and the values its formulas calculate. Highlighted [[text]] is for you to replace; rows marked EXAMPLE are for you to delete. Wide sheets scroll sideways. The cover, document control and changelog sheets are in the file.
Instructions
How to use this workbook
| Step | What to do |
|---|---|
| 1 | Save a copy of this workbook for each month, named for it (for example 'Metrics 2026-09'). Keep every copy: together they show what was checked, what failed and what was reported. |
| 2 | Cycle: enter the period and its last day, and the date you are checking as the as-at date. The timetable counts 6 steps in working days after the period end, from the Security Metric Definition & Measurement Method. Enter your public holidays so they are skipped. Type the as-at date each time you check; do not use a formula that changes it. |
| 3 | Metric Checks: one row per metric you collect, with the quality-check fields from its definition card (Metric Definition Card Template): the supplier and the validator (never the same person, MR-06), the source, what one item in scope is, the scope count, the plausible range, and anything you cross-check it against. |
| 4 | Inputs: by the supply deadline (3 working days after the period end), each data supplier enters one row per metric: the extract date, the number of items with a value, the value, and last period's value from the previous copy. A missing input is left blank, never entered as zero (DQ-01). |
| 5 | By the checks deadline (5 working days), the validator answers 'Follows the definition', enters any cross-check value and whether a large change was explained, and adds a note. The three checks and the result calculate. A share is entered as a number from 0 to 1. |
| 6 | An input that fails is never overwritten. Record the failure on the Quality Log, then either add a new row with the corrected input and the next submission number (the checks run again), or record that the metric owner agreed to report it with a caveat, or that it is withheld (MR-05). |
| 7 | Results: each metric's result. Ready to report goes to the Operational Security Metrics Dashboard. A held metric is shown there as "Not available", with the reason: never last period's value. Copy the MC-38 line into the dashboard. |
| 8 | To clear the EXAMPLE, delete the contents of the 'Row' column and of every yellow column on Metric Checks, Inputs and the Quality Log, and the period on Cycle. |
Legend
Yellow cells are inputs. Everything else is calculated or fixed — do not overwrite formulas.
| EXAMPLE | Rows marked EXAMPLE in the first column show how a completed row looks. Delete them before approval. |
Rule MR-05: "Every input must pass the completeness, freshness and plausibility checks before a figure is reported. A figure that fails is corrected, reported with a printed caveat, or withheld. It is never reported silently, and never replaced by last period's value." Rule MR-06: "The person who validates an input must not be the person who supplied it."
DQ-01 Completeness: Every input the card names is supplied for every item in scope: every system, site, supplier or risk the card lists. A missing input is recorded as missing, never as zero.
DQ-02 Freshness: Each input is taken on or after the period end, and no later than [[3]] working days after it. An older extract is replaced before use, never adjusted.
DQ-03 Plausibility: The value follows the card's definition, sits within the range the card sets, and agrees with related figures, including another pack's count of the same things. A change from last period larger than the card allows is explained by the supplier before it is accepted.
EXAMPLE: a wholesale distributor with about 900 staff, three warehouses and an online ordering service that takes 60% of its orders. Its September 2026 cycle, checked as at 7 Oct 2026. Two inputs failed and were corrected before anything was reported. QF-01 (freshness): The supplier register export was dated 31 Aug 2026: August's file, used again. The pallet network (SUP-009) was assessed on 15 Sep, after the old export. The fresh export counts it. QF-02 (plausibility): The last exercise was entered as 12 Aug 2026: the ransomware incident, INC-2026-014. A live incident is never an exercise (P09 IMM-04). The date must be a held exercise in the P10 programme: EX-2026-01 on 18 Mar 2026.
Not collected here: MC-38, derived from the Quality Log of the collection workbook: this workbook's own result, the figures that failed a check this period. Not supplied, so not checked for freshness. MC-39, derived from the escalation log, and reported one cycle in arrears: the risk owner's review can fall after the month's report is sent. The September 2026 report shows August's escalations. Not supplied, so not checked for freshness.
Tailoring — small organisation: one person may supply most inputs. The validator must still be someone else; a finance or operations manager who can read the source is enough. Keep the three checks: they take minutes once the card sets the scope count and range.
Tailoring — regulated entity (NIS2, DORA): the checks are the method that ensures valid results (Implementing Regulation (EU) 2024/2690, Annex 7.2). Keep each month's copy, with its Quality Log, as the record of how the figures were produced.
Tailoring — IT run by a service provider: the provider will supply several inputs. Put the extract deadline and the definitions in the service agreement, and validate its figures yourself: a provider never validates its own input (MR-06).
Cycle
Cycle — the period, the as-at date and the timetable
Yellow cells are yours. The deadlines count working days after the period end; the as-at date is typed, so a saved copy reads the same on any day.
| Setting | Value | |
|---|---|---|
| Period | September 2026 | EXAMPLE — your month |
| Period end (the last day of the month) | 30 Sep 2026 | |
| As-at date (the day you check) | 7 Oct 2026 | EXAMPLE — the day the checks were finished |
| Supply deadline (calc) | 5 Oct 2026 | |
| Checks deadline (calc) | 7 Oct 2026 | |
| Ready to report? (from Results, calc) | Yes: every metric is ready to report |
Timetable — working days after the period end
| Step | Who | Working days after period end | Due date (calc) | Completed on | Status (calc) |
|---|---|---|---|---|---|
| Inputs supplied in the collection workbook, each with its extract date | Data supplier | 3 | 5 Oct 2026 | 5 Oct 2026 | Done |
| Quality checks run; each input accepted, corrected or rejected (MR-05, MR-06) | Validator | 5 | 7 Oct 2026 | 7 Oct 2026 | Done |
| KRI zones and KPI statuses set; commentary written; escalations started (MR-08) | Metric owner | 6 | 8 Oct 2026 | Not yet due | |
| Operational dashboard reviewed by the security and IT leadership team | Reporter | 7 | 9 Oct 2026 | Not yet due | |
| Executive committee report sent | Reporter | 8 | 12 Oct 2026 | Not yet due | |
| Executive committee meeting | Reporter | 10 | 14 Oct 2026 | Not yet due |
Working days are Monday to Friday, less the non-working days below. In the last month of a quarter the same figures feed the board report: these deadlines fall before its data-return and sign-off dates.
Non-working days (public holidays)
| Date | Holiday |
|---|
[[e.g. a public holiday in the first two weeks of the month]]
Metric Checks
One row per metric you collect: the quality-check fields of its definition card (Metric Definition Card Template). Yellow columns are yours. The 17 EXAMPLE rows are the example organisation's.
| Row | Metric ID | Metric (calc) | Type (calc) | Data supplier (role) | Validator (role) | Data source | One item in scope is | Scope count | Plausible from | Plausible to | Largest change accepted without explanation | Cross-check against | Card check (calc) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| EXAMPLE | MC-13 | Risks outside appetite and past tolerance | KRI | Assessor | Head of Information Security | P05 register | Top risk in the risk register | 12 | 0 | 12 | OK | ||
| EXAMPLE | MC-14 | Treatment actions overdue | KPI | Head of Risk | Assessor | P05 treatment actions | Treatment action in the risk treatment plan | 4 | 0 | 4 | OK | ||
| EXAMPLE | MC-15 | Acceptances past review | KPI | Assessor | Head of Information Security | P05 acceptances | Risk acceptance | 1 | 0 | 1 | OK | ||
| EXAMPLE | MC-17 | Tier 1 suppliers assessed | KPI | Procurement Manager | Assessor | P06 supplier register | Tier 1 supplier in the supplier register | 14 | 0 | 14 | OK | ||
| EXAMPLE | MC-19 | High findings past deadline | KPI | Assessor | Head of Information Security | P06 findings | Finding raised with a supplier | 4 | 0 | 4 | OK | ||
| EXAMPLE | MC-20 | Concentration | KRI | Procurement Manager | Assessor | P06 supplier register | Tier 1 supplier in the supplier register, with the critical services it supports | 14 | 0 | 14 | OK | ||
| EXAMPLE | MC-22 | Removals confirmed on time | KPI | System administrator | Campaign coordinator | P07 campaign UAR-2026-Q3 | Revoke or Modify decision in the access review | 69 | 0 | 69 | OK | ||
| EXAMPLE | MC-24 | Process weaknesses open | KPI | Campaign coordinator | Head of Information Security | P07 campaign UAR-2026-Q3 | Process weakness sent to a process owner | 2 | 0 | 2 | OK | ||
| EXAMPLE | MC-25 | Significant incidents and time to contain | KPI | Incident manager | Head of Information Security | P09 case log | Case in the incident case log for the quarter | 5 | 0 | 5 | OK | ||
| EXAMPLE | MC-26 | Reports made on time | KPI | Incident manager | Data Protection Officer | P09 reports | Report to an authority or individual that fell due | 4 | 0 | 4 | OK | ||
| EXAMPLE | MC-27 | Review actions overdue | KPI | Incident manager | Head of Information Security | P09 review actions | Post-incident review action | 6 | 0 | 6 | OK | ||
| EXAMPLE | MC-28 | Months since the plan was last exercised | KPI | Incident manager | Head of Information Security | P09 and P10 exercise programme | Exercise in the exercise programme | 6 | 0 | The last held exercise in the exercise programme (never a live incident) | OK | ||
| EXAMPLE | MC-29 | Audiences exercised within their interval | KPI | Exercise lead | Exercise sponsor | P10 exercise programme | Exercise audience (AU-01 to AU-04) | 4 | 0 | 4 | OK | ||
| EXAMPLE | MC-31 | Exercise actions overdue | KPI | Exercise lead | Exercise sponsor | P10 improvement actions | Improvement action from an exercise | 6 | 0 | 6 | OK | ||
| EXAMPLE | MC-34 | Phishing compromises | KRI | Incident manager | Head of Information Security | P09 case log | Case in the incident case log for the last 3 months | 5 | 0 | 5 | OK | ||
| EXAMPLE | MC-35 | Critical systems without a checked restore | KRI | IT Operations Manager | Information Security Manager | Backup restore records | System that supports a critical service | 4 | 0 | 4 | OK | ||
| EXAMPLE | MC-36 | Staff security training completion | KPI | HR Learning Lead | Information Security Manager | Training records (P03 BM-08) | Member of staff in post | 900 | 0 | 1 | OK |
Inputs
One row per metric and submission for September 2026. Suppliers fill the first yellow columns; the validator fills 'Follows the definition' to the note. The three checks and the result calculate. EXAMPLE rows: the example's September inputs.
| Row | Metric ID | Metric (calc) | Submission | Supplied by | Validated by | Extract date | Items with a value | Value | Last period's value | Follows the definition | Cross-check value | Change explained | Validated on | Validator's note | Scope count (calc) | Plausible from (calc) | Plausible to (calc) | Largest change (calc) | Completeness (calc) | Freshness (calc) | Plausibility (calc) | Plausibility reason (calc) | Roles, MR-06 (calc) | Result (calc) | Latest submission (calc) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| EXAMPLE | MC-13 | Risks outside appetite and past tolerance | 1 | Assessor | Head of Information Security | 30 Sep 2026 | 12 | 2 | 3 | Yes | 7 Oct 2026 | 12 | 0 | 12 | Pass | Pass | Pass | OK | Ready to report | Yes | |||||
| EXAMPLE | MC-14 | Treatment actions overdue | 1 | Head of Risk | Assessor | 30 Sep 2026 | 4 | 0 | Yes | 7 Oct 2026 | 4 | 0 | 4 | Pass | Pass | Pass | OK | Ready to report | Yes | ||||||
| EXAMPLE | MC-15 | Acceptances past review | 1 | Assessor | Head of Information Security | 30 Sep 2026 | 1 | 0 | Yes | 7 Oct 2026 | 1 | 0 | 1 | Pass | Pass | Pass | OK | Ready to report | Yes | ||||||
| EXAMPLE | MC-17 | Tier 1 suppliers assessed | 1 | Procurement Manager | Assessor | 31 Aug 2026 | 14 | 8 | 8 | Yes | 7 Oct 2026 | QF-01: The supplier register export was dated 31 Aug 2026: August's file, used again. | 14 | 0 | 14 | Pass | Fail | Pass | OK | Held | No | ||||
| EXAMPLE | MC-17 | Tier 1 suppliers assessed | 2 | Procurement Manager | Assessor | 1 Oct 2026 | 14 | 9 | 8 | Yes | 7 Oct 2026 | QF-01 corrected: The pallet network (SUP-009) was assessed on 15 Sep, after the old export. The fresh export counts it. | 14 | 0 | 14 | Pass | Pass | Pass | OK | Ready to report | Yes | ||||
| EXAMPLE | MC-19 | High findings past deadline | 1 | Assessor | Head of Information Security | 30 Sep 2026 | 4 | 1 | 1 | Yes | 7 Oct 2026 | 4 | 0 | 4 | Pass | Pass | Pass | OK | Ready to report | Yes | |||||
| EXAMPLE | MC-20 | Concentration | 1 | Procurement Manager | Assessor | 30 Sep 2026 | 14 | 6 | Yes | 7 Oct 2026 | 14 | 0 | 14 | Pass | Pass | Pass | OK | Ready to report | Yes | ||||||
| EXAMPLE | MC-22 | Removals confirmed on time | 1 | System administrator | Campaign coordinator | 30 Sep 2026 | 69 | 65 | Yes | 7 Oct 2026 | 69 | 0 | 69 | Pass | Pass | Pass | OK | Ready to report | Yes | ||||||
| EXAMPLE | MC-24 | Process weaknesses open | 1 | Campaign coordinator | Head of Information Security | 30 Sep 2026 | 2 | 0 | Yes | 7 Oct 2026 | 2 | 0 | 2 | Pass | Pass | Pass | OK | Ready to report | Yes | ||||||
| EXAMPLE | MC-25 | Significant incidents and time to contain | 1 | Incident manager | Head of Information Security | 30 Sep 2026 | 5 | 1 | Yes | 7 Oct 2026 | 5 | 0 | 5 | Pass | Pass | Pass | OK | Ready to report | Yes | ||||||
| EXAMPLE | MC-26 | Reports made on time | 1 | Incident manager | Data Protection Officer | 30 Sep 2026 | 4 | 4 | Yes | 7 Oct 2026 | 4 | 0 | 4 | Pass | Pass | Pass | OK | Ready to report | Yes | ||||||
| EXAMPLE | MC-27 | Review actions overdue | 1 | Incident manager | Head of Information Security | 30 Sep 2026 | 6 | 1 | Yes | 7 Oct 2026 | 6 | 0 | 6 | Pass | Pass | Pass | OK | Ready to report | Yes | ||||||
| EXAMPLE | MC-28 | Months since the plan was last exercised | 1 | Incident manager | Head of Information Security | 30 Sep 2026 | 6 | 1 | No | 6 | 7 Oct 2026 | QF-02: The last exercise was entered as 12 Aug 2026: the ransomware incident, INC-2026-014. | 6 | 0 | Pass | Pass | Fail | Does not follow the definition | OK | Held | No | ||||
| EXAMPLE | MC-28 | Months since the plan was last exercised | 2 | Incident manager | Head of Information Security | 30 Sep 2026 | 6 | 6 | Yes | 6 | 7 Oct 2026 | QF-02 corrected: A live incident is never an exercise (P09 IMM-04). The date must be a held exercise in the P10 programme: EX-2026-01 on 18 Mar 2026. | 6 | 0 | Pass | Pass | Pass | OK | Ready to report | Yes | |||||
| EXAMPLE | MC-29 | Audiences exercised within their interval | 1 | Exercise lead | Exercise sponsor | 30 Sep 2026 | 4 | 2 | Yes | 7 Oct 2026 | 4 | 0 | 4 | Pass | Pass | Pass | OK | Ready to report | Yes | ||||||
| EXAMPLE | MC-31 | Exercise actions overdue | 1 | Exercise lead | Exercise sponsor | 30 Sep 2026 | 6 | 1 | Yes | 7 Oct 2026 | 6 | 0 | 6 | Pass | Pass | Pass | OK | Ready to report | Yes | ||||||
| EXAMPLE | MC-34 | Phishing compromises | 1 | Incident manager | Head of Information Security | 30 Sep 2026 | 5 | 2 | 1 | Yes | 7 Oct 2026 | 5 | 0 | 5 | Pass | Pass | Pass | OK | Ready to report | Yes | |||||
| EXAMPLE | MC-35 | Critical systems without a checked restore | 1 | IT Operations Manager | Information Security Manager | 30 Sep 2026 | 4 | 0 | Yes | 7 Oct 2026 | 4 | 0 | 4 | Pass | Pass | Pass | OK | Ready to report | Yes | ||||||
| EXAMPLE | MC-36 | Staff security training completion | 1 | HR Learning Lead | Information Security Manager | 30 Sep 2026 | 900 | 0.92 | Yes | 7 Oct 2026 | 900 | 0 | 1 | Pass | Pass | Pass | OK | Ready to report | Yes |
Quality Log
Every input that failed a check, and what happened to it (MR-05). Outcomes: Corrected; Reported with a caveat; Withheld. Last period's value is never carried forward.
| Row | Failure ID | Metric ID | Metric (calc) | Check failed | What was found | Value supplied | Corrected value | Why, and the correction | Outcome | Caveat printed beside the value | Check (calc) |
|---|---|---|---|---|---|---|---|---|---|---|---|
| EXAMPLE | QF-01 | MC-17 | Tier 1 suppliers assessed | DQ-02 Freshness | The supplier register export was dated 31 Aug 2026: August's file, used again. | 8 | 9 | The pallet network (SUP-009) was assessed on 15 Sep, after the old export. The fresh export counts it. | Corrected | OK | |
| EXAMPLE | QF-02 | MC-28 | Months since the plan was last exercised | DQ-03 Plausibility | The last exercise was entered as 12 Aug 2026: the ransomware incident, INC-2026-014. | 1 | 6 | A live incident is never an exercise (P09 IMM-04). The date must be a held exercise in the P10 programme: EX-2026-01 on 18 Mar 2026. | Corrected | OK |
Results
Results — what can be reported this period
Everything here is calculated. A metric is ready to report when its latest submission passed every check; a held metric goes to the Operational Security Metrics Dashboard as "Not available", with the reason.
Summary for the period
| Count | Metrics | ||||||
|---|---|---|---|---|---|---|---|
| Metrics with a card on Metric Checks | 17 | ||||||
| Ready to report | 17 | ||||||
| Ready to report, with the caveat | 0 | ||||||
| Held, not yet checked, or not supplied | 0 | ||||||
| MC-38 Figures that failed a quality check | 2 | ||||||
| of which corrected | 2 | ||||||
| of which reported with a caveat | 0 | ||||||
| of which withheld | 0 | ||||||
| MC-38 for the dashboard | 2 failed; 2 corrected, 0 reported with a caveat or withheld | ||||||
| Ready to report? | Yes: every metric is ready to report | ||||||
Result per metric
| Metric ID | Metric | Submissions | Submissions held | Latest submission | Outcome | Result | Value to report |
|---|---|---|---|---|---|---|---|
| MC-13 | Risks outside appetite and past tolerance | 1 | 0 | Ready to report | Passed | Ready to report | 2 |
| MC-14 | Treatment actions overdue | 1 | 0 | Ready to report | Passed | Ready to report | 0 |
| MC-15 | Acceptances past review | 1 | 0 | Ready to report | Passed | Ready to report | 0 |
| MC-17 | Tier 1 suppliers assessed | 2 | 1 | Ready to report | Corrected | Ready to report | 9 |
| MC-19 | High findings past deadline | 1 | 0 | Ready to report | Passed | Ready to report | 1 |
| MC-20 | Concentration | 1 | 0 | Ready to report | Passed | Ready to report | 6 |
| MC-22 | Removals confirmed on time | 1 | 0 | Ready to report | Passed | Ready to report | 65 |
| MC-24 | Process weaknesses open | 1 | 0 | Ready to report | Passed | Ready to report | 0 |
| MC-25 | Significant incidents and time to contain | 1 | 0 | Ready to report | Passed | Ready to report | 1 |
| MC-26 | Reports made on time | 1 | 0 | Ready to report | Passed | Ready to report | 4 |
| MC-27 | Review actions overdue | 1 | 0 | Ready to report | Passed | Ready to report | 1 |
| MC-28 | Months since the plan was last exercised | 2 | 1 | Ready to report | Corrected | Ready to report | 6 |
| MC-29 | Audiences exercised within their interval | 1 | 0 | Ready to report | Passed | Ready to report | 2 |
| MC-31 | Exercise actions overdue | 1 | 0 | Ready to report | Passed | Ready to report | 1 |
| MC-34 | Phishing compromises | 1 | 0 | Ready to report | Passed | Ready to report | 2 |
| MC-35 | Critical systems without a checked restore | 1 | 0 | Ready to report | Passed | Ready to report | 0 |
| MC-36 | Staff security training completion | 1 | 0 | Ready to report | Passed | Ready to report | 0.92 |
Value to report is the latest submission's value, in the metric's unit. "Corrected": a check failed and the corrected input passed. Held: the metric owner decides on the Quality Log whether to report it with a caveat or withhold it.
Lists
| CatID | CatName | CatType | YesNo | CheckFailed | QualityOutcome |
|---|---|---|---|---|---|
| MC-01 | Scan coverage | KPI | Yes | DQ-01 Completeness | Corrected |
| MC-02 | Mean time to remediate, by priority | KPI | No | DQ-02 Freshness | Reported with a caveat |
| MC-03 | Deadline adherence | KPI | DQ-03 Plausibility | Withheld | |
| MC-04 | Overdue exposure | KRI | |||
| MC-05 | Open exceptions by band | KPI | |||
| MC-06 | Expired exceptions | KPI | |||
| MC-07 | Chronic exceptions | KPI | |||
| MC-08 | Unmitigated SoD conflicts | KRI | |||
| MC-09 | Documents past review date | KPI | |||
| MC-10 | Documents in force without approval | KPI | |||
| MC-11 | Acknowledgement coverage | KPI | |||
| MC-12 | Overdue acknowledgements | KPI | |||
| MC-13 | Risks outside appetite and past tolerance | KRI | |||
| MC-14 | Treatment actions overdue | KPI | |||
| MC-15 | Acceptances past review | KPI | |||
| MC-16 | Risks not reviewed this quarter | KPI | |||
| MC-17 | Tier 1 suppliers assessed | KPI | |||
| MC-18 | Reassessments overdue | KPI | |||
| MC-19 | High findings past deadline | KPI | |||
| MC-20 | Concentration | KRI | |||
| MC-21 | Reviews on time | KPI | |||
| MC-22 | Removals confirmed on time | KPI | |||
| MC-23 | Access that should not have existed | KRI | |||
| MC-24 | Process weaknesses open | KPI | |||
| MC-25 | Significant incidents and time to contain | KPI | |||
| MC-26 | Reports made on time | KPI | |||
| MC-27 | Review actions overdue | KPI | |||
| MC-28 | Months since the plan was last exercised | KPI | |||
| MC-29 | Audiences exercised within their interval | KPI | |||
| MC-30 | Objectives met at the last exercise | KPI | |||
| MC-31 | Exercise actions overdue | KPI | |||
| MC-32 | Re-tests outstanding | KPI | |||
| MC-33 | Critical suppliers exercised | KPI | |||
| MC-34 | Phishing compromises | KRI | |||
| MC-35 | Critical systems without a checked restore | KRI | |||
| MC-36 | Staff security training completion | KPI | |||
| MC-37 | Metrics reported with an approved card | KPI | |||
| MC-38 | Figures that failed a quality check | KPI | |||
| MC-39 | KRI escalations made on time | KPI | |||
| MC-40 | Metrics reviewed in the last 12 months | KPI |
Columns A to C are the metrics of the Security KPI & KRI Catalogue (MC-01 to MC-40). Yellow rows: add your own metrics with an ID, name and type.
Definitions
Definitions
| Term | Meaning in this workbook |
|---|---|
| Metric | A number defined once, on a definition card, that answers one question for one audience: what is counted, how, from which source, by whom and how often. |
| Value | The figure a metric gives for one period, as at the period end. |
| Data quality | Whether an input can be relied on. This pack checks three things: completeness, freshness and plausibility. |
| DQ-01 Completeness | Every input the card names is there, for the whole scope the card sets. Test: The count of items with a value equals the scope count on the card. |
| DQ-02 Freshness | The input is as at the period end, taken within the time the card allows. Test: The extract date is recorded, and falls between the period end and the supply deadline. |
| DQ-03 Plausibility | The value could be true: it follows the definition, sits in a believable range and agrees with related figures. Test: Definition, range, cross-check and change against last period, each passed or failed with a note. |
| Data supplier | The person who provides an input to a metric each period, from a named source. |
| Validator | The person who runs the quality checks on an input and accepts or rejects it. Never the person who supplied it. |
| Metric owner | The person who interprets a metric, writes the commentary and answers for it. One per metric. |
| Period end | The last day of the month the figures describe. Every input is as at this date. |
| Supply deadline | The last day an input may be taken and supplied: 3 working days after the period end. An extract taken before the period end, or after this date, fails freshness. |
| As-at date | The day you check the workbook, typed in. The timetable's status is judged at this date. |
| Scope count | The number of items the card says a metric covers, such as top risks or Tier 1 suppliers. Completeness compares the items with a value with it. |
| Cross-check value | The same thing counted from another source, such as another pack's register. A value that disagrees with it fails plausibility. |
| Submission | 1 for the first input of a metric in the period; 2, 3 for each corrected input. The checks judge every submission; the latest one counts. |
| Outcome — Passed | Every check passed. The figure is reported. |
| Outcome — Corrected | A check failed. The supplier fixed the input, and the checks passed on the fixed input before the figure was reported. |
| Outcome — Reported with a caveat | A check failed and the input could not be fixed in time. The metric owner agreed to report it, and the caveat is printed beside the value. |
| Outcome — Withheld | A check failed and the figure could mislead. It is shown as "Not available" with the reason. Last period's value is never carried forward. |
| Caveat | A short note printed beside a value that failed a check and could not be fixed in time, saying what is wrong and which way the error runs. |
| Held | Not reported as it stands: a check failed, or roles break MR-06. The Quality Log records whether it is corrected, reported with a caveat or withheld. |
| MR-nn, DQ-nn, MC-nn | Rules, data quality checks and metrics defined in the Security Metric Definition & Measurement Method and the Security KPI & KRI Catalogue. |
| (calc) | A column or cell the workbook calculates. Do not type or paste over it. |
| EXAMPLE | A worked example: a wholesale distributor with about 900 staff, three warehouses and an online ordering service that takes 60% of its orders, September 2026. Delete before use. |
Framework References
Framework references
These references indicate relevance only and do not reproduce the text of any standard.
| Framework | Reference | Supported by |
|---|---|---|
| ISO/IEC 27001:2022 | Clause 9.1 — Monitoring, measurement, analysis and evaluation | The workbook as a whole: what is measured, who supplies and who checks it, when, and the checks that make results valid |
| NIST CSF 2.0 | GV.OV-03 — “Organizational cybersecurity risk management performance is evaluated and reviewed for adjustments needed” | Results: only figures that passed their checks are used to evaluate performance |
| NIS2 — Directive (EU) 2022/2555 | Article 21(2)(f) — “policies and procedures to assess the effectiveness of cybersecurity risk-management measures” | The checks as part of the procedures to assess whether measures are effective |
| NIS2 — Implementing Regulation (EU) 2024/2690 | Annex, point 7.2 — taking into account the risk assessment and past significant incidents, determine what is monitored and measured, the methods “to ensure valid results”, when it is measured, who measures, when the results are analysed and evaluated, and who analyses and evaluates them | Metric Checks and Inputs: what is measured, who measures, when, and the methods that ensure valid results |
Editions referenced: ISO/IEC 27001:2022 incl. Amd 1:2024; NIST CSF 2.0; Directive (EU) 2022/2555 (NIS2) and Implementing Regulation (EU) 2024/2690; Regulation (EU) 2022/2554 (DORA)