Most privacy programmes fail in the gap between a legal team that writes obligations and a security team that never turns them into controls, evidence and alerts. GDPR, the UK GDPR and a growing set of US state laws all expect organisations to show that personal data is mapped, assessed for risk, protected appropriately and handled correctly when something goes wrong. Security teams own much of that evidence: access controls, encryption, logging, incident response and supplier assurance. This guide explains how to structure a privacy programme that security can run with legal, which obligations land on security, how to choose between the NIST Privacy Framework and ISO/IEC 27701, and how to measure whether the programme works. It is written for CISOs, security architects and GRC leads who have been asked to "own privacy" or to work alongside a privacy office.
Key takeaways
- Privacy risk is wider than security risk. The NIST Privacy Framework separates privacy events caused by data processing from cybersecurity-related privacy events; security teams own the overlap but must not mistake it for the whole programme.
- Several legal duties are security deliverables. GDPR Articles 25, 28, 30(1)(g), 32, 33 and 35 all need evidence that only security and IT can produce.
- Keep the DPO independent of security decisions. GDPR Article 38(3) says the DPO takes no instructions and reports to the highest management level; a CISO who decides how monitoring data is processed is unlikely to pass the ICO's test for the role.
- US state laws now require written assessments and audits. California's first cybersecurity audit certifications are due in April 2028, and Virginia and Colorado require data protection assessments for higher-risk processing.
- Identity is the most used privacy control. Who and what can reach personal data, including service accounts and AI agents, decides most real-world privacy outcomes.
Where privacy and security meet
The NIST Privacy Framework (version 1.0, January 2020) describes cybersecurity risk as arising from loss of confidentiality, integrity or availability, and privacy risk as arising from data processing itself, even when nothing is breached. The overlap, "cybersecurity-related privacy events" such as data theft or unauthorised internal access, is where security teams already work. Outside it sit risks security tools do not see: collecting more than needed, using data for an incompatible purpose, keeping it too long, or profiling people unfairly.
GDPR reflects the same split. Article 5(1) lists six principles: lawfulness, fairness and transparency; purpose limitation; data minimisation; accuracy; storage limitation; and integrity and confidentiality. Only the last is a classic security principle, but Article 5(2) makes the controller accountable for demonstrating all six. In practice security is asked to evidence integrity and confidentiality, and to supply the technical means (deletion jobs, access restriction, pseudonymisation) for the others.
Governance: roles and structure
| Role | Accountable for | Source or practice |
|---|---|---|
| Data protection officer (DPO) | Advising, monitoring compliance, training, audits, DPIA advice, regulator contact | GDPR Articles 37 to 39; mandatory for public bodies and for core activities involving large-scale monitoring or large-scale special category data |
| Chief privacy officer or senior privacy official | Leading the programme and privacy risk management | NIST SP 800-53 PM-19 (Privacy Program Leadership Role) |
| CISO and security team | Article 32 measures, breach detection and response, supplier security, access control | GDPR Articles 32 to 34; NIST CSF 2.0 |
| Control assessors | Testing privacy and security controls and reporting results | NIST SP 800-37 Rev. 2 treats security and privacy assessment in one Risk Management Framework |
| Privacy steering committee | Risk acceptance, priorities, budget, escalations | Common practice; members from legal, security, IT, HR, product and data |
| Data and system owners, privacy champions | Keeping records of processing accurate, triggering DPIAs | Common practice; owners are named in the record of processing |
- DPO independence: Article 38(3) bars instructions to the DPO on how tasks are carried out and requires direct reporting to the highest management level; Article 38(6) allows other duties only if they create no conflict of interest. The UK ICO says a DPO cannot hold a role that decides how personal data is processed, and that the DPO is not personally liable for compliance; the controller is.
- Programme plan: NIST SP 800-53 PM-18 asks for a privacy programme plan describing structure, resources, roles, the controls used to meet requirements and how teams coordinate, approved by a senior official. It is a useful template even outside US federal systems.
- Where privacy sits: a privacy office in legal works when security has a named counterpart and shared metrics; a privacy function inside security works when the DPO keeps a direct line to the board and no operational decision rights over processing. Either fails if no one owns the record of processing.
Obligations that land on security
| Obligation | Source | Security deliverable |
|---|---|---|
| Security appropriate to the risk, including pseudonymisation and encryption, resilience, timely restoration and regular testing | GDPR Art. 32(1)(a) to (d) | Encryption standards, backup and restore tests, penetration tests and control testing evidence |
| Data protection by design and by default: only necessary data, limited access, not accessible to an indefinite number of people by default | GDPR Art. 25(1) and (2) | Secure design reviews, default-deny access, retention settings in new systems |
| Record of processing including a general description of security measures | GDPR Art. 30(1)(g) and 30(2)(d) | Security measures summary per system, kept current |
| Processor contracts requiring Article 32 measures, confidentiality, deletion or return, and audit rights | GDPR Art. 28(3)(b), (c), (g), (h) | Supplier security assessment and contract schedule |
| Breach notification to the regulator within 72 hours where feasible, with reasons for any delay, and a record of every breach | GDPR Art. 33(1) and 33(5) | Incident runbooks, breach register, decision log |
| Data protection impact assessment before high-risk processing | GDPR Art. 35 | Threat model and security measures section of each DPIA |
| Reasonable administrative, technical and physical data security practices | Virginia Code § 59.1-578(A)(3) | Documented security programme scaled to data volume and sensitivity |
| Cybersecurity audits and risk assessments, with certifications and attestations filed with the CPPA | California CCPA regulations effective 1 January 2026 | Independent audit evidence, risk assessment records |
Penalties follow the same split. Under GDPR Article 83(4), failures under Articles 25 to 39, which include security, records, breach notification, DPIAs and the DPO, carry fines up to EUR 10 million or 2% of worldwide annual turnover, whichever is higher. Breaches of the Article 5 principles, data subject rights or transfer rules fall under Article 83(5): up to EUR 20 million or 4%.
US state laws: what security teams need to know
The US has no comprehensive federal consumer privacy law, so states have passed their own. The table below covers three that set security-relevant duties, confirmed from each state's official text or regulator. Check every state where you have customers, because thresholds and exemptions differ.
| State | Applies to (summary) | Security-relevant duties |
|---|---|---|
| California (CCPA) | For-profit businesses with gross annual revenue of $26.625 million or more (from 1 January 2025), or that buy, sell or share personal information of 100,000 or more residents or households, or earn 50% or more of revenue from selling or sharing it | Regulations approved 23 September 2025 and effective 1 January 2026: risk assessments from 1 January 2026, with an attestation and summary due to the CPPA by 1 April 2028; cybersecurity audit certifications due 1 April 2028 (revenue over $100 million), 1 April 2029 ($50 million to $100 million) and 1 April 2030 (under $50 million); automated decision-making rules from 1 January 2027. Consumers can sue after certain data breaches. |
| Virginia (Consumer Data Protection Act) | Controllers of personal data of at least 100,000 consumers a year, or at least 25,000 consumers with over 50% of gross revenue from selling personal data; exempts GLBA financial institutions, HIPAA covered entities and business associates, nonprofits and higher education | Reasonable data security practices; data minimisation; consent for sensitive data; data protection assessments for targeted advertising, sale, risky profiling, sensitive data and other heightened-risk processing, which the Attorney General can demand |
| Colorado (Colorado Privacy Act, in effect since 1 July 2023) | Controllers processing data of more than 100,000 consumers a year, or earning revenue or discounts from selling data of 25,000 or more | Data protection assessments before selling data, processing sensitive data or risky processing; universal opt-out mechanisms honoured from 1 July 2024; rules at 4 CCR 904-3; enforced by the Attorney General and district attorneys |
Virginia allows one assessment to cover similar processing and accepts assessments done for other laws if they are reasonably comparable in scope and effect. Build one assessment template that satisfies GDPR Article 35(7) and the state laws together, rather than separate documents per jurisdiction.
Choosing a framework: NIST Privacy Framework, ISO/IEC 27701 or SP 800-53
| Framework | What it is | Best fit |
|---|---|---|
| NIST Privacy Framework 1.0 | Voluntary outcomes framework with five Functions: Identify-P, Govern-P, Control-P, Communicate-P and Protect-P; Profiles and four Implementation Tiers (Partial, Risk Informed, Repeatable, Adaptive). Version 1.1 is in draft. | Organisations already using NIST CSF that want a gap analysis and roadmap without certification |
| ISO/IEC 27701:2025 | Privacy information management system requirements for PII controllers and processors; second edition published October 2025 as an independent management system standard that aligns with ISO/IEC 27001 | Organisations that need certifiable, auditable evidence for customers and regulators, especially processors |
| NIST SP 800-53 Rev. 5 | Control catalogue with privacy built in: the PT family (PII Processing and Transparency, PT-1 to PT-8) plus PM-18 and PM-19 for the programme | US federal systems and contractors, and anyone needing control-level detail for assessment |
- Use the Privacy Framework with CSF 2.0: Protect-P is the Function focused on cybersecurity-related privacy events, and NIST says the CSF's Detect, Respond and Recover Functions can be used alongside it. That lets security reuse its CSF profile rather than start again.
- Choose ISO/IEC 27701 when customers ask for certification, you already hold ISO/IEC 27001, or you act mainly as a processor. Under the 2019 edition it extended ISO/IEC 27001; the 2025 edition can be used alone.
- Small organisations: GDPR Article 30(5) relieves organisations with fewer than 250 employees of records of processing only where processing is occasional, unlikely to create risk and does not involve special category or criminal data. Most organisations handling staff and customer data routinely do not qualify, so keep a record anyway; a spreadsheet maintained by named owners is enough to start.
- Large organisations: federate the record of processing to business units, put DPIA triggers into change management and procurement, and report a single set of metrics to the steering committee.
Privacy risk assessment and the control baseline
A DPIA is required before processing likely to result in high risk, and always for systematic and extensive automated evaluation with significant effects, large-scale special category or criminal data, and large-scale monitoring of public areas (Article 35(3)). Article 35(7) sets the minimum content: a description of the processing and purposes, a necessity and proportionality assessment, an assessment of risks to individuals, and the measures to address them. The controller must seek the DPO's advice and review the DPIA when the risk changes.
Security's contribution is the last two parts: a threat model of the data flows and the measures that reduce the risk. Assess likelihood and impact to the individual, not only to the organisation; a low-value record to the business can be serious for the person. A practical control baseline for systems holding personal data:
- Inventory: data stores tagged with data categories and owners, matching the record of processing.
- Access: role-based access with periodic review, privileged access through a managed path, and no shared accounts. See the Access Reviews Guide.
- Encryption and pseudonymisation: encryption at rest and in transit, with keys managed separately; pseudonymised data in analytics and test environments.
- Retention: automated deletion or anonymisation at the end of the retention period, with logs showing it ran.
- Logging: access to personal data logged and retained for investigation, with the logs themselves treated as personal data.
- Suppliers: Article 28 terms in every processor contract and a risk-based security assessment before onboarding.
Building the programme: a phased roadmap
- Establish governance (months 0 to 3). Appoint or confirm the DPO and the senior privacy official, form the steering committee, write the programme plan and agree a RACI between legal, privacy and security.
- Map the data (months 1 to 6). Build the record of processing from interviews and from technical discovery (data catalogue, cloud storage scans, SaaS inventory). Reconcile the two; differences are your shadow processing.
- Assess risk. Run DPIAs on existing high-risk processing first, then embed a DPIA screening question in change, architecture review and procurement.
- Implement the baseline. Prioritise systems holding special category data and large customer datasets. For deletion and minimisation jobs, run in report-only mode first, review what would be removed, then enable deletion with backups or soft-delete so a mistake can be reversed.
- Rehearse breach response. Run a tabletop that starts the 72-hour clock, involves the DPO and legal, and ends with a draft notification and a breach register entry.
- Train and audit. Role-based training for engineers, support staff and administrators; an annual internal audit against the chosen framework, with findings tracked by the steering committee.
- Review annually and whenever laws, processing or organisation change, which PM-18 also expects of the programme plan.
Breach response: the 72-hour clock
- Regulator notification: Article 33(1) requires notification without undue delay and, where feasible, within 72 hours of becoming aware, unless the breach is unlikely to result in risk to individuals. Late notification must explain the delay, and information may be provided in phases (Article 33(4)).
- Processors: must notify the controller without undue delay (Article 33(2)); write a specific hour target into contracts so the controller's clock is not consumed by the supplier.
- Individuals: Article 34 requires telling affected people when the risk is high, unless the data was rendered unintelligible, for example by encryption, or later measures removed the high risk. Strong encryption with separately held keys directly reduces notification exposure.
- Record everything: Article 33(5) requires documenting every breach, including those not notified, with facts, effects and remedial action.
- New actors: AI agents with access to personal data create a new breach path, as the Spanish AEPD AI agent data breach notification shows. Include agents in the record of processing and in incident runbooks.
Detection, audit and measurement
Article 39(1)(b) gives the DPO the task of monitoring compliance, including training and audits. Security supplies the telemetry: data loss prevention alerts on personal data categories, anomalous bulk access to customer records, access by accounts outside the approved role set, and failures of deletion jobs. Feed these to both the SOC and the privacy office.
| Metric | What it shows |
|---|---|
| Share of processing activities in the record with a named owner and a current security measures description | Whether the map is maintained |
| Share of high-risk changes with a completed DPIA before go-live | Whether privacy by design is real |
| Median time from incident detection to a documented notify or do-not-notify decision | Readiness for the 72-hour requirement |
| Share of processors with Article 28 terms and a security assessment in date | Supplier assurance coverage |
| Retention jobs completed on schedule, and records past retention found in scans | Storage limitation in practice |
| Privileged and service accounts with access to special category data, and share reviewed this quarter | Access exposure |
Where identity fits
Most privacy failures security teams investigate are access failures: an account that could read more than it needed, a credential that was stolen, or an integration that copied data elsewhere. Service accounts, API keys and AI agents that touch personal data should appear in the record of processing as recipients or processors of that data, with owners, scopes and review dates like any human. See the Identity Data Privacy and Consent Guide and the NHI Ownership Guide.
Framework mapping
| Programme element | GDPR | NIST CSF 2.0 | ISO/IEC 27001:2022 Annex A | CIS Controls v8.1 |
|---|---|---|---|---|
| Legal and regulatory requirements | Art. 5(2) | GV.OC-03 | 5.31, 5.34 | 3.1 |
| Roles and responsibilities | Art. 37 to 39 | GV.RR-02 | 5.2 | None direct |
| Data inventory and records | Art. 30 | ID.AM-07 | 5.9, 5.12 | 3.2, 3.7, 3.8 |
| Data protection | Art. 25, 32 | PR.DS-01, PR.DS-02 | 8.11, 8.24 | 3.10, 3.11 |
| Supplier assurance | Art. 28 | GV.SC-05 | 5.19, 5.20 | 15.4 |
| Breach notification | Art. 33, 34 | RS.CO-02, RS.CO-03 | 5.24, 5.26 | 17.2 |
| Retention and deletion | Art. 5(1)(e) | PR.DS-01 | 8.10 | 3.4, 3.5 |
Common failure patterns
- Treating customer account security as a product issue, not a privacy one. Credential stuffing against accounts without strong authentication exposed genetic data in the 23andMe breach; special category data deserves DPIA-level controls on the login page.
- Remote access without MFA to systems holding sensitive data. A single Citrix login without MFA led to the Change Healthcare breach. See the MFA Guide.
- Help desks as an uncontrolled data path. Social engineering of support staff exposed member data in the Co-op attack. Verification steps are a privacy control.
- A record of processing written once and never updated. New SaaS tools, analytics exports and AI integrations appear without anyone updating the record, so DPIAs and breach scoping start from a wrong map.
- Running the 72-hour clock from the wrong moment. Teams that wait for forensic certainty before involving the DPO lose the window; the clock runs from awareness, and phased notification exists for this reason.
- DPO conflicted or under-resourced. Giving the role to someone who decides processing, or to someone with no access to systems and data, breaks Article 38.
Practitioner checklist
- Agree a written RACI between privacy, legal and security, and name a security counterpart for the DPO.
- Confirm the DPO reports to the highest management level and holds no role deciding processing.
- Reconcile the record of processing with technical discovery of data stores and SaaS at least annually.
- Add a DPIA screening question to change, architecture review and procurement workflows.
- Maintain a security measures description for every system in the record, as Article 30(1)(g) expects.
- Rehearse a breach that starts the 72-hour clock, and keep a register of all breaches, notified or not.
- Check California, Virginia, Colorado and every other state where you operate for assessment and audit duties and deadlines.
- Choose one framework (NIST Privacy Framework or ISO/IEC 27701) and map it to your existing security framework.
- Include service accounts, API keys and AI agents with access to personal data in access reviews and the record of processing.
Standards and references
- EUR-Lex: Regulation (EU) 2016/679, General Data Protection Regulation
- NIST: Privacy Framework, A Tool for Improving Privacy through Enterprise Risk Management, Version 1.0
- ISO: ISO/IEC 27701:2025, Privacy information management systems, Requirements and guidance
- NIST: SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations
- California Privacy Protection Agency: California Finalizes Regulations to Strengthen Consumers' Privacy
- Code of Virginia: § 59.1-580, Data protection assessments
- Colorado Attorney General: Colorado Privacy Act
- ICO: Data protection officers
Related NHI Mgmt Group resources: Identity Data Privacy and Consent Guide · Identity Security Regulatory Map · Identity Security Programme Guide · Identity Security Metrics Guide. This guide summarises GDPR, selected US state privacy laws and privacy frameworks for security teams and is not legal advice.