IAM cycle in action: a mid-market IT consultancy

An end-to-end worked example of the IAM operational cycle and JML in a consolidated mid-market IT consultancy — where consultants rotate constantly between client engagements, access often lives in clients' own tenants via federation, the Mover is the dominant motion, and the core risk is one client's data following a consultant onto the next.

When the Mover is the main event

We close the module between our two extremes. The hospital was heavy with regulation; the startup was light on governance and fast on its feet. A consultancy is neither — it’s a mature, consolidated organization whose defining trait is constant internal motion. Its people don’t sit in fixed roles touching fixed systems; they rotate between client engagements, and each rotation reshapes their access. If the JML article told you the Mover is the step most programs neglect, here’s the organization where the Mover is the main event.


Meet Northcape — a 2,000-person IT consultancy serving mid-market and enterprise clients across application development, cloud migration, and managed services. Northcape is well-established and profitable, with a real IT function and mature tooling. Its challenge isn’t capability; it’s velocity of change: at any moment, hundreds of consultants are rolling off one engagement and onto another, and a meaningful share of their access lives not in Northcape’s own systems but inside their clients’ tenants.



The organization and its identity populations

Northcape’s populations are organized around how people relate to work, not just to the firm:


PopulationCountLifecycle shapeAuthoritative source
Billable consultants~1,500Constant project rotationHRIS + project staffing (PSA)
Bench (between engagements)~150Reduced access, awaiting assignmentHRIS + PSA
Subcontractors~200Engagement-bound, externalVendor management + PSA
Internal staff (HR, finance, IT)~150Stable, conventional rolesHRIS
Client-side guest identitiesthousandsFederated into client tenantsClients’ own directories

The interesting populations are the first two. A billable consultant on a project has its access; a consultant on the bench between projects should have reduced access — internal systems only, no client environments — because they’re not currently serving anyone. The transition between billable and bench, in both directions, is a Mover that happens constantly, and treating “bench” as a real state with its own reduced access set is what stops idle consultants from carrying live client access they have no current reason to hold.


Two authoritative sources: who you are, and what you’re on

A conventional org can run JML off the HRIS alone. Northcape can’t, because the HRIS knows who someone is and their job grade but not what engagement they’re on this week — and access is driven by the latter. So Northcape runs a second authoritative source: a project staffing system (PSA) that owns assignments, roles on the engagement, and project end dates.


AttributeAuthoritative sourceWhy
Identity, grade, employmentHRISThe firm owns the person
Current engagement & end datePSAStaffing owns who’s on what, until when
Subcontractor statusVendor managementSubcontractors aren’t on payroll
Client tenant accessClient directory (federated)The client authorizes their own systems

The IGA platform joins these feeds: HRIS establishes the identity and its baseline, the PSA drives engagement-specific access with hard end dates, and the result is access that reflects current reality. The crucial encoded rule: engagement access expires with the engagement. Because the PSA carries an end date for every assignment, access can be time-boxed to vanish when the project closes — a just-in-time pattern at the scale of whole engagements.


Joiner and Mover: rolling onto an engagement

At Northcape, the Joiner (a new consultant joining the firm) is the rare event, and the Mover (a consultant rolling between engagements) is the constant one. The two share the same machinery, so we treat the engagement rotation as the canonical flow.


flowchart TB
  accTitle: A consultant rotating between client engagements
  accDescr: A PSA assignment-change event fires when a consultant rolls off engagement A onto engagement B. The IGA platform revokes the engagement A access set, including federated guest access to client A's tenant, then provisions the engagement B access set with federated access to client B's tenant and a time-box set to engagement B's end date. The change is logged for both the firm and the affected clients.
  PSA[PSA assignment change<br/>roll off A, onto B] --> REVOKE[Revoke engagement A access]
  REVOKE --> DEFED_A[Remove federated guest<br/>in client A tenant]
  PSA --> GRANT[Provision engagement B access]
  GRANT --> FED_B[Add federated guest<br/>in client B tenant]
  GRANT --> BOX[Time-box to engagement B end date]
  DEFED_A --> LOG[Log for firm + clients]
  FED_B --> LOG
  BOX --> LOG
Every rotation is a Leaver from the old engagement and a Joiner into the new one, run together — and the firm, not the client, drives the revoke half.

