Incidents and Breach Notification Under RFFR: Three Clocks, Not One

Most providers know the Privacy Act gives them 30 days to assess a suspected data breach. Rather fewer have read the clause in their own Deed that gives them one business day.

That gap — between the number people remember and the number they signed — is the single most consequential misunderstanding in this topic. By the time an organisation reaches for the 30-day figure, it may already be a day late to the Department.

There are three obligations here. They have different triggers, different recipients and different clocks, and none of them discharges another. This guide separates them.

Clock 1: your Deed — and it is not 30 days

Start with the Deed, because it moves fastest and it is the one providers miss.

The employment services Deeds are published, and the clause is unambiguous. Under the Workforce Australia Services Deed (clause 43.6) and the Parent Pathways Deed (clause 35.6): if you become aware that there are reasonable grounds to suspect there may have been an eligible data breach in relation to Personal Information you hold under the Deed, you must notify the Department in writing no later than the Business Day after you become so aware — and, unless the Department directs otherwise, carry out the Privacy Act assessment.

The Inclusive Employment Australia Deed (clause 45.6) sets a different clock: as soon as possible and within two calendar days. It also adds an obligation the others don't — if the Department requires it, you must allow the Department to participate in your assessment of whether the event is an eligible data breach.

Three things about that are worth sitting with.

The trigger is suspicion, not confirmation. "Reasonable grounds to suspect" is a low bar, and it is deliberately lower than the standard for believing a breach occurred. You notify while you are still working out what happened — not once you know.

Two calendar days is not two business days. Under the IEA Deed, a Friday-evening discovery is due on Sunday. The Workforce Australia and Parent Pathways wording — "the Business Day after" — behaves differently over a weekend. If you hold more than one Deed, you hold more than one clock, and they do not agree.

It's in the privacy clause, not the security clause. This is why capable providers still miss it. Clause 40 of the Workforce Australia Deed is "Access and information security assurance" — that's the RFFR clause. The breach notification duty is over in clause 43, under Privacy. A team that has diligently worked through the security obligations can quite reasonably never have read it.

There is more in the same clause. Under Workforce Australia 43.5, you must immediately notify the Department if you become aware of a breach or possible breach of the privacy obligations by any of your Personnel or a Subcontractor, or that a disclosure of Personal Information may be required by law, or that the Australian Information Commissioner — or an individual claiming their privacy has been interfered with — has approached you.

Check your own Deed and its clause numbers. The three published Deeds differ from one another in both timing and detail, and yours is the one that governs you.

The PPIR: a wider net than the Deed clause

The Deed sets the clock. The Guidelines set the mechanism — and cast the net wider.

The Workforce Australia Guidelines (Part A, the Universal Guidelines) require that you notify the Department as soon as possible after becoming aware of any unauthorised access to, use or disclosure of, personal information, or any loss of personal information you hold — using the Provider Privacy Incident Report (PPIR).

And then the sentence that matters most: this applies to all privacy incidents, whether or not they are an eligible data breach.

That is a materially lower threshold than the Deed's notifiable-data-breach clause. You are not filtering for "serious harm" before you report. An email to the wrong participant is a privacy incident. It goes in a PPIR. Whether it later turns out to be an eligible data breach is a separate question you assess afterwards — and the Guidelines require you to assess all potential privacy incidents promptly to work that out.

Two more duties attach:

• The Department gets copies. If you notify the OAIC of an eligible data breach, you must give the Department a copy of that notification and of any subsequent correspondence with the OAIC. Your regulator conversation is not private from your client.
• Records incidents count too, even without personal information. Providers must report all incidents involving unauthorised access to, or damaged, destroyed, lost or stolen Records. Where those Records contain — or possibly contain — participant personal information, you follow the PPIR process on top.

