Who Still Has the Keys?
The people who built your website, your old bookkeeper, the staff member who left in March. Access outlives the relationship, and nobody keeps the list.
On a decommissioning job years ago I asked for the list of everyone with administrator access to the system we were about to retire. There wasn't one. So we pulled it out of the system itself, and the list had a contractor who had finished on site three years earlier, a vendor engineer nobody in the room could name, and a shared login whose password lived in a spreadsheet on a file share. Nothing had gone wrong. That was the unsettling part.
Your business has that list too. You've just never printed it.
Access outlives the relationship
Think about who you have handed a key to over the years. The people who built your website - they set up the hosting, they configured the domain, they probably still hold the login for both. Your old bookkeeper, who you parted ways with amicably in 2023 and who may still be sitting in your accounting file. The marketing agency you used for six months, still an admin on your Facebook page. The staff member who left in March, whose email account you disabled but whose personal phone still has the shared password for the booking system.
None of these people are villains. That's the whole point. Access is granted in a hurry because someone needs to do a job, and it is almost never taken back, because taking it back is nobody's job. The relationship ends. The key does not.
In thirty years I have never once been asked to hand a credential back. Not once. Every organisation I have worked for or with has, somewhere in its systems, an account of mine that outlived my usefulness to them. Some of those organisations were very large and had entire teams whose job description included exactly this.
Two ways old access hurts you
The first way is the boring one, and it's the one that actually happens: somebody does something wrong with access they still legitimately hold. The Office of the Australian Information Commissioner published a case study for the first half of 2025 in which an agency engaged a software developer to work on its website, and the developer ran a script without authorisation. Documents marked private became publicly available online, and then on search engines (OAIC, 2025). No attacker. No malware. Just a person with a login doing a thing nobody asked for.
The OAIC states the principle plainly: organisations are responsible for the actions of third-party providers when outsourcing their personal information handling. Your web developer's mistake is your incident.
The second way is the one everybody thinks of. Credentials get stolen and reused. Of the incidents the Australian Signals Directorate rated C3 in 2024-25, 42 per cent involved compromised accounts or credentials (ASD, 2025). Now, be honest about that number: ASD's C3 band is governments, large organisations, academia and their supply chains. It is not you. I quote it anyway because the pattern travels even when the figure doesn't, and because organisations with security teams and a stale-credential problem are still organisations with a stale-credential problem.
The same report carries a case that does travel. An employee logged into a personal Google account on their work device; the browser dutifully synchronised the work credentials across; then malware on that person's own device harvested them out of the browser. Nobody attacked the company. The credentials simply walked out through a convenience feature.
Notice what those two stories share. In neither case did anyone break in. The access was already there, sitting quietly, waiting for either a mistake or a thief. An old credential isn't a small risk that grows slowly. It's a full-strength risk that simply never expires.
The list takes an afternoon
You cannot manage what you have never written down. So write it down, once, and then keep it.
Open a spreadsheet. Four columns: who has access, at what level, why they have it, and the date you last confirmed it. One row per system, and the rows are these:
- The domain registrar and the DNS, wherever they live.
- The web hosting and the website's own admin login.
- Email, which for most of you means Microsoft 365 or Google Workspace.
- The accounting package, the bank, the payment terminal and the point-of-sale.
- The booking or job-management system, and anything holding customer records.
- The social accounts, the phone and internet account, and the insurance portal.
Then go and actually look. Do not fill this in from memory - memory is the reason the list is wrong. Open each system's user list and read it. You will find at least one name you had forgotten about. Everybody does.
Two rows will not fit this format, and they are the two worth the most attention. The shared login that everyone uses has no answer to "who has access", which is precisely the problem: it cannot be taken off anyone, so it has to be changed instead, and on a schedule.
The other is the API keys and app passwords your systems use to talk to each other. They belong to nobody, they outlive whoever created them, and disabling a person's account does not touch them.
The domain registrar is the row to check first. It is the single account that, in the wrong hands or simply in nobody's hands, takes your website, your email and your business name with it. If it is still sitting in your web developer's account under their email address rather than yours, that is not a partnership. That is a hostage situation nobody has noticed yet.
The way out is unglamorous: ask to be made the registrant and administrative contact of record, in your own name, on your own email address. If you are moving away from them entirely, what you want is the transfer authorisation code. A developer who will give you neither has answered the question for you. The same logic applies to the recovery email on every account you own, which is the quietest master key in the building.
Then make removal somebody's job
Granting access has a natural owner: the person who needs it asks. Removing it has none, which is why it doesn't happen. So attach it to something that already happens reliably.
When anyone stops working with you - staff, contractor, agency, bookkeeper - the same day they finish, you open the list and close their accounts. Not next week. That day, while the fact is fresh and slightly awkward, because in a month it will be neither fresh nor awkward, just forgotten. Write the steps into your run book so they survive your memory and can be done by someone who isn't you.
And twice a year, take twenty minutes and read the list against reality. Half the value is finding the leftovers. The other half is that you finally know which accounts exist, which is a thing a surprising number of owners cannot say out loud. Add it to the thirty-minute drill if you already run one - it is the same twenty minutes of useful discomfort, aimed at a different wall.
There's a version of this that costs money and comes with a dashboard. You don't need it yet. A spreadsheet you actually read beats a platform you bought and never opened, and the review is the part that does the work.
Have a think about the last person who stopped working with your business. Could you say, right now, with certainty, what they can still open?
Sources
- Office of the Australian Information Commissioner, Latest Notifiable Data Breach statistics for January to June 2025 - retrieved 5 August 2026, https://www.oaic.gov.au/news/blog/latest-notifiable-data-breach-statistics-for-january-to-june-2025
- Australian Signals Directorate, Annual Cyber Threat Report 2024-25 - retrieved 5 August 2026, https://www.cyber.gov.au/about-us/view-all-content/reports-and-statistics/annual-cyber-threat-report-2024-2025
- Red Bridge Cyber, perspective: Locked Out of Your Own Business
- Red Bridge Cyber, perspective: Write the Run Book Before You Need It
- Red Bridge Cyber, perspective: The Thirty-Minute Fire Drill