Locked Out of Your Google Workspace Admin Account: How to Get Back In

If nobody can sign in to your Google Workspace Admin console, you are not locked out of an app, you are locked out of your company’s identity system. Every path back in ends at the same question: can you prove, to Google’s satisfaction, that you control the domain name. Some of these recoveries take an afternoon, some take weeks, and a small number never succeed at all.

A super administrator is the Google Workspace role that can reset any password, assign admin roles, and change any setting in the Admin console. Losing every super admin account means losing administrative control of your email, your files and your user accounts, even though the service itself keeps running normally for staff.

Work out which lockout you actually have before you touch anything

The recovery paths are different and the wrong one wastes days. Find yourself in this list first.

You forgot the password and your recovery email and phone still work. This is the easy case. Fix it in ten minutes with the standard recovery wizard.

You know the password but 2-Step Verification is blocking you. The phone is gone, the security key is lost, or nobody printed backup codes. Different path, and slower.

The super admin has left, been dismissed, gone quiet or died. The account may still exist and still be the only super admin. This is the most common serious case in small businesses.

Nobody knows who the super admin is. Often it turns out to be a generic address like info@ or admin@ that nobody has opened in years, or a personal Gmail address used during signup.

The account is suspended. Usually billing, occasionally a policy or abuse action. Recovery is a payment or a support case, not a DNS record.

A contractor, web developer or hosting company set the domain up. They own the Workspace signup, or the domain registration, or both. This is the case that most often fails, because two separate ownership problems have to be solved in the right order.

Being honest about which one you are in is the whole job. Everything below assumes you have picked correctly.

Try the self-service paths in Google’s order, because support will ask if you did

Google’s published position is that support-assisted recovery is only available after you have been through the automated flow. Do not skip it.

1. Ask another super admin. Any other super administrator can reset your password from the Admin console in under a minute. This is the reason Google’s own security guidance says every organisation should have more than one super admin account, each held by a different person. If you have a second one, stop reading and go use it.

2. Standard password recovery. Go to accounts.google.com/signin/recovery, enter the admin address, click Next and then Try another way. If a recovery email or phone number is attached to the account, Google sends a verification code and you reset the password. If you have forgotten the address itself, use Forgot email? and supply the recovery email or phone plus the full name on the account.

3. Check whether self-recovery is even switched on. This is the step almost every guide misses. Super admin account self-recovery is a setting an organisation can turn off, and if it is off, the Forgot password? link tells super admins to contact their administrator rather than offering a code. The control lives in the Admin console at Security, then Authentication, then Account recovery. Google documents the default as off for a list of editions including Business Plus, Frontline Standard, Enterprise Essentials Plus, Education Standard and Plus, G Suite Basic and Cloud Identity Premium, and on for the others. Google’s admin security best practices page states it differently again, that recovery is off by default for most current and all new customers, with existing customers under three super admins or 500 users defaulting to on. If you can still get in, check yours now rather than trusting either summary.

4. Backup codes and a spare security key. If 2-Step Verification is the blocker and the account has printed backup codes or a second enrolled security key, that is your way through. If it does not, note that Google is progressively enforcing 2SV on administrator accounts, so this failure mode is becoming more common, not less.

If none of that works, you are into domain proof.

Proving you own the domain is what actually decides most of these cases

Google’s fallback is not a phone call and not a photo of a driver’s licence. It is a DNS record you place at your domain host, because control of the domain is the only ownership signal Google can verify without a human judgement call.

There are two flows and they use different record types. Most guides conflate them.

The automated wizard asks for a CNAME record. Working through accounts.google.com/signin/recovery and clicking Try another way repeatedly eventually offers domain verification. Google gives you a CNAME record to add at your DNS host. Wait a few minutes, click Next, and if Google finds the record you get straight to a Create Password screen. If it does not find the record immediately, you supply a contact email address that is not the locked account, receive a verification code, and Google emails a password reset link once the record is confirmed. Google’s documented cut-off is that if the CNAME is not found within 48 hours, you get an email telling you the recovery failed and you start again.

The support-assisted flow accepts a CNAME or a TXT record. If the automated wizard cannot resolve it, it may offer Contact support, which sends you to the Apps Admin Toolbox at toolbox.googleapps.com/apps/recovery/form. You give a contact email address that is not the locked account, Google issues a support reference number, and you add either a CNAME built from that reference number or a TXT record at your domain host. Then you click Check Again, select Request for Password Reset, and submit. Google’s documentation says DNS changes can take up to 24 hours to propagate and gives you two toolbox.googleapps.com/apps/dig lookups to confirm the record is visible before you resubmit.

Use those lookups. A large share of failed recoveries are not identity failures, they are a record placed on the wrong zone: added at the registrar when DNS is actually hosted somewhere else, added to a redirect service, or added with the domain name accidentally doubled on the end of the hostname. Google’s own note is explicit that if your hosting provider is separate from your registrar, you must change the record with the provider that is actually answering for the zone.

Then Google asks the account history questions. Expect to be asked the date the Workspace account was created, the original secondary or recovery email address used at signup, the Google order number if there is one, how many user accounts were created, the billing address, and the card type and last four digits. Google states you do not have to answer every question correctly. You do have to answer enough of them, and the answers a departed admin took with them are usually the signup email address and the creation date. Search old email for a welcome message from [email protected] and pull the oldest Google charge off the company card statement before you start the form.

The only elapsed times Google commits to are the ones inside the DNS steps. On the automated flow you have 48 hours for the CNAME to be found, after which Google emails you to say the recovery was unsuccessful and you begin again. On the support-assisted flow Google allows up to 24 hours for the record to propagate before you click Check Again. Past the point where you press Submit Request, Google publishes no timeframe at all. Its documentation says only that the support team will contact you for next steps, and that in some cases you may need to provide additional verification so that access is granted to the rightful owner.

