The operational IAM cycle

From concepts to the machinery that runs them

In the previous articles we built the concepts: what a digital identity is, the four modern types, how IAM fits into cybersecurity, the four historical waves, and the five domains. If you memorized all of that but never saw what it looks like in operation, you’re missing the most important part.

Concepts don’t float in the air — they live inside a machinery that runs every day, without pause. Every time a new employee joins the company, every time someone changes teams, every time a contract is renewed, every time a customer deletes their account, there’s an IAM process running in the background. If that machinery is well-oiled, everything flows without anyone noticing. If it’s broken, the problems show up: orphan accounts, access that survives offboarding, certifications that arrive empty, failed audits.

This article opens the “IAM in Action” module: we’re going to open up that machinery and look inside. We’ll walk through the six core operational processes — aggregation, master record, correlation, orphan reconciliation, JML, mapping — and land them in a complete healthcare case, where IAM operational complexity is among the highest that exists.

Big picture of the cycle

The operational IAM cycle runs six continuous processes: aggregation from authoritative sources, building the master record, correlation of identities to accounts, orphan reconciliation, the Joiner-Mover-Leaver lifecycle, and account mapping. It’s a loop, not a line — each process’s output feeds the next.

Before getting into the detail of each process, look at the full cycle. The important thing about this schematic is to understand that it’s not linear but continuous: data comes in, gets transformed, goes out, and the output becomes input for the next iteration.

flowchart LR
  accTitle: The IAM operational cycle
  accDescr: Authoritative sources feed aggregation, which builds the master record in the identity warehouse. Correlation links that record to downstream application accounts; reconciliation returns existing accounts to the warehouse; and JML workflows push lifecycle changes back into the applications, forming a continuous loop.
  SOURCES[Authoritative sources<br/>HRIS, CRM, contractors] --> AGG[Aggregation]
  AGG --> WAREHOUSE[(Master record<br/>Identity Warehouse)]
  WAREHOUSE --> CORR[Correlation<br/>identities ↔ accounts]
  CORR --> APPS[Downstream<br/>applications]
  APPS -.existing accounts.-> RECON[Reconciliation]
  RECON --> WAREHOUSE
  WAREHOUSE --> JML[JML workflows]
  JML --> APPS

Reading the diagram: authoritative sources feed the aggregation process, which produces the master identity record. That record connects with the real accounts in each application via correlation. The apps report their accounts back, and reconciliation detects inconsistencies (orphans, unclaimed) that go back to the warehouse. On top of the warehouse run the JML workflows that trigger automatic actions in the apps. It’s a cycle: what goes out one side comes back in another.

1. Data aggregation from authoritative sources

What an authoritative source is

An authoritative source is the system that holds the “true” version of an attribute. If you want to know María’s legal name, the right thing is to ask the HR system, not Salesforce. If you want to know her current phone number, also HR. If you want to know what cards she has assigned, it’s probably the IT Service Management tool. Every attribute has a source that is the “single authority” over it.

This matters because without a declared source, attributes live in a Schrödinger state: if your directory says “ext. 4521” and SAP says “ext. 4530,” which is the truth? Without authority, neither. And that means the data is essentially useless for making decisions.

Common authoritative source types

Integration patterns

There are two basic ways to move data from the source to the IAM system:

• Pull (scheduled queries): the IAM system queries the source every so often (every 15 minutes, every hour, every night). Simple, but introduces latency — an employee might appear in the 6:00 AM query if their contract started at 5:55 AM, or be left out and not show up until the next day.
• Push (real-time events): the source notifies the IAM system when something changes, via webhook or message queue. More complex to implement but lowers latency to seconds.

Typical challenges

• Data quality: if HR enters names with typos or inconsistent emails, those errors propagate to everything else.
• Latency between sources: HRIS may take 24 hours to reflect a new hire while the manager already wants to grant system access. The pressure to “skip the process” is huge.
• Multiple authoritative systems for the same field: who’s the authority on email — HR or Active Directory? If not decided explicitly, the two fight silently.
• Missing data in the source: HRIS may not have the right security group for the new hire, so they’re created with default values that are never corrected later.

