A rotation that reaches every client
Set a quarterly recurring schedule and assign each run to an auditor from a group, so every client is audited at least once a year and larger or fast-changing clients more often. The grid view shows who is due.
MSP Client Documentation Audit Checklist Template
Documentation decays one ticket at a time. An engineer fixes something late at night, means to update the record and doesn’t. A year later the record describes a network that no longer exists, and nobody notices until an outage.
Every MSP depends on its documentation platform. It is how a technician who has never visited a client can fix their firewall at 7am, how a new hire learns the estate and how the service desk knows who is allowed to ask for a new admin account. It is also the system most likely to be quietly wrong. Records are created carefully during onboarding and then updated only when someone remembers. This free MSP client documentation audit checklist tests one client’s records against your documentation standard, section by section: credentials and the password vault, network and infrastructure, configurations and assets compared with the RMM, applications and vendors, and contacts and procedures. Each section is scored, gaps become tickets in the PSA and the service manager signs off the result. When the overall score falls below your threshold, a remediation phase sets a deadline and a re-audit, so a poor result is fixed rather than just filed.
The Platform Holds the Record. The Audit Checks It Is Still True.
Most MSPs already ask engineers to update documentation as part of closing a ticket. That catches changes someone knew they had made. It does not catch the switch a client’s office manager added, the laptop that was retired without anyone telling you, the contact who left, or the password that was changed by a vendor during a support call. Those gaps only show up when somebody deliberately compares the record with the real environment.
A documentation audit is that comparison, done on a schedule by someone who doesn’t work on the account every day. The auditor works from evidence rather than memory: the RMM device list, the directory, the PSA contacts, a login test. Because every client is scored against the same standard, the result can be compared across clients and over time, which shows where the documentation process itself needs fixing.
Upkeep at ticket close
Continuous, but partial
Done by: whichever engineer worked the ticket.
Catches: changes the team made and remembered to record.
Misses: changes made by the client, vendors or nobody in particular.
Scheduled documentation audit
Periodic, but complete
Done by: an auditor who is not the client’s primary engineer.
Catches: missing, stale and orphaned records, tested against live data.
Produces: a score, remediation tickets and a signed-off result.
What the MSP Documentation Audit Checklist Covers
Six phases audit one client from preparation to a signed-off score. Phase 7 appears only when the overall score falls below your pass threshold.
Phase 1
Phase 1: Prepare the Audit
- Select the client and auditor — next in the rotation, audited by someone who is not the client’s primary engineer
- Open your documentation standard — the required record set for this client’s service tier and the scoring rules
- Export the comparison data — RMM device list, directory users, PSA contacts and agreement, and the licence list
- Review the last audit — the previous score, its weakest sections and any remediation tickets still open
Phase 2
Phase 2: Credentials & Access
- Confirm a vault entry for every critical system — domain registrar, DNS, Microsoft 365 or Google admin, firewall, Wi-Fi, ISP, backup and line-of-business admin
- Test a sample of credentials — log in to three or four systems and record any entry that no longer works
- Find credentials outside the vault — passwords in tickets, notes, spreadsheets or a former engineer’s personal account
- Check changes after trigger events — credentials rotated after a leaver, a departed provider or a suspected compromise
- Check emergency access and MFA records — break-glass accounts documented, and who holds each MFA method for shared admin logins
Phase 3
Phase 3: Network & Infrastructure
- Compare the network diagram with the RMM and a scan — sites, links, switches, firewalls and access points that are missing or retired
- Verify IP addressing — subnets, VLANs, DHCP scopes and static assignments match what is configured
- Check firewall, VPN and wireless records — firmware version, support status and the date of the last configuration backup
- Check internet circuits — provider, circuit ID, support number, contract end date and failover arrangement
- Verify domains, DNS and certificates — registrar, DNS host, renewal dates and who at the client receives the renewal notices
Phase 4
Phase 4: Configurations & Assets
- Reconcile asset records against the RMM — every managed device has a record, and every record is a device that still exists
- Check server and key device records — role, operating system version, warranty, backup coverage and recovery notes
- Archive stale records — retired devices, old configurations and expired licences moved out of the live record
- Check lifecycle data — warranty and end-of-support dates complete enough to feed the client’s roadmap
Phase 5
Phase 5: Applications, Vendors & Contacts
- Check line-of-business application records — vendor, version, support contact, licence details and the client’s internal owner
- Check vendor and contract records — support contracts and renewal dates for everything you rely on but don’t supply
- Verify client contacts — compare with the directory and PSA, remove leavers and confirm who can authorise changes
- Test one client-specific procedure — follow it step by step, such as adding a new user, and note anything out of date
- Check out-of-hours information — emergency contacts, site access arrangements and where to find them
Phase 6
Phase 6: Score & Sign Off
The sign-off is an approval step. Remediation tasks stay locked until the service manager approves the score.
- Score each section — against your documentation standard, with a note on every item that lost points
- Calculate the overall score — as a percentage, compared with the client’s previous audit and your pass threshold
- Raise remediation tickets — one PSA ticket per gap, assigned to the client’s primary engineer with a due date
- Approve the audit result — the service manager reviews the score, the evidence and the tickets
- Share the result with the account team — the score, the trend and anything the vCIO or account manager should know
Phase 7 — Below Threshold
Phase 7: Remediation & Re-Audit
Shown only when the overall score is below your pass threshold. Conditional logic keeps it out of audits that pass.
- Set the remediation deadline — commonly 30 days, agreed with the service manager and the client’s primary engineer
- Find the cause of the drift — skipped updates at ticket close, an unrecorded project, a staff change or changes made by the client
- Fix the process, not only the records — a ticket-close step, a project closure task or a change to the standard
- Re-audit the failed sections — by the same auditor, using fresh exports
- Record the re-audit score — and bring the client forward in the rotation if it still fails
A Scoring Model You Can Apply to Every Client
An audit is only comparable if every auditor scores the same way. The model below weights the sections by what it costs when they are wrong. A missing registrar login can take a client’s email offline for days; an out-of-date printer record costs a few minutes. Score each item 2 (complete and verified), 1 (present but incomplete or unverified) or 0 (missing or wrong), then weight the section totals.
| Section | Minimum standard | Evidence the auditor checks | Weight |
|---|---|---|---|
| Credentials & access | Every critical system in the vault, owned, working | Sample logins, trigger-event history | 30% |
| Network & infrastructure | Diagram, addressing, circuits and renewals current | RMM data, a scan, registrar and DNS records | 25% |
| Configurations & assets | Records match managed devices in both directions | RMM export compared with asset records | 20% |
| Applications & vendors | Owner, support contact and renewal for each | Vendor portals, contracts, client confirmation | 15% |
| Contacts & procedures | Authorised contacts current; procedures tested | Directory, PSA contacts, a procedure walkthrough | 10% |
Pick a pass threshold and keep it stable, so scores mean the same thing from quarter to quarter. Many MSPs start around 80% and raise it as their documentation matures. Treat any zero on a critical credential as a fail for that section, whatever the overall percentage says. Then watch the trend as well as the number. A client whose score falls at two audits in a row usually has a process problem, such as a new engineer who was never shown the standard or a project that closed without updating the records.
Two pieces of guidance worth building in
- Inventories are a security control. The NIST Cybersecurity Framework 2.0 lists maintained inventories of hardware, of software and services, of network data flows and of supplier services as separate outcomes. A documentation audit is how an MSP shows those inventories are maintained, not just created.
- Rotate on events, not the calendar. NIST’s current password guidance (SP 800-63B-4, 2025) says passwords should not be changed on a fixed schedule but must be changed when there is evidence of compromise. That is why Phase 2 checks rotation after a leaver, a departed provider or a suspected breach, rather than password age.
The joint MSP advisory from CISA, the NCSC and their partners also tells MSPs to treat every account with access to customer environments as privileged and protect it with MFA. The audit is a regular point to confirm that is still true for each client.
Why Run Documentation Audits in CheckFlow?
Evidence, not ticked boxes
Exports, login test results and scan output are uploaded to the task they support. When the service manager reviews the score, or a client asks how well their estate is documented, the evidence is there with dates.
A failed audit leads to a fix
When the score falls below your threshold, conditional logic adds the remediation phase, with a deadline, a root-cause task and a re-audit. Low scores get worked on, not just filed.
Documentation is where many MSP processes either hold or fall apart. The MSP process management guide explains how process management sits between documentation and execution, and CheckFlow for MSPs runs audits like this one alongside onboarding and client reviews.
The first documentation for a client is built during the MSP Client Onboarding Checklist, and this audit keeps it accurate afterwards. The lifecycle data it checks feeds the vCIO Technology Roadmap Review, and for writing procedures that hold up when tested, see our IT runbook guide.
Frequently Asked Questions
What is an MSP documentation audit?
It is a scheduled check of one client’s records in your documentation platform against your documentation standard. The auditor compares the records with live data from the RMM, the directory and the PSA, tests a sample of credentials and one procedure, and scores each section. Gaps become tickets, and the service manager signs off the result. Over time the scores show which clients, and which parts of your process, need attention.
How often should client documentation be audited?
At least once a year for every client, and more often for large or fast-changing ones. A common pattern is a quarterly schedule that works through a rotation, so a quarter of your clients are audited each quarter. Audit sooner after anything that disturbs the records: a major project, a change of primary engineer or a failed audit.
Who should carry out the audit?
Someone who knows your documentation standard but does not work on the client every day. The primary engineer reads the records through their own memory and fills gaps without noticing them. A peer from another team, a service desk lead or a dedicated documentation owner will follow the records as written, which is exactly how a stranger would use them during an outage.
What score should count as a pass?
It is your choice, but make it explicit and keep it stable so scores are comparable. Many MSPs start around 80% and raise the bar as their documentation matures. Weight the sections by risk, and treat a missing or broken credential for a critical system, such as the domain registrar or global admin, as a failure regardless of the overall score.
Should the audit force password changes?
Not on age alone. NIST’s current guidance says passwords should not be changed on a fixed schedule, but must be changed when there is evidence of compromise. The audit checks that credentials were changed after the events that matter: a leaver in your team or the client’s, a previous provider’s departure or a suspected breach. Any credential found outside the vault should be treated as exposed and changed.
Can the documentation platform’s own reports replace the audit?
They help. Some platforms flag empty fields, records that haven’t been updated for a long time and devices without a matching record. They can’t tell whether a password still works, whether a diagram matches the comms cabinet or whether a procedure still produces the right result. Use the reports as the starting point and the audit to test what the reports can’t.
Is CheckFlow free for this template?
14-day free trial, no card required. The Business plan is $10 per user per month after the trial. Full details at checkflow.io/pricing.