What governs how quickly a human picks the case up is your support tier rather than the recovery flow, and the tiers are set out further down. Plan against the documented floor, not against a promise, and get the DNS record right the first time, because a failed check restarts the whole sequence.

If you are a user and there is no reachable admin at all, you can be promoted

There is a separate path most people never find. A normal user account can be promoted to super administrator with proof of domain ownership, using the same Apps Admin Toolbox form.

You sign in to your own working Google account first, because only active accounts can be promoted. Then enter the domain at toolbox.googleapps.com/apps/recovery/form, click Lookup Recovery Options, choose I am a user and cannot contact my administrator, add the CNAME or TXT record, and submit Request User Promotion.

The important detail: Google then contacts the existing administrators. If they are inactive and unresponsive, Google promotes your account. If they respond, you are offered the option of having Google pass your contact details to them instead. So this path works when an admin has genuinely vanished, and does not work as a way around an admin who simply disagrees with you.

When the registrar login is gone too

This is where recoveries stall. You cannot add a DNS record if you cannot sign in to the registrar or the DNS host, and the person who could is the same person who has gone.

Work in this order.

Find out who actually answers for the domain, rather than who you think does. A public WHOIS lookup gives you the registrar of record. A nameserver lookup gives you the DNS host, which is frequently a different company: the domain sits at one registrar while the zone is served by a web host, a CDN or a previous IT provider.

Then run the registrar’s own account recovery against the registrant email address on the record. If that address is inside the locked Workspace tenancy, you have a circular dependency and you need to break it at the registrar, not at Google.

For a .com.au name, the auDA rules work in your favour more than most people expect. The .au Domain Administration Rules state that a licence confers no proprietary rights in a domain name: a registrant holds a licence to use the name for a period and does not legally own it. Eligibility for com.au requires both an Australian Presence and a Commercial Entity, and auDA’s definitions include a company registered under the Corporations Act 2001 and any entity issued with an ABN. The name itself must be a match or an acronym of the registrant’s company, business, statutory or personal name, or a match or synonym of goods or services that the registrant actually provides. If your business is the genuine registrant, that list is also the evidence pack: ABN, company extract, business name registration, invoice history.

Ask for the authorisation code by name. auDA requires a valid authorisation code from the registrant for a transfer between registrars, and requires the registrar to release it in writing only to the registrant contact recorded in the registry data, unless the registrant has authorised in writing that it go to a third party. That ordering matters. Getting the registrant contact corrected comes before asking for the code, not after.

If the registrar will not act, there is a defined complaints path rather than a dead end. auDA’s rules require the complaint to go to the registrar of record first, give that registrar 30 calendar days to resolve it, and require written reasons plus notice of your right of appeal to auDA for review. It is slow. It is also a real lever, and registrars behave differently once you cite it.

The other lever is the paying party. Whoever’s card is on the domain renewal has standing to ask the registrar to correct the account.

Google’s clock is not the Australian problem here. Google’s published hours of operation table lists Australia as 24/7 in English, the same as the United States and the United Kingdom. There is no overnight window in which nobody is available to take the case. The delays in Australian recoveries come from the registrar side, not from Google’s support hours.

When a third party registered the domain in their own name

If a web developer or agency registered the domain as themselves rather than as your business, you have a commercial problem wearing a technical hat. Google will accept a DNS record from whoever controls the zone, and right now that is not you.

The realistic options are to get the third party to add the record on your behalf, to get the domain transferred into your own registrar account, or to pursue it as a contractual matter. None of those are quick, and the technical recovery cannot start until one of them lands.

If the business is still trading and simply unresponsive, a written request naming the specific record to add, with a deadline, resolves it more often than people expect. If the business has wound up, the registrar becomes the only route.

auDA’s rules are clearer on this than most web development contracts are. A person may use an agent to make a licence application. That agent warrants to the registrar and to auDA that it has the authority to bind the person it is acting for, and the rules require the agent to ensure that the person on whose behalf they are applying is recorded as the registrant in the registry data. A developer who put their own company in that field did not follow the rules. Quote that when you write to them, because it changes the conversation from a favour you are asking for into an obligation they already had.

The correction path exists, and it closes fast. auDA allows a registrant to ask a registrar to correct registrant information, and the listed grounds include a licence incorrectly registered by the registrar in the name of the reseller or other agent who arranged the registration. The catch is in the next rule: the request must be made within 14 calendar days of the licence being recorded in the registry data. Three years after a website build, that route is shut and you are into a change of registrant instead.

A change of registrant is a transfer, not an edit. auDA requires the transfer request in writing from the current registrant to the registrar, requires the incoming party to satisfy the Australian Presence and the namespace eligibility criteria at the date of transfer, to enter a new licence agreement and pay a new licence fee, and requires the registrar to complete the transfer within two calendar days of the request. Read that list again and note where the friction actually sits. Everything except the first line is mechanical. The whole thing turns on the departed developer signing a written request.

Escalation: what Google support can and cannot do for you

Google Workspace support is real, staffed and reachable, and it is also narrower than most people assume.

You need an admin account to raise a case. Contacting support requires the Support administrator privilege and access to the Admin console. That is the trap: the people who most need support are the ones who cannot get in to ask for it. That is exactly why the Apps Admin Toolbox login issues form exists as an unauthenticated channel.

Support tiers change response speed, not eligibility. Google publishes three offerings. Standard Support is included with a Workspace licence, has 24/7 access, and carries a four hour service level objective for P1 cases. Enhanced Support accelerates that to one hour for P1 and adds commercially reasonable help with third-party applications. Premium Support carries a fifteen minute P1 objective, designated technical advisors and a Technical Account Manager. Cases are prioritised P1 to P4, where P1 is a critical service access issue affecting more than one user with no workaround, and Google’s stated commitment is an initial response within one business day or less.

