The ASD Update Your Board Thinks Is Someone Else’s Problem
The Australian Signals Directorate has updated its Information Security Manual with tightened controls around developer security competence. Most boards will hear about this, if they hear about it at all, through a brief IT update that frames it as a technical matter being handled. That framing is wrong, and it is costing you.
The iTnews coverage of the ASD ISM update describes new and revised controls that draw an explicit line between developer skill levels and security outcomes. Read it as a technical document if you like. But what ASD has actually done is create a paper trail that points directly at the governance decisions sitting above the development team — the decisions made in boardrooms and executive committees, not sprint planning sessions.
What ASD Is Saying
Guidance that ties security failures to workforce competence is not a training syllabus. It is a statement of what reasonable practice looks like, which matters a great deal after an incident — under the Privacy Act, under SOCI, or in front of an APRA prudential review. “We didn’t know our developers lacked the skills” is not a defence in that setting. It is closer to an admission.
The ISM has always carried weight beyond its formal standing as a mandatory framework for government agencies. Courts, regulators and insurers treat it as a benchmark for what a reasonable organisation should have done. The OAIC has referenced it. APRA’s CPS 234 is read alongside it. When ASD draws a hard line, the line appears in places that affect you directly, well beyond any Commonwealth IT contract.
Your Last Three Delivery Decisions
The competence problem ASD is now formalising did not arrive from outside. It was assembled, decision by decision, inside your organisation, and that is the conversation most boards are not having.
Start with headcount. The technology reductions driven by cost programmes in 2022 and 2023 did more than trim capacity; they removed the senior developers and security-minded engineers who held the institutional memory of what the codebase did and why it did it that way. Whoever remained, or arrived as a replacement, was frequently cheaper, faster, and much less equipped to reason about security implications while a system was still being designed.
Offshoring and near-shoring are not inherently security problems. The version many Australian organisations executed — decided on cost, transitioned quickly, with security requirements either missing from the vendor contract or buried in a schedule nobody ever enforced — is precisely the scenario these controls describe consequences for.
Then there is speed. Boards approved transformation roadmaps with aggressive timelines and executives tied performance to delivery velocity, so when security review slowed a sprint it was deferred, deprioritised, or quietly designed out of the process. Nobody went rogue. People responded rationally to what the organisation was paying them to optimise.
ASD has drawn a line around the outcome of all that and called it a security risk. Whether developers can fix it is beside the point. Whether the governance model that produced it is still running is the question.
Why Vendors and Consultants Won’t Tell You This
The advisory ecosystem around cyber security has a structural problem: the people most likely to brief boards on ASD guidance are either selling a product that addresses the symptom, or billing by the hour to remediate code that should not have been written that way in the first place.
Neither has any reason to tell a board that its own decisions built the exposure. The vendor wants a contract, the consultant wants a remediation project, and both will present a technical gap requiring a technical solution. Some of it genuinely is that. The root cause sits upstream of the codebase, in the decisions that shaped how it was written.
That is an observation about incentives rather than about individuals. The board carries the risk in this arrangement, and the board is generally the last party to hear a frank account of how the risk got there.
What the Regulatory Direction Tells You
Australia’s regulatory posture on cyber security has been moving in one direction for three years. The Privacy Act reforms, the expanded SOCI obligations, the enforcement shift at the OAIC following Optus and Medibank — all of it points toward a model where organisations are expected to demonstrate that they took reasonable steps, not just that they had a policy.
“Reasonable steps” now includes workforce competence. The ASD ISM update makes that explicit for developers. It will not stop there. The trajectory of Australian cyber regulation is toward outcomes-based accountability, which means the question regulators will ask after an incident is not “did you have a security policy” but “did the people building your systems know what they were doing, and did leadership create conditions where they could act on that knowledge.”
Boards that have approved delivery models incompatible with that standard are carrying unpriced risk. The ISM update is the signal that the pricing is about to change.
What You Should Do With This
ISM updates should stop arriving as IT correspondence. When a revised control links security outcomes to workforce capability, three questions belong at board level. Do we know the security competence profile of the people writing our code, internal or contracted? Have we created delivery conditions — timelines, cost structures, oversight models — under which secure development is not realistically achievable? And if an incident happened next month and a regulator asked what steps we had taken, would the last two years of decisions hold up?
What the update provides is a specific, citable standard to audit against, and it is worth using as one. Commission an honest review of development governance: not a penetration test or a vulnerability scan, but a structured look at whether decisions made above the development team have produced a liability that now has a regulatory name attached to it.
The line ASD has drawn is not aimed at your developers. It is aimed at the conditions they work in, and those were approved several floors up.