What is the difference between data security and data privacy?

How security and privacy split the work on data

Security and privacy are related, but they solve different problems. Data security is about preventing unauthorised access, misuse, alteration, loss, or exfiltration. Data privacy is about whether a person or organisation should be allowed to collect, use, retain, disclose, or transfer data in the first place, and for what purpose. The two overlap most when the data is personal, sensitive, or regulated.

That means the same dataset can be secure but still privacy-problematic if it is collected without a lawful basis, retained too long, or shared too broadly. It can also be privacy-compliant on paper yet insecure in practice if access controls, logging, or encryption are weak. A useful way to think about it is that security protects the asset, while privacy governs the legitimacy of its use.

For a broader operating model, NHIMG’s Data Security Guide is the right starting point when the question is about exposure, classification, access governance, and protection controls.

Where the distinction matters in practice

The difference becomes most visible in day-to-day decisions. A security team may ask who can read a file, whether the storage is encrypted, and whether anomalous access is detected. A privacy team may ask whether the file should exist, whether the collection notice matches the actual use, whether the retention period is justified, and whether sharing with a third party is permitted.

Those questions are not duplicates. Security can be implemented for data that should never have been collected, and privacy obligations can still apply even if the environment is technically well defended. In mature programmes, privacy requirements often drive collection minimisation, purpose limitation, retention rules, and disclosure controls, while security provides the technical enforcement for those decisions.

Legal and regulatory obligations often make the boundary concrete. The EU General Data Protection Regulation (GDPR) ties privacy principles to security of processing, data protection by design, and impact assessment, which is why teams usually need both governance and technical controls.

When personal data is the subject, NHIMG’s Privacy Programme Guide for Security Teams helps connect policy, roles, assessments, and operational security work into one programme.

How to tell whether you have a security issue, a privacy issue, or both

Start by asking what has failed. If the failure is unauthorised access, missing encryption, weak authentication, excessive permissions, or data theft, the primary issue is security. If the failure is unlawful collection, over-retention, uncontrolled sharing, secondary use beyond the stated purpose, or weak rights handling, the primary issue is privacy. In many incidents, both are present because bad governance and weak controls reinforce one another.

This is especially true where organisations manage identity data, customer records, health information, or analytics datasets. Privacy questions often determine what is allowed, while security questions determine how that allowed data is protected. If you only answer one side, you usually miss part of the operational risk.

NHIMG’s Identity Data Privacy and Consent Guide is useful when access, consent, retention, and data subject rights intersect in identity-centric systems.

For cloud and shared-platform environments, the CSA Cloud Controls Matrix is a practical way to map security and privacy responsibilities across cloud domains without conflating the two.

Risk and Threat Considerations

Confusing data security with data privacy creates two distinct failure modes. One is technical exposure, where data is accessed, altered, or stolen. The other is governance exposure, where data is collected or used in ways that exceed the stated purpose, consent, or legal basis. Either can lead to regulatory action, contractual breach, customer harm, or loss of trust.

Failure mechanism: Weak access control, poor classification, over-permissioned systems, or missing monitoring create security exposure; weak policy, unclear purpose limitation, or excessive retention create privacy exposure.

Impact: The organisation may suffer data leakage, unlawful processing, unnecessary retention, failed disclosure control, and a larger blast radius when an incident occurs.

Practitioner Guidance

What to verify: Confirm that your control set distinguishes protection of data from rules for permitted use. If the same team owns both, check that access reviews, retention rules, consent handling, and disclosure approvals are independently traceable.

Decision rule: If a control only keeps data safe, treat it as security. If a rule decides whether the data should be collected, retained, shared, or reused, treat it as privacy. If both apply, document both owners and both evidence sets.

Practitioner takeaway: The most common mistake is assuming a strong security posture automatically means good privacy, when in practice the two disciplines answer different questions and need different controls.

Related resources from NHI Mgmt Group

• Why do AI programs increase data privacy liability for security teams?
• How should organisations build a data inventory that supports privacy and security governance?
• How should security teams handle privacy rights requests when customer data is spread across multiple systems?
• How should organisations separate data security controls from data privacy controls?