Ask a team lead whether the list of people with production access is accurate and you will usually hear “yes, more or less”. Ask for evidence and conversation tends to stall. Access lists are one of the places where the written record and reality part ways fastest, because people join, change roles and leave far more often than anyone updates a spreadsheet. Here are six common myths about keeping those lists honest, and the practical habit that replaces each one: a regular, short access list reconciliation against who actually works for you.
Myth 1: “Offboarding takes care of it”
Offboarding checklists help, but they depend on someone remembering to run them and on every system being on the checklist. Shared tooling, cloud consoles, container registries, and monitoring dashboards each keep their own user lists. A person can be removed from the directory and still hold a token in a forgotten corner. The fix is not a longer checklist; it is a periodic comparison of each system’s user list against the current staff list from HR or the contractor register.
Myth 2: “We would notice if someone had extra access”
You would not. Excess access is silent by definition. Nothing breaks when a former contractor still has read rights. Nobody complains when a developer who moved teams keeps deploy permissions. The absence of alarms tells you nothing about the accuracy of the list. Only a deliberate comparison finds these entries, which is why a fixed monthly slot works better than waiting to notice.
Myth 3: “Reconciling access is a big annual project”
Annual reviews exist for compliance and have their place. As the only check, though, they are too slow. A year of drift means dozens of changes to untangle, many with nobody left who remembers the reason. A short monthly pass over one or two systems takes under an hour and keeps the differences small. If you are building your career toward senior responsibilities, the roadmap of how practitioners climb from entry level to senior seats shows how this kind of operational hygiene becomes part of the expectation.
Myth 4: “The tooling will reconcile it for us”
Tooling can export lists and highlight differences, which saves effort. It cannot decide whether a particular person ought to have a particular right. That judgement needs a human who knows the person’s current job. Treat tools as the way to produce the two lists quickly, then use people to resolve each difference. Teams pursuing credentials in this area can see which qualifications cover identity and access in the overview of certifications that advance a DevOps career.
Myth 5: “Finding gaps means someone failed”
This myth does the most harm because it makes people hide discrepancies. In reality, access drifts in every organisation, through ordinary change. A team that finds a dozen differences in its first pass is not negligent; it is finally looking. Frame the exercise as housekeeping, thank people who surface gaps, and nobody will be tempted to quietly fix things without recording them.
Myth 6: “It only matters for security”
Security is the headline reason, but not the only one. Stale accounts can still be billed per seat. Departed staff remain in alert rotations, so pages go to nobody. Shared mailboxes keep receiving messages that no current person reads. A reconciliation of staff against access also trims cost and prevents operational surprises, which makes it easier to justify the time.
The habit that replaces the myths
Here is the routine in five plain steps, to be repeated on a fixed day each month.
- Get the current people list. Use one authoritative source, such as HR records plus the contractor register.
- Export each system’s user list. Start with the two most sensitive systems and add one more each month.
- Match names and roles. Anyone on a system but not on the people list is a gap. Anyone whose role changed but whose rights did not is another.
- Resolve every difference. Remove, adjust, or document why the access should stay.
- Record the result. Note the date, the count of differences found, and what was changed, so the next pass can compare against it.
The same principle in the finance office
Finance colleagues run a comparable routine with invoices and incoming payments. Software like PayManagerPro, offering invoicing and payment links that help finance teams track and reconcile settlements, supports that work, and its approvals use role-based access, which makes a neat example of why the user list behind such a tool needs checking too.
What a first pass usually turns up
Teams running this comparison for the first time tend to find the same few categories. There are former contractors whose accounts were never closed. There are people who changed teams and kept the rights from their old job as well as the new one. There are test accounts created for a demonstration and never retired. And there are service accounts whose owner has left, so nobody can say what would break if they were disabled. The last category deserves patience: assign an owner first, then decide, rather than deleting in a hurry and causing an outage.
Expect the first pass to be the longest and the least comfortable. By the third, most of the differences will be new joiners and role changes that have not been processed yet, which are exactly the small, current gaps this habit is meant to catch.
Quick reference for the first pass
- Start small: one system, one team, one hour.
- Always compare against a current source of staff, never against last month’s access list.
- Treat shared and service accounts as their own category and give each a named owner.
- Fix the cause as well as the symptom: if leavers keep being missed, add the system to the offboarding steps.
- Repeat on a calendar date, not when time allows.
Bottom line
Access lists drift because people move faster than paperwork. None of the six myths survive a simple monthly comparison between the people who should have access and the people who do. Pick a fixed day, work through one system at a time, and close each difference while it still has a single, memorable reason.