How can organisations tell whether their data security programme is actually improving?

Why This Matters for Security Teams

Data security programmes often look healthy on paper because they report activity, not control. More scans, more policy exceptions reviewed, and more tickets closed do not automatically mean sensitive data is safer. The real question is whether the programme is reducing exposure, clarifying ownership, and shrinking the amount of data that can be found, copied, or misused.

That is why measurement has to focus on change over time. A useful benchmark is whether unknown stores are disappearing, sensitive datasets are being assigned owners, and access reviews are completing faster with fewer exceptions. NIST’s Cybersecurity Framework 2.0 treats governance and outcome tracking as core discipline, not optional reporting. For data-heavy environments, that same logic appears in NHIMG’s Ultimate Guide to NHIs, which shows how visibility gaps and excessive privileges persist when programmes measure activity instead of control.

One relevant signal from the NHIMG research is that only 5.7% of organisations have full visibility into their service accounts, which is a reminder that control gaps often hide inside identity and data sprawl rather than in obvious breaches. In practice, many security teams discover the programme was not improving only after the same high-risk data reappears in audits or incidents, rather than through intentional performance reviews.

How It Works in Practice

A mature data security programme should be measured as a closed loop: discover, classify, protect, review, and reduce. The key is to track whether each cycle produces lower residual risk, not just more findings. Current guidance suggests using a small set of operational metrics that connect directly to outcomes, such as the number of unknown data stores, the percentage of sensitive datasets with named owners, the percentage of systems with least-privilege access applied, and the time required to complete access reviews.

In practice, the most useful indicators are the ones that can be trended monthly and tied to remediation. For example, if discovery tools keep finding the same storage buckets, file shares, or analytics repositories, the programme is generating noise. If access reviews are faster but still approve broad access without challenge, the review process is procedural rather than protective. If exposure counts fall because datasets are retired, classified, or moved behind stronger controls, the programme is producing control gain.

• Track visibility and overexposure signals alongside ownership and remediation completion.
• Measure how many sensitive datasets have explicit business owners and technical custodians.
• Count high-risk findings that recur across audits, because repeat findings often show weak governance.
• Use the NIST Cybersecurity Framework 2.0 to align measurements with governance, protection, detection, and recovery outcomes.

For identity-heavy data environments, the NHIMG research is especially useful because data exposure is often amplified by service accounts, API keys, and other NHIs that can move data at scale without human oversight. These controls tend to break down when data ownership is unclear and access paths are embedded in automation, because the same hidden identities keep reintroducing exposure after each review cycle.

Common Variations and Edge Cases

Tighter measurement often increases administrative overhead, requiring organisations to balance better visibility against reporting fatigue and tool complexity. That tradeoff matters because not every environment can use the same success metrics. A cloud-first programme may focus on policy drift and shadow data stores, while a regulated enterprise may prioritise access review completion, encryption coverage, and retention enforcement. Best practice is evolving, and there is no universal standard for the exact metric set yet.

Some programmes also look improved when only the easiest assets are being remediated. That creates a false signal if high-risk repositories, third-party shares, or machine-generated datasets are left untouched. Another common edge case is when lower incident volume reflects weaker detection, not stronger control. For that reason, current guidance suggests pairing leading indicators, such as ownership coverage and remediation speed, with lagging indicators, such as repeated findings and exposure-related incidents.

Where NHIs are heavily involved, data security metrics should include the identity layer too, because service accounts and automation often carry the permissions that move sensitive data. The best available research shows the problem is not just quantity of data, but the persistence of excessive privilege and poor visibility across connected systems. In practice, the programme is improving only when repeat findings shrink, ownership becomes unambiguous, and the same sensitive data stops resurfacing in the next quarter’s audit.

Related resources from NHI Mgmt Group

• How can teams tell whether DSPM is actually improving security?
• How can organisations tell whether their AI security model is actually working?
• How do organisations know whether passwordless access is actually improving security?
• How can security leaders tell if their identity programme is over-focused on tooling?