Secure Device Disposal and E-Waste for Australian Business

Two things go wrong at the end of a device’s life, and they go wrong in different directions. The data does not get destroyed properly, which is a Privacy Act problem and potentially a notifiable breach. And the hardware ends up somewhere it is not allowed to be, which in Victoria has been illegal since 2019. A disposal process has to solve both, and most SMB processes solve neither.

Media sanitisation is the process of removing data from storage media so that it cannot be reconstructed. Destruction is physically rendering the media unusable. They are different controls, they suit different devices, and they produce different evidence.

A factory reset is a convenience feature, not a data destruction control

A factory reset is designed to make a device usable by the next person quickly. On most operating systems it removes the file system pointers and the user profile. Whether it removes the data depends entirely on the underlying storage and whether encryption was in play.

The Australian Signals Directorate’s Information Security Manual sets out why a straightforward overwrite is not sufficient on a spinning disk. Modern magnetic hard drives keep a host-protected area and a device configuration overlay table that are normally invisible to the firmware and the operating system, so sanitising the readable sectors leaves anything in those regions untouched. They also reallocate bad sectors into a growth defects table, and data written to a sector before it was reallocated will not be overwritten by ordinary software. The ISM’s answer is to reset the host-protected area and device configuration overlay first (control ISM-1065), and to use the ATA secure erase command in addition to block overwriting software so the growth defects table is covered (ISM-1067).

Flash memory has a different problem. Wear levelling deliberately spreads writes across memory blocks, so a single pass has no guarantee of touching every block. The ISM requires non-volatile flash memory media to be overwritten at least twice in its entirety with a random pattern, followed by a read back for verification (ISM-0359). For hybrid drives, it requires separating the magnetic media from the circuit board holding the flash and sanitising each separately.

The ISM is written for government systems, not for private businesses. The OAIC’s own APP 11 guidance points to the ISM’s media sanitisation section and notes that although it applies to Australian Government agencies, it may be of interest to organisations complying with APP 11.2. That is as close to a benchmark as an Australian SMB is going to get, and it is a good one to be measured against in an audit.

Three methods, and when each is defensible

Factory reset or an OS-level wipe. Acceptable only for a device that was fully encrypted from first use and is staying inside your organisation. Not acceptable as the sole control for a device leaving your custody.

Cryptographic erase. The drive is encrypted, and you destroy the key rather than the data. NIST SP 800-88 Rev. 1 recognises cryptographic erase as a purge technique. It is fast, it works at scale, and it is the mechanism behind Apple’s “Erase All Content and Settings” on Macs with Apple silicon or the T2 chip and on iPhones and iPads, where the volume key is held in dedicated hardware and destroyed on erase. Two conditions have to hold: encryption must have been enabled from the moment the device was first used, and you must trust the firmware implementation. If the device spent its first year unencrypted, cryptographic erase does not reach the data written during that year. Note also that the ISM’s sanitisation controls are built around overwriting and use ATA secure erase in addition to, not instead of, software overwriting.

Physical destruction. The only method that does not depend on trusting firmware. The ISM specifies destruction methods by media type (furnace or incinerator, hammer mill, disintegrator, grinder or sander, degausser, or cutting depending on the media) and requires resulting particles to be no larger than 9 mm. It requires the use of Security Construction and Equipment Committee-approved or ASIO-approved equipment, and where a degausser is used, it also requires the platters to be physically deformed afterwards. Destruction is the right answer for any drive that failed, that cannot be verified, or that held sensitive information. The ISM is explicit on this point: media that cannot be successfully sanitised is destroyed prior to disposal (ISM-1735).

The trade-off is straightforward. Destruction gives you certainty and destroys residual value. Sanitisation preserves the resale or redeployment value of the asset and puts the burden of proof on you. Decide per device class, write the decision down, and stop making it case by case at the loading dock.

SSDs, spinning disks, phones and the printer everyone forgets

Spinning disks. Sanitise with a tool that resets the host-protected area and device configuration overlay and issues ATA secure erase, then verify with a read back. If verification fails, destroy it. Old drives under 15 GB or manufactured before 2001 need three overwrite passes under the ISM rather than one.

SSDs and NVMe. Prefer cryptographic erase where the drive was encrypted from day one, or the manufacturer’s sanitise command. Software overwriting alone is unreliable because of wear levelling and over-provisioning. If the drive held anything sensitive and you cannot verify the erase, destroy it. SSDs shred easily and cheaply.

