· Yair Knijn
Joiner-mover-leaver when nobody owns IT
There is a company with fifty-eight employees, a controller who is also the HR lead, an office manager who used to be a project manager, and a CTO who would rather not be the person who resets passwords. The CTO is, nonetheless, the person who resets passwords, on Sunday afternoons, because there is no one else. The company is not unusual. The 60-person company is the most common regulated employer in most markets, and it is the company with the worst joiner-mover-leaver hygiene, because JML is sold as an IT-desk discipline and the 60-person company does not have an IT desk.
JML is the boring half of identity. Provisioning when someone joins, access changes when they move, and deprovisioning when they leave. The joiner is the easy one — somebody usually notices. The mover is the slow one — access accumulates. The leaver is the dangerous one — somebody forgets, and a year later the company is paying for a licence belonging to a person who has been gone for nine months, and the audit wants to know why.
The leaver who keeps a licence and a laptop
The leaver failure mode is not exotic. The person resigns on a Friday. Their last day is in two weeks. The hiring manager is busy, the controller is busy, and the laptop goes back in a box under someone's desk for a week. The Microsoft 365 account deactivates on the last day, but the Google account was on a personal recovery email and the workspace admin never knew to disable it. The licence attached to the leaver — a GitHub seat, a Figma seat, a Datadog seat — was paid for by the credit card of whoever set it up, and the auto-renewal is still ticking.
Two months later, the SOC 2 auditor asks for a list of active users. The list is the source of truth in the identity provider, and the identity provider says the account is disabled, and the auditor is satisfied. The auditor did not ask about the third-party systems, and the third-party systems still have a seat, and a billing record, and an API key issued to a person who has been gone for two months.
The mover who accumulates access
The mover is the failure mode that scales with the company. A salesperson moves from the UK team to the US team. Their UK territory's Salesforce permissions stay on, because nobody thought to take them off. Their UK travel agent's profile stays active. Their UK conference budget code stays attached, until the controller notices in the quarterly review. None of these are malicious; they are simply the path of least resistance, and the path of least resistance is also the path of least auditability.
The mover failure mode does not announce itself. The leaver failure mode does, at the point of access termination. The mover failure mode is detected only in retrospect, by an auditor asking why an employee's permissions span three teams, or by an incident where a former team member uses an old role to view a document they should not be able to see.
What a usable JML record looks like
A usable JML record is not a ticketing-system record. A ticketing system requires someone to file a ticket, and the 60-person company is the company that does not have a ticketing system. The JML record has to be produced by the workflow itself, and it has to bind three things: the people record (who, when, in what role), the account record (which identity was created, deactivated, or modified), and the asset record (which devices, licences, and seats belong to that person as of which date).
The record has to be a single object. The moment the joiner is in one system, the account is in another, and the laptop is in a spreadsheet, the audit has to reconcile them. The reconciling is what fails, and the failure is what surfaces in the audit.
How OpsDesk runs it
OpsDesk holds the people record. Each employee has a profile that carries their role, their start date, their team, and their change history. The profile is the source of truth for the joiner, mover, and leaver events; the changes are made there, and the downstream account and asset changes are driven by those changes.
For Microsoft 365, OpsDesk drives account creation and deactivation against the tenant. For Google Workspace, the integration uses domain-wide delegation, so the same workflow that creates the M365 account creates the Google account and assigns the right set of groups, and the same workflow that deactivates one deactivates the other. Mover events are a profile change plus a workflow; the old account does not keep its old groups because no one thought to remove them — the workflow removes them.
Devices and licences are tracked as a register per employee, not as a register per system. The same record that says "this person is in this role" says "this person has this laptop and these seats". A leaver event closes the person record, returns the devices to the register, and releases the seats. The audit trail is per-person, from the request that started the change through the account and asset changes that resulted, with timestamps and approvers.
What OpsDesk does not do is replace the people decisions. The role and the team and the date are inputs from the company; the platform is the record and the workflow. The platform closes the failure modes that the 60-person company is not staffed to close on its own; the staffing, such as it is, still has to make the call.