IT documentation is an asset your business owns

One of the most uncomfortable conversations in IT goes like this. The person who looked after the systems has left, or the relationship with the old provider has ended badly. Someone needs to change a firewall rule, renew a domain or recover an admin account, and nobody knows the password, the account number or even which company the domain is registered with.

When we take over the management of a new environment, the state of the documentation tells me more about the risk ahead than almost anything else. It is also the part of IT that owners and operations leaders most often assume exists and rarely ask to see.

Documentation is a business asset, not an IT chore

It is easy to think of documentation as something technicians write for each other. In practice it pays off for the whole business:

• Continuity. Illness, holidays, resignations and provider changes stop being emergencies.
• Faster fixes. A technician who can read how something is set up resolves issues sooner than one who has to rediscover it.
• Audits, insurance and due diligence. Cyber insurance questionnaires, client security reviews and the sale of a business all ask questions that good documentation answers in minutes.
• Better decisions. You cannot plan a refresh, negotiate a renewal or trim licence spend without knowing what you have.

What your IT documentation should contain

Network

A current diagram showing how the offices, internet connections, firewalls, switches and wireless fit together. The internet circuits, with provider, account number, support phone number and static IP addresses. IP ranges and network segments, and what each is for. Firewall rules with a short note on why each one exists. VPN configuration, and the domain registrar and DNS host for every domain you own.

Accounts and access

Every administrator account, who holds it and what it can do. The emergency access procedure for when normal sign-in fails. Where credentials are stored, which should be a proper password vault with access logging, not a spreadsheet or someone's browser. How MFA is recovered if a phone is lost. Service accounts and what depends on them.

Vendors and contracts

Every technology vendor you rely on: internet providers, software vendors, printer leasing, phone systems, security tools. For each one, the contact details, account number, what the contract covers, renewal date and notice period. Missed renewal deadlines are one of the easiest ways to overpay.

Licences and subscriptions

What you subscribe to, how many seats, who they are assigned to, what they cost, when they renew and who in the business approves them. This is where unused licences for people who left a year ago tend to show up.

Devices and infrastructure

Laptops, desktops, servers, network equipment and printers, with serial numbers, purchase dates, warranty end dates and current user or location. Ideally this inventory is updated automatically by your management tools rather than typed by hand.

Runbooks

Step-by-step procedures for the tasks that matter: onboarding and offboarding a staff member, restoring from backup, what to do when the internet goes down, failing over to a second connection, rotating a compromised password, responding to a suspected phishing incident. A good runbook lets a competent person who has never seen your environment do the task correctly.

Decisions and their reasons

A short record of why things are the way they are. Why the accounting server is still on-premises. Why a certain vendor has remote access. Why one group is excluded from a policy. Without the reason, nobody dares change anything, and old decisions outlive the problems they solved.

What good documentation looks like

The content matters, but so does how it is kept. In my experience, documentation that stays useful shares a few traits:

• It lives in one system. Not in one person's head, laptop or inbox, and not scattered across shared drives.
• It is linked. A firewall links to its vendor, its warranty, its configuration and its runbooks. You can follow the thread from any starting point.
• It is dated. Every page shows when it was last reviewed. An undated page is a page nobody trusts.
• It is part of the work. A change is not finished until the documentation reflects it. Documentation written in a big push once a year is out of date by spring.
• Credentials are protected. Passwords sit in a vault with access controls and an audit trail, not in plain text next to the diagram.

Never held hostage by one person or one provider

This is the part I care most about, and it applies to providers like us as much as anyone. Your documentation and your credentials belong to your organization. No single employee or outside provider should be the only holder of your top-level admin accounts, your domain registrar login or your firewall password.

A few practical safeguards:

• Make sure your organization, not your provider, is the registered owner of your domains, internet circuits and software subscriptions.
• Keep at least one emergency admin credential in the hands of a trusted person inside the business, stored securely.
• Put documentation ownership and handover in writing in any IT services agreement.
• Ask for a full export of your documentation once a year, and look at it.

The test is simple: if you parted ways with your IT provider tomorrow, could a competent replacement take over without guessing? If the answer is no, your current arrangement has a hidden cost, even if everything is working today.

Where to start if you have very little

If your documentation is thin, do not try to write everything at once. Work in order of risk:

1. Admin accounts, the domain registrar and DNS. Losing control of these is the hardest to recover from.
2. Internet circuits and the firewall, including how to reach the provider in an outage.
3. Vendors, contracts and renewal dates.
4. Licences and the device inventory.
5. Runbooks for the five tasks you do most often, then the ones you hope never to need.

How Ceifa handles documentation

Documenting the environment is one of the first things we do when we start with a new client, and keeping it current is part of every change we make after that. Under our managed IT services, the documentation belongs to you, and you can have a copy whenever you ask. For organizations with their own IT team, our co-managed IT model gives both teams one shared, current record to work from. If you are not sure what your documentation looks like today, talk to us and we can help you take stock.

Frequently asked questions

Who should own our IT documentation?

Your organization should. Your IT staff or provider can write and maintain it, but you should be able to access and export it at any time, and any services agreement should say so clearly.

Where should IT passwords be kept?

In a dedicated password vault with individual accounts, access controls and an audit trail of who viewed what. Not in spreadsheets, documents, email or browser password stores shared between people.

How often should IT documentation be reviewed?

It should be updated with every change, and reviewed as a whole at least once a year. Critical items such as admin accounts, emergency procedures and vendor contacts deserve a check every quarter.

What should we ask for when changing IT providers?

A full export of the documentation, all admin credentials, confirmation of who owns your domains, circuits and subscriptions, and a handover meeting. Then change the passwords of every account the old provider could access.