Patching cadence for AU regulated industries: a defensible policy under APRA CPS 234, ASIC, and TGA

Patching is the control regulators look at first. It's also the control that breaks most frequently under operational pressure. A vulnerability management policy is easy to write. A patching cadence that survives an audit, a breach post-mortem, or a regulator inquiry is harder to build, because it has to be operationally realistic, documented with evidence, and traceable to the frameworks the organisation is actually obliged to meet.

This guide covers three Australian regulatory contexts where patching obligations carry the most weight: APRA CPS 234 for APRA-regulated entities (banks, insurers, superannuation funds), ASIC's cyber resilience guidance for Australian financial services licensees, and TGA requirements for medical device and pharmaceutical manufacturers with computerised systems. The principles generalise, the timelines differ.

How each framework approaches patching

APRA CPS 234

CPS 234 requires APRA-regulated entities to maintain information security capability commensurate with the size and extent of threats. It does not prescribe a specific patch timeline, but APRA's 2023 and 2024 findings letters have been explicit: 'timely patching' and 'defined remediation timeframes for critical vulnerabilities' are recurring audit findings. APRA expects entities to have a documented vulnerability management policy with risk-based timeframes, evidence of compliance against those timeframes, and a reporting line to the Board on material breaches.

In practice, APRA entities that have passed scrutiny operate on the following as a minimum defensible position: critical and high vulnerabilities in internet-facing systems patched within 30 days of vendor disclosure; critical and high vulnerabilities in internal systems patched within 60 days; exceptions documented with risk acceptance sign-off and compensating controls in place.

ASIC cyber resilience guidance

ASIC does not operate a prescriptive patching standard equivalent to CPS 234. Its cyber resilience guidance for Australian financial services licensees (AFS licensees) references the NIST Cybersecurity Framework and the ACSC's Essential Eight as appropriate benchmarks. For patching, the relevant benchmark is Essential Eight Maturity Level 2: operating system patches applied within one month of release for internet-facing systems and two months for non-internet-facing systems; application patches applied within one month. At Maturity Level 3 the window tightens to two weeks for internet-facing systems.

ASIC's position on enforcement has sharpened following the RI Advice Group Federal Court case, where the firm was found to have failed to manage cybersecurity risk adequately. Patching evidence was part of the factual record. AFS licensees who cannot demonstrate a documented, evidenced patching programme are carrying material licence risk.

TGA requirements for computerised systems

The TGA's good manufacturing practice (GMP) requirements for computerised systems, Annex 11-equivalent expectations in Australia, require that computer systems used in regulated manufacturing and quality processes are validated, maintained, and that changes (including patches) are handled under a documented change control process. This creates a tension with rapid patching: every patch to a validated system theoretically requires change control assessment before deployment.

The practical resolution most TGA-audited manufacturers use is a risk-tiered change control process: emergency patches to systems with active critical vulnerabilities trigger an expedited change control (same-day or 24-hour approval with retrospective documentation), while routine patches follow a standard 30-day change control cycle. This requires a documented policy and pre-approved emergency change procedure, not informal approval after the fact.

A defensible patch policy framework

Regardless of the specific regulatory context, a defensible patching policy has five components. The exact timelines vary by framework, the structure doesn't.

1. 1Scope, defines exactly which systems and software are in scope for vulnerability management. 'All systems' is too broad to be operational. The scope should be expressed as a defined asset register, not a category description.
2. 2Vulnerability classification, defines how severity is classified (CVSS score, vendor advisory, threat intelligence context) and who makes the classification decision. Using CVSS alone is common but insufficient, a CVSS 7.5 vulnerability with no known active exploitation is different from a CVSS 7.5 vulnerability actively used in ransomware campaigns.
3. 3Remediation timeframes by severity and system tier, specific calendar-day targets for critical, high, medium and low severity findings, differentiated by internet-facing versus internal systems. These should be achievable given your patch window schedule, not aspirational.
4. 4Exception handling, defines what happens when a patch can't be deployed in the required timeframe: formal risk acceptance with named sign-off, required compensating controls (network isolation, application control, additional monitoring), review period, and escalation if the exception extends past the review date.
5. 5Evidence requirements, specifies what is collected to demonstrate compliance: patch deployment records, vulnerability scan results pre- and post-patch, exception log, and reporting frequency to management or the board.

Microsoft 365 and Windows patching in a managed service context

For the M365 estate specifically, patching operates across two layers: the Windows endpoint layer (managed through Intune Autopatch or Windows Update for Business) and the M365 application layer (managed through Microsoft's automatic update mechanisms for Microsoft 365 Apps for Enterprise).

Intune Autopatch, available from Business Premium onwards, automates Windows quality and feature update deployment across deployment rings. A defensible Autopatch configuration for a regulated industry client looks like this: a Test ring covering five to 10 devices patched on Patch Tuesday plus two days, a First ring covering 10% of the fleet patched on Patch Tuesday plus nine days, a Fast ring at 40% at Patch Tuesday plus 16 days, and Broad covering the remainder at Patch Tuesday plus 23 days. The ring structure means critical patches reach the full fleet within 23 days of Patch Tuesday, comfortably within a 30-day requirement.

A regional Queensland financial services client Frontrow manages moved from an ad hoc patching process to Intune Autopatch with the above ring structure. Pre-implementation, their mean time to patch across the fleet was 62 days. Post-implementation, it dropped to 18 days. The evidence trail Autopatch generates, deployment reports per ring, compliance dashboards per device, was sufficient for their next APRA-related internal audit with no additional manual reporting.

What a patch policy review should cover

If a regulated-industry IT team is reviewing their patching policy for the first time or preparing for an audit, the following questions frame the key gaps most commonly found:

• Is there a current, approved vulnerability management policy with named owner and last-reviewed date?
• Are remediation timeframes specified by severity tier and system type, and are they being met?
• Is the exception process documented with evidence of actual exceptions handled, not just theoretical process?
• Is Board or management reporting on patching compliance happening, and what does it look like?
• For TGA entities: is there a documented risk-tiered change control process that allows emergency patching without a full change control cycle?
• Is third-party (MSP) patching activity included in your policy scope, and is there a contractual obligation for the MSP to provide patch compliance evidence on request?