The short answer
Named accounts per person, permissions scoped to what the work needs, no production data in development, and a documented offboarding step that actually gets run. Those four cover most of the risk.
The common failure is a shared account passed around because it was quicker on day one, and still in use two years later with nobody sure who has the password.
Named accounts, always
One account per person, in their own name, on every system. It costs a little more in licences and it is the difference between an audit trail and a guess.
- You can see who did what, which matters when something breaks
- Access can be removed for one person without disrupting everyone
- Multi-factor authentication works properly
- Offboarding is a defined action rather than a password change everyone has to learn
Scope the permissions
| System | Usually needed | Usually not |
|---|---|---|
| Source control | Read and write on relevant repositories | Organisation admin |
| Cloud | Development and staging | Production write access |
| Database | Development data | Production, especially personal data |
| CI and deployment | Trigger builds, see logs | Change pipeline secrets |
| Issue tracker | Full access to their work | Admin or billing |
Production access deserves particular thought. Most augmentation work does not need it, and where it genuinely does, time-limited elevation with a record is better than standing permission.
Keep production data out of development
Copying a production database into development is common, convenient and the source of a large share of data incidents. Personal data ends up on laptops, in backups and in places nobody is tracking.
Generate representative test data, or take a production copy with personal fields masked as part of the copy rather than afterwards. It is a day of work and it removes a category of risk permanently.
Where genuinely sensitive data is unavoidable, that is a conversation to have before the engagement, including what the contract requires and what your own obligations are.
Devices and environments
Decide whether people work on their own machines or yours. Your own machines give control and cost money. Their machines are cheaper and mean your code sits on a device you do not manage.
A middle path that works for many teams is development inside an environment you control, reached from whatever device they have, so the code and data never leave your infrastructure.
Offboarding that actually runs
- Keep a written list of every system access was granted on, updated as it is granted.
- Set a removal date at the start, matching the engagement end.
- Revoke on the day rather than when someone remembers.
- Rotate any shared secret they had access to.
- Check for accounts and services registered in their name.
The list in step one is what makes the rest possible. Without it, offboarding is an archaeology exercise and something always gets missed.