They should govern the relationship state, not just the account label. When a person moves between employee, contractor, customer or partner relationships, the access rules, approvals and review cadence should change with that relationship. If the programme cannot express overlapping or sequential relationships, it will drift into fragmented entitlement management.
Why relationship state should drive access decisions
Security teams should treat access as a function of relationship state, not a fixed account label. Employee, contractor, customer and partner states carry different approval chains, entitlement limits, support models and review cadences. If those differences are ignored, the access model usually becomes inconsistent, over-permissive and hard to recertify when the same person crosses boundaries.
That means a person can keep the same core identity record while their access posture changes materially as the relationship changes. The practical question is not “Who is this account?” but “What authority should exist for this relationship, right now, in this context?”
For teams building the operating model, IAM and IGA basics are the right foundation because they tie authentication, entitlement management and access review to governance rather than to a single login form. That is also why the Identity Security Programme Guide matters here, it frames identity governance as an operating model across human, non-human and AI-agent populations.
How to handle overlapping and sequential relationship states
The cleanest model is to let each relationship state carry its own policy bundle, then let the active relationship determine the current permissions, approvals and review rhythm. If someone is both employee and contractor, or moves from employee to customer after separation, the system should know which relationship is primary for which application or process, rather than merging everything into a single entitlement bucket.
That is where many programmes break down. They may support a single “person” record, but they cannot express concurrent obligations, temporary overlaps or handoff periods. When that happens, teams compensate manually, which creates ad hoc approvals, inconsistent deprovisioning and entitlement drift.
The Joiner-Mover-Leaver Guide is useful because it treats movers as a first-class lifecycle event, not an exception. For relationship-state governance, the key lesson is that every move must trigger both removal of old access and assignment of the new access pattern, including any tokens, keys or delegated access that no longer fit the new state.
Identity Convergence Guide adds the broader design lens: the more identity silos you keep for workforce, customer, partner and non-human use cases, the harder it becomes to preserve a coherent view of relationship state and enforcement consistency.
What good governance looks like in practice
Good governance starts with explicit state transitions and clear ownership. Each transition should define who approves it, what entitlements are inherited, what must be removed, and when the next review is due. The goal is to make relationship change visible to the access model, so the entitlement model does not lag behind the business relationship.
For customer and partner relationships, the access design often needs different recovery, delegation and support patterns than workforce identity. A partner may need scoped B2B access, while a customer may need self-service recovery, consent-based data access or delegated administration. Treating those as the same operating state usually produces either excessive access or unusable friction.
Customer IAM (CIAM) Guide is relevant because customer and partner states commonly demand distinct authentication, recovery and delegated-access rules from workforce identities. The Workforce Identity Security Guide is the complementary reference for employee-state controls such as joiner-mover-leaver handling, federation and step-up protection.
For teams trying to measure whether the model is actually working, Identity Security Metrics and KPIs Guide is useful because relationship-state governance should show up in measurable reductions in stale access, delayed deprovisioning and manual exceptions.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CIS Controls v8 and OWASP ASVS set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Relationship-state access depends on account lifecycle, provisioning and deprovisioning. |
| AC-6 — Least Privilege | Changing relationship state should reduce access to only what the new role justifies. | |
| IA-5 — Authenticator Management | State changes often require rotating or revoking credentials, tokens and keys tied to the old relationship. | |
| Recommendation — Tie provisioning and revocation to relationship changes, not just account status. Remove inherited permissions that no longer match the current relationship. Revoke or rotate authenticators when the relationship context changes. | ||
| ISO/IEC 27001:2022 | A.5.18 — Access rights | Access rights must track changing business relationships across users and third parties. |
| A.5.16 — Identity management | Relationship-state governance depends on identifying and managing the same person across multiple states. | |
| Recommendation — Review and adjust rights when a person’s relationship to the organisation changes. Maintain identity records that support lifecycle changes and overlapping relationships. | ||
| CIS Controls v8 | CIS-5 — Account Management | Moving between employee, customer and partner states requires controlled account and access changes. |
| Recommendation — Enforce lifecycle-based account changes and remove stale access promptly. | ||
| OWASP ASVS | V8 — Authorization | Access must be authorized by current relationship context, not by a fixed account label. |
| V6 — Authentication | Different relationship states often require different authentication and recovery controls. | |
| Recommendation — Validate authorization rules against the user’s current relationship state. Apply state-appropriate authentication strength and recovery flows. | ||
Practitioner Guidance
What to verify: Confirm that your identity lifecycle can represent concurrent or sequential relationships without flattening them into one status flag. If the system cannot distinguish “former employee,” “current partner,” and “active customer” cleanly, the access process will eventually rely on human memory and spreadsheet reconciliation.
Decision rule: If the relationship changes, recalculate access from the new state first, then reattach only the access that is still justified. Do not carry forward entitlements just because the underlying account still exists.
Common mistake: Teams often govern the directory object and call that governance. In practice, the important control is the state transition, because that is where entitlement creep, review failures and approval bypass usually enter.
What to measure: Track how many moves required manual entitlement cleanup, how long old access remains active after a relationship change, and how many access reviews are still using the wrong relationship context.
Practitioner takeaway: The mature model is relationship-aware entitlement governance, where access follows the business relationship and not the historical account identity.