The Patch Directive Went Out the Same Day. Not Every School Applied It.

The Department of Education’s directive to patch went to every Victorian government school technician six and a half hours after the Australian Signals Directorate issued a critical alert. That part worked. What the Department could not do was tell whether the schools had acted on it, and at least one had not. An attacker got into that school’s IT system and took the names, schools, year levels, school email addresses and encrypted passwords of every government school student in the state, plus hundreds of thousands of former students.

That is the finding of the Office of the Victorian Information Commissioner’s investigation report, published this week. It is worth reading for anyone who runs IT across more than one site, because the failure it describes is not a missing control. It is a control that stopped at “sent”.

Short answer

OVIC found the Department breached Information Privacy Principles 4.1 (security) and 4.2 (destroying or de-identifying information no longer needed). The Department had a patching policy and issued the right instruction on the right day. It had no process to verify or monitor whether schools carried it out. OVIC made seven recommendations, all due by 31 December 2026, including a “feedback loop” so the Department knows schools have acted on future security advisories. The lesson for any multi-site organisation is that an instruction is the start of a control, not the control.

What happened, and when

The timeline comes from the OVIC report.

Two details stand out. The school whose system was compromised did not know its network and servers had been breached until it was told. And the advisory had to be sent a second time, five weeks later, after the attack had been found.

Why the directive was not enough

Victorian government schools run on a devolved model. The Department sets policy and schools implement it, supported by more than 750 specialist technicians through the Technical Support to Schools Program. The Department’s policy expects technicians to carry out “risk-prioritised patching”.

On 27 October the Department told the program to notify schools, and it did, the same day. OVIC’s report records that “not all schools followed the advice”, and that “timely and effective patching did not occur at the school level”. OVIC described the Department’s governance of the support program as “inadequate”, because there was no process to check whether schools had acted on a directive. It also found the Department’s vulnerability management program did not cover every school and did not see every critical vulnerability remediated, and said exposure of unpatched internet-facing servers after a critical alert “should have warranted greater attention by the Department”.

None of that is unusual. Most organisations with branches, franchisees, clinics, depots or schools work this way: the centre writes the policy, the sites do the work, and the centre assumes that what it sent was done.

The control is the check, not the email

Read this as an auditor and the gap is precise. ISO 27001 control A.8.8, management of technical vulnerabilities, asks you to obtain information about vulnerabilities, evaluate your exposure and take appropriate measures. Getting an advisory and passing it on covers the first part. It does not show the exposure was evaluated or that anything was done about it.

The evidence an auditor would ask for is the return leg:

• Confirmation per site. Which sites have applied the patch, by when, and who confirmed it.
• Independent verification. A scan or report from a central tool, not just a reply saying “done”.
• Follow-up for the gaps. What happens to a site that has not confirmed by the deadline, and who chases it.
• Escalation. At what point an unpatched internet-facing system stops being a site’s problem and becomes the organisation’s.

That return leg is what OVIC’s second recommendation describes as a feedback loop. In ISO 27001 terms it is also A.5.36, compliance with policies, rules and standards for information security, which asks you to regularly review whether your own policy is being followed. A policy that expects risk-prioritised patching, with nobody checking whether it happens, is a policy the organisation has written for itself and then not tested.

Your own policy is auditable too

This is the part internal audit tends to miss. Clause 9.2 asks two questions: does the management system meet the standard, and does it meet the organisation’s own requirements? The second one is a trap for anyone who has written more into their system than they do in practice.

If your patching procedure says critical vulnerabilities are applied within 48 hours at every site, that is now an auditable requirement, whether or not ISO 27001 asked for 48 hours. An internal audit should sample it: pick an advisory from the last quarter, pick three sites, and trace it from receipt to confirmed remediation. If the trail stops at the email, that is a nonconformity against your own procedure, and it is far better found by your internal auditor than by a regulator.

The Department has told OVIC it will run an internal audit in 2027 to review how well its vulnerability management for schools works. That is the right instrument. The difficulty is timing: OVIC noted the Department’s plan to move schools to centrally provided technology by the end of 2028 leaves a long lead time, with risk to manage in the meantime.