Phones and tablets. Remove them from your MDM and from Apple Business Manager or the Android enterprise equivalent before wiping, then perform the vendor erase. A device still enrolled or still tied to an activation lock is not disposable and is not resellable, and this is the single most common failure we see. Personal devices under a BYOD arrangement need a documented selective wipe that removes corporate data without touching the owner’s photos.

Multifunction devices. This is the one everyone forgets. Business photocopiers and multifunction printers commonly contain an internal hard drive or SSD that has retained images of everything scanned, printed, faxed and emailed through them, sometimes for years. When the lease ends the machine goes back to the finance company with that drive inside it. Before any MFD leaves the building, either have the vendor perform and certify a documented data removal, or buy the drive out of the lease and destroy it yourself. Put this in the lease negotiation, not in the exit conversation.

Everything else with storage. Network video recorders, backup appliances, firewalls with logging, VoIP handsets with local directories, USB sticks in the bottom drawer, and the old NAS in the comms room. If you do not have an asset register that actually tracks devices, you will miss several of these, and the ones you miss are the ones that turn up on a marketplace listing.

The Privacy Act requires you to destroy what you no longer need

APP 11.2 requires an APP entity to take such steps as are reasonable in the circumstances to destroy personal information or ensure it is de-identified once the information is no longer needed for any purpose for which it may be used or disclosed under the APPs, unless an Australian law or a court or tribunal order requires it to be retained. APP 11.3, introduced by the Privacy and Other Legislation Amendment Act 2024 and applying to personal information held from 11 December 2024, confirms that reasonable steps include both technical and organisational measures.

Three points from the OAIC’s guidance change how a disposal process should be built.

Destruction means the information can no longer be retrieved. The OAIC states that for hard copy, disposal through garbage or recycling is not reasonable steps unless the information has already been pulped, burnt, pulverised, disintegrated or shredded. For electronic information, reasonable steps vary with the hardware, and where hardware cannot be sanitised, the information must be irretrievably destroyed another way.

You must deal with all copies, including archives and backups. A wiped laptop does not help if the same personal information is sitting in a backup set you have kept for six years without a retention policy.

Where the information sits on a third party’s hardware, such as cloud storage, and you have instructed them to destroy it, reasonable steps include taking steps to verify that it happened. That is the same discipline as asking where your cloud data actually lives at the start of the relationship.

There is also a fallback the OAIC calls putting information beyond use, for the limited cases where irretrievable destruction is genuinely impossible. It requires that you will not use or disclose the information, cannot give any other entity access to it, surround it with technical, physical and organisational security including access logs and audit trails, and commit to destroying it when that becomes possible. It is a narrow exception, not a filing strategy.

Get this wrong and a lost or stolen device holding personal information is exactly the example the OAIC gives of a notifiable data breach. Knowing which machines held what makes that assessment survivable, which is the practical reason to know which devices held sensitive information before they reach end of life.

Certificates of destruction, and what a real one contains

Most certificates of destruction we see are marketing documents. A useful one is an evidence record. It should contain:

• The serial number of every item, matched to your asset register, not a count of items or a weight
• The media type and the method used for each item, not a generic statement covering the batch
• The date and physical address at which destruction or sanitisation occurred
• The name and signature of the person who performed it and the person who witnessed it
• For sanitisation, the tool and version used and confirmation that verification passed
• For destruction, the equipment used and the resulting particle size
• A statement of the standard the vendor worked to
• Confirmation that the residue was then handled as e-waste under Victorian law

If the certificate cannot be reconciled to serial numbers in your asset register, it proves nothing in an audit. The ISM’s own approach for government is instructive: destruction is supervised, the supervisor confirms it was completed successfully, and where destruction of sensitive media is outsourced it requires a National Association for Information Destruction AAA certified service. Asking a commercial vendor whether they hold NAID AAA certification is a fast way to sort the serious operators from the rest.

Chain of custody is where it actually fails

The data is rarely lost during destruction. It is lost between the desk and the truck.

Devices sit in a store room for eight months. A staff member takes one home because it was “going to be thrown out anyway”. The pallet is collected by a subcontracted driver nobody recognises. A box goes missing between sites and nobody notices because there is no manifest.

