An agency needs access to particular systems to perform agreed work. That does not mean everyone should share a password or that the business should surrender its only administrative control. Before sending an invitation, identify the account, the task and the permission required to complete it.
List the systems involved. They may include advertising, analytics, the website, tag management, domain administration and billing information. These areas are not interchangeable. Permission to read reports does not automatically require permission to change payment details or domain settings.
Give people individual access
Use the product's invitation and role functions where available. Permissions can then be assigned to identifiable people and removed individually. Google explains how to manage Ads access, including changing roles and removing users. Check the current options in the specific product; similarly named roles do not necessarily permit the same actions across systems.
Do not send personal master passwords by email. If a system lacks suitable collaboration controls, plan an alternative deliberately instead of accumulating credentials in an unprotected spreadsheet. The account owner must understand how access is granted and how it can later be withdrawn.
Preserve business control
Document which account belongs to the business, who administers it and how recovery would work. A business email address is not a complete recovery plan by itself. Check that the address will remain accessible if someone leaves and that the recovery methods are maintained.
Where the product supports it, arrange suitable backup responsibility with controlled access. This does not mean making every colleague an administrator. It means avoiding dependence on one private device or one external person. Enable additional sign-in protection offered by the service and store recovery information securely.
Test the business's own access before granting external access. Discovering that the company cannot reach its account only when a contract ends makes an ordinary handover unnecessarily difficult.
Separate permissions from approval
Record which changes can be made independently and which need discussion first. Text corrections within an approved offer may be handled differently from a budget increase or the introduction of new measurement. Technical permission to make a change does not replace the agreement about who may authorise it.
Set a review date for temporary access. Also review invitations and linked accounts when staff change. The number of authorised users can otherwise increase quietly even after individual engagements have ended.
Plan the end of the engagement
Before removing access, collect required reports, approved files, settings and outstanding tasks. Check whether automations or notifications depend on the departing person's account. Transfer those responsibilities deliberately so the business does not discover a failed process only after access has been revoked.
Then remove permissions that are no longer needed and verify the company's remaining access. A short handover test should establish that reports open, necessary settings are available and contact details can be updated. Record the completion date and responsible person. The business should be able to establish who can still act after the handover, rather than relying on an assumption that all external access has disappeared.
