Why do organisations struggle to keep sensitive data protected as it moves through modern applications?

Why This Matters for Security Teams

Sensitive data rarely stays in one place long enough for a single control to protect it. It is collected in one application, enriched in another, copied into analytics tools, synced to endpoints, and increasingly surfaced in AI-assisted workflows. That movement creates a control problem as much as a data problem: if classification, access rules, and logging do not follow the data, protection degrades at every hop. The issue is not simply encryption at rest, but whether controls remain effective during use, transfer, and sharing across systems.

This is why the NIST Cybersecurity Framework 2.0 is useful as a baseline. It treats protection as a lifecycle issue spanning governance, access control, monitoring, and response rather than a point solution. Security teams often underestimate how quickly business workflows create shadow copies, temporary exports, and API-based integrations that bypass original safeguards. When that happens, the organisation may still believe data is protected even though the operational path has already changed.

In practice, many security teams only discover these gaps after an export, sync, or AI prompt has already exposed the data outside the intended boundary.

How It Works in Practice

Protecting data in motion requires a layered approach that follows the data, not just the environment. Practitioners usually combine classification, access governance, encryption, monitoring, and DLP-style inspection, but the quality of those controls depends on whether metadata is preserved across systems. A document labelled sensitive in a file platform may lose that label when copied into email, pasted into chat, or ingested into an application workflow.

Strong programmes start by defining what qualifies as sensitive, then mapping how that data enters, moves through, and leaves core business systems. That mapping should include SaaS connectors, browser sessions, mobile endpoints, and AI interfaces that can receive prompts or documents. The operational goal is to keep decisions about handling and sharing attached to the record, not to the application that first received it.

• Use classification rules that are simple enough for users and automation to apply consistently.
• Apply least privilege and just-in-time access where data is high value or highly regulated.
• Enforce transfer controls on email, file sharing, API integrations, and endpoint copy paths.
• Log access, sharing, and export events so suspicious movement can be correlated later.
• Review AI and automation workflows separately, because they can create new copies or summaries of sensitive content.

NIST control guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls is especially relevant here because it ties access control, auditing, media protection, and system monitoring together. That matters when the same dataset appears in a database, a collaboration platform, a ticketing workflow, and an AI-assisted assistant. Teams also need to decide where policy enforcement lives: in the source system, in the identity layer, in the endpoint, or in the transfer channel. There is no universal standard for this yet, so current guidance suggests prioritising the points where data is most likely to be copied or transformed.

These controls tend to break down when business teams rely on ad hoc exports and unmanaged integrations because the data leaves the governed path before monitoring or classification can follow it.

Common Variations and Edge Cases

Tighter data controls often increase friction for legitimate work, requiring organisations to balance protection against user productivity and operational speed. That tradeoff is especially visible in collaboration-heavy environments, customer support operations, and AI-enabled knowledge workflows where staff need to move information quickly.

Best practice is evolving for generative AI and agentic workflows. Sensitive data may be exposed not only through direct sharing, but also through prompts, retrieved context, cached responses, or tool outputs. In those cases, protection depends on prompt hygiene, retrieval filtering, output review, and strict governance over what the model or agent is allowed to access. This is where identity and data governance intersect: if an AI agent has execution authority, then its access path must be treated like any other privileged path.

Edge cases also appear in cross-border operations and regulated sectors. Some organisations must retain content for legal or audit reasons while still limiting who can see it. Others need to preserve evidence for fraud, investigations, or incident response. Current guidance suggests using differentiated controls rather than one blanket policy: encrypt broadly, restrict access narrowly, and retain only what is necessary for the stated business or legal purpose. When systems are heavily customised or built around legacy file movement, those assumptions often fail because the control logic is fragmented across too many owners and tools.

Related resources from NHI Mgmt Group

• What should teams do when sensitive data moves through service accounts or automation?
• How should organisations govern personal data that moves through email, cloud apps, and AI tools?
• How can organisations govern sensitive data moving through AI and MCP-connected apps?
• When should organisations tighten access reviews for sensitive data?