Ask Your IT Provider for Your Own Documentation. Here Is What Should Come Back.

Your IT documentation should not be a mystery folder that only your provider can open. Ask for the asset list, the people with administrator access, a recent successful restore test, the licences and registrations held in your name, and a record of important changes. Five things. A well-run account should be able to produce them without a week of detective work.

This is a fair request, even if you have worked happily with the same provider for years. You may need those records for a board, an insurer, a new provider or simply the person taking over from your current finance lead. And you should be able to understand what comes back without hiring another IT person to translate it.

Kane's view is straightforward: if a provider runs your environment, it should be able to show you what it runs. inSUPPORT documents the environment before it assesses the gaps and keeps the technical record connected to the work it does. Use the email and the five checks below to see where you stand with your current provider.

Ask for these five things

An asset register showing the devices, servers and services you rely on.
A named list of who can administer them, including outside providers.
Evidence that a backup was restored and checked, with a date and result.
Proof that your domains, licences, tenancy and data are held in your name.
A useful history of changes and the person who approved them.

What to ask for, and what should come back
What the reply tells you
Why the documentation is the product, not a favour
Questions people ask before they send the email

What to ask for, and what should come back

Keep the request short and specific, because a vague request earns a vague reply. Five items, each with a plain description of what you want, and a date. You are not inventing a standard here. ASD's Information Security Manual already sets out the registers and records a well run environment keeps, and the five below map onto them. That manual is written for government systems, and nobody expects a 60-person business to run it line by line. What it does mean is that the list is not one provider's opinion against another's.

Send it to whoever manages your account, copy the person who signs the invoices, and give them until the same day next week. Write the five items out in full rather than asking for "our documentation", because the general request is the one that comes back as a phone call offering to talk you through it. You want artefacts, not a conversation.

Notice what is not on the list below. Not the full network diagram, not a password list, not the provider's internal procedures. ASD's own point about network documentation is that it can help an attacker compromise a network, which is why it is protected rather than passed around, and a password list should never travel by email at all. What you are asking for is the core of your IT provider documentation: the records that describe your environment and prove it can be brought back.

An asset register. Every workstation, server, network device and cloud service the provider looks after, with a support status against each. ASD's manual calls this a networked IT equipment register and expects it to be maintained and regularly verified.
A record of administrative access. Which accounts can administer which systems, who holds them, who authorised them and when that was last reviewed. ASD's guidance for organisations engaging a provider is that the provider's accounts are attributable to it rather than shared, carry the least privilege the job needs, and can be switched on at an agreed time against a specific job ticket. Your business should also hold at least one administrator account of its own, in its own tenant, that still works when the provider cannot be reached.
Evidence of a tested restore. Not the backup schedule. The date somebody restored data from backup and confirmed it came back usable, which ASD expects to be tested as part of disaster recovery exercises.
Licences and registrations in your name. Your domain names, your Microsoft tenant, your software licences and subscriptions, with the registrant or account holder shown. ASD's manual expects software registers to carry versions and patch histories; this is the finance copy of the same list.
Change history. A log of what was altered in the environment and when: firewall rules, new accounts, retired servers, exceptions granted. Six months of it is enough to show whether one is kept at all, and it is the record that answers what changed just before something broke.

What the reply tells you

The form of the reply tells you more than its contents. Records already in use arrive as a link into a documentation system, an export from a monitoring tool, or a spreadsheet with a last-modified date. Records that did not exist until you asked arrive as a tidy PDF, with everyone's name spelled correctly. Only one of them was running your environment before you sent the email. Question six of the twelve worth asking before you renew puts it in a line: a link, not a promise to send something through.

Then read for gaps rather than errors. An asset register with no support status has skipped the question that costs money. An access record naming a shared login and no individual is telling you nobody can say who did what. A restore confirmed by a green tick in a console reports that the job ran, not that the business comes back. Anything in the provider's name rather than yours is what you would be negotiating over if you ever decided to change IT providers.

Be fair about what a thin answer means. Documentation slips in busy shops, and a provider who asks for a few more days and then delivers has answered well. What deserves attention is the shape of the pushback: the request treated as an insult, or the records called the provider's property. ASD's guidance to organisations engaging a managed service provider puts that record on your side of the line: identify which systems each provider can reach and how, and keep it current.

A link or an export beats a PDF. Live records carry a last-modified date and a trail of who touched them; assembled ones carry a cover page.
"Everything is documented" is an adjective. Ask for the item itself, and if what comes back is an offer to walk you through it, ask again in writing.
Check the dates on the face of each record. A register verified eleven months ago and a restore last tested two years ago are different problems, and only one of them is urgent.
Registrations in the provider's name go to the top of the follow-up list while the relationship is still friendly. Domain names and cloud tenants are the awkward ones to move later.
A defensive reply is worth more attention than a slow one. Lateness is usually a workload problem. Ownership language is a structural one.

Why the documentation is the product, not a favour

Every serious moment starts with somebody asking for the records. An incident responder wants the asset register and the change history first, because that is how they work out what was reached. An insurer's questionnaire asks for evidence that controls exist, not a statement that they do. A buyer's due diligence asks what is registered to whom. A new provider's first job is discovery, and how long that takes depends on what the last one wrote down.

