Metric Definition Card Template
One-page specification per metric covering question answered, formula, source, frequency, owner and known limitations.
Available soon
- Format
- Word
- Size
- 59 KB
- Length
- 16 pages
- Version
- 1.0
- Updated
What's inside
What changed
- 1.0
Published.
Preview
The document from section 1, as you will receive it. Highlighted [[text]] is for you to replace; shaded guidance boxes are for you to delete before approval. The cover and document control pages are in the file.
How to use this card
Use this card to specify one metric: the question it answers, the decision it informs, exactly what it counts and how, where the data comes from, who supplies, checks, interprets and reports it, and how it can mislead. Every metric must have an approved definition card before its first value is reported. The card is the only definition, and every document that shows the metric uses it.
The rules the card serves are in the Security Metric Definition & Measurement Method; every field names the rule it meets. The Security KPI & KRI Catalogue lists the metrics that need a card.
When a card is written
Situation | What to do |
|---|---|
A new metric is proposed | Write the card before anything is collected. If Part A cannot be completed, the metric is not needed (MR-01). |
A metric is imported from another pack | Copy the owning pack's name, definition and target unchanged into Part B, and complete the rest (MR-04). |
A definition, source or threshold changes | Change the card first, and record the change in Part F, with whether earlier values were restated (MR-09). |
The annual review | Check every field is still true, and set the next review date (MR-11). |
A metric is retired | Mark the card Retired with the date and reason, and keep it (MR-11). |
Who does what
- The metric owner writes the card, with the data supplier for Part C and the validator for Part D.
- Approval: the metric owner and the head of each audience the metric goes to. For a KRI, the owner of the linked risk also approves the thresholds (MR-07).
- The Head of Information Security keeps the cards with the catalogue, and checks each period that every reported metric has an approved card (MC-37).
Steps
- Complete Part A first. A metric with no question or no decision stops here.
- Check the catalogue and the other packs for an existing definition. If one exists, copy it into Part B unchanged.
- Write the formula and the scope, with a scope count the completeness check can use.
- Name the source and the four roles in Part C. The validator must not be the supplier (MR-06).
- Set the four numbers in Part D with the validator. For a new metric, set a wide plausible range and narrow it after three periods.
- Set the target or the thresholds in Part E. For a KRI, work them out with the risk owner as the Key Risk Indicator Threshold & Escalation Model sets out.
- Write the known limitations, and have the card approved before the first value is reported.
Guidance — delete before approval
One card per metric, on one or two pages. If a card needs more, the metric is probably two metrics.
Write "None" where a field does not apply, never leave it blank: a card with an empty field is not approved (MR-02).
Field guidance
Field | What a good answer looks like | Common reason a card is sent back |
|---|---|---|
Metric ID and name MR-02 | The catalogue ID and the name exactly as the catalogue has it. | A new name for an existing metric, so two reports seem to show two things. |
Type MR-07 | KPI where a target says what good looks like; KRI where the number warns about a named risk. | Both, or neither. A number judged against a target and thresholds at once. |
Question it answers MR-01 | One question an audience member would ask aloud, ending in a question mark. | A topic ("Phishing") or two questions joined by "and". |
Decision it informs MR-01 | A verb and a person: who funds, reassesses, escalates, changes a plan or accepts. | "Awareness" or "visibility". Nobody would act differently. |
Audience and cadence MR-10 | Operational, executive or both, each with its cadence from the reporting levels (MR-10). | "Board" for a metric that is not one of the eight board measures. |
Owning pack MR-04 | The pack and its measure ID, or P11 with a note that no pack defines it. | P11 for a measure another pack already defines. |
Definition MR-04 | The owning pack's words, copied exactly. For a P11 metric, one or two plain sentences. | An imported definition reworded "to make it clearer". |
Formula MR-02 | Numerator, denominator and unit, or what one counted item is and the window. | A percentage with no denominator; a count with no window. |
Scope MR-05 | What is in, what is out, and how many items the scope holds, with where that count comes from. | "All systems", with no count to check completeness against. |
Better when MR-12 | Higher or Lower. One word. | Left blank, so nobody can say whether a change is better or worse. |
Data source MR-02 | The system, register or workbook, and the report or export within it. | "The tool" or "IT". |
Data supplier MR-03 | One role for each input, in your organisation. | A team, a mailbox or a provider. |
Validator MR-06 | One role, never the supplier, with a named deputy. | The supplier, or "the team". |
Metric owner MR-03 | One role who can explain the number to the audience. | A committee, or the person who only collects it. |
Reporter MR-03 | One role for each audience the metric goes to. | No reporter for the executive committee. |
Period and as-at date MR-10 | Calendar month or quarter, as at its last day; any window stated. | "Current", or the date the extract happened to be run. |
Quality checks MR-05 | The four numbers the checks use: scope count, extract deadline, plausible range, largest change without explanation. | "Checked by the owner", with no numbers to check against. |
Target and tolerance MR-07 | KPI: the owning pack's target unchanged, and the tolerance the audience set. KRI: None. | A target changed on the card and not in the owning pack. |
Thresholds and linked risk MR-07 | KRI: green, amber and red as values, the risk ID, and the reasoning from its score. KPI: None. | Thresholds chosen because they are round numbers. |
Escalation MR-08 | KRI: who is told for amber and for red, within how many working days, as the escalation table sets. KPI: None. | "Escalate as needed". |
Board measure it feeds MR-04 | BM-nn from the board catalogue, or None. | A board measure the metric does not count the same things as. |
Known limitations MR-01 | How it can mislead, in the P03 catalogue's words where one fits, and what to read beside it. | "None". Every metric has at least one. |
Change log MR-09 | Each change with its date, what changed, and whether earlier values were restated or a break marked. | Changes made to the definition with no entry. |
Approved by and date MR-02 | The metric owner and the head of each audience; for a KRI, also the owner of the linked risk. | Approved by the person who wrote the card only. |
Next review MR-11 | A date within 12 months of the last review. | Blank, or more than 12 months away. |
The card
Guidance — delete before approval
Copy this card once for each metric, and name the copy with the metric's ID. Keep the field labels, so every card reads the same.
A What it is for | |||
Metric ID and name MC-nn and the name from the catalogue (MR-02) | [[MC-nn Name]] | Type KPI or KRI (MR-07) | [[KPI / KRI]] |
Question it answers One question, in the words the audience would ask it (MR-01) | [[One question, in the audience's words?]] | ||
Decision it informs The decision, and who takes it (MR-01) | [[The decision, and who takes it]] | ||
Audience and cadence Operational, executive, or both; monthly or quarterly (MR-10) | [[Operational: monthly / Executive: monthly]] | ||
B What it counts | |||
Owning pack The pack that defines it, or P11 where none does (MR-04) | [[Pnn, measure ID / P11: no pack defines it]] | Board measure it feeds BM-nn, or none (P03) (MR-04) | [[BM-nn Name / None]] |
Definition The owning pack's words, unchanged (MR-04) | [[The owning pack's words, unchanged]] | ||
Formula Numerator, denominator and unit; for a count, what one item is (MR-02) | [[Numerator ÷ denominator, unit / what one counted item is, and the window]] | ||
Scope What is counted and what is left out, with the scope count the completeness check uses (MR-05) | [[In: … Out: … Scope count: n, from …]] | ||
Better when Higher or lower (MR-12) | [[Higher / Lower]] | Period and as-at date Calendar month or quarter, as at its last day (MR-10) | [[Calendar month, as at its last day]] |
C Data and roles | |||
Data source The system, register or workbook each input comes from (MR-02) | [[System, register or workbook, and the report or export]] | ||
Data supplier One role per input (MR-03) | [[Role, one per input]] | Validator One role, never the supplier (MR-06) | [[Role, never the supplier; deputy]] |
Metric owner One role, who interprets it (MR-03) | [[Role]] | Reporter One role per audience (MR-03) | [[Operational: role Executive: role]] |
D Quality checks | |||
Quality checks The scope count, the extract deadline, the plausible range and the largest change accepted without explanation (MR-05) | Scope count (DQ-01): [[n, from …]] Extract deadline (DQ-02): [[3]] working days after the period end Plausible range (DQ-03): [[from … to …]] Largest change without explanation (DQ-03): [[n]] Cross-check (DQ-03): [[the other count of the same things, or none]] | ||
E Target, thresholds and escalation | |||
Target and tolerance KPI only: the owning pack's target, and the tolerance the audience set (MR-07) | [[KPI: target, from the owning pack; tolerance, set by the audience / KRI: None]] | ||
Thresholds and linked risk KRI only: green, amber and red, the P05 risk they are set from, and the reasoning (MR-07) | [[KRI: green … amber … red …; risk R-nn; reasoning / KPI: None]] | ||
Escalation KRI only: who is told, within what time, for amber and red (MR-08) | [[KRI: amber, who within n working days; red, who within n working days / KPI: None]] | ||
F Limits and changes | |||
Known limitations How it can mislead, in the P03 catalogue's words where one fits (MR-01) | [[How it can mislead (P03 weakness), and what to read beside it]] | ||
Change log Each change to definition, source or thresholds, with date and whether earlier values were restated (MR-09) | [[YYYY-MM-DD: what changed; restated or break marked / None since approval]] | ||
G Approval | |||
Approved by and date The metric owner and the head of the audience it goes to (MR-02) | [[Metric owner; head of each audience; KRI: owner of the linked risk; YYYY-MM-DD]] | ||
Next review Within 12 months of the last review (MR-11) | [[YYYY-MM-DD, within 12 months]] | ||
Worked example 1: a risk indicator this pack defines
This is the card for MC-34 Phishing compromises, one of the pack's own metrics, as approved by a wholesale distributor with about 900 staff, three warehouses and an online ordering service that takes 60% of its orders. It is a KRI linked to R-09 in the Information Security Risk Register (P05). The organisation and its roles are fictional; replace them with your own.
Guidance — delete before approval
Its thresholds come from the threshold method in the Key Risk Indicator Threshold & Escalation Model: amber is the first count at which the risk owner would score R-09 outside appetite, and red the first at which it would be past tolerance.
Delete this worked example from your adopted template.
A What it is for — EXAMPLE | |||
Metric ID and name MR-02 | MC-34 Phishing compromises | Type MR-07 | KRI, leading |
Question it answers MR-01 | Are phishing emails getting through and causing harm more often than our assessment of the phishing risk assumes? | ||
Decision it informs MR-01 | Whether the owner of R-09 must review the risk and strengthen its treatment; when the indicator is amber or red, whether the executive committee agrees further action. | ||
Audience and cadence MR-10 | Operational: monthly Executive: monthly | ||
B What it counts — EXAMPLE | |||
Owning pack MR-04 | P11. No pack defines it. P09 counts incidents by severity, and the P03 candidate CM-04 counts reports of simulated phishing, which is behaviour, not harm. | Board measure it feeds MR-04 | None |
Definition MR-04 | Incidents in the last 3 calendar months whose root cause was a phishing email: an account taken over, or malware run from an attachment or link. Counted from the incident case log by the date detected. | ||
Formula MR-02 | A count. One item is one incident case in the case log whose recorded root cause is a phishing email received by our own staff. Window: detected in the 3 calendar months to the period end. Unit: incidents. | ||
Scope MR-05 | In: Every incident case in the case log detected in the 3 calendar months to the period end, of any severity, open or closed. Out: Phishing emails that caused no incident; a supplier's own mailbox compromised by phishing (their incident, not ours). Scope count: the cases detected in the window, from the Incident Case & Action Log. September 2026: 5. | ||
Better when MR-12 | Lower | Period and as-at date MR-10 | Calendar month, as at its last day; counts the 3 months to that day |
C Data and roles — EXAMPLE | |||
Data source MR-02 | Incident Case & Action Log (P09): each case's detection date and recorded root cause | ||
Data supplier MR-03 | Incident manager: Information Security Manager | Validator MR-06 | Head of Information Security |
Metric owner MR-03 | Head of Information Security | Reporter MR-03 | Operational: Information Security Manager Executive: Head of Information Security |
D Quality checks — EXAMPLE | |||
Quality checks MR-05 | Scope count (DQ-01): every case detected in the window has a root cause recorded, or "not yet known" Extract deadline (DQ-02): 3 working days after the period end Plausible range (DQ-03): 0 to the scope count Largest change without explanation (DQ-03): [[1]] a month Cross-check (DQ-03): each counted case's root cause in the case log names a phishing email | ||
E Target, thresholds and escalation — EXAMPLE | |||
Target and tolerance MR-07 | None: a KRI (MR-07) | ||
Thresholds and linked risk MR-07 | Green 0 to 1; Amber 2 to 3; Red 4 or more (incidents in 3 months) Linked risk: R-09 Staff account taken over through phishing. Residual impact 2 Moderate × likelihood 3 Likely = 6, Medium; RC-06 People and insider, Cautious (appetite Medium, tolerance High). Reasoning: One phishing compromise a quarter is what R-09's likelihood (Likely: has happened to us, and the gap is still open) already assumes. Two in three months means attempts are getting through with little in the way: likelihood Almost certain. Four means the owner would expect one to lose data or money: impact one step higher as well. Amber stands for impact 2 Moderate × likelihood 4 Almost certain = 8, High, outside appetite, within tolerance; red for impact 3 Major × likelihood 4 Almost certain = 12, Critical, outside tolerance. | ||
Escalation MR-08 | Amber: HR Director, owner of R-09, within 5 working days of validation; the risk reviewed within 10. Red: Executive management, through the Head of Information Security, within 2 working days; the risk reassessed within 10. Amber for 3 periods in a row is escalated as red, unless R-09 has an approved treatment plan that is on schedule (P05 RM-06, RM-07), recorded by the risk owner each period (MR-08). | ||
F Limits and changes — EXAMPLE | |||
Known limitations MR-01 | • Small numbers: one incident moves the indicator a whole step. Read the cases behind it, not the count alone. • It depends on the root cause being recorded. A case whose root cause is found later is counted in the month it was detected, so an earlier month's value may change: restate it (MR-09). • Part lagging: it counts compromises that have happened. Read it beside the P03 candidate CM-04, phishing report rate, for whether staff spot and report attempts. | ||
Change log MR-09 | None since approval | ||
G Approval — EXAMPLE | |||
Approved by and date MR-02 | Head of Information Security, metric owner; HR Director, owner of R-09, for the thresholds (MR-07); Chief Executive, chair of the executive committee. 26 Jun 2026 | ||
Next review MR-11 | By 26 Jun 2027 | ||
How the card was used in September
The counts at each month end, and the zone the card's thresholds give. EXAMPLE, as at 30 Sep 2026.
Month end | Value | Zone | In words |
|---|---|---|---|
31 Jul 2026 | 0 | Green | Green: consistent with the risk within appetite |
31 Aug 2026 | 1 | Green | Green: consistent with the risk within appetite |
30 Sep 2026 | 2 | Amber | Amber: the risk may be above appetite |
September's value was validated on 7 Oct 2026. The card named who to tell: the HR Director was told the same day (0 working days; limit 5), and reviewed R-09 on 13 Oct 2026 (4 working days; limit 10), keeping it at impact 2 Moderate × likelihood 3 Likely = 6, Medium. The executive committee on 14 Oct 2026 agreed an action: replace text-message codes with an authenticator app for every staff account that can sign in from outside the office, owner Head of IT, due 30 Nov 2026.
Worked example 2: a measure imported unchanged
This is the distributor's card for MC-17 Tier 1 suppliers assessed. The measure belongs to the Third-Party Security Risk Management pack (TPM-01), and the card uses it unchanged (MR-04). P11 adds only what it needs to run it: type, audience, roles, the quality check numbers and the board measure it feeds.
What "unchanged" means, field by field:
Field | P06 TPM-01 | This card, MC-17 | Same |
|---|---|---|---|
Name | Tier 1 suppliers assessed | Tier 1 suppliers assessed | Yes |
Definition | Tier 1 suppliers with an assessment within the last 12 months, out of all Tier 1 suppliers. | Tier 1 suppliers with an assessment within the last 12 months, out of all Tier 1 suppliers. | Yes |
Target | All Tier 1 by [[year end]] | All Tier 1 by [[year end]] | Yes |
Guidance — delete before approval
If P06 changes the target or the definition, the card follows: copy the new words, and record the date and whether earlier values were restated (Part F). Never change them here first.
Delete this worked example from your adopted template.
A What it is for — EXAMPLE | |||
Metric ID and name MR-02 | MC-17 Tier 1 suppliers assessed | Type MR-07 | KPI, leading |
Question it answers MR-01 | Have the suppliers we depend on most been assessed against our security requirements, and will they all be by year end? | ||
Decision it informs MR-01 | Whether to chase or escalate a supplier whose assessment is late, or add assessor time; at the executive committee, whether to accept any Tier 1 supplier going unassessed past year end. | ||
Audience and cadence MR-10 | Operational: monthly Executive: monthly | ||
B What it counts — EXAMPLE | |||
Owning pack MR-04 | P06 Third-Party Security Risk Management, TPM-01. Name, definition and target copied unchanged (MR-04). A change is made in P06, then copied here. | Board measure it feeds MR-04 | BM-05 Critical suppliers assessed (P03) |
Definition MR-04 | Tier 1 suppliers with an assessment within the last 12 months, out of all Tier 1 suppliers. | ||
Formula MR-02 | Tier 1 suppliers with an assessment dated within the 12 months to the period end, out of all Tier 1 suppliers in the register at the period end. Shown as "n of N". | ||
Scope MR-05 | In: Tier 1 suppliers, as tiered by the Supplier Criticality & Tiering Model (P06). Out: Tier 2 and Tier 3 suppliers; suppliers being exited, once their contract has ended. Scope count: the Tier 1 rows in the register at the period end. September 2026: 14. | ||
Better when MR-12 | Higher | Period and as-at date MR-10 | Calendar month, as at its last day |
C Data and roles — EXAMPLE | |||
Data source MR-02 | Supplier Security Risk Register (P06): export of the Tier 1 rows with each supplier's last assessment date | ||
Data supplier MR-03 | Procurement Manager | Validator MR-06 | Assessor: Information Security Manager |
Metric owner MR-03 | Head of Information Security | Reporter MR-03 | Operational: Information Security Manager Executive: Head of Information Security |
D Quality checks — EXAMPLE | |||
Quality checks MR-05 | Scope count (DQ-01): the Tier 1 suppliers in the register Extract deadline (DQ-02): 3 working days after the period end; the export's date must be on or after the period end Plausible range (DQ-03): 0 to the scope count. A fall is plausible only when an assessment passes 12 months old Largest change without explanation (DQ-03): [[2]] a month Cross-check (DQ-03): the same count in BM-05, in the Board Reporting Data Collection Workbook (P03) | ||
E Target, thresholds and escalation — EXAMPLE | |||
Target and tolerance MR-07 | Target: All Tier 1 by [[year end]] (P06, unchanged) Tolerance: [[No more than 2 Tier 1 suppliers neither assessed nor booked before year end]] Before year end the target is judged on plan: a Tier 1 supplier assessed within the last 12 months, or booked to be assessed before year end, counts towards it. With every Tier 1 supplier assessed or booked, the status is On target. | ||
Thresholds and linked risk MR-07 | None: a KPI (MR-07) | ||
Escalation MR-08 | None: a KPI. At "Outside tolerance" an ask goes to the executive committee (P03 BR-06). | ||
F Limits and changes — EXAMPLE | |||
Known limitations MR-01 | • Gaming (P03): An assessment can be a questionnaire returned and never read, and the figure says nothing about what was found. The list of critical suppliers can shrink to improve it. • Read it beside MC-19 High findings past deadline (TPM-03), for what the assessments found. | ||
Change log MR-09 | None since approval | ||
G Approval — EXAMPLE | |||
Approved by and date MR-02 | Head of Information Security, metric owner; Chief Executive, chair of the executive committee. 26 Jun 2026 | ||
Next review MR-11 | By 26 Jun 2027 | ||
How the card was used in September
The card's extract deadline caught an error before anything was reported (QF-01). The Procurement Manager supplied an export dated 31 Aug 2026, giving 8 of 14. The validator, the Information Security Manager, checked the date against the card: the period ended on 30 Sep 2026 and the deadline was 5 Oct 2026, so the export failed the freshness check (DQ-02). The pallet network (SUP-009) was assessed on 15 Sep, after the old export. The fresh export counts it. The corrected figure, 9 of 14, was reported as On target under the on-plan rule in Part E: the other 5 are booked for Q4 2026, so all 14 are on plan for year end.
The plausible range in Part D also warns of the next fall: the oldest assessment, of SUP-001, the managed IT service provider, on 18 Nov 2025, passes 12 months on 18 Nov 2026. If it is not reassessed by then, the count will drop, and the drop is expected.
Related documents
Document | Relationship |
|---|---|
Security Metric Definition & Measurement Method | The rules each field serves (MR-01 to MR-12), the checks in Part D and the change rules in Part F |
Security KPI & KRI Catalogue | Every metric that needs a card, with its catalogue ID |
Metrics Data Collection & Quality Workbook | Where the inputs named in Part C are supplied and checked each period |
Key Risk Indicator Threshold & Escalation Model | How the thresholds and escalation in Part E are set |
Metric Ownership Responsibility Matrix | The roles in Part C, for every metric at once |
Metrics Programme Maturity Self-Check | The annual review that sets the date in Part G (MR-11) |
Board Metric Selection Catalogue (P03) | The board measures in Part B, and the weaknesses named in Part F |
Information Security Risk Register (P05) | The risk a KRI is linked to in Part E |
Adapting this template
Guidance — delete before approval
Small organisation: keep every field; they are what makes a number comparable from one month to the next. A card can be short: many fields take one line. Where one person is both supplier and owner, the validator must still be someone else, such as a finance colleague or an outside adviser (MR-06).
Regulated entity (NIS2, DORA): Implementing Regulation (EU) 2024/2690 asks digital providers to determine what is monitored and measured, the methods that ensure valid results, when, and who measures and evaluates (Annex, point 7.2). Parts B, C and D record each for one metric, so the set of cards is that record. DORA asks financial entities to set key performance indicators and key risk metrics in their digital operational resilience strategy (Article 6(8)(c)); keep the cards with the strategy.
IT run by a service provider: where a provider supplies an input, the data supplier in Part C is the person in your organisation who receives it. Put the extract deadline and the scope count from Part D into the provider's reporting schedule.
A spreadsheet in place of a document: the card works as one row per metric, one column per field, as long as every field is kept and the change log is kept with it.
Delete this section before approval.
Framework references
These references show where this document supports an external framework. They indicate relevance only and do not reproduce the text of any standard. 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).
Framework | Reference | Supported by |
|---|---|---|
ISO/IEC 27001:2022 | Clause 9.1 — Monitoring, measurement, analysis and evaluation | The whole card: what is measured, the method, when, and who measures and evaluates |
NIST CSF 2.0 | GV.OV-03 — “Organizational cybersecurity risk management performance is evaluated and reviewed for adjustments needed” | The whole card: performance evaluated on figures defined once |
NIST CSF 2.0 | GV.RM-02 — “Risk appetite and risk tolerance statements are established, communicated, and maintained” | Part E: KRI thresholds set from the linked risk's appetite and tolerance |
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 | Parts B, C and D: what is measured, how, when and by whom |
DORA — Regulation (EU) 2022/2554 | Article 6(8)(c) — the strategy sets out “clear information security objectives, including key performance indicators and key risk metrics” | The whole card: key performance indicators and key risk metrics |
Definitions
Term | Meaning in this template |
|---|---|
Break in series | The point where a metric's definition, source or thresholds changed. No trend is drawn across it unless earlier values are restated. |
Data supplier | The person who provides an input to a metric each period, from a named source. |
Definition card | The one-page specification of a metric: the question it answers, the decision it informs, the formula, the source, the roles, the checks, the target or thresholds and the known limits. |
Key performance indicator (KPI) | A metric that shows whether a control or process is working as intended, judged against a target. |
Key risk indicator (KRI) | A metric that gives early warning that a risk in the risk register may be moving, judged against thresholds set from that risk's appetite and tolerance. |
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. |
Metric owner | The person who interprets a metric, writes the commentary and answers for it. One per metric. |
Reporter | The person who puts validated values into the report for an audience. |
Scope count | The number of items in scope for a period, which the completeness check compares with the number of items that have a value. |
Target | The value of a KPI the organisation is aiming for. A KPI at or better than its target is On target. |
Threshold | A value of a KRI at which its zone changes: green to amber, or amber to red. |
Tolerance | The limit beyond which the people who set it must act, and not just be told. For a risk, the highest residual band tolerated while a plan brings it back (P05). For a KPI, the furthest short of target the audience accepts without a decision (P03). |
Validator | The person who runs the quality checks on an input and accepts or rejects it. Never the person who supplied it. |
Zone | Where a KRI's value falls: green, amber or red. The zone says what the value suggests about the linked risk. It never changes the risk's position on its own: only a reassessment in the risk register does that (P05). |