Use this workflow when one Australian cyber issue may touch the Security of Critical Infrastructure Act 2018, the Cyber Security Act 2024 ransomware-payment rules, or the smart-device security standards.
Identify the and critical-infrastructure asset first. Then decide whether incident reporting, risk-management evidence, Part 3 ransomware reporting, or smart-device compliance needs its own owner and record.
overlap triage starts by asking which legal stream the facts belong to. A for a may have SOCI register, risk-management-program, and cyber incident work. The same incident can also trigger Cyber Security Act reporting if a makes a payment or becomes aware that another entity made one on its behalf. A smart device raises a separate product-security question unless the device or service is also part of a critical-infrastructure asset.
1
Section 1
Separate SOCI, ransomware, and smart-device streams
Open the triage record with three yes-or-no lanes. Lane one is : is there a , a , and a Part 2, , or obligation? Lane two is Cyber Security Act Part 3: did a make, or become aware that another entity made on its behalf, a after a cyber security incident? Lane three is smart-device compliance: is the product a that the or knows, or could reasonably be expected to know, will be acquired in Australia by a ?
Do not merge the evidence packs. incident reporting, reporting, and smart-device statements of compliance answer different questions and may be handled by different owners even when the same event or product family triggered the review.
lane: record the asset name, asset class, , operational owner, and whether the question concerns the Register of Critical Infrastructure Assets, the critical infrastructure risk management program, or mandatory cyber incident reporting.
Ransomware lane: record the cyber security incident, impacted , demand, payment or benefit, payment maker, awareness time, and whether the $3 million turnover threshold or responsible-entity limb is the basis for scope.
Smart-device lane: record the product type, , , -acquisition basis, exemption check, statement of compliance, password design evidence, vulnerability-reporting contact, and .
Overlap result: assign each lane a separate owner, source citation, evidence location, reviewer, and status so a product-security record is not mistaken for a asset record or report.
Supports the SOCI triage lanes for critical infrastructure asset, responsible entity, Part 2 register, Part 2A risk-management-program, and Part 2B incident-reporting questions.
Supports the separate smart-device lane for consumer grade relevant connectable products and statements of compliance.
Security standards for consumer grade relevant connectable products
Recommended next step
Turn SOCI overlap triage into assigned evidence work
This workflow helps separate SOCI responsible-entity records, ransomware payment reports, smart-device statements of compliance, and review tasks in Sorena.
Responsible-entity and critical-infrastructure asset check
The branch should start with the asset, not a generic organisation name. Section 12L identifies the separately for each asset class; it is not a single across-the-board test that can safely be reduced to whoever owns or operates the asset. Record the applicable asset provision and the person or organisation that provision designates.
Once the asset and are identified, check which obligation is in play. Part 2 concerns the Register of Critical Infrastructure Assets. concerns the critical infrastructure risk management program. concerns mandatory cyber incident reporting. The Application Rules are the source to check whether Part 2 or Part 2B applies to the relevant asset class.
For , use the 10 June 2026 compilation of the program rules. now apply to specified broadcasting, domain-name-system, electricity, energy-market-operator, freight, gas, liquid-fuel, and water assets. Section 4A gives existing covered assets 12 months from commencement for section 6A and specified parts of sections 8A and 9A, and 24 months for the other enhanced provisions; an asset that becomes critical infrastructure later receives the corresponding period from that date.
Evidence to request: asset-class analysis, responsible-entity rationale, corporate ownership or operating-control evidence, service or system architecture, third-party data storage or processing dependency, and any prior register submission or update record.
Part 2 outcome: if the issue concerns register information or notifiable events, route it to the owner who maintains operational and ownership information for the Register of Critical Infrastructure Assets.
outcome: if the issue concerns ongoing resilience, route it to the critical infrastructure risk management program owner and link the hazard, material-risk assessment, selected controls, and annual-report evidence.
outcome: if the issue is a cyber incident affecting the asset, route it to the incident-reporting owner and keep the Part 2B report record separate from any report under the Cyber Security Act 2024.
Current 10 June 2026 compilation for Part 2A asset coverage, baseline program requirements, enhanced requirements, affected asset classes, and 12- and 24-month grace periods.
Supports the responsible-entity risk-management-program branch and the hazard categories used when SOCI Part 2A is in scope.
responsible entities to have, and follow, a critical infrastructure risk management program
3
Section 3
Part 2B and ransomware-payment triage
Treat a cyber incident report and a Cyber Security Act report as separate filings. Part 2B belongs to the SOCI critical-infrastructure stream. The Cyber Security Act Part 3 stream applies when the ransomware-payment conditions are met: a is impacted by a cyber security incident and provides, or becomes aware that another entity provided on its behalf, a payment or benefit to the extorting entity.
Start the clock from awareness of the qualifying impact on the covered asset: within 12 hours for a critical incident that materially disrupts essential goods or services, or within 72 hours for another incident with a relevant impact. Start the ransomware clock from the payment or awareness of an on-behalf payment. Build the ransomware record around what the knows or can find out by reasonable search or enquiry within that separate 72-hour period.
Scope gate: identify a for an asset to which applies. For the separate turnover route, confirm business in Australia, previous-financial-year turnover above the prescribed threshold, and that the entity is neither a Commonwealth or State body nor a responsible entity for any .
reporting gate: determine whether the incident has a significant impact on asset availability or another relevant impact. An oral critical-incident report needs an approved-form written record within 84 hours unless exempted; an oral report about another relevant-impact incident needs one within 48 hours unless exempted.
Trigger gate: confirm a cyber security incident, the direct or indirect impact on the , the demand by the extorting entity, and the payment or benefit directly related to that demand.
Report content: capture and address where required, incident timing and awareness, infrastructure and customer impact, ransomware or malware variant, exploited vulnerabilities, demand quantum and method, payment quantum and method, and communications with the extorting entity.
Cyber Security Act section 44 says information provided under Part 4 does not affect other Commonwealth information requirements, so do not close the question merely because a coordinator information-sharing record exists. Assess any Part 3 ransomware report separately.
Supports the Part 3 ransomware-payment trigger, the 72-hour reporting period, and the interaction rule preserving other incident-information obligations.
Sections 30BC and 30BD support the separate 12-hour and 72-hour SOCI reporting clocks and the 84-hour and 48-hour written follow-up periods after oral reports.
4
Section 4
Smart-device separation check
The smart-device branch is product compliance, not critical-infrastructure asset classification. Cyber Security Act Part 2 commenced on 29 November 2025, while Part 2 and Schedule 1 of the Smart Devices Rules, which contain the -grade standard and statement requirements, commenced on 4 March 2026. Use this branch for consumer grade relevant connectable products that can directly or indirectly connect to the internet when the or is aware, or could reasonably be expected to be aware, that a consumer will acquire the product in Australia, subject to the Rules' exclusions. The Rules set the binding scope test; the official explanatory statement gives smart TVs, smart watches, home assistants, baby monitors, and consumer energy resources as examples, but each product still needs its own connectivity, intended-use, acquisition, awareness, date, and exclusion analysis. A smart product used inside a critical-infrastructure environment may create operational risk evidence for , but the statement-of-compliance and security-standard evidence remain product records.
The Rules require a -prepared statement of compliance for covered products and set product-security evidence around passwords, reporting security issues, and defined support periods for security updates. Suppliers have their own supply-side check because the Rules outline when non-compliant products must not be supplied and when products must be supplied with the statement of compliance.
Product scope evidence: product type, intended use, -acquisition basis, direct or indirect internet connectivity, exemption analysis, identity, identity, and Australian supply channel.
Security-standard evidence: password design showing user-defined or unique-per-product passwords, published security-issue reporting contact and update process, and the for security updates.
Statement evidence: product type and batch identifier, and details, compliance declaration, , signatory, place and date of issue, and retention owner for the five-year statement period.
bridge: if the product is deployed in a critical-infrastructure asset, link the smart-device evidence into the SOCI material-risk or -risk record without treating the product statement as proof that SOCI or is satisfied.
Supports linking product or supplier risks into the SOCI risk-management program only when they affect a responsible entity's critical infrastructure asset.
Official explanatory material gives smart TVs, smart watches, home assistants, baby monitors, and consumer energy resources as examples of products the consumer-grade standard may cover; the binding Rules still control the product-specific scope decision.
5
Section 5
Evidence and owner matrix for the triage record
Keep the overlap triage record after the incident or product release. It should show why a lane was opened or closed, who owned it, which official source supported the decision, what evidence was reviewed, and which record remains authoritative for later audit or regulator questions.
Use a short matrix rather than a narrative memo. Each row should identify the lane, trigger fact, obligation checked, owner, evidence, source, decision, reviewer, and follow-up. Mark unknown facts as unknown and assign a collection owner instead of filling gaps with assumptions.
Legal or compliance owner: approves the asset, responsible-entity, Part 2, , , ransomware, and smart-device scope decisions against the cited sources.
Asset owner: confirms the critical-infrastructure asset, essential function, operational dependencies, third-party providers, and whether a hazard or incident has a relevant impact on the asset.
Security incident owner: maintains incident timing, impact, exploited vulnerabilities, malware or ransomware indicators, containment evidence, report status, and other regulator-notification cross-references.
Product owner: maintains smart-device scope, and evidence, statement of compliance, password controls, vulnerability-reporting publication, and support-period publication.
Finance or procurement owner: confirms facts, payment maker, payment method, demand details, role, and contracts that may affect evidence collection.
Primary SOCI source, including the compilation in force on 4 June 2026, for critical-infrastructure asset, responsible entity, Register of Critical Infrastructure Assets, Part 2A risk-management-program, Part 2B cyber incident, protected-information, and critical-telecommunications provisions.
Supports the SOCI triage lanes for critical infrastructure asset, responsible entity, Part 2 register, Part 2A risk-management-program, and Part 2B incident-reporting questions.
Supports the SOCI asset and responsible-entity triage fields and the distinction between Part 2, Part 2A, and Part 2B obligations.
Show 2 more
Sections 30BC and 30BD support the separate 12-hour and 72-hour SOCI reporting clocks and the 84-hour and 48-hour written follow-up periods after oral reports.
Supports keeping SOCI evidence tied to the relevant asset, responsible entity, register, risk-management-program, incident-reporting, and protected-information provisions.
Primary Cyber Security Act source used for smart-device security standards, ransomware payment reporting, significant incident coordination, and interaction with other incident-information requirements.
Supports keeping Cyber Security Act ransomware payment reports separate from SOCI Part 2B and other incident information requirements.
Supports the Part 3 ransomware-payment trigger, the 72-hour reporting period, and the interaction rule preserving other incident-information obligations.
Show 1 more
Supports treating smart-device security standards as a Cyber Security Act Part 2 product-compliance stream rather than a SOCI asset-class decision.
"Ransomware reporting obligations"
More quoted passages
"does not affect any other requirement"
"within 72 hours of making the ransomware payment"
Home Affairs source used for responsible-entity risk-management-program context and the cyber, supply-chain, physical, natural, and personnel hazard categories.
Supports the responsible-entity risk-management-program branch and the hazard categories used when SOCI Part 2A is in scope.
Supports linking product or supplier risks into the SOCI risk-management program only when they affect a responsible entity's critical infrastructure asset.
"cyber and information security hazards"
More quoted passages
"responsible entities to have, and follow, a critical infrastructure risk management program"
Application Rules source used to support checking which asset classes are captured by SOCI Part 2 register and Part 2B mandatory cyber incident reporting obligations.
Supports checking the Application Rules for asset classes captured by SOCI Part 2 register and Part 2B mandatory cyber incident reporting duties.
Supports checking whether SOCI Part 2B applies before relying on the responsible-entity limb of Cyber Security Act ransomware-reporting scope.
Current 10 June 2026 compilation for baseline and enhanced critical infrastructure risk management program requirements, covered asset classes, and transitional grace periods.
Current 10 June 2026 compilation for Part 2A asset coverage, baseline program requirements, enhanced requirements, affected asset classes, and 12- and 24-month grace periods.
Official explanatory material gives smart TVs, smart watches, home assistants, baby monitors, and consumer energy resources as examples of products the consumer-grade standard may cover; the binding Rules still control the product-specific scope decision.