How can organisations tell whether data protection is actually working?

Why This Matters for Security Teams

Data protection only counts when it changes exposure, not when it simply adds another control layer. Security teams often measure coverage, policy count, or encryption adoption, yet those indicators can miss whether privileged paths still reach sensitive data in ways that are easy to abuse. The real test is whether access is narrowed to the task, reviewed at the right time, and prevented from expanding into bulk movement or administrative reach.

This is especially important in NHI-heavy environments, where service accounts, API keys, and automations often accumulate reach over time. NHI Management Group notes that 97% of NHIs carry excessive privileges, which means many organisations are defending data after overexposure has already occurred. The issue is not just leakage at rest, but whether the control plane keeps sensitive data away from identities that should never see it in the first place. That aligns with the outcome-based approach in the NIST Cybersecurity Framework 2.0, which pushes organisations to prove that risk is being reduced, not merely documented. In practice, many security teams discover the gap only after a privileged workflow touches data it was never meant to access.

How It Works in Practice

To tell whether data protection is working, organisations should look for evidence that access, movement, and use are becoming more constrained over time. That means tracking whether sensitive datasets are only reachable through approved paths, whether privileged identities are granted just enough access for the task, and whether exceptions are shrinking instead of spreading. Current guidance suggests focusing on control effectiveness rather than control presence.

Practical checks usually combine identity, data, and operational signals:

• Review whether sensitive data is reachable only through approved roles, workflows, or brokers.
• Measure the percentage of privileged identities with access that matches current task requirements.
• Check whether bulk exports, admin queries, and cross-environment transfers are being flagged or blocked.
• Validate that encryption, tokenisation, and masking are actually reducing who can read usable data, not just who can store it.
• Confirm that alerts lead to faster containment, cleaner revocation, and fewer lingering access paths.

For NHI governance, these checks should include service accounts and machine credentials as first-class identities. NHI Management Group’s research shows that only 5.7% of organisations have full visibility into their service accounts, and that visibility gap makes it hard to prove whether protection is working at all. The Schneider Electric credentials breach is a useful reminder that exposed credentials and broad access often turn a local weakness into a larger data exposure event. In parallel, teams should map their approach to the NIST Cybersecurity Framework 2.0 by checking whether protect and detect functions are measurably reducing sensitive-data reach.

These controls tend to break down in mixed human and machine environments where legacy integrations, shared secrets, and unmanaged admin paths make it difficult to attribute access to a specific task or identity.

Common Variations and Edge Cases

Tighter data controls often increase operational friction, requiring organisations to balance reduced exposure against workflow speed and support overhead. That tradeoff is real, especially where reporting teams, automation jobs, and third-party integrations need repeated access to the same datasets.

Best practice is evolving on how to judge effectiveness in those cases. Some organisations rely on policy exceptions, while others use time-bound access, scoped tokens, or proxy-based controls that preserve business continuity without granting standing reach. There is no universal standard for this yet, but the direction is clear: if a control can only be shown on paper, it is not proving real protection.

A useful edge case is when a programme appears strong because data is encrypted, but privileged identities still decrypt, query, or export it without meaningful limits. Another is when masking is used in analytics, but admin accounts can bypass it entirely. In both cases, the question is whether the control changes what an identity can actually do at runtime. The Ultimate Guide to NHIs highlights why this matters: excessive privilege is common, so even well-intentioned programmes can leave sensitive data broadly reachable unless they continuously tighten access paths.

Related resources from NHI Mgmt Group

• How can organisations tell whether governed data access is actually working?
• How can organisations tell whether their SBOM process is actually working?
• How do organisations know if data quality controls are actually working?
• How can organisations tell whether their Travel Rule controls are working?