Search every question across sub-FAQs

For smart devices, keep the statement of compliance and the product evidence behind it for the rule-backed retention period. The Security Standards for Smart Devices Rules say the statement must identify the product type and batch, manufacturer and Australian authorised representatives, compliance declarations, defined support period, signatory details, and place and date of issue; the same rules set a five-year retention period for those statements.

For ransomware payment reporting, keep a report file that can show whether the entity was a reporting business entity, when the payment was made or discovered, what information was known or findable by reasonable search within the 72-hour reporting period, and what was submitted to the designated Commonwealth body. The Act and ransomware reporting rules do not set a separate retention period for that report file, so retain it with the source evidence used to prepare the report for internal compliance and follow-up checks.

The ransomware record should be built around the report fields, not around a generic incident summary. The Act requires the report to cover contact and business details for the reporting entity or another payer, the cyber security incident and its impact, the extortion demand, the ransomware payment, and communications with the extorting entity.

The 2025 ransomware reporting rules make those categories more concrete. They add ABN and address details where available, incident occurrence and awareness timing, impact on infrastructure and customers, ransomware or malware variant, exploited vulnerabilities, information useful to government response, payment quantum and method, and the nature, timing, and description of communications or negotiations.

Do not merge every Australian cyber record into the Cyber Security Act file. SOCI overlap is supported where the ransomware rules refer to responsible entities for critical infrastructure assets to which Part 2B of the SOCI Act applies. APRA overlap is supported only for APRA-regulated entities, because CPS 234 separately requires notification to APRA for material information security incidents and material control weaknesses.

A clean record separates the Cyber Security Act submission evidence from adjacent SOCI or APRA evidence: which entity was in scope, which asset or prudential entity was affected, which regulator or body was notified, what facts were reused, and which facts were held back because the regimes have different purposes.

The trigger is not every ransomware incident. Part 3 applies where a cyber security incident has had, is having, or could reasonably be expected to have a direct or indirect impact on a reporting business entity; an extorting entity makes a demand to benefit from the incident or its impact; and the reporting business entity provides, or knows another entity has provided on its behalf, a payment or benefit directly related to that demand.

A reporting business entity is either a responsible entity for a critical infrastructure asset to which Part 2B of the Security of Critical Infrastructure Act 2018 applies, or an entity carrying on business in Australia whose annual turnover for the previous financial year exceeds the turnover threshold and that is not a Commonwealth body, State body, or responsible entity for a critical infrastructure asset under the other limb.

The 2025 Rules prescribe the ordinary turnover threshold as $3 million for the previous financial year. If the business operated for only part of the previous financial year, the Rules use a pro-rated formula based on $3 million multiplied by the number of operating days divided by the number of days in that previous financial year.

The reporting business entity must give the designated Commonwealth body a ransomware payment report within 72 hours of making the ransomware payment or becoming aware that the ransomware payment has been made, whichever applies.

The Act requires the report to include information the reporting business entity knows or can find out by reasonable search or enquiry at the time of reporting. The report must cover contact and business details for the reporting business entity if it made the payment, or the other entity if another entity paid; the cyber security incident and its impact; the extortion demand; the ransomware payment; and communications with the extorting entity about the incident, demand, and payment.

The Rules add detail: ABN if any and address for the reporting entity or other payer; when the incident occurred or is estimated to have occurred; when the reporting business entity became aware of it; impacts on infrastructure and customers; ransomware or malware variants; exploited vulnerabilities; response-useful information; the amount or quantum and method demanded; the amount or quantum and method provided, including non-monetary benefits; and the nature, timing, description, and any pre-payment negotiations in communications with the extorting entity.

The risky pattern is answering the FAQ with only an incident-response policy or a payment approval note. The grounded answer needs the reporting-business-entity scope analysis, the threshold calculation, the 72-hour clock, and a report-content inventory tied to the Act and Rules.

Do not rely on a generic ransomware playbook to decide whether the Part 3 report is triggered. Preserve the facts that distinguish a non-reportable incident from a reportable ransomware payment: entity status, Australian business activity, turnover, critical-infrastructure responsibility, the demand, the payment or benefit, and awareness that another entity paid on the reporting entity's behalf.

For covered smart devices, the manufacturer must provide a statement of compliance for supply in Australia, and the supplier must supply the product in Australia with that statement. Both manufacturer and supplier must retain a copy for the period set by the rules.

Start by confirming scope. The current Smart Devices Rules prescribe a security standard for consumer-grade relevant connectable products intended or likely to be used for personal, domestic, or household use or consumption, where the products will be acquired in Australia by a consumer. The rules exclude desktop and laptop computers, tablet computers, smartphones, therapeutic goods, road vehicles, and road vehicle components.

The manufacturer owns preparation of the statement, or preparation on its behalf. The supplier should not treat the statement as optional packaging copy: the Act requires the product to be supplied in Australia with a statement of compliance when the statutory conditions are met.

For statements of compliance with the security standard in Part 1 of Schedule 1 to the Smart Devices Rules, the statement must be prepared by, or on behalf of, the product manufacturer. It must identify the product and responsible parties, record manufacturer declarations, name the defined support period, and include execution details.

A useful implementation record should mirror the required legal contents instead of replacing them with a generic security attestation.

Keep the statement for five years for the consumer-grade relevant connectable product security standard covered by the Smart Devices Rules. The retention file should allow a reviewer to connect the signed statement to the product batch, the manufacturer role, the supplier handoff, and the underlying security-standard controls.

Evidence should be practical and product-specific: retain the issued statement, the product classification decision, supporting test or engineering records, the published vulnerability-reporting and support-period materials, supplier distribution proof, and any notices or regulator correspondence about examination requests.