Note what that does not say. A faster tier gets you a human sooner. It does not remove the domain ownership requirement, and it does not let an agent hand over a super admin account because you sound convincing.

If you bought Workspace through a reseller, Google will send you back to them. This is stated plainly in Google’s own troubleshooting documentation, along with links to reseller-specific reset instructions for Wix, Squarespace, Weebly, Automattic, Namecheap, Bluehost, Domain.com, HostGator and iPage. If your Workspace came bundled with a website build or a hosting plan, check this before anything else. Your reseller set the account up and can usually reset the password directly.

What a reseller or a support partner can actually do, according to Google’s own documentation. There are two distinct arrangements and Google documents both. If a reseller manages your subscription, Google states the reseller can access your Admin console, submit support cases and provide other services for you unless you remove that access, and Google’s stated recommendation is to leave the access on so they can troubleshoot for you. Separately, any Workspace customer can assign a Support Partner in the Google Cloud Support Portal, and Google’s wording is that while assigned, the partner can file cases on your behalf and access cases you filed yourself.

Two things follow. Both arrangements are switches inside your own account, under Account then Reseller management in the Admin console, or under Support Partners in the Support Portal. And both require a working admin sign-in to set up, which means neither is something you can arrange after you are already locked out. Turn on the one you want while you can still get in.

What that buys you is a second party who can open and chase the case while you are dealing with the registrar. It does not change the evidence Google requires. The domain proof is identical, the account history questions are identical, and nobody at Google or at a partner can release a super admin account without them.

TechAssist is listed in Google Cloud’s partner directory and we take that second-party role for clients, which means the case gets opened and chased by someone who has run the flow before rather than by an owner reading the form for the first time. It buys you competence and persistence on the process, not a shortcut through it.

Have this ready before you open the case. The domain name. The exact admin address you are trying to recover. Evidence of the signup: the original welcome email, the creation date, the secondary email address used. Billing evidence: the card type and last four digits, the billing address, the Google order number, and the date of the most recent payment. Registrar and DNS host details, with proof you can edit the zone. A contact email address that is outside the locked domain. Assembling this first is the difference between one exchange and five.

Two lockouts that look like this but are not

A suspended account is a billing or policy problem. If you can reach the Admin console but the service is suspended, or if sign-in reports the account is not using Google Workspace, no amount of DNS proof helps. Check the payment method and the billing contact first. Google’s documentation is blunt that if a Workspace or Cloud Identity account has been deleted rather than suspended, the data is not recoverable, and re-signing up the domain 24 hours later gives you a new empty tenancy.

A Context-Aware Access rule can lock every admin out at once. If an access level was applied to the Admin console itself and the conditions can no longer be met, for example a device or IP requirement that no longer exists, you have a total lockout that no password will fix. Google’s documented remedy is to contact support through the Customer Care Portal, and support will remove all Context-Aware Access policies applied to the Admin console. Policies on other apps are untouched. Google is equally clear that the policies must be reapplied immediately after access is restored.

Be honest about the odds

Some of these recoveries simply fail. The pattern is consistent: the further the domain is from your control, the worse the outcome. If you can edit DNS, you will almost certainly get back in eventually. If you cannot edit DNS and cannot recover the registrar account, there is no Google process that fixes that, because from Google’s side you are indistinguishable from an attacker.

The realistic worst case is not that you never recover the tenancy. It is that recovering it costs more elapsed time than the business can absorb, and someone makes the call to stand up a new tenancy on a new domain and accept the data loss. That decision is much easier to make on day three than on day twenty.

There is one structural failure point rather than a list of them, and Google’s documentation makes it obvious. The automated wizard, the support-assisted form and the user promotion path all terminate at the same requirement: a record placed in the zone that answers for your domain. Google offers no documented alternative to it. Whoever can edit the zone completes a recovery. Whoever cannot does not, however obviously they are the rightful owner. Everything worth doing in advance is really about making sure that person is you.

Making sure this never happens again

Every item here takes minutes while you have access and is impossible once you do not.

Run at least two super admin accounts, held by two different people. Google’s own guidance says so. One is a single point of failure attached to a human being who can resign, get sick or lose a phone.

Create a break-glass account. A dedicated super admin account that belongs to the business rather than to a person, not used for daily work, with a long unique password and its own 2-Step Verification enrolment. Store the credentials and the printed backup codes somewhere physical and controlled. Google’s guidance to enrol a spare security key and to generate backup codes in advance exists precisely for this account.

Keep recovery information current and remove it when people leave. Google explicitly recommends stripping a super admin’s recovery phone and email the moment they are terminated, so they cannot recover their way back in. That cuts both ways: the recovery details on your remaining admin accounts need to point at people who still work there.

Separate admin duties from daily accounts. Google’s best practice is that each super admin has two accounts, one for super admin tasks and one for everyday email, and that routine administration is delegated to limited roles rather than super admin. Shared generic admin accounts also destroy your audit trail, because you cannot tell which person made which change. Store the credentials in a business password manager rather than a spreadsheet, and put multi-factor authentication on the manager itself.

Document the registrar, the DNS host and who pays for them. Written down, in your IT documentation, with the account holder named. This one item removes the single most common cause of failed recovery.

Check that the registrant on the domain is your legal entity, and hold the authorisation code. For a .com.au name, confirm the registrant recorded in the registry data is your company and not a developer, an agency or a staff member’s personal name. Ask your registrar for the authorisation code and store it with the rest of the break-glass material. auDA requires that code for any transfer between registrars, and it will not be handed to you at speed during a crisis.

Decide now whether a reseller or support partner should have access. If someone else is going to open the case on your behalf, the switch has to be on before the lockout, not after.

Record the signup facts while someone still remembers them. Creation date, original secondary email address, order number, billing contact. Those are the questions Google will ask, and they are trivial to capture now.

