Building a Triage Protocol for Suspected Data Exfiltration

When an organisation suspects that sensitive records are leaving the network, the first hour shapes everything that follows. A triage protocol for suspected data exfiltration is not a forensic deep-dive and it is not a public statement. It is the structured bridge between an alert and a defensible response, the moment where raw telemetry becomes a working theory of the breach.

In Australia, this bridge matters more than ever. The Notifiable Data Breaches scheme, sitting under the Privacy Act 1988 and the Australian Privacy Principles, forces organisations with an annual turnover above $3 million to assess and report eligible incidents within 30 days. For APRA-regulated entities, CPS 234 imposes tighter timelines for material incidents. A triage plan that is rehearsed and documented becomes the difference between a measured regulator notification and a chaotic scramble from a Sydney CBD boardroom.

Most teams discover the value of a triage protocol only after the first real event. A SOC analyst sees an unusual outbound flow to an IP in a jurisdiction the business has no reason to contact. A help desk technician notices that an executive has exported a customer list at 2am AEST. Without a protocol, these signals sit in inboxes. With a protocol, they trigger a known sequence of decisions, owners and artefacts.

The protocol also protects the business from itself. A premature containment step can destroy volatile memory evidence. A delayed statement can erode trust with customers in Melbourne, Brisbane or Perth who read about the breach on a phone before the response team has briefed them. Triage is therefore as much about discipline and pacing as it is about technology.

Defining Triage Objectives and Scope

Triage begins with a single question: is data actually leaving the environment, and if so, what kind, in what volume, to whom? The protocol must answer this question in minutes, not hours.

The first objective is rapid classification. Each suspected event is placed into one of three buckets: confirmed exfiltration, probable exfiltration, or anomalous-but-unconfirmed activity. The bucket determines who is paged, what systems are touched and whether external counsel is briefed before lunch in Adelaide or Sydney. The second objective is preservation of volatile artefacts, including process memory, network session state and authentication tokens that may never be recoverable later.

The protocol must also lock down who does what. Legal, the board, the privacy officer and the managed detection partner each have a defined lane, with a named owner for the regulator notification and the public statement. Every action taken during triage should be timestamped, attributed and reversible where possible, so the audit trail supports both internal review and any later inquiry by the Office of the Australian Information Commissioner.

Building the Detection Layer

A protocol is only as good as the signals feeding it. The detection layer for exfiltration triage relies on three families of telemetry: network, endpoint and identity. Network sensors watch for unusual outbound flows, DNS tunnelling and connections to known bullet-proof hosts. Endpoint sensors watch for large file reads, archive creation and the use of off-label tools such as rsync or powershell web transfers. Identity sensors flag impossible travel, dormant account resurrection and privilege escalation just before the data movement.

In practice, Australian mid-market organisations often rely on a single SIEM fed by Microsoft 365 Defender, a cloud proxy and a handful of EDR agents. The triage protocol must therefore assume partial coverage and compensate with human verification. An analyst confirms a TLS beaconing pattern by pulling five-minute NetFlow samples. A detection engineer confirms endpoint activity by querying the EDR for parent-child process trees around the alert time.

The protocol should also define what counts as a trigger. Thresholds matter: a 50GB spike to a single external endpoint is qualitatively different from a 200MB attachment leaving via webmail. Both are signals, but only one warrants an immediate page-out. The detection layer must produce a small number of high-fidelity events that the triage workflow can absorb.

Triage Phase Primary Objective Key Artefact Produced Typical Owner Time Target
Detection and classification Confirm whether exfiltration is occurring Annotated alert packet Tier 1 SOC analyst 0–15 minutes
Containment decision Stop further loss without destroying evidence Containment playbook ticket Tier 2 incident responder 15–60 minutes
Forensic preservation Capture volatile and log evidence Forensic image manifest Digital forensics lead 1–6 hours
Regulatory assessment Determine NDB or CPS 234 exposure Notification draft Privacy officer and counsel 6–48 hours

First-Hour Containment Actions

Once classification lands in the probable or confirmed bucket, the protocol shifts to controlled action. Containment in the first hour is about narrowing the blast radius without erasing what investigators will need. The most common mistake is to immediately reimage the affected endpoint; that step can wipe process memory, prefetch artefacts and any in-memory credentials that the attacker used.

