Back to articles

Dark web monitoring is a signal, not a breach decision

What leaked credentials and dark web findings can tell you, and why they do not by themselves decide whether an Australian data breach is notifiable.

A security signal entering a control plane, followed by verification, response, and notification pathsTasmanian Cloud a security signal entering a control plane, followed by verification, response, and notification paths.[PATCH REPORTING]HOSTpackage stateSCANfinding and ageREPORTwebhook or emailKeep the boundary explicit. Let each system do the work it is good at.

A dark web finding is evidence to investigate

Dark web monitoring can identify a credential, email address, token, or other identifier in a source that should not contain it. That is useful operational evidence. It does not prove how the value was obtained, whether it is still valid, which system was accessed, or whether personal information was exposed.

Treat the finding as a trigger for verification. Record the source, time, affected identity, confidence, and action taken without copying the exposed value into tickets, chat, or an AI prompt.

The Australian NDB threshold is specific

The Australian Notifiable Data Breaches scheme concerns eligible data breaches. The OAIC describes an eligible breach as unauthorised access, unauthorised disclosure, or loss of personal information that is likely to result in serious harm, where remedial action has not prevented that likely harm.

A dark web alert may be one input to that assessment. It is not a substitute for determining whether personal information was involved, which entity held it, the likelihood of serious harm, and whether an exception applies.

Connect the signal to the affected asset

A useful security workflow links an alert to the service identity, host, container, account, or deployment that needs checking. Dialkeys and API-owned resource state help connect a finding to the system without spreading the underlying secret or personal data through unrelated tools.

The control plane should show what was observed, what was checked, who owns the response, and whether the finding is open, contained, remediated, or awaiting an external decision.

Contain first, then decide

A response may include revoking a credential, rotating a key, forcing a session reset, isolating a workload, checking access logs, and preserving evidence. Those actions can reduce risk while the organisation assesses its notification obligations.

Notification is a legal and organisational decision. Use the current OAIC guidance and qualified privacy or legal advice for the incident. Do not present monitoring software as a certification or as a decision engine for the NDB scheme.

Send the right signal

A confirmed high-priority finding can create a signed webhook for the response system, an email for the people who must act, or an ntfy-compatible notification for an operator. Routine findings can remain queryable through the API and appear in a scheduled report.

Delivery changes who receives the signal. It does not change the evidence, the incident state, or the organisation's responsibility for assessment and response.

Need the implementation details?

Read the Tasmanian Cloud documentation ↗

References

OAIC: Part 4, Notifiable Data Breach schemeOAIC: Quick reference guide for responding to data breaches