Who should own identity readiness in an M&A programme?

Why This Matters for Security Teams

identity readiness in an M&A programme is not a narrow IAM exercise. It determines whether the buyer can trust inherited access paths, vendor connections, service accounts, and automation before integration accelerates risk. The deal team is focused on valuation and timing, but identity gaps can silently undermine both, especially when legacy systems, forgotten secrets, and weak offboarding collide. NHI Management Group notes that only 5.7% of organisations have full visibility into their service accounts in the Ultimate Guide to NHIs.

This is why identity readiness belongs in the integration workstream with clear executive sponsorship. It needs legal, finance, IAM, infrastructure, and business process owners aligned on what must be verified before close, at Day 1, and during post-close stabilization. The NIST Cybersecurity Framework 2.0 supports this kind of cross-functional accountability, but it does not replace the operating model needed to execute it. In practice, many security teams encounter privilege sprawl only after inherited accounts have already been used to move data or alter systems.

How It Works in Practice

Effective ownership starts with a named integration lead who can force decisions across the deal timeline. That person is usually not the security team alone. Deal leadership defines the gating questions, finance identifies material systems and control dependencies, IAM inventories identities and entitlements, and business owners validate whether access is still needed for payroll, ERP, customer support, manufacturing, or cloud operations.

Current guidance suggests treating identity readiness like a diligence and remediation programme with explicit work products:

• Inventory human and non-human identities, including service accounts, API keys, certificates, and third-party access.
• Map where identities authenticate, what they can reach, and whether access is tied to a business process that will survive the transaction.
• Flag secrets stored outside managed vaults, because inherited secrets often appear in code, scripts, CI/CD, and shared documentation.
• Define Day 1 controls for privileged access, break-glass use, and revocation of unnecessary integrations.
• Track remediation owners and dates so issues are resolved before systems are merged or inherited controls are accepted.

For non-human identities, the operational bar is higher because machine access persists even when staff change. The most useful reference point is the lifecycle discipline in the Top 10 NHI Issues, especially around rotation, offboarding, and visibility. Security teams should also compare acquisition findings against breach patterns in the 52 NHI Breaches Analysis to pressure-test assumptions about inherited trust. These controls tend to break down when the acquired environment spans multiple IAM stacks and no single team can verify ownership of every credential path.

Common Variations and Edge Cases

Tighter identity control often increases deal friction and remediation cost, requiring organisations to balance speed of close against confidence in inherited access. That tradeoff is unavoidable when the target has fragmented identity tooling or heavy reliance on contractors and unmanaged automations.

There is no universal standard for ownership in every transaction type. In a tuck-in acquisition, the integration lead may run identity readiness from a central PMO. In a carve-out, the divestiture team may own separation, while the buyer owns inbound access validation. In regulated environments, finance and legal may insist on stronger sign-off because identity issues can affect control assertions, audit scope, and customer commitments. Best practice is evolving, but the ownership model should always make one executive accountable for decisions, one technical team accountable for evidence, and one business owner accountable for process impact.

The hardest cases are environments with cloud-native tooling, unmanaged secrets, or heavy third-party dependence. Those situations require explicit decisions about which identities are transferred, recreated, or terminated. The lesson from NHI governance is straightforward: identity readiness cannot be delegated to post-close cleanup, because inherited access is often the first place attackers look.

Related resources from NHI Mgmt Group

• Who should own privileged access governance in an identity programme?
• Who should own identity-related compliance controls in practice?
• Who should own identity and device governance in a consolidated work platform?
• Who should own biometric verification risk in an IAM programme?