Turn on admin alerts and review the admin log. You want to know when a super admin role is granted, when recovery information changes, and when a new admin appears. Most of that is covered in the Admin console settings that carry real risk, and the wider programme is in hardening Google Workspace properly.

Understand what you would actually lose. Losing admin access and losing data are different problems with different answers. If the tenancy is unrecoverable, or if someone with access deletes at speed, Google’s retention windows are shorter than most owners assume. That argument is set out in Google is not backing up your Workspace data.

If you have just taken over a Workspace tenancy from a previous provider or a departed staff member, do all of the above in the first week. The full checklist is in inheriting a Google Workspace tenancy nobody documented, and if you are also running Macs and Windows machines alongside it, running Windows, Mac and Google in one business covers how the pieces fit together. Being a partner on the Apple, Microsoft and Google sides at once is unusual for a Melbourne provider, and it is the reason we can tell you which platform genuinely suits the business rather than the one we happen to sell.

If you are locked out right now, call us on 1300 028 324 and have your domain name, your registrar details and any old Google billing records in front of you. We will tell you within one conversation which recovery path applies and whether it is realistically going to work. You can also start at techassist.au/contact.

The honest answer to “what does an hour offline cost us?” is: more than you think, and you can work it out in ten minutes. Take the staff who can’t work, multiply by their loaded hourly cost and the hours lost, then add the revenue you didn’t earn and the cost of putting things right. That number is usually a nasty surprise.

Most owners have never run that sum. They have a vague sense that downtime is bad, but no figure to weigh against the cost of preventing it. That gap is exactly why “we’ll fix it when it breaks” feels cheaper than it is. Here’s how to calculate the real cost of downtime for your business, what people leave out, and why a proactive approach almost always wins on the numbers.

The simple formula

You don’t need a consultant or a spreadsheet model to get a defensible figure. Four buckets cover most of it.

• Lost productivity = staff affected x loaded hourly cost x hours down. The people who are sitting idle, or working at half pace, while the system they need is unavailable.
• Lost revenue = sales, billable hours or transactions you couldn’t process during the outage and won’t recover later. Not every business has this; a retailer with the till down clearly does.
• Recovery costs = the after-hours engineering, overtime, expedited hardware, and the catch-up work once you’re back. This is the bit that keeps running after the lights come back on.
• Intangibles = reputation damage, missed deadlines, SLA penalties you owe your own clients, and the goodwill you spend apologising. Hard to price exactly, real all the same.

Add the four together and you have your cost per hour of downtime. The first bucket is the one everyone can calculate, so start there.

Getting “loaded hourly cost” right

A common mistake is to use the raw wage. The figure you want is the loaded cost — salary plus superannuation, payroll tax, leave loading, and overheads like the desk, the laptop and the software licence that person needs to do their job. As a rough rule, loaded cost runs about 1.25 to 1.4 times base salary. Someone on $90,000 isn’t costing you $43 an hour when they’re idle; they’re closer to $55 to $60 once you load it properly. Use the loaded figure or you’ll undercount every time.

A worked example

Let me put real numbers to it. This is a deliberately hypothetical scenario, not a real client and not a statistic — but the assumptions are the kind we see in Melbourne SMEs every week. You should swap in your own figures.

Picture a 30-person professional services firm in Camberwell. Their line-of-business application and shared files go down for half a day — four working hours — because a server failed and there was no quick failover. Assumptions:

• 25 of the 30 staff are completely blocked; the other five can do offline admin.
• Average loaded hourly cost across the affected staff: $60.
• The firm bills time, and roughly $8,000 of billable work for that morning simply can’t be done and largely can’t be clawed back.
• Recovery: an after-hours engineer, a replacement part couriered in, and overtime to catch up — call it $3,500.

That’s $17,500 for half a day, before you count the intangibles. Spread the same event across a few times a year and you’re well into five figures of avoidable loss. Run those four lines for your own business with your own headcount and rates — the exercise takes ten minutes and the result tends to change how people think about their IT budget.

The hidden costs people forget

The formula above captures the obvious losses. The ones that quietly inflate the real figure are easy to miss.

• The ramp-back-up tax. Productivity doesn’t snap back to 100% the moment systems return. People spend the next hour re-doing lost work, re-establishing context and clearing the backlog. Add 25 to 50 per cent to your productivity figure for this.
• Cascading effects. If your phone system, payment terminal or booking platform depends on the same internet link or server, one failure takes out several functions at once. The blast radius is usually wider than the thing that broke.
• SLA penalties you owe. If you have your own service-level commitments to clients, an outage can trigger credits or penalties. A logistics firm that misses a delivery window doesn’t just lose that job’s margin.
• Morale and overtime. Staff who lose half a day’s work then stay back to catch up don’t forget it. Chronic instability is a genuine factor in people leaving.
• Reputation. A retailer whose card terminal is down on a Saturday, or a clinic that can’t access patient records, loses trust as well as revenue. You can’t invoice for that, but you pay for it.

Why “fix it when it breaks” is a false economy

Break-fix — paying an hourly rate to fix things only once they fail — looks cheaper on a quiet month because you’re not paying for anything. The problem is what it does to both the frequency and the duration of downtime, which are the two levers that actually drive your cost.

Under break-fix, nobody is watching your systems. A failing disk, a backup that quietly stopped running three weeks ago, a firewall firmware bug — these get discovered when they cause an outage, not before. And when something does break, you’re at the back of the queue: the provider has to be called, has to understand an environment they don’t monitor, has to source parts cold. Your four-hour outage in the example above could easily have been an eight-hour one if the first two hours were spent just working out what failed.

The false economy is comparing the monthly fee of managed IT against zero, when the honest comparison is against the downtime you’ll eat without it. One avoided half-day outage a year often covers the difference.

How proactive managed IT cuts the bill

