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.
Here is the position: that same 70% failure rate applies to security programs, and it fails for identical reasons. Not because organisations chose the wrong framework. Not because the CISO lacked technical skill. Because the accountability structures at the top of the organisation were never actually fit for the decisions being made. Boards and executives keep reforming the delivery engine when the problem is the governance sitting above it.
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 is this: who, specifically, had the authority to stop work that was clearly failing? Who had the authority to reallocate budget mid-cycle when priorities shifted? Who was accountable — not responsible in the RACI sense, but genuinely accountable — when the outcome was poor?
In most organisations, the honest answer is: nobody, clearly. Authority is diffuse. Accountability is collective, which means it belongs to no one. Executives sponsor programs without owning outcomes. Boards receive updates formatted to reassure rather than inform. And the methodology absorbs 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?
These are the wrong questions. The right questions are structural: Did the board have a clear view of what success looked like in measurable terms — not maturity scores, but business outcomes? Did the executive team have defined decision rights over the trade-offs between security investment and operational velocity? When the CISO escalated a resourcing conflict or a business unit refusing to participate, was there a clear escalation path with teeth?
In most cases, the answer to all three is no. The security program was approved, funded, and then effectively orphaned at the governance level. The CISO was expected to navigate organisational politics, compete for engineering resources, and manage business unit resistance — without the formal authority to resolve any of it. Failure under those conditions is not a methodology problem. It is a predictable outcome of inadequate governance design.
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% 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 Actually Do Differently
Stop asking whether the organisation has the right methodology. Start asking whether the organisation has the right decision rights.
Specifically: when a security program is approved, the board should be able to name — with precision — who is accountable for the outcome, what that accountability means in practice when things go wrong, and what authority that person has to resolve the conflicts that will inevitably arise. If those three questions cannot be answered clearly at the point of approval, the program is already at risk.
Audit committees should treat a security program update the same way a rigorous investor would treat a project update: not as a status report to be received, but as a governance test. Is the person presenting accountable for the outcome? Do they have the authority commensurate with that accountability? Is the reporting designed to inform or to reassure?
The 70% failure rate is not a technology problem or a methodology problem. It is a governance problem that the technology and methodology industries have successfully reframed as their own to solve — at considerable ongoing expense to the organisations that keep buying the next solution.
Boards are the only actors in this system with both the authority and the obligation to break that pattern. The methodology cannot do it. Only governance can.