A business restores its servers after a ransomware attack. Orders are moving again, staff can sign in and the backup report is green. Management wants to tell customers the problem is resolved.
That conclusion may be premature. Restoring systems addresses availability. It does not establish whether customer information was copied before the encryption, whether an attacker still has access, or whether the business has a notification obligation. Those questions need separate evidence and separate decisions.
For an Australian business, this distinction changes the incident budget, the advice it needs and what it can responsibly say to customers. A recovery plan built around getting systems online can succeed technically while leaving the business exposed commercially and legally.
The attacker does not need your systems to stay offline
One possible attack sequence begins with compromised remote access, an exploited application or another foothold. The intruder uses accessible accounts to find valuable records, may gather them into an archive, and transfers copies outside the business. Encryption can follow, creating a second pressure point. These steps can vary, and data theft or extortion can occur without encryption.
A backup restores your copy. It cannot retrieve an attacker’s copy. Rebuilding an endpoint also does not necessarily revoke access to a cloud account, invalidate every stolen credential or remove an unauthorised application integration. Containment must address the access paths involved, not only the visibly encrypted devices.
The Australian Cyber Security Centre explicitly warns that paying a ransom does not stop criminals from sharing or selling stolen information. A successful restore is equally incapable of proving deletion at the attacker’s end. Neither a restored application nor an extortionist’s assurance is evidence that confidentiality has been recovered.
A commercial scenario: services resume, customer exposure remains
Consider a hypothetical Australian professional-services business whose file server contains identity documents, signed authorities and customer correspondence. An attacker obtains access through a compromised account, copies selected files, then encrypts the server. The business restores a clean backup and resumes client work.
Operationally, the restore is valuable. Commercially, the incident is not finished. If those records were taken, customers may face targeted impersonation or other misuse. The business may need specialist investigation, legal assessment, customer support and carefully controlled communications, even though its applications are functioning.
This is an illustrative scenario, not a reported incident. The exposure depends on which records were accessible, what the evidence shows, the individuals affected and any effective remedial action. An attacker’s file list is a lead to investigate, not automatically an accurate inventory of everything stolen.
Three decisions that should not share one sign-off
Operational recovery: Can the service run safely from a verified recovery point? The IT recovery owner should demonstrate that restored systems work, dependencies are available and the recovery environment is appropriately secured. The board or business owner should understand any remaining service limitations.
Containment and exposure: Have the relevant access paths been closed, and what can the investigation establish about unauthorised access or extraction? The incident-response lead should record findings, uncertainty and the scope of evidence. A green backup dashboard answers neither question.
Notification and communications: What must the business tell customers, regulators, insurers or contractual partners, and when? Assign an accountable executive supported by privacy and legal advisers. Do not make the person restoring servers solely responsible for interpreting legal duties or approving public statements.
These workstreams run in parallel. They do not require waiting for every forensic question to be settled before taking protective action, meeting an applicable deadline or issuing a carefully qualified update.
What evidence management should ask for
The first useful question is not simply, “Did the backup work?” It is, “What evidence separates what we know from what we are assuming?”
- A defensible access timeline. Preserve relevant identity, endpoint, file-access, application and network records before rebuilding or log expiry removes them. Record time zones and gaps. Have responders decide how to preserve evidence while containing harm; staff should not improvise destructive cleanup.
- Data scope, not just device scope. Identify the customer-information categories reachable through affected accounts, including cloud repositories and third-party applications where relevant. Distinguish confirmed access, suspected access and confirmed extraction.
- A documented containment basis. Record which accounts, sessions, remote-access paths and integrations were investigated and remediated. Credential rotation may be necessary, but its effectiveness depends on the identity system and access method involved.
- The limits of the investigation. If logs were never collected, expired or lack file-level detail, absence of an alert is not proof that no information left. Conversely, an unusual transfer alone does not establish exactly which customer records were taken. State the uncertainty and the further evidence required.
These are investigation requirements to agree with qualified responders, not a direction to let an untrained employee interrogate an attacker or handle forensic evidence independently.
Australian reporting: do not confuse the triggers
Privacy notification is about eligible data breaches, not whether a ransom was paid. Under the OAIC’s guidance, entities covered by the Notifiable Data Breaches scheme must assess suspected eligible breaches promptly. Notification generally becomes necessary where the relevant unauthorised access, disclosure or loss is likely to cause serious harm and effective remedial action has not prevented that risk, subject to applicable exceptions.
For a suspected eligible breach, a covered entity must take all reasonable steps to complete its assessment within 30 calendar days after becoming aware of the grounds for suspicion. This is not permission to wait 30 days before acting. Where there are reasonable grounds to believe an eligible breach has occurred, notification obligations arise promptly. Being a small business does not, by itself, settle coverage; exceptions and information-specific obligations can matter.
Ransomware-payment reporting has a different trigger. Home Affairs’ guidance under the Cyber Security Act 2024 requires reporting business entities to report ransomware or cyber-extortion payments within 72 hours of making a payment, or becoming aware of a payment made on their behalf. Coverage includes businesses meeting the prescribed turnover test and relevant responsible entities for critical infrastructure assets. Confirm the precise criteria with an adviser rather than assume all Australian businesses have identical duties.
A demand with no payment does not trigger that particular payment-reporting obligation. It can still leave privacy, contractual, insurance or other reporting duties. A report to one agency should not be assumed to discharge a different obligation. Outsourcing the response also does not automatically transfer the business’s responsibility.
The Australian Government strongly discourages ransom payments. Payment offers no reliable guarantee of recovery or non-disclosure, and particular payments can raise sanctions or other legal issues. This article is not advice to negotiate or pay.
What to change before the next incident
Keep restore testing, but broaden the exercise. Ask your IT provider to demonstrate how identity and file-access evidence would be obtained, who can authorise containment, and how response continues if normal email or administrator accounts are unavailable. Confirm what logs your actual licences retain, for how long, and who can export them during an incident.
Have finance and management understand the difference between recovery costs and the wider cost of investigation, advice, notifications and customer assistance. Review provider and insurer arrangements before an emergency: contacts, authorisation, evidence ownership, access to logs and the process for engaging specialists. Do not assume those services are included in a routine backup or support agreement.
The executive reporting line should be explicit: service restored; containment position; data-exposure findings; notification decisions; unresolved risks and named owners. A single “recovered” status conceals decisions that deserve separate scrutiny.
How Xpansion can support your next step
Xpansion Technologies can help review the technical connections between backup recovery, identity controls, logging and incident escalation, and identify where specialist response or legal support needs to be arranged. Privacy and payment-reporting determinations should remain with appropriately qualified advisers and the accountable business owner.
The management question is not whether backups matter. They do. It is whether your business can distinguish getting its systems back from understanding what happened to its customers’ information.
References
- Australian Signals Directorate, Australian Cyber Security Centre: Steps to take following a ransomware attack
- Australian Department of Home Affairs: Mandatory ransomware and cyber-extortion payment reporting guidance
- OAIC: Quick reference guide for responding to data breaches, published 29 June 2026
Sources checked for this draft on 2 November 2026. This is general technical and business-risk information, not legal advice. Reporting requirements depend on the entity and circumstances.
Leave a comment