MSP IT Documentation Best Practices: What to Document for Every Client

By David, 2026-10-10

It's 2 a.m. and a client's line-of-business app is down. The on-call technician needs three things: the firewall's admin URL, the name of the vendor who supports the app, and the credential for the service account it runs as. The firewall URL is in a wiki page last edited two years ago. The vendor contact is in someone's inbox. The service account password was rotated last month, and nobody updated the record. Forty minutes go on finding things before anyone starts fixing anything.

That's what poor documentation costs an MSP: not a missing page, but time spent at the worst possible moment, by the person least likely to know the client. This guide covers why documentation decays, a per-client checklist of what to record, a structure that scales past a dozen clients, and how to keep it current. It's vendor-neutral until the section on Atlas Vault.

The short version: keep one record per client and hang everything off it: people, sites, networks, licenses, domains and certificates, credentials, runbooks and vendors. Link items to each other instead of writing long pages that repeat them. Put a date on anything that expires and let the tool remind you, give each client's documentation a named owner, and review it on a schedule rather than when something breaks.

Why documentation decays

Documentation is usually written once, during onboarding, by the engineer who did the onboarding. From then on, every change to the client's environment is a chance for the record to fall behind, and nothing forces it to keep up. A few patterns account for most of the decay:

• No owner. When documentation belongs to "the team", nobody notices that it's wrong until someone relies on it.
• The fix outruns the record. A technician changes a firewall rule or a DNS record during a ticket, closes the ticket, and moves on. The documentation still describes last month's network.
• Wiki sprawl. Free-form pages repeat the same facts in several places. When one copy is updated, the others become quietly wrong, and a reader can't tell which is current.
• Nothing expires visibly. A domain renewal date or a certificate expiry sitting in a paragraph of text is invisible until the site goes down.
• Secrets live somewhere else. When credentials are kept in a separate tool from the documentation that explains what they're for, the two drift apart.

The cost shows up in the same places every time: slower incident response, longer onboarding for new technicians, outages from lapsed renewals, and a painful handover when a client's long-time engineer leaves.

The per-client checklist

Whatever tool you use, every client should have the same core set of records. Use this as a minimum standard: if a technician who has never worked with a client couldn't find one of these in under a minute, it isn't documented yet.

Organization and contacts

• Legal name, trading name, primary address and main phone number.
• Key contacts and their authority: who can approve changes, who can authorize spend, who to call out of hours, and who must never be called at 2 a.m.
• Contract basics: what's in scope, response targets, and any services you explicitly don't support.
• The client's line-of-business applications and who uses them.

Sites and locations

• Every office, data center or colocation space, with its address, opening hours and an on-site contact.
• Access instructions: alarm codes belong with credentials, not in the site description.
• Where the network and server equipment physically sits, ideally with a rack diagram.

Network

• Subnets and their purpose, with CIDR ranges, gateways and DNS servers.
• VLAN IDs and what each one carries (users, voice, guest, management, cameras).
• Site-to-site VPNs and cloud networks, including Azure virtual networks and how they peer.
• Static IP assignments and reserved ranges, so nobody hands out an address a printer already uses.
• Internet circuits: provider, circuit ID, public IP addresses and the support number.

Devices and assets

• Servers, firewalls, switches, access points, printers and other managed devices, with hostname, model, serial number, location and warranty dates.
• What each device does and what depends on it. "Hosts the line-of-business database" is more useful than a model number.
• A consistent set of fields per device type, so every firewall record answers the same questions.

Licenses and renewals

• Every subscription and license: vendor, product, seat count, license key or agreement number, purchase date and renewal date.
• Who pays for it (you or the client) and whether it auto-renews.
• Microsoft 365 and Azure subscriptions, with the tenant they belong to.

Domains, DNS and SSL certificates

• Every domain the client owns, its registrar, the account it's registered under and its expiry date.
• Where DNS is hosted, and the records that matter (mail, verification, remote access).
• Every TLS certificate in use, where it's installed, who issued it and when it expires.

