Most organisations have a privacy policy, a DPO or privacy lead and a stack of templates, yet few can show with evidence how mature their privacy programme is or which gap to close next. Regulators judge accountability on what you can prove, not on what is written down. This five-level model uses the same Ad hoc to Optimised scale as the NHI Mgmt Group NHI Governance Maturity Model and scores a privacy programme across eleven dimensions, from governance and records of processing to AI. It lines the levels up, loosely, with the NIST Privacy Framework Implementation Tiers, the GAPP-based Privacy Maturity Model and the ICO Accountability toolkit. It is for privacy leads, DPOs, security and GRC teams who need an honest baseline and a roadmap.
Key takeaways
- Score eleven dimensions separately, from governance and the RoPA to breach management and AI, and fix the weakest one that covers your highest-risk processing first.
- Evidence decides the level, not documents. A retention schedule that no system enforces is Level 2. A RoPA that has not been reconciled with real systems in a year is Level 2.
- Level 3 (Defined) is the sensible first target: documented, owned processes covering the whole organisation, with evidence for each of the ten areas in the ICO Accountability toolkit.
- Retention, third parties and AI need other teams to act. Engineering and procurement own most of these fixes, so the privacy team cannot close them alone.
- Maturity must show in numbers: requests closed within one month, DPIAs signed off before go-live and hours to a breach notification decision.
The five levels
| Level | Name | Description |
|---|---|---|
| 1 | Ad hoc | There is no reliable record of what personal data is held or why, subject requests and breaches are handled from scratch each time, and problems surface through complaints, regulator letters or audits. |
| 2 | Developing | A privacy lead or DPO is in place and core policies exist. A first RoPA has been drafted, a DSAR process and a breach log exist, and DPIAs happen for some projects. Coverage is partial and manual. |
| 3 | Defined | Documented, approved processes cover every dimension and every business unit. Owners are named, the RoPA is reconciled with the system inventory, DPIA screening is built into change and procurement, processors have Article 28 contracts and transfer assessments, and a retention schedule exists for every system. |
| 4 | Managed | Processes are measured and partly automated. Data discovery tools keep the inventory current, subject requests run through a workflow with deadlines, deletion is enforced by systems, privacy KPIs are reported to leadership and breach response is tested. |
| 5 | Optimised | Privacy is built into how products and data platforms are engineered. Controls are continuous, privacy-enhancing technologies are used by default where they fit, AI systems are governed from design to retirement, and lessons from incidents and complaints change practice within weeks. |
The eleven dimensions
The table shows Levels 1, 3 and 5; Levels 2 and 4 sit between them, and the roadmap below lists what moves you from one level to the next.
| Dimension | Level 1 Ad hoc | Level 3 Defined | Level 5 Optimised |
|---|---|---|---|
| Governance and accountability | No named owner; privacy seen as a legal task | DPO or privacy lead with board reporting line; privacy policy and standards approved; data owners named per business area | Privacy risk in enterprise risk management; leadership reviews KPIs quarterly |
| Data inventory and RoPA | No record of processing | Article 30 RoPA covering all processing, reconciled with the system inventory at least annually and on change | RoPA fed by automated data discovery and the CMDB; new systems cannot go live without an entry |
| Lawful basis and consent | Basis not recorded; cookies set before consent | Lawful basis recorded per purpose; legitimate interests assessments on file; consent captured, logged and withdrawable | Preferences synchronised across channels in real time |
| Individual rights | Requests handled by whoever receives them | Single intake, identity verification proportionate to risk, tracked one-month deadline, search playbooks per system | Workflow with automated search and redaction across core systems |
| Privacy by design and DPIAs | No DPIAs, or written after launch | DPIA screening in change, project and procurement gates; Article 35 DPIAs signed off before processing starts | Privacy requirements in engineering standards and design patterns; DPIA outcomes tracked to closure |
| Third parties and transfers | Unknown processors; no contracts reviewed | Processor register; Article 28 terms in every contract; due diligence by risk tier; transfer mechanism and assessment for each restricted transfer | Continuous monitoring of processors and sub-processors; contract and transfer status tracked as data |
| Retention and deletion | Data kept indefinitely | Retention schedule per record type and system, owners named, manual deletion runs evidenced | Deletion and anonymisation enforced automatically, including backups and logs on a defined cycle |
| Breach management | No breach log; notification decisions made late | Breach procedure linked to incident response; every breach recorded (Article 33(5)); 72-hour notification assessment owned | Breach scenarios exercised yearly; notification decisions within 24 hours |
| Training | None, or a generic annual video | Mandatory baseline training plus role-based modules for HR, marketing, engineering and customer service | Targeted by role and incident data; measured by fewer errors, not completion |
| Monitoring and metrics | No metrics | Defined KPIs and an annual compliance review against the ICO toolkit or equivalent | Controls tested continuously; independent assurance such as ISO/IEC 27701 |
| AI and new technologies | AI tools used with personal data without review | AI use register; DPIA required for AI that processes personal data; rules on training data and inputs to public AI tools | AI lifecycle governance with privacy testing, data lineage and decommissioning |
How the levels relate to other frameworks
Three published references help calibrate scores; none is an exact match. The NIST Privacy Framework 1.0 (January 2020) defines four Implementation Tiers, "Partial (Tier 1), Risk Informed (Tier 2), Repeatable (Tier 3), and Adaptive (Tier 4)", and NIST is explicit that moving up is "not a compulsory one": success is judged against your Target Profile. NIST released Privacy Framework 1.1 as an initial public draft in April 2025, realigned with CSF 2.0 and with a new section on AI and privacy risk. CPA Canada describes the GAPP-based Privacy Maturity Model, in which "Each of the 73 GAPP criteria is broken down according to five maturity levels": ad hoc, repeatable, defined, managed and optimized. The ICO Accountability toolkit (formerly the Accountability Framework) offers control measures and a self-assessment tracker, not levels.
| This model | NIST Privacy Framework Tier (loose fit) | GAPP Privacy Maturity Model (loose fit) | Evidence that marks the level |
|---|---|---|---|
| 1 Ad hoc | Tier 1 Partial | Ad hoc | No RoPA; no breach log; requests handled informally |
| 2 Developing | Tier 2 Risk Informed | Repeatable | Policies approved; first RoPA; DPIAs for some projects |
| 3 Defined | Tier 3 Repeatable | Defined | Every ICO toolkit area has a documented, owned process with evidence |
| 4 Managed | Tier 3 to Tier 4 | Managed | KPIs reported; deletion enforced by systems; breach response exercised |
| 5 Optimised | Tier 4 Adaptive | Optimized | Continuous controls; lessons learned change practice; privacy engineered into products |
Dimension to framework mapping
| Dimension | GDPR / UK GDPR | ICO Accountability toolkit area | NIST Privacy Framework function |
|---|---|---|---|
| Governance and accountability | Art. 5(2), 24, 37 to 39 | Leadership and oversight; Policies and procedures | Govern-P |
| Data inventory and RoPA | Art. 30 | Records of processing and lawful basis | Identify-P |
| Lawful basis and consent | Art. 6, 7, 9 | Records of processing and lawful basis; Transparency | Control-P, Communicate-P |
| Individual rights | Art. 12 to 22 | Individual rights | Control-P |
| Privacy by design and DPIAs | Art. 25, 35, 36 | Risks and data protection impact assessments (DPIA) | Identify-P, Govern-P |
| Third parties and transfers | Art. 28, Chapter V (Art. 44 to 49) | Contracts and data sharing | Identify-P, Govern-P |
| Retention and deletion | Art. 5(1)(e), 17 | Records management and security | Control-P |
| Breach management | Art. 33, 34 | Breach response and monitoring | Communicate-P (notifying affected individuals), with CSF 2.0 Respond |
| Training | Art. 39(1)(b) | Training and awareness | Govern-P |
| Monitoring and metrics | Art. 5(2), 24(1) | Breach response and monitoring | Govern-P |
| AI and new technologies | Art. 22, 25, 35 | Risks and data protection impact assessments (DPIA) | All functions |
ISO/IEC 27701:2025 (October 2025) is now an independent privacy information management system standard, usable alone or with ISO/IEC 27001, and a natural evidence framework at Levels 4 and 5. See the GDPR Compliance Guide for Security Teams and the Global Privacy Regulatory Map for the wider legal picture.
Self-assessment questions
Score each dimension from 1 to 5 using evidence you could hand to a regulator. Your overall level is the lowest score among the dimensions that cover your highest-risk processing (special category data, children's data, large-scale monitoring), not the average.
- Governance and metrics: who accepts privacy risk, and when did leadership last see privacy KPIs?
- Inventory and RoPA: pick three systems at random from the IT asset list. Are all three in the RoPA with correct purposes, categories and retention?
- Lawful basis and consent: for each marketing and analytics purpose, can you show the basis, the consent record and that tags do not fire before consent?
- Individual rights: what share of last quarter's subject requests closed within one month, and how do you verify identity without collecting more data?
- Privacy by design: how many products or changes went live last quarter that needed a DPIA, and how many had one signed off before launch?
- Third parties: what share of processors have Article 28 terms, a due diligence record and, where data leaves the UK or EEA, a transfer mechanism and assessment?
- Retention: which systems delete data automatically at the end of the retention period, and how much data is already past it?
- Breach management: how many hours passed between detection and the notification decision in your last three breaches, and are unreported breaches logged too?
- AI: do you know which AI tools and models process personal data, what data trained them and who approved them?
Moving up a level
From Ad hoc to Developing
- Appoint a privacy lead or DPO (mandatory under Article 37 for some organisations) with a reporting line to senior management, and publish a short privacy policy.
- Draft a first RoPA from interviews with business owners, starting with HR, customer and marketing processing. See the Data Mapping and ROPA Guide.
- Set up one intake channel for subject requests and a tracker with the one-month deadline. See the DSAR Guide: Handling Data Subject Requests.
- Start a breach log and agree who decides on notification within 72 hours. See the Incident Response Guide.
From Developing to Defined
- Reconcile the RoPA against the system inventory and data classification, and assign a data owner to every entry. See the Data Classification Guide.
- Add DPIA screening questions to the change, project and procurement gates, and pilot them with one product team before mandating them. See the DPIA Guide: Running a Data Protection Impact Assessment.
- Build a processor register, review contracts for Article 28 terms and record a transfer mechanism and assessment for each restricted transfer. See the Third-Party Access Guide.
- Publish a retention schedule per system and run, evidence and sign off the first manual deletion cycle.
- Fix consent: block non-essential cookies and SDKs until consent, and log consent and withdrawal. See the Consent Management Guide: Cookies, CMPs and GPC.
From Defined to Managed
- Deploy data discovery on the main data stores and feed results into the RoPA; pilot on one platform and compare findings with the manual record first.
- Move subject requests into a workflow with system-by-system search playbooks and automated deadline alerts.
- Enforce deletion in the largest customer data stores first, keeping a short restore window as the rollback if a rule deletes the wrong records. See the Log Management and Retention Guide for log data.
- Exercise a personal data breach with the security team once a year, timing the notification decision.
- Create an AI use register and require a DPIA for any AI that processes personal data. See the AI and Privacy Guide.
From Managed to Optimised
- Write privacy requirements into engineering standards and reusable design patterns (pseudonymisation, field-level encryption, data minimisation by default). See the Privacy-Enhancing Technologies Guide.
- Bring AI systems under lifecycle governance with privacy testing before release and a plan for retiring models and training data. See the AI Governance Guide.
- Consider ISO/IEC 27701:2025 certification where customers or regulators value independent assurance.
Metrics that show maturity
- Subject request timeliness: percentage closed within one month, and median days to close.
- RoPA accuracy: percentage of in-scope systems with a current RoPA entry reviewed in the last 12 months.
- DPIA before launch: percentage of high-risk changes with a signed-off DPIA before processing started.
- Breach decision time: hours from detection to notification decision, and percentage of notifiable breaches reported within 72 hours.
- Processor coverage: percentage of processors with Article 28 terms, due diligence and, where needed, a transfer assessment.
- Retention enforcement: percentage of systems with automated deletion, and volume of records past their retention date.
- AI coverage: percentage of AI use cases processing personal data that are registered with a completed DPIA.
Common failure patterns
- Retention without deletion: a schedule is approved but no system deletes anything, so every breach exposes years of data that should have gone.
- DPIAs after launch: assessments written to close an audit finding rather than to change the design.
- Processor blind spots: SaaS tools bought on a card never reach the processor register, and their sub-processors move data overseas unnoticed.
- AI as a side programme: AI tools and agents process personal data under credentials and integrations nobody reviewed. The Spain AEPD AI agent breach notification shows an agent's access to personal data becoming a reportable breach.
- Privacy and security working apart: the incident team contains an intrusion but nobody starts the 72-hour clock for the personal data involved. See the Privacy Programme Guide for Security Teams.
Practitioner checklist
- Score all eleven dimensions with evidence, recording the source for each score.
- Set Level 3 as the 12-month target, with Level 4 for special category and children's data.
- Fix the lowest-scoring dimension that covers your highest-risk processing first.
- Baseline the seven metrics now and report them quarterly.
- Use the ICO Accountability toolkit tracker, or an equivalent, as the annual evidence check, and reassess after new AI use, acquisitions or new markets.
- Join privacy and security processes at three points: breach response, DPIAs for new systems and access to personal data stores. See the Identity Data Privacy and Consent Guide.
Standards and references
- NIST: Privacy Framework Version 1.0
- NIST: Privacy Framework (including the PF 1.1 initial public draft)
- ICO: Accountability toolkit
- ICO: Accountability Framework and data protection audit framework
- ICO: Personal data breaches, a guide
- ISO: ISO/IEC 27701:2025 Privacy information management systems
- CPA Canada: Measuring a privacy program
Related NHI Mgmt Group resources: Privacy Programme Guide for Security Teams · GDPR Compliance Guide for Security Teams · Identity Security Maturity Model · GRC Platform Buyer's Guide. This guide summarises privacy programme practice and the frameworks named above, and is not legal advice.