Fix it with unglamorous controls. Log every device into a disposal batch at the moment it is decommissioned, with its serial number. Store the batch in a locked area, not the corridor. Do not release a batch without a signed manifest listing every serial. Require the vendor to acknowledge receipt against that manifest within an agreed window, and chase it when they do not. Reconcile the certificate to the manifest and close the batch in your asset register. That whole loop belongs in a documented disposal procedure so it survives the departure of whoever currently does it from memory.

Where devices held highly sensitive information, remove and destroy the drives on site before the hardware leaves, and let the vendor take the carcass. It is cheap and it eliminates the entire chain of custody argument.

Victoria banned e-waste from landfill in 2019

Since 2019 it has been illegal in Victoria to send e-waste to landfill or put it in general rubbish. E-waste is broadly defined: anything with a plug, a battery or a power cord. That includes computers, phones, monitors, whitegoods, batteries and photovoltaic panels.

For a business the obligations go further than “do not bin it”. EPA Victoria regulates the transport, storage and reprocessing of industrial waste, and most e-waste from business and industry is pre-classified as priority waste under Schedule 5 of the Environment Protection Regulations 2021. Duties under the Environment Protection Act 2017 apply to the generator, the transporter and the receiver, which means you carry a duty as the generator and cannot fully delegate it. The general environmental duty applies as well: you must eliminate or reduce the risk of harm from your e-waste so far as reasonably practicable. Used lead-acid and nickel-cadmium batteries are classified as reportable priority waste and attract additional requirements.

Lithium-ion batteries deserve a specific mention. EPA Victoria’s guidance is to manage all e-waste as if it has a battery, and e-waste is treated as a specified combustible recyclable and waste material. A crate of old laptops and vapes in a comms room is a fire load, not just a compliance item.

The relevant Australian Standard is AS 5377:2022, which covers the collection, storage, transport and treatment of end-of-life electrical and electronic equipment. Ask your vendor whether they work to it.

Who to contact now that Sustainability Victoria has closed

Sustainability Victoria closed on 30 June 2026 following the Independent Review of the Victorian Public Service, and its website is no longer updated. Programs that continued, including Detox Your Home and the recycling infrastructure funding streams, transferred to the Department of Energy, Environment and Climate Action (DEECA). For current Victorian information on recycling and waste, go to DEECA. For the rules themselves, and for enforcement of the e-waste landfill ban, go to EPA Victoria. Anything still citing Sustainability Victoria as the authority is out of date.

At Commonwealth level, the Product Stewardship Act 2011 was repealed and replaced by the Recycling and Waste Reduction Act 2020, with the repeal effected by the accompanying Consequential and Transitional Provisions Act. The National Television and Computer Recycling Scheme continues under that framework, administered by the Department of Climate Change, Energy, the Environment and Water, which has also committed to developing a mandatory product stewardship scheme covering small electrical products and solar photovoltaic systems. If a supplier quotes the Product Stewardship Act 2011 at you, they have not updated their paperwork since 2020.

What to require from a disposal vendor

Put these in the engagement, not in an email thread.

1. Which EPA Victoria permission they hold, or which permissioned facility their material goes to
2. Whether they work to AS 5377:2022, and whether they hold NAID AAA certification for data destruction
3. Whether destruction happens on your site, at their site, or at a third site, and who transports it
4. What the certificate of destruction contains, with a sample provided before you sign
5. Serial-level reconciliation against your manifest, with a stated turnaround
6. What happens to devices they on-sell rather than destroy, and what sanitisation they apply first
7. Whether any material is exported, and to where
8. Their insurance position if a device holding your data surfaces after they took custody of it

The last one is the question that separates a disposal partner from a scrap dealer.

We handle decommissioning, drive destruction and compliant e-waste disposal as part of asset lifecycle work for our managed clients, including the MFD lease exits that usually get missed. If you have a store room full of retired kit and no record of what is in it, call us on 1300 028 324 or get in touch at https://techassist.au/contact/. We will inventory it, tell you what is defensible to sanitise and what has to be destroyed, and give you your Privacy Act obligations in writing rather than in principle.