2. Building the master identity record

What it is and why it matters

The master identity record (or identity warehouse) is the unified canonical representation of each identity in the organization. It’s a single place where, for each identity, all the attributes that matter live, with their respective sources and update timestamps.

Without this record, apps would each have to go to the original sources, which would generate chaos: every app asking the same thing, every one with its own logic for combining data when it comes from multiple places, every one with its own delay. The warehouse centralizes that logic just once.

Typical structure of a record

A master record typically has:

• Internal unique identifier (a GUID, a number, a canonicalized email): never changes, even when the other attributes change.
• Primary attributes: first name, last name, email, phone, hire date, manager.
• Derived attributes: tenure level, location, preferred language (calculated from the primary ones).
• Lifecycle state: active, suspended, terminated.
• Change history (audit log): who changed what, when, from which source.

How it stays up to date

The warehouse isn’t static. Every time the authoritative source pushes a change, the warehouse runs it through a short pipeline: the event arrives and is normalized (for example, “Maria Garcia” becomes “MARIA GARCIA”); then it’s validated (does the email have the right format? does the manager exist?); if it passes, the master record is updated and consumer apps are notified; if it doesn’t, it lands in an error queue for a human to resolve.

3. Correlation between identities and accounts

The problem correlation solves

Once an identity exists in the warehouse, the immediate question is: what real accounts in applications belong to it?. María García in the warehouse might have an account in Active Directory as mgarcia, in Salesforce as maria.garcia@company.com, in SAP as MGARCIA01, in GitHub as mgarciapro. They’re all her, but the identifiers are different in each system.

Correlation is the process that connects each master identity with its real accounts in the various applications. Without correlation, you can’t answer “all of María’s access” — only “all the accounts named mgarcia,” which isn’t the same thing.

Correlation strategies

How it looks in practice

Picture the warehouse with María (master identity EMP-08531). The correlation process walks through connected apps:

• Active Directory: finds account mgarcia with employeeID=EMP-08531. Direct match. ✓
• Salesforce: finds account maria.garcia@company.com without employeeID. Uses email to match. ✓
• SAP: finds MGARCIA01 with personnel number field 08531. Match by rule. ✓
• GitHub: finds user mgarciapro who doesn’t have a corporate email. No automatic match. Generates a case for manual review.

The result of correlation gets saved in the warehouse as an explicit map: identity EMP-08531 → accounts in N apps. From that map onward, everything is easier — searching access, certifying, deprovisioning, auditing.

Correlation confidence

Not all correlations are equally reliable. A good IGA platform assigns a score:

• High confidence (exact employeeID): 100%, automatable.
• Medium confidence (email + name): 70-90%, automatable with audit.
• Low confidence (name only): <70%, requires human validation.

This granularity matters because it’s sometimes preferable to leave an account as “uncorrelated” rather than correlate it incorrectly — a wrong correlation can grant access to the wrong person.

4. Orphan accounts: detection and reconciliation

What an orphan account is

An orphan account is an account that exists in an application but doesn’t have a corresponding master identity in the warehouse. It’s the account of someone who no longer exists (or never formally existed) in the organization but whose access remains alive.

Orphan accounts are the silent cancer of any IAM program. They’re the raw material for breaches: a former employee who took their credentials with them, a contractor whose contract ended but whose account wasn’t deactivated, a test user created by a consultant who left.

Why they accumulate

Orphans appear for predictable reasons:

• Failed manual deprovisioning: someone leaves, IT forgets to deactivate an account.
• Accounts created outside the formal flow: an admin creates them directly in the app, skipping IGA.
• Apps that connected late to the IGA program: if an app was integrated after its launch, existing accounts may not have been correlated.
• Migrations without cleanup: when a company changes platforms, all accounts are sometimes migrated without verifying which ones are valid.
• Email/employeeID changes without updating links: if the correlated attribute changes, the connection breaks.

How to detect them

The reconciliation process is the automated counterpart to correlation. Every so often (typically daily or weekly):

1. The IAM system extracts all accounts from each connected app.
2. For each account it tries to correlate it with an identity from the warehouse.
3. Those that don’t match get marked as orphan candidates.
4. A report is generated and goes to app owners or the IAM team.

