SOCI overlap triage for the Cyber Security Act

Open the triage record with three yes-or-no lanes instead of one generic cyber checklist. Lane one is SOCI: is there a critical infrastructure asset, a responsible entity, and a Part 2, Part 2A, or Part 2B obligation? Lane two is Cyber Security Act Part 3: did a reporting business entity make, or become aware that another entity made on its behalf, a ransomware payment after a cyber security incident? Lane three is smart-device compliance: is the product a consumer grade relevant connectable product acquired in Australia by a consumer?

Do not merge the evidence packs. SOCI incident reporting, ransomware payment 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.

The SOCI branch should not start with a generic organisation name. Start with the asset and the person or organisation that owns or operates it. Home Affairs guidance describes a responsible entity as the individual or organisation that owns or operates a critical infrastructure asset, while the SOCI Act table of contents locates the detailed responsible-entity definition in section 12L and the critical-infrastructure asset definitions across the asset-class provisions.

Once the asset and responsible entity are identified, check which SOCI obligation is in play. Part 2 concerns the Register of Critical Infrastructure Assets. Part 2A concerns the critical infrastructure risk management program. Part 2B 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.

A SOCI Part 2B cyber incident report and a Cyber Security Act ransomware payment report are not substitutes. 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 reporting business entity 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.

The ransomware payment record must be built quickly around what the reporting business entity knows or can find out by reasonable search or enquiry within the 72-hour reporting period. Keep the payment facts, demand facts, communications, and incident facts in that record even if a SOCI incident record, privacy record, or APRA incident record also exists.

The smart-device branch is product compliance, not critical-infrastructure asset classification. Use it for consumer grade relevant connectable products that can directly or indirectly connect to the internet and will be acquired in Australia by a consumer, subject to the product exclusions in the Rules. A smart product used inside a critical-infrastructure environment may create operational risk evidence for SOCI, but the statement-of-compliance and security-standard evidence remain product records.

The Rules require a manufacturer-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.

A good SOCI overlap triage record should be useful after the incident or product release is over. 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.