This is the JML article’s “every Mover is a tiny Leaver plus a tiny Joiner” rule made literal and unavoidable. Rolling onto engagement B without rolling off engagement A doesn’t just create privilege creep — it leaves the consultant with standing access to a client they no longer serve, which in consulting is a confidentiality and conflict-of-interest breach, not merely untidy access. The revoke half is the half that protects the firm’s contracts, so it cannot be optional or manual.


The distinctive challenge: access that lives in clients’ tenants

The structural twist of consultancy IAM is that much of a consultant’s access isn’t in systems Northcape controls — it’s inside the client’s environment. A consultant building software for a client logs into the client’s cloud tenant, their repositories, their ticketing system. How does Northcape govern access it doesn’t own?


The answer is federation. The consultant authenticates with their Northcape identity and is admitted to the client’s tenant as a guest or external user — for example via Microsoft Entra B2B collaboration. Authentication stays with the employer; authorization is granted by the client. This is elegant but creates a sharp deprovisioning responsibility:


  • When the consultant rolls off, Northcape must remove the guest access in client A’s tenant — not wait for client A to notice.
  • When the consultant leaves Northcape entirely, every federated guest identity across every client must be revoked, or the person retains live access to multiple clients after departure.
  • The home identity is the linchpin: disabling it at the source should cascade to cut federated access everywhere, which is why the firm must drive offboarding rather than delegating it to each client.


Leaver: departure across many environments

A consultant leaving Northcape is a more complex Leaver than in a single-tenant company, because their access is scattered across the firm’s systems and an unknown number of client tenants accumulated over their tenure. The flow:

  • Immediately: disable the Northcape home identity, revoke sessions, and cascade to remove federated guest access from every client tenant the identity reaches.
  • Reconcile against the PSA: cross-check the consultant’s engagement history to confirm no client environment was missed — the engagement record is the map of where to look.
  • Disable, then delete: as always, retain the disabled account for the contractual and regulatory retention window before deletion, because consulting work product and audit obligations often outlive the consultant by years.
  • Subcontractor variant: subcontractors lapse rather than resign, so a missing vendor end date is treated as an exception, exactly as with the hospital’s contractors.

The reconciliation step matters more here than anywhere else in the module: in a consultancy, the list of places someone has access is itself hard to know, and the PSA’s engagement history is the only reliable map of the federated footprint to dismantle.


Compliance and the conflict-of-interest dimension

Northcape lives under ISO/IEC 27001 and SOC 2, and — uniquely — under the security clauses of its own client contracts, which often impose stricter access requirements than any general framework. A client may contractually require that access be removed within hours of a consultant rolling off, that no consultant serving a competitor retains access, and that the firm produce evidence of both on demand.


This adds a dimension absent from the other two cases: access hygiene is a conflict-of-interest control, not just a security one. The same Mover discipline that prevents privilege creep also prevents client A’s data from being reachable by a consultant now embedded at client A’s competitor. In consulting, deprovisioning isn’t only about reducing attack surface — it’s about honoring the wall between clients that the firm’s reputation depends on.



The bench: a real state, not a gap

The single control that distinguishes a mature consultancy’s IAM is treating the bench — consultants between engagements — as a first-class lifecycle state, not as “still on the last project until the next one starts.” When a consultant rolls off and isn’t immediately re-staffed, the correct behavior is a Mover into a reduced-access state: internal systems only, every client federated guest removed, billable-project entitlements retired.


Practitioners enforce this because the alternative is the quiet accumulation that the JML article warns about, in its most contractually dangerous form. A consultant who sits on the bench for six weeks while retaining live access to three former clients’ tenants is a walking conflict-of-interest exposure — and the longer the bench, the staler and less defensible that access becomes. Tying the access state to the PSA’s assignment status, so that “unassigned” automatically means “internal-only,” removes the judgment call and the delay. The bench is also where periodic certification has the most leverage: a consultant with no current engagement should have no client access, which is the easiest access review in the world to adjudicate and the most embarrassing one to fail.


Subcontractors and offshore delivery

Northcape doesn’t deliver every engagement with its own badged employees. Subcontractors and offshore delivery centers extend the workforce — and the identity perimeter — well beyond the firm, and they’re where the lifecycle is hardest to enforce.


