When Someone Leaves Your Company, What Can They Still Access?

SSO makes sign-in easier to manage. Good offboarding also checks application accounts, sessions and credentials, with practical evidence for your ISO 27001 programme.

The laptop is back. The company account is disabled. The offboarding ticket is closed. But could your former colleague still open the project board in an existing browser session? What about a separate cloud account or an API token created months ago?

For companies using many online tools, an employee's last working day is a useful test of access management. The same applies when a contractor's assignment ends. You need to know which access should stop, when it should stop, and how you confirm the result.

SSO helps, but it is only part of offboarding

Single sign-on (SSO) lets people use a central company identity to sign in to connected applications. Disabling that identity helps stop new sign-ins through that route. It also gives you a much better starting point than managing a separate password for every tool.

However, an application may maintain its own session after sign-in. As NIST's federation guidance explains, ending the identity provider's session does not necessarily end the application's session. Some integrations support coordinated revocation, but you need to check what yours actually does.

Direct logins, guest accounts and personal API tokens can create other access routes. A failed SSO login alone does not prove that all of them have been closed.

SCIM connects the account lifecycle

SCIM (System for Cross-domain Identity Management) lets an identity system create, update and deactivate accounts in supported applications. With a correctly configured connection, a departure can trigger account changes across those tools instead of leaving every application owner to act manually.

That is a different job from SSO. Connecting an application for sign-in does not automatically mean its accounts are managed through SCIM.

SCIM still needs checking. Did the change reach the application? Was the right account covered? Does deactivation end existing sessions and revoke personal tokens? The SCIM standard leaves the precise meaning of an account's active status to the service provider. Verify the integration's behaviour rather than assuming every service responds identically.

Know your vendors before you need to remove access

Not every application supports SSO or SCIM, and support does not mean an integration is enabled. Include sign-in and account-removal requirements when choosing vendors, but plan for risk-assessed exceptions. A tool without these integrations still needs a reliable offboarding process.

Keep an up-to-date vendor and application register as part of supplier management. For each tool, record its owner, how people actually sign in (SSO, direct accounts or both), and whether SCIM is available, enabled and tested. Link to the current user-access list and the steps for removing accounts, sessions and credentials, including any API or manual actions.

For exceptions, document the risk, agreed safeguards and a review date. Give removal steps an owner and a completion check. Test that an authorised colleague can perform them without the departing employee. During an urgent departure or account compromise, you should be following a known plan, not discovering which vendors hold access.

A practical offboarding checklist

Keep the process short enough to use. The NCSC's SaaS guidance is a useful starting point for managing staff access, automation and exceptions.

• Agree the cutoff. HR, the manager and IT should know when access ends and who coordinates the work, including for contractors.
• Check the actual tools. Start with your vendor and application register, then check for unlisted tools. Cover email, files, code repositories, cloud infrastructure and business applications, including guest and direct-login accounts.
• Close the remaining routes. Confirm account deactivation, end sessions where supported, revoke personal credentials and rotate shared secrets the person could still use. Track anything that needs separate action.
• Transfer ownership. Reassign documents, integrations and service accounts. Check their credentials separately so removing a person does not unexpectedly stop a business process. Recover company devices and handle retained data under your policies.
• Record the result. Keep the completion time, application-level checks and any exception with an owner and follow-up date. A submitted request is not the same as confirmed removal.

The ISO 27001 connection: show that the process works

ISO/IEC 27001 provides a framework for managing information security according to your organisation's risks. Offboarding makes that practical: access rights should follow the person's responsibilities, and your process should leave evidence of the change.

This connects supplier management with access management. Vendor requirements, known limitations and agreed exceptions should inform the offboarding plan. The register above is a practical way to make that connection, not an ISO-prescribed template.

For an internal audit, sample a completed departure. Can you connect the agreed leaving time to the applications checked, actions completed and exceptions followed up? This is more useful than showing that an offboarding policy exists. Neither SSO nor SCIM alone establishes ISO 27001 conformity, and the standard does not prescribe one identity product.

Try one small test

Use a dedicated test account in a representative application. Start a browser session, then run your offboarding process. Check a fresh sign-in, the existing session and, where relevant, a test API token. Confirm the account status in the application too.

Record what stopped, what remained available and for how long. Use that result to improve the checklist before a real departure. The goal is simple: know that access has ended, rather than assuming one disabled account took care of everything.

Keep access under review

ISO 27001's access-rights control also covers reviewing access. Make this a periodic activity, with a schedule based on risk and additional checks when responsibilities change. Use the vendor register to confirm that accounts, permissions, API tokens and SSH keys still have an owner and a valid purpose.

Alongside that review, check whether SCIM remains enabled and processes changes successfully. Inspect provisioning errors and verify that failed removals are resolved. Record the checks, follow-up actions and who owns them. Known removal failures need prompt attention, not a wait until the next scheduled review.

Need help checking how this works across your company? Coding Mammoth helps teams build practical ISO 27001 processes and test them through internal audits.