Start by identifying the relationship types that exist across the organisation, then map which access rights each relationship justifies and who owns each one. Once that inventory exists, lifecycle actions can be tied to relationship change instead of treated as isolated account events.
Why the first move is relationship-based, not account-based
When identity categories stop matching business reality, the problem is usually that the organisation is managing accounts, roles, or labels after the fact instead of managing the actual identity security programme it needs to support. The first useful step is to identify the real relationship types across the business, because those relationships determine which access is legitimate, who should approve it, and what lifecycle change should trigger review.
This matters because categories such as employee, contractor, service account, partner, bot, or application often hide different entitlement patterns. If the organisation starts with the wrong category model, it will keep recertifying the wrong things, miss ownership gaps, and treat legitimate lifecycle changes as exceptions instead of normal events.
That is why lifecycle management has to begin with the business relationship, not the technical account. A relationship-first model makes it possible to decide whether access is justified by employment, vendor work, delegated administration, automation, or another operating relationship, then connect each relationship to the minimum access it actually requires.
What to inventory before you redesign identity categories
The first inventory should cover who or what the relationship is, what business function it supports, what systems it touches, and who owns it. NHI lifecycle management guidance is useful here because it treats provisioning, rotation, offboarding, and ownership as linked lifecycle decisions rather than isolated account tasks.
Once that inventory exists, map each relationship type to the access rights it justifies and the control boundary that should govern it. That is where many organisations uncover duplicated roles, shared credentials, overbroad inheritance, and access that survives after the relationship has ended. The inventory should be detailed enough to show whether access is human, service, vendor, or automation-driven, because those different relationship patterns have different review and revocation needs.
Good practice is to include the owner for each relationship, the system owner for each entitlement set, and the operational trigger that should change the access state. For example, a contractor ending an engagement, a supplier changing scope, or an automation being retired should all produce different downstream actions even if they currently look like the same account event.
How relationship-driven lifecycle control changes day-to-day governance
Relationship-driven governance turns identity management into a change-management discipline. Instead of asking whether an account is old, stale, or in the wrong group, teams ask whether the underlying relationship still exists and whether the access still matches the current business purpose. That is a stronger control model because it ties review and revocation to an external reality, not to a calendar or a username.
It also improves decision quality for privileged and shared access. When access is justified by a relationship, the organisation can decide whether it should be time-bound, approval-bound, environment-bound, or task-bound. If the relationship changes, the entitlement should change with it, rather than waiting for a periodic cleanup cycle to discover the mismatch.
For this reason, many identity programmes benefit from treating categories as reporting labels and relationships as the true governance object. The category can help route workflow, but the relationship should determine whether access remains valid, whether ownership is still clear, and whether the account should be recertified, reduced, or removed.
Risk and Threat Considerations
When organisations misclassify relationship types, they tend to preserve access longer than the business relationship justifies. That creates excess privilege, weak ownership, and blind spots around offboarding, especially where shared or service-style access has been copied from one context into another.
Failure mechanism: The governance model treats the label on the account as authoritative, so lifecycle events do not trigger the right review, revocation, or reclassification action. Over time, stale access accumulates and remains usable even after the underlying relationship has changed or ended.
Impact: The result is avoidable exposure to misuse, privilege creep, delayed deprovisioning, and harder incident containment. If a compromised account still reflects an outdated relationship, the organisation may also miss the point at which access should have been removed.
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 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Lifecycle changes require managing credentials and revocation tied to relationship changes. |
| AC-2 — Account Management | The question is about how organisations should inventory and govern accounts by real relationship ownership. | |
| AC-6 — Least Privilege | Mapping relationship types to justified access rights is a least-privilege decision. | |
| Recommendation — Tie credential issuance, rotation, and revocation to relationship changes rather than isolated account events. Maintain account records that map each identity to a current business relationship and owner. Restrict each relationship type to the minimum access its business purpose justifies. | ||
| ISO/IEC 27001:2022 | A.5.18 — Access rights | Identity categories must be translated into justified access rights and ownership. |
| A.5.16 — Identity management | The topic centers on redefining identity categories around real business relationships. | |
| Recommendation — Review access rights against the business relationship that originally justified them. Align identity records to the organisation’s actual relationship model and ownership structure. | ||
Practitioner Guidance
What to prioritise: Start by building a relationship taxonomy that reflects how the business actually operates, not how the IAM tool happens to label users. The taxonomy only needs to be good enough to separate materially different access justifications, such as employment, vendor service, automation, delegated administration, and partner access.
What to verify: For each relationship type, verify that there is a named owner, a clearly justified access pattern, and a defined lifecycle trigger for review or removal. If any of those three are missing, the category model is still too abstract to govern real access.
Practitioner takeaway: The first control problem is not excessive accounts, it is weak correspondence between business relationships and the access those relationships are allowed to carry.