Who owns ransomware containment when IAM, PAM, and recovery teams are involved?

Accountability should sit with the incident commander, but execution depends on IAM, PAM, endpoint, and recovery teams working from the same playbook. The practical test is whether access can be revoked, sessions terminated, and backup paths protected without delay. Shared ownership is essential, but roles must be explicit before the incident begins.

Why This Matters for Security Teams

Ransomware containment is rarely a single-team task. Once identity stores, privileged access platforms, backup systems, and endpoints are all in play, the question becomes who can act fastest without creating a second outage. NIST Cybersecurity Framework 2.0 treats incident response and recovery as coordinated outcomes, not isolated technical actions, which is the right lens when access control itself may be under attack. When a compromised admin path is part of the blast radius, delays in revoking access can matter as much as the malware payload.

The operational risk is that IAM may own identity lifecycle, PAM may own session control, endpoint may isolate hosts, and recovery may protect backups, but none of those teams can contain the event alone. That is why many incident programs map a single commander to decision authority while still requiring pre-approved execution steps across domains. NHIMG has documented how fast attackers move once credentials are exposed in cases like the Cisco Active Directory credentials breach and the Codefinger AWS S3 ransomware attack, where access abuse and ransomware pressure intersected. In practice, many security teams encounter fragmented containment only after attacker movement has already reached backup or identity systems.

How It Works in Practice

The cleanest model is a command-and-control structure with one incident commander and clearly assigned technical owners. IAM executes account disables, token revocation, federation shutdowns, and emergency credential resets. PAM handles privileged session termination, vault lockouts, and temporary elevation freezes. Recovery teams protect restore points, isolate backup infrastructure, and verify that clean recovery paths remain intact. Endpoint and network teams usually execute host isolation and segmentation, but they should do so under the same incident plan rather than improvising in parallel.

Practically, this works best when the organisation pre-defines which actions are permitted during a ransomware event and which require explicit approval. For example:

• IAM can disable suspected identities and rotate exposed secrets within minutes.
• PAM can terminate active privileged sessions and suspend just-in-time elevation.
• Recovery can block backup deletion, snapshot tampering, and replication changes.
• The incident commander resolves conflicts when containment actions may disrupt business systems.

This is where guidance from NIST Cybersecurity Framework 2.0 is useful: response and recovery must be rehearsed as a single workflow, not a ticket queue. It also helps to review identity-specific exposure patterns such as the BeyondTrust API key breach and the Azure Key Vault privilege escalation exposure, because ransomware actors often begin by abusing trusted control planes rather than encrypting systems first. These controls tend to break down when identity, backup, and endpoint tooling are owned by separate vendors with no shared incident authority, because each team can wait for another to move first.

Common Variations and Edge Cases

Tighter containment often increases the chance of accidental business disruption, so organisations have to balance speed against the risk of locking out legitimate responders or corrupting recovery workflows. That tradeoff is especially visible in hybrid environments, where cloud IAM, on-prem directory services, SaaS admin consoles, and immutable backups all require different operators.

There is no universal standard for who “owns” every containment action. Current guidance suggests the incident commander owns decision-making, while the technical teams own execution within their domains. In regulated environments, recovery may also need to preserve evidence, which can delay destructive cleanup or full credential rotation. In environments with third-party managed services, ownership becomes even more complex because a provider may control part of the response path but not the incident authority.

Practitioners should treat ransomware containment as a pre-negotiated operating model: named backups for each role, explicit approval thresholds, and a tested sequence for revoking access before restoring systems. The biggest failure mode is assuming the backup team can restore safely before IAM and PAM have removed attacker access. That assumption often collapses when identity compromise reaches privileged control planes.

Related resources from NHI Mgmt Group

• How should IAM teams interpret developer summit content for identity governance?
• What should IAM teams do when identity services are part of a public-sector supply chain?
• What do security teams get wrong about threat detection in IAM?
• How should security teams prioritise NHI remediation in cloud environments?