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

Ask your IT provider for your own documentation and five things should come back inside a week: an asset register, a record of who holds administrative access, evidence of a tested restore, the licences and registrations in your name, and a change history. You do not need to be technical to judge any of them, which is what makes it a fair test. Documented evidence you can hand to a board, an insurer or a client is also what a Cyber Strength Audit is built to leave behind, and inSUPPORT has conducted 1,500 or more cyber audits.

If you have never asked, that is normal. Asking is not an accusation. The Australian Signals Directorate (ASD) publishes five questions organisations should put to a managed service provider, guidance last updated in 2021, so asking yours to show its work is ordinary governance rather than a challenge. It is your environment, and the records describing it are part of what you pay for.

Documentation is easy to let slide, because nobody watches it slide. Tickets get closed, patches get applied, and the diagram from three years ago stops matching the network. A provider can do decent daily work and still be unable to show what it looks after. The gap surfaces on the day you need the records: an incident, an insurer's questionnaire, a sale, a change of provider.

So run the test. One email this afternoon, five items, a week to reply. Below is what each should look like, what a thin answer tells you, and why IT provider documentation is a deliverable rather than a favour.

TL;DR: What to remember

• ✅ One email, five records: assets, administrative access, restore evidence, licences and registrations in your name, and change history. A week is a fair deadline.
• ✅ Records already in use arrive as a link or an export with a last-modified date. Records built after you asked arrive as a tidy PDF a week later. That difference is the test.
• ✅ A thin answer does not prove a bad provider. A defensive answer deserves more attention than a slow one.
• ✅ Documentation is what makes the environment yours. It is the first thing an incident responder, an insurer, a buyer or a new provider asks for.
• ✅ Ownership belongs in the agreement rather than in the admin console: which data is yours, what is handed back if you leave, and who can reach the logs.

Contents

• 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.

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

Related Reading

• Managed IT Services
• Twelve Questions to Ask Your IT Provider Before You Renew
• What Your Provider Should Show You at an Essential 8 Review
• How Long Does It Take to Change IT Providers?
• Cyber Strength Audit

Content reviewed by Probably Genius for accuracy and relevance.

inSUPPORT provides managed IT and cyber security services. It is not an insurer, insurance broker or underwriter and does not hold an Australian Financial Services Licence. Where cyber insurance forms part of a plan, it is arranged through licensed insurance partners and underwritten by the insurer. Cover is subject to the insurer's assessment, the policy terms and the Product Disclosure Statement and Target Market Determination. This article is general information about IT and security practice, not financial product advice, and it does not take account of your objectives, financial situation or needs.