Good managed IT attacks downtime on two fronts: it makes outages less frequent, and it makes the ones that do happen shorter. Both reduce the hours in your formula.

Monitoring catches problems before they’re outages

Continuous monitoring means a failing drive, a service that’s stopped, or a backup job that didn’t complete raises an alert while it’s still a maintenance task, not an emergency. Most of the outages we prevent are ones the client never knew were coming. That’s the whole point — the cheapest downtime is the kind that never happens.

Redundancy removes single points of failure

A second internet service, a failover server, a clustered firewall — redundancy means one component failing doesn’t stop the business. It costs money, so you apply it where the downtime cost justifies it, which is exactly the calculation above. A business that knows an hour offline costs $4,000 can make a rational call on a $200/month redundant link.

Backups and a tested DR plan shorten recovery

When something does take systems down, the difference between a two-hour recovery and a two-day one is whether your backups work and whether you’ve ever actually tested restoring from them. An untested backup is a guess. We restore from backups on a schedule precisely so the day we need them isn’t the day we find out they were corrupt. A real backup and disaster recovery setup — with a documented, rehearsed DR plan — is what turns a catastrophe into an inconvenience. We go deeper on this in our guide to backup and disaster recovery for Melbourne businesses.

Tying downtime tolerance to RTO and RPO

Once you know what an hour costs, two numbers turn that into a design target. Your recovery time objective (RTO) is how long you can be down before the damage is unacceptable. Your recovery point objective (RPO) is how much data — measured in time — you can afford to lose. A business losing $4,000 an hour can’t tolerate a 24-hour RTO; the maths makes that obvious.

These aren’t abstract IT acronyms — they’re the bridge between your downtime cost and the money you should spend preventing it. Tight RTO and RPO targets cost more to deliver because they need redundancy and faster backups; loose ones are cheaper but expose you to bigger losses. The right answer falls out of the numbers you just calculated. Our explainer on RTO versus RPO walks through how to set them sensibly for each system.

TechAssist is a Melbourne-based MSP, founded in 2014, with 13 Australian-employed engineers and no offshore helpdesk. We run per-user fixed monthly pricing with no hourly billing for in-scope work, and we target sub-15-minute response on critical issues from our 24/7 NOC in Tecoma — because on a P1, every minute is a line in the downtime sum above. If you’d like help working out what an hour offline genuinely costs your business and designing around it, get in touch and we’ll run the numbers with you.

Frequently asked questions

How do I calculate the cost of downtime for my business?

Add four buckets: lost productivity (staff affected x loaded hourly cost x hours down), lost revenue you can’t recover, recovery costs like after-hours engineering and overtime, and intangibles such as reputation and SLA penalties. Sum them for a cost per hour, then multiply by a realistic outage length. Use loaded staff cost — salary plus on-costs and overheads — not the raw wage.

What is loaded hourly cost?

It’s the true cost of an employee per hour, including superannuation, payroll tax, leave entitlements and overheads like their equipment and software, not just their base wage. It usually works out to roughly 1.25 to 1.4 times base salary. Using the loaded figure stops you undercounting your productivity losses.

Is managed IT actually cheaper than break-fix?

Over a realistic period, usually yes — because break-fix ignores the cost of downtime it fails to prevent. Managed IT reduces both how often outages happen and how long they last through monitoring, redundancy and tested backups. One avoided half-day outage a year commonly covers the difference in fees.

How do RTO and RPO relate to downtime cost?

Your downtime cost tells you how much an outage hurts; RTO and RPO turn that into design targets. RTO is how long you can be down, RPO is how much data you can lose. A high hourly cost demands tighter targets, which justify spending on redundancy and faster backups. The numbers should drive the design, not the other way round.

What are the hidden costs of downtime?

The ones people miss include the ramp-back-up time after systems return, cascading effects when one failure takes out several functions, penalties under your own client SLAs, staff morale and overtime, and reputation damage with customers. These often add as much again to the obvious productivity and revenue losses.

An untested disaster recovery plan is a hope, not a plan. Until you’ve actually restored your systems and timed it, you don’t know if your backups work, how long recovery takes, or whether the data you assume is protected even exists. Disaster recovery testing is the only thing that turns a document into a capability.

Most businesses we meet discover this at the worst possible moment — mid-incident, watching a restore fail or a backup turn out to be empty. The plan looked fine on paper. Nobody had ever proven it. This post covers why backups quietly fail, the four kinds of DR testing, how to actually run a test, and how it all ties back to your recovery targets.

Why your backup is probably lying to you

A backup job that reports “completed successfully” every night feels reassuring. The green tick tells you the job ran. It does not tell you the data is complete, readable, or recoverable. Those are different questions, and the gap between them is where businesses get destroyed.

Here are the failure modes we see most often, and they’re rarely dramatic — they’re quiet:

• Incomplete coverage. The backup protects the file server everyone remembers, but not the SQL database behind the line-of-business app, the configuration on a critical appliance, or the new cloud VM someone spun up in March. Coverage drifts as the environment changes, and nobody re-checks it.
• Corrupt or unreadable backups. The job runs, the file lands, but the backup itself is corrupt — a bad block, a half-finished snapshot, an encryption key nobody can find. You only learn this when you try to restore.
• Microsoft 365 assumed safe but not backed up. This is the big one, and it deserves its own section below.
• No recent restore test. The most common failure of all. The backups exist. Nobody has actually pulled data back out of them in months — or ever. A backup you’ve never restored from is an untested assumption, not a safety net.

A manufacturing business in Dandenong we work with came to us after a ransomware scare at a competitor prompted a nervous board to ask a simple question: “If this happened to us, could we get back up?” Their previous provider had been running nightly backups for years. When we ran a test restore, two of the four critical systems wouldn’t come back — one backup set was corrupt, the other had silently stopped including the database six months earlier. Every nightly report had said “success”.

