Data Security Metrics: Board KPIs and KRIs for Exposure Trend and Risk Reduction

Boards are usually told how many data stores were scanned and how many DLP alerts fired, numbers that grow with tool coverage and say nothing about whether sensitive data is less exposed than it was a year ago. This guide sets out a board-level set of key performance indicators (KPIs) and key risk indicators (KRIs) for a data security programme: how much sensitive data is exposed, how widely it can be reached, how long exposures survive, how much is kept past its useful life and whether actual data loss is falling. For each measure it gives a definition, a calculation, a source, example tolerances and how to show the trend. It is written for data security leads, CISOs and the risk teams who build committee packs. Operational measures such as encryption coverage, key rotation and DLP policy mode belong in the quarterly Data Security Health Check; privacy operations measures such as subject request timeliness are in the companion Privacy Programme Metrics.

Key takeaways

• Measure exposure, not activity. Scan counts and alert volumes rise when tooling improves; the board needs sensitive records exposed, reachable and retained, read as a trend.
• Weight by sensitivity and volume. One public bucket of payment card data matters more than fifty internal folders of draft slides, so count records and data classes, not just findings.
• Report time to close as well as counts. An exposure fixed in four hours and one open for four months are both "one finding"; the 95th percentile shows which kind you have.
• Retention is risk reduction. Sensitive data deleted on schedule cannot be breached, so the volume held past retention is one of the cheapest KRIs to move, and storage limitation is a GDPR Article 5(1) principle in its own right.
• Keep two layers, linked. Eight board measures, of which only two overlap the operational health check, with the health check explaining why a board measure moved.

KPIs, KRIs and the measurement basis

NIST SP 800-55 Volume 1 (December 2024) treats a measure as a quantifiable and objective value that results from measurement, and groups measures into four types: implementation measures show the progress of specific controls, effectiveness measures evaluate how well controls are working, efficiency measures examine timeliness, and impact measures connect security to the organisation's mission, costs and public trust. It describes a target as a range or an upper or lower bound, with interim targets allowed. It also separates leading indicators, which track behaviour that precedes incidents, from lagging indicators, which track outcomes. A data security board set should be mostly effectiveness and impact measures, with a mix of leading and lagging indicators, each framed against risk appetite. The general method is in the Security Metrics and KPIs Guide and the distinction is explained in KRI vs KPI in Cyber Security.

The board set at a glance

A sensitive record is a row, object or document in a data class rated confidential or restricted in your classification scheme, such as payment card data, health data, credentials, source code or regulated personal data. The scheme itself is covered in the Data Classification Guide.

Only M1 and M2 overlap the health check (inventory completeness DS-02 and public exposure DS-03). The board versions are record-weighted, where the health check counts stores. Keep the IDs fixed in every pack so trends compare quarter to quarter.

Defining and calculating each measure

Each definition states the formula, the reporting cut and the source. These are NHI Mgmt Group recommended definitions, not requirements of any standard; write your version down and change it only with a note in the pack.

M1 Sensitive data under governance

Formula: sensitive stores that are inventoried, classified and assigned a current owner, divided by all stores where discovery found sensitive data, across cloud accounts, SaaS tenants, warehouses, file shares and backups. Report: the percentage, the count of ungoverned stores, and coverage by environment. Source: discovery and data security posture management (DSPM) results joined to the data inventory. Every other figure is only as good as M1: a falling exposure count over 60% coverage can simply mean the exposed data sits in the other 40%. The tooling is described in the Data Security Posture Management (DSPM) guide.

M2 Externally exposed sensitive records

Formula: sensitive records readable by anonymous users, public links or external accounts that are not approved partners, at quarter end, plus the peak during the quarter. Report: records by data class, the number of distinct exposures and how many were found by your own controls rather than by a third party. Source: posture findings for storage, snapshots and databases, SaaS sharing reports and external attack surface results. The "found by us" share is a strong board signal: exposures reported by researchers, customers or journalists mean detection is not working.

M3 Sensitive data exposure index