Orphan candidates go through review: sometimes they’re true orphans (forgotten deprovisioning), sometimes they’re legitimate accounts that just need manual correlation (an app admin, a user who changed email).

What to do with them

5. The Joiner-Mover-Leaver (JML) cycle

What it is and why it’s the engine of operational IAM

The JML cycle is the operational version of “a person arrives → changes → leaves.” It’s the engine that executes access changes in response to lifecycle events. Without automated JML, the rest of the IAM program collapses: identities get stuck in previous states, access survives role changes, and orphans pile up. This section is the overview; the dedicated JML article opens each movement all the way up.

The three movements

flowchart LR
  accTitle: The three movements of the JML cycle
  accDescr: Three lifecycle events feed the identity warehouse. A Joiner triggers onboarding that creates accounts and roles; a Mover triggers a change that assigns new roles and retires old ones; and a Leaver triggers offboarding that deactivates accounts.
  J[Joiner<br/>new hire] --> ON[Onboarding<br/>create accounts + roles]
  M[Mover<br/>internal change] --> CHG[Change<br/>new roles + retire old]
  L[Leaver<br/>departure] --> OFF[Offboarding<br/>deactivate accounts]
  ON --> WAREHOUSE[(Identity<br/>Warehouse)]
  CHG --> WAREHOUSE
  OFF --> WAREHOUSE

Joiner (new hire)

• HRIS fires the “new employee” event before the first day.
• IGA creates an identity in the warehouse.
• By rules (based on title, department, location), IGA assigns base roles — the so-called birthright accesses.
• Workflows provision accounts in AD, email, core systems — many modern apps via the SCIM provisioning standard.
• On day one, everything works from the first click.

Mover (internal change)

This is the most underestimated, and where most programs fail. When someone changes teams, ideally:

• IGA detects the change in HRIS (new manager, new department).
• Calculates the new expected set of roles.
• Retires the old roles that no longer apply (this step is the most often skipped, generating privilege creep).
• Assigns the new roles.
• Detects SoD if the change creates conflicts.

Leaver (departure)

• HRIS fires “terminated” on a date.
• IGA deactivates the identity in the warehouse.
• Workflows deactivate accounts cascading across each app.
• Active sessions are revoked immediately.
• Email mailboxes go into retention status per policy.
• After N days, accounts get deleted (not just deactivated) per retention policy.

Edge cases that break simple JML

JML looks easy on paper but gets complicated in reality:

6. Account mapping: the glue that connects everything

Account mapping (also called account correlation) is the persistent result of the previous processes: a living table that says “identity X has accounts A, B, C in systems 1, 2, 3”.

This table is the input to practically everything else:

• Certification: when a manager certifies their team’s access, they’re reviewing this map.
• Audit reports: showing who has access to what requires the map to be consistent and complete.
• Deprovisioning: when an identity leaves, the map tells us which accounts to deactivate.
• Risk analysis: measuring an identity’s “exposure” implies summing the risk of all their accounts.

Without a reliable account map, the IAM program is blind. That’s why the previous processes (aggregation, correlation, reconciliation) exist — they all feed that map.

Integrated case: Hospital San Rafael, an ordinary week

To land everything above, let’s follow a week at a fictional regional hospital, “San Rafael,” with 1,200 employees, 350 rotating physicians, 80 contractors (cleaning, security, maintenance), and about 4,500 patients registered each year on its portal. It’s a sector where the operational complexity of IAM is among the highest: HIPAA regulation, physicians who rotate between multiple hospitals, medical devices as identities, and a mix of legacy and modern systems.

Authoritative sources at the hospital

San Rafael has three different authoritative sources, not just one:

Each source publishes events to a message bus (Apache Kafka) that the hospital’s IGA platform (SailPoint) consumes.

Monday: new physician

Dr. Pablo Méndez, cardiologist, starts working at San Rafael. He’s already credentialed at two other hospitals, but he’s new here. The process:

