# Account handover checklist when agency staff leave or change roles Before the change, list the person's accounts, two-step codes and shared logins. On the day, remove access or request password changes. Then confirm it worked. Updated: October 16, 2026 A staff change at an agency changes who can get into your clients' accounts. What you have to do depends on how your staff get into each account. There are three ways: delegated access, a shared login, or an access management tool (a tool that signs staff in without showing them the password). Of these, only a shared login means asking the client for a new password. The overview is in [managing client accounts at an agency](/guides/agency-accounts). ## Before the change Start as soon as the last day or the role change date is set. Some checks can only happen while the person is still there, because after they leave you can't ask which accounts they used. Steps that wait on the client should be requested at this stage. 1. Pull the person's accounts from your list of client accounts (your agency). If there's no list, build it with them. An account missing from the list gets skipped on the day, and the person can still get in after they leave. 2. Check how staff get into each account (your agency). The work on the day differs by type: remove the invitation for delegated access, request a password change for a shared login, or stop access in the tool. 3. Check whether each invitation went to a work email address or a personal one (your agency). A user invited at a personal address can still sign in to the platform after you shut off their work email. 4. Check where two-step verification codes go (your agency checks; the client changes it). If the codes still go to the person's phone or number, the rest of the team can't sign in once that person is gone. Changing where they go is a client-side setting. 5. List the shared logins whose passwords the person knows (your agency). A password can't be taken back from memory, so decide which clients to ask for a change, and when. 6. Choose a replacement, and set up their access first (the client sends invitations; your agency sets up the tool). If you remove the old access before the new person can get in, posting and campaigns stop. 7. Decide what to tell each client, and when (your agency). Removing invitations and changing passwords are client-side actions, so the message is both a notice and a request. If someone leaves suddenly and can't be asked, the list is all you have. Without one, go through each client's platform user lists and the shared logins your team uses. Send requests to clients as you confirm each one. ## On the day What shuts the person out differs by type. Delegated access and shared logins wait on the client. An access tool is handled entirely by your agency. 1. For delegated access, ask for the person's invitation to be removed, and check that the replacement's invitation works (the client, or your agency's manager account). The invitation is tied to the person's own login, so it stays valid until someone removes it. 2. For a shared login, ask the client to change the password, then decide who gets the new one and send it (the client changes it; your agency sends it). The only way to stop a password the person knows is to change it. 3. For an access tool, stop the person's access in the tool (your agency). The person never knew the password, so once stopped they can't get in through the tool. 4. Move two-step verification codes from the person's phone or number to one your company controls (the client). Otherwise, codes the replacement needs go to a device outside your company. 5. Collect the person's company devices, or sit with them and delete saved passwords and signed-in browsers from personal devices (your agency). A browser's saved password stays on the device even after the password changes elsewhere. 6. If the platform can sign out other devices, use it (the client or your agency, depending on the platform). This reaches devices you couldn't collect. 7. Tell each client about the change and confirm the requested removals and changes are done (your agency). If the client puts it off, the person can still get in. ## After the change Two jobs remain: confirm the day's steps took effect, and update the list for next time. A request isn't the same as the change being made. Look for confirmation that it's done, not just a reply saying the request arrived. 1. For delegated access, check the platform's user list and confirm the person is gone (your agency). 2. For a shared login, get the client's confirmation, then sign in once with the new password (the client confirms; your agency signs in). Failing to sign in with the old password is a secondary check. The records name the login, not the person, so you can't confirm this by looking for the person's activity. 3. For an access tool, check the tool's user list (your agency). The tool's own records also show when you stopped the person. 4. For delegated access and access tools, watch for any activity under the person's name for a while (your agency). This check works only where records are kept per person. A missed removal shows up as their name in the history. 5. Update your list of client accounts (your agency): staff names, who knows each password, where two-step codes go, and which address each invitation went to. The next staff change starts from this list. ## Why this matters when you handle personal information Some agency work involves consumers' personal information, such as answering direct messages or uploading customer lists for ad targeting. Then you may be a client's "service provider" under the California Consumer Privacy Act (Cal. Civ. Code 1798.140(ag)). That applies when the client is a "business" under the law and you process the information for it under a written contract. That contract must let the client take "reasonable and appropriate steps" to help ensure you use the information in line with its obligations (1798.100(d)(3)). The CCPA regulations add that the contract must require you to give personal information "the same level of privacy protection" that businesses must give (11 CCR 7051(a)(5)). One example the regulation gives is reasonable security procedures under Civil Code 1798.81.5. A dated record of who could get into which account, and when that access was removed, is something concrete to show when the client takes those steps. Work that never touches personal information, such as writing and scheduling posts, may fall outside these rules. The steps above are the same either way, because the goal is the same: a person who left can't get into a client's account. ## Frequently asked questions **What do we do about a shared login the departing person knows?** You can't take a password back from someone's memory. Ask the client to change it and decide who gets the new one. Confirm with the client's note that it's done and a first sign-in with the new password. **When should we start preparing a handover?** As soon as the last day or the role change is set. Removing invitations and moving two-step codes wait on the client, so send those requests while the person is still there. **What if someone leaves suddenly and can't be asked?** Your list of client accounts is what you work from. Without one, go through each client's platform user lists and shared logins, and send requests to clients as you confirm each one. **Does the handover process matter under the CCPA?** If you handle consumers' personal information as a client's service provider, the client's contract must let it check how you use that information (Cal. Civ. Code 1798.100(d)). Dated access records give you something to show. ## Sources - [California Consumer Privacy Act of 2018, Cal. Civ. Code 1798.100 and 1798.140 (text posted by the California Privacy Protection Agency)](https://cppa.ca.gov/regulations/pdf/cppa_act.pdf) - [California Consumer Privacy Act Regulations, 11 CCR 7051 (effective January 1, 2026)](https://cppa.ca.gov/regulations/pdf/ccpa_statute_eff_20260101.pdf) ## How Junify handles this **Doing this by hand** You agree with each client on how access is handed over, add and remove people platform by platform whenever staff change, and keep track of which staff member used which client's account. **With Junify** With Junify, staff sign in without seeing the client's password, so on the day of a change your admin removes that person's access in Junify. If you change the password when you set up Junify so only Junify holds it, the person can't sign in to the client account again. You don't need to ask the client for a new password. The record of who used which account stays under each person's name. Junify is an access management service for handing work in your web accounts to employees, contractors and outside teams without giving them the password. Each person verifies on their own phone and clicks a card to sign in. The password is never shown, and Junify records who used which account and when. - [Try the demo](https://www.junify.com/bpo/try?lang=en&scenario=marketing-ops&from=guide&cluster=agency-accounts&slug=handover-checklist) - [Book a 30-minute demo](https://www.junify.com/bpo/demo) ## More on this topic - [Account clauses an agency should propose in its client contract](/guides/agency-accounts/account-clauses-for-service-providers): Propose five: account handover, who may use accounts, records, incident notice, and offboarding. Keep your own promises apart from what the client must do. - [How to write client account handling into your agency's security policy](/guides/agency-accounts/agency-security-policy-for-clients): Write a short public policy, an internal policy for staff, and an access summary for each client. Rewrite template rules for logins the client owns. - [Amazon Seller Central user permissions, and how to give an agency access](/guides/agency-accounts/amazon-seller-central-user-permissions): Seller Central Help says not to share logins. On a Professional plan, the seller invites staff as employees and authorizes your agency as a Service Provider.