Formula: for each sensitive store, records multiplied by a sensitivity weight (for example restricted 3, confidential 1) multiplied by a reach weight (for example external 10, organisation-wide 3, team 1, named individuals 0.2), summed across governed stores and indexed to 100 at the baseline quarter. Report: the index trend over at least four quarters and the five stores contributing most. Source: DSPM or data access governance analytics. The weights are a judgement: agree them with the risk committee once, publish them in the measure dictionary and do not tune them to improve the line. The index is the single measure most likely to answer "are we safer than last year?".

M4 Broadly accessible sensitive records

Formula: sensitive records accessible to organisation-wide groups, all authenticated users, default groups or standing machine credentials that are not limited to the specific dataset, divided by all sensitive records. Report: the percentage, with human group access and non-human access shown separately. Source: effective permissions analysis from data access governance tooling, cloud IAM and SaaS sharing settings. Service accounts, API keys and AI agents with wide read access to warehouses and buckets are often the largest contributor, so report them as their own line. See the Data Access Governance Guide.

M5 Critical exposure time to close

Formula: hours from detection to verified remediation for exposures rated critical (external reach or restricted data with broad access), median and 95th percentile, for exposures closed in the quarter. Report: both figures, the share closed within service level and every exposure still open beyond it, with owner and age. Source: posture findings with open and close timestamps, validated by rescan. Count closure on rescan, not on a ticket being resolved.

M6 Sensitive data held past retention

Formula: sensitive records older than the retention period set in the records schedule for their data class, divided by all sensitive records in governed stores. Report: the percentage, the volume deleted in the quarter and legal holds shown separately so they are not counted as failures. Source: data inventory with creation or last business-use dates, the records schedule and deletion logs. The health check measures whether retention rules exist; this measure shows whether data is actually leaving. See the Data Retention and Secure Deletion Guide.

M7 Sensitive data in unprotected copies

Formula: sensitive records found in non-production environments, analytics sandboxes, ad hoc exports, developer endpoints and AI training or retrieval stores without masking, tokenisation or equivalent production controls. Report: records by location type and the trend. Source: discovery scans over non-production accounts and data platforms, and DLP discovery on endpoints. Copies sprawl faster than production data and usually sit under weaker access control. Generative AI data flows are covered in the GenAI Data Security Risks and Mitigations Guide.

M8 Confirmed data loss events

Formula: incidents in the quarter where sensitive data was confirmed accessed or taken by an unauthorised party, by severity, with records and data classes affected. Report: count and records by severity, root cause category (misconfiguration, credential misuse, insider, supplier) and which board measure should have caught it. Source: the incident register, not DLP alert counts. This is the lagging measure that tests the others: if M8 rises while M2 to M4 fall, the board set is measuring the wrong exposures. Supplier-caused events link to third-party reporting, see Third-Party Risk Metrics.

Setting tolerances and targets

KRIs need tolerances drawn from the cyber risk appetite statement; KPIs need targets with dated milestones. The values below are NHI Mgmt Group example starting points, to be calibrated against your baseline. The Cyber Risk Appetite Statement Template shows how to word the appetite they derive from.

M2 has no amber band on purpose: a live external exposure of sensitive data is an event to fix and explain. Record a reason whenever a tolerance changes, so the board can see bands were not moved to turn a measure green.

Presenting the trend and the risk reduction

• Headline: one sentence on whether sensitive data exposure is inside appetite and the direction of M3 since the last pack.
• Trend panel: M3 as a line over at least four quarters, with the glide path and the points where major remediation landed.
• Measures table: M1 to M8 with value, previous quarter, status and owner. Always show the count behind each percentage.
• Risk reduction statement: exposure removed in the quarter, in records and index points, attributed to named work (a warehouse permissions clean-up, a retention purge). This is the impact view SP 800-55 says executives most want.
• Exceptions: every red item with cause, action and date, and every accepted risk with expiry.
• Coverage statement: which environments are in M1, and what is not yet scanned.
• Decisions requested: funding, risk acceptance or a policy change such as a shorter retention period.

Data security is normally one page in the wider pack described in the Board Cyber Risk Reporting Guide.

Data quality and assurance

