The operational IAM cycle

An account nobody missed

On a Thursday morning, Sara, an IAM analyst at a regional hospital, opens the overnight reconciliation report and finds an account called lcastillo in the clinical records system. It doesn’t belong to anyone in the identity master record. It hasn’t been used in eleven months. The name matches a nurse who left the hospital a year ago; HR closed her record on time, but somewhere between HR and the clinical system the change got lost, and the account stayed active the whole time. Nobody missed it, and that’s exactly the problem.

The previous articles built the concepts: what a digital identity is, the four modern kinds, how IAM fits into cybersecurity, the four historical waves and the five domains. If you know all of that but have never seen it running, you’re missing the most important part.

Concepts don’t float in the air. They live inside machinery that runs every day without stopping. Every time someone joins, changes team or has a contract renewed, every time a customer deletes their account, an IAM process runs in the background. When that machinery is well oiled, nobody notices. When it’s broken, the symptoms appear: orphan accounts like lcastillo, access that outlives a departure, certification campaigns that arrive half empty, failed audits.

This article opens the IAM in action module by looking inside that machinery. It walks through the core processes, aggregation, the master record, correlation, reconciliation, JML and the account map, and then follows them through a week at a hospital, where the day-to-day complexity of IAM is about as high as it gets. If you join an IAM project as an engineer or analyst, your first question should be “what’s the authoritative source for identities here?”. If the answer is vague, or several people give you different answers, you already have your diagnosis: the cycle is broken at the root.

The cycle at a glance

The operational IAM cycle runs six processes continuously: aggregation from authoritative sources, building the master record, correlating identities with accounts, reconciling orphans, the joiner-mover-leaver lifecycle and the account map. It’s a loop, not a line, because the output of each process feeds the next.

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

Authoritative sources feed aggregation, which produces the master record of identities. That record is linked to the real accounts in each application through correlation. The applications report their accounts back, and reconciliation finds the mismatches, orphans and unclaimed accounts, which go back to the warehouse. On top of the warehouse run the JML workflows, which trigger changes in the applications. What goes out on one side comes back on the other.

Aggregation from authoritative sources

An authoritative source is the system that holds the true version of an attribute. If you want María’s legal name, you ask the HR system, not Salesforce. Her current phone number, also HR. Which badges she’s been issued, probably the IT service management tool. Every attribute has one source that’s the authority on it.

This matters because without a declared authority, attributes are in limbo. If the directory says extension 4521 and SAP says 4530, which is right? Without an authority, neither, and data you can’t trust is useless for making decisions.

Different kinds of identity come from different sources. Employees come from an HR system such as Workday, BambooHR or SAP SuccessFactors, which owns their name, title, manager, department and start and end dates. External contractors come from a contractor-management system such as Beeline or Fieldglass, which owns the supplier and the contract end date. Customers come from a CRM such as Salesforce or Dynamics. Devices and workloads come from a CMDB such as ServiceNow, with the hostname, owner and location. And in a hospital, doctors come from a medical credentialing system that knows their license, specialty and affiliated hospitals.

Data moves from the source to IAM in two basic ways. With pull, the IAM system queries the source on a schedule, every fifteen minutes, every hour or every night. It’s simple but adds delay: someone whose contract starts at 5:55 might make the six o’clock query or might not appear until tomorrow. With push, the source tells the IAM system when something changes, through a webhook or a message queue. It’s harder to build but brings the delay down to seconds.

The usual problems are predictable. Data quality: if HR types names with mistakes or inconsistent emails, those errors spread to everything downstream. Delay between sources: the HR system may take a day to show a new hire while their manager already wants them in the systems, and the pressure to “skip the process” is enormous. Two authorities for one field: is HR or Active Directory the authority on email? Unless someone decides explicitly, the two fight in silence. And gaps in the source: HR may not know which security group a new hire needs, so they get default values that nobody ever corrects. Deciding and documenting the authoritative sources is one of the most strategic decisions in any IAM program. Doing it on day one saves years of arguments; putting it off means every new project renegotiates the same thing.

The master record

The master identity record, or identity warehouse, is the single canonical version of each identity in the organization: one place where, for each identity, all the attributes that matter live together, with their sources and when they were last updated. Without it, every application would have to go to the original sources itself, each asking the same questions, each with its own logic for combining data from several places and each with its own delay. The warehouse does that work once.

A master record usually has an internal unique identifier, a GUID, a number or a normalized email, that never changes even when everything else does; primary attributes such as name, email, phone, start date and manager; derived attributes such as seniority, location or preferred language, calculated from the primary ones; a lifecycle state, active, suspended or terminated; and a history of who changed what, when and from which source.

It isn’t static. Every time a source pushes a change, the warehouse runs it through a short pipeline. The event arrives and is normalized, so “Maria Garcia” becomes “MARIA GARCIA”. Then it’s validated: is the email well formed, does the manager exist? If it passes, the record is updated and the applications that depend on it are told. If it doesn’t, it lands in an error queue for a person to sort out. The warehouse doesn’t have to be a special database, either. Many organizations keep it inside their IGA platform, which SailPoint and Saviynt call an “identity cube” or “identity profile”. The idea is the same: one source of truth for each identity.

