Most Australian organisations we meet already have a one-page summary of the ASD Cyber Security Principles pinned somewhere. Govern. Identify. Protect. Detect. Respond. Recover. Beyond the principles, the actual work is tracing each of those six functions down into the specific controls in the Information Security Manual (ISM) your environment actually needs, and then wiring those controls into how your engineers build and run things day to day.
This post is for the person who has been handed the Principles and asked to do something with them. Not the person writing the policy — the person who has to make the policy true in a production environment.
The two ASD instruments most people conflate
Two ASD products get mentioned in the same breath and treated as interchangeable. They are not.
The Essential Eight is a prioritised set of eight mitigation strategies (application control, patching applications and operating systems, configuring Microsoft Office macros, user application hardening, restricting administrative privileges, multi-factor authentication, regular backups) with a three-tier maturity model. It tells you what to do first. It is narrow on purpose.
The Cyber Security Principles are broader. They sit inside the ISM and group all of ASD's strategic guidance into six functions: govern, identify, protect, detect, respond, recover. They are the scaffolding the rest of the ISM — the guidelines and the individual controls — hangs from. They tell you how to think about the whole. Every ISM control is classified under one of the principles.
If your board is asking "are we doing the Essential Eight", they are asking a different question to "are we aligned with the Cyber Security Principles". Both questions can be answered honestly and they often have different answers.
The current release matters
The ISM is a living document. ASD publishes updates roughly quarterly, with a change log. As at January 2026, the operative release is the December 2025 update, which introduced meaningful changes that a lot of existing policy text has not caught up with.
The December 2025 release removed the recommendation for time-based password changes, added new controls requiring that security questions are not used for authentication and that email is not used for out-of-band authentication, added two artificial intelligence controls — a general-purpose AI usage policy and the use of AI-specific documentation such as model and system cards — and added a control recommending use of a cryptographic bill of materials where one is available for imported third-party software components. The existing fax machine controls were rescinded, which tells you roughly where ASD thinks the current century begins.
If your internal policy library still references "passwords must be changed every 90 days" as an ISM-aligned control, your policy library is behind the manual.
What each principle looks like in engineering, not policy
Here is how we translate the six principles into work that ships.
Govern
Govern is the principle that sounds the most like a slide and maps least obviously to engineering. It is also the one that breaks first under pressure. Every control in the Govern family has an equivalent technical artefact: approval records, exception registers, system security plans, risk assessments that are actually signed.
Two concrete grounding points from the ISM. ISM-0576 requires that a cyber security incident management policy, and the associated incident response plan, is developed, implemented and maintained. ISM-1784 requires that the incident management policy (including the response plan) is exercised at least annually.
That second control is the one most often failed in the field. "Exercised" does not mean "read". It means a tabletop or a live drill where the plan gets pressure tested against a plausible scenario, the decisions get made under time pressure, the gaps get captured, and the plan is updated. If you cannot point to the artefact that came out of the last exercise, you do not have ISM-1784.
Identify
Identify is asset awareness and risk awareness. The engineering translation is unglamorous: a current, machine-readable inventory of systems, data, identities, and third-party connections. Not a spreadsheet that was true in 2023.
The honest test is whether your incident responders, at 3am, can answer "does this hostname touch regulated data" and "who is the asset owner" in under five minutes. If not, Identify is notional.
Practical anchors: CMDB reconciled against cloud provider APIs on a short cadence; data classification applied at ingest and carried through downstream systems; a third-party register that lists the data shared and the legal instrument that covers the sharing.
Protect
Protect is where the Essential Eight lives, and where most of the ISM's control volume sits. This is also where teams burn time if they treat each control as an isolated line item.
Worked example. Application control at Essential Eight Maturity Level Two requires allow-listing of executables, software libraries, scripts, installers, compiled HTML, HTML applications and control panel applets on workstations and internet-facing servers. The supporting ISM controls under Protect cover the implementation — what gets allow-listed, where the rulesets live, how changes are approved, how logs are centralised. If you stop at the Essential Eight statement and do not flow it into those controls, you will pass an initial assessment and fail an audit.
Protect is also where the December 2025 AI controls matter in practice. If you have a general-purpose AI assistant deployed across your workforce, you now have a published expectation that a usage policy exists and that model and system documentation is retained. That is a protect-family requirement with real engineering consequences — you need a retention location, an approval workflow, and a way to tie each deployment back to its documentation.
Detect
Detect collapses into log coverage, log fidelity, and the human or automated process that reads the logs. In ISM terms it is the event logging guidelines and the SOC capability controls.
The questions that actually predict detection maturity are blunt. Are your identity provider sign-in logs retained for long enough that a DFIR engagement in month four can read them? Are your EDR telemetry, cloud audit logs, and application logs joined on a common identity and timeline? Does anyone read the alerts on Sunday at 2am?
Coverage without analysis is a storage bill. Analysis without coverage is a guess.
Respond
Respond is two things sitting on top of each other: the ability to execute a response, and the ability to do so in a way that preserves legal and regulatory options. The ISM captures the first — incident response plan development (ISM-0576), enactment (ISM-1819), reporting obligations (ISM-0140 requires cyber security incidents be reported to ASD as soon as possible after they occur or are discovered). The second — preserving privilege, coordinating with breach counsel, making disclosure decisions under the Privacy Act 1988 (Cth) Notifiable Data Breaches scheme — sits alongside the ISM and is where engagements most often go sideways.
We wrote about the day-zero choices that determine how this goes in DFIR under privilege. The short version: the structural choices you make in the first few hours — who engages whom, under what instrument, via which channel — set the ceiling on what the Respond function can deliver.
Recover
Recover is the function that gets funded last and tested least. The ISM controls here cover backups, restoration testing, and business continuity — but the engineering question is whether a verified-good restore has actually happened, from the specific backup medium, into a clean environment, within the stated recovery time objective, in the last twelve months. Quarterly is better.
A backup you have not restored is a hypothesis. A hypothesis is not a control.
How to use the Principles without drowning
A few operating rules that keep this tractable.
Pick one function per quarter and run it end-to-end, from principle to ISM control to engineering artefact to evidence. Trying to uplift all six simultaneously produces a thin layer of effort everywhere and maturity nowhere.
When a control looks awkward in your environment, do not write an exception and move on. Write the exception, assign an owner, put an expiry on it, and surface it to whoever signs the risk register. Exceptions that never expire are how environments drift.
Track the ISM release you are aligned to, by date, in your policy header. When ASD publishes the next quarterly update, read the change log before you read anything else. Changes are almost always smaller than a full re-read but more consequential than a skim suggests.
Stop treating the Principles as a maturity score to report. Treat them as a map of the terrain you operate in. A score rewards the appearance of coverage; a map rewards knowing where you actually are.
Putting this into your own environment
If you are using the Cyber Security Principles as a foundation and the gap between policy and production is wider than you would like, we work with Australian organisations on exactly this shape of problem — tracing the Principles down into ISM controls, mapping controls onto your specific architecture and risk profile, and standing up the engineering work that makes the framework true. Start a conversation via the services page and we will scope from there.
The firms that respond fastest are the ones that planned ahead.
When an incident hits, the last thing you want is to be searching for a firm. Retainer clients get priority response, privileged structure, and a team that already knows your environment.
Discuss a retainer →- ✓ Priority SLA — response within hours, not days
- ✓ Alignment with your legal, executive, and CTO-office protocols from day one
- ✓ Pre-negotiated rates — no emergency premium
- ✓ Red team and blue team engagements to pressure-test your defences
- ✓ Quarterly posture reviews so we already know your environment when it counts