Old credentials are a data risk too

The second finding is less about patching and more about what was there to steal. The Department kept credentials for past students so that a new student would not be given an email address that had already been used, and with it access to a former student’s records. OVIC accepted the business need but found keeping the credentials themselves was “not a proportionate response” to it, and that the practice breached IPP 4.2.

The equivalent ISO 27001 control is A.8.10, information deletion. Ask what personal information you are holding for people who left years ago, and whether you need the information itself or only a record that the identifier was used. Under the Commonwealth Privacy Act the same thinking sits in APP 11.2, and we covered the reasonable-steps side of it in securing personal information under APP 11.3. The Department has said it plans an archive policy for inactive student records by December 2026, but will need extra funding to deliver it.

Where this sits next to the other recent cases

This is the reverse of the problem in one breach, 21 GP practices, where a single compromised head office exposed every site. Here the centre did its part and one site did not. Both come back to the same question of scope: if your ISMS covers many locations, the controls have to reach every one of them, and you need evidence that they do.

It is also a cousin of the Mathspace case, where a patch was published on 6 August, the breach happened on the 10th and the patch was applied on the 29th. In a single organisation the gap is between the advisory and the patch. Across many sites there is a second gap, between the instruction and the confirmation, and it is easier to miss because the centre believes it has already acted.

What to do this month

If you run IT across more than one site, five things are worth doing now:

1. Pick last quarter’s most serious advisory and trace it to every site. Record who confirmed, when, and how you know.
2. Add a confirmation step to your vulnerability procedure, with a deadline and a named owner who chases the gaps.
3. Get central visibility of internet-facing systems at every site, so verification does not depend on a reply.
4. Put the trace in your internal audit programme under clause 9.2 and A.5.36, sampled against your own stated timeframes.
5. Review what you keep about former customers, students, members or staff, and whether you need the record itself or only a note that it existed.

Frequently asked questions

What did OVIC find about the Department of Education breach?

OVIC found the Department breached IPP 4.1 because its security controls were not adequate, and IPP 4.2 because it kept past students’ credentials when that was not proportionate to the business need. It made seven recommendations, all due by 31 December 2026, which the Department accepted.

Was the Department told about the vulnerability in time?

Yes. ASD issued a critical alert at 10am on 27 October 2025, the Department was alerted a minute later, and it directed all school technicians to act at 4.32pm the same day. OVIC’s concern was what happened after the directive, not before it.

What is a feedback loop in vulnerability management?

It is the return path that confirms each site, team or system owner has acted on a security advisory, with evidence and a follow-up for anyone who has not. Without it, the centre knows what it asked for but not what was done.

Does ISO 27001 require patches within a set time?

No. A.8.8 asks for timely, appropriate action based on your evaluation of the exposure. The timeframe is yours to set, but once your procedure states one, internal audit should test it.

Does this apply to private businesses?

The report applies Victorian public sector privacy law, but the failure is common to any organisation with sites, branches or franchisees managing their own IT. Private businesses covered by the Commonwealth Privacy Act face the equivalent test under APP 11.

Closing the loop

The Department did the hard part on the first day and still lost the data, because nobody could see whether the instruction had landed. That is a governance gap, and it is exactly what an independent audit is designed to find before an attacker does.

Streamline builds ISO 27001 information security management systems for Australian organisations, and you deal directly with a practising ISO Lead Auditor. An independent internal audit will trace your last critical advisory to every site, a gap analysis will show where your vulnerability process stops short, and ISO mentoring suits organisations that want their own people to build it. If your patching ends at “sent”, get in touch.

Sources

• Office of the Victorian Information Commissioner, Investigation into the data breach of student information at the Department of Education, report dated 5 October 2026, page updated 7 October 2026 (PDF)
• ISO/IEC 27001:2022, clause 9.2 and Annex A controls A.5.36, A.8.8 and A.8.10

Facts in this article are current as at 8 October 2026 and are drawn from the OVIC report. This article is general information from an auditing and management system perspective and is not legal advice.