Data Privacy vs Data Security: overlapping duties, different questions

An organisation can encrypt every record, pass every penetration test and still break the law on privacy, and it can have a spotless lawful basis for every processing activity and still lose the data to an attacker. Data security asks whether information is protected from unauthorised access, loss and alteration. Data privacy asks whether the organisation should hold and use that personal data at all, for what purpose, for how long and with whose knowledge. The two share controls and overlap in GDPR Article 32, but they have different objectives, owners, laws and failure cases. This guide sets out where they diverge, gives two failure archetypes with real enforcement examples, and offers a RACI between the Data Protection Officer and the CISO. It is for CISOs, DPOs, privacy counsel and executives deciding how to organise both.

Key takeaways

• Security protects data; privacy governs its use. Security is judged by confidentiality, integrity and availability; privacy by lawfulness, fairness, transparency, purpose limitation, minimisation, accuracy and storage limitation.
• The overlap is real but partial. NIST's Privacy Framework shows cybersecurity-related privacy events as the overlap of two risk circles and states that privacy risks can also arise by means unrelated to cybersecurity incidents.
• Secure but unlawful is a common failure. Meta Ireland was fined EUR 1.2 billion for transfers that breached GDPR Article 46(1), a privacy failure that encryption did not cure.
• Lawful but breached is the other. 23andMe had a business purpose for genetic data and still lost data on millions of people through weak authentication controls.
• Separate ownership, shared evidence. The DPO advises and monitors, the CISO runs protective controls, and both rely on the same data inventory, access logs and incident records.

The short answer

Data security is a necessary condition for data privacy, never a sufficient one. Security answers "can anyone who should not see this data see it, change it or destroy it?" Privacy answers "should we be collecting this, using it this way, keeping it this long and sharing it with this party, and have we told people?" A security team can be excellent and the organisation still fail on privacy, because privacy failures often come from authorised people using data in ways the law or the individual did not permit. Run them as two disciplines with distinct accountabilities that share a data inventory, a risk register and an incident process.

Side by side

Where the law joins them: Article 32 and its neighbours

GDPR makes security one of its principles. Article 5(1)(f), integrity and confidentiality, requires processing "in a manner that ensures appropriate security of the personal data", including protection against unauthorised or unlawful processing and against accidental loss, destruction or damage. Article 32 turns that into an obligation on both controllers and processors to implement measures "to ensure a level of security appropriate to the risk", listing pseudonymisation and encryption, ongoing confidentiality, integrity, availability and resilience of systems, timely restoration after an incident, and regular testing of the measures' effectiveness. Article 32(2) frames the risk in terms of accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data.

Three points matter for the comparison:

• Risk is measured to the person, not the company. Article 32 weighs risk to the rights and freedoms of natural persons. A security risk register scored only on business impact will under-rate exposures such as health or location data that cost the firm little but harm individuals greatly.
• Security has a privacy purpose clause. Article 5(1)(f) covers "unauthorised or unlawful processing". An insider browsing customer records with valid credentials is a security event and a privacy event at once.
• Privacy reaches design choices security does not. Article 25 requires data protection by design and by default: measures designed to implement principles such as data minimisation, and defaults under which only data necessary for each specific purpose is processed. That is a product decision, not a firewall rule. See the Privacy by Design Guide for Engineering Teams.

The ICO makes the same point from the other side: information security is often equated with cyber security, but it also covers physical and organisational measures, and Cyber Essentials is a baseline set of controls rather than a complete answer. For the full Article 32 treatment see the GDPR Compliance Guide for Security Teams.

Different objectives, different risk models

NIST's Privacy Framework (version 1.0, January 2020) is the clearest statement of the relationship. It shows cybersecurity risk and privacy risk as two overlapping circles. The overlap, labelled cybersecurity-related privacy events, comes from loss of confidentiality, integrity or availability. Outside the overlap sit privacy events that arise from data processing itself: NIST's example is a smart meter that operates as intended, yet whose data processing could lead people to feel surveilled. No control failed and no attacker was involved.

That has practical consequences for how each team assesses risk:

The treatments column is telling. The strongest privacy control is often not to have the data, which is also excellent security. The Data Minimisation guide covers how to make that operational.

Failure case one: secure but unlawful