The main risk is treating the statement as a broad cyber compliance memo rather than a product-specific statutory statement tied to the smart-device security standard. Another risk is relying on the manufacturer's statement but failing to retain supplier-side proof that the statement accompanied products supplied in Australia.

A compliance notice can be issued by the Secretary when an entity that must comply with section 15 or 16 is not complying, or when information suggests possible non-compliance. A response record should start with the product, the relevant connectable product class, the security-standard requirement, the manufacturer or supplier role, and the specific section 15 or 16 obligation at issue.

A stop notice is the next escalation. It depends on a prior compliance notice and the Secretary being reasonably satisfied that the compliance notice was not met or that attempted remediation was inadequate.

A recall notice is a further escalation after a stop notice. It can be issued where the stop notice was not met or remediation remains inadequate for the same section 15 or 16 non-compliance.

A recall notice must identify the entity, give brief details of the non-compliance, and specify the action the entity must take. The action can require the entity to stop the product being acquired in Australia, stop the product being supplied to suppliers for supply in Australia, or arrange return of the product to the entity or to the manufacturer.

The notice must also specify a reasonable period for the action. If the Secretary considers it appropriate, the notice can also specify a reasonable period for the entity to provide evidence that the action was taken. The notice must explain what may happen if the entity does not comply and how the entity may seek review.

If an entity fails to comply with a recall notice, the Minister may publish information on the Department's website or another way the Minister considers appropriate. The Act lists the identity of the entity, product details, non-compliance details, and risks posed by the product relating to the non-compliance.

The 2025 Smart Devices Rules add that the public notification may include details of the recall notice and actions consumers are recommended to consider, such as destroying the product or taking extra precautions when using it.

The Cyber Security Act does not supersede the Security of Critical Infrastructure Act 2018 (SOCI Act). It imports SOCI concepts for a critical infrastructure asset and a responsible entity, and its ransomware payment reporting regime expressly covers a responsible entity for a critical infrastructure asset to which SOCI Act Part 2B applies.

That means a ransomware payment incident can need a Cyber Security Act ransomware payment report while the same incident is also assessed against SOCI Act cyber security incident notification duties. The overlap question starts with asset status and entity role, not with whether the affected system is a consumer smart device.

Do not merge the smart-device product regime into the SOCI overlap analysis. Cyber Security Act Part 2 applies to relevant connectable products and product supply obligations. SOCI overlap for this FAQ is about critical infrastructure assets, responsible entities, SOCI Part 2B incident notification, and Cyber Security Act ransomware payment reporting.

A manufacturer or supplier may have smart-device duties for a relevant connectable product even when it is not the responsible entity for a SOCI asset. Conversely, a SOCI responsible entity can have ransomware reporting exposure even when the incident is not about placing a smart device on the Australian market.

Keep a short overlap record that proves the asset, entity, incident, and payment analysis. The useful record is factual: which asset was affected, why SOCI Part 2B was or was not relevant, who the responsible entity was, whether a ransomware payment was made, and which report-content fields could be completed within the reporting window.

If the same event also touches a connected product, keep that product compliance file separate so SOCI incident triage is not confused with smart-device security-standard evidence.

Manufacturers must make an in-scope relevant connectable product in line with the applicable security standard when the product is in the covered class and the manufacturer is aware, or could reasonably be expected to be aware, that it will be acquired in Australia in the specified circumstances. The Smart Device Rules target consumer-grade relevant connectable products, with listed exclusions for desktops and laptops, tablets, smartphones, therapeutic goods, road vehicles, and road vehicle components.

Suppliers must not supply a non-compliant covered product in Australia when they are aware, or could reasonably be expected to be aware, that it will be acquired in Australia in the specified circumstances. Suppliers must also supply the product with a statement of compliance and retain a copy for the period set by the Rules.

Importers are not given a separate importer-specific duty label in the cited Act and Rules. Treat an importer as in scope when its facts also make it a manufacturer or a supplier, such as importing a covered consumer-grade smart device for supply in Australia. Keep the role analysis explicit instead of assuming that every overseas purchase, distributor, or logistics movement is automatically covered.

Keep records that show why the product and actor were placed inside or outside the smart-device obligations. The useful evidence set is a product-scope file, a role file, a security-standard file, and a statement-of-compliance file, not a generic compliance memo.

The statement of compliance should be prepared by, or on behalf of, the manufacturer and include the product type and batch identifier, manufacturer and authorised representative details, compliance declarations, defined support period, signatory details, and place and date of issue. Both manufacturers and suppliers should be able to retrieve the statement for the Rules' five-year retention period.

Escalate cases where the supply-chain label does not match the legal role. An offshore OEM, Australian distributor, online marketplace seller, local importer, and reseller may each need a separate manufacturer-or-supplier assessment based on who manufactures, who supplies in Australia, and who knows or should know the product will be acquired in Australia by a consumer.

Also escalate products near the Rules' scope boundary: bundled products, accessories with their own connection capability, consumer energy resources, business devices that may still be consumer acquisitions, and excluded product categories. Do not use ransomware reporting or Security of Critical Infrastructure Act workflows as substitutes for the smart-device product duties; those are separate regimes unless the same facts independently trigger them.

Start with the product. Under the Act, a relevant connectable product is an internet-connectable product or a network-connectable product that is not exempted under the rules. Internet-connectable means capable of connecting to the internet using a communication protocol in the internet protocol suite to send and receive data. Network-connectable covers products that can send and receive data by electrical or electromagnetic transmission, are not internet-connectable, and meet the Act's direct-connection tests.

Then apply the Smart Devices Rules. The current security standard covers relevant connectable products intended by the manufacturer to be used, or of a kind likely to be used, for personal, domestic, or household use or consumption. The specified circumstance is that the product will be acquired in Australia by a consumer.