Australia's software and AI security rules: a 90-day plan for 2026

Australian organisations that build, buy or run software now answer to several overlapping regimes at once: the Security of Critical Infrastructure Act 2018 (SOCI), the Cyber Security Act 2024, ASD's Information Security Manual (ISM) and Essential Eight, APRA's CPS 234 and CPS 230, and a reformed Privacy Act. Each one turns, sooner or later, into the same few questions: what software do you run, who supplied it, how fast do you patch it, and how quickly can you tell a regulator what happened.

This guide covers each regime as it stands in late October 2026, maps the requirements to the evidence a supervisor asks for, and ends with a 30/60/90-day plan that works with the tools you already have. Safeguard appears only near the end. Nothing here is legal advice; where a rule is interpreted, check the primary text linked in Sources or ask your counsel.

Key takeaways

• SOCI is the backbone for critical infrastructure. The Act covers 11 sectors, and its three positive security obligations (register, incident reporting, written risk management program) apply depending on asset class. Systems of National Significance carry four enhanced cyber security obligations on top.
• The Cyber Security Act 2024 is now fully operational. It received Royal Assent on 29 November 2024. Ransomware payment reporting is live, and the smart device security standard commenced on 4 March 2026.
• The ISM is the most detailed software rulebook in the country. The September 2026 release (OSCAL version 2026.09.4, published 3 September 2026) includes controls ISM-1730 (produce and make available a software bill of materials), ISM-2054 (use supplier SBOMs during development), ISM-1876 (48-hour patching for critical online service vulnerabilities) and a growing set of AI controls.
• APRA-regulated entities have two clocks. CPS 234 paragraph 35 requires notice to APRA within 72 hours of becoming aware of a material information security incident; paragraph 36 allows 10 business days for a material control weakness. CPS 230 has applied since 1 July 2025, with pre-existing service provider contracts caught at the earlier of renewal or 1 July 2026.
• Privacy reform has already landed. The Privacy and Other Legislation Amendment Act 2024 is law, with a statutory tort, new civil penalty tiers, infringement notices and automated decision transparency in privacy policies.
• The OAIC is litigating. A $5.8 million civil penalty against Australian Clinical Labs and live proceedings against Optus and Medibank show breach handling is now tested in court.
• Safeguard capabilities used in this guide, all GA: SBOM generation and analysis, software composition analysis with deep transitive scanning, vulnerability management with EPSS and KEV, reachability analysis, policies and gates, the Compliance and GRC suite with Australian framework pages, TPRM SBOM requests, Portal and Trust Center sharing, AI-BOM discovery, autonomous remediation (ships switched off), the CLI and local runner, Zero AI mode, and private VPC, on-prem and air-gapped deployment.

The situation

The trigger is usually not a new law. It is a customer questionnaire that quotes ISM-1730, an APRA review that asks for the material service provider register, a SOCI annual report that needs a line on supply chain hazards, or a weekend vulnerability in a popular open source library and a board member asking on Monday whether you are exposed. A bad week looks like this: the 12-hour clock under the SOCI Act has started, nobody can say which products ship the affected component, and the supplier who might know is in a different time zone.

Who this applies to in Australia

Australia does not have one software security law. It has a set of sector regimes that each reach software through a different door. Start by finding which doors apply to you.

The last row matters more than it looks. A software company with no Australian licence of its own still meets SOCI risk management programs, CPS 230 material service provider registers and ISM supply chain controls, because its customers have to evidence them. The questionnaires and contract clauses arrive through procurement, not through a regulator letter.

The 11 SOCI sectors above come from the CISC's SOCI Act page (updated 30 June 2026). If your sector is not listed, the Act likely does not apply to you directly, though a customer's risk management program may still reach you.

The rules, regulator by regulator

Every status below was checked against the primary source on 25 and 26 October 2026. Where we could not confirm a status on a primary source, the regime is left out here and flagged in the editorial notes rather than guessed.

SOCI Act 2018 (Cyber and Infrastructure Security Centre)

Status: in force. The Security of Critical Infrastructure Act 2018 is administered by the Department of Home Affairs through the CISC.

The CISC describes three positive security obligations that can apply to critical infrastructure assets, depending on asset class:

1. Provide operational and ownership information to the Register of Critical Infrastructure Assets (Part 2 of the Act).
2. Report cyber incidents that affect the delivery of essential services to the Australian Cyber Security Centre (Part 2B, sections 30BC for critical incidents and 30BD for other incidents).
3. Adopt, maintain and comply with a written critical infrastructure risk management program (Part 2A).

