Choosing website hosting in Australia comes down to a handful of questions that matter more than price or disk space: where your data is stored and under whose law, who patches what, whether backups have actually been restored, who answers the phone during your business hours and whether you can leave cleanly. This guide sets out what to ask and what good answers look like.
Data residency versus data sovereignty
The two terms are often used interchangeably, but they mean different things.
- Data residency is where the data physically sits: which data centre, in which city, and where the backups and replicas live.
- Data sovereignty is which country's laws can reach that data. A provider can store your data in Sydney or Melbourne and still be subject to a foreign government's legal process if the provider, or its parent company, is based overseas.
For many websites, residency is enough. For applications holding health, financial or government information, ask who owns the provider, where its administrators are located and where support and monitoring tools send data. Logs, backups and remote support sessions are where data most often leaves the country without anyone deciding that it should. We covered the same distinction for email and files in our article on Microsoft 365 and Australian data sovereignty.
Where the Privacy Act and APP 8 fit
If your site or application holds personal information and your organisation is covered by the Privacy Act 1988, Australian Privacy Principle 8 applies when you disclose that information to an overseas recipient. Before doing so you must take reasonable steps to ensure the recipient does not breach the APPs, and under section 16C you can remain accountable for what the recipient does with it.
The OAIC's APP 8 guidelines (opens in a new tab) explain that giving information to an overseas cloud provider purely for storage and management may be a "use" rather than a disclosure, but only where a binding contract limits what the provider can do, extends those limits to subcontractors and leaves you with effective control over access, retrieval and deletion. That is a contractual and factual question, so read the hosting agreement with it in mind. Hosting with an Australian provider in Australia removes much of the uncertainty, but not your other obligations, such as securing the information under APP 11.
What a CDN does and does not change
A content delivery network caches copies of your site's files at edge locations close to visitors, improving load times and absorbing some traffic floods. Be clear about its limits.
- It can move data offshore. Edge locations are usually worldwide, so cached pages and files may be served from other countries. Some providers offer options to restrict where content is cached or decrypted, usually on higher plans, so check rather than assume.
- It often sees your traffic in clear text. Many CDNs terminate TLS at the edge, which means form submissions and logins pass through the CDN decrypted. Treat the CDN as another processor of your data.
- It does not move your origin. Your database and application still run where your host runs them. A CDN will not fix a slow or unpatched server.
Backups and tested restores
Ask how often backups run, how long they are kept, where they are stored and whether one copy is immutable or held separately from the hosting account. A backup kept on the same server, or deletable with the same login, will not help after a compromise. Then ask when a restore was last tested and how long it took. The real measure of a backup is a successful restore. Our article on backup and disaster recovery covers the 3-2-1-1-0 approach in more detail.
Patching and shared responsibility
Every hosting arrangement splits responsibility between you and the provider, and problems start when each side assumes the other is handling something. As a rough guide:
- Shared hosting: the provider patches the server and the web stack; you are responsible for your CMS, plugins, themes and user accounts.
- Managed servers: the provider usually patches the operating system and core services; application updates depend on the contract.
- Unmanaged virtual servers or cloud: almost everything above the hardware is yours.
Get the split in writing. For a benchmark, the ASD's Essential Eight maturity model (opens in a new tab) expects patches for vulnerabilities in online services to be applied within 48 hours when the vendor rates them critical or a working exploit exists, and within two weeks otherwise. If your site runs WordPress or another CMS, ask specifically who applies plugin and theme updates, and how quickly.
TLS and web application firewalls
Every site should be served only over HTTPS, using TLS 1.2 or later (TLS 1.3 where supported), with HTTP redirected and certificates renewed automatically. Automation matters: under the CA/Browser Forum's Ballot SC-081 (opens in a new tab), the maximum lifetime of public TLS certificates is being reduced in stages from March 2026 to 47 days by March 2029. Manual renewal will not keep up.
A web application firewall filters malicious requests such as SQL injection and automated login attacks before they reach your application. It is a sensible layer, but it reduces risk rather than replacing patching. Ask whether a WAF is included, who tunes its rules and who is alerted when it blocks something.
Uptime and support in Australian business hours
An uptime figure in a service level agreement means little unless you know how it is measured, what is excluded (often scheduled maintenance) and what you receive when it is missed, usually a small service credit. Ask too how incidents are communicated and how quickly a real person responds.
Check support hours against your own: Australia has several time zones, and daylight saving applies in some states but not others. If your site takes orders or bookings, ask what after-hours cover exists and whether it costs extra.
Exit and portability: who owns the domain, DNS and code
- Domain: for a .au name, the registrant named on the licence is the holder, and the auDA licensing rules (opens in a new tab) require that holder to have an Australian presence. Make sure the registrant is your organisation, not your web developer or host, and that you can log in to the registrar account.
- DNS: know where DNS is hosted and who holds the login. Whoever controls DNS controls your website and email delivery.
- Code and content: confirm in the contract that you own the site code, database and media, and that you can export them in a standard format at any time.
- Notice periods: check minimum terms, cancellation notice and any fees for handing over data.
Red flags in cheap shared hosting
Low-cost shared hosting suits simple brochure sites, but watch for:
- No stated data centre location, or backups held overseas.
- Backups described as a courtesy, kept on the same server, or charged per restore.
- Outdated PHP or database versions still offered as defaults.
- FTP without encryption, and no multi-factor authentication on the control panel.
- The domain registered in the provider's name.
- Advertised prices that apply only to the first year of a long term.
Questions to ask a hosting provider
- In which data centres are our data, backups and logs stored?
- Is your company, or its parent, subject to foreign laws that could compel access to our data?
- What exactly do you patch, how quickly, and what is our responsibility?
- How often are backups taken, is one copy immutable, and when did you last test a restore?
- Is a WAF included, and who manages it?
- What are your support hours in our time zone, and what does after-hours cover cost?
- Will the domain, DNS and code stay in our name, and how do we export everything if we leave?
Asset Hosting provides managed website and application hosting from Australian data centres, and if you would like help weighing up your options, get in touch.