Certificate expiry deserves particular attention, because it's about to happen far more often. Under the CA/Browser Forum's ballot SC-081, the maximum lifetime of a publicly trusted TLS certificate fell from 398 days to 200 days on March 15, 2026, and drops to 100 days in March 2027 and 47 days in March 2029 (DNSimple summary). A certificate you renewed once a year now needs renewing roughly twice a year, and soon about eight times. Anything not renewed automatically needs a date and a reminder.

Credentials

• Admin accounts for every system you manage, service accounts, and the vendor portals you sign in to on the client's behalf.
• For each credential: what it's for, where it's used, when it was last rotated and when it expires.
• Break-glass accounts and where they're kept.

Store as few standing credentials as you can, and keep the ones you need in a store that audits every reveal. Where should an MSP store client credentials? covers the options and the controls to insist on.

Runbooks and procedures

• Onboarding and offboarding a user, step by step, for this client.
• Backup and restore: what's backed up, where, how often, and how to restore it. Test the restore and note when you last did.
• How to fail over or recover each critical system.
• Anything unusual: the server that must be rebooted in a certain order, the app that breaks if you patch on a Tuesday.

Vendors and third parties

• Every vendor that supports part of the client's environment: line-of-business software, internet provider, phone system, copier lease.
• Support numbers, account or customer IDs, contract references, and who at the client is authorized to raise a case.

Copy this as your onboarding checklist: organization and contacts · sites · networks and VLANs · devices and assets · licenses and renewals · domains, DNS and certificates · credentials · runbooks · vendors. A client isn't fully onboarded until each one has at least one record and a named owner.

Structure: one record per client, with linked items

The most common structural mistake is treating documentation as a set of pages. Pages invite prose, prose repeats facts, and repeated facts drift. A better model is a register per type of thing, with every item belonging to a client and linked to the items it relates to.

In practice that means:

• One client record at the top. Every contact, site, network, device, license, domain, credential and document belongs to exactly one client. A technician opens the client and sees everything.
• Structured records, not paragraphs. A firewall has a record with fields for model, IP address, firmware and location. A license has a renewal date field, not a sentence that mentions a date. Structured fields can be searched, sorted, filtered and alerted on.
• Links, not copies. The runbook for restoring the file server links to the file server's asset record, the backup service account's credential and the backup vendor's contact. When the service account password changes, it changes in one place, and the runbook is still correct.
• Templates for consistency. Use the same fields for every firewall and the same headings for every runbook, so technicians know where to look regardless of who wrote the record.
• Prose where it earns its place. Narrative belongs in runbooks and "how this client is different" notes, not in places a structured field would do.

This structure also makes reviews possible. "Show me every license renewing in the next 60 days across all clients" is one filter on a register. In a wiki it's an afternoon of reading.

Keeping it current

Structure stops documentation from becoming contradictory. It doesn't stop it from going stale. That takes process.

Put a date on everything that expires. Domains, certificates, licenses, warranties, contracts and credentials all have an expiry or a renewal date. Record it in a date field and have your tool remind you, typically 30 days and 7 days ahead, so a renewal is a routine task and not an outage.

Track rotation, not just expiry. Many credentials never expire on their own. Record when each was last rotated and set a rotation interval for the sensitive ones, especially shared admin and service accounts. Rotate immediately when someone with access leaves.

Make documentation part of closing the ticket. If a change altered the environment, the ticket isn't done until the record reflects it. Some MSPs add a "documentation updated?" checkbox to their change process. The point is to make updating the record the default, not an extra.

Give every client an owner. One named person is accountable for each client's documentation being accurate. They don't write every record, but they review it.

Review on a schedule. A quarterly review per client, led by its owner, catches what the ticket process misses: contacts who have left, decommissioned devices, vendors that changed. Pair it with the quarterly business review if you hold one, because the client can confirm contacts and authority on the spot.

Keep history. When a record changes, keep the previous version. It answers "what was this before?" during an incident, and it protects against a mistaken edit.

Where the data should live

Your documentation is a map of every client's environment, often with the credentials to get in. Where it lives deserves the same thought you'd give any other sensitive system.

• Who holds a copy. A SaaS documentation platform keeps every client's data in the vendor's cloud, alongside other MSPs' data. A platform deployed in your own Azure subscription keeps the copy in a database you control.
• Who holds the keys. Ask how secrets are encrypted and whose key does it. A key in your own Azure Key Vault is one you can see being used, and can revoke.
• Who can reach it. Documentation should sign in through your own identity provider, so your MFA and Conditional Access policies apply, and should audit who viewed which credential.
• What happens if you leave. Check what you can export, in what format, and whether secrets come with it.

