01

Connect access to a purpose and sponsor

Supplier access should begin with a named internal sponsor, defined service, approved systems, expected actions and end date. Contract language sets expectations, but technical access still needs an identity, policy and accountable owner. Avoid shared supplier accounts that make investigation and revocation ambiguous.

Classify the consequence of the access. A support engineer who can view a test dashboard differs from a provider that can administer identity, production infrastructure or backups. Higher-impact access should require stronger authentication, managed devices or controlled entry points, and narrower operating windows.

02

Constrain the path and observe its use

Prefer individual federated identities or dedicated accounts with least privilege and automatic expiry. Route privileged work through approved administration paths, separate it from ordinary collaboration and prevent direct public management interfaces where feasible. Tokens and application integrations need the same ownership and expiry as human accounts.

Record sign-in, elevation, connection and material changes in a location the supplier cannot alter. Alert on activity outside approved windows, new access paths and disabled safeguards. Monitoring should support timely decisions, not merely satisfy a contractual checkbox.

03

Review change and prove removal

Reconfirm access when the supplier team, scope, contract or internal sponsor changes. High-impact access needs more frequent review than a low-risk guest account. Treat unanswered review requests as a reason to suspend access rather than silent approval.

At termination, remove accounts, groups, certificates, API tokens, remote agents, firewall rules and delegated permissions. Validate from the target systems because disabling one identity may leave alternate paths. Preserve evidence of removal and record any retained data or transition dependency.

Practical checklist

What to do next.

  • ✓Name an internal sponsor and expiry for every supplier.
  • ✓Use individual identities and least privilege.
  • ✓Constrain privileged work to approved paths and times.
  • ✓Monitor sessions and security-reducing changes.
  • ✓Review after scope, staff or contract changes.
  • ✓Verify removal across identities, agents, tokens and network rules.

Use guidance responsibly

Technology, provider behaviour and legal requirements change. Validate implementation details against current official documentation, test changes safely and obtain qualified legal advice where required.