Who Holds the Keys to Your Business?

Quick question: if the person who manages your technology walked out the door today, could you log into your own systems tomorrow morning? If you hesitated, keep reading.

Let’s paint a scenario with a fictitious company called “Cacao Sips.” They’re an up-and-coming beverage chain with several locations in the metro area.

When Bill, the founder, started the business, he went to the only person he knew who knew computers: his neighbor, Zach. Zach did a pretty good job getting things going with one store. He set up a network, the point-of-sale system, and even a couple of TVs for the guest experience. Then the second store opened, and he just carried on with what he did the first time. The same went for the third and fourth stores. By this point, Zach was starting to feel like he was in charge of technology for the whole company. Everything ran through him, and he saw a long, comfortable future ahead of him.

But as the fifth store opened, Bill noticed that a few things just weren’t working right anymore. As an example, to check on his stores, he had to use a different security camera portal for each location, each with its own login, and a couple of them wouldn’t load at all. Nobody at his stores could really tell him why, and Zach said he’d look into it but that it worked fine for him. So Bill reached out to a local IT support company. They came in, did an assessment, and found consumer firewalls that weren’t set up properly or even suited for use in restaurants. The guest Wi-Fi wasn’t segmented from the rest of the network, and that was only the start. Bill approached Zach about these issues and got brushed off; as far as Zach was concerned, they were non-issues. With that, the local IT company was hired to fix the problems and help the business grow.

This is where it gets bad. Zach didn’t share any of the passwords, network design, or account information with Bill. Nobody had ever asked him to, and Zach never thought to write any of it down. It all lived in his head, and he wasn’t in a hurry to change that. Somewhere along the way, this knowledge had become his guarantee of employment. Meanwhile, Bill was running a growing business on systems he couldn’t even log into. The end result was that the local IT company had to take Bill’s stores offline one at a time to rebuild the network, document everything, and retrain staff on the newly configured systems.

Cacao Sips is made up, but this story plays out more often than you’d think. The real problem wasn’t Zach, and it wasn’t really Bill either. It was that nobody owned the documentation. Zach’s knowledge was what kept things running, and that’s exactly the problem. If he had an accident, took a new job, or just stopped answering his phone, Bill’s business would be stuck. So, whose problem is this? Bill’s. Documentation isn’t just an IT task, it’s something the business owns, and that’s what we’ll dig into next.

Documentation Is Yours

Documentation is everything when it comes to a business’s technology. It’s the passwords and the network design. It’s the vendor contacts and the admin accounts. It’s the basis for how your business functions, and it’s vital to day-to-day operations. Unfortunately, some technology and IT service providers don’t document, don’t share, or, even worse, use it as leverage against the business.

Think of it this way: you hired a company or person to manage your technology, the same as you would hire someone to write your advertising copy. You paid for the work, so it’s yours. That includes the documentation.

What You Own (and What You Don’t)

There is one important distinction, though. The credentials should be yours, but only for the software you own the license to. For example, here at Wolverstone Solutions, we encourage our clients to pay for their Microsoft software directly, and we’ll help you do that as part of our onboarding process. Other software, like antivirus (or better yet, endpoint detection and response software), is licensed to the provider, so the credentials for it stay with the provider.

Documentation platforms work the same way. The platform your IT provider uses to store your documentation is licensed to the provider, which means your access to it can be revoked. That’s why you should ask for regular exports of your documentation in a format you control.

Vendor Lock-In Without the Contract

When most people hear “vendor lock-in,” they picture a long contract or some proprietary platform they can’t get out of. Sometimes that’s true. More often, it’s quieter than that. Lock-in happens when you don’t have enough information to leave.

Go back to Cacao Sips. Nothing forced Bill to stay with Zach. There was no contract holding him there. But Bill couldn’t log into his own systems, didn’t know what he owned, and couldn’t explain to anyone else how it was put together. Zach never needed a contract. The missing information did the job for him.

If you can’t identify your licenses, admin accounts, network equipment, backup systems, or vendor relationships without asking your current provider, then your provider controls your next move. Not you.

That doesn’t mean your provider is a bad actor. In most cases, the documentation exists. It just lives in a tool built for the provider’s workflow instead of yours. The trouble shows up when a contract ends, a technician leaves, the company is sold, or an emergency forces someone else to step in. That’s when missing documentation stops being an inconvenience and becomes a business risk.

