Protecting client information: a security and recovery plan for RMAs

Map the records and the accounts that control them

Start with email, matter records, document storage, accounting, the website domain, and backup services. Record the business owner, administrator, recovery method, permitted users, and the information held in each. Include business information on personal devices or accounts.

Identify dependencies. If email is the recovery address for every other service, losing that account can obstruct recovery across the practice. If the same administrator can delete working records and all recovery copies, one compromised account may defeat both.

Keep an inventory of systems and responsibilities, not a spreadsheet containing passwords. Store credentials and recovery material in an appropriately protected system with access and emergency arrangements the practice understands.

Protect the accounts first

Prioritise email, domain registration, document storage, practice software, accounting, and backup administration. For each, verify who can administer it and who can recover access.

ASD recommends phishing-resistant MFA, such as supported security-key or passkey arrangements. Where that is not available, use the strongest supported option and protect the recovery path. Record how the practice would regain access after losing a phone or key; do not discover the process during an incident.

Use individual staff accounts, restrict administrator privileges, and review access when duties change or staff leave. Keep devices and software updated. Train staff to verify unusual payment or credential requests through a previously established contact method. ASD’s small business handbook provides the underlying security recommendations.

Understand storage, sync, and backup

These functions can overlap within a product. Check the actual subscription and settings. A provider’s internal recovery system may restore its service without letting you recover an individual deleted matter.

A file export is useful only if it contains the records you need and can be restored or read independently. A copy of documents without associated notes, communications, or relationships may be an incomplete recovery plan.

Set recovery targets before choosing a backup

Decide how much recent work you could reconstruct and how long the practice could operate without each system. These are the recovery point objective—the acceptable loss of recent data—and recovery time objective—the target time to restore the required service. The New Zealand NCSC explains these concepts.

For a fictional practice, a target of at most two hours of lost document changes and eight working hours to recover access is a planning choice, not a standard for RMAs. A nightly backup may leave too large a gap for that two-hour target. A recovery service that takes several days would also fail the proposed time target.

Set targets by system and test whether the proposed arrangement can meet them. Include the time to regain administrator access and obtain provider help. A fast file copy does not restore the whole practice if staff still cannot authenticate or identify the current matter position.

Check what survives each failure

Ask your provider or IT adviser to walk through:

• A laptop is stolen: can another approved device access the necessary records?
• A file is deleted and noticed weeks later: does the required version still exist?
• An administrator account is compromised: can that account also alter or delete the backups?
• The provider is unavailable: which essential records and contacts remain accessible?
• Ransomware affects working systems: is there a protected recovery copy and a process for restoring into a clean environment?

Ask whether backup copies are offline, protected by separate access, or immutable for a defined retention period. “Immutable” is a property to verify, including who can change the policy; it is not a guarantee about the entire service.

ASD’s cloud responsibility guidance sets out questions about backup coverage, frequency, access protection, and restoration. Request answers for your exact plan. Neither a drive at home nor a cloud label settles those questions.

Run a small restoration exercise

Use a fictional matter in an approved test location. Never delete a live client record to demonstrate recovery.

1. Record the sample documents, notes, and relationships that should be recoverable.
2. Confirm when the relevant backup completed and which version it contains.
3. Follow the documented restoration process into a separate test location.
4. Open the files and inspect notes, dates, permissions, and relationships.
5. Record elapsed time, missing information, required permissions, and provider assistance.
6. Assign an owner and due date to each gap, then retest the failed part after correction.

A successful sample establishes what that test demonstrated. Plan additional tests around other critical systems and significant changes. A completed backup job is evidence that a job ran; restoration is evidence about recoverability.

Separate recovery from retention and incident response

A rolling backup that expires after a short period is not a long-term archive. Align your archive and disposal process with applicable file-retention duties, including the Code’s section 56. Privacy Act coverage also requires checking against the OAIC’s small business guidance.

Keep an incident contact sheet outside the normal email dependency: provider support, IT assistance, internal decision-maker, and an alternative staff contact method. Arrange technical advice before restoring compromised systems, preserve relevant evidence, and assess applicable notification duties.

Backups help restore availability; they do not reverse information already disclosed. Use the OAIC’s security guidance when reviewing protection across the information lifecycle. This operating plan supports that work; it does not certify compliance.