A further obligation, to notify data storage or processing providers that they hold business critical data, applies to all critical infrastructure assets, according to the CISC's regulatory obligations page.

For assets the Minister declares Systems of National Significance, the CISC lists four enhanced cyber security obligations under Part 2C: develop cyber security incident response plans, undertake cyber security exercises, undertake vulnerability assessments, and provide access to system information.

What this means for software. The risk management program in Part 2A must address material risks from all hazards; the CISC's obligations factsheet names cyber, personnel, natural disasters and supply chains, and the program comes with an annual report. In practice that means a responsible entity has to know which software its asset depends on, who supplies it, and how a compromise of that supplier would reach the asset. Section 30BC is the short clock. The CISC's guidance says critical cyber security incidents (a significant impact on the availability of the asset) must be reported to ASD's ACSC within 12 hours of becoming aware of them, and other incidents with a relevant impact (on integrity, reliability or confidentiality) within 72 hours under section 30BD. If an incident first reported as other later becomes significant, a second report is due within 12 hours. Those clocks are only achievable when the inventory already exists.

2024 amendments. The November 2024 cyber security legislative package also amended SOCI. Read the current compilation on the Federal Register of Legislation before relying on a specific amended provision.

Cyber Security Act 2024 (Department of Home Affairs)

Status: in force. The Cyber Security Act 2024 (No. 98, 2024) received Royal Assent on 29 November 2024. Home Affairs describes it as Australia's first standalone cyber security Act and as implementing four initiatives under the 2023 to 2030 Australian Cyber Security Strategy. The Act's structure, from the Federal Register of Legislation:

• Part 2, security standards for smart devices. Sections 14 to 16 let the Minister set security standards for relevant connectable products and oblige manufacturers and suppliers to comply and to supply a statement of compliance. Sections 17 to 20 give compliance, stop and recall notices.
• Part 3, ransomware reporting obligations. Sections 25 to 32 require certain businesses that make a ransomware or cyber extortion payment to report it, and limit how the report can be used against them, including a legal professional privilege provision (section 31) and an admissibility limit (section 32).
• Part 4, coordination of significant cyber security incidents. Voluntary information sharing with the National Cyber Security Coordinator, with a limited use obligation on what the Coordinator can do with it.
• Part 5, the Cyber Incident Review Board. Independent, no-fault post-incident reviews of significant incidents, with the power to require documents (sections 49 and 50).

Smart devices. Home Affairs states that the Cyber Security (Security Standards for Smart Devices) Rules 2025 commenced on 4 March 2026, after a 12-month transition period, and apply to most smart devices acquired in Australia by a consumer. The obligations Home Affairs lists include no universal default passwords (passwords unique per product or set by the user), a published means to report security issues to the manufacturer with status updates, and published information on how long the device will receive security updates, including an end date. Desktops, laptops, smartphones and tablets are excluded. If you make firmware or companion apps for consumer devices sold in Australia, your vulnerability intake process is now a legal obligation, not a nice-to-have. Our related post on the smart device standard covers this part in depth.

Ransomware payments. Home Affairs' factsheet says payment reporting has been active since 30 May 2025. Section 27 of the Act requires a report within 72 hours of making a ransomware or cyber extortion payment (or becoming aware that one was made on your behalf). Section 6 of the Cyber Security (Ransomware Payment Reporting) Rules 2025 sets the annual turnover threshold at AUD 3 million, and responsible entities for critical infrastructure assets that report under Part 2B of the SOCI Act are covered whatever their turnover. Home Affairs explains the purpose plainly: government does not know the true scale of payments to criminals.

Information Security Manual (Australian Signals Directorate)

Status: current release September 2026. ASD publishes the ISM as a living document. Its official machine-readable OSCAL repository released version 2026.09.4 on 3 September 2026, "based on the September 2026 Information security manual." The ISM is written for Commonwealth entities and their systems, and state agencies, defence suppliers and critical infrastructure operators often reuse it in contracts and internal standards.

The software controls a supply chain program needs, quoted from the September 2026 catalog:

The September 2026 release also changed incident handling controls. ASD's release notes say the control recommending a separate system for planning intrusion remediation was amended to recommend using trusted systems instead.