Correlating identities and accounts

Once an identity is in the warehouse, the next question is which real accounts in which applications belong to it? María García in the warehouse might be mgarcia in Active Directory, maria.garcia@company.com in Salesforce, MGARCIA01 in SAP and mgarciapro in GitHub. All of them are her, with a different identifier in each system. Correlation links each master identity to its real accounts. Without it you can’t answer “show me all of María’s access”, only “show me every account called mgarcia”, which isn’t the same thing.

There are several ways to correlate. By email, assuming it’s the same everywhere, which works for modern SaaS applications that use single sign-on with email. By employee ID, when HR’s identifier was sent along with the original provisioning and is present in each application. By name plus another unique attribute, such as date of birth, for legacy applications with no corporate identifier. By hand, an analyst matching accounts one at a time, for very mixed applications and special cases. And by rules with a confidence score, combining several signals, for large volumes of imperfect data.

Picture the warehouse with María, master identity EMP-08531, and the correlation process walking through the connected applications. In Active Directory it finds mgarcia with employeeID=EMP-08531, a direct match. In Salesforce it finds maria.garcia@company.com with no employee ID and matches on email. In SAP it finds MGARCIA01 with a personnel number of 08531 and matches by rule. In GitHub it finds mgarciapro with no corporate email at all, so there’s no automatic match and a case opens for manual review. The result is saved in the warehouse as an explicit map, identity EMP-08531 to accounts in each application, and from then on searching access, certifying, removing access and auditing all get easier.

Not every correlation is equally reliable, and a good IGA platform scores them. An exact employee ID is high confidence and can be automated. Email plus name is medium confidence, somewhere between 70 and 90%, and can be automated with an audit trail. Name alone is below 70% and needs a person to confirm it. That matters because sometimes it’s better to leave an account uncorrelated than to correlate it wrongly; a wrong match can hand access to the wrong person.

Orphan accounts

An orphan account is an account that exists in an application but has no matching identity in the warehouse. It belongs to someone who no longer exists in the organization, or who never formally did, and its access is still alive. Orphan accounts are the quiet rot of any IAM program and the raw material for breaches: a former employee who took their password with them, a contractor whose contract ended but whose account wasn’t disabled, a test user a consultant created before leaving.

They appear for predictable reasons. Someone leaves and IT forgets one account. An admin creates an account directly in an application, bypassing IGA. An application joined the IGA program after it went live, and its existing accounts were never correlated. A platform migration moved every account across without checking which were still valid. Or an email or employee ID changed and the link that depended on it broke. lcastillo was one of those.

Reconciliation is the automated counterpart to correlation. Every day or every week, the IAM system pulls every account from each connected application, tries to match each one to an identity in the warehouse and marks the ones that don’t match as orphan candidates, which go in a report to the application owners or the IAM team. Some candidates are real orphans, forgotten when someone left. Others are legitimate accounts that just need a manual match, an application’s own admin or a user who changed email.

What happens next depends on the kind of orphan. A former employee’s account is disabled straight away, and someone looks into what it did after they left. A contractor’s account is disabled and the supplier’s contract terms are checked. A service account with no owner is either given one formally or disabled. A test or demo account is documented or deleted. And a valid account that simply wasn’t correlated is matched by hand and linked to the warehouse. Regulations such as HIPAA, SOX and PCI DSS, and control frameworks such as NIST SP 800-53 with its account management control AC-2, explicitly require finding and removing orphan accounts on a regular basis. Not having a documented reconciliation process is close to a guaranteed audit finding.

Joiners, movers and leavers

The JML cycle is the working version of “someone arrives, changes, leaves”. It’s the engine that changes access in response to lifecycle events, and without it automated the rest of the program falls apart: identities get stuck in old states, access survives role changes and orphans pile up. This is the overview; the JML article opens each step fully.

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

For a joiner, the HR system fires a “new employee” event before the first day. IGA creates the identity in the warehouse and, using rules based on title, department and location, assigns the basic roles, the so-called birthright access. Workflows then create accounts in the directory, email and core systems, many of them through the SCIM provisioning standard, so everything works from the first click on day one.

The mover is the most underestimated step and the one where most programs fail. When someone changes team, IGA should notice the change in HR, a new manager or department, work out the new set of roles, remove the old roles that no longer apply, add the new ones and check whether the change creates a separation-of-duties conflict. The removal is the step most often skipped, and it’s where privilege creep comes from.

For a leaver, HR marks the person as terminated on a given date. IGA disables the identity in the warehouse, workflows disable their accounts in every application, active sessions are revoked immediately, the mailbox goes into retention according to policy, and after a set number of days the accounts are deleted, not just disabled.

JML looks easy on paper and gets complicated quickly. What happens when an employee becomes a contractor on the same team: remove everything and grant contractor roles, and how do you coordinate the two? When someone is rehired after a few months, do you reuse their old identity or create a new one? During long medical leave, which access stays? When someone moves country, do local rules demand something different? How do you handle seasonal staff joining and leaving in bulk every year? And for an urgent dismissal, how do you disable everything in minutes without waiting for the nightly run? IGA platforms handle the simple cases, a normal joiner, a planned leaver, well. The quality of a program shows in these edge cases, and a program that collapses at the first one is badly designed.

