Who is accountable for SaaS identity risk after an M&A deal closes?

Why This Matters for Security Teams

Post-close SaaS identity risk is not a simple account-cleanup problem. An M&A event usually creates overlapping directories, inherited admin roles, duplicated service accounts, and third-party integrations that no one fully mapped before Day 1. That makes accountability a governance issue as much as a technical one. NIST Cybersecurity Framework 2.0 emphasizes clear ownership for risk treatment, while NHIMG’s Ultimate Guide to NHIs notes that only 5.7% of organisations have full visibility into their service accounts.

The practical challenge is that acquisition risk spans multiple control planes at once: identity governance, SaaS admin consoles, secret rotation, and offboarding of legacy access. If ownership is unclear, each team assumes another group is handling cleanup, and stale access survives long after deal closure. That is why accountability should be explicit, time-bound, and documented before the integration work begins. In practice, many security teams encounter identity sprawl only after a rogue integration or over-privileged account has already been used.

How It Works in Practice

Accountability should be assigned by control domain, not by organisational hierarchy. Security should own the risk decisioning, exception handling, and escalation path. IAM should own identity reconciliation, privileged access review, and lifecycle enforcement. Integration teams should own the operational inventory of SaaS apps, tenant merges, federation changes, and decommissioning of duplicate or shadow systems. That division aligns with NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where access governance and system inventory intersect.

In practice, the first step is to establish a post-close identity register that includes human accounts, service accounts, API keys, OAuth grants, app-to-app connections, and any delegated administrator roles. From there, teams should triage access into three buckets:

• retain, when the identity is still required for a confirmed business process;
• rotate or reissue, when the identity is valid but provenance is unclear;
• revoke, when the account or integration is no longer needed.

This is where SaaS-specific evidence matters. NHIMG’s 52 NHI Breaches Analysis shows how compromised non-human identities often become the entry point for broader access abuse. Security teams should therefore require complete logs for token issuance, admin consent, and third-party app authorization, then validate those events against the acquired company’s intended operating model. Where possible, use continuous controls from the NIST Cybersecurity Framework 2.0 to track inventory, protect high-risk access, and verify remediation.

These controls tend to break down when the acquired environment uses multiple SaaS tenants with inconsistent federation settings and undocumented delegated access.

Common Variations and Edge Cases

Tighter post-merger access control often increases integration overhead, requiring organisations to balance rapid business continuity against the cost of a slower cleanup. That tradeoff is especially visible when the acquired company depends on external contractors, reseller portals, or embedded integrations that cannot be turned off immediately.

There is no universal standard for this yet, but current guidance suggests that accountability should shift as the integration matures. During the first days after close, integration teams usually coordinate the inventory and freeze changes, while security retains final approval for high-risk exceptions. After the initial stabilisation period, IAM should drive remediation through normal governance processes, and business system owners should confirm which SaaS connections are still required.

One common edge case is when a deal includes shared vendor tooling or co-managed operations. In that case, the accountable owner for each app must be explicit, because inherited admin rights can look legitimate while remaining outside standard governance. Another edge case is when legal hold or regulatory retention prevents immediate account removal. Even then, access should be narrowed, monitored, and time-boxed. NHIMG’s Ultimate Guide to NHIs is clear that excess privileges and weak offboarding are recurring failure points, so the goal is not just ownership but provable closure. In practice, post-close risk persists when everyone agrees the other team is “handling it” but no one has authority to revoke access.

Related resources from NHI Mgmt Group

• Why do SaaS environments still create identity risk even after SSO is in place?
• Who should be accountable for identity risk after a merger closes?
• Who is accountable for identity risk after a merger closes?
• Who is accountable when a high-risk SaaS or AI tool is used without documented purpose or review?