AI controls in the ISM. The current catalog contains a set of AI controls that go further than anything in Australian statute. Examples: the board or executive committee is accountable for ensuring AI is secure, controllable and human supervised (a cyber security principle); ISM-2084 asks for AI model cards and system cards; ISM-2072 asks that AI models be stored in a non-executable file format that does not allow arbitrary code execution; ISM-2086 and ISM-2087 ask that the source and integrity of models, weights and training data be verified; ISM-2103 limits training on organisational data without informed and explicit consent; and ISM-2095 stops people on privately owned devices from granting unapproved AI agents access to OFFICIAL: Sensitive or PROTECTED systems.

Essential Eight (Australian Signals Directorate)

Status: current; maturity baselines published with the ISM. The Essential Eight is ASD's prioritised set of eight mitigation strategies, assessed against maturity levels. ASD's OSCAL repository publishes Essential Eight Maturity Level 1, 2 and 3 baselines as profiles of the ISM catalog. The Maturity Level 1 baseline includes the patching controls above (ISM-1876, ISM-1690) and daily vulnerability scanning of online services (ISM-1698).

Two points matter for software teams. First, the Essential Eight is about the systems you run, so for a SaaS vendor it covers your own corporate and production estate, not your customers'. Second, the patch timeframes are measured from the vendor's release of a fix, which makes exact component versions the limiting factor: if you cannot tell which services run a vulnerable library, the 48-hour window starts before you know you are in it. For the detail on maturity levels, see our related posts on Essential Eight supply chain controls and the 2026 Essential Eight update.

APRA CPS 234 Information Security (APRA)

Status: in force since 1 July 2019. CPS 234 applies to all APRA-regulated entities. The paragraphs that reach software:

• Paragraph 15: maintain an information security capability commensurate with the size and extent of threats to information assets.
• Paragraph 16: where information assets are managed by a related party or third party, assess that party's information security capability, commensurate with the potential consequences of an incident.
• Paragraph 35: notify APRA as soon as possible, and no later than 72 hours, after becoming aware of a material information security incident.
• Paragraph 36: notify APRA as soon as possible, and no later than 10 business days, after becoming aware of a material information security control weakness that the entity expects it will not be able to remediate in a timely manner.

APRA CPS 230 Operational Risk Management (APRA)

Status: in force since 1 July 2025, with a 2026 amendment. APRA's operational risk page confirms CPS 230 commenced on 1 July 2025. For pre-existing contracts with service providers, the requirements apply from the earlier of the next contract renewal or 1 July 2026, so that transition has now ended. Banks, superannuation trustees and insurers had to submit a completed material service provider register to APRA by 1 October 2025, using APRA's template. On 30 April 2026 APRA released targeted amendments to CPS 230, CPG 230 and the register template, introducing limited exemptions from specific contractual requirements for certain categories of service provider where contractual compliance is not practicable. APRA's disruption notification form also asks whether a disruption was triggered by a material service provider.

For a software supplier to a bank or insurer, CPS 230 is the reason your customer now asks about your own subcontractors, your offshoring arrangements and the country where services are performed.

Privacy Act 1988 and the 2024 reforms (OAIC)

Status: the first tranche is law. The Privacy and Other Legislation Amendment Act 2024 is on the Federal Register (C2024A00128, dated 10 December 2024). The OAIC's statement on its passage lists the measures:

• a statutory tort for serious invasions of privacy;
• expanded OAIC enforcement and investigation powers, including new tiers of civil penalties and infringement notices;
• a mandate to develop a Children's Online Privacy Code;
• a mechanism to prescribe countries and binding schemes with adequate protection, to ease cross-border transfers;
• a requirement that privacy policies describe substantially automated decisions that significantly affect individuals' rights or interests, including the kinds of decisions and personal information used.

The Act's Schedule 1 also includes a part on security, retention and destruction. The security duty sits in Australian Privacy Principle 11, and the Notifiable Data Breaches scheme in Part IIIC sets the assessment and notification process (section 26WH(2) requires an entity to take all reasonable steps to complete the assessment of a suspected eligible data breach within 30 calendar days, and the OAIC treats that as a maximum, not a target). APP 8 governs cross-border disclosure.

The automated decision provisions have a delayed start. Several law firm summaries put it at 10 December 2026; we could not confirm the commencement date on a primary page, so check the Act's commencement table before you plan around it.

AI rules

