- Removal manifest
- Sheet 6 of 7
- Item 5: the keys
A safe cutover: accounts and access when a site changes host
A safe cutover starts with a list of every account that can reach the site and ends with every access nobody needs taken away. The Australian Signals Directorate’s advice for outside IT providers is to know which systems each one can reach and keep that record up to date, give them only the access their role needs, and remove access once it is no longer needed.
This sheet summarises published guidance; it is not technical advice for your own systems. The Australian Signals Directorate’s cyber.gov.au is the official place to check.
01Why a host counts as an outside provider
Much of the ASD’s advice on access is written for managed service providers, which it says often need access to an organisation’s systems, networks and sensitive data. It says many of its recommendations apply to any outsourced ICT service provider, not only to those firms. On this guide’s reading, a hosting company, a developer with an admin login and the agency that built the site all fit that description, and a move adds one more to the list before it takes one away.
02The cutover, in three parts
Before: make the list
- Write down which systems each provider can reach, and how. The ASD’s advice is to identify this clearly for every provider and to keep the record up to date.
- Check who receives the domain’s notices. auDA says a registrar sends the transfer authorisation code to the registrant contact email in the .au registry, and the ASD suggests having more than one staff member listed for renewal notifications.
- Turn on multi-factor authentication at the new host. The ASD’s advice is to use it for every account with administration privileges for your website, such as accounts with access to its content management system.
On the day: hand over only what is needed
- Give each provider its own account, with the least privilege it needs. The ASD recommends least-privilege accounts for providers, and accounts that can be attributed to the provider so its activity is easy to pick out in logs.
- Pass the domain’s authorisation code the way the rules allow. Under auDA’s rules a registrar gives the code only to the registrant contact in the registry data, unless the registrant has authorised it in writing to go to a third party.
- Protect remote access. Where a provider logs in remotely, the ASD advises multi-factor authentication on those services, and suggests blocking provider access by default and allowing it at an agreed time.
After: close the old doors
- Change the domain’s authorisation code. auDA’s rules require the registrant to change it within two calendar days after the licence moves to a new registrar; if that does not happen, the new registrar may reset it.
- Remove access nobody needs. The ASD advises reviewing user access often and removing it when it is no longer needed, noting that staff changing roles or leaving can put your data and website at risk.
- Change the logins people knew. The ASD’s small business handbook says to update or change key logins when staff turn over. Treating a departing host or developer the same way is this guide’s suggestion, in keeping with the ASD’s point that its provider advice applies to outsourced ICT services generally.
- Keep the logs. The ASD recommends keeping event logs for at least 18 months, and notes some organisations may have a regulatory requirement to keep them longer.
03Who held which key
A move is easier to close out with the keys written down in one place. This blank layout is an illustration of such a list, not a form any regulator prescribes; each row is something the sources on this sheet mention.
| Key | Where the rule comes from | Changed or removed after the move? |
|---|---|---|
| Domain authorisation code | auDA Licensing Rules, section 2.12 | Within two calendar days of a registrar transfer |
| Website admin accounts | ASD, Secure your website | Reviewed, and removed when no longer needed |
| Provider accounts | ASD, managing a service provider | Least privilege while in use; recorded and kept up to date |
| Shared logins | ASD, small business handbook | Updated or changed when people leave |
| Encryption keys for records | ATO, TR 2018/2 | Kept, with a means of access, for the retention period |
The last row runs the other way from the rest: the ATO’s ruling asks you to keep encryption keys for encrypted records, so those are kept rather than thrown away. Keeping business records through a move explains why.
04If something goes wrong
The ASD says to report cybercrimes, incidents and vulnerabilities, and points to its online reporting. Its guidance on service providers adds that where personal information is lost or compromised, there may be a legal duty to report the incident to the Office of the Australian Information Commissioner. Whether that duty applies to your business is covered in getting your data back, and deleting it.
For questions about its guidance, the ASD lists the phone number 1300 CYBER1 (1300 292 371) on its own publication pages.
Sources for this sheet
- Australian Signals Directorate: How to manage your security when engaging a managed service provider
- Australian Signals Directorate: Secure your website
- Australian Signals Directorate: Small business cyber security handbook, Restrict and monitor access
- auDA: .au Domain Administration Rules: Licensing (section 2.12)
- auDA: How to transfer your .au domain name
- ATO: TR 2018/2, record keeping and access for electronic records