Why do traditional security models struggle to protect modern data environments?

Why Traditional Security Models Struggle with Data Anywhere

Traditional security models were built around fixed perimeters, trusted networks, and explicit ownership boundaries. Modern data environments break those assumptions. Data now moves through SaaS apps, cloud storage, collaboration platforms, analytics pipelines, and automated workflows that create new copies and exposures faster than perimeter tools can inspect them. That leaves security teams reacting to where data is stored instead of how it is used, shared, or reshaped.

This is why data-centric controls matter. The NIST Cybersecurity Framework 2.0 emphasizes risk management across the full lifecycle, not just the network edge. NHIMG research shows the scale of the challenge: 79% of organisations have experienced secrets leaks, and 97% of NHIs carry excessive privileges, which means the problem is often compounded by identities that can reach far more data than they should. The issue is not simply where the data sits, but who and what can access it in motion.

Security teams often discover this only after a collaboration link, API token, or over-permissioned service account has already expanded access beyond the original boundary, rather than through deliberate design of the data control plane.

How Data-Centric Security Works in Practice

Data-centric security treats the asset itself as the control point. Instead of assuming that anything inside the network is trustworthy, policy follows the record, file, object, or dataset wherever it goes. That means pairing classification with enforcement, so sensitive data is tagged, monitored, and protected based on context such as user role, device posture, location, business purpose, and sharing intent.

In mature implementations, teams combine several layers. They use classification and discovery to locate sensitive data, encryption and tokenisation to reduce exposure, rights management to limit reuse, and policy engines to decide access at request time. For modern environments, this also requires controlling non-human identities because automation often touches data more than humans do. NHIMG’s Ultimate Guide to NHIs — Key Research and Survey Results notes that 96% of organisations store secrets outside secrets managers in vulnerable locations, which makes data protection inseparable from identity hygiene.

• Classify data by sensitivity, business impact, and regulatory scope.
• Bind access decisions to context, not just static roles or network location.
• Reduce exposure with short-lived credentials, tokenisation, and encryption.
• Monitor sharing, exfiltration, and abnormal access patterns across SaaS and cloud.
• Revoke or rotate credentials when a dataset, workflow, or integration changes.

The most effective programmes align this model with NIST Cybersecurity Framework 2.0 functions so that identification, protection, detection, response, and recovery all operate on the data layer. These controls tend to break down when organisations cannot inventory shadow SaaS, because policy cannot protect data that is invisible to discovery.

Common Failure Points and Where the Model Breaks Down

Tighter data controls often increase operational overhead, requiring organisations to balance visibility and enforcement against user friction and administrative burden. That tradeoff becomes sharper in highly distributed environments where data is constantly re-created, exported, and embedded into downstream tools. Best practice is evolving, and there is no universal standard for every workflow yet, especially when organisations mix legacy systems with modern cloud services.

One common failure point is over-reliance on static labels. If classification is incomplete or stale, the policy engine may under-protect sensitive data or block legitimate work. Another is weak identity governance for service accounts and integrations. NHIMG research shows only 5.7% of organisations have full visibility into their service accounts, which means many “data security” gaps are actually identity gaps. The Schneider Electric credentials breach illustrates how credential exposure can cascade into broader data access problems when access is not tightly scoped and monitored.

For these reasons, current guidance suggests treating data protection, identity control, and secrets governance as one programme rather than separate domains. The model breaks down most often in environments with unmanaged third-party integrations, persistent shared folders, and automation that can copy data faster than policy can be updated.

Related resources from NHI Mgmt Group

• Why do operational documents create more security risk than traditional regulated data in modern environments?
• Why do modern security programs struggle with traditional monitoring tools in cloud-native environments?
• Why do traditional enterprise security stacks often struggle with modern application-centric environments?
• Why do traditional security controls fail to protect modern SaaS environments?