Subcontractors lapse rather than resign, exactly like the hospital’s contractors, so their identities must carry a hard end date from the vendor management system and the PSA, with a missing or extended date treated as an exception. Offshore delivery adds two more dimensions practitioners handle explicitly:

  • Device posture: access from an offshore center’s managed workstations is treated differently from access via an unmanaged personal device. Conditional-access policies gate sensitive client environments on device compliance and location, so identity isn’t the only signal — the context of the request matters too (a direct preview of the risk-based authentication we’ll cover in Access Management).
  • Data residency: some client contracts require their data never leave a jurisdiction, which constrains which delivery center may be staffed onto the engagement at all. Here the access decision is entangled with where the human physically sits — a constraint the PSA must carry alongside the assignment.

The lesson is that the identity perimeter of a consultancy is porous by design, and the controls have to reach people the firm doesn’t employ, on devices it doesn’t own, in countries where the data isn’t allowed to travel.


What practitioners actually run: entitlement management and access reviews

Mature consultancies converge on a recognizable best-practice stack built around time-bound, request-and-approve access packages rather than standing grants:

  • Entitlement management with expiration — for example Microsoft Entra Entitlement Management access packages — bundles the access an engagement needs and assigns it with an expiry tied to the project end date, so roll-off deprovisioning is automatic rather than remembered.
  • Governed external collaborationMicrosoft Entra External ID / B2B on the client side, with the home firm driving guest lifecycle — so the federated access from the diagram above is created and removed under control, not left to each client.
  • Recurring access reviewsEntra Access Reviews or the equivalent in a full IGA suite (SailPoint, Saviynt) — where engagement leads recertify who still needs client access, catching anything the automated roll-off missed.
  • SoD and conflict-of-interest enforcement — the same IGA toolset models ethical walls: rules that prevent a consultant on client A from being granted access to a direct competitor’s environment, the access-layer expression of the confidentiality the firm contractually owes.

These map cleanly onto ISO/IEC 27001 Annex A — identity management, access provisioning and review, and the management of access for external parties — which is why a consultancy that runs this stack tends to sail through both its certification audit and its client security assessments. The unifying idea practitioners keep returning to is expiration over revocation: in an organization where people move constantly, access that defaults to ending on a known date is far safer than access that must be remembered to be removed. The whole industry’s tooling has converged on that principle precisely because the Mover never stops.


A consultant’s quarter: rotation in practice

Trace David, a senior cloud engineer, through three months to see the machinery turn. In January he’s staffed on Client A, a bank, with a federated guest identity in the bank’s tenant and an entitlement package whose expiry is set to the engagement’s planned end. He works inside the bank’s cloud environment daily, authenticating with his Northcape identity.


In mid-February the engagement wraps early. The PSA records the roll-off, and three things happen automatically: the entitlement package for Client A expires, his federated guest access in the bank’s tenant is removed, and his status flips to bench — internal-only access, no client environments. He’s not carrying live access to a bank he no longer serves, and the audit trail shows the exact timestamp each access ended.


Two weeks later he’s staffed on Client B, a retailer. A new assignment in the PSA triggers a fresh entitlement package — federated access into the retailer’s tenant, scoped to his role, expiring at the new project’s end date. At no point did anyone file a ticket to remove his bank access; it expired by design when the engagement did. That single property — access that defaults to ending — is what lets Northcape rotate hundreds of Davids every quarter without drowning in standing grants or confidentiality breaches. The contrast with the startup’s struggle is instructive: where Rebate fights to remember to remove access, Northcape engineers the removal to happen on its own.


Measuring consultancy IAM

The metrics that matter at Northcape are weighted toward the removal side, because that’s where both the contractual risk and the conflict-of-interest exposure live:


MetricWhat good looks like
Roll-off deprovision timeClient access removed within the hours the contract specifies, not days
Federated guest orphan countNear zero — no guests in client tenants without a current engagement
Project-end auto-expiry rateThe overwhelming majority of access ending by expiry, not by manual action
Bench access complianceBenched consultants holding zero client access, full stop
Access review completionEngagement leads recertifying client access on the contractual cadence

Federated guest orphan count is the metric unique to this sector and the one practitioners watch hardest: a guest identity sitting in a client’s tenant with no matching current engagement is the cross-organizational orphan that federation makes possible, and it’s invisible unless you reconcile into each client’s directory, not just your own. Roll-off deprovision time is where the audit and the contract meet — a client’s security clause may specify a hard number, and Northcape must be able to prove it hit that number for every consultant who ever rolled off that client. When access expires by design at project end, both metrics take care of themselves; when removal is manual, both quietly degrade with every rotation, which over hundreds of consultants is a guarantee of eventual breach.


