IT Documentation for SMBs: The 6 Documents That Make the Difference (With Templates)
Daniel Sarica
Published: April 22, 2026
Document 1: The IT System Inventory (2–4 hours)
A table with everything that exists in your IT infrastructure:
System | Type (physical/VM/cloud) | Location | Owner | Criticality (critical/medium/low) | Last updated | Notes
What to include: physical and virtual servers, cloud services (Microsoft 365, Azure, AWS, Google Workspace), business applications (ERP, CRM, email, accounting), network equipment (firewalls, switches, access points), backup systems, network printers.
A quick test: if tomorrow you had to explain everything in your infrastructure to someone from the outside, could you do it in 30 minutes with this document? If yes, it’s good enough. It doesn’t have to be perfect. It has to exist.
Update: with every infrastructure change, at minimum once per quarter.
Document 2: The Network Diagram (2–3 hours)
A diagram that shows how things are connected. It doesn’t need to be technical down to the VLAN and subnet level; it needs to show the general flow:
- what’s in the cloud and what’s on-premises
- how the offices connect (if there’s more than one)
- where the VPNs are
- what’s exposed to the internet
- where the critical data lives
Tool: draw.io (free), Visio, or even a scanned sheet of paper. What matters is that it exists, not that it looks nice.
At a 90-employee company, I drew the diagram together with their IT admin in about 2 hours. It was the first time in 6 years that anyone had put on paper what the network looked like as a whole. They discovered an old OpenVPN server still active that they had completely forgotten about; nobody used it anymore, but it was an open access point into the network. And they discovered that two systems they thought were isolated were in fact on the same network as the file server.
Update: with every network change, at minimum every six months.
Document 3: The Access Register (3–4 hours)
Who has access to what, focused on privileged (admin) access:
System | User | Access level | Granted by | Date | Justification
Plus three things that are usually missing:
The IT onboarding process
Which accounts get created for a new employee, in what order, who approves. Ideally: a checklist that HR sends to IT the day the contract is signed, not the day the person walks in.
The IT offboarding process
What gets deactivated when someone leaves, who verifies it, within what timeframe. Ideally: everything gets deactivated on the day of departure, not “when IT gets around to it.”
Review frequency
Who checks quarterly whether access rights are still justified. Does someone who moved from sales to accounting still need access to the CRM?
Last month I counted 11 active accounts belonging to former employees at a single company. Not because someone forgot with bad intent; there simply was no process linking an employee’s departure to the deactivation of their accounts.
Update: with every onboarding/offboarding, quarterly review.
Document 4: The Backup Documentation (2–3 hours)
Not just “we have automatic backups.” Concretely:
System | What gets backed up | Where | Frequency | Retention | Last restore test | Estimated full restore time
Plus the restore procedure — the actual steps, detailed enough that someone who didn’t set up the backup could perform a restore. And a test log: date, what was tested, how long it took, the result.
One company received the “backup completed successfully” email every day for 2 years. When they needed a restore after a ransomware incident, they discovered the backup hadn’t saved anything in 8 months because of a Veeam configuration error. The email only confirmed that the script had run, not that it had actually saved anything. The cost: 3 weeks of downtime and tens of thousands of dollars.
If you haven’t tested a restore in the last 3 months, you don’t have backups. You have hope.
Update: with every change, monthly testing (30 minutes: restore a random file, confirm it works).
Document 5: The Vendor and Contract List (1–2 hours)
Vendor | Service | Monthly cost | Emergency contact | Renewal date | Exit terms | Internal owner
It sounds trivial, but in many companies nobody has this list complete in one place. The information sits in different inboxes, with different people.
At a company with 3 different IT vendors, a file server went down one morning. The CEO called the IT vendor. The IT vendor said the problem was the network. He called the network vendor. They said everything was fine on their end. Six hours went by and nobody had fixed anything, because nobody had the complete picture of who was responsible for what.
Update: quarterly.
Document 6: The Incident Procedure (3–4 hours)
A 1–2 page document that answers one question: if something happens, who does what.
- Emergency contacts: internal IT, IT vendor, management, CISA (report@cisa.gov), the FBI’s IC3 (ic3.gov), your attorney, your cyber insurance carrier
- Who assesses the severity of the incident
- Who decides to shut down systems (if necessary)
- Who communicates internally (employees) and externally (customers, partners)
- Reporting obligations: your state’s data breach notification law, sector rules where they apply (HIPAA’s 60-day breach notification for health data, the SEC’s 4-business-day disclosure for public companies), and your cyber insurer’s notification deadline
- A short communication template: “We have identified an incident affecting [X]. The team is working on a fix. Next update at [time].”
Testing: at least once every six months, a 30-minute exercise. “It’s Thursday morning and the email server is down. What do we do?” Then you see who knows what to do and who doesn’t.
Where to store them
Two places, always:
- Digital: a dedicated folder on SharePoint/Google Drive, with controlled access
- Offline: a PDF copy on a USB stick or external hard drive, in a cabinet you can reach even when the servers are down
The second copy seems excessive right up until the moment the servers really don’t work and you need your hosting provider’s phone number or the restore procedure.
Who maintains them and how long the whole thing takes
IT writes them. Management asks for them, allocates the time, and checks quarterly that they’re up to date. If management doesn’t ask for them, they will never get done — because IT always has something more urgent to fix. Documentation isn’t urgent until the day it becomes critical.
Total from zero: 3–5 days for a dedicated IT person. Not necessarily consecutive — spread across 2–3 weeks, a few hours a day.
The cost: a few days of work. The cost of not having them: in one recent case, about $13,000 in external consulting and 37 days until things stabilized after the departure of the only person who knew everything.