The Microsoft 365 and SaaS backup gap

This catches out more Melbourne SMEs than anything else, so it’s worth being blunt. Microsoft 365 does not back up your data in the way most people assume. Microsoft replicates your data across its own infrastructure for availability — so the service stays up if a data centre has a problem. That is not the same as a backup that protects you from your own mistakes.

Under Microsoft’s shared responsibility model, the data in Exchange Online, SharePoint, OneDrive and Teams is your responsibility to protect. If an employee deletes a mailbox folder, a departing staff member wipes a SharePoint site, or ransomware encrypts files synced through OneDrive, Microsoft’s retention windows are limited and unforgiving. A deleted user’s mailbox is gone after 30 days by default. Versioning and recycle bins help with small accidents, but they are not designed to recover from a deliberate or large-scale data loss.

The same logic applies to other SaaS platforms — Xero, your CRM, your practice management system. Many businesses run their entire operation on cloud apps and have never asked who is responsible for backing the data up. The honest answer is usually: nobody. A proper backup strategy treats Microsoft 365 and key SaaS data as first-class assets to be backed up independently, with their own restore tests. We cover the full backup picture in our guide to backup and disaster recovery for Melbourne businesses.

The four types of DR testing

“Testing your DR” isn’t a single activity. There’s a ladder of tests, from cheap and frequent to involved and occasional. A mature business uses all four for different purposes.

Restore verification

The foundation. You pick data from a backup and actually restore it, confirming it opens and is intact. Done monthly, this catches corrupt backups and coverage gaps long before a real incident. It’s low effort and there is no excuse for skipping it — yet it’s the test most businesses never run.

Tabletop exercise

A tabletop is a structured walkthrough, no live systems touched. You gather the people who’d respond to a disaster, present a realistic scenario — “ransomware has encrypted the file server and the backup NAS at 9am on a Monday” — and talk through exactly who does what, in what order, using what. Tabletops surface the human gaps: nobody knows where the recovery runbook lives, the only person with the backup credentials is on leave, no one’s sure who decides to declare a disaster. Cheap to run, brutally revealing.

Partial and full failover

Failover testing is the real thing — you actually recover systems. A partial failover brings one workload back, often into an isolated environment so it doesn’t disrupt production. A full failover recovers the entire environment and confirms the business could genuinely operate from the recovered state. Full failover is the most demanding test and the most honest one. It’s where you discover that recovery takes eleven hours, not the three you’d promised the board.

How to actually run a test

Testing fails when it’s vague. “We should test our backups sometime” never happens. Here’s the approach that works:

1. Schedule it. Put recurring dates in the calendar — monthly restore verification, a tabletop each half, an annual failover. If it isn’t booked, it won’t happen.
2. Pick a real recovery scenario. Don’t test the easy case. Choose something that would actually hurt: the primary file server lost, the finance database corrupted, the email tenant compromised. Test what you’re afraid of, not what’s convenient.
3. Time it against your targets. Start a clock. How long until the data is back and usable? Measure it against your Recovery Time Objective (RTO) and check the recovered data is recent enough to satisfy your Recovery Point Objective (RPO). A restore that works but takes three days when your RTO is four hours is a failed test.
4. Document the gaps. Write down everything that went wrong or slowly — missing credentials, an out-of-date runbook, a system nobody knew wasn’t covered. The output of a test is a list of fixes, not a pass mark.
5. Fix and re-test. Close the gaps, then test again to confirm. A test that finds problems you never fix is theatre.

The discipline here is the same one that separates a real plan from a hopeful one. If you can’t put a stopwatch on your recovery and read the number out loud to your directors, you don’t have a tested plan.

Tying results back to RTO and RPO

This is the point of the whole exercise. Your RTO is how long the business can tolerate being down before the damage is serious. Your RPO is how much data you can afford to lose, measured in time. These aren’t IT numbers — they’re business decisions about survival, and we walk through setting them in our piece on RTO versus RPO and how long your business can survive without IT.

A DR test exists to prove your recovery meets those targets. You set an RTO of four hours; the test reveals actual recovery takes nine. That’s not a failure of the test — it’s the test doing exactly its job, exposing a dangerous gap before a real incident does. Now you have a choice: invest in faster recovery, or honestly revise the target and tell the business what to expect. Either way you’re working from reality instead of a comforting assumption.

Untested, RTO and RPO are just numbers in a spreadsheet. Tested, they become commitments you can stand behind. That’s the difference between business continuity that exists on paper and business continuity that actually holds when the building floods or the ransomware note appears.

How managed backup with monthly restore verification works

The reason most businesses don’t test is honest: it’s tedious, easy to defer, and the day job always wins. That’s precisely why it belongs with a provider who does it as routine rather than something you’ll get to “next quarter”.

Under our managed backup and disaster recovery service, restore verification is scheduled, not optional. Each month we pull real data back from backups — including Microsoft 365 — and confirm it’s intact, not just that the job reported success. Coverage is reviewed as your environment changes, so the new server or cloud app doesn’t quietly fall outside protection. When something fails, we find out during a test on a quiet Tuesday, not during an incident at 9am on a Monday with the whole business watching.

TechAssist is a Melbourne-based MSP founded in 2014, with 13 Australian-employed engineers and a 24/7 NOC in Tecoma. We run backup as an operated service — monitored, tested and tied to your RTO and RPO — alongside managed IT, because a backup nobody verifies is the most expensive false comfort in IT.

Frequently asked questions

How often should we test our disaster recovery?

Restore verification monthly, a tabletop exercise twice a year, and a failover test annually where the risk warrants it. The cheap, frequent tests catch the most failures, so don’t skip restore verification just because it feels routine — that routine is exactly what protects you.

Isn’t my Microsoft 365 data already backed up by Microsoft?