Status: no AI-specific statute. Australia has no enacted AI law that imposes obligations on private organisations in the way the EU AI Act does. For a software team the binding AI requirements today come from three places: the ISM AI controls above (for government and the suppliers who adopt the ISM), the Privacy Act (APP 11 security, and automated decision transparency once it commences), and sector regulators applying existing rules such as CPS 234 to AI systems as information assets. The government's policy direction on mandatory AI guardrails changed during 2025; we could not confirm its current status on a primary government page, so it is listed in the editorial notes rather than stated here.

What the rules ask of software and open source

Put the regimes side by side and the same handful of demands appear. This table maps each to the evidence a supervisor, auditor or customer usually asks for.

Inventory sits under almost every row, and every reporting clock is shorter than the time it takes to build an inventory from scratch. Do that work first.

Real public incidents in or affecting Australia

The examples below come from the regulator's own statements. We describe only what those sources say.

• OAIC v Australian Clinical Labs. In November 2023 the OAIC announced Federal Court civil penalty proceedings against Australian Clinical Labs, alleging serious interference with the privacy of millions of Australians between May 2021 and September 2022. In its 2026 commentary the OAIC describes the outcome as a $5.8 million civil penalty imposed on the company.
• OAIC proceedings against Optus and Medibank. The OAIC's own blog lists civil penalty proceedings filed against Optus and Medibank and says it will continue them in 2026. Both followed large data breaches. We do not know the outcome, and neither should you assume one.

We left out incidents we could not confirm on an official page. The narrow lesson: regulators now test whether a breach was assessed promptly and notified properly, and both depend on knowing which systems and data were involved.

The personas who own the problem

Each regime lands on a different desk, at a different moment. Knowing who carries which clock is half the plan.

CISO

What they need: a board-reportable view of software and supplier risk, and confidence that the 12-hour and 72-hour clocks are achievable. When: before the annual SOCI risk management program report goes to the board, after any APRA letter, and every time a major vulnerability makes the news and the board asks whether the organisation is exposed. The ISM puts cyber supply chain oversight with the CISO explicitly (ISM-0731).

Head of AppSec or product security

What they need: SBOMs that are complete and current, a patch backlog ranked by real risk, and a defensible metric for the 48-hour and two-week ISM timeframes. When: quarterly ISM releases, Essential Eight assessments, customer security questionnaires, and incident triage.

VP or Director of Engineering or Platform

What they need: one pipeline that produces the SBOM, runs the checks and blocks bad releases, with one exception process. When: a regulated customer adds SBOM delivery to a contract, or patch timeframes start blocking roadmaps.

GRC, compliance and regulatory affairs

What they need: evidence mapped to clause numbers (CPS 234 para 15, 16, 35 and 36; SOCI Part 2A; ISM-1730; APP 11), a register of weaknesses with dates, and a way to answer the same question from APRA, the CISC and the OAIC without three separate projects. When: APRA prudential reviews, internal audit cycles, SOCI annual reports, and privacy audits.

Procurement and vendor risk

What they need: a material service provider register that is accurate, supplier SBOMs on request, and contract clauses that flow down disclosure and notification duties. When: contract renewals (CPS 230 caught every pre-existing contract by 1 July 2026 at the latest), onboarding, and after a supplier incident.

Privacy officer

What they need: a map of which systems and components process personal information, which cross the border, and which make automated decisions. When: privacy policy updates for the automated decision provisions, NDB assessments, and OAIC inquiries.

Step by step: a 30/60/90-day plan

This plan works with or without Safeguard. Use your current tools, spreadsheets if you must, and replace them later if the volume demands it.

Days 1 to 30: know what you have and which clocks apply

1. Write down which regimes apply. Use the "Who this applies to" table. Record the asset classes under SOCI, whether you are APRA-regulated, whether you supply Commonwealth entities, and whether you are above the ransomware reporting threshold. One page, signed off by legal.
2. Build an SBOM for every production application and image. Use any SPDX or CycloneDX generator in CI. Generate per release, not once. Store them where incident responders can query them.
3. Inventory suppliers that touch production. Start from your accounts payable list and your cloud bills. Tier them by criticality. Mark the ones that would be CPS 230 material service providers or SOCI supply chain hazards.
4. Write the clock card. One page with each reporting clock, who decides whether it has started, who files, and where: SOCI 30BC and 30BD, CPS 234 para 35 and 36, the NDB assessment, the ransomware payment report. Put it in the incident runbook.
5. Start daily scanning of internet-facing services. ISM-1698 and the Essential Eight Maturity Level 1 baseline expect it. Record the date each finding was first seen.

