Google guarantees that Gmail and Drive stay available. It does not guarantee that a file one of your staff deleted in March is recoverable in June. Those are different promises, and the gap between them is where Australian businesses lose data they legally have to keep.
Backing up Google Workspace means holding an independent copy of your Gmail, Drive, Shared drives, Calendar, Contacts and Chat data, outside the tenancy and outside the control of the accounts that use it, that can be restored to a chosen point in time. Nothing included with a Workspace licence does that.
The shared responsibility line, stated plainly
Google is responsible for the infrastructure: keeping the service running, keeping the data centres up, protecting against hardware failure, and replicating your data so a disk or a site failure does not lose it.
You are responsible for what happens inside your tenancy: what your users delete, what an attacker who has your password deletes, what a departing employee takes or destroys, and how long you keep records you are legally obliged to keep.
Google’s replication is not a backup, because replication faithfully copies the deletion. If a file is gone from the live system, it is gone from every copy of the live system. The question is never whether Google still has your data somewhere. The question is whether Google will give it back to you, and for how long.
What Google actually retains, and for how long
These are Google’s published windows. They are shorter than most business owners assume, and they are not adjustable.
Drive trash: 30 days. By default, Drive permanently deletes files 30 days after a user moves them to their trash. The user can restore them during that window.
Admin recovery after the trash is emptied: 25 days. If a user empties their trash, an administrator can recover deleted Drive items for a further 25 days from the Admin console. After that, Google purges the items and states they cannot be recovered.
Deleted user accounts: 20 days. If you delete a user and do not transfer their files at the time, Google deletes those files 20 days later. Restoring the account inside that window is the only route back.
Deleted Gmail: a comparable window and no more. Admins can restore a user’s permanently deleted email for a limited period after deletion, and after that Google purges it.
Shared drives: deleting a shared drive removes its content, with a limited administrative restore window rather than an indefinite one.
Audit logs: mostly six months. Most log event types are retained for six months. Email log search is 30 days. Chrome reports are 12 months. Administrators cannot delete log event data or change how long it is kept.
Put those together and the practical position is this: you have roughly a month to notice an ordinary deletion, and slightly less if the deletion happened through an account that was then removed. If your only detection mechanism is somebody looking for a file, you will regularly miss the window.
Vault is not backup, and Google says so
This is the most expensive misunderstanding in the Google ecosystem, because Vault is genuinely good at its actual job.
Google Vault is an information governance and eDiscovery tool. It lets you retain, hold, search and export Gmail, Drive, Calendar, Chat, Meet recordings, Groups, Sites, Voice and Gemini data. It is included with Business Plus, Frontline Standard and Plus, Enterprise Standard and Plus, all Education editions, Enterprise Essentials and Enterprise Essentials Plus for domain-verified accounts, and G Suite Business, and it is available as an add-on licence for some other editions. Since 1 November 2025 administrators need a Vault licence themselves in order to use it.
Here is why it is not backup, in Google’s own terms.
Vault does nothing until you configure retention rules. Google states it directly: Vault does not retain data until you set up retention rules, and until you do, users can delete data and services can purge it on their normal schedule. A tenancy with Vault licensed and no rules configured has exactly the same recovery position as a tenancy without Vault.
Vault is not an archive. Google’s documentation says Vault retention rules are applied to the live data systems of the underlying services and that Vault is not a data archive. When a retention period ends and the data is not on hold, it is subject to normal deletion, and once purged it cannot be recovered by users or admins.
Vault deletes as well as retains. Retention rules cut both ways. A rule configured to purge data after a set period will purge it, permanently, on schedule. That is the intended behaviour for a governance tool and the opposite of what you want from a backup.
Vault exports, it does not restore. You can search retained data and export it. You cannot press a button and put a user’s Drive back the way it was on Tuesday. Recovering a mailbox from a Vault export is a manual reconstruction project, not a restore.
Vault dies with the licence. Google’s documentation warns that if you delete a user or a required licence, their data may be irreversibly purged and no longer available to Vault. A backup that disappears when you stop paying for the platform it protects is not an independent copy.
Vault is bounded by the tenancy. If you lose administrative control of the tenancy, you lose Vault along with everything else. That scenario is covered in losing admin access to the tenancy.
Vault is the right tool for legal hold, for eDiscovery, and for enforcing a retention policy. Use it for those. Do not put it in the recovery column of your business continuity plan.
The four scenarios that actually cause data loss
Ransomware and account compromise. The modern version does not encrypt a file server. An attacker takes a password, signs in, and works through Drive and Gmail from inside a trusted session. Files are deleted, shares are changed, mailbox rules are created. Google’s systems replicate every one of those actions correctly, because from the platform’s point of view an authenticated user is doing normal work. Your recovery position is the 30 day trash window and whatever the attacker did not bother to empty.
The malicious insider. Someone resigns badly and spends their notice period deleting or exfiltrating. Because they own the files, most of it is legitimate activity that no security control will block. Detection after the fact depends on Drive log events, which are retained for six months, and recovery depends on those same short windows.
Departing staff and the 20 day clock. This is the quiet one, and it is almost always self-inflicted. An employee leaves, someone deletes the account to stop paying for the licence, and nobody transfers the files. Twenty days later the data is gone, including files that were the only copy of a client project. Google’s own guidance is to transfer ownership of Drive files and Calendar events before deleting, or to suspend rather than delete, or to archive the account. A proper offboarding checklist prevents this entirely, and it is a five minute change to the process.
Ordinary human error found too late. A folder is deleted in the last week of the financial year and nobody notices until the accountant asks for it in October. There is no window left, no matter how good your excuse is.
The Australian angle you cannot configure your way out of
Record keeping. The ATO requires businesses to keep records that explain their transactions, generally for five years. Employment, contractual and industry-specific obligations frequently run longer. Google’s Drive and Gmail recovery windows are measured in weeks. Vault can hold data for five years if you configure a rule to do it, which is a governance answer rather than a recovery answer, and only on the editions that include it.
Privacy Act and the NDB scheme. Under the Notifiable Data Breaches scheme, loss of personal information counts alongside unauthorised access and disclosure. If personal information is destroyed and you cannot recover it, you may still have a notifiable breach on your hands and an assessment obligation the OAIC expects you to complete within 30 calendar days. Being able to say precisely what was lost, and to restore it, materially changes both the assessment and the notification.
Where the copy lives. If you take a third-party backup, ask where the backup itself is stored, because that answer may be different from where Workspace stores your live data. Workspace data regions offer United States, Europe or no preference, with no Australian option, so an Australian-hosted backup can end up being the only Australian copy you have. That question is worked through in where your business data actually lives.
What a real backup covers, and what to look for
We are not going to name a product, because the right one depends on your edition, your data volume and where you need the copy to sit. These are the criteria that separate a real backup from a file sync with good marketing.
Independent credentials and an independent blast radius. The backup must not be accessible with the Workspace admin credentials it is protecting. If compromising your super admin account also lets someone delete the backups, you have one copy, not two.
Coverage of everything, not just Drive. Gmail with labels and folder structure intact, My Drive, Shared drives, Calendar, Contacts, Chat, and Sites if you use them. Shared drives are the common gap, because they are owned by the organisation rather than a user and some tools skip them.
Point-in-time restore, not just latest. You need to restore to the day before the deletion, not to the current state. Daily is the minimum, more often is better.
Granular restore back into the tenancy. Restoring a single message to a single mailbox, or a folder to its original Drive location with permissions intact, without the user having to reimport a zip file. Export-only tools are recovery projects, not restores.
Retention you set, decoupled from your Workspace licence. If you need seven years, the backup should hold seven years regardless of whether the user is still licensed, still employed, or still exists.
Immutability and deletion protection. Backups that cannot be altered or deleted for a defined period, including by an administrator, so that an attacker who gets in cannot destroy the recovery path.
Data location you can specify and evidence. Ask where the data is stored, in writing, and ask what happens on termination.
A tested restore. An untested backup is a hypothesis. Restore something real, on a schedule, and document that you did. Cyber insurers and client security reviews increasingly ask for evidence of the test, not the policy.
The general architecture behind all of this is covered in how business cloud backup should be structured.
What to do this week
Check your Workspace edition and whether Vault is licensed and whether any retention rules exist, because a licensed Vault with no rules is a common and misleading finding. Check your offboarding process for the account deletion step and add a file transfer before it. Confirm someone owns the alerting so a mass deletion gets noticed inside days rather than months. Then decide whether a third-party backup is warranted, and if it is, scope it against the criteria above rather than on price alone.
Tightening the tenancy itself is a separate and complementary job, covered in hardening the tenancy itself and the Admin console settings that matter. Backup reduces the consequence of a bad day. Hardening reduces how often you have one.
We can tell you in one session what your current recovery position actually is, including which retention windows you are relying on without realising it. Call 1300 028 324 or start at techassist.au/contact.
Most Google Workspace tenancies in Australian small business are running close to the settings they had on day one. The good news is that the highest-value hardening steps cost nothing and are available on every edition. The bad news is that several controls your cyber insurer or your client’s security questionnaire asks about are only sold in the Enterprise and Frontline tiers, and no amount of configuration substitutes for them.
Hardening Google Workspace means changing the Admin console settings that govern identity, application access, data sharing and monitoring so that a stolen password, a malicious add-on or a departing employee cannot quietly take your data with them. Do it in the order below, because each phase makes the next one worth doing.
Why this matters in Australia specifically
Under the Privacy Act, APP 11 requires you to take reasonable steps to protect personal information. If you hold personal information and you suffer unauthorised access, disclosure or loss that is likely to result in serious harm, the Notifiable Data Breaches scheme obliges you to assess it and, if it qualifies, notify the OAIC and the affected individuals. The OAIC’s position is that you must take all reasonable steps to complete that assessment within 30 calendar days of becoming aware of grounds to suspect an eligible breach.
Two practical consequences follow. First, you cannot assess a breach you cannot see, which is why logging and alerting sit high in this plan rather than at the end. Second, the reasonable steps standard is judged against what was available to you, and 2-Step Verification is free on every Workspace edition.
Cyber insurance questionnaires now ask the same handful of questions: is MFA enforced on all users and all administrators, is email filtering in place, are backups separate and tested, and can you detect and investigate an incident. Answering those honestly is easier if you have already done the work. Your obligations under the Notifiable Data Breaches scheme covers the reporting side in detail.
Phase 0: find out which edition you are actually on
Before you plan anything, check Billing, then Subscriptions, and write down the exact edition name. Business Starter, Business Standard, Business Plus, Enterprise Standard, Enterprise Plus, Frontline Starter, Frontline Standard, Frontline Plus and the Essentials editions all differ, and several of the controls people assume are standard are not.
Also check whether all your users are on the same edition. Mixed tenancies are common after growth or acquisition, and a policy that relies on an Enterprise feature will silently not apply to the Business Standard users sitting next to them.
Phase 1: identity, because everything else is downstream of it
This phase is free on every edition and delivers most of the risk reduction.
Enforce 2-Step Verification for everyone. Not just admins. Set it under Security, then Authentication, then 2-Step Verification, and set a new user enrolment period so joiners are not locked out on their first day.
Move admins to phishing-resistant methods. Google’s own admin security guidance names security keys as the most secure form of 2SV and the one that resists phishing, because a hardware key will not authenticate to a lookalike domain. Codes delivered by SMS or voice call do not resist phishing or SIM swap. Set the allowed methods to exclude text and call codes at least for administrators and anyone who can move money. Enrol a second key per admin and store it separately. The broader case is in phishing-resistant MFA.
Fix the admin account structure. More than one super admin, each held by a separate person. Separate super admin accounts from the daily accounts those people use for email. Delegate routine tasks to limited prebuilt roles rather than handing out super admin. No shared generic admin logins, because the audit log cannot attribute a change to a person if three people use the same account.
Create a break-glass account and prepare recovery. A super admin account that belongs to the business, not used daily, with printed backup codes and a spare security key stored physically. Google’s guidance to keep signup and billing details on hand exists because those are the questions support asks during account recovery. If you skip this, read recovering a locked admin account now rather than later.
Consider the Advanced Protection Program for super admins. Google positions it as applying many of the admin hardening recommendations at once for high-risk accounts. It requires security keys or passkeys and restricts third-party app access to the account, which is exactly what you want on an account that should be doing nothing except administration.
Note the enforcement clock. Google is progressively enforcing 2SV on administrator accounts, with super admins notified roughly 90 days ahead and other admins roughly 60 days ahead, and escalating access restrictions after the date. Getting ahead of that is free.
Phase 2: close the doors nobody remembers opening
Still free on every edition, and this is where most tenancies have never been touched.
Restrict OAuth and third-party app access. Security, then Access and data control, then API controls. Review the accessed apps list first, then move Gmail and Drive to Restricted so that apps you have not explicitly trusted cannot use the high-risk scopes, allowlist the apps the business genuinely uses, and change the Unconfigured third-party apps setting so that unclassified apps get sign-in information only or nothing. Expect breakage: Google states that restricting a service stops previously installed untrusted apps and revokes their tokens.
Block less secure app access. Anything still authenticating with a username and password rather than OAuth is a standing bypass of your 2SV enforcement. Find it, migrate it, then block it.
Set Drive external sharing deliberately. Apps, then Google Workspace, then Drive and Docs, then Sharing settings. Default new items to restricted rather than link sharing, warn users when they share outside the organisation, and leave the external file indicator on. Allowlisted domains is stronger if your external collaborators are stable.
Turn on the Gmail safety settings. Spoofing and authentication protections against domain and employee-name impersonation, advanced phishing and malware protection for attachments, links and external images, and enhanced pre-delivery message scanning. Then publish SPF, DKIM and DMARC in DNS, and check that your DMARC policy is not still sitting at p=none doing nothing.
Audit Gmail routing rules. Attacker-created routing and forwarding rules survive password resets and do not show up in the user’s own settings. Check the list now and check it again after any suspected compromise.
Restrict Calendar and Chat externally. Free or busy only for external calendar visibility, and external chat limited to the people who need it.
The detail on each of these, including the trade-offs, is in the Admin console settings that carry real risk.
Phase 3: be able to see what happened
Set up admin email alerts. Suspicious sign-in attempts, admin role changes, settings changed by another admin, compromised devices. This is available without an Enterprise licence and it is the difference between finding out in an hour and finding out in a quarter.
Use the alert centre. It aggregates Google-generated security alerts in the Admin console under Security. Assign someone to actually look at it weekly, because an alert nobody reads is not a control.
Know your log retention before you need it. Google retains most log event types for six months, Email log search for 30 days, Chrome reports for 12 months, and Vault log events indefinitely. Administrators cannot extend those periods. If your obligations or your insurer require longer, export on a schedule.
Licence reality: the alert centre and the audit and investigation page are broadly available. The security investigation tool, which is what makes hunting across those logs fast, is listed by Google for Frontline Standard and Plus, Enterprise Standard and Plus, Education Standard and Plus, Enterprise Essentials Plus and Cloud Identity Premium. On Business tier you can still answer a question you know how to ask. You cannot easily go looking.
Phase 4: control which devices get in
Turn on endpoint management. Basic mobile management is broadly available and gets you an inventory, a screen lock requirement and remote wipe of work data. Advanced mobile management and desktop endpoint verification give you more, including the device signals that Context-Aware Access depends on.
Endpoint verification installs on managed desktops and reports device attributes back to Workspace. On its own it gives you an inventory of the computers accessing company data, which is more than most SMBs have.
Licence reality: Context-Aware Access is not on Business Plus. This is the one that catches people out. Context-Aware Access, which lets you allow or block access to Gmail, Drive and other services based on device state, IP address, geography or operating system, is supported on Frontline Standard and Plus, Enterprise Standard and Plus, Education Standard and Plus, Enterprise Essentials Plus and Cloud Identity Premium. Business Plus does support App access protection, which is a narrower control, but it is not the same thing. If a client questionnaire asks whether you enforce conditional access on managed devices only, and you are on a Business edition, the honest answer is no.
A warning that matters. Applying Context-Aware Access levels to the Admin console itself can create a total admin lockout if the conditions become unmeetable. Google’s documented remedy is a support case through the Customer Care Portal to strip the policies off the Admin console. Test on a pilot organisational unit first, and never apply an untested access level to the top-level unit.
Phase 5: control the data itself
Licence reality: Drive DLP needs Enterprise or Frontline. Data loss prevention rules for Drive, which scan content for things like credit card numbers, tax file numbers and custom patterns and then block or warn on sharing, are supported on Frontline Standard and Plus, Enterprise Standard and Plus, Education Fundamentals, Standard and Plus, and Enterprise Essentials Plus. If you are on Business Standard or Business Plus, you do not have Drive DLP, and the substitute is tighter sharing defaults plus the external shares report, which is coarser but real.
Data regions are US or Europe only. There is no Australian data region option in Workspace. The choices are United States, Europe or No preference, availability varies by edition, and the policy covers a defined list of core services. If your requirement is genuinely that Australian personal information stays onshore, say so plainly to whoever is asking rather than pointing at this setting.
Vault is retention and eDiscovery, and it needs a licence. Vault is included with Business Plus, Frontline Standard and Plus, Enterprise Standard and Plus, all Education editions, Enterprise Essentials and Enterprise Essentials Plus for domain-verified accounts, and G Suite Business, and is available as an add-on for some other editions. Since 1 November 2025 admins have needed a Vault licence themselves to use it. Vault also does nothing until you configure retention rules. It is not backup, and treating it as backup is the single most common mistake in this space. That argument is set out in backup is a separate problem.
Client-side encryption exists for Gmail, Drive, Meet and Calendar in the higher tiers, and is worth considering only if you genuinely hold regulated or high-value intellectual property, because it changes how search and collaboration behave.
The licence tier summary, stated plainly
Free on every edition, and worth more than anything you can buy: 2-Step Verification enforcement, admin role separation, multiple super admins, OAuth and API controls, Drive sharing defaults, Gmail safety settings, SPF, DKIM and DMARC, admin email alerts, and the audit and investigation page with six month retention.
Needs Business Plus or above: Vault for retention and eDiscovery.
Needs Enterprise Standard or above, or the equivalent Frontline tiers: Context-Aware Access, Drive DLP, the security investigation tool, and the more granular data region controls.
If your risk profile genuinely requires the second and third groups, the licence cost is the cheapest part of getting there. If it does not, spend the money on the first group being done properly and on backup, and do not buy Enterprise to tick a box you will never configure.
How this maps to the Essential Eight
The ACSC and ASD Essential Eight is the framework Australian clients, insurers and government buyers actually reference. Several of its mitigation strategies map cleanly onto Workspace controls, particularly multi-factor authentication and restricting administrative privileges. Others, notably application control, patch applications, patch operating systems and macro settings, are endpoint controls that Workspace does not address at all and that you have to solve on the devices themselves. The full mapping, including where Workspace genuinely cannot help, is in meeting the Essential Eight on Google Workspace, and the framework itself is covered in the Essential Eight explained.
Settle who can raise a support case before you need one
This belongs in the plan rather than at the end of it. Contacting Google Workspace support requires the Support administrator privilege and access to the Admin console, so the people most likely to need support during an incident are exactly the people who may not be able to reach it. Standard Support is included with your licence, has 24/7 access and carries a four hour service level objective for P1 cases, and Google’s published hours of operation table lists Australia as 24/7 in English, so there is no overnight gap to design around.
If someone outside the business is going to open cases for you, Google documents two arrangements. A reseller who manages your subscription can access your Admin console and submit support cases for you unless you remove that access, controlled under Account, then Reseller management. Separately, you can assign a Support Partner in the Google Cloud Support Portal, after which Google states that partner can file cases on your behalf and see cases you filed yourself. Both switches need a working admin sign-in, which is the whole point of doing it now.
Do it in this order
Phase 1 in a week. Phase 2 over a fortnight with a change window for the OAuth restrictions. Phase 3 the same week, because it costs nothing. Phases 4 and 5 only after you have confirmed your edition supports them and someone owns the ongoing tuning.
The mistake to avoid is buying Enterprise licences first and configuring nothing. A Business Standard tenancy with enforced security keys, restricted OAuth scopes and tight sharing defaults is meaningfully safer than an Enterprise Plus tenancy running defaults.
We are listed in Google Cloud’s partner directory, and Workspace hardening is ordinary work for us rather than a side project. We do this as a fixed-scope uplift: an audit against the list above, a written plan with the licence implications spelled out, and the changes made in staged windows so nothing breaks unannounced. Call 1300 028 324 or start at techassist.au/contact.
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.