Who should own access cleanup during post-merger integration?

Who should own access cleanup after a merger?

access cleanup is not a task to hand to one function in isolation. It works best when a single accountable owner drives the transition, with corporate development, security, engineering, and the business leader for the acquired capability each contributing their part. The failure mode is fragmented ownership, because orphaned access tends to linger until customer impact, audit pressure, or an incident forces remediation.

Why ownership has to be cross-functional, not committee-based

Post-merger access cleanup spans more than account removal. It includes discovering inherited identities, understanding which systems are still in use, deciding who approves access changes, and sequencing revocation so operations do not break. That makes it a governance problem as much as a technical one, because the answer depends on business continuity, application ownership, and security control execution.

The practical model is shared input with single-threaded accountability. Corporate development usually owns deal coordination and integration milestones. Security owns control standards, risk acceptance, and verification that access reduction is actually happening. Engineering owns system knowledge, dependencies, and the mechanics of removal. The business leader for the acquired capability decides what still needs access and what can be retired.

When those roles are explicit, the cleanup can happen as part of the integration plan rather than as an afterthought. When they are not, teams often preserve access “temporarily,” then discover months later that temporary access has become normal operating state.

What the accountable owner must control end to end

The accountable owner should not personally perform every removal. They should control the sequence: inventory the inherited access surface, classify what is needed for the retained business, assign owners for each system, set deadlines for revocation or migration, and confirm that exceptions are documented. This is especially important when access is tied to shared admin roles, service credentials, or integration accounts that are easy to overlook during a transaction.

A useful boundary is this: if a system, account, or entitlement can outlive the integration decision without being reassessed, the ownership model is too loose. Access cleanup needs a named decision-maker for the whole transition, plus named executors for each platform or business domain.

For teams standardising the cleanup process, the underlying access-control work is often easiest to align with established control language in NIST Cybersecurity Framework 2.0, CIS Controls v8, and NIST SP 800-53 Rev 5 Security and Privacy Controls, because all three reinforce clear ownership, least privilege, and verification of access changes.

How to keep the cleanup from stalling

The main reason merger cleanup stalls is ambiguity over who can approve the access change and who is judged on the outcome. A good ownership model makes one team accountable for the transition end to end, then uses the other functions as required approvers or subject-matter owners. That keeps the work moving while still preserving the checks needed to avoid accidental outages.

A second failure point is assuming the acquired environment can be cleaned up after “business as usual” is restored. In practice, access cleanup competes with integration fatigue, so it needs dates, exit criteria, and an escalation path. If no one is forced to resolve exceptions, inherited access becomes permanent by default.

Risk and Threat Considerations

Fragmented ownership creates a predictable security exposure: old access survives because every team assumes another team will decide what to remove. In a merger, that can leave legacy administrators, shared accounts, stale API access, and privileged sessions available long after the business need has ended.

Failure mechanism: The access transition is split across functions without a single accountable owner, so approvals, revocations, and exception handling fall out of sequence or are never closed. That weakens visibility over inherited privilege and makes it easier for unnecessary access to persist.

Impact: Excess access increases the blast radius of compromise, raises audit findings, and can delay integration because teams cannot safely retire legacy systems until they trust the entitlement state.

Practitioner Guidance

What to prioritise: Assign one accountable owner for the full access transition, then require each domain team to provide inventory, dependency confirmation, and sign-off on its own slice. If that owner cannot name the approver for a revocation request, the control design is already too weak.

What to verify: Confirm that every inherited system has a business owner, technical owner, and removal deadline, and that exceptions have an expiry date rather than an open-ended waiver. The useful test is whether the team can prove who approved continued access and why.

Practitioner takeaway: Access cleanup succeeds when one party owns the outcome and the rest own inputs; it fails when everyone is involved but nobody is accountable for closure.

Related resources from NHI Mgmt Group

• When do NHI access reviews create more value than a one-time cleanup?
• What do security teams get wrong about PAM during post-merger integration?
• Who should own access and data cleanup during employee offboarding?
• Who should own post-breach access cleanup?