Days 31 to 60: connect inventory to risk

6. Match SBOMs to vulnerability data every day. Use a feed that includes exploited vulnerability status and exploit probability, so you can tell "critical or working exploit" (48 hours under ISM-1876) from "non-critical, no working exploit" (two weeks under ISM-1690).
7. Set gates in CI. Start in warn mode for a fortnight to see the volume, then block on the highest-risk conditions. Use a formal exception with an owner and an expiry date for everything else.
8. Request SBOMs from your top-tier suppliers. Ask for SPDX or CycloneDX, the generation method, update frequency, and a named security contact. Track responses.
9. Run a tabletop on the 12-hour clock. Pick a plausible scenario, for example a critical vulnerability in a widely used open source library. Time how long it takes to answer "which assets run it." If the answer is more than a few hours, fix the inventory before anything else.
10. Inventory AI assets. List models, AI SDK imports, inference endpoints and agents. Record model formats and sources (ISM-2072, ISM-2086). Note which make decisions about individuals (Privacy Act automated decision transparency).

Days 61 to 90: evidence and governance

11. Map evidence to clauses. For each row in the requirements table, link the artefact that proves it. Keep the link live, not a screenshot.
12. Publish a vulnerability disclosure policy. ISM-1755 and, for device makers, the smart device rules. Give a channel and a response expectation you can meet.
13. Share SBOMs with customers who ask. ISM-1730 says SBOMs are made available to consumers of your software. Decide the channel (portal, NDA gated share, contract annex).
14. Review data location. Record where source code, SBOMs, findings and logs are stored and processed for each tool you use. This answers APP 8 and CPS 230 offshoring questions in one place.
15. Report to the board. Coverage of SBOMs, median days to patch critical and exploited findings, supplier SBOM response rate, open exceptions, and tabletop results.

A same-day template for the clock card:

Fill in the names, then test it.

How Safeguard does this

Everything below is GA and comes from Safeguard's offering documentation and docs.safeguard.sh. Safeguard holds no Australian certification or assessment; it helps a team produce and keep the evidence these regimes ask for.

1. Switch on the Australian framework pages. Safeguard's Compliance and GRC suite (GA) includes framework pages for the Australia ACSC ISM, the Essential Eight, the SOCI Act and the Privacy Act. The docs say each is on in your workspace unless you switch it off in Compliance › Manage. Each page lists the scan requirements Safeguard checks, the extra controls from its control catalog, and policy templates written for that regime, such as an ACSC ISM System Security Plan template and a SOCI critical infrastructure risk management programme template.
2. Generate SBOMs on every scan. SBOM generation and analysis (GA) produces SPDX and CycloneDX. Software composition analysis with deep transitive dependency scanning (GA) covers the open source underneath. From the CLI, the docs show safeguard scan --dir . for a local directory, safeguard scan --image for a container image, safeguard scan --repo for a Git repository and safeguard scan --sbom sbom.json for an SBOM you already have. Results are written as JSON under ./output.
3. Let each scan check the Australian requirements. The docs describe requirements decided by a scan against the product's SBOM. Examples from the docs: AU-ISM-SBOM (an SBOM in a standard machine-readable format), AU-ISM-PATCH (exact versions known so patch timeframes can be met), AU-E8-PATCHSPEC (no vague or floating version specifiers), AU-E8-ASSETID (PURL or CPE identifiers so scans match advisories), AU-SOCI-30BC and AU-SOCI-30BD (version-level knowledge to support the 12-hour and 72-hour clocks), and AU-APP-8 (supplier of each component known for cross-border accountability). Requirements a scan cannot see, such as a policy or an access review, pass only with evidence or an attestation.
4. Rank vulnerabilities for the 48-hour and two-week windows. Vulnerability management (GA) enriches findings with EPSS and CISA KEV status, and reachability analysis (GA) shows which vulnerable code paths your application actually calls. That gives the "critical or working exploit" split ISM-1876 and ISM-1690 depend on.
5. Enforce with policies and gates. Policies, gates and guardrails (GA) let you write rules such as no critical CVEs, a CVSS ceiling, or no abandoned packages, from Settings → Policies → Create Policy. Each policy's action is Block, Warn or Notify. Approval for a legitimate exception runs through the exception workflow (justification, expiry date, approver, audit trail). In CI, the docs show:

