home / incident-response / joiner-mover-leaver-iam-web-agency
IAM Analyst at a Web Design Company
My work as IAM Analyst running the joiner, mover, leaver lifecycle for a web design company, anonymised.
- Type
- Ongoing operational case
- Severity
- Medium
- Category
- Identity and access management
- Role
- IAM Analyst
- Organisation
- Web design company (anonymised)
Summary
A web design company hands out access to client sites, hosting, design tools, source repositories and shared drives. People, freelancers and contractors come and go often, and move between client projects. Access that is granted late, never reduced or never removed is the main identity risk. I owned the joiner, mover, leaver (JML) process so that access matched the person’s current job and ended when they did.
My role
IAM Analyst. I owned the JML process end to end: provisioning requests, access changes when someone moved project or role, and offboarding. I worked with the people lead, project managers and the engineers who administer hosting and tools.
Timeline
relative to the first event- Start
Gap found
Review of accounts against the staff list showed leavers whose access to hosting, repositories and shared drives was still active, and movers who kept access from earlier projects.
- Week 1
Inventory
Listed every system that holds client or company data, who administers it, and how accounts are created and removed in it.
- Week 2
Role model
Defined a small set of roles (designer, developer, project manager, contractor, admin) with the minimum access each needs, mapped per system.
- Week 3
Joiner flow
Access is requested by the manager, approved by the system owner, and granted from the role template on the start date. Contractors get an end date at creation.
- Week 4
Mover and leaver flows
A role or project change triggers a review that removes the old access first. Leaving triggers a same-day checklist: disable accounts, revoke tokens and SSH keys, rotate shared credentials, transfer ownership of files and client assets.
- Ongoing
Access review
Regular review of accounts against the staff list, with orphaned and overly broad accounts removed.
Key decisions
Remove old access when someone moves
Granting new access is easy to remember; removing the old access is not. The mover flow starts with removal so people do not collect access over time.
Give contractors an end date at creation
Contractor access most often outlives the contract. An expiry set when the account is created removes the need to remember.
Rotate shared credentials on every leaver
Shared accounts and tokens cannot be disabled per person, so they are rotated whenever someone with access leaves.
Actions taken
- Joiner: role-based access from a template, approved by the system owner, ready on day one.
- Mover: review on project or role change, old access removed first.
- Leaver: same-day checklist covering accounts, tokens, SSH keys, shared credentials and file ownership.
- Review: accounts compared with the staff list on a schedule; findings tracked to closure.
Post-incident improvements
| Area | Change |
|---|---|
| People | Managers own the request and the end date; system owners own approval; one named person owns the process. |
| Process | Written JML checklists, contractor end dates, and a regular access review. |
| Tooling | Role templates per system and a single list of who has access to what. |
| Detection | Alerts on sign-ins from disabled or departed accounts. |
Lessons
- Least privilege is easier to keep than to restore: start from a role template and review on every move.
- Offboarding is a checklist problem. The same steps every time beat clever one-off clean-ups.
- A single, current list of who has access to what is the foundation for every other identity control.
Tags
#incident-response#iam#access-control#identity