The project is over. Can the supplier still get in?

At the end of a project, teams check that the system has been delivered, outstanding issues are documented, and support arrangements are in place. Add one more question to that handover: which supplier access remains active, and why is it still needed?

Access granted during implementation can outlive the work. A guest account, cloud administrator role, remote connection, or API key does not necessarily expire when the final invoice is approved. Closing it requires coordination between the people who know the project has ended and the people who manage access to each system.

The aim is to remove access that is no longer needed and define any access required for ongoing service. That can happen without disrupting support, provided someone checks the dependencies first.

Give someone responsibility for the handover

The project manager knows delivery is complete. Procurement knows when the agreement ends. IT knows which accounts it created. Those facts need to reach someone responsible for checking that access has been addressed.

Name an internal owner for supplier offboarding. That person need not make every technical change. They should coordinate with system owners, track completion, and make sure any continuing access has an approval. Even when the supplier administers part of the environment, the organization needs its own decision-maker.

Agree what starts the process: final delivery, contract termination, a replacement supplier, or an individual leaving the supplier's team. A date in a contract is useful, but it needs a route to the people who can act on it.

Look beyond the user directory

The central identity directory is a useful starting point. Compare it with system owners' records, because supplier access can exist in several places:

• Named supplier users and guest accounts.
• Administrator roles, access groups, and local application accounts.
• VPN connections and remote support tools.
• API keys, service accounts, and system integrations.
• File shares, source repositories, and test environments used during the project.

For each entry, establish which system it reaches, who uses it, what it allows, and who approves it. Pay particular attention to service accounts supporting an ongoing business process. Before disabling one, understand its dependencies and arrange an appropriate transfer of ownership or replacement access.

CIS Control 5 on account management covers user, administrator, and service accounts. A review limited to the supplier's employees can miss access used by software or integrations.

Make continued support a defined exception

There may be a sound reason to retain access after delivery. Warranty work, an unresolved fault, or a maintenance agreement can all require further involvement. The permissions should fit the work that remains.

Record the business need, approver, systems covered, and next review date. Broad administrator access required during implementation may be unnecessary for routine support. Where practical, use time-limited access or require approval before enabling it for a particular task.

If there is no fixed end date, assign a review date and someone who must make the decision. “Keep it in case we need it” leaves too much unresolved. An approved, limited arrangement lets support continue while making the access understandable to the next person reviewing it.

Check the result in the systems

A closed ticket does not establish that every access route has been addressed. Check the systems in scope and retain a record appropriate to the change, such as the disabled account status, revised permissions, revoked key, or removal of a remote connection.

Understand how the platform handles existing sessions. Disabling a central account may not immediately terminate every application session. Microsoft's access-revocation guidance explains that token behavior varies and applications may control their own sessions. Include those sessions and any direct application accounts in the review.

Keys and other secrets need separate attention. Revoke those that are no longer required. If a service must continue and the departing supplier knew a secret it uses, plan a controlled replacement or transition that protects service continuity. OWASP's secrets-management guidance treats rotation, revocation, and expiration as distinct parts of the lifecycle. Changing one password will not automatically cover them all.

Leave a record someone else can verify

Keep a concise closure record showing which access was reviewed, what changed, when it changed, and who verified it. Link to supporting evidence and record approved exceptions with an owner and review date. Do not put passwords or secret values in the closure document.

Address information and assets held by the supplier separately. Establish which files, copies, and project documentation were transferred, and what was agreed about their return, retention, or deletion. Follow the agreement and applicable organizational requirements. Revoking an account does not remove information already copied outside the system.

Plan the exit when the project begins

This work is easier when access, responsibilities, and exit conditions are recorded at the start. NIST CSF 2.0, outcome GV.SC-10, specifically addresses planning for activities after a supplier relationship ends. It is a useful reference when designing the process, without assuming that every framework applies to every organization.

Start with one recently completed project. Can you account for all the access it left behind? An incomplete list or unclear ownership gives you a specific improvement to make.

Questions at the end of an engagement

Must all supplier access end immediately?

Remove access that is no longer needed. Retain necessary support access only with approval, a defined scope, and a review date. Check operational dependencies before making changes.

What should the closure record contain?

The access reviewed, changes made, completion and verification dates, and supporting evidence. List retained access as an approved exception with an owner and review date.

Through an agreed CISO as a Service engagement, Cybecs can review the process, help define responsibilities and controls, and assess the evidence of access removal. Authorized internal teams or the IT provider make the technical changes. Contact us if you would like to work out where to begin.