Back to Blog
Operations

Five Asset Documentation Mistakes That Come Back to Bite MSPs

· Pinar Ormeci
Network asset documentation on a whiteboard

Asset documentation is one of those MSP tasks that everyone knows is important and almost nobody keeps current. The record is accurate at onboarding and deteriorates from there. By the time it matters during an incident, the documentation is describing an environment that was replaced eight months ago.

Here are five specific mistakes that cause the most damage, and what to do instead.

1. Documenting at onboarding and never updating

The onboarding asset audit produces the most accurate snapshot of a client environment you will ever have. Then it sits untouched while the environment changes around it. Firewalls get replaced. Cloud platforms get added. Software versions get updated. None of it is reflected in the documentation until an incident forces someone to look and discover the discrepancy.

The fix is to tie asset record updates to ticket closure. When a ticket involves a change to a documented asset, updating the record is part of closing the ticket, not an optional follow-up task.

2. Storing assets without context

An asset record that says "Cisco ASA 5506" is less useful than one that says "Cisco ASA 5506, serial SN-29183, primary internet gateway, managed interface at 192.168.1.1, admin credentials in vault entry ASA-PROD-ACME, last config backup 2025-10-15." The difference between those two records is measured in minutes of incident resolution time.

Asset records should include: device role, network position, associated credentials, firmware or software version, last verified date, and any known quirks or non-standard configurations. This takes three extra minutes at documentation time and saves 15 minutes at incident time.

3. Not linking assets to runbooks

An asset record and a runbook for that asset stored in different systems or sections is still a search problem. When a tech needs to reset a switch or restart a service, they should be able to get from the asset record to the relevant runbook in one click, not two application switches and a search query.

The link between an asset and its runbooks is one of the highest-value relationships in an MSP knowledge system. If your tool does not support it natively, build it manually through consistent naming conventions as a minimum.

4. Using only one level of categorization

Categorizing assets as "servers," "workstations," "network," and "peripherals" is a start, but it breaks down past 50 assets per client. A server room with 20 different machines needs subcategories: production servers, dev/test, file and print, backup appliances, virtual hosts. The category structure determines how fast a tech can find the right record under pressure.

5. No "last verified" timestamp

A record with no last-verified date is a record with unknown reliability. It might be current. It might be two years out of date. A tech reading that record cannot tell. Including a verified date (even if that date is old) tells the tech what they are working with and creates implicit accountability: an unverified record is a visible liability, not an invisible one.

Set a quarterly review cycle for critical assets and a semi-annual cycle for lower-risk assets. Make the review task visible in your ticketing system so it does not get lost.