How should organisations separate data security controls from data privacy controls?

Why This Matters for Security Teams

Separating data security from data privacy prevents teams from using the wrong control for the wrong problem. Security is about reducing unauthorised access, misuse, and exfiltration. Privacy is about lawful collection, purpose limitation, retention, and deletion. When these functions are blended, organisations often over-index on perimeter controls while missing whether data should have been collected or retained at all. That gap shows up in audit findings, incident response, and policy exceptions.

The distinction is especially important for systems that process personal data at scale, where encryption or MFA can still coexist with poor retention, weak purpose controls, or excessive sharing. Guidance from the NIST Cybersecurity Framework 2.0 reinforces that governance and protection are related but not interchangeable. NHIMG research also shows how control gaps persist in practice: the Ultimate Guide to NHIs reports that 79% of organisations have experienced secrets leaks, 77% of which caused tangible damage. In practice, many security teams encounter privacy failures only after a data request, retention review, or breach review has already exposed the gap.

How It Works in Practice

A practical split starts with ownership. Security teams define and operate controls that protect data from unauthorised access and disclosure. Privacy teams define the rules for why data exists, what it may be used for, where it may move, and how long it may remain in systems. Those functions must work together, but they should not be collapsed into one policy set.

Security controls usually include MFA, encryption, key management, logging, segmentation, DLP, and access review. Privacy controls usually include data classification, lawful basis review, consent where applicable, purpose limitation, retention schedules, deletion workflows, and processor agreements. The best way to operationalise the difference is to map each dataset to both control families:

• Security asks: who can access it, from where, and under what authentication?
• Privacy asks: should it be collected, processed, shared, or retained at all?
• Security asks: how do we detect exposure or misuse?
• Privacy asks: what is the permitted business purpose and deletion trigger?

That mapping is especially important for secrets and non-human identities, where access can be technically secure but still privacy-invasive if the underlying data use is overbroad. NHIMG’s IOS app secrets leakage report illustrates how leaked credentials can directly endanger user privacy, even when the original issue looks like a security defect. NIST’s framework supports this layered approach by treating governance, protection, detection, and recovery as distinct operational functions. These controls tend to break down when one team owns both policy and enforcement in highly regulated environments, because exceptions accumulate faster than review processes can catch them.

Common Variations and Edge Cases

Tighter privacy control often increases process overhead, requiring organisations to balance business agility against compliance risk. That tradeoff becomes sharper in analytics, AI training, and cross-border processing, where data that is secure may still be inappropriate to use. Current guidance suggests treating privacy as a decision framework rather than a technical hardening exercise, but there is no universal standard for exactly how much detail belongs in policy versus implementation.

One common edge case is pseudonymised or tokenised data. Security may consider it lower risk, while privacy may still treat it as personal data if re-identification remains possible. Another is backups and archives, where security teams often preserve integrity and availability, but privacy teams must still enforce retention and deletion requirements. A third is vendor sharing: access can be tightly controlled, yet privacy obligations still require purpose limits, subprocessor oversight, and contract terms.

For organisations maturing governance, the practical rule is simple: security controls should prove the data is protected, while privacy controls should prove the data is justified. The Ultimate Guide to NHIs — Standards is useful here because it highlights how identity and access controls support enforcement, but they do not replace policy decisions about data use. The two control sets must be aligned, not merged.

Related resources from NHI Mgmt Group

• How should security teams handle privacy rights requests when customer data is spread across multiple systems?
• How should organisations balance security with employee productivity in identity controls?
• How do organisations decide where AI data security controls should sit?
• How should organisations build a data inventory that supports privacy and security governance?