If a client or an insurer asks where your data lives, the honest answer for most Australian businesses is: the files sit in an Australian data centre, the company that runs it is American, and the people who administer it could be anywhere. Those three facts are separate questions, and most providers answer only the first one and call it sovereignty. Getting the distinction right matters, because the Privacy Act holds you responsible for what happens to personal information after it leaves your hands.

Data residency is where your data is physically stored. Data sovereignty is whose laws apply to it. Jurisdiction is which courts and agencies can compel its production. A data centre in Sydney settles residency. It does not settle the other two.

Residency, sovereignty and jurisdiction are three different questions

Residency is a fact about geography. Microsoft or Google can tell you which metropolitan area holds your mailboxes and files, and both publish that information.

Sovereignty is a question about law. A US-headquartered provider remains subject to US law wherever its servers sit, and an Australian subsidiary does not change the parent company’s obligations. A local region does not create a legal firewall.

Jurisdiction is the practical version of the sovereignty question: who can lawfully order the data to be handed over, and under what process. That question is answered by the provider’s corporate structure and the contract, not by the postcode of the building.

Providers who blur these three are usually selling a data centre tour. Ask which of the three they are actually addressing.

APP 8 makes you accountable for what your overseas provider does

Australian Privacy Principle 8 governs cross-border disclosure. Before an APP entity discloses personal information to an overseas recipient, it must take such steps as are reasonable in the circumstances to ensure that the recipient does not breach the APPs. Section 16C then makes the disclosing entity accountable for acts or practices of the overseas recipient that would breach the APPs. In plain terms: if your offshore provider mishandles the information, you are treated as having breached the APPs yourself.

The OAIC’s expectation is that “reasonable steps” normally means an enforceable contract requiring the recipient to handle the information in accordance with the APPs, requiring the same terms to flow down to subcontractors, setting out complaint handling, and requiring the recipient to notify you of suspected breaches so you can meet your obligations under the Notifiable Data Breaches scheme.

There is an important wrinkle that changes the analysis for cloud storage. The OAIC’s APP Guidelines say that providing personal information to an overseas contractor may be a use rather than a disclosure where you do not release the information from your effective control. The example given is a cloud provider engaged for the limited purpose of storing the information and making it available to you, where a binding contract limits the provider to those purposes, binds subcontractors to the same obligations, and leaves you with effective control over access, security and deletion. In that case APP 8 does not apply.

That is not a free pass. The Guidelines are equally clear that where the arrangement is a use, you still hold the information, so you can still breach APP 11 and the other APPs if the provider mishandles it. You have changed which principle you are judged under, not whether you are responsible.

There are also two exceptions worth knowing. APP 8.2(a) applies where you reasonably believe the recipient is subject to a law or binding scheme substantially similar to the APPs with an accessible enforcement mechanism. APP 8.2(b) applies where the individual consents after being expressly told that if they consent, you will not be accountable and they will not be able to seek redress under the Privacy Act. Consent-based offshoring is legally available and commercially unattractive, because you have to say that sentence out loud to the customer.

Before any of this is workable you need to know what you actually hold. That is why we ask clients to classify your data first and to keep a documented record of where each system stores data. Without it, the APP 8 question cannot be answered honestly for any given system.

Microsoft 365 in Australia: what the commitment actually covers

Microsoft treats Australia as a Local Region Geography, with Microsoft 365 data centre locations in Melbourne and Sydney. For a tenant whose Default Geography is Australia, Microsoft’s Privacy and Security Product Terms provide a durable data residency commitment for Exchange Online, SharePoint and OneDrive, Microsoft Teams, and Microsoft 365 Copilot and Copilot Chat.

Four things about that commitment are routinely misunderstood.

The Default Geography is set when the Microsoft Entra ID tenant is created and cannot be changed afterwards. If someone signed your business up for a trial with the wrong country years ago, that decision is still governing your data location today.

The commitment covers a defined list of services, not everything with a Microsoft logo. Coverage for Microsoft Defender for Office P1, the Microsoft 365 web apps, Viva Connections and selected Microsoft Purview services requires the Advanced Data Residency add-on, which must be applied to 100 per cent of paid licences in the tenant. Services outside the covered list follow their own provisioning logic.

Where there is no durable commitment for a service, Microsoft’s own documentation states that the data is not committed to reside in any particular data centre and that the storage location is subject to change without notice.

Finally, Microsoft’s documentation notes that a customer request may be handled by servers in a region other than the one where the data is stored at rest. Processing paths and storage location are not the same thing.

