How should organisations govern identity when one person moves through multiple relationship states?

Why This Matters for Security Teams

When a person moves from employee to contractor, approver to requester, or internal staff to external partner, the risk is not the label itself. The risk is whether access still reflects the current relationship state. Static identity records, manual reviews, and one-time provisioning often lag behind reality, which leaves stale access in place after role or status changes. NIST’s NIST Cybersecurity Framework 2.0 treats this as an access governance problem, not a paperwork problem.

The same pattern appears in NHI governance, where authority should follow lifecycle state rather than a permanent label. The Ultimate Guide to NHIs shows why lifecycle visibility matters: 97% of NHIs carry excessive privileges, and 71% are not rotated within recommended time frames. That is the same failure mode seen in human relationship transitions, only with more ambiguity and fewer built-in controls.

Security teams get this wrong when they design access around the person instead of the state machine behind the person. In practice, many organisations discover excess access only after a status change has already created an audit gap or an unwanted privilege path.

How It Works in Practice

Governance should start by defining the authoritative relationship states that matter operationally: employee, manager, approver, contractor, vendor, intern, partner, and terminated. Each state needs explicit ownership, data sources, and entitlement rules. The important shift is that policy should not ask, “Who is this person?” alone. It should also ask, “What relationship state is currently authoritative, and what access is permitted in that state?”

That approach aligns with current identity guidance from NIST and with lifecycle thinking in the Ultimate Guide to NHIs. For practitioners, the operating model usually includes:

• Authoritative sources for each state, such as HRIS, contractor management, procurement, or partner directories.
• Machine-readable triggers for state transitions, so changes can drive provisioning, deprovisioning, or entitlement reduction automatically.
• Role or attribute mapping that converts state into access rules, rather than relying on manual judgement at review time.
• Revocation logic that removes or changes access immediately when the state changes, especially for privileged or shared systems.
• Periodic reconciliation that compares the current relationship state against actual entitlements and flags drift.

This is where the NHI analogy is useful. Identity should behave like a governed lifecycle, not a permanent grant. The Ultimate Guide to NHIs — Regulatory and Audit Perspectives reinforces that auditors care less about intent and more about evidence that access changes followed the lifecycle consistently. For human identities, the same principle applies: if the state changes, the entitlement model must change with it.

In practice, this works best when identity governance, PAM, and workflow orchestration are connected so that transition events are handled in near real time. These controls tend to break down when relationship states are tracked in spreadsheets or ticket comments because the system cannot reliably detect which source of truth should win.

Common Variations and Edge Cases

Tighter state-based governance often increases operational overhead, requiring organisations to balance access precision against onboarding speed and administrative burden. That tradeoff becomes more visible in environments with matrix management, contingent labour, or shared accountability across business units, where a single person may legitimately hold multiple active states at once.

Best practice is evolving here. There is no universal standard for how many relationship states should exist or how granular they should be. Some organisations collapse the model into a few coarse states, while others track finer distinctions for approver rights, financial controls, or regulated data access. The right choice depends on whether the state affects authorisation decisions in a meaningful way.

Edge cases also matter. A person may be both a contractor and a system owner, or may transition from employee to advisor without a clean end date. In those cases, governance should prefer additive rules only when explicitly approved, and should otherwise default to the most restrictive applicable state. This is especially important where privileged access, third-party access, or delegated approval rights are involved, because stale entitlements can persist long after the relationship that justified them has ended. Current guidance suggests that transition handling should be auditable, deterministic, and reversible, not dependent on manual exception tracking.

For organisations already managing NHI lifecycle risk, the lesson carries over directly: relationship state is not metadata to display, it is the control input that should drive access decisions.

Related resources from NHI Mgmt Group

• How should organisations govern multiple credential types in one identity programme?
• How should organisations govern reusable digital identity across multiple services?
• How should organisations govern access through identity providers without overcentralising risk?
• How do organisations govern identity attack surface as a programme, not a one-off project?