safeguard ci scan --wait --fail-on-gate <gate>

6. Collect supplier SBOMs. TPRM (GA) lets you open a vendor, click Request SBOM, choose products and a template, set a deadline and send, or send in bulk. Received SBOMs are checked for format and completeness and scanned for vulnerabilities automatically. Reminders go out seven days before the deadline, at the deadline and seven days after. That is your evidence for ISM-2054, CPS 234 paragraph 16 and CPS 230 service provider reviews.
7. Share SBOMs with your own customers. The Portal publish and share product (GA) and the Trust Center (GA) let you publish posture and share SBOMs with customers, including NDA-gated sharing, which addresses ISM-1730's "made available to consumers."
8. Inventory AI assets. AI-BOM discovery (GA) builds an inventory of AI assets across code (AI SDK imports, model weight files such as .pt, .safetensors and .gguf, prompts, notebooks, MCP server configuration), cloud inference endpoints and connected SaaS. The inventory records format and source, which is the starting point for ISM-2072, ISM-2084 and ISM-2086 evidence.
9. Fix, with a human in charge. Autonomous remediation (GA) can open tested, policy-gated pull requests that move a dependency to a fixed version, one repository at a time or in bulk. It ships switched off, with every category set to Manual.
10. Keep code and data where your rules need them. Safeguard's SaaS runs in US, EU and Gov regions only. For Australian residency or offshoring concerns, the GA answers are private VPC or dedicated tenancy, full on-prem, fully air-gapped deployment with the AI models running inside your environment, the local runner (the CLI scans on your own machine; source code never leaves your environment and only encrypted results are sent), and Zero AI mode, in which the platform runs with no LLM in the loop.

What Safeguard does not do

• It does not file your reports. Safeguard can shorten the time to answer "are we affected," but deciding that a SOCI, CPS 234, NDB or ransomware clock has started, and filing with the CISC, ASD, APRA or the OAIC, stays with your nominated people.
• It does not make you compliant. A framework page with every scan requirement met is evidence, not a finding. Your board, your auditor and your regulator decide whether your program meets the standard.
• It does not hold Australian certifications. Safeguard's own posture is "SOC 2 Type II audit in progress" and "designed for FedRAMP High." Your assessors judge your systems, not the tool.
• It does not host in Australia. SaaS regions are US, EU and Gov. If data must stay in Australia, use private VPC, on-prem, air-gapped deployment or the local runner.
• It does not patch systems it does not build. Vendor appliances, hosted services and operating system packages you do not build yourself still need the vendor's fix.
• It does not cover all eight Essential Eight strategies. Office macros, MFA and backups are mostly outside a software supply chain tool. The Essential Eight framework page lists catalog controls you evidence yourself.
• It does not write your privacy policy or your model cards. It inventories AI assets; the documentation ISM-2084 and the Privacy Act ask for is yours.

Common mistakes

• Treating the SBOM as a one-off deliverable. ISM-2054 and the incident clocks need SBOMs per release, queryable in minutes.
• Starting the 48-hour clock at triage. ISM-1876 measures from the fix release, not from when your team noticed.
• Forgetting the supply chain hazard in a SOCI risk management program. A program that lists physical and personnel hazards but no software suppliers is weak on its own terms.
• Assuming CPS 230 only matters to the bank. Every material service provider will be asked for subcontractor and offshoring detail.
• Waiting for an AI law. The ISM already has AI controls, and the Privacy Act already applies to AI systems that handle personal information.
• Using floating version ranges in production manifests. They make patch timeframes impossible to evidence.

FAQ

Does the SOCI Act require an SBOM?

Not in those words. The SOCI Act requires a written risk management program that addresses supply chain and cyber hazards, and incident reports within 12 or 72 hours. An SBOM is the most direct way to show you know which software components an asset depends on and to answer whether an incident affects it.

Is the ISM mandatory for private companies?

The ISM is written for Commonwealth entities, but suppliers to government, defence industry and many critical infrastructure operators adopt it through contracts. If a customer writes ISM controls into your contract, they are mandatory for you.

What are the Essential Eight patch timeframes in 2026?

In the September 2026 ISM catalog, ISM-1876 sets 48 hours for patches to online services when the vulnerability is critical or a working exploit exists, and ISM-1690 sets two weeks otherwise. ASD's Maturity Level 1 baseline includes both.

When must an APRA-regulated entity notify APRA of a cyber incident?

