Why do manual joiner-mover-leaver processes distort productivity reporting?

Why manual JML reporting looks productive when the work is still unfinished

Manual joiner-mover-leaver reporting optimises for visible activity, not for completed control outcomes. A queue can move quickly even while the underlying access state remains wrong, because every approval, rekey, entitlement change, and offboarding step is handled as a separate human task. That makes “tickets closed” a poor proxy for actual governance progress.

In practice, this is a measurement problem as much as an operations problem. The reporting layer usually counts workflow events, while the real security work is embedded in exception handling, cross-team follow-up, and cleanup after delays. The result is a productivity narrative that rewards motion, not closure of the access-change loop.

Manual handling also inflates apparent output when teams spend time reconciling stale records, duplicate requests, and mismatched ownership. The same person can appear busy across HR, IT, security, and application support, even though no single system has reached a trustworthy state. That is why JML metrics built from ticket throughput alone tend to overstate delivery value and understate control debt.

Where manual JML metrics distort throughput and value reporting

The distortion comes from confusing process volume with business impact. A large number of onboarding or access-change tickets may simply reflect fragmented administration, repeated approvals, or poorly integrated provisioning paths. If each mover event requires manual role cleanup, the reporting can show high productivity while the organisation quietly accumulates access creep and delayed deprovisioning.

This is why JML reporting should distinguish between activity and effect. Activity metrics include tickets opened, approvals completed, and time in queue. Effect metrics include time to correct access, stale-access exposure, entitlements removed on schedule, and the share of changes completed through authoritative provisioning paths. For a useful internal benchmark, the Joiner-Mover-Leaver Guide frames JML as a lifecycle control, not a workload counter.

Manual processes also obscure the hidden cost of governance. A team may be “productive” by closing requests, but the real work may have shifted to escalation handling, access recertification, and post-hoc remediation. That is especially true where entitlement changes depend on human approval chains rather than authoritative identity data. IAM and IGA Basics is useful here because it separates access administration from governance outcomes such as least privilege, entitlement review, and identity lifecycle control.

When organisations still rely on spreadsheets, inboxes, and manual exceptions, reporting can also miss the long tail of leaver activity. Closed tickets do not prove revoked access if tokens, keys, shared accounts, or application-side permissions remain live. A good lifecycle view must include the lag between employment status change and actual access removal, not just the administrative completion of the request.

What better JML measurement should capture instead

Better reporting measures whether the identity state changed, not whether a ticket was touched. That means pairing operational metrics with control metrics that reflect completed provisioning, clean mover transitions, and verifiable offboarding. In other words, the question is not “How many requests did we process?” but “How many access states were actually corrected, and how quickly?”

For practitioners, the most useful signals are the ones that expose governance cost directly: time to deactivate, number of stale entitlements after role change, percentage of changes executed automatically from an authoritative source, and exceptions still awaiting cleanup. If those measures are poor, a fast ticket desk is not evidence of efficient JML, it is evidence that the control is still absorbing manual friction. The SCIM and Automated Provisioning Guide is relevant because automation only improves productivity reporting when provisioning and deprovisioning are actually tied to source-of-truth events.

Governance reporting should also separate normal workflow from exception handling. Manual approvals may be acceptable for edge cases, but if most JML volume lives outside automation, productivity dashboards will keep reflecting effort rather than control maturity. The better test is whether the organisation can prove that access changes happen with minimal delay, minimal rework, and minimal stale exposure.

Risk and Threat Considerations

Manual JML processes create a hidden security exposure because delayed offboarding, over-provisioned movers, and inconsistent cleanup leave access alive after the business state has changed. That can skew productivity reporting and also increase the window in which stale permissions, dormant accounts, or unrevoked credentials can be abused.

Failure mechanism: Work is counted when requests move through humans, but access remains effective until every downstream system, token, and entitlement is updated. Exceptions, handoffs, and rework extend exposure while making the process look busy and efficient.

Impact: Reporting becomes misleading, governance debt accumulates, and the organisation can retain unnecessary access longer than intended. In the worst case, a leaver or moved user keeps enough access to cause data exposure, privilege creep, or delayed containment after an internal or external compromise.

Practitioner Guidance

What to prioritise: Separate workflow productivity from access-outcome productivity. If your dashboard only shows tickets closed or average handling time, it is measuring administration, not JML effectiveness.

What to verify: For a sample of joiners, movers, and leavers, confirm that the authoritative identity record, target-system entitlements, and any credentials or tokens all changed within the expected service window. If they did not, the apparent throughput number is overstated.

What good looks like: Most routine JML actions are event-driven, exceptions are rare and visible, and stale access is measured as an operational defect rather than buried inside general ticket volume.

Practitioner takeaway: The best JML reporting proves that access state changed, not just that work moved through a queue, because only the former reflects real governance value.

Related resources from NHI Mgmt Group

• What do teams get wrong about quarterly access reviews and manual joiner mover leaver processes?
• Why do service accounts and API keys complicate joiner-mover-leaver processes?
• What breaks when joiner-mover-leaver workflows are mostly manual?
• What breaks when joiner, mover, leaver processes are handled differently for technical accounts?