Begin a critical infrastructure security assessment with the essential service the facility supports, then identify how disruption or compromise at that facility could affect users and dependent services. Include dependencies beyond the fence where they change the service consequence.
For an Australian facility, establish the asset, responsible entity and applicable regulatory arrangements with the organisation's authorised specialists. The practical assessment below supports risk decisions. It is not a completed Critical Infrastructure Risk Management Program, a legal applicability opinion or proof of compliance.
The distinction matters. A useful local assessment can still omit obligations or dependencies belonging to the broader asset. Conversely, a corporate programme may describe controls without showing whether they work at a particular site.
Define the service and the assessment boundary
Describe what the facility contributes: a product, a flow, a processing function or support for another operation. Identify the service users, the period assessed and the operating conditions included.
Ask operations to explain what happens if the contribution is unavailable, unreliable or altered. Avoid jumping from “equipment failure” to a high consequence without tracing the intermediate effects.
Record what lies outside the site but remains essential to its function. This could include an external utility, specialist maintenance capability, an information service or another site. The assessment does not need to inspect every external organisation, but it must make consequential reliance visible.
The Australian CISC's February 2026 risk-assessment advisory for critical infrastructure emphasises asset criticality, interdependencies and an all-hazards view. Use that framing to connect local security findings with service consequences, while keeping the site's detailed configurations in controlled records.
Establish the regulatory boundary separately
Ask the organisation's legal or compliance owner to record the current applicable instruments, approved programmes, directions and reporting arrangements relevant to the asset. Confirm which entity owns each obligation and which assessment evidence it needs.
Use current official sources, including the Federal Register's CIRMP Rules record, rather than assuming an older guidance PDF contains every current requirement. The scope and timing of particular obligations must be checked for the actual asset and decision date.
Keep a traceable link between requirements and supporting evidence where needed. Do not convert a general risk rating into a compliance conclusion. A low assessed likelihood does not authorise the organisation to disregard an applicable requirement.
This separation also helps a consultant state the limits of the engagement. Identify which applicability questions the client must resolve and do not silently mark them complete.
Bring the right operational evidence together
Include the service owner, site operations, engineering or facilities, security, relevant technology teams, people responsible for suppliers and the compliance owner. Involve continuity and emergency-management specialists where the scenarios depend on their arrangements.
Request evidence tied to decisions: relevant incident history, current operating constraints, control responsibilities, maintenance findings, authorised test results and recovery assumptions. A large document collection is less useful than a clear explanation of what each record supports.
Distinguish observed facts from design intentions. A redundant component may exist while a shared dependency undermines the expected resilience. Ask what has been demonstrated under relevant conditions and what remains uncertain.
Do not conduct intrusive testing on operational infrastructure without the required authority and competent planning. Start with records, interviews and safe observations; escalate unresolved technical questions to the responsible specialists.
Build scenarios around service loss or compromise
Describe an initiating event, affected function, relevant control limitations and credible consequences. Include malicious activity and interacting non-malicious hazards where they change the security decision.
Avoid listing threat labels as completed scenarios. “Insider threat” does not explain the asset at risk, the permitted access involved or the consequence the organisation is trying to prevent.
Use enough detail to support a treatment decision without distributing exploitable site information. The general report can refer to a controlled technical annex for sensitive dependencies and test evidence.
A fictional example might state: “Loss of the site's maintenance coordination capability during a wider disruption could delay restoration of an essential service because alternative support arrangements have not been demonstrated.” This identifies a reliance to investigate without publishing real-site weaknesses.
Worked example: a service-dependency review
A fictional utility operator reviews a support facility. Its team uses the following questions to turn assumptions into assessment actions.
| Assessment question | Evidence found | Resulting decision |
|---|---|---|
| What service depends on this facility? | Operations identifies a restoration-support function | Assess service delay as well as local equipment loss |
| Is alternative support available? | A contract exists, but the relevant capability has not been exercised | Treat availability as uncertain and arrange proportionate verification |
| Could several sites need the same support? | The same supplier supports multiple locations | Review concurrent demand with the supplier relationship owner |
| Who authorises temporary operation? | Local instructions name a role without current delegation evidence | Resolve decision authority before relying on the workaround |
These are illustrative findings. They do not establish the regulatory status of a real utility or the adequacy of any particular restoration arrangement.
Assess consequence and uncertainty together
Consider effects on people, continuity, dependent services and the wider community, as relevant to the organisation's criteria. Keep the time dimension visible: a short interruption and a prolonged loss may have very different consequences.
Document the assumptions behind an alternative service or recovery estimate. If the result changes materially when an assumption changes, make that sensitivity visible to the decision-maker.
Prioritise evidence gaps that affect consequential decisions. You may need an interim operating constraint while a technical question is resolved. Record its owner and review condition rather than treating the assessment's completion as the end of the risk.
Turn findings into accountable changes
For each treatment, identify the function it protects, dependencies needed for it to work, implementation owner and evidence required before claiming benefit. Separate installation from demonstrated operation.
Agree review triggers such as changed operating capacity, a supplier change, new technical interfaces or an incident revealing a different failure mechanism. Feed material findings into the organisation's wider programme through its established governance route.
Set a clear assessment scope for the facility and retain accountable service-related changes in the treatment plan.
Your next action is to select one essential service and trace its reliance on the facility with operations. Resolve the most consequential unsupported dependency before expanding the assessment.
The paid SRMBOK Risk Assessment Template provides an editable report structure with worked examples for scope, assets, scenarios, controls and treatments. Replace those examples with verified site evidence and keep regulatory applicability and programme obligations explicitly assigned to the appropriate owners.