What the Privacy Dashboard Is Not Telling the Board
Eleven months after its PIMS went live, Hesta Health Network runs a monthly privacy dashboard for its executive team. It contains three measures: privacy training completion (currently 100%), number of privacy incidents (one this year) and "regulatory fines (EUR 0)". Behind the dashboard: 14 product changes went live last quarter and two had a privacy review; 210 data subject requests were received and 78 were answered after the 30-day deadline; the retention schedule says imaging data is kept seven years after the last episode of care, but no deletion job exists; 31 of 190 vendors have a current data processing agreement. Internal audit was outsourced and covered ISO/IEC 27001 Annex A only, with no PIMS sampling, and the audit team included no privacy specialist. The management review agenda held the security risk register and the incident summary, and the meeting lasted 40 minutes. The board asks whether privacy is "under control" and the PIMS manager is unsure what to say.
1. Redesign the measurement set: what should Hesta measure, with examples, thresholds and the rationale for each choice?
Read the worked answer
Start from the controls that actually prevent harm, and measure whether they operate, not whether people attended training. Each metric needs a definition, a data source, an owner, a threshold and a response when the threshold is breached.
- Data subject requests: percentage answered within the statutory period, median days to close, open backlog aged over 20 days. Threshold: 95% on time, backlog under 10. Rationale: this is a direct legal obligation and the clearest signal of operational capacity.
- Privacy review coverage: percentage of product and process changes screened; percentage of high-risk changes with a completed DPIA before go-live. Threshold: 100% screened, zero go-lives without sign-off. Rationale: harm is designed in at change time, not discovered later.
- Retention execution: percentage of datasets where deletion ran on schedule, and count of datasets past retention. Rationale: an unenforced schedule is a documented intention to over-retain.
- Vendors: percentage with a current DPA and completed due diligence; time to offboard. Threshold: 100% for high-risk vendors.
- Consent and preferences: percentage of withdrawals actioned within the stated SLA.
- Incidents: time from detection to notifiability decision; recurrence by cause.
- Audit and corrective actions: percentage closed on time and verified effective.
Drop "fines" and "incidents" as primary measures: they are outcomes, lag behind reality by months, and encourage under-reporting. Training completion should be replaced by assessment scores or simulated tests. Present the set as a RAG dashboard with trends, not single numbers.
2. Assess the internal audit. What does the PIMS require, and what should change before the next cycle?
Read the worked answer
The current audit cannot support the PIMS. It covers the wrong criteria, the wrong population and lacks the competence to interpret what it finds.
Criteria. An ISO/IEC 27701 audit must test the PIMS-specific requirements and the applicable Annex controls alongside the ISMS controls, not merely re-perform an Annex A check of ISO/IEC 27001. The audit criteria should be written into the programme and the engagement letter.
Scope and sampling. The sample must cover the PIMS scope and the processing activities that carry the most risk: data subject requests, retention deletion, vendor management, consent, incident handling and privacy review of changes. A sample of five DSARs and ten vendor files will reveal more than another walkthrough of the data centre.
Competence and objectivity. Auditors need privacy knowledge and familiarity with the applicable legal context. If the outsourced firm cannot supply that, add a specialist or use a different provider; note the competence rationale in the programme.
Reporting and follow-up. Findings should be graded, assigned owners and tracked to verified closure, and the results must feed management review before the certification audit.
Also check independence: if the same team designed the PIMS and then audits it, document how objectivity is preserved. A revised programme, an addendum engagement covering PIMS criteria and a scheduled audit before the next management review would close most of this gap.
3. What must management review cover for the PIMS, and what decision should the executive team take given these findings?
Read the worked answer
The review needs to be an input-driven decision forum, not a status briefing. Required inputs include: status of actions from previous reviews; changes in external and internal issues, including new or amended privacy law and regulatory guidance; feedback from interested parties such as regulators, customers, the DPO, works councils and data subjects; privacy risk assessment results and the status of treatment; monitoring and measurement results against objectives; internal audit results; nonconformities and corrective action status; adequacy of resources and competence; and improvement opportunities, including complaint and request trends and breach data.
Outputs must be decisions: changes to the PIMS, resource commitments, changes to risk treatment, revised objectives, and actions with owners and dates.
On these findings the honest answer to the board is "not demonstrated". The evidence points to three specific failures: a legal obligation (DSAR timeliness) missed in 78 of 210 cases, a change process that bypasses privacy review in 12 of 14 cases, and a retention control that exists only on paper. The executive team should treat the first two as nonconformities with root-cause analysis, commission a PIMS-scoped internal audit, assign an owner for vendor contracting with a dated target, and require the dashboard plus a trend view at every subsequent review. "Zero fines" is not evidence of control, and saying so is part of the PIMS manager's job.