Rebadging: when a consultant becomes the client’s employee

A distinctive consultancy edge case is rebadging — a consultant is hired away by the very client they were serving, or a managed-services transition moves a whole team from Northcape’s payroll to the client’s. It’s simultaneously a leaver from Northcape and a joiner at the client, and the dangerous moment is the seam between them.


Handled well, the consultant’s Northcape home identity is offboarded — including the federated guest access into the client — while the client provisions them a native identity in parallel, so access is continuous but the basis of that access changes hands cleanly. Handled badly, the federated guest lingers alongside the new native account, leaving the person with two access paths into the client’s systems, one of which Northcape still nominally owns but no longer has any reason to. That orphaned guest is a textbook cross-organizational loose end.


The best practice is to treat rebadging as a coordinated dual event with an explicit cutover, not as two unrelated transactions that happen to involve the same human. Northcape’s leaver flow must run to completion — guest access removed everywhere — precisely because the person is staying reachable in the client’s world through a different door. The principle echoes the hospital’s dual-affiliation rule: when one human’s relationships change hands, govern each relationship’s access on its own terms rather than assuming continuity of the person means continuity of access.


What this case teaches

Northcape generalizes to any project-based or matrixed organization where people move faster than org charts:


LessonThe generalizable principle
Access follows the engagementDrive access from current assignment, not static title
Add a second authoritative sourceWhen the HRIS can’t answer “on what,” add a system that can
Every rotation revokes and grantsThe Mover is a Leaver plus a Joiner — make both halves automatic
You own offboarding from others’ systemsFederation moves the door, not the responsibility
Engagement history is the deprovisioning mapYou can’t remove access you can’t enumerate

The deepest lesson closes the loop on the whole module: across a regulated hospital, a chaotic startup, and a rotation-driven consultancy, the same truth holds — the value and the risk both live on the removal side of the lifecycle. Granting access is easy and popular everywhere; the discipline that distinguishes a real IAM program, in every sector, is how reliably it takes access away when the relationship, the role, or the engagement that justified it ends.



Three questions to test yourself

  1. A consultant rolls from client A onto client B, a direct competitor. List exactly what must be revoked, what must be granted, and why the revoke half is a contractual obligation here and not merely good hygiene.
  2. A consultant leaves Northcape. How do you guarantee that every federated guest account across all their past client tenants is removed, and what authoritative record tells you where to look?
  3. Northcape’s HRIS says a consultant is a “Senior Developer,” but that title implies nothing about what they can access today. What second authoritative source resolves this, and what specific attribute does it contribute that the HRIS cannot?

Frequently asked questions

Why is the Mover the dominant JML motion in a consultancy?

Because consultants don't stay on one assignment — they roll off one client engagement and onto the next every few weeks or months. Each rotation is a Mover that must grant access to the new engagement and, critically, revoke access to the old one. In a project-based firm the steady churn of project assignments, not hiring and firing, is the highest-volume lifecycle event by far.

What is a second authoritative source in a consultancy, and why is it needed?

Beyond the HRIS, which owns who someone is, a consultancy needs a project staffing system (PSA) that owns what engagement they're assigned to right now and until when. Access is driven by the current assignment, not by the static job title, so the PSA is authoritative for project membership and end dates — and the IGA platform joins both feeds to compute access.

How do consultancies manage access to clients' systems?

Often through federation: the consultant uses their home firm identity to access the client's tenant as a guest or external user (for example Microsoft Entra B2B), so authentication stays with the employer while authorization is granted by the client. The home firm must still drive deprovisioning, because a consultant who leaves the firm or rolls off the engagement should lose client access immediately, not whenever the client notices.

What is the biggest confidentiality risk when a consultant changes projects?

That access to the previous client's data and systems isn't revoked, so a consultant now serving a competitor still holds standing access to the former client. This is both a privilege-creep problem and a contractual and conflict-of-interest breach, which is why every engagement rotation must retire the old client's access as deliberately as it grants the new one's.

Why tie consultant access to project end dates?

Because engagements have known end dates, access can be time-boxed to expire automatically when the project does — a just-in-time pattern at the engagement scale. This prevents the accumulation of standing access across the dozens of clients a consultant touches over a career, and it satisfies client contracts that require access to end when the work does.