Under CPS 234 paragraph 35, as soon as possible and no later than 72 hours after becoming aware of a material information security incident. Paragraph 36 adds 10 business days for a material control weakness that cannot be remediated in time.

Has CPS 230 fully commenced?

Yes. It applied from 1 July 2025, and for pre-existing service provider contracts from the earlier of renewal or 1 July 2026. APRA released targeted amendments on 30 April 2026.

Does Australia have an AI law?

There is no AI-specific statute that binds private organisations today. AI is governed through existing law, mainly the Privacy Act, and for government systems through the ISM's AI controls. Check current government policy before you plan around guardrails.

Who has to report ransomware payments in Australia?

Businesses carrying on business in Australia with annual turnover of AUD 3 million or more (section 6 of the 2025 Rules), and responsible entities for critical infrastructure assets that report under Part 2B of the SOCI Act. Under section 27 of the Act the report is due within 72 hours of the payment, and the duty has applied since 30 May 2025.

Can our source code stay in Australia if we use Safeguard?

Safeguard has no Australian SaaS region. You can keep code in your own environment by running the local runner, or deploy Safeguard in a private VPC, on-prem or fully air-gapped, with Zero AI mode if no model may touch the code.

Every Australian regime above eventually asks how fast a known vulnerability stops running in production, whether that is ISM-1876's 48 hours or the evidence behind a SOCI risk management program. The block below explains how Safeguard closes the gap between a published fix and your builds, and what to do when no fix exists yet.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The local runner demo shows the residency answer in practice: you set up the runner on your own machine, approve it with its device code, then scan from the terminal. For an Australian team that cannot send source code offshore, this is how SBOMs and findings get produced without the code leaving your environment.

Click through it at your own pace, or open it full screen.

The CLI demo is a real session: it installs the CLI, opens the interactive terminal and asks it to fix a lodash CVE in a repository. It reads the finding and advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, prints a summary and pushes nothing. That is the shape of meeting a 48-hour patch window without handing control to a tool.

Click through it at your own pace, or open it full screen.

The Claude demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. GRC and AppSec teams can use the same pattern to ask an assistant which products contain a component during the first hours of an incident, with access limited to the tools you allow.

Click through it at your own pace, or open it full screen.

Quick check

Related reading

• Australia critical infrastructure security
• SOCI Act software supply chain and SBOM practice
• Essential Eight software supply chain controls
• Essential Eight 2026 update and the supply chain
• Australia's smart device security standard

Sources

• Cyber and Infrastructure Security Centre: SOCI Act 2018
• Cyber and Infrastructure Security Centre: regulatory obligations
• Federal Register of Legislation: Security of Critical Infrastructure Act 2018
• Federal Register of Legislation: Cyber Security Act 2024
• Federal Register of Legislation: Intelligence Services and Other Legislation Amendment (Cyber Security) Act 2024
• Federal Register of Legislation: Privacy and Other Legislation Amendment Act 2024
• Department of Home Affairs: Cyber Security Act
• Department of Home Affairs: security standards for smart devices
• Australian Signals Directorate: ISM OSCAL releases
• Australian Signals Directorate: ISM OSCAL catalog, September 2026
• Australian Signals Directorate: Essential Eight Maturity Level 1 baseline profile
• APRA: operational risk management (CPS 230)
• APRA: Prudential Standard CPS 234 Information Security
• OAIC: passing of the Privacy and Other Legislation Amendment Bill
• OAIC: handling privacy complaints, a new approach for a new era
• OAIC: proceedings against Australian Clinical Labs
• OAIC: Notifiable Data Breaches publications
• Safeguard docs: Australia ACSC ISM
• Safeguard docs: Australia Essential Eight
• Safeguard docs: Australia SOCI Act
• Safeguard docs: Australia Privacy Act
• Safeguard docs: compliance frameworks
• Safeguard docs: CLI usage
• Safeguard docs: policies and gates
• Safeguard docs: TPRM SBOM requests
• Safeguard docs: AI-BOM discovery
• Safeguard docs: air-gapped deployment
• CISC: SOCI Act obligations factsheet
• CISC: notification of cyber security incidents guidance
• Department of Home Affairs: ransomware payment reporting factsheet
• OAIC: Part 4, Notifiable Data Breach scheme

To try the CLI and local runner yourself, download Safeguard at safeguard.sh/download and read the documentation at docs.safeguard.sh/docs.

Last reviewed: 25 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.