Setting up a new client or project: an access checklist

Practical guides · About 7 minutes

Access setups are decided in the first week, under time pressure, by whoever is available — and then they last for years. Half an hour of deliberate choices at the start saves an enormous amount of untangling later, and makes the eventual handover a non-event instead of an argument. This is that half hour.

Ask for delegated access before anything else

The most important question of the engagement, asked before anyone sends you a password: can you add me as a user, rather than sharing your login?

Most clients will say yes. Many have never been asked, because their previous supplier just took the password. Asking marks you as competent, and it avoids the position you don't want to be in — holding a client's personal credentials, with no way to prove what you did and what you didn't.

Where the platform supports agency or partner linking rather than user seats, use that. It's designed for exactly this relationship: the client grants access from their side and revokes it from their side, and no credential ever changes hands. Advertising, analytics, and merchant platforms almost all have this. The access-sharing guide covers the full ladder.

Establish who owns what, in writing

The single biggest source of bad endings. Get it settled while everyone is friendly.

The principle worth stating plainly: the client should own the accounts, and you should have access to them. Not the reverse. When the domain, the ad account, or the analytics property is registered under your name and card, ending the relationship becomes a negotiation instead of a revocation — and the client is right to be unhappy about it.

Specifically, agree in writing:

• Which accounts belong to the client, registered under their organisation and their billing.
• Which are yours — your tooling, your workspace, your subscriptions.
• Who pays for what, and on whose card.
• What happens to each at the end of the engagement.
• Who the account owner of record is on the platforms that have one.

If you must create an account on their behalf because they don't have one yet, register it to their role address and add yourself as a user. It takes the same amount of time as doing it the other way and removes the entire problem class.

Use role addresses, not personal ones

Accounts registered to ops@client.com rather than a named individual survive staff turnover on both sides. Password resets, security alerts, and vendor notices land somewhere the organisation controls.

This is the fix that's cheap now and expensive later. An account registered to someone who left, with a recovery address nobody can read, is the classic unrecoverable account — and it's the one your successor will be dealing with.

Take the narrowest role that works

Resist "just make me an admin, it's easier". Ask for what the work needs, and expect to revisit it. Reporting work needs read access; you can request more when a task genuinely requires it.

Two things follow from this. It protects the client, obviously. It also protects you — the less you can do, the less you can be blamed for, and the smaller the consequence if your own account is ever compromised.

Set up your side properly on day one

The habits are the same as your own inventory, applied per client:

A separate vault collection per client. Not entries scattered through your personal vault. When the engagement ends, you archive or delete one collection, and you can state exactly what you held.

Consistent naming from the first entry. Client — Service — Role. Twenty clients in, this is the difference between finding something and searching for it. It also makes it obvious when you're about to act on the wrong client's account, which is the mistake that actually costs you a relationship.

A separate browser profile per client. Keeps sessions and cookies isolated, so you're never one tab away from posting to the wrong account. See the browser profiles guide.

2FA on every account you're given, with the factor stored where your team can reach it rather than on one person's phone.

An end date, if one exists. A fixed-term project gets a calendar entry for access removal at the start, not a note-to-self.

Document as you go

Write the handover document during onboarding, while you're discovering everything anyway. Doing it at the end means reconstructing from memory under time pressure, which is why it usually doesn't happen.

Per account: what it is, the login URL, which identity signs in, what access level you hold, who granted it, what depends on it, and whether it's client-owned or yours. That's a spreadsheet, not a project. The handover guide covers what else belongs in it.

Inheriting a mess

Often you're not starting clean — you're taking over from someone else, and what you inherit is a shared password from a departed employee and no documentation. Work in this order:

1. Inventory what exists before changing anything. You can't safely rotate credentials you haven't mapped.
2. Rotate every shared credential you received. You don't know its history or who else holds it. Do this early — you're accountable for these accounts now.
3. Audit the user lists on each account. Former staff and previous suppliers are routinely still present.
4. Revoke unrecognised tokens and connected apps. The most commonly missed leftover from a previous supplier — see the tokens guide.
5. Fix ownership and recovery addresses so accounts point at the client's role addresses, not a predecessor's inbox.
6. Then migrate to individual accounts where the platform supports it.

Report what you find to the client factually, without editorialising about your predecessor. "Three former users still have admin; I've removed them" is useful. Commentary isn't, and it makes clients wonder what you'll say about them later.

Plan the exit at the start

Every engagement ends. Deciding how while everyone is happy costs nothing:

• You'll remove your own access rather than waiting to be removed, and confirm in writing when it's done.
• Shared credentials get rotated by the client at the end — remind them, because they'll forget.
• The handover document goes to the client as a deliverable.
• Anything of theirs in your systems gets exported to them and then deleted.
• Accounts you created on their behalf get transferred, with the owner of record changed.

A clean exit is a competitive advantage. Clients notice, and the ones who've been through a bad one notice more. It's also the thing most likely to bring them back or get you referred.

The half-hour version

1. Ask for individual or delegated access before any password moves.
2. Agree ownership and billing in writing.
3. Register accounts to client role addresses.
4. Take the narrowest role that does the job.
5. Create a dedicated vault collection and a dedicated browser profile.
6. Enable 2FA, with the factor reachable by your team.
7. Start the handover document now, not later.
8. Diarise access removal if there's an end date.