No. Microsoft keeps your data available across its infrastructure, but protecting it from deletion, ransomware and human error is your responsibility under their shared responsibility model. Default retention is limited and won’t save you from a large or deliberate data loss. Microsoft 365 needs its own independent backup with its own restore testing.

What’s the difference between a tabletop and a real failover test?

A tabletop is a discussion — you walk through a scenario to check your people, roles and decisions, without touching live systems. A failover test actually recovers systems and proves the technology works. You need both: the tabletop finds the human gaps, the failover finds the technical ones.

What does a failed DR test mean?

It means the test worked. Finding a corrupt backup, a missing system or a recovery that blows past your RTO during a controlled test is the entire point — far better there than during a real disaster. A test that surfaces problems has just saved you. The failure is never testing at all.

Stop hoping, start proving

A plan you’ve never tested is a guess about the worst day of your business year. The fix isn’t more documentation — it’s putting a stopwatch on a real restore and reading the number honestly. Verify your backups, close the Microsoft 365 gap, run the tabletop, and prove your recovery actually meets the targets you’ve set.

If you’re not certain your backups would come back — or you’ve never actually tried — get in touch. We’ll run a real restore test, time it against your RTO and RPO, and tell you plainly where you stand. Better to find out now than to find out mid-incident.

Introduction

Cyber security has become a crucial aspect of modern business operations as organisations increasingly rely on digital technology. The Australian Cyber Security Centre (ACSC) developed the Essential 8 recommendations as a practical guide to help organisations of all sizes and industries enhance their security posture. These recommendations address critical areas of vulnerability, aiming to protect businesses from cyber threats while promoting a proactive approach to risk management.

Overview of the Essential 8

Understanding the Essential 8 recommendations is crucial for organisations seeking to enhance their cyber security posture. These guidelines address various aspects of IT security, ensuring a comprehensive approach to risk management.

Application control is vital in preventing unauthorized applications from running on business systems, as such applications can introduce vulnerabilities or act as attack vectors. Best practices for implementing application control include maintaining a whitelist of approved applications, regularly reviewing and updating the list, and monitoring application usage.

Patching applications is critical for protecting against known vulnerabilities. Timely patching reduces the window of opportunity for cyber criminals to exploit these weaknesses. To manage patches effectively, organisations should establish a patch management process, prioritize patches based on risk, and monitor patching success rates.

Configuring Microsoft Office macro settings is essential due to the risks associated with malicious macros, which can be used to deliver malware or exploit vulnerabilities. Organisations should follow guidelines for secure macro settings, such as disabling macros by default, allowing only digitally signed macros, and providing user training on macro security.

User application hardening involves minimising the attack surface by reducing vulnerabilities in applications. This can be achieved by disabling unnecessary features, removing unused plugins, and configuring applications with security in mind. Different applications may require specific hardening measures, which should be aligned with industry best practices.

Restricting administrative privileges plays a significant role in mitigating cyber attacks, as privileged accounts can be targeted to gain unauthorized access to sensitive data and systems. To limit and monitor administrative privileges, organisations should implement least privilege policies, regularly review user permissions, and employ tools for tracking privileged access.

Keeping operating systems patched is crucial for maintaining a secure IT environment. Best practices for efficient OS patch management include automating patch deployment, prioritizing critical updates, and monitoring patch success rates.

Implementing multi-factor authentication (MFA) significantly enhances security by requiring additional verification methods beyond just a password. When selecting and deploying MFA solutions, organisations should consider factors such as ease of use, compatibility with existing systems, and the level of security provided.

Performing regular backups is vital for ensuring business continuity in the event of data loss or a cyber attack. Effective backup strategies include scheduling automated backups, storing backups offsite or in the cloud, and periodically testing backup restoration processes.

Essential 8 Maturity Model

The Essential 8 Maturity Model offers a structured approach to assessing and improving an organisation’s cyber security posture. This model features four maturity levels, each reflecting the degree to which the Essential 8 recommendations have been implemented.

To assess an organisation’s current maturity level, a thorough evaluation of existing security controls, policies, and procedures should be conducted. This assessment helps identify areas of strength and weakness, providing valuable insights for decision-makers.

Developing a roadmap for progressing towards higher maturity levels involves setting achievable goals and outlining specific actions to address identified gaps. This strategic approach ensures that resources are allocated effectively and that the organisation’s security posture is continuously improved.

Challenges in Implementing the Essential 8

While the Essential 8 recommendations provide a robust framework for enhancing cyber security, organisations may face challenges in their implementation. One common obstacle is resource constraints, as businesses often have limited budgets and competing priorities. This may result in cyber security initiatives being delayed or deprioritized.

Another challenge is resistance to change from employees, who may be hesitant to adopt new security measures or modify their routines. This resistance can be mitigated through effective communication, training, and ongoing support to help employees understand the importance of the Essential 8 and their role in maintaining a secure environment.

Lastly, implementing the Essential 8 requires regular monitoring, maintenance, and updates to ensure that security controls remain effective and up-to-date. This ongoing commitment can be resource-intensive and may require the involvement of multiple stakeholders within the organisation.

How TechAssist Can Help with Cyber Security and Essential 8 Compliance

Partnering with TechAssist can ease the challenges of implementing the Essential 8 recommendations and enhance an organisation’s cyber security posture. TechAssist offers comprehensive IT security solutions tailored to meet the needs of businesses of all sizes and industries.

TechAssist’s expertise in IT security best practices ensures that their solutions align with the Essential 8 guidelines. Their services include:

• Threat detection and prevention: TechAssist utilizes advanced tools and technologies to identify and mitigate potential cyber threats, safeguarding your organisation’s digital assets.
• Data backup and recovery: TechAssist offers robust data backup solutions to ensure business continuity in the event of data loss or a cyber attack. Their recovery plans are designed to minimise downtime and financial losses.
• Compliance management: TechAssist helps organisations meet regulatory requirements and maintain compliance with the Essential 8 recommendations, reducing the risk of penalties and reputational damage.

