Article
Handle a supplier data breach without losing the operational picture
Coordinate a supplier breach response across security, service continuity, privacy and communications, with a practical responsibility worksheet.
Contrata editorial team ·
A supplier reports unauthorised access to a system containing customer information. Security wants to contain the incident. Operations needs to know whether the service can continue. Privacy needs facts about the information involved. Customer teams need an approved answer for incoming questions.
Those activities overlap, but they are not the same decision. A coordinated response keeps them moving together without assuming that the supplier's investigation answers every question for your organisation.
This article provides a practical coordination worksheet for Australian organisations, including APRA-regulated entities. It is not an incident-response plan, legal advice or a complete notification guide. Activate your established response arrangements and involve qualified security, privacy and legal advisers promptly.
Establish one incident record with clear sources
Start by preserving the supplier's notice and recording when your organisation received it. Identify the service, internal owner and incident coordinator. Use approved channels and access controls for sensitive material.
Separate the record into confirmed facts, supplier statements, internal assessments and unanswered questions. “The supplier says no customer data was accessed” is different from “we have established that no customer data was accessed”. Preserve that distinction in briefings and decisions.
The first information request should be focused enough for the supplier to answer under pressure. Ask what is known about the affected service, timing, information, containment and current operational status. Ask when the next update will arrive and who can provide urgent clarification. Do not wait for a polished final report before escalating facts that may require action.
Run connected response tracks
The OAIC's breach-response guide describes containment, assessment, notification where required and review. The worksheet below is an original way to coordinate those activities with service operations.
| Track | Suggested internal lead | Questions to resolve | Shared output |
|---|---|---|---|
| Security and containment | Security incident lead | What is compromised, what action is safe, and what evidence must be preserved? | Current containment position and restrictions |
| Operational impact | Service or operation owner | Which services are affected, what work is accumulating, and are alternatives usable? | Service-impact assessment and recovery needs |
| Privacy assessment | Privacy lead with legal support | What personal information and people are involved, and what harm could result? | Documented assessment and required actions |
| Notifications | Authorised compliance or legal lead | Which obligations apply, what triggers them and who submits each notice? | Decision log and notification record |
| Communications | Approved communications owner | What can be said accurately, to whom and through which channel? | Approved messages and correction process |
| Supplier coordination | Relationship owner | What evidence and actions are outstanding from the provider? | Consolidated requests and update schedule |
One person may perform several roles in a lean team. The responsibilities still need to be explicit, including who covers them if that person is unavailable.
Fictional example: availability and privacy diverge
A fictional insurer uses a provider to manage customer correspondence. The provider reports suspicious access and temporarily disables an integration. The insurer's customer-service platform remains available, but staff cannot retrieve some correspondence through the normal route.
The operational team assesses the effect on enquiries and work queues. Security assesses whether reconnecting the integration would create further exposure. Privacy investigates the records potentially accessed. None of these assessments can be replaced by the statement that the platform is “online”.
The provider later says the integration can restart. That does not establish whether information was accessed earlier. Equally, an ongoing privacy investigation does not by itself determine which operational recovery steps are safe. The incident coordinator brings the relevant decision-makers together and records the basis for each action.
Do not use a single notification clock
For entities covered by the NDB scheme, the OAIC's eligibility guidance explains that notification concerns eligible breaches: relevant unauthorised access, disclosure or loss, likely serious harm and the effect of remedial action. Not every data incident meets that test.
The OAIC's current quick reference guide says a suspected eligible breach must be assessed quickly, with all reasonable steps taken to complete assessment within 30 calendar days. That is not permission to defer action or wait 30 days once notification is required.
APRA-regulated entities also need to assess their prudential obligations. CPS 234 requires notification as soon as possible and no later than 72 hours after becoming aware of an incident meeting the triggers in paragraph 35. CPS 230 has separate operational incident and disruption provisions. Obtain advice on their application and interaction; do not treat one regulator's process as satisfying every obligation.
Maintain a notification decision record with the applicable provision, trigger assessment, awareness time, responsible person and next review point. If facts change, reopen the assessment. The supplier's view of its own obligations does not determine yours.
Preserve evidence without spreading the breach
Coordinate evidence handling with the incident specialists. Ask for relevant logs, timelines, affected-system descriptions and investigation findings through secure channels. Avoid circulating raw customer information in broad email threads or copying it into general task trackers.
Where a supplier provides a list of potentially affected records, establish who may access it, how it will be reconciled and how corrections will be handled. A record count without a clear definition can create confusion: it may refer to files, people, accounts or transactions.
Do not ask operational staff to alter or delete relevant records merely to simplify the investigation. Containment and evidence preservation need coordinated technical decisions. Record what was done, by whom and when through your established incident process.
Keep communications tied to the evidence
Prepare updates that explain what is known, what remains under investigation and what the recipient should do, where appropriate. Have the authorised owners review the content and notification requirements.
Avoid absolute claims such as “all information is safe” when the evidence supports only a narrower statement. If the supplier revises an earlier account, identify which internal and external messages need correction. Keep the previous version and the reason for the change in the incident record.
For internal operational updates, include service impact and restrictions, not just investigation status. Staff need to know which process to use and where to escalate exceptions.
Close the incident and its remaining actions separately
Service restoration, completion of the investigation and remediation closure may happen at different times. Record them separately so an operational recovery does not silently close privacy or control issues.
The incident-intake guide provides a complementary escalation structure; use remediation closure criteria for improvements that remain open after restoration.
The post-incident review should identify what changed in the supplier assessment, dependency map, contract procedures or response plan. Give unresolved actions owners and evidence-based closure criteria. The next review should be able to trace the original notice to the decisions made, the information supporting them and the work still outstanding.