What should teams do when access decisions differ between two merging organisations?

Set one access model for the merged estate

When two organisations merge, the access problem is rarely just technical. Different approval paths, role names, and revocation habits can produce conflicting decisions about the same user or system. Teams should establish one governing model for the combined estate, then treat the legacy models as transitional mappings rather than parallel authorities.

The practical goal is consistency. A single decision model gives security, IAM, and application owners one answer for who can request access, who can approve it, and what level of privilege is acceptable. It also makes it possible to compare entitlements across the inherited environments without arguing policy by policy every time an exception appears.

Mergers often expose hidden differences in how access was justified, especially where one side relied on broad role bundles and the other used tighter least-privilege rules. The cleaner pattern is to define the target model first, then translate the old entitlements into it in a controlled way. That keeps the combined estate governable while the technical consolidation work continues.

How to handle policy conflicts without freezing operations

During transition, exceptions are unavoidable, but they should be explicit and time-bound. If a legacy approval rule must remain in place for a business reason, document the exception, assign an owner, and set a retirement date. That prevents the merged organisation from quietly inheriting two competing authorities for the same access decision.

The important distinction is between a temporary mapping and an enduring policy split. Temporary mappings let teams keep people productive while the target model is rolled out. Enduring splits create ambiguity over approval, provisioning, and revocation, and that ambiguity is where access sprawl and missed removals usually start.

This is also where recertification matters. Access that was valid under one company’s policy may be excessive under the combined model, even if nobody notices immediately. Teams should review inherited entitlements against the new baseline, especially for privileged roles, shared accounts, and application access that crosses business units.

What good governance looks like after the merge

Good merger governance makes the target access model visible, owned, and enforceable. That means clear ownership for the new policy, a mapped inventory of inherited access rules, and a single process for approving exceptions. It also means the retirement of old policies is tracked as a deliverable, not left as an informal cleanup task.

Teams should also preserve evidence of each access decision while the transition is underway. When two models coexist, reviewers need to see which rule applied, why an exception was granted, and when it will expire. Without that record, audit and operations teams end up guessing whether a user should still have access or whether a revocation was missed.

For guidance on access control and governance expectations, practitioners can anchor the merged-state model in NIST SP 800-53 Rev 5 Security and Privacy Controls, CIS Controls v8, and ISO/IEC 27001:2022 Information Security Management. These are useful reference points for building one control baseline and retiring duplicated policy paths.

Risk and Threat Considerations

When two access models remain active after a merger, the main risk is not just administrative confusion. Conflicting rules can leave users overprivileged, delay revocation, or let an old approval path continue to operate after the target model has already changed. That increases the chance of unauthorized access and makes it harder to prove that access was correctly granted or removed.

Failure mechanism: Competing policies create gaps between approval, provisioning, and revocation, so a user or service may remain valid under one model after it should have been removed under the other.

Impact: The merged estate can accumulate excess privilege, inconsistent audit evidence, and delayed deprovisioning, which raises both operational and security exposure.

Practitioner Guidance

What to prioritise: Start by naming one policy owner for the combined estate and one target access model that will win. If the old models are both still being used in production decisions, treat that as a transition risk, not a stable operating state.

What to verify: Check that every inherited entitlement can be traced to either the target model or a documented exception with an expiry date. The test is simple: if a reviewer cannot tell which rule applied, the governance model is not yet operational.

Practitioner takeaway: Mergers become safer when access policy consolidation is treated as a control-design problem, not just a migration task. The objective is to remove decision ambiguity before it turns into privilege drift or missed revocation.

Related resources from NHI Mgmt Group

• How should security teams run access reviews for non-human identities?
• How should security teams govern non-human identities that have persistent access?
• What is the difference between reviewing human access and reviewing NHIs?
• What is the difference between role-based access and API key governance for NHI security?