On access, Microsoft states that engineers have no standing administrative privileges and no standing access to customer data, that any access is limited, logged and approved by senior management, and that customers licensed for Customer Lockbox also approve it themselves. That is a meaningful control and it is worth turning on. It is not the same as saying nobody outside Australia can ever see the data.

You can check your own position in the Microsoft 365 admin center under Settings, Org settings, Organization profile, Data location.

Google Workspace does not offer an Australian data region

This one surprises people, so state it plainly. Google Workspace data regions let an administrator pin covered data to the United States or to Europe. The third option is “No preference”. Australia is not a choice.

The coverage is otherwise reasonably good where it applies. Data regions cover data at rest, including backups, and data processing for core services including Gmail, Calendar, Drive, Docs, Chat, Meet, Contacts and Vault, subject to edition. Google’s documentation is explicit that data regions cannot be applied to data types not listed, such as logs or cached content, and that users on an unsupported edition are not covered even if a policy is applied to their organisational unit.

Google Cloud, which is a different product, does operate Australian regions. If a vendor tells you their Workspace data is held in Australia, they are either describing something built on Google Cloud rather than Workspace, or they have not read the documentation.

Storage is local. Support and administration usually are not.

This is the gap that catches businesses in a client security review. Your tenant can be pinned to Melbourne and your support model can still involve people outside Australia.

Three things to check. First, the vendor’s own support model: follow-the-sun support desks routinely mean an engineer in another country holds a privileged account in your tenant. Second, subcontractors: a vendor with an Australian front office and an offshore development or support partner has an APP 8 question of its own to answer, and the OAIC expects the obligations to flow down. Third, your own provider: if your MSP uses offshore staff for after-hours triage, that is a disclosure decision you have made whether or not you were told about it.

TechAssist runs an Australian team from our Tecoma head office and Melbourne CBD office, so this is an easy question for us to answer. The point is that it is a question you should be asking of every provider with administrative access, including the ones you have used for years.

Foreign government access, stated factually

The United States enacted the Clarifying Lawful Overseas Use of Data (CLOUD) Act in March 2018. It confirms that US providers can be compelled to produce data in their possession, custody or control regardless of where that data is stored, and it authorises bilateral agreements allowing partner countries to serve orders directly on US providers. The United States and Australia signed a CLOUD Act agreement on 15 December 2021.

Two things follow. Data stored in Sydney by a US-headquartered provider is still within reach of US legal process. And Australian agencies have their own compulsory powers, so the alternative is not an absence of government access, it is a different government’s access.

Both Microsoft and Google publish periodic transparency reports on government requests. If this risk is genuinely material to your business, read those rather than the marketing page, and treat customer-managed encryption keys and Customer Lockbox as the controls that actually change the analysis.

The trade-off is worth naming. Moving to a wholly Australian-owned provider removes the foreign jurisdiction exposure and usually costs you the security engineering, availability and feature velocity of a hyperscaler. For most SMBs that is a bad trade. For a defence supplier it may not be.

When sovereignty is a legal requirement, and when it is a procurement preference

Genuine legal requirements exist, and they are narrower than the sales conversation suggests. Commonwealth and state government contracts commonly impose hosting and data location conditions, and those are contractual obligations you can read. APRA-regulated entities have their own prudential standards on information security and outsourcing.

Health is the example everyone reaches for, and it is the one most often stated wrongly. There is a real Commonwealth localisation rule, and it is section 77 of the My Health Records Act 2012 (Cth). It provides that the System Operator, a registered repository operator, a registered portal operator or a registered contracted service provider that holds records for the purposes of the My Health Record system, or has access to information relating to those records, must not hold or take the records outside Australia, must not process or handle the information relating to those records outside Australia, and must not cause or permit another person to do either. The only carve-out is for the System Operator itself, for operating or administering the system, and only where the records and information contain no personal information about a healthcare recipient or participant and no identifying information. Contravention is a fault-based offence carrying imprisonment for 5 years or 300 penalty units or both, with a civil penalty of 1,500 penalty units.

