Contractors, Vendors and Third Parties

Employee departures are announced by HR. Contractor departures are announced by nobody, and the access remains.

Why the process does not reach them

They are not in the HR system, so the trigger that starts offboarding does not fire.

Their end date is in a contract that IT never saw.

Their engagement is extended informally, so the recorded end date passes without meaning anything.

They are engaged by a team rather than by a central function.

Multiple parties are involved — an agency, a consultancy, the individual — and none is accountable for access.

What to require at engagement

An end date, recorded, in whatever system triggers your access processes.

A sponsor: a named employee accountable for the engagement.

Defined access, granted for the work rather than by role bundle.

Their own account, never a shared one and never an employee's credentials.

Identifiable accounts. A naming convention or an attribute that lets you list all third-party accounts in seconds.

That last point is the one that makes everything else possible, and it costs nothing at creation and cannot be retrofitted easily.

Managing the end date

Set access to expire on the contract end date, automatically, where your identity platform supports it.

Extension requires action, which converts silent drift into a deliberate decision.

Notify the sponsor before expiry, so extensions happen deliberately rather than through an outage.

Where automatic expiry is unavailable, a monthly report of third-party accounts past their recorded end date is the fallback, and it should be short.

Vendor access

Distinct from contractors and frequently worse.

Support access granted during an implementation and never revoked.

Integration accounts belonging to a vendor's platform.

Administrator access granted to a consultancy, covered in its own note.

Audit for external domains across your applications, quarterly. Every account with an email domain you do not own is a question.

Time-box vendor access and require a request for renewal.

Their devices

Contractors frequently use their own equipment, which changes the data position entirely.

Decide the position explicitly: company device issued, or personal device with defined restrictions, or no local data at all with browser-only access.

Document what was agreed, because at the end of the engagement you have no recovery route for a personal device and the only control was whatever you set at the start.

Prefer browser-only access with no local storage for short engagements. It is the only arrangement where the end of the engagement is clean.

The register fields

Account type: employee, contractor, vendor, service.

Sponsor.

Engagement end date.

Reviewed date.

These four fields, populated, turn third-party access from an invisible category into a report.

The quarterly review

List every non-employee account.

Confirm each is still needed, with the sponsor.

Remove the ones that are not.

Check for accounts past their end date, which should be none.

This review reliably finds accounts from engagements that ended a year ago, in almost every organisation running it for the first time.

The browser-only arrangement

For short engagements, the cleanest position is one where the contractor never holds company data locally.

Access through a browser, with no local application installation.

Download and copy restrictions where your platforms support them.

No email client configuration, so no local mailbox copy.

Session policies limiting access to defined hours or locations where appropriate.

No device to recover at the end, which removes the largest practical problem.

Less convenient than a full setup, and appropriate for a three-month engagement. For longer ones, issue a managed device instead — the arrangement should follow the duration rather than being decided once for all third parties.

The identifiable account convention

The one decision at account creation that makes every subsequent third-party control possible.

A naming convention, a directory attribute, or a separate organisational unit — any of the three works.

Applied at creation, because it cannot be retrofitted reliably.

It enables: listing all third-party access in seconds, applying different session and device policies, setting expiry by default, and auditing separately.

It also makes the quarterly review possible, which is otherwise a manual trawl through user lists guessing at who is internal.

Agree it once with whoever creates accounts, and enforce it at the identity platform rather than by policy.