The Australian Signals Directorate has released Essentials for operational technology, enterprise IT and cloud. It gives organisations a broader basis for planning and assessing cyber security work, including the shared services, suppliers and operating responsibilities that sit around individual systems.
We’ve reviewed the guidance against Quokka’s approach to design and delivery. There’s useful direction here. The work is in applying it to the equipment, people and constraints an organisation actually has, while making good use of the security investment already in place.
What ASD Essentials covers
Essentials describes security outcomes, the actions needed to achieve them and the groups of systems those actions apply to. ASD calls these principles, actions and domains. A domain can cross team and network boundaries, which matters when an application depends on shared identity, administration or recovery services.
| Chapter | Where it applies |
|---|---|
| OT | Systems that monitor or control physical processes, with their safety, availability and equipment constraints. |
| Enterprise IT | Business applications and infrastructure, including on-premises, hybrid and infrastructure-as-a-service environments. |
| Cloud | Software-as-a-service and platform-as-a-service, including the division of work between customer and provider. |
Several chapters may apply to one service. ASD recommends an implementation sequence, but allows the starting point to reflect risk, existing gaps and obligations. We don’t postpone an available maintenance window just to finish a group of actions in order. Record what moves forward, what waits and the exposure during that wait.
Keep the work that still holds up
A new framework shouldn’t mean buying the same capability twice. We start with the controls already installed, previous assessments and the records that show what was tested. Sometimes the useful change is a configuration correction or a recovery procedure the operating team can actually use.
Essential Eight controls and evidence remain useful, and existing obligations continue. Where an organisation uses NIST SP 800-53, retain the selected controls and their parameters; SP 800-53A provides the assessment procedures. Check the systems and conditions covered before reusing a test result. A mapping helps find evidence, but Essential Eight maturity, Essentials effectiveness and IEC 62443 security levels remain different assessments.
Follow the connections
A shared identity platform, supplier maintenance connection or hosted application can change who has authority over another system. Before joining environments, establish what the connection allows, who operates it and how the affected services recover if it fails. Permission to collect data and permission to issue commands need different decisions.
For industrial environments, Purdue helps describe the functions and their relationship to the business. IEC 62443 supports the risk assessment, zones, conduits and security requirements. A Purdue level isn’t automatically a security zone, and cloud isn’t another trusted level above the plant. Our Purdue and connected industry guide explains the architecture; the OT paper below takes it into implementation.
Work with the constraint
Compensating controls are a substantial part of the engineering. Equipment may have years of useful life left, an application may depend on an old component, or a provider may be unable to restore the records the business needs.
First, establish the restriction. “The vendor doesn’t support it” needs a product, version and specific limitation behind it. An unfunded change should be described as an unfunded change, so its cost can be compared with the cost of keeping the exception open.
Then design protection around the exposure. That could mean restricting the routes to older equipment, controlling maintenance access or keeping an independent copy of data. Test both the protection and the work people still need to complete. Include the ongoing effort: access reviews, alerts, recovery material and retesting after changes.
The decision needs a named owner, funding, remaining risk and a review date. ASD allows a different implementation where evidence demonstrates the intended outcome across the systems in scope. Accepting the risk is a separate decision; it doesn’t prove the control works.
The implementation papers
The three papers carry the detail: ASD’s priorities, existing frameworks, compensating controls, worked examples and acceptance tests. Use the paper that matches the systems you operate; a connected service may need more than one.
OT
Maintenance access, equipment restrictions, change windows and site recovery. The worked example follows a controller that can’t be patched until the next shutdown.
Enterprise IT
Shared platforms, administration, older applications and recovery. The worked example follows a change of support provider through separate accounts and scheduled jobs.
Explore the enterprise IT guide
Cloud
Provider commitments, customer configuration, integrations and exit. The worked example covers finance records that the provider cannot restore at the required level.