If your IT provider walked away tomorrow, could a competent replacement pick up your environment and run it without guessing? For most Australian businesses of 10 to 200 staff the honest answer is no. An IT documentation set is the written record of every system, device, account, licence, supplier relationship and recovery procedure your business depends on, kept accurate enough that someone who has never seen your environment can take it over without reverse engineering it.
Undocumented IT is a business risk, not an IT inconvenience
The bill for missing documentation never arrives on a quiet Tuesday. It arrives at five specific moments, and all five are already bad days.
An outage, where the question is not “can we fix it” but “what exactly is running on that box, and who do we ring at the vendor”. A staff departure, where the one person who knew how the ERP integration was configured has just served notice. A provider change, where the incoming team spends its early months discovering your environment instead of improving it, and bills you for the privilege. An insurance renewal or client security questionnaire, where you are asked to list systems holding personal information and you cannot. And a due diligence process during a sale, where an inability to produce an asset register and access records turns into a price adjustment.
The regulatory side is blunter than most owners expect. Australian Privacy Principle 11 requires an APP entity to take reasonable steps to protect the personal information it holds from misuse, interference and loss, and from unauthorised access, modification or disclosure, and to destroy or de-identify it in certain circumstances (OAIC, Australian Privacy Principles quick reference). Reasonable steps is an evidentiary standard. You demonstrate it with records, not with recollection.
The Notifiable Data Breaches scheme sharpens it further. Where you have grounds to suspect an eligible data breach, section 26WH(2) of the Privacy Act 1988 requires a reasonable and expeditious assessment, and you must take all reasonable steps to complete that assessment within 30 calendar days of becoming aware of the grounds. The OAIC’s stated expectation is that 30 days is treated as a maximum, not a target. Assessment means scoping: which systems were touched, whose data sat in them, what left the building. You cannot scope an environment nobody has mapped, and the clock does not pause while you work out what you own.
Worth naming the trade-off honestly: if your business turns over $3 million or less a year, the small business operator exemption may mean the Privacy Act does not apply to you at all. The exceptions are broad, though, and they catch a lot of Melbourne SMBs: health service providers holding health information, businesses trading in personal information, contracted service providers under a Commonwealth contract, and reporting entities under anti-money laundering legislation (OAIC, Small business). Check which side of that line you sit on before deciding it does not concern you. Your clients’ security questionnaires will not care either way.
What a complete set contains
Nine things. If your provider has given you fewer, you have a partial set.
1. Asset register. Every device, physical and virtual: make, model, serial, purchase date, warranty expiry, assigned user, location, operating system and current patch state. This is also where the security frameworks start. The ASD Essential Eight maturity model requires an automated method of asset discovery at least fortnightly under Patch applications, specifically to support subsequent vulnerability scanning. You cannot patch what you have not discovered, and you cannot report on what you have not recorded. If you are still tracking this in a spreadsheet, read our piece on asset management for a growing business before you buy anything else.
2. Network diagram and IP addressing. The ASD Information Security Manual’s Guidelines for networking call for network documentation to be developed, implemented and maintained, including high-level diagrams showing all connections into the network and logical diagrams covering critical servers, network devices and network security appliances, along with their settings. In practice that means a current diagram, an IP address plan, VLAN allocations, firewall rules with a stated purpose for each, VPN configuration and internet service details with account numbers. Add rack elevations and patch schedules for the physical layer, which is where comms room design and documentation meet.
3. Identity and access records. Every user account, service account, shared mailbox and group, with what each one can reach and who approved it. Service accounts are the ones that get missed, and they are the ones that outlive their creators.
4. Licence and subscription register. What you hold, per tenant and per user, with renewal dates, term commitments and the billing owner. This is the single most common source of a nasty surprise at renewal, and the second most common source of an audit exposure.
5. Supplier and account ownership. Every vendor, the account number, the support contract level, the escalation path, the phone number that actually reaches a human, and critically the name of the person at your business who owns the relationship. Domain registrar and DNS belong here, and they are usually the worst documented item in the whole environment.
6. Backup and recovery runbooks. Not “we back up to the cloud”. What is backed up, to where, how often, how long it is retained, when it was last restore-tested, and the step by step procedure to bring each system back. A backup you have never restored is a hypothesis.
7. Standard build and configuration baselines. The known-good state for a workstation, a server, a firewall and a mobile device. Baselines are what let you say “this machine is compliant” without opening it. The ISM’s Guidelines for system management also expect software registers covering workstations, servers and network devices, maintained with versions and patch history and verified regularly.
8. Change history. What changed, when, why, who approved it and how to reverse it. Without this, every incident investigation starts from zero.
9. The credential store. Which is its own conversation.
Credentials do not belong in the documentation system
This is where a lot of otherwise decent documentation goes wrong. Passwords, API keys, certificates, recovery codes and PINs should live in a dedicated secret store, not in a wiki page, not in a spreadsheet called Passwords_FINAL.xlsx, and not in a shared mailbox.
The separation matters for a practical reason. Documentation needs to be widely readable inside your business so it is actually used. Secrets need to be narrowly readable, individually attributable and revocable in seconds. Those two requirements pull in opposite directions, so you satisfy them with two systems and a link between them: the documentation record names the credential, the secret store holds it, and access to the store is granted by role rather than by person.
A business-grade password manager gives you role-based vaults, per-user identity, multi-factor authentication on the vault itself, an audit log of who viewed which secret and when, and the ability to revoke one person’s access without a mass reset. A spreadsheet gives you none of that, and it also gives you no way to answer the only question that matters after a departure: what did they have access to. Our guide to business password management covers the selection criteria in detail.
Two rules that are worth stating plainly. Break-glass credentials for your global admin and firewall accounts should be printed, sealed and stored physically, with a documented procedure for opening the envelope, because a secret store you cannot log into is not much use during an identity outage. And every credential in the store should have a named owner and a rotation trigger tied to your onboarding and offboarding checklist, not to a calendar reminder nobody honours.
The sharp question: if you leave, do you get it?
Here is the part your current provider would rather you did not read.
If you gave notice tomorrow, what would you receive? Not “would they help”, but specifically: which documents, in what format, within how many days, and is any of that written into your agreement? Most SMB managed services contracts are silent on it. Silence favours the incumbent.
The pattern we see repeatedly with new clients is a partial handover: a PDF export missing the credential store, an asset list months out of date, no network diagram at all, and a domain registrar account still sitting under the outgoing provider’s login. That last one is not a documentation failure, it is a control failure, and it is remarkably effective at making a client stay. Anyone who has taken over an undocumented cloud tenancy knows the shape of this: our post on inheriting a tenancy nobody documented walks through the recovery work involved.
Four things to check in your agreement this week.
Ownership. Does it state that documentation, asset records and configuration data relating to your environment are your property, not work product owned by the provider? If it is not stated, assume it is contested.
Format and portability. A handover in a proprietary format you cannot open is not a handover. Ask for machine-readable exports: CSV or JSON for registers, PDF or image for diagrams, and a documented export path from the secret store.
Registrant and tenant control. Your domain registrar, DNS zone, Microsoft 365 or Google Workspace tenancy and your certificate authority accounts should be registered to your business, with a director or nominated staff member holding a global administrator account. Your provider should have delegated access, not sole possession.
Exit and handover. Termination is usually the thinnest clause in an SMB managed services agreement, and it is the one that decides how your last month goes. Look for four specifics by name: a transition assistance clause that lists the deliverables, a timeframe expressed in business days from notice, a stated format for each deliverable, and whether that transition work is included in your fee or billed hourly. Check as well that the intellectual property clause does not quietly claim configuration data and documentation as the provider’s work product, and that there is an obligation to return or destroy your data rather than simply stop using it. If any of those are missing, that is the amendment to raise at renewal, because it is a far easier conversation to have while you are happy than while you are leaving.
Documentation rots, so tie it to change rather than to a review
An annual documentation review is a promise everyone makes and nobody keeps. The moment it slips once, the set is stale, and a stale set is arguably worse than none because people trust it.
The fix is structural. Documentation updates become an exit condition of the change, not a task that follows it. A change is not closed until the record is updated. That means:
- New device deployed? Asset register updated as part of provisioning, ideally automatically from the management platform rather than by hand.
- Staff member starts or leaves? Identity records and credential access updated as part of the onboarding or offboarding run, same day.
- Firewall rule added? Diagram and rule register updated before the change ticket closes.
- Licence purchased or cancelled? Subscription register updated at the point of purchase, by whoever raised the order.
- System restored from backup? Runbook updated with what actually happened, because that is when you discover the runbook was wrong.
Automate the parts that can be automated. Device inventory, software versions, patch state and licence assignment can all be pulled from your management and identity platforms on a schedule, which removes the largest and most tedious category of manual updates. The parts that cannot be automated, meaning the diagrams, the runbooks and the supplier relationships, are the parts a human has to own, and they should be reviewed on a fixed cadence with a named person accountable for each.
The trade-off is real: tying updates to change makes every change slightly slower. That is the cost, and it is worth paying. A change process that produces accurate documentation as a by-product is the only one that stays accurate.
Audit your provider this week
Send one email. Ask for these six items, and give a deadline.
- A current asset register export, in CSV, with serial numbers and warranty dates.
- The network diagram, dated within the last six months, plus the IP addressing plan.
- A licence and subscription register with renewal dates and the billing owner.
- Confirmation of who holds the registrant details for your domain and who holds global administrator on your cloud tenancy.
- The date of the last successful restore test, and which system was tested.
- The clause in your agreement that covers documentation handover on termination.
What comes back tells you most of what you need to know. Items arriving within a couple of days means the documentation exists and is maintained. A request for time to compile means it is being assembled for the first time. Silence, or a phone call asking why you are asking, means the answer is no. If you want a broader sweep of your environment while you are at it, our annual IT audit checklist covers the other governance items worth reviewing in the same pass.
If those six requests come back thin, we will do the documentation build for you and hand it over in a format you own, whether or not you move your managed services across. Call TechAssist on 1300 028 324 or get in touch at https://techassist.au/contact/ and we will scope it against your actual environment.