sequenceDiagram
  accTitle: Onboarding a new physician at Hospital San Rafael
  accDescr: At 6:00 AM the credentialing system notifies SailPoint that Dr. Méndez is active. SailPoint creates identity MD-04127 in the warehouse, applies the affiliated-cardiologist role, and provisions accounts in Active Directory, Epic, and the lab system, so that by 7:30 AM he can log in.
  participant CRED as Credentialing system
  participant IGA as SailPoint
  participant WH as Identity Warehouse
  participant AD as Active Directory
  participant EPIC as Epic (EMR)
  participant LAB as Lab system
  CRED->>IGA: Monday 6:00 AM — Dr. Méndez activated
  IGA->>WH: Creates identity MD-04127
  WH->>WH: Applies rules: role "affiliated cardiologist"
  IGA->>AD: Creates pmendez account with groups
  IGA->>EPIC: Provisions access to cardiology records
  IGA->>LAB: Provisions access to lab results
  Note over WH: Monday 7:30 AM — Dr. Méndez can log in

Reading: at 6 AM the credentialing system publishes an event to the bus. SailPoint consumes it, creates the master identity MD-04127, applies rules that give him the “affiliated cardiologist” role — a role that groups the typical access for this function at this hospital. The workflows execute cascading provisioning. At 7:30 AM, when Dr. Méndez arrives at the hospital, his badge works, his Epic login works, and he can see lab results.

Wednesday: a critical attribute changes

Mid-week, the credentialing system detects that Dr. Méndez’s license will expire in 30 days unless renewed. It publishes an event. SailPoint consumes it and triggers a workflow:

• Notifies Dr. Méndez via email.
• Notifies the credentialing department.
• Schedules an alert for day 25 if he hasn’t renewed yet.
• If day 30 arrives without renewal, automatically deactivates access to Epic and the lab (because HIPAA requires that only personnel with active license access medical records).

This is an example where the operational cycle prevents a regulatory risk without human intervention. Without that automation, we’d depend on someone remembering to verify the licenses of 350 physicians every month — humanly impossible.

Thursday: orphan account detection

The nightly reconciliation process detects an lcastillo account in Epic that doesn’t correlate with any warehouse identity. It generates a case. An IAM analyst investigates the next day:

• The account has been inactive for 11 months.
• The name matches a nurse who left San Rafael a year ago.
• Her lifecycle was closed in Workday, but due to some error the Epic account stayed active.

Immediate action: deactivate the account + forensic report to review whether there were suspicious accesses in the past 11 months. In this case there weren’t, but the audit goes into the HIPAA compliance program file.

Friday: contractor termination

The cleaning company’s contract expires on a Friday. Beeline pushes “terminated” events for 12 contractors at 18:00 — including Roberto, Marta, and Luis, all of whom had access to shift systems and reports.

At 18:01, SailPoint processes the events in cascade:

• Deactivates the 12 identities in the warehouse.
• Revokes accounts in the shift system, the security portal, the reporting system.
• Closes active sessions (one of them still had a session open on his tablet).
• Generates a report for the physical security team to collect physical badges as they exit.

By 18:15, the 12 can no longer enter anything digital. If any of them try to come back on Monday, the badge doesn’t work and the systems don’t let them in.

What the case shows

San Rafael illustrates five things any well-designed operational IAM program has:

1. Multiple coordinated authoritative sources — not one, but several depending on identity type.
2. Real-time events, not next-day batch processes.
3. Rules that run automatically (license expiration, onboarding, offboarding) without requiring manual approvals in every case.
4. Regular reconciliation that finds and resolves orphans.
5. Complete traceability so HIPAA auditors can reconstruct any event months later.

Recap

The IAM operational cycle is what turns concepts into functional reality. Its six main processes are:

Without these six processes operating well, no IAM project produces sustained value. The concepts of the previous articles are the theory; the operational cycle is the practice that sustains it day after day.

Three questions to test yourself

1. You’re tasked with diagnosing the IAM operational cycle in a company. What five questions do you ask first and why?
2. An organization says “we don’t have orphan accounts because everything is automated.” What three ways are there for that statement to be false even though they believe it’s true?
3. Design the JML flow for the case “regular employee becomes contractor on the same team.” What steps are automatic, which require human approval, and why?