In May 2023 the Irish Data Protection Commission announced a EUR 1.2 billion fine against Meta Platforms Ireland for transferring personal data of Facebook users from the EU and EEA to the United States in breach of GDPR Article 46(1). The DPC found that the updated Standard Contractual Clauses and supplementary measures did not address the risks the Court of Justice had identified in Schrems II. It ordered Meta to suspend future transfers within five months and to cease the unlawful processing, including storage in the US, within six months.

The lesson for security leaders is that encryption, access control and certifications were not the question. The issue was legal exposure of the data to a third country's authorities, judged against transfer rules. Other common secure-but-unlawful patterns:

• No lawful basis: a well-protected analytics warehouse built on data collected for another purpose, with no compatibility assessment.
• Over-retention: encrypted backups that keep customer records years past the retention schedule, breaching storage limitation and enlarging any future breach.
• Function creep: security telemetry, such as DLP or user behaviour analytics, repurposed for performance management without notice or assessment.
• Opaque profiling: a model trained on customer data in a secure enclave, used for decisions people were never told about.
• Unanswered rights requests: data so locked down and fragmented that the organisation cannot find it to answer an access or erasure request within the deadline.

Failure case two: lawful but breached

23andMe had an obvious, disclosed purpose for genetic data. Between April and October 2023 an attacker used credentials leaked from other services to access more than 18,000 accounts, and the DNA Relatives feature let them collect profile data on nearly 7 million people. In June 2025 the UK Information Commissioner's Office fined the company GBP 2.31 million for failing to protect UK customers' genetic data; regulators found low MFA adoption, an eight-character password minimum and warning signs that went unaddressed. See the 23andMe breach analysis.

The case also shows the overlap working in both directions. The breach was a security failure (credential stuffing, no mandatory MFA) amplified by a privacy design choice (a feature that exposed data about relatives who never logged in). A DPIA that asked what an account takeover would expose about third parties might have changed the default. That is why privacy and security reviews of the same feature should be run together, not in sequence.

In GDPR terms the two failure types also attract different fine tiers: infringements of Article 32 fall under Article 83(4), up to EUR 10 million or 2 percent of worldwide annual turnover, while infringements of the basic principles in Article 5 and lawful basis in Article 6 fall under Article 83(5), up to EUR 20 million or 4 percent.

Where identity fits

Identity is where the two disciplines meet most often. Access control is a security control, and "who may access which personal data for which purpose" is a privacy question. Purpose-based access (support staff can see a customer's order history only while handling that customer's ticket) is privacy by design implemented through authorisation. Non-human identities matter too: service accounts, API keys and AI agents with broad read access to personal data stores create both breach risk and purpose-limitation risk, because nobody has stated what each machine identity is allowed to do with the data. Record the purpose of every service account that touches personal data in the record of processing, and review machine access with the same rigour as human access. See the Data Mapping and ROPA Guide.

Ownership model: a RACI between DPO and CISO

The DPO's tasks under GDPR Article 39 are to inform and advise, monitor compliance, advise on DPIAs and cooperate with the supervisory authority. The DPO must not be put in a position where they decide the purposes and means of processing, which is why a DPO who also runs security operations raises conflict of interest questions. The DPO vs CPO guide covers the legal test. The RACI below assumes a separate privacy lead (CPO or head of privacy) with operational responsibility, a DPO in an advisory and monitoring role, and a CISO. R = responsible, A = accountable, C = consulted, I = informed.

Adjust by size. A small organisation may have one privacy professional who also acts as DPO and a part-time security lead; keep the decision on purposes with the business owner so that neither specialist is marking their own homework. A large group may have privacy and security reporting to different executives; the shared artefacts below are what keep them aligned. The Privacy Programme Guide for Security Teams covers programme structure.

Decision guidance

• Should privacy sit under the CISO? It can work operationally, especially in smaller firms, but the DPO role must stay independent and the privacy agenda will drift towards controls unless someone owns purpose, transparency and rights. Large organisations usually place privacy under legal or a CPO with a dotted line to security.
• Which framework? Use one control catalogue for both where possible. NIST SP 800-53 Rev 5 integrates privacy controls (the PT family alongside security families). ISO/IEC 27701:2025, published October 2025, is now a standalone privacy information management system standard that no longer requires ISO/IEC 27001, which suits organisations that want a certifiable privacy system.
• When security must yield to privacy: monitoring that is effective but disproportionate, such as full content inspection of staff personal messages or indefinite retention of logs containing personal data. Run a DPIA and minimise.
• When privacy must yield to security: retention of security logs long enough to investigate incidents is a legitimate purpose; document it, set a period and protect the logs.
• Breach notification: security determines facts and scope; privacy decides whether the breach is unlikely to result in a risk to individuals, which under GDPR Article 33 is the test for not notifying, and records every breach either way. See the Data Breach Notification Checklist.