Now read the list of who that binds, because that is the part clinics get wrong in both directions. Section 77 applies to the operators of the My Health Record system and their contracted service providers. It is not a rule that all Australian health data must stay onshore. A medical, dental or allied health practice is a registered healthcare provider organisation, and registered healthcare provider organisations are not in the section 77 list. So section 77 does not, by itself, prohibit a clinic from using an offshore-hosted practice management system for its own clinical records. If your software vendor or your hosting sits inside the My Health Record system as a repository, portal or contracted service provider, section 77 binds that role directly and you should ask them to say so in writing. If it does not, your offshore hosting question is answered by the Privacy Act, your state health records legislation and your contracts, not by section 77. Getting this backwards means either buying sovereignty you are not required to have, or assuming a protection that does not apply to you.

Everything else is usually a procurement preference: a large customer’s security questionnaire, an insurer’s checklist, or a board that would prefer the answer to be “Australia”. Preferences are legitimate, and they cost money. Meeting them can mean an Advanced Data Residency add-on, an edition upgrade, or leaving a product you otherwise like.

The Privacy Act itself does not require personal information to stay in Australia. It requires you to take reasonable steps and holds you accountable if the recipient mishandles it. A business under the $3 million small business turnover threshold in section 6D may be exempt from the Privacy Act altogether, though the exemptions are narrower than most owners assume. It is worth understanding what the Privacy Act asks of a small Australian business before deciding you are outside it.

Where privacy reform has actually got to

Do not build a data strategy on the small business exemption surviving, and do not assume the second tranche has already landed. Both mistakes are common.

The first tranche is law. The Privacy and Other Legislation Amendment Act 2024 passed Parliament on 29 November 2024 and progressed 23 proposals from the government’s response to the Privacy Act Review Report, including a framework for a Children’s Online Privacy Code. Two of its changes reach ordinary businesses. The statutory tort of serious invasion of privacy commenced on 10 June 2025, and the OAIC notes that it is broader in application than the Privacy Act, extending to individuals and entities that are not APP entities, which means it can reach a business the Privacy Act does not. Separately, from 10 December 2026, an APP entity that has arranged for a computer program to use personal information to make a decision that could reasonably be expected to significantly affect a person’s rights or interests must say so in its privacy policy, including the kinds of information used and the kinds of decisions made. The OAIC has consulted on guidance and said it intends to publish it before that date.

The second tranche is not law, and that is where the bigger changes sit, including removal of the small business exemption. At the time of writing the Attorney-General’s Department’s own privacy page still describes the work as developing draft provisions and engaging on the detail to inform the government’s decisions on next steps, and no second tranche Bill has passed. Treat the exemption as a temporary position, check the position again before you rely on it, and note that it was never a shield against the statutory tort, which does not depend on being an APP entity at all.

The questions to put to a SaaS vendor

Send these in writing and keep the answers with the contract.

1. In which country is customer data stored at rest, and is that a contractual commitment or a current arrangement you may change?
2. Which specific services or modules are covered by that commitment, and which are not?
3. Where are backups, replicas, logs and cached content stored?
4. From which countries can your staff and subcontractors access customer data, and under what approval process?
5. Who are your sub-processors, where are they, and do your contracts require them to meet the same obligations?
6. Under APP 8, do you regard your handling of our customers’ personal information as a use or a disclosure, and why?
7. Will you notify us of a suspected data breach, within what timeframe, and in what form?
8. On termination, how is our data returned and destroyed, and will you provide evidence that destruction occurred?

Question seven is the one that determines whether you can meet your obligations under the Notifiable Data Breaches scheme, which require you to notify the OAIC and affected individuals when a breach is likely to result in serious harm. Question eight is the one everyone forgets until an exit, and it connects directly to secure device disposal and the APP 11.2 obligation to destroy personal information you no longer need. If you want the configuration side handled properly as well, start with cloud security controls that matter for an SME.

If you are filling in a client security questionnaire or a cyber insurance form and cannot answer these questions about your own tenant, we can audit it and give you the documented answers. Call us on 1300 028 324 or get in touch at https://techassist.au/contact/. We will tell you where your data actually sits, not where you would like it to be.

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.

1. A current asset register export, in CSV, with serial numbers and warranty dates.
2. The network diagram, dated within the last six months, plus the IP addressing plan.
3. A licence and subscription register with renewal dates and the billing owner.
4. Confirmation of who holds the registrant details for your domain and who holds global administrator on your cloud tenancy.
5. The date of the last successful restore test, and which system was tested.
6. 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.