Why do organisations struggle to contain breaches quickly even when they have many security tools?

Why This Matters for Security Teams

Many organisations buy broad coverage but still lack a fast containment path, which means the problem is usually operational rather than tool-related. The delay often comes from alert overload, unclear ownership, and approvals that have to be chased while an incident is unfolding. Security teams also lose time when telemetry is fragmented across endpoint, identity, cloud, and SIEM workflows that do not hand off cleanly. Current guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls reinforces that control strength depends on implementation and response discipline, not just product count.

This matters because containment speed determines whether an intrusion remains local or becomes a business-wide event. When security teams cannot quickly revoke access, isolate a host, or block a malicious session, attackers gain time to harvest secrets, pivot across environments, and disable recovery options. In practice, many security teams encounter the true cost of slow containment only after adversaries have already used the delay to expand access, rather than through intentional readiness testing.

How It Works in Practice

Effective containment is less about adding another dashboard and more about designing response as a sequence of pre-approved actions. The organisations that move fastest usually define what gets contained first, who can approve it, and which actions can be automated without waiting for a human decision. That workflow should cover identity, endpoints, cloud workloads, and collaboration tools so the response does not stall when the attack crosses boundaries.

A practical containment model typically includes:

• Central triage that assigns severity and ownership as soon as an alert crosses a threshold.
• Automated isolation for known-bad hosts, risky user sessions, and compromised service accounts.
• Access revocation or step-up verification when identity compromise is suspected.
• SOAR playbooks that preserve evidence while executing repeatable actions.
• Escalation rules that define when humans must override automation.

This is especially important in identity-heavy environments, where a stolen credential may be more dangerous than malware on a single endpoint. If the attacker can use a valid account, containment needs to include session termination, token invalidation, and privileged access review, not only device quarantine. MITRE ATT&CK is useful here because it maps common post-compromise techniques such as valid account abuse and lateral movement to practical defensive checks. The recent Anthropic — first AI-orchestrated cyber espionage campaign report is also a reminder that attack speed can be amplified by automation, which raises the bar for defensive response speed.

These controls tend to break down when approval chains are slow and asset ownership is unclear across hybrid environments, because the right action cannot be executed fast enough to matter.

Common Variations and Edge Cases

Tighter containment often increases operational overhead, requiring organisations to balance speed against the risk of disrupting legitimate users or breaking production services. That tradeoff is real, especially in environments with fragile legacy systems, shared administrative accounts, or heavily outsourced operations.

Best practice is evolving around where to automate aggressively and where to keep a human in the loop. There is no universal standard for this yet, but current guidance suggests using stronger automation for low-risk, repeatable actions such as host isolation or account disablement, while reserving manual approval for high-impact changes like broad network segmentation or production shutdown. NIST CSF is helpful for mapping this to detection, response, and recovery outcomes, while security controls guidance from NIST and MITRE can help teams test whether containment actions are actually executable under pressure.

Edge cases appear in organisations with many exceptions, such as shared service identities, bring-your-own-device access, or third-party managed infrastructure. In those settings, a containment action can fail because it was never operationally instrumented, even if it exists on paper. Teams should also expect slower response when telemetry is noisy, because analysts cannot confidently separate true compromise from routine admin activity. The strongest programs regularly rehearse containment paths, validate access revocation timing, and confirm that automation still works after infrastructure changes.

Related resources from NHI Mgmt Group

• Why do teams with many security tools still struggle to respond quickly?
• Why do small security teams struggle with cloud detections even when they have modern tools?
• Why do organisations with many IAM tools still struggle with governance?
• Why do identity programmes struggle even when they have strong visibility tools?