Why customer-owned infrastructure matters goes through these trade-offs in more depth.

How Atlas Vault organizes client documentation

Atlas Vault is the IT documentation and credential store built into Atlas AVD. It's deployed with Atlas into your own Azure subscription, and its data is stored in the Azure Database for PostgreSQL server that Atlas deploys there. This section describes what it does today.

One record per client. Clients live in Companies / Clients, with each company's name, website, industry, primary contact and address. Locations, assets and racks belong to a company, and a company's page lists the contacts linked to it.

A register for each part of the checklist. Vault's registers map closely to the checklist above:

Linked items, not copies. A document's Related items panel links it to the things it describes, with a typed relationship such as "documents", "authenticates", "depends on" or "hosts". A runbook can link to credentials, contacts, assets, networks, certificates, websites and companies, and also to things Atlas manages directly: host pools, virtual machines, scripts and Azure resources. Asset templates can include an asset link field, so a server record can point at the switch it's plugged into.

Expiry reminders that arrive on their own. Atlas Vault checks every day and emails you 30 days and 7 days before a credential, a certificate, a website's SSL certificate or a domain registration expires, and again when it lapses. When you add a website or a certificate, Detect looks up the domain registration and the live certificate so the dates start out right. License expiry shows in the Software & Licenses list as Expiring Soon or Expired. The Vault overview counts credentials Expiring within 30 days and those whose rotation is due.

Runbooks with an owner for each step. Processes turn a procedure into a checklist template. Each step can have an owner, and each time someone clicks Start run, Atlas records who completed each step. That gives you a record of every onboarding, offboarding or restore test, per client.

History on the things that change. Documents keep a Version history you can restore from, and credentials keep the previous secrets so a rotation can be rolled back. Every reveal of a credential is audited.

What stays with your team. Vault doesn't assign an owner to a client or schedule documentation reviews, so set the owner and the quarterly review in your own process, as described above. It also doesn't import from other documentation platforms; credentials import from CSV exports of password managers and from Azure Key Vault JSON.

Atlas Vault is included on every paid Atlas AVD plan from Starter up, including the MSP plans, with no per-technician fee. If you're comparing it with a documentation platform you already use, read Atlas AVD vs IT Glue.

FAQ

What should an MSP document for every client?

At a minimum: the organization and its key contacts, every site, networks and VLANs, devices and assets, licenses and renewal dates, domains, DNS and certificates, credentials, runbooks for common and critical tasks, and every vendor that supports part of the environment. If a technician new to the client can't find one of these in under a minute, it isn't documented yet.

How should MSP documentation be structured?

One record per client, with structured registers for each type of item (contacts, networks, assets, licenses, credentials) instead of free-form pages. Link items to each other rather than repeating facts, and use templates so every record of the same type answers the same questions.

How often should MSP documentation be reviewed?

Update it as part of closing any ticket that changes the environment, and review each client's documentation quarterly with a named owner. Dates that expire, such as domains, certificates, licenses and credentials, should trigger reminders rather than wait for a review.

Should passwords be stored in the documentation platform?

Keeping credentials next to the documentation that explains them stops the two drifting apart, as long as the platform audits every reveal, signs users in through your own identity provider and encrypts secrets with a key you can account for. Store as few standing credentials as you can either way.

What is a good MSP client documentation template?

Start from the checklist in this guide: organization and contacts, sites, network, devices and assets, licenses, domains and certificates, credentials, runbooks and vendors. Turn each section into a structured record type with the same fields every time, rather than one long template document.

How do you stop SSL certificates and domains expiring unnoticed?

Record every domain and certificate with its expiry date in a structured field, and use a tool that emails reminders at 30 and 7 days. With public TLS certificate lifetimes falling to 200 days in 2026 and 47 days by 2029, automate renewal wherever you can and track the rest.

The CA/Browser Forum certificate lifetime schedule is as published in ballot SC-081. Atlas Vault behavior is described as of October 2026.