In addition to their technical expertise, TechAssist’s personalized approach and commitment to customer satisfaction set them apart as a reliable partner for your organisation’s cyber security needs. By working closely with your team, TechAssist ensures that their solutions are tailored to your unique business requirements, fostering a secure and resilient IT environment.

Secure Your Cyber Future

Throughout this blog, we’ve discussed the importance of the Essential 8 in enhancing an organisation’s cyber security posture and the benefits of partnering with TechAssist to achieve Essential 8 compliance. TechAssist provides comprehensive IT security solutions tailored to your organisation’s needs, ensuring that your digital assets are protected. With their personalized approach, commitment to customer satisfaction, and deep expertise in IT services, TechAssist is an ideal partner in your journey towards a more secure IT environment. Visit TechAssist’s website to learn more about their IT security solutions and get started on your Essential 8 journey.

Why IT Security Matters for Your Business

Businesses today face an array of cyber threats, making IT security crucial to protect sensitive information and maintain operations. TechAssist understands the importance of IT security and offers expert solutions tailored to your needs, ensuring comprehensive protection and compliance with industry standards. Emphasizing our commitment to customer satisfaction, we deliver reliable technology to secure your business and safeguard your digital assets.

Understanding IT Security

IT security, also known as cybersecurity, encompasses the measures taken to safeguard digital information and systems from unauthorized access, theft, or damage. With the rapid growth of technology and increased dependence on digital systems, IT security has become a crucial aspect of modern business operations.

As businesses continue to rely heavily on digital platforms for communication, data storage, and transactions, the importance of IT security cannot be overstated. Failing to prioritize IT security can have severe consequences, including financial loss, damage to reputation, and legal repercussions. In today’s digital world, a robust IT security strategy is essential for businesses to protect their sensitive data, maintain customer trust, and ensure compliance with industry regulations.

Common threats faced by businesses in the realm of IT security include malware attacks, phishing attempts, ransomware, and data breaches. These cyber threats can lead to significant financial and reputational damage, emphasizing the need for comprehensive protection. By understanding the potential risks and taking proactive measures to safeguard your digital assets, you can ensure the security and success of your business.

Reasons Why IT Security Should Be a Top Priority for Your Business

Making IT security a top priority for your business is vital for several reasons. First and foremost, it ensures the protection of sensitive data, both your own and that of your customers. Safeguarding this information is crucial to prevent data breaches, which can result in severe financial and reputational damage. A proactive approach to IT security also helps maintain customer trust and demonstrates your commitment to their privacy.

Compliance with industry regulations and standards, such as the General Data Protection Regulation (GDPR) and the Health Insurance Portability and Accountability Act (HIPAA), is another critical reason to prioritize IT security. Failure to comply with these regulations can lead to substantial fines and penalties, further emphasizing the importance of a robust IT security strategy.

Additionally, a strong IT security foundation is crucial for maintaining your business’s reputation. Security breaches can severely impact customer trust and tarnish your image in the market. By proactively addressing IT security risks, you can protect your business’s reputation and ensure continued customer confidence.

Finally, prioritizing IT security is essential for business continuity. Cyber attacks and breaches can disrupt operations, causing significant downtime and financial losses. A solid IT security strategy plays a vital role in disaster recovery planning, helping to minimise downtime and maintain smooth operations in the face of potential threats.

Best Practices for IT Security

To ensure the highest level of IT security for your business, start by developing a comprehensive strategy. This involves identifying potential risks and vulnerabilities, followed by establishing protocols and procedures to address these threats. By having a robust plan in place, you can better navigate the complex landscape of cybersecurity.

Implementing strong security measures is a crucial aspect of maintaining IT security. This includes regular software updates and patches, which help prevent potential vulnerabilities from being exploited. Network monitoring and intrusion detection systems also provide an additional layer of protection by detecting and responding to any unauthorized access or suspicious activity.

Training employees on IT security best practices is essential to maintain a secure environment. Staff members should be educated on potential threats, such as phishing attempts and malware, to minimise the risk of breaches. Ongoing training and awareness programs ensure that employees remain vigilant and informed about emerging threats and security measures.

Regularly reviewing and updating IT security policies and procedures is vital to stay current with evolving threats and technologies. As the cyber landscape changes, adapting security measures accordingly is crucial to ensure continued protection. By following these best practices, you can safeguard your business against cyber threats and maintain a robust IT security posture.

How TechAssist Can Help Secure Your Business

TechAssist brings extensive expertise and experience in IT security, offering comprehensive solutions tailored to the unique needs of your business. Our team of knowledgeable professionals is dedicated to providing the highest level of security and customer satisfaction.

Our IT security solutions encompass a wide range of services, including risk assessment, policy development, network monitoring, and incident response. These services are designed to identify and address potential vulnerabilities, ensuring that your business remains protected from evolving cyber threats.

By partnering with TechAssist for your IT security needs, you can benefit from our commitment to customer satisfaction, advanced technology solutions, and industry best practices. Together, we can safeguard your business’s digital assets and help maintain a secure and successful operation.

Secure Your Business with TechAssist

In this digital age, prioritizing IT security is essential for businesses to protect sensitive data, maintain customer trust, ensure compliance with industry regulations, and promote business continuity. Investing in a comprehensive IT security strategy can help safeguard your business against evolving cyber threats and minimise the impact of security breaches.

TechAssist is here to support you with expert IT security solutions tailored to your needs. Our team of experienced professionals is dedicated to providing reliable technology and exceptional customer satisfaction. Don’t wait to secure your business – take action today. To learn more about how TechAssist can help protect your digital assets and keep your business running smoothly, please visit our website or contact us for assistance.