That is why IT provider documentation cannot be a favour done on request. ASD's Information Security Manual, written for government systems rather than for your business, records that data ownership resides with a service provider's customers, and expects contracts to document which data is yours, how it is protected after the arrangement ends, and your access to your own logs. Those are clauses rather than settings, which puts them in the lane of whoever signs the agreement. inSUPPORT publishes its own answer in its FAQ: your tenancy, domains, accounts and data stay in your name, and documentation and access are handed over on exit.

The other half is when the records get built. Documentation assembled at the exit is a negotiation. Documentation built at the start is a record. The managed IT onboarding opens with a site visit to document how the business operates, before the environment is assessed against the compliance frameworks for that industry. That order is deliberate. An audit is worth something only if the record it leaves is one you can hand to an insurer, a buyer or a board without preparing it first.

Documentation is named as a deliverable in the agreement, with a place it lives, a person responsible for keeping it current, and a date it was last verified.
You hold your own administrator account in your own tenant, and your domain names, licences and subscriptions are registered to the business rather than to whoever set them up.
The agreement says what comes back to you if you leave, and in what format, settled while nobody is leaving and everyone is still reasonable.
You have access to the logs about your own systems, because that is the record that answers what actually happened when somebody eventually asks. ASD recommends event logs be kept for at least 18 months, and that a provider be obliged to hand over detailed logs when you have a security concern to investigate.

Questions people ask before they send the email

What documentation should my IT provider give me when I ask?

Five records, and every one of them should already exist: an asset register of the devices, servers and cloud services they manage; a record of which accounts hold administrative access and who authorised them; evidence of the last tested restore, with a date; the licences, domain names and subscriptions held in your business's name; and a change history for the environment. These are not a wish list. They correspond to the registers and records set out in ASD's Information Security Manual, which is written for government systems rather than for Australian businesses generally, and a provider running your systems properly is already using them to do the job. What you are testing is whether they can hand them over without building them first.

Do I need someone technical to judge what comes back?

No. Every one of the five items can be read by the person who pays the invoices. An asset register either has a support status column or it does not. An access record either names individuals or it names a shared login. A restore either has a date somebody tested it or it has a screenshot of a green tick. What a technical reader adds is judgement about whether the contents are right, and that is a second step. If the records arrive and you want a second pair of eyes on them, an independent audit reads the same documentation, checks it against the environment, and tells you where the two disagree.

How long should it take, and what if my provider will not hand it over?

A week is fair, and a provider who asks for a few more days and then delivers has given you a good answer. A refusal is different. Ask them to point to the clause in your agreement that makes the records theirs. That is a fair question with a checkable answer: either the clause is there and you can read it, or it is not. ASD's Information Security Manual, written for government systems, puts data ownership and post-contract handling in the contract in writing. Then, before anything else, get your own administrator account in your own tenant and confirm your domain and licences are registered to your business. Do not give notice to any provider before you can reach your own systems without their help.

What should I do if what comes back is thin?

Do not leave over one thin reply, and do not renew on one either. Write down what arrived, what did not, and how the request was received, then get an independent picture of the environment itself. A Cyber Strength Audit documents what actually exists first, then assesses it against the compliance frameworks that apply to your industry, and hands you a plain English report with the gaps ranked by business impact and a costed path to closing them. That report is a document you can take back to your current provider, or use to brief a new one. Either way, you finish with the folder you asked for.

Find out what your records are missing If what comes back is thin, we can help establish the real picture. A Cyber Strength Audit documents the environment, tests the controls and gives you a plain-English plan for the gaps. You get something you can use with a board, an insurer or your current provider. You own the information; the point is to make it useful.

Book a Cyber Strength Audit →

Sources

"Questions to ask managed service providers", Australian Signals Directorate. Five questions ASD sets out for an organisation to put to its managed service provider, one per topic area: Essential Eight implementation, secure administration, monitoring, regular assessment and incident response. Each is a heading on the page, with ASD's explanation beneath it. It is the basis for the point above that asking your provider to show its work is ordinary practice. Last updated 6 October 2021. cyber.gov.au
"How to manage your security when engaging a managed service provider", Australian Signals Directorate. The source for the access record above: know where the boundaries are, identify which systems each provider can access and how, keep that record up to date, and use attributable, least-privilege accounts. Last updated 6 October 2021. cyber.gov.au
"Guidelines for procurement and outsourcing, Information Security Manual", Australian Signals Directorate. States that data ownership resides with a service provider's customers, and carries the controls expecting contracts to document data ownership, protection after the arrangement ends, access to logs, and data portable enough to allow migration and decommissioning. Last updated 3 September 2026. cyber.gov.au
"Guidelines for system management, Information Security Manual", Australian Signals Directorate. Software registers carrying versions and patch histories, and restoration of data, applications and settings from backups tested as part of disaster recovery exercises. Last updated 3 September 2026. cyber.gov.au
"Guidelines for networking, Information Security Manual", Australian Signals Directorate. The source for the exclusions above: network documentation is developed and maintained, and 'as network documentation could be used by malicious actors to assist in compromising networks, it is important that it is appropriately protected'. Last updated 3 September 2026. cyber.gov.au
"Guidelines for information technology equipment, Information Security Manual", Australian Signals Directorate. The networked IT equipment register that is developed, implemented, maintained and regularly verified, which is the asset register asked for above. Last updated 3 September 2026. cyber.gov.au