A confident IT provider shouldn’t be afraid of an informed client. Clear documentation actually makes the relationship better. You know what you have, your provider has an accurate baseline, and both sides can have honest conversations about risk, budget, and priorities.

What Should Be in the Package

A documentation package doesn’t need to be fancy. It needs to be accurate, current, secure, and usable by whoever would need it during a transition or an emergency. Here’s what we’d expect to see:

• Administrative access records: Domain credentials, cloud tenant ownership, registrar access, firewall administration, and any other privileged accounts. Basically, everything Zach kept in his head.
• Network diagrams: Internet circuits, firewall placement, switches, wireless access points, VLANs, VPNs, and important IP ranges.
• System inventory: Servers, workstations, printers, phones, network devices, operating systems, warranties, and lifecycle notes.
• Licensing and subscriptions: Microsoft 365, line-of-business applications, security tools, backup systems, domains, certificates, and renewal dates, plus whose name each one is registered under.
• Vendor and support contacts: Internet providers, software vendors, hardware support, payment processors, and any other third party you’d need to call when something breaks.
• Backup and recovery procedures: What is backed up, where it’s stored, how often it’s tested, and who can authorize a recovery.
• Operational notes: Standard procedures, recurring maintenance, known quirks, escalation paths, and change history.

Keeping It Secure

Owning your documentation doesn’t mean printing out the passwords and leaving them in an unlocked drawer. It doesn’t mean a spreadsheet called “passwords” on the shared drive, or a sticky note on the monitor, either. (Please, PLEASE don’t do these.)

Think about what’s in that package: your admin accounts, your network design, your backup and recovery procedures. Whoever holds it effectively holds the keys to your business. In the wrong hands, it’s a roadmap for an attacker. In the right hands at the wrong time, like a former employee or a former provider, it can still cause real damage.

Cacao Sips had the opposite problem. Bill couldn’t get to anything. But the answer isn’t to swing the other way and let everyone have everything. The goal is controlled access, not uncontrolled exposure. You need to be able to get to it, and almost nobody else should.

Here’s how we approach it at Wolverstone Solutions:

• A secure home: Your documentation lives in a password manager or protected repository, not in email, a shared folder, or a spreadsheet.
• Limited access: Only leadership and designated staff can get to it, and there is a named owner on your side of the table.
• Multi-factor authentication: Required for anyone who touches it, no exceptions.
• Regular access reviews: We review who has access on a schedule, and any time someone leaves or changes roles, or the provider relationship changes.
• An emergency plan: An offline or emergency-access process for a true disaster, so the answer to “what if Zach has an accident?” is never “we wait.”
• A check at every review: At each technology business review (TBR), we check whether the emergency account has been accessed since the last one. If it has, credentials are reset and we find out why it was accessed, even when the use was authorized.
• Keeping it current: Documentation is reviewed on a regular schedule, because a package you can’t trust is almost as bad as no package at all.

When Things Go Wrong: Recovery and Staff Changes

Disaster recovery is where weak documentation becomes painfully visible. Backups matter, but backups alone don’t answer the questions that show up in the middle of a crisis. Which systems come back first? Who is allowed to approve a restore? Where are the credentials kept? Who do you call at the internet provider, and what has to be running before anything else will work?

Now try answering those during a ransomware attack or a fire at your busiest location, with nobody who knows the answers picking up the phone. That is not the day to start writing things down. Bill’s rebuild meant taking his stores offline one at a time. A real disaster doesn’t give you that luxury.

The same principle applies any time people change. A key employee retires, a technician leaves, you switch providers, or the business changes hands. Good documentation is the difference between a controlled handoff and expensive rediscovery. Nobody should have to reverse-engineer their own environment. Bill paid for exactly that.

Conclusion

IT documentation isn’t busywork. It’s an ownership record, a recovery tool, a transition plan, and a safeguard against avoidable disruption. You should absolutely work with a competent IT provider, but you should also keep enough usable knowledge to stay in control of your own business.

At Wolverstone Solutions, we believe good IT service should make you more resilient, not more dependent. Keeping your documentation in your hands, and keeping it secure, is part of that.

Bill didn’t lose control because Zach was a bad guy, or because he picked the wrong person. He lost it because nobody ever asked who owned the keys. Ask that question now, before you need the answer. A simple place to start is asking your provider, “If you disappeared tomorrow, could I keep my technology running?” If the answer isn’t an easy yes, we’d be glad to help.

A business that owns its documentation owns more than passwords and diagrams. It owns options.