There's a rectification obligation as well, and it contains a trap: you must not destroy damaged Records without prior authorisation from the Department. The instinct after a spill or a flood is to clean up. Don't — not without asking first. You are also required to make every effort to recover lost or damaged Records (paying for expert contractors if that's what it takes), and to inform participants where personal information has been lost or is at risk of becoming public.

Related, and easy to miss: privacy complaints carry their own clock. Providers must respond within 10 Business Days, and follow the PPIR process where the complaint reveals a privacy incident.

Clock 1b: what RFFR asks of the capability itself

Separately from the notification clock, RFFR expects the capability to exist. Managing cyber security incidents is one of the five strands of the cyber security core expectation — alongside the Essential Eight, risk management, monitoring and restricted access controls.

The Department expects a formal approach to cyber security incident management that addresses ISM guidance, with controls designed to detect and respond to incidents, report them internally and to external stakeholders (the Department included) as appropriate, and keep proper records.

And there's a detection requirement attached that providers routinely read past: as a key element of incident detection, implement controls to log security-related events in your IT systems, and audit those logs on a regular basis.

That clause turns a passive capability into an active one. Having logs is not the requirement. Auditing them is. A provider with six months of logs nobody has ever opened does not have detection — it has storage. And you cannot notify within a business day of suspecting something if nothing in your organisation is capable of noticing it.

Clock 2: the Privacy Act

Here is the trap that makes the Deed clock so easy to miss. Search DEWR's RFFR pages for "notifiable data breach", or "Privacy Act", or "OAIC". They aren't there. Their guidance on using ISO 27001 to meet RFFR requirements doesn't mention them either.

So a provider working conscientiously through the RFFR material can reach accreditation without ever meeting the breach obligations — because they don't live in the RFFR material. They live in the Deed, and in the Act.

The Notifiable Data Breaches (NDB) scheme is a legal obligation under the Privacy Act. It applies to you regardless of what your Deed says, it is enforced by a different regulator, and it runs on its own clock. Note that your Deed explicitly hooks into it: the same clause that gives you a business day to tell the Department also requires you to carry out the assessment in accordance with the requirements of the Privacy Act. The two are wired together, at different speeds.

An eligible data breach requires all three of:

1. unauthorised access to, unauthorised disclosure of, or loss of personal information you hold; and
2. it is likely to result in serious harm to one or more individuals; and
3. you have not been able to prevent that likely risk of serious harm through remedial action.

That third limb matters and is often forgotten. If you act fast enough that serious harm is no longer likely — a laptop is remotely wiped, credentials are revoked before use — you may not have an eligible breach at all. Fast, competent response doesn't just limit damage; it can change your legal position.

The clock: once you have grounds to suspect an eligible data breach, you must carry out a reasonable and expeditious assessment within 30 calendar days. Read that as a ceiling, not a target — the Commissioner expects assessments to be completed in a much shorter timeframe where possible, and 30 days spent deciding is itself a fact someone will later examine. If it is an eligible breach, you notify the Commissioner and the individuals at risk of serious harm as soon as practicable.

Notice that both clocks start on the same trigger — reasonable grounds to suspect. One gives you 30 days to finish assessing. The other gives you until tomorrow to pick up the phone. The 30-day figure is the one everyone remembers, and on its own it is dangerously misleading.

Serious harm is not defined in the Act. It covers serious physical, psychological, emotional, financial or reputational harm, judged against the kind and sensitivity of the information, the protections around it, the circumstances of the breach, and the nature of the harm that could follow.

Which is exactly why this is not a hypothetical for employment services. You hold sensitive personal information about job seekers and participants — circumstances, health, financial position. The bar for "serious harm" is not far away when that is the data in question.

Clock 3: change notification — which is not an incident obligation

The third clock gets dragged into incident conversations because it's the only RFFR deadline most providers can recite: notify the Department within 5 business days.

That duty is not about incidents. It is triggered by a change in your circumstances that alters your risk profile — a new Deed, changed subcontracting arrangements, different third-party IT vendors supporting your environment, moving from Category 2 to Category 1.

Different trigger, different purpose. Do not let a well-known deadline crowd out the ones that actually apply when something goes wrong. And note the two can intersect: if an incident causes you to change providers or re-architect an environment, that change may itself be notifiable — as a change, not as an incident.

The three, side by side

The bottom row is the whole point. These do not substitute for one another. Telling the Department is not notifying the Commissioner. Neither is telling ASD via ReportCyber, which is worth doing and satisfies neither.

And read the first two columns together. Same trigger, wildly different speeds — which means the moment you have grounds to suspect, you are simultaneously on a one-day contractual clock and a 30-day statutory one. Plan for the short one.

What your plan actually has to do

Formality here is not the goal. A plan's real job is answering three questions while people are stressed and information is thin: who is in charge, who do we call, and what do we say?

If a one-page document answers those, it beats a forty-page plan nobody has opened. What that page needs:

• A named decision-maker, and a deputy. Incidents do not wait for someone's annual leave to end.
• The call list, with numbers that work. Internal escalation, your Department contact, your privacy officer or legal support, your insurer, your key vendors. Stored somewhere reachable when the network isn't.
• The notification triggers, written down in advance — with the actual deadline next to each. "Reasonable grounds to suspect → Department, in writing, by the next Business Day" is a sentence that belongs on the page, in your Deed's own words. Decide this on a calm Tuesday, not at 2am with a lawyer on hold.
• A record from minute one. What you knew, when you knew it, what you decided and why. Every clock in this article starts from when you became aware — so the moment of awareness is a fact you will have to evidence, possibly to a regulator. "We were busy responding" is not an answer.

Test it, and let the test fail

An incident plan that has never been exercised is a hypothesis.

A one-hour tabletop — a plausible scenario, the actual people in a room, walked through end to end — will find things a document review never does. The call list has a departed employee on it. Nobody can say who declares an incident. Two people each assume the other tells the Department. Everyone is working to the 30-day number they half-remember, and nobody notices the Deed's clock expired yesterday.

Those are cheap discoveries in a meeting room and expensive ones in an actual breach. And an exercise that surfaces findings is evidence of a working capability, not an embarrassment — the same logic that makes a clean internal audit suspicious rather than reassuring. Auditors like seeing a tabletop with findings and the fixes that followed. It tells them the capability is real.

The bottom line

You do not have 30 days. Under the Workforce Australia and Parent Pathways Deeds you have until the next Business Day; under Inclusive Employment Australia, two calendar days. The trigger is suspecting a breach, not proving one. The Privacy Act's 30 days is the outer limit on finishing your assessment — a different question entirely, and the one everybody answers instead.

Then RFFR asks that the capability behind all this actually exists: detect, respond, keep records, and genuinely read your logs. And the five-business-day rule people can recite is about change, not incidents.

Three obligations. Three clocks. None discharges another.

So go and read the privacy clause of your own Deed — not the security clause, the privacy one — and put its deadline on the page your team will actually reach for. Then exercise it once before you need it. The organisations that handle this well are not the ones with the thickest plans. They are the ones who already knew what time it was.