• Classification accuracy: every measure inherits classifier errors. Sample a set of findings each quarter, record precision, and state it in the appendix.
• Record counts: unstructured data rarely has a clean record count. Use documents or objects as the unit, say so, and keep the unit fixed.
• Rescan evidence: remediation counts only when a later scan confirms it.
• Independence: the team that runs the tooling should not be the only one producing and approving the figures, consistent with separation of duties in SP 800-53 AC-5. Have the second line recalculate one measure per quarter from raw exports.
• Definition breaks: when coverage or weights change, restate prior quarters or mark the break on the chart.

How to implement

1. Link each KRI to a register risk, such as external exposure of customer data or loss of source code, so tolerances follow appetite rather than whatever is easy to count.
2. Fix the scope and units: the data classes counted as sensitive, the environments, and the unit (records, objects or documents) per store type.
3. Write the measure dictionary with formula, weights, source, owner and reporting cut for M1 to M8.
4. Run two quarters as a baseline without showing thresholds to the board. Expect gaps: stores with no owner, unstructured stores with no counts, non-production accounts never scanned.
5. Calibrate tolerances and the M3 glide path against the baseline and have the risk committee approve them.
6. Report for four quarters unchanged, then retire a measure that has stayed green with low variation and bring in the next exposure.
7. Roll back cleanly: if a source breaks or coverage drops sharply, show the measure as "not reported" with the reason rather than carrying the last value forward.

Small and large organisations

A smaller organisation without DSPM can report M1, M2, M5, M6 and M8 from cloud provider posture findings, SaaS sharing reports, a spreadsheet inventory and the incident register, and use store counts in place of record counts. The exposure index and broad-access measures need permissions analytics that usually arrive with a platform. A large or regulated organisation should report by legal entity and data class, add the record-weighted index, and expect internal audit and regulators to test the figures. The stage a programme has reached is described in the Data Security Maturity Model.

Where identity fits

Exposure is a function of who and what can reach data. In M4 and M8, standing machine credentials are frequently the path: a long-lived access key with read access to a whole bucket, a warehouse service account shared by several pipelines, or an AI agent granted broad retrieval scope. Report non-human access as its own M4 line and tag M8 root causes by identity type. The identity side is measured in the NHI Programme Metrics.

Framework mapping

Frameworks require that performance is measured and reviewed but do not prescribe these measures; the table shows which controls each measure evidences.

CIS Controls v8.1 Control 3 (Data Protection) covers the underlying safeguards, including data inventory, retention, encryption and data loss prevention.

Common failure patterns

• Findings counted, records ignored: a dashboard of "open findings" that treats a public archive of customer records the same as a misconfigured empty bucket.
• Coverage growth read as risk growth: onboarding a new cloud account doubles the findings and the board concludes the programme is failing. Show M1 beside every count.
• DLP alerts as the loss measure: alert volume tracks policy tuning, not loss. M8 must come from confirmed incidents.
• Machine access left out: permissions analysis limited to human groups misses the keys and service accounts that reach the most data.
• Retention measured as policy, not deletion: rules exist on paper while the oldest sensitive data is never removed.
• Weights tuned to the result: changing the index weights in the quarter the line would have risen, with no recorded reason.

Practitioner checklist

• Choose no more than eight board measures, mixing leading exposure and lagging loss measures.
• Show M1 coverage beside every other figure.
• Weight exposure by sensitivity and reach, and publish the weights.
• Report the 95th percentile time to close, not only the median.
• Measure data deleted, not just retention rules written.
• Scan non-production, exports and AI data stores, not only production.
• Report non-human access to sensitive data as its own line.
• Take loss events from the incident register, with root cause tags.
• Have the second line recalculate one measure each quarter.

Standards and references

• NIST: SP 800-55 Vol. 1 Measurement Guide for Information Security, Identifying and Selecting Measures
• NIST: Cybersecurity Framework 2.0
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls for Information Systems and Organizations
• CIS: Control 3 Data Protection
• EUR-Lex: Regulation (EU) 2016/679, General Data Protection Regulation
• NCSC: Cyber Security Toolkit for Boards

Related NHI Mgmt Group resources: Data Security Guide · Data Security Health Check · Privacy Programme Metrics · Data Security and AI Executive Briefing