The first-hour menu typically includes suspending the implicated user account, revoking active OAuth tokens, blocking the destination IP at the egress proxy and isolating the endpoint at the network layer. None of these actions are irreversible, and each one preserves the underlying state for later forensic work. In an Australian context, where many enterprises run hybrid environments that span Azure AD alongside on-premises Active Directory, the protocol must spell out which directory is authoritative for the suspension.

A second consideration is the supply chain. Many Australian financial services and healthcare organisations depend on outsourced SOC partners for round-the-clock coverage. The protocol must be written so that an analyst offshore and an on-call lead in Sydney can execute the same containment steps without ambiguity. Plain-language checklists, not tribal knowledge, are what make this consistent.

Forensic Preservation and Evidence Handling

Containment buys time; preservation uses it. Forensic preservation is about capturing the right things quickly, then stopping. Volatile memory of the affected endpoint, the last hour of DNS logs, the relevant proxy sessions and any cloud audit logs from the implicated identity should be exported and hashed before the system is touched further.

The protocol should name the storage destination and the access model. A read-only forensic share in a separate tenancy, encrypted at rest and access-logged, prevents the contamination that defence barristers in Australian courts frequently attack. The hashing step, even a quick SHA-256 of each artefact, gives the legal team a defensible chain of custody when the matter reaches the Office of the Australian Information Commissioner or a state Supreme Court.

Documentation runs in parallel. Each preservation action is logged with the operator, the system, the command used and the timestamp in AEST. The triage lead assigns a unique matter identifier that flows through every artefact, every ticket and every regulator draft. Without that identifier, the post-incident review will spend weeks reconstructing what actually happened.

Communication and Regulatory Notification

Triage fails when communication lags behind technical reality. The protocol must define who hears what and when. The internal cascade usually starts with the security lead, escalates to the CISO or head of risk within 30 minutes, and reaches the CEO and chair of the audit committee within the hour if the classification is confirmed.

External communication has stricter triggers. Under the NDB scheme, an eligible data breach requires a statement to the OAIC and to affected individuals as soon as practicable. APRA-regulated entities must notify APRA within 72 hours of becoming aware of a material incident. The protocol should pre-draft the holding statement, the regulator cover note and the customer email template so legal review becomes the bottleneck, not creative writing.

Customers in regional centres like Newcastle, Geelong or Townsville often experience incidents differently to those in capital cities. They may rely on a single bank branch, a local GP clinic or a regional council that processes their data. A communication plan that assumes metropolitan digital channels alone will miss segments of the population who still rely on phone, post or in-person contact. The triage lead should therefore loop in a channel-aware communications partner before the first public statement.

Post-Incident Hardening and Protocol Refinement

Triage does not end when the regulator notification is filed. The protocol must close the loop with a structured review within ten business days. The review asks three questions: what worked, what failed, and what telemetry gap allowed the incident to reach the stage it did. Each question produces an action item with an owner and a deadline.

The hardened protocol often reveals gaps that only an exercise surfaces. Many Australian organisations discover during a tabletop that their DNS logs are retained for 14 days while the relevant window was 30. Others find that their managed detection partner does not have authority to suspend an account without written client approval, costing 40 minutes that the protocol never budgeted for. Those gaps feed directly into the next iteration of the runbook.

A useful pattern is to align protocol refinements with the Essential Eight maturity uplift cycle. If a triage review identifies that application control would have blocked the initial vector, the security team can fold the relevant change into the next quarterly uplift. The triage protocol thereby becomes a forcing function for broader security improvement rather than a standalone document. Reference material that supports this kind of cross-walk, including sample runbooks and notification templates, is available in the technical document library.

Signals that justify immediate escalation

Activity that usually proves benign

A triage protocol for suspected data exfiltration is not a binder that sits on a shelf. It is a rehearsed sequence of decisions, owners and artefacts that converts a frightening alert into a structured response. In an environment where regulators, customers and boards expect measured action in hours rather than weeks, that rehearsal is the single most valuable security investment an Australian organisation can make this year. When the next suspected data exfiltration alert arrives at 2am AEST, the right answer is already written down.