One person knew how the network fitted together. They configured the firewall, they held the passwords, they knew which cable went where and why that one server must not be rebooted on a Tuesday. Now they have resigned, and it is suddenly obvious that none of it was written down.
The first 48 hours: access
Before anything else, deal with what that person can still reach. Not because departing staff are usually a threat, but because unrevoked access is a real risk that compounds quietly, and because you will not remember to do it in three weeks.
- Administrative accounts on the firewall, switches and servers. Change them rather than disabling the named account, because shared admin credentials are common and the password may be known well beyond one person.
- Remote access. Revoke VPN certificates and accounts. If remote access is password-only, this is the moment to add multi-factor authentication, since you are touching it anyway. See VPN setup and management.
- Cloud and vendor portals. The firewall vendor's support portal, the domain registrar, the hosting account, the backup service. These are frequently registered to one person's email address and are the hardest to recover later.
- Anything with a key rather than a password. SSH keys, API tokens, and certificates issued to their machine.
Write down what you changed as you go. This list becomes the first page of documentation the business has ever had.
Week one: find out what you actually have
Once access is contained, the question becomes what exists. Most businesses in this position cannot answer basic questions: how many servers are running, what is reachable from the internet, which supplier has remote access, when anything was last patched.
Start with what faces outward, because that is what an attacker sees and it is usually the shortest list. Then work inward to servers, then to the network itself. A network security assessment exists precisely for this situation and produces the inventory as a by-product, but a competent internal person with a week can make real progress on the first two.
What usually turns up
The findings are remarkably consistent across businesses that have just lost their only technical person.
There is nearly always a remote access account belonging to a supplier who did a project years ago and never had access removed. There is usually a firewall rule opened during troubleshooting that was never closed, frequently something broad pointed at a server that no longer does what it did. There is often a server nobody can identify the purpose of, which nobody is willing to switch off. Backups usually exist and have usually never been restored as a test, so nobody knows whether they work or how long recovery takes.
None of this indicates the departing person was bad at their job. It is what happens when one person carries an entire infrastructure without time, budget or a second pair of eyes.
The handover document that should have existed
Whatever you build now, build it so the next departure is not another emergency. It does not need to be elaborate. It needs to exist, live somewhere the business controls rather than on one laptop, and be accurate.
- A network diagram showing sites, links, firewalls, switches and servers. Hand-drawn and correct beats generated and stale.
- An inventory: what each server does, who the supplier is, when support expires.
- Where credentials live, and who can reach them. A password manager the business owns, not a spreadsheet on a desktop.
- Which supplier to call for what, with the account numbers they will ask for.
- What the backup schedule is and when it was last restore-tested.
If you want a structure to work to rather than inventing one, the NIST Cybersecurity Framework organises this under its govern and identify functions, and is readable in an afternoon. The CIS Critical Security Controls open with asset and software inventory for exactly this reason. It is unglamorous and it is the foundation everything else rests on.
The hiring question
The instinct is to hire a replacement quickly and hand them the same undocumented estate, which reproduces the problem with a new name attached. If the role genuinely needs a full-time person, hire one, but give them the documentation as a first deliverable rather than an eventual one.
Where the business is not large enough to justify a full-time specialist, a smaller internal role for day-to-day support with external engineering for the network and security work is usually more resilient. Not because it is cheaper, but because knowledge sits with more than one person. Our managed services are structured this way.
What to do this week
Change the firewall and server administrative credentials today if you have not already. Then list, on one page, everything reachable from the internet. If you cannot produce that list, that is the finding, and it is the first thing to fix. Everything else can wait a fortnight. Those two cannot.