Ending a contract does not automatically remove every digital access. Before you close the work, list the accounts, permissions and integrations involved, keep control of how each one is recovered, and agree what gets revoked. Do it as a tested handover: removing a connection without knowing what it does can stop an operation you still need.
The contract ends on Friday. On Monday someone new starts, and nobody remembers which account connected the contact form to the calendar. The conversation about access usually comes late, when a notification goes missing or someone stumbles on a shared folder. A proper close-out is an operational handover, not just handing over files.
What does it really mean to close an access?
There are several doors. One person may have a CRM user, an invitation to a folder, a session on the hosting account and an app authorised to read your calendar. They are different relationships, even if all of them were created during the same project. You should not treat them as a single password that needs changing.
Google distinguishes between signing in with your account, linking accounts and allowing an app to access data. Its account page lets you review each type of connection. That distinction is useful for asking what you actually authorised, without assuming that every sign-in button grants the same permissions. Google, managing linked apps, accessed on 12 October 2026.
Imagine a sports equipment shop that changes agency. The agency ran campaigns, prepared content and maintained an order integration. Removing its access to the website editor may be simple; removing the order connection requires knowing who replaces it. Continuity and revocation are prepared together, so nobody leaves an access open indefinitely for fear of breaking something.
The goal of the close-out is to answer two questions: who can get in now, and who maintains each dependency. It does not assume any wrongdoing by the supplier. A working relationship can end on good terms and still leave accounts with no clear owner. Documenting that state helps both sides define what was delivered.
What inventory do you need before changing anything?
Start with the business services, not with people's names. For each one, identify the owner account, the invited users and the relevant connections. Include the domain, hosting, forms, shop, email and the working tools involved in the project. Do not put passwords in the inventory.
A short record can capture these details:
- The service and its purpose in the process.
- The person or role that controls the main account.
- The access granted to the supplier and its known scope.
- The integrations that use that access.
- The close-out action, who is responsible and how it will be checked.
Describe the scope with concrete verbs: view, edit, administer, publish or invoice. "Has access" is too vague to decide what to remove. If you do not know a permission, mark it as pending review. A visible doubt is better than a box ticked on instinct that later hides a dependency.
In the shop example, an account might belong to the business but have an agency address as its recovery email. Another might belong directly to the supplier. Those situations need different answers. Do not assume that paying the service invoice proves you can recover the account or transfer all its resources.
Ask the supplier to fill in the pieces they know and keep a dated copy. Include services bought outside the project's scope too. A useful list should not look exhaustive when it leaves out what nobody reviewed. Stating that limit lets you decide whether someone else is needed to complete the handover.
How do you move control without stopping the work?
Separate preparation, change and checking. First identify what must end up under the business's control and confirm that a suitable recovery access exists. Then agree how accounts or connections will be replaced. Finally, test the usual outcomes. Changing the person in charge does not by itself prove the process still works.
Not every service lets you transfer an account in the same way. You may need to change the owner, invite an administrator or create a new connection. Check each provider's options before closing the old one. Do not work around a limitation by sharing personal credentials or by putting another password in a shared document.
Pick a window in which you can watch the result. For the shop's integration, an agreed test could receive a dummy order, recognise it and generate an internal notice. It must avoid charges, shipments or messages to real buyers. The rehearsal checks the transition; it does not try to reproduce all of the shop's activity.
Leave an understandable temporary fallback. If a connection fails, the team needs to know where to look for pending operations and how to handle them. Note who decides to stop the change and how the previous state is restored where that is possible. A rollback cannot be improvised after you have lost the old access.
Document the handover without copying customer data you do not need. You can record which journey was tested, at what time and with what result. The outgoing supplier and whoever takes over should both know what has been verified and what remains open. That stops an unchecked task from turning into a silent expectation.
What should you revoke, and what is worth keeping?
Remove what no longer has an agreed purpose, following the service's own options. Do not confuse revoking a permission with deleting documents, cancelling a subscription or deleting an account. Each action has its own consequences. An integration may need replacing; a file may need keeping; an invitation may stop being necessary immediately.
Google explains that removing an app's access stops it from continuing to reach the data you authorised, but you may need to contact its developer about information it already obtained. Reviewing permissions and reviewing retained copies are therefore separate tasks. Google, app access to your account, accessed on 12 October 2026.
Where personal data is involved, review what was agreed on return, retention and deletion with the right person. This article is general information, not legal or professional advice. It does not set universal deadlines and does not replace a review of your contract and of the obligations that apply to your activity.
In the hypothetical shop, keeping the original photographs does not mean keeping an editing invitation forever. Likewise, cancelling the agency's access to a folder does not prove its local copies are gone. Make the specific request, keep the reply, and avoid statements you cannot verify.
How do you check that the handover is finished?
Define observable results. The business can reach its resources, knows who maintains each one and has tested the connections it needed to replace. Accesses with no purpose are removed or documented as a temporary exception. A list of accounts is not enough if nobody has checked that they can use them.
Check future notifications as well. A renewal, an error or a recovery request should not depend on a person who is no longer involved. Review the relevant recipients inside each service, together with the authorised people. Do not change contact addresses until you understand which messages they receive and who has to act on them.
Leave a close-out sheet with three states: done, pending and out of scope. Add owners and next steps for the pending items. You do not need to declare everything secure to close a project well. You need to describe what control has been moved and what uncertainty remains, with enough evidence to keep working.
How have we approached it at meiika?
The bespoke systems and websites we present at meiika depend on understanding their tools and dependencies. A conversation about handover starts with that journey and with who controls each account. We are not presenting here a supplier change carried out for a client, nor any proven results.
If you want to review your situation, you can describe what is ending, which tools are involved and what you need to keep. Please do not send passwords, keys or client files through the form. Any later technical work would need an agreed scope and limited access. Clarifying who owns the work is part of the project, not a detail to settle at the end.