A Credential Handoff Checklist for Solo Cloud Consultants

A team needs a written process because no one person holds the whole picture. A solo consultant assumes they don't need one, since they are the whole picture, until a client engagement ends, a health issue takes them out of commission for two weeks, or they simply forget the specific reasoning six months later when the client asks a follow-up question.

The checklist isn't for coordinating with a team you don't have. It's for coordinating with your future self and with whoever the client hands the account to next, including you, after enough time has passed that memory alone won't cut it.

Every new client environment should go through the same recorded sequence: what infrastructure-as-code template was used and which version, what access controls and network boundaries were set, what monitoring and alerting were configured, and what assumptions were made about the client's existing setup that could break if something upstream changes.

Running this as a checklist instance per client, rather than trusting memory or a personal notes file, means the record exists independent of whether you happen to remember to write it down that day. It also means a second consultant, if you ever bring one on, can pick up a client's environment without a lengthy handover call.

When an engagement ends, or pauses, the client needs a complete accounting of every credential, API key, and access grant created during the work, not a best-effort memory of most of them. A handoff checklist that requires listing every account touched, rotating any shared secrets, and confirming the client's own team can access everything without you protects both sides if the relationship doesn't continue.

It also protects you specifically: a client who later has a security incident and can't identify what a former consultant still has access to is a client who's going to call you first, whether or not you're actually responsible. A clean handoff record is what actually settles that conversation quickly.

A credential handoff at the end of an engagement should follow these steps:

1. List every account, API key and access grant created during the work, not a best-effort memory of most of them.
2. Rotate any shared secrets so old copies stop working.
3. Confirm the client's own team can reach everything without you.
4. Get the client's sign-off, and treat any credential you can't account for as one still to be found and revoked.

Something will eventually break in production, and a postmortem you write immediately after, covering what happened, what you changed to fix it, and what you'd do differently, is worth far more than one you try to reconstruct from memory a month later when the client asks what happened. Keep a standard template ready so writing it isn't its own obstacle right after an incident you're already tired from handling.

It's easy to accumulate standing access across a growing roster of clients and never revisit whether you still need it for the ones you finished work for months ago. A recurring checklist, quarterly is reasonable, that walks through every client you still have credentials for and confirms whether that access is still needed catches the kind of exposure that has nothing to do with any single client and everything to do with how much access has quietly piled up across all of them.

Independent cloud and DevOps consultants often undercharge for the documentation and handoff work relative to the build itself, treating it as an afterthought instead of a deliverable a client is paying for. Writing the provisioning checklist and the handoff record as you go, rather than reconstructing them later if a client ever asks, is cheaper in your own time and produces a better result, since the details are still fresh instead of half-remembered.

It's also a fair line item to name directly in a proposal. A client who understands that the checklist and handoff record are part of what they're buying is less likely to push back on the hours spent writing them, and more likely to actually use them if the relationship ends.