Worked scenario: a customer support AI assistant

A retailer wants an AI assistant to summarise support tickets, drawing on order history and past chats.

1. Security review asks: where are prompts and outputs stored, who can access them, is the model provider's endpoint authenticated with a workload identity, are chats encrypted, and is the vector store segmented by tenant?
2. Privacy review asks: is summarising chats compatible with the purpose customers were told, does the assistant need full order history or only the last 90 days, will chats be used to train models, where is the provider located and is there a transfer mechanism, how long are summaries kept, and can a customer's data be found and erased across the vector store?
3. Joint decisions: limit retrieval to the current customer and recent orders (minimisation that also cuts breach scope), disable provider training on customer data, set a retention period for transcripts, log access to summaries, and add the assistant's service identity to the record of processing with its purpose.
4. Outcome: neither review alone would have caught everything. Security alone would have approved an encrypted, well-authenticated system that kept every chat forever; privacy alone would have approved a minimal design with a static API key in a configuration file.

Detection and measurement

• Privacy metric: percentage of processing activities in the record of processing with a documented lawful basis and retention period.
• Privacy metric: data subject requests completed within the statutory deadline.
• Shared metric: volume of personal data held past its retention date, measured by automated discovery.
• Security metric: percentage of personal data stores with access logging enabled and reviewed, and identities with standing access to them.
• Shared metric: new systems or features that went live with both a DPIA screening and a security review completed.
• Signals to monitor: bulk reads of personal data by any identity, access outside the stated purpose (support staff viewing accounts with no open ticket), new data flows to third countries, and new machine identities granted access to personal data stores.

Framework mapping

Common failure patterns

• Equating privacy with security: treating an ISO/IEC 27001 certificate or a clean penetration test as evidence of GDPR compliance, while lawful basis, transparency and retention are never assessed.
• Risk scored only to the business: security registers that rate a location or health data store as low impact because a leak would cost little in direct losses.
• Security tooling as surveillance: DLP, insider risk and productivity monitoring rolled out without a DPIA or staff notice, creating a privacy complaint from a security control.
• Retention ignored by both: privacy sets schedules that security never implements in backups, logs and data lakes, so the breach that eventually happens exposes years of data that should not exist.
• Sequential reviews: privacy signs off a feature before security sees it, or the reverse, so design choices that amplify breach impact on third parties, as in the 23andMe case, are missed.
• Notification decided by one side: security closes an incident as contained without the privacy risk assessment that Article 33 requires to be documented.

Practitioner checklist

• Agree written definitions: privacy covers lawful, fair and transparent use; security covers protection of all data.
• Maintain one data inventory and record of processing used by both teams.
• Score personal data risks by harm to individuals as well as to the business.
• Run DPIA screening and security review together for every new system or feature that touches personal data.
• Publish a DPO, privacy lead and CISO RACI and keep purpose decisions with the business owner.
• Implement retention schedules technically in backups, logs and analytics platforms, and measure overdue data.
• Record the purpose of every machine identity that accesses personal data and review its access.
• Run joint breach exercises that include the notification risk assessment, not just containment.

Standards and references

• GDPR: Article 5 Principles relating to processing of personal data
• GDPR: Article 32 Security of processing
• GDPR: Article 25 Data protection by design and by default
• GDPR: Article 33 Notification of a personal data breach to the supervisory authority
• NIST: Privacy Framework Version 1.0
• ICO: A guide to data security
• ISO: ISO/IEC 27701 Privacy information management systems
• Data Protection Commission: Conclusion of inquiry into Meta Ireland

Related NHI Mgmt Group resources: Compliance vs Security, Data Security Guide, DPIA Guide: Running a Data Protection Impact Assessment, Special Category Data Guide. This guide summarises GDPR obligations and enforcement examples and is not legal advice.