Most privacy programmes can say how many policies they have approved, but not how many subject requests went past the legal deadline last quarter or how many high-risk launches went live without an assessment. This guide defines operational key performance indicators (KPIs) and key risk indicators (KRIs) for a privacy programme, built around the obligations that carry statutory clocks or prior-to-processing duties: data subject access requests (DSARs), data protection impact assessments (DPIAs), personal data breach handling, records of processing and processor contracts. Each measure has a formula, a source, example thresholds and the legal hook it evidences. It is written for data protection officers (DPOs), privacy leads and the security teams who supply much of the data. Programme design is covered in the Privacy Programme Guide for Security Teams and stage-by-stage capability in the Privacy Programme Maturity Model; exposure of the data itself is measured in the companion Data Security Metrics.
Key takeaways
- Anchor measures to legal clocks. GDPR sets one month for subject requests, 72 hours for regulator breach notification and "prior to the processing" for DPIAs, so timeliness against those clocks is the core of the set.
- Report the tail and the misses. An average DSAR time of 18 days can hide requests answered at day 60; show the 95th percentile and every overdue case.
- Measure the clock from the right start. The DSAR clock starts on receipt and the breach clock on awareness, not when a ticket is triaged; measuring from triage makes every figure look better than it is.
- Count what was skipped, not just what was done. DPIAs completed is activity; high-risk launches without a completed DPIA is the risk.
- Keep the set small and stable. Nine measures, defined once, reported for four quarters before changing, give a DPO report a trend instead of a snapshot.
The legal clocks behind the measures
The EU GDPR text on EUR-Lex sets the anchor points. The UK GDPR follows a similar structure, though after the Data (Use and Access) Act 2025 the UK time limits for subject access responses sit in a new Article 12A; UK guidance is being revised after the Data (Use and Access) Act 2025, and the ICO notes that its breach reporting guidance is under review for that reason, so confirm current UK wording before setting thresholds. Other laws, such as the CCPA and CPRA, set their own response periods; see the CCPA and CPRA guide.
| Obligation | GDPR provision | Clock or trigger | Measure in this guide |
|---|---|---|---|
| Respond to data subject requests | Art. 12(3) | Within one month of receipt; extendable by two further months where necessary, with the requester told within the first month | P1, P2 |
| Assess high-risk processing | Art. 35(1), 35(3) | Prior to the processing; mandatory cases include systematic and extensive profiling, large-scale special category data and large-scale monitoring of public areas | P3, P4 |
| Consult the regulator on residual high risk | Art. 36(1) | Prior to processing | P4 (reported as a count) |
| Notify the supervisory authority | Art. 33(1) | Without undue delay and, where feasible, not later than 72 hours after becoming aware | P5 |
| Document every breach | Art. 33(5) | All personal data breaches, notified or not | P6 |
| Tell affected people | Art. 34(1) | Without undue delay where likely to result in a high risk | P5 |
| Maintain records of processing | Art. 30(1) | Continuous | P7 |
| Contract with processors | Art. 28 | Before processing starts | P8 |
| Demonstrate compliance | Art. 5(2) | Accountability principle | The whole set |
The DPO's tasks under Art. 39(1)(b) include monitoring compliance, which is the natural home for this report. Breach clocks differ outside the GDPR; the Breach Notification Laws by Country Guide sets them out.
The measure set at a glance
| ID | Measure | KPI or KRI | What it shows | Good direction |
|---|---|---|---|---|
| P1 | DSARs completed within the statutory period | KPI | Whether individual rights are met on time | Up, P95 inside the deadline |
| P2 | Overdue open DSARs | KRI | Live non-compliance today | Zero |
| P3 | High-risk launches with a DPIA completed before go-live | KRI | Whether the prior-to-processing duty holds | 100% |
| P4 | DPIA cycle time | KPI | Whether privacy review slows delivery, which drives teams to bypass it | Down without P3 falling |
| P5 | Breach notification timeliness | KPI | Whether notifiable breaches reach the regulator inside 72 hours of awareness | 100% |
| P6 | Detection to awareness decision time | KRI | How long incidents sit before anyone decides whether personal data is involved | Down |
| P7 | Records of processing reviewed in 12 months | KPI | Whether the ROPA describes reality | Up |
| P8 | Processors with a compliant contract and current review | KPI | Whether Art. 28 terms and oversight exist for every processor | Up |
| P9 | Complaints and regulator contacts | KRI | External signal that something is failing | Down; repeat themes at zero |
Defining and calculating each measure
These are NHI Mgmt Group recommended definitions, not regulatory requirements; record your version in a measure dictionary and change it only with a note in the report.
P1 DSARs completed within the statutory period
Formula: requests closed in the quarter where the response was sent within the applicable period (one month, or the extended period where an extension was validly notified within the first month), divided by all requests closed. Report: the percentage; median and 95th percentile calendar days from receipt; the share that used an extension; and volumes by request type (access, erasure, rectification, objection). Source: the request case management system, with receipt date taken from the first channel the request arrived on, including email to staff and social media, not the date it reached the privacy team. Process design is in the DSAR Guide.
P2 Overdue open DSARs
Formula: open requests past their due date at quarter end, plus the oldest overdue age. Report: the count, age bands and the blocking cause (identity verification, a system owner not returning data, legal review). A rising extension rate in P1 alongside P2 above zero usually means extensions are being used to absorb backlog rather than genuine complexity.
P3 High-risk launches with a DPIA completed before go-live
Formula: new or changed processing that met your DPIA screening criteria and went live in the quarter with a signed-off DPIA dated before go-live, divided by all such launches. Report: the percentage and each exception with the system and owner. Source: DPIA register joined to change and release records, so launches that never reached the privacy team are counted. This join is the point of the measure: a DPIA register can only count DPIAs it knows about. See the DPIA Guide and the DPIA Template.
P4 DPIA cycle time
Formula: business days from screening outcome "DPIA required" to sign-off, median and 95th percentile, for DPIAs closed in the quarter. Report: both figures, the number open, the number referred for prior consultation under Art. 36, and the share needing rework. Read P4 with P3: a fast cycle time with falling coverage means teams are avoiding the process, not that it improved.
P5 Breach notification timeliness
Formula: breaches notified to a supervisory authority in the quarter where the initial notification was made within 72 hours of the recorded awareness time, divided by all notified breaches. Report: the percentage, hours from awareness to notification for each case, whether reasons for delay accompanied any late notification, and whether affected individuals were told where the high-risk test was met. Source: the breach register. The ICO encourages an early initial report with details added later, so measure the initial submission, not the final one. Notification steps are in the Data Breach Notification Checklist.
P6 Detection to awareness decision time
Formula: hours from the first security alert or report linked to an incident to the recorded decision on whether a personal data breach has occurred, median and 95th percentile. Report: both figures, with the slowest cases explained. Source: security incident tickets joined to the breach register. This measure sits on the boundary between security and privacy: if the security operations centre takes days to involve the privacy team, the 72-hour clock in P5 is already under pressure, however quickly the DPO acts. Exercise the hand-off with the privacy breach tabletop exercise.
P7 Records of processing reviewed in 12 months
Formula: processing activities in the record of processing activities (ROPA) reviewed and confirmed by their business owner in the last 12 months, divided by all activities. Report: the percentage and new activities found by discovery that were not in the ROPA. Source: ROPA tool or register, compared with data discovery results where available. See the Data Mapping and ROPA Guide.
P8 Processors with a compliant contract and current review
Formula: processors receiving personal data that have a contract containing the Art. 28 terms and a privacy and security review within the agreed review period, divided by all processors in the ROPA and supplier register. Report: the percentage, processors in high-risk tiers shown separately, and international transfers without a documented mechanism. Supplier security measures are reported in the Third-Party Risk Metrics.
P9 Complaints and regulator contacts
Formula: privacy complaints received and regulator enquiries opened in the quarter. Report: counts, themes, upheld complaints and the root cause action taken. A complaint about a late DSAR that P1 recorded as on time is a data quality finding about P1.
Thresholds and targets
The values below are NHI Mgmt Group example starting points; calibrate them against two quarters of baseline and your risk appetite.
| ID | Green | Amber | Red |
|---|---|---|---|
| P1 | 98% or more, P95 within the deadline | 90% to below 98% | Below 90% |
| P2 | Zero | Not used | One or more |
| P3 | 100% | Not used | Any high-risk launch without a prior DPIA |
| P4 | Median 15 business days or less | 16 to 30 | Over 30, or P3 falling |
| P5 | 100% | Not used | Any notification later than 72 hours |
| P6 | P95 within 24 hours | 24 to 48 hours | Over 48 hours |
| P7 | 95% or more | 80% to below 95% | Below 80% |
| P8 | 100% of high-risk processors, 95% overall | Any high-risk processor overdue for review | Any processor without Art. 28 terms |
| P9 | Falling, no repeat theme | Flat | Rising two quarters, or any regulator investigation |
P2, P3 and P5 have no amber band because each failure is a breach of a specific obligation, not a trend to manage.
Reporting to the DPO, executive and board
- DPO operational report (monthly): all nine measures, the overdue DSAR list, open DPIAs and the breach register summary.
- Executive committee (quarterly): P1, P3, P5 and P9 with trend, red items with actions, and resourcing asks such as more DSAR handlers or automated data retrieval.
- Board (half-yearly or on a red KRI): one paragraph inside the cyber and data risk pack, with P3 and P5 as headline KRIs. The structure is in the Board Cyber Risk Reporting Guide.
- Volumes beside rates: always show request and breach counts, so a 100% on-time rate on three requests is not read as proof of capacity.
Where security teams supply the data
| Measure | Security input | Typical gap |
|---|---|---|
| P1, P2 | Data retrieval from logs, backups and SaaS tenants; identity verification | No owner for retrieval from security tooling, so requests stall |
| P3 | Change and release records; architecture review | Security reviews launches but does not check for a DPIA reference |
| P5, P6 | Incident tickets, forensic scoping of records and data subjects | Personal data question asked late in triage |
| P7 | Data discovery and classification results | Discovery runs but results never reach the ROPA owner |
| P8 | Supplier security assessments | Security and privacy reviews run separately with different supplier lists |
Machine identities matter here too: DSAR retrieval and erasure automation run on service accounts with broad read and delete rights across systems, which should be scoped and reviewed like any privileged access. See the Data Access Governance Guide.
How to implement
- List the obligations in scope by jurisdiction, with each clock and trigger, and get legal sign-off on the start point for each.
- Fix the timestamps: receipt for DSARs, screening outcome and go-live for DPIAs, awareness for breaches. Make them mandatory fields in the case tools.
- Join the data sources: DPIA register with release records (P3), incident tickets with the breach register (P6), ROPA with the supplier register (P8).
- Run two quarters as a baseline without thresholds, and fix missing timestamps and unregistered launches as they surface.
- Set thresholds and agree escalation routes with the DPO and risk committee.
- Report unchanged for four quarters, then review the set. Retire stable measures and add the next weak point, such as erasure completion across backups.
- Roll back on bad data: show a measure as "not reported" with the reason when a source breaks, rather than carrying the last value forward.
Small and large organisations
A small organisation with a handful of requests a year can track P1, P2, P3, P5 and P7 in a spreadsheet and report case by case rather than as rates. A large or multi-jurisdiction organisation needs per-law clocks, per-entity reporting, automated DSAR intake and retrieval, and P6 measured inside the security operations workflow. The Privacy Programme Maturity Model shows which measures are realistic at each stage.
Framework mapping
| Measure | GDPR | NIST SP 800-53 Rev. 5 | ISO/IEC 27701 |
|---|---|---|---|
| P1, P2 Subject requests | Art. 12(3), Arts. 15 to 22 | PM-26, SI-18 | Obligations to PII principals |
| P3, P4 DPIAs | Arts. 35, 36 | RA-8 | Privacy impact assessment |
| P5, P6 Breaches | Arts. 33, 34 | IR-6, IR-8(1) | Incident management |
| P7 ROPA | Art. 30 | PM-5(1), PT-3 | Records related to processing PII |
| P8 Processors | Art. 28 | SA-9 | Customer and processor agreements |
| Programme reporting | Arts. 5(2), 39(1)(b) | PM-6, PM-18, PM-19, PM-27 | Performance evaluation |
In NIST CSF 2.0 terms, the set evidences GV.OV-03 (performance is evaluated and reviewed) and RS.CO-02 (stakeholders are notified of incidents). ISO/IEC 27701:2025 is now a standalone privacy information management system standard that can be aligned with an ISO/IEC 27001 system; its performance evaluation clause is where these measures live.
Common failure patterns
- Clock started at triage: DSAR and breach times measured from when the privacy team logged the case, not from receipt or awareness, hiding days of delay.
- Extensions used as backlog relief: a high extension rate with no recorded complexity reason, which also fails the requirement to tell the requester within the first month.
- DPIA register counted in isolation: 100% of registered DPIAs complete, while launches that never reached the privacy team are invisible.
- Unreported breaches not recorded: breaches judged non-notifiable are left out of the register, although Art. 33(5) requires all to be documented.
- Security and privacy hand-off unmeasured: the DPO meets the 72 hours from awareness, but awareness was recorded days after the security team saw the incident.
- Erasure measured in production only: erasure requests closed while copies remain in backups, analytics and exports.
Practitioner checklist
- Map every measure to an obligation and its clock, per jurisdiction.
- Record receipt, go-live and awareness timestamps as mandatory fields.
- Report 95th percentiles and every overdue or late case.
- Join the DPIA register to release records to find launches without a DPIA.
- Document every breach, notified or not, and measure the initial notification time.
- Measure the security to privacy hand-off time for incidents.
- Keep the ROPA and supplier register reconciled.
- Show volumes beside every rate and keep definitions stable for four quarters.
Standards and references
- EUR-Lex: Regulation (EU) 2016/679, General Data Protection Regulation
- ICO: Personal data breach reporting
- ICO: Right of access guidance
- ICO: Accountability toolkit
- ISO: ISO/IEC 27701 Privacy information management systems
- NIST: SP 800-55 Vol. 1 Measurement Guide for Information Security
- NIST: Privacy Framework
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls for Information Systems and Organizations
Related NHI Mgmt Group resources: Privacy Programme Guide for Security Teams · Privacy Programme Maturity Model · Data Security Metrics · Security Metrics and KPIs Guide