Australia Cybersecurity Requirements: Security Leadership Considerations

Where Australian rules reach leadership

Australian cyber obligations are not only technical. Several of them require a board to approve something, an executive to make a decision under time pressure, or a license holder to show that its risk management was adequate. A security leader who treats them as a control checklist will miss the part that regulators actually test.

Four regimes carry most of the weight: the ransomware payment reporting rules under the Cyber Security Act, the Security of Critical Infrastructure Act, the APRA prudential standards for financial services, and the Privacy Act with the general duties of license holders. Applicability depends on your entity and sector, so use this as a leadership briefing and confirm scope with counsel.

The four regimes

Clocks that leadership should know exist

Seven triggers with several different definitions of severity is a design problem. A single incident can start several clocks at once, each with its own idea of “serious”. The security team’s severity scale should map onto these triggers explicitly, so that classification at the first escalation tells the right executives which clocks are running.

Decisions that belong to leadership

The decision to pay. The Cyber Security Act requires reporting. It does not tell you whether to pay, and payment can raise sanctions and other legal questions that need review before any money moves. Decide in advance who can authorize a payment, who clears it legally, and who files the report. The 72-hour clock runs from the payment, and the report asks for the demand, the payment and your communications with the extorting party, so those records need to exist from the start of the negotiation.

The board’s annual attestation. For critical infrastructure, the annual report asks the board to stand behind a statement that the risk management program was up to date. Board approval of the program itself is not strictly required by the Act, but the annual report is, and it is hard to approve a report without evidence behind it. Ask what testing supports the statement, which hazards actually occurred and whether the program changed as a result.

Tolerance for disruption. CPS 230 asks boards to approve how much downtime and data loss each critical operation can bear. That is a business decision. Security supplies the scenarios and the recovery evidence. The board owns the number.

Escalation authority. A twelve-hour clock can expire overnight. Decide who can classify an incident as critical at three in the morning, and who may file without waiting for the full executive group.

One supplier register. The same providers often appear in the supply chain hazard under SOCI, in CPS 230 as material service providers and in CPS 234 as third parties. A single register with a single assurance process serves all three. Three separate ones guarantee inconsistency.

What adequacy looks like

The Federal Court’s decision in ASIC’s case against RI Advice is the clearest guide to how courts approach cyber adequacy. The licensee’s cyber risk management had fallen short of its general license obligations. The court accepted that cyber risk cannot be reduced to zero. The test was whether documentation, controls and risk management reduced it to an acceptable level, judged against a risk that keeps changing. It also looked at pace. The licensee’s cyber resilience program took years to complete, and that delay was part of the finding.

Our reading is that the lesson reaches beyond financial services. A board that has seen a risk, funded a response and then let it run slowly has a harder story to tell than one that moved quickly on an imperfect plan.

Where leadership programs go wrong

• Attestation without testing. The board signs, and the evidence behind the signature is a policy document.

• Reporting activity instead of exposure. Dashboards count alerts closed and patches applied. They do not show whether critical operations can recover within tolerance.

• Mismatched severity definitions. The security team’s “high” bears no relation to SOCI’s “critical”, so executives learn that a clock has started after most of it has run.

• Treating the payment report as paperwork. It is a legal filing with its own deadline, and it starts when the decision is made.

Questions for the next board or executive meeting

1. Who can authorize a ransomware payment, who must clear it, and who files the report within 72 hours?

2. What evidence supports the statement we make in our annual critical infrastructure report?

3. Does our severity scale map to the 12-hour and 72-hour triggers, and who can classify at any hour?

4. Which numbers has the board approved for tolerance of disruption, and when were they last tested?

5. Do we hold one supplier register that serves every regime we are subject to?

Sources

1. MinterEllison, Pay and tell: mandatory ransomware payment reporting obligations in force — minterellison.com

2. Mallesons (King & Wood Mallesons), The risk management program rules under the SOCI Act — mallesons.com

3. Ashurst, Mandatory cyber incident reporting now live for Australia’s critical infrastructure — ashurstperkinscoie.com

4. Corrs Chambers Westgarth, APRA’s new CPS 230: key requirements for regulated entities and their service providers — corrs.com.au

5. Corrs Chambers Westgarth, APRA’s prudential standard CPS 234 on information security — corrs.com.au

6. Piper Alderman, Federal Court highlights adequate cybersecurity measures as a legal obligation for financial services license holders — piperalderman.com.au

7. Office of the Australian Information Commissioner, Notifiable Data Breaches — oaic.gov.au