TL;DR: Data security and data privacy overlap, but they solve different problems: security protects data from unauthorized access and misuse, while privacy governs lawful collection, use, retention, and disclosure, according to Zluri. The practical lesson is that access control, consent, retention, and review must be governed as distinct control planes, not blended into one.
NHIMG editorial — based on content published by Zluri: Security & Compliance Data Security vs Data Privacy: 4 Key Differences
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security.
Questions worth separating out
Q: How should organisations separate data security controls from data privacy controls?
A: Organisations should treat data security as the enforcement layer and data privacy as the governance layer.
Q: Why do access controls alone not satisfy data privacy requirements?
A: Access controls only determine who can reach a system or dataset.
Q: How can security teams tell whether access governance is working?
A: Access governance is working when entitlements consistently match business purpose, data sensitivity, and retention obligations.
Practitioner guidance
- Separate privacy policy from security enforcement Assign explicit owners for lawful processing decisions, then map the enforcement controls that make those decisions operational across apps, databases, and SaaS systems.
- Tie access reviews to data purpose and retention Require reviewers to confirm not only whether access is needed, but whether the underlying data should still exist and whether the processing purpose is still valid.
- Treat service accounts as privacy-relevant subjects Inventory non-human identities that can read or export personal data, then include them in review, deprovisioning, and exception workflows rather than excluding them as infrastructure.
What's in the full article
Zluri's full article covers the operational detail this post intentionally leaves for the source:
- Specific examples of access management controls such as RBAC, just-in-time access, least privilege, and segregation of duties in a SaaS environment.
- Practical guidance on continuous monitoring of access rights and deprovisioning workflows when access gaps appear.
- Examples of compliance alignment with GDPR, HIPAA, and ISO/IEC 27001 in the context of data handling.
- The vendor’s own positioning on how its access management workflow supports security and privacy outcomes.
👉 Read Zluri's analysis of data security vs data privacy →
Data security vs data privacy: where IAM controls actually split?
Explore further
Data security and data privacy are separate control problems, not interchangeable labels. Security protects information from unauthorized access and misuse. Privacy governs whether personal data may be collected, used, and retained at all. Organisations that collapse the two usually overinvest in technical controls while leaving purpose, retention, and consent decisions under-governed. The practitioner implication is clear: one set of controls enforces access, the other defines legitimacy.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
A question worth separating out:
Q: Who should be accountable for aligning privacy and security controls?
A: Accountability should sit with a joint governance model, but one owner must be responsible for making the controls line up in practice. Security teams typically enforce access and monitoring, while privacy leads define lawful processing and retention. The gap appears when neither side owns the handoff.
👉 Read our full editorial: Data security vs data privacy: what IAM teams need to separate