Insights / Guide / Managed IT services and infrastructure support
GuideDocumenting your IT environment
Clear records make support faster and reduce dependence on a few individuals. This guide covers what to document, how to keep it current and where to start.
In many organisations, the most complete record of the IT environment is in one person’s head. They know which server runs the payroll export, which supplier holds the domain name, where the firewall password is kept and why the warehouse printers need restarting on Mondays. That works until they are on holiday, unwell or moving to a new job.
Clear records make support faster and reduce dependence on a few individuals. They also make audits, insurance renewals, supplier changes and security incidents far less stressful. This guide sets out the three core records every organisation should keep, how to build them without a large project and how to keep them current once they exist.
Why documentation slips
Almost every IT team agrees that documentation matters. Few have documentation they trust. The reasons are familiar: there is always something more urgent; nobody owns it; it was written once for a project and never updated; or it lives in so many places that nobody can find the current version.
The fix is not a heroic documentation sprint that produces hundreds of pages. It is a small set of records, kept in one place, with clear owners and simple habits that keep them current. Aim for documentation that is good enough to be used every week, rather than complete enough to impress once.
Record systems and owners
Keep a current list of systems, owners and contracts. This is the foundation for everything else. A spreadsheet is a perfectly good starting point; a dedicated tool can come later if the estate is large.
What to record for each system
- Name and a one-line description of what it does for the business.
- Business owner, who decides how it is used, and technical owner, who keeps it running.
- Supplier and contract details: contact routes, support hours, renewal date and notice period.
- Licences: type, quantity and what they permit.
- Hosting: on premises, cloud or software as a service, and where.
- Criticality: what happens to the business if it stops, and how quickly it must be restored.
- Key dates: version, end of vendor support and planned upgrades.
Include the less obvious items. Domain names, certificates, internet connections, telephone lines, cloud subscriptions taken out by individual departments and small tools built on spreadsheets or scripts all belong on the list. They are frequently the items that cause trouble because nobody knew they existed until they stopped working or expired.
Contracts and renewals
Add renewal dates to a shared calendar with a reminder well ahead of each notice period. Many organisations roll over contracts they meant to renegotiate simply because the notice date passed unnoticed.
Building the list in practice
- Export what you can automatically: device lists from management tools, subscriptions from cloud portals and licence counts from supplier accounts.
- Ask finance for a list of recurring IT payments; every regular invoice points to a system, service or contract.
- Hold a short session with each department head to capture the tools their teams use, including ones IT did not buy.
- Merge the results into one list, remove duplicates and flag anything without an owner.
- Agree owners for the flagged items within a fortnight, or schedule them for retirement.
The finance route is often the most revealing. Department-level subscriptions paid on company cards rarely appear in IT records, yet they may hold customer data or support a process the business depends on.
Draw the connections
Diagrams show how systems depend on each other. When a problem occurs, a clear picture of what connects to what can save hours of diagnosis. When a change is planned, it shows what else might be affected.
Three diagrams cover most needs. They do not have to be beautiful. They have to be accurate and easy to update.
- A network diagram: sites, internet connections, firewalls, main switches, wireless networks and links to cloud services.
- An application map: the main business systems and the integrations between them, showing what data flows where and how often.
- A service view for each critical service: the applications, servers, databases, network components and external suppliers it depends on.
Keep each diagram dated and stored with the system list, so anyone can see when it was last checked. Where tools can generate network or dependency maps automatically, use them as a starting point, but have the owners confirm the result. Automated discovery finds connections; people know which ones matter.
Consider a typical mid-sized distributor whose order system stops sending dispatch notes to customers one morning. Without an application map, the team checks the email server, then the order system, then the network. With one, they see immediately that dispatch notes pass through an integration service that was patched the night before, and start there. The map took a day to draw; it paid for itself on its first use.
Keep access records
Know who has access to what and review it regularly. Access records matter for security, for compliance and for practical reasons such as removing access promptly when someone leaves.
- Maintain a list of administrator and privileged accounts for every critical system, with a named person responsible for each.
- Store shared credentials and recovery codes in a secure password manager, never in spreadsheets or emails.
- Record who can approve access to each system, usually the business owner.
- Link joiner, mover and leaver processes to access changes, so roles and permissions follow people as they change jobs.
- Review access to critical systems at least quarterly, and remove anything no longer needed.
Pay special attention to accounts held by suppliers. Former providers sometimes retain access long after a contract has ended. Include them in every review.
Keep it current
Documentation only stays useful if updating it is part of everyday work rather than a separate task. A few habits make the difference.
- One place: all IT documentation lives in a single, searchable location that the team and key suppliers can reach.
- Change control includes a documentation step: a change is not closed until records and diagrams are updated.
- Each record has an owner and a last-reviewed date.
- A quarterly review checks the system list, diagrams and access records against reality.
- New starters in IT use the documentation to learn the environment and report anything that is wrong or missing.
- Managed service contracts require the provider to maintain documentation and hand it over in full on exit.
We stopped asking whether the documentation was complete and started asking whether someone could use it at two in the morning.
Head of IT, professional services firm
Where to start
Do not try to document everything at once. Start with the system list, focusing on your ten most critical services, their owners, suppliers and renewal dates. Next, draw a simple network diagram and an application map. Then review privileged access for those same critical systems. Within a month, you will have the core of a record that makes support faster, holidays less risky and the next audit considerably calmer.
A useful test of progress is to ask someone who did not write the documentation to answer a few practical questions using only what is written down: who supports the finance system out of hours, what depends on the main file server, and who has administrator access to the firewall. Where they cannot find the answer, you have found the next gap to fill.
Source: Intelliversal analysis.
