How should teams govern access across multiple sites and business units?

How to set a common access lifecycle across sites

Cross-site access governance works best when the lifecycle is standardised and the exceptions are localised. Treat joiner, mover and leaver handling as one operating model, so every business unit follows the same identity creation, change and removal steps. That gives you consistent approval, recertification and revocation behaviour even when the access itself differs by site, function or legal entity.

The practical difference is between centralising the rules and centralising the permissions. Teams should avoid one-off local account processes, because those create hidden variations in approval paths, expiration rules and revocation timing. A shared lifecycle makes it easier to prove who can still reach what, and why, after an organisational change.

Accessing systems across regions also tends to expose process drift, especially where sites have different HR feeds, local IT ownership or legacy admin practices. A single lifecycle model reduces that drift by making the control point the same everywhere, while still allowing local decision-making on role assignment and business justification.

Why role, location and relationship still matter

A common lifecycle does not mean identical access. Role should remain the primary driver, but location and relationship often determine whether access is lawful, operationally sensible or commercially necessary. For example, a finance user may need the same core application entitlement across sites, but only a subset of datasets or workflows should be reachable in each location.

Location is especially useful when access depends on jurisdiction, support boundary, data residency or on-site operational responsibility. Relationship matters when access is granted because someone owns a process, manages a vendor, supports a business unit, or is temporarily embedded in another team. Those are legitimate reasons to vary access without breaking the lifecycle model.

The governance test is whether the variation is tied to an enduring business purpose and can be reviewed explicitly. If the reason cannot be stated clearly, the access is usually too broad, too vague, or too hard to defend during recertification.

What good governance looks like at scale

At scale, good governance means the request, approval, provisioning and removal workflow is predictable everywhere, while the entitlement set remains flexible enough to support local operations. Teams should be able to answer three questions quickly: who approved the access, what business condition justified it, and when it will be removed or revalidated.

This is where NIST Cybersecurity Framework 2.0 is useful as a broad organising model, because the govern and protect functions both reinforce consistent access decisions and ongoing review. For a more control-oriented implementation view, NIST SP 800-53 Rev 5 Security and Privacy Controls maps naturally to access control, identification and authentication, auditability and account lifecycle management.

Where organisations need a more prescriptive operational benchmark, CIS Controls v8 reinforces account management and access control as repeatable safeguards rather than ad hoc administration. That matters because multi-site access usually fails through inconsistency, not through a lack of policy language.

Risk and Threat Considerations

Multi-site access models become risky when local exceptions survive longer than the business need that created them. The biggest exposure is not the initial grant, but the accumulation of stale access, inconsistent approval evidence and weak offboarding across sites or business units. That creates unnecessary reach for insiders, contractors and compromised accounts alike.

Failure mechanism: One location keeps using a local workflow, an inherited role or a manual exception, so revocation and recertification no longer happen on the same timetable as the rest of the organisation.

Impact: Access remains active after a transfer, project end or separation, increasing the blast radius of compromise and making it harder to prove that access was still justified.

Practitioner Guidance

What to prioritise: Standardise the lifecycle first, then tune the entitlement rules. If approvals, expiry and removal are inconsistent, location-based exceptions will eventually outlast their purpose no matter how strong the policy sounds.

What to verify: Check that every exception has an owner, an expiry or review trigger, and a recorded business rationale. If a site cannot produce that evidence, treat the access as ungoverned until proven otherwise.

Practitioner takeaway: The right model is not “one permission set for everyone”, it is “one control process for everyone, with tightly justified differences in access.” That is what keeps growth from turning into permanent local drift.

Related resources from NHI Mgmt Group

• How should security teams govern AI use cases across multiple business units?
• How should IT teams govern AI spend across multiple vendors and business units?
• How should security teams manage role-based access for mixed identity populations across multiple countries and business units?
• How should platform teams govern access to AI models and agents across multiple business groups?