Data breaches involving more than one entity (NDB)

Why this matters. A lot of Australian breach notices now start with 'a third-party provider'. Examples are a fax-to-email platform, a feedback widget wired into the CRM, or a cloud host. The Notifiable Data Breaches (NDB) scheme in the Privacy Act expects this. The OAIC's Part 4 guidance says entities often hold personal information jointly. One may physically have the records while another has legal control. A breach that is eligible for one of them is eligible for every entity that holds the affected information.

What 'holds' means. Under s 6(1) of the Privacy Act, an entity holds personal information if it has possession or control of a record containing it. Control includes a right or power to deal with the record, even when the entity does not physically have it or own the storage. The OAIC's example is cloud storage. The provider holds the records because it has them and can reach them. The customer also holds them because its contract keeps the right to access and use them. Outsourcing, Commonwealth contracts and joint ventures are the other common cases. Whether you hold the data depends on the arrangement. If a supplier builds a new record of its own from data you gave it, only the supplier may hold that new record.

One can act for all, but someone must act. Each entity holding the record is generally responsible for the NDB steps. The Act lets one entity act for the group. If one entity has assessed a suspected breach, the others do not also have to assess it (s 26WJ). Only one entity needs to give the statement to the Commissioner and notify individuals (s 26WM). The OAIC warns about the other side of this: if nobody assesses, each holder may have breached the assessment requirement, and if nobody notifies, all of them may have breached the notification requirement. 'We assumed the vendor was handling it' is not a defence.

Who should notify. The Act does not say which entity assesses or notifies, so the parties decide. The OAIC's general advice is that the entity with the most direct relationship with the affected individuals should notify them. That is usually the brand the customer or patient recognises, not the processor behind it. The statement may name the other entities involved and give their contact details (s 26WK(4)). This is optional, so decide case by case whether it helps the people being notified.

Overseas providers. If you send personal information to an overseas recipient under APP 8.1, you are treated as still holding it for NDB purposes (s 26WC). If that recipient is breached, you must assess the breach and, if it is eligible, notify. If you disclosed it under one of the APP 8.2 exceptions instead, you are not treated as holding it, and a breach at the recipient does not give you NDB notification duties. Credit providers have a similar rule for credit eligibility information passed to bodies without an Australian link.

Other exceptions that interact. Where an enforcement body relies on the enforcement-related-activity exception, the other entities involved do not have to notify individuals either. They normally need a dated written statement signed by that body's CEO before relying on it. Secrecy provisions in Commonwealth law can also limit statements or notices. Breaches already notified under s 75 of the My Health Records Act do not need a separate NDB notification. None of these exceptions removes the need to contain the breach and record your decisions.

Put it in the contract. The OAIC asks entities that share information to agree NDB procedures when they sign the service agreement. A practical clause set covers six things: how fast the supplier must tell you about a suspected breach, and through which channel and contact; who runs the assessment and how you get the evidence (logs, record lists, forensic findings); who contains and remediates; who notifies the OAIC and individuals, and who signs off the wording; what the supplier must tell you about other customers it notifies about the same incident; and cost recovery. Write the default down, for example 'customer notifies, supplier supports', so nobody has to negotiate it on day one.

Practitioner checklist. List every supplier that holds or can reach your personal information, including SaaS integrations with API or OAuth access to the CRM or help desk. For each one, record whether you still hold the data (possession or control) and who notifies by default. Start your own NDB assessment clock when the supplier tells you of a suspected breach. Do not wait for the supplier to finish its investigation. Keep a written record of which entity did the assessment and when, because each holder must be able to show it met the scheme. Rotate integration credentials as soon as a supplier reports an incident. Cross-links: ndb-clock, serious-harm-test, ndb-statement, third-party-supply-chain, data-breach-response-plan, privacy-act-oaic.