The 70% Problem Has Nothing to Do With Methodology
Boards have now sat through multiple generations of delivery reform. Waterfall gave way to Agile. Agile gave way to SAFe. SAFe gave way to product operating models, DevOps transformations, and whatever the consultants are calling it this quarter. And yet, as iTnews reports, nearly 70 per cent of IT projects still fail or fall short of expectations. The methodology changes. The failure rate doesn’t.
The same rate applies to security programs, and for the same reasons. Not the wrong framework, and not a CISO short on technical skill. The accountability structures at the top of the organisation were never fit for the decisions being made, and boards keep reforming the delivery engine while the governance sitting above it stays exactly as it was.
The Excuses Are the Same in Both Rooms
Those of us who have sat in project post-mortems and board security reviews will recognise the pattern immediately, because the language is interchangeable.
In the project post-mortem: “The requirements kept changing.” “The business wasn’t engaged.” “We didn’t have the right skills.” “The vendor underdelivered.” “There wasn’t enough executive sponsorship.”
In the board security review after an incident or a failed program: “The threat landscape changed.” “The business units weren’t engaged.” “We had skill gaps in the team.” “The vendor didn’t perform.” “There wasn’t enough executive support.”
The same failure, narrated in two different rooms, by two different sets of professionals, who rarely compare notes. The project office blames delivery complexity. The security team blames threat complexity. Both are deflecting from the same root cause: nobody at the top of the organisation owned the decision rights clearly enough to make hard calls when they were needed.
Methodology Is a Comfort Blanket
When a major project fails, the instinct is to change the method. When a security program fails to mature or an incident exposes systemic gaps, the instinct is to change the framework — adopt a new standard, bring in a new CISO, commission another maturity assessment.
This is understandable. Methodology changes are visible, bounded, and allow leadership to demonstrate action without confronting the harder question of whether the governance above the program was ever adequate.
The harder question: who specifically had the authority to stop work that was clearly failing, to reallocate budget mid-cycle when priorities moved, and who was accountable — not responsible in the RACI sense, genuinely accountable — when the outcome was poor?
In most organisations the honest answer is nobody in particular. Authority is diffuse and accountability is collective, which is another way of saying it belongs to no one. Executives sponsor programs without owning outcomes, boards receive updates formatted to reassure rather than inform, and the methodology takes the blame because it cannot answer back.
What This Means for Security Governance Specifically
Security programs fail this way constantly, and the pattern is well-established. An organisation invests in a multi-year uplift program. A maturity framework is selected. Resources are allocated. Eighteen months in, the program has produced documentation, workshops, a revised policy suite, and a dashboard — but the actual risk posture has not materially changed. The program is then refreshed, reframed, or quietly wound back.
The post-mortem, when it happens at all, focuses on execution. Did the CISO have enough resources? Was the vendor the right choice? Was the framework appropriate for the organisation’s size and complexity?
All the wrong questions. The structural ones run differently. Did the board have a clear view of what success looked like in measurable terms — business outcomes, not maturity scores? Did the executive team hold defined decision rights over the trade-off between security investment and operational velocity? When the CISO escalated a resourcing conflict, or a business unit that simply would not participate, did the escalation path have teeth?
Usually the answer to all three is no. The program was approved, funded and then orphaned at governance level, leaving the CISO to navigate organisational politics, compete for engineering resources and manage business unit resistance without formal authority over any of it. Failure under those conditions is not a methodology problem; it is governance design working exactly as built.
Australian Boards Have a Specific Obligation Here
This is not abstract. Under APRA CPS 234, regulated entities are required to maintain information security capability commensurate with the size and extent of threats to their information assets. Under the Security of Critical Infrastructure Act, responsible entities carry direct obligations that sit at the board level, not the IT level. The Privacy Act reforms moving through the Australian legislative process will increase the accountability exposure of directors when personal information is compromised as a consequence of inadequate governance.
The legal and regulatory framing is shifting accountability upward. Boards that have treated cyber security as a technical matter — delegated to the CISO, reported on periodically, and otherwise managed below the executive line — are accumulating exposure they may not fully appreciate.
But compliance framing aside, the business case is straightforward. If 70 per cent of transformation programs are failing, and security uplift programs fail at similar rates, and both sets of failures trace back to governance rather than execution, then the single highest-leverage intervention available to a board is not approving a new framework. It is redesigning the accountability structure above the program.
What Boards Should Do Differently
The question is not whether the organisation has the right methodology. It is whether it has the right decision rights.
At the point a security program is approved, the board should be able to name who is accountable for the outcome, what that accountability means in practice when things go badly, and what authority that person holds to resolve the conflicts that will certainly arise. Any of those three left vague at approval, and the program is already in trouble.
Audit committees can treat a program update the way a demanding investor treats a project update: as a governance test rather than a status report to be received. Is the person presenting accountable for the outcome? Does their authority match that accountability? Is this reporting built to inform or to reassure?
That 70 per cent failure rate has never been a technology or methodology problem. It is a governance problem that the technology and methodology industries have successfully claimed as theirs to solve, at considerable recurring expense to everyone who keeps buying the next answer. Boards are the only party in the system with both the authority and the obligation to break that cycle.