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 Actually Saying
When a regulator publishes guidance that ties security failures to workforce competence, it is not writing a training syllabus. It is establishing what reasonable practice looks like. That matters enormously in a post-incident environment, under the Privacy Act, under SOCI obligations, or in front of an APRA prudential review. “We didn’t know our developers lacked the necessary skills” is not a defence — it is a confession of governance failure.
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
Here is the conversation most boards are not having. The developer competence problem ASD is now formalising did not emerge from nowhere. It was built, decision by decision, in your own organisation.
Headcount reductions in technology teams, particularly the kind driven by cost programmes in 2022 and 2023, did not just reduce capacity. They removed the senior developers and security-aware engineers who carried institutional knowledge about what the codebase was doing and why. What remained, or what was hired to replace them, was often cheaper, faster and considerably less equipped to reason about security implications during design.
Offshoring and near-shoring of development work is not inherently a security problem. But the version of it that many Australian organisations executed — where the decision was made on cost, the transition was done quickly, and security requirements were either absent from the vendor contract or buried in a schedule nobody enforced — is exactly the scenario ASD’s updated controls are describing consequences for.
Speed-over-security delivery models are the third vector. Boards approved digital transformation roadmaps with aggressive timelines. Executives tied performance to delivery velocity. When security reviews slowed sprints, they got deprioritised, deferred, or redesigned out of the process entirely. The developers were not rogue. They were responding rationally to the incentives the organisation created.
ASD has now drawn a line around the outcome of those decisions and called it a security risk. The question for boards is not whether the developers can fix it. It is whether the governance model that created it is still in place.
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 party is incentivised to tell a board that its own decisions created the exposure. The vendor wants a contract. The consultant wants a remediation project. Both will frame the problem as a technical gap requiring a technical solution. Some of it is. But the root cause is not in the codebase — it is in the decision-making that produced it.
This is not a criticism of vendors or consultants as individuals. It is a structural observation about who carries risk in that conversation. The board carries the risk. The board is also the last to hear a frank account of how it 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
Stop treating ASD ISM updates as IT correspondence. When a revised control connects security outcomes to workforce capability, the board should be asking three questions directly: Do we know the current security competence profile of our development workforce, whether internal or contracted? Have we created delivery conditions — timelines, cost structures, oversight models — that make secure development practically impossible? And if an incident occurred tomorrow and regulators asked what steps we took, would our answers from the last 24 months hold up?
The ASD update gives boards a specific, citable standard to audit against. Use it that way. Commission an honest review of your development governance — not a penetration test, not a vulnerability scan, but a structured examination of whether the decisions made above the development team have created a security liability that now has a regulatory name.
The hard line ASD has drawn is not aimed at your developers. It is aimed at the conditions your developers are working in. Those conditions were approved at your level.