The account map

The account map is the lasting result of everything above: a living table that says “identity X has accounts A, B and C in systems 1, 2 and 3”. Almost everything else feeds on it. When a manager certifies their team’s access, they’re reviewing this map. Audit reports showing who has access to what need it to be complete and consistent. When someone leaves, the map says which accounts to disable. And measuring an identity’s exposure means adding up the risk of all its accounts. Without a reliable map, the IAM program is blind, which is why aggregation, correlation and reconciliation exist: they all feed it.

A week at San Rafael hospital

To see it all working, follow a week at San Rafael, a fictional regional hospital with 1,200 employees, 350 doctors who rotate between hospitals, 80 contractors for cleaning, security and maintenance, and about 4,500 patients signing up each year on its portal. It’s a sector where operational IAM is about as complex as it gets: HIPAA, doctors working across several hospitals, medical devices as identities and a mix of old and new systems.

San Rafael has three authoritative sources, not one. Administrative staff come from Workday, with their name, department, manager and start date. Doctors and nurses come from a custom-built medical credentialing system, with their license, specialty, license expiry and affiliated hospitals. Contractors come from Beeline, with the supplier, the contract, its end date and their access level. Each source publishes events to a message bus, Apache Kafka, which the hospital’s IGA platform, SailPoint, reads.

On Monday, Dr. Pablo Méndez, a cardiologist, starts at San Rafael. He’s already credentialed at two other hospitals but is new here.

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
  participant IGA as SailPoint
  participant WH as Warehouse
  participant AD as AD
  participant EPIC as Epic (EMR)
  participant LAB as Lab system
  CRED->>IGA: Monday 6:00, 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: Grants access to cardiology records
  IGA->>LAB: Grants access to lab results
  IGA->>IGA: Monday 7:30, Dr. Méndez can sign in

At six in the morning the credentialing system publishes an event. SailPoint reads it, creates the master identity MD-04127 and applies rules that give him the “affiliated cardiologist” role, which bundles the usual access for that job at this hospital. The workflows provision everything in cascade, and when Dr. Méndez arrives at half past seven, his badge works, he can sign into Epic and he can see lab results.

On Wednesday, the credentialing system notices that Dr. Méndez’s license expires in thirty days unless he renews it, and publishes an event. SailPoint starts a workflow: it emails Dr. Méndez, tells the credentialing department, schedules a reminder for day 25 if he hasn’t renewed, and if day 30 arrives without a renewal it automatically removes his access to Epic and the lab, because HIPAA only allows staff with an active license to see medical records. The cycle prevents a regulatory risk without anyone lifting a finger. Without that automation, someone would have to check 350 doctors’ licenses every month, which simply wouldn’t happen.

On Thursday, Sara finds lcastillo, the account from the start of this article. She investigates: it’s been inactive for eleven months, the name matches a nurse who left a year ago, and her record was closed in Workday, but an error left the Epic account active. Sara disables it and asks for a forensic review of any access in those eleven months. There wasn’t any, but the review goes into the hospital’s HIPAA compliance file.

On Friday, the cleaning company’s contract ends. At six in the evening Beeline sends “terminated” events for twelve contractors, including Roberto, Marta and Luis, who all had access to the shift system and reports. At 18:01 SailPoint processes them in cascade: it disables the twelve identities in the warehouse, removes their accounts in the shift system, the security portal and the reporting system, closes their active sessions, one of which was still open on a tablet, and sends the physical security team a list so they can collect the badges at the exit. By 18:15 none of the twelve can get into anything digital, and if any of them comes back on Monday, neither the badge nor the systems will let them in.

San Rafael shows what a well-designed operational program has: several coordinated authoritative sources, one per kind of identity; events in real time rather than next-day batches; rules that run automatically for license expiry, joiners and leavers without a manual approval every time; regular reconciliation that finds and clears orphans; and a complete trail that lets HIPAA auditors rebuild any event months later.

Recap

The operational cycle is what turns concepts into something that works. Aggregation answers where the true data about identities comes from. The master record answers what the single, canonical version of each identity is. Correlation answers which real accounts belong to each identity. Reconciliation answers which accounts live on without a formal owner. JML answers how lifecycle changes reach access. And the account map answers who has what, in full. Without those six running well, no IAM project delivers lasting value. The earlier articles were the theory; this cycle is the practice that holds it up every day, and the one that, at San Rafael, turned a forgotten account into a Thursday-morning ticket rather than a breach.

Three questions to test yourself

1. You’re asked to diagnose a company’s operational IAM cycle. Which five questions do you ask first, and why?
2. An organization says “we have no orphan accounts because everything is automated.” Give three ways that statement could be false even though they believe it.
3. Design the JML flow for “an employee becomes a contractor on the same team.” Which steps are automatic, which need a human approval, and why?