Why do slow data breaches stay hidden for so long?

Why This Matters for Security Teams

Slow breaches are difficult to spot because they rarely look like a single event. Instead, they unfold through small, repeated actions that resemble ordinary administration, business analytics, or scheduled integration traffic. That makes them dangerous in environments where the security program treats login success as proof of safety and assumes data exfiltration must be noisy to matter. Guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it separates access control from audit and monitoring expectations, which is exactly the gap slow intrusions exploit.

What often gets missed is that long dwell time is not only an incident response problem. It is also a logging design problem, a data governance problem, and a detection engineering problem. If teams do not define what normal data movement looks like for each system, then bulk exports, unusual API reads, or repeated sync jobs can blend into routine noise for weeks or months. The same issue appears in emerging AI-enabled operations, where automated tooling can accelerate both legitimate workflows and attacker tradecraft, as noted in the Anthropic first AI-orchestrated cyber espionage campaign report.

In practice, many security teams encounter a slow breach only after a quiet data trail has already been normalised by the business.

How It Works in Practice

Slow breaches succeed because attackers minimise the signals that would trigger obvious alerts. They may use valid accounts, approved tooling, service integrations, or low-and-slow queries that stay below threshold-based detection. The objective is not speed; it is camouflage. That means defenders need telemetry that captures data context, not just identity context. The right question is not only who authenticated, but what they touched, how much they accessed, where the data went, and whether that pattern fits the user, workload, or service history.

Operationally, this usually requires combining identity, endpoint, network, and data-layer evidence. For example, an analyst should be able to correlate an unusual export with the user session that initiated it, the device used, the database objects queried, and the destination reached afterward. The ENISA Threat Landscape regularly highlights how persistence, stealth, and lateral movement overlap with data theft, which is why data-centric analytics should sit alongside traditional alerting.

• Baseline normal query volume, export size, API frequency, and time-of-day patterns for each sensitive system.
• Alert on destination changes, not only on volume, especially for cloud storage, unmanaged endpoints, and third-party tools.
• Track service accounts, automation identities, and delegated access separately from human users.
• Use audit logs that retain enough detail to reconstruct the sequence of reads, exports, and transfers.
• Correlate repeated low-risk actions into a campaign view rather than judging each event in isolation.

Detection should also account for legitimate operational noise, such as batch jobs, ETL pipelines, backups, and replication. Those workflows often create the same outward symptoms as theft, which means the security team needs strong allowlists, change management, and ownership metadata before it can trust anomaly scoring. These controls tend to break down when telemetry is fragmented across SaaS applications, cloud services, and legacy databases because no single platform sees enough of the chain to confirm suspicious movement.

Common Variations and Edge Cases

Tighter monitoring often increases operational overhead, requiring organisations to balance visibility against alert fatigue and privacy constraints. That tradeoff becomes sharper in highly regulated environments, shared-service platforms, and globally distributed teams, where data access patterns vary widely by region and function. There is no universal standard for anomaly thresholds yet, so current guidance suggests tuning by business context rather than chasing a single enterprise-wide baseline.

Some environments make slow breach detection harder by design. In SaaS-heavy organisations, much of the relevant evidence sits outside the core security stack. In engineering teams, automated CI/CD systems and machine identities can generate high-volume access that looks suspicious unless ownership and purpose are well documented. In analytics or research environments, broad query privileges are sometimes necessary, which means the control focus shifts from restricting every read to monitoring unusual extraction paths and off-hours use.

The strongest programs treat prolonged access as a data protection issue rather than a purely perimeter issue. That means reviewing who can read, export, replicate, and forward sensitive datasets, then making sure those permissions are paired with auditability and response playbooks. When that is missing, slow breaches become invisible because each step looks reasonable on its own, even though the full chain clearly is not.

Related resources from NHI Mgmt Group

• Why are supplier breaches so hard to contain once attackers stay hidden for months?
• What breaks when access approvals stay in ticket queues too long?
• Why do service accounts and automation create hidden data-access risk?
• What breaks when an app relies on a hidden token broker for external data access?