Code, data and device access for developers: joining, moving and leaving checklists

A web development firm lets a developer go on a Friday. On Monday the client reports a strange commit on their site. The former developer's repository access was never removed, and nobody remembers which shared passwords he knew. The head of engineering spends the week changing keys instead of shipping.

This post gives three short checklists for developers who join, move between projects and leave. They help an engineering head decide who can reach code, data and devices, and when that access ends.

You cannot remove access you have not listed. Build a simple sheet of systems: code repositories, cloud accounts, the project tracker, client staging servers, design files, shared password stores, email and chat. Beside each, write the owner and who currently has access. This sheet is the base for every checklist below.

Access control sits within your wider password and access control policy. The checklists are the practical side of that policy.

1. 1

   Raise one access request

   The manager lists the systems the person needs for the first month. No broad starter pack.

2. 2

   Create named accounts

   Each person gets their own login. Shared accounts hide who did what.

3. 3

   Issue a managed device or record a personal one

   Write down which device holds company code and who maintains it.

4. 4

   Walk through the rules

   Cover password habits, two step sign in, handling client data and what must never be copied to personal storage.

5. 5

   Record the grant

   Update the access sheet with the date, the approver and the systems.

Access tends to pile up. A developer who worked on four client sites over two years may still reach all four. When someone changes project, ask the project owner to confirm what stays and what goes. Remove staging and production access for finished client work. Keep a short log of each change.

Joining: systems requested, approver, date granted, device recorded.
Moving: old project access removed, new project access added, shared secrets changed if needed.
Leaving: last working day, accounts disabled, keys and tokens rotated, devices returned and checked.
Leaving: client contacts told if they had direct access.
Leaving: handover notes stored in the team repository.
Leaving: confirmation signed off by the engineering head and one other person.
Quarterly: sheet compared with the current team list.

For planned exits, prepare the removal list in advance and time it to the last working day. For sudden exits, act the same day. Disable accounts first, then rotate shared keys and tokens, then collect devices. Check who else knew a shared password, and change it even if you think the person did not use it.

Freelancers and client staff can hold access to your repositories, and your developers can hold access to theirs. Agree in writing who may reach what, how long for and who removes it. Ask your own adviser to review the written terms, since confidentiality and ownership of work depend on the facts and the contract.

Website teams often work in shared client environments. The page on website development companies covers common people and process issues in this setting.

Access removal is half the job. The other half is knowledge. Ask a leaver to write a short note on open tasks, unusual setups, scheduled jobs and anything only they understand. Review it with their manager in the final week. The longer notice you can agree for senior roles, the easier this is. The notice terms are a company decision and should be settled with your adviser.

When firms run the first review, the same gaps appear. A former intern still sits in the chat group with client channels. A cloud account has one admin who has since left. A test database holds a copy of real customer data. A laptop returned months ago was never wiped. An old deploy key still sits in a build tool. None of these is dramatic alone. Together they are the open door that causes the Monday morning scramble.

Fix these in order of exposure. Start with production access and admin roles, then client environments, then everything else. Keep a short note of what you changed and when, so the next review starts from facts.

• Name one owner for the access sheet, usually the engineering head.
• Put each checklist into the project tracker as a task list.
• Compare the sheet with the staff list every quarter.
• Test the leaver routine on paper once a year.
• Tell new joiners the rules in the first week.

If hiring is moving fast, tie the joiner checklist to your offer process. See how to reduce drop-off between offer and joining. Releases at night need accounts too, so check the fair rules for on-call and release night work alongside who holds production access.