Systems Access and the Account in Their Name
Access is granted by you and revoked by you, and the leaving date you act on comes from somebody else.
Direction of the work
Whether the work is any good
Equipment and systems
Whatever the agreement did not list
YoursThe provider'sCrosses the twoNeither contract
Four matters, and no share: what any one agreement covers differs by agreement. One crosses both, and the handoff is where these arrangements fail. Everything the fee did not buy stayed where it was.
Access is granted by you and revoked by you. The leaving date you act on arrives from a third party, on their timetable, and that single dependency is where access control in this arrangement goes wrong.
The control boundary in “Systems Access and the Account in Their Name” should be written before workforce technology is deployed. Organisations assessing a clearer way to assess boss vs leader for boss vs leader should define which data is collected, who can view it, how long it remains and how access is removed when a worker, manager or provider changes.
Everything else about it is ordinary joiner-mover-leaver work.
The New Zealand privacy obligations provides an external reference for the issue raised in “Systems Access and the Account in Their Name”. It is most useful when the team records which principles apply to this arrangement and which require local advice.
Why the leaving date is the problem
The person resigns to their employer. The employer tells your account manager. Your account manager tells somebody at your company. That person tells IT.
Four hops, each with its own delay:
- The person resigns to their employer.
- The employer tells your account manager.
- Your account manager tells somebody at your company.
- That person tells whoever runs access.
All for a fact that should reach your identity system the same day.
Shortening the chain
Ask the provider to notify a named mailbox at your company directly and immediately on any resignation or termination, in addition to telling your account manager.
Put it in the agreement. Most providers will agree and almost none offer it.
Asking the person to tell you too
Worth saying at the start: if you resign, please also tell me directly. Most people would anyway, and saying it removes the awkward question of whether they are allowed to.
It does not replace the provider notification. It frequently arrives first.
The same request applies in reverse: tell them you will always let them know directly if anything changes at your end, rather than letting it reach them through their employer.
Treating them as a normal identity
Same provisioning, same groups, same multi-factor requirements, same reviews. An exception here is a security exception and should be justified rather than inherited.
The commonest failure is a person set up by hand outside the standard process because the usual joiner form required an employee number.
Hand-built accounts miss the leaver automation as well as the joiner process, which is why that single shortcut produces the stale access found at the next review.
The employee number problem
Your HR system holds employees. This person is not one, so they have no record, so none of the automation that hangs off that record applies to them.
Decide early how they are represented. A contingent-worker record in the HR system, or an equivalent in the identity system, is far better than a laptop and an email address created ad hoc.
Accounts in their name
Subscriptions, cloud accounts, domains, developer accounts bought on their card or registered under their personal identity.
These accumulate and are genuinely difficult to recover. Establish at the start that anything needed by the business is bought by the business, and reimburse rather than letting them hold it.
Access reviews
Include them. The quarterly or annual review that covers your staff should cover everybody with access, however they are engaged.
This is the control that catches the person who left eight months ago and still has a seat, which happens more often here than for employees.
Offboarding in a single list
Revoke identity, remove from groups, transfer ownership of documents and repositories, forward or archive mail, reassign anything they administered, and confirm equipment.
Write the list once and use it every time. Doing it from memory on the day guarantees something is missed.
Transferring what they owned
Documents, repositories, dashboards, scheduled jobs, anything with a single owner. The transfer has to happen before access is revoked, which means somebody has to look before the last day.
A reasonable practice is to ask, a fortnight before any planned ending, what they own that nobody else can reach.
For a single person holding a whole area of work, that question is worth asking annually rather than only at the end.
Security training and policies
Your policies apply because your systems are involved, and the person should receive the same training as anybody else with the same access.
The provider does not do this and will not. Where a policy acknowledgement is required, ask the provider how to obtain one, since it cannot be imposed through an employment relationship you do not have.
When the ending is abrupt
Where somebody is dismissed, access should go immediately and the employment process belongs to the provider. Coordinate the timing so the person is not told by a locked account.
That is the same courtesy you would extend to an employee and it takes one message between you and the provider.
What no process closes
The gap between the person deciding to leave and you finding out. A resignation served to an employer in another country can sit for days before it reaches anybody who can act on it.
Technical controls are the only honest answer: least privilege, no standing access to what is not needed, logging that would show something unusual, and a short revocation list that can be run in minutes once the news arrives. The notification arrangement narrows the window and does not remove it.