MCSS is the business case you haven't written yet

TL;DR.The Minimum Cyber Security Standards are mandatory for every NZ public sector agency. Most of the sector will treat them as compliance work, which is probably the easiest way to think about them, but it’s the wrong frame. An MCSS response, done right, contains every ingredient of a funding business case: the gap analysis, the risk position, the prioritised roadmap, the peer comparison. The data is the same; the viewing is the difference. The question is whether your team treats MCSS as a submission to file, or as the cheapest business case it will ever write.

MCSS at a glance:
10 standardsscored on the CMM 1–4 maturity scale.
A maturity gap against the target for an agency of your size and risk profile.
A business risk position that maps your cyber posture onto the harms an exec actually loses sleep over.
A prioritised roadmap that shows which gaps to close first, and why.
Together, these are the components of a funding business case. The mandate already requires you to collect the inputs.

Most cyber vendors will sell you MCSS as a compliance headache: a ten-standard checklist, a spreadsheet to fill in, a rating to submit, and then a trek back to the same risk register you already have.

We think that’s the wrong way round.

The Minimum Cyber Security Standards are mandatory, and every NZ public sector agency is going to do them. The only real question is whether your team treats that work as a cost, or as the cheapest business case it will ever write.

Why isn’t MCSS just compliance work?

Here’s what nobody says out loud at the CISO meetups: NZ public sector cyber leads aren’t short on compliance work, they’re short on funding.

You have a risk register. You have a backlog of initiatives you know would move the needle. You have an exec who nods sympathetically when you present the quarterly cyber update, and a CFO who asks, politely, whether this year’s ask can wait. You have a minister who rewards the absence of bad headlines, not the presence of good controls. And you have a budget cycle that closes faster than any business case you could write from scratch.

A Cabinet-style business case is a significant piece of work. The prep alone for a dedicated security team, the gap analysis, the risk position, the benchmarking, eats a quarter and still comes back with questions. Nobody has that quarter, not in the run-up to Budget, not during the year-end reporting crush, not ever, really.

So the business cases don’t get written, the funding doesn’t land, and the risks you knew about last year are still on the register this year, only older. The sector tells itself this is a resourcing problem. We think it’s a framing problem.

How does MCSS become a funding business case?

MCSS is mandatory data collection about your agency’s cyber maturity: ten standards scored on a consistent model, showing where you sit against what NCSC expects. You have to gather it and submit it regardless. That data, viewed the right way, is already a business case. The compliance submission and the funding argument are built from exactly the same inputs.

• Gap analysis is the gap between your current maturity and the standard target.
• Risk quantificationis the impact of those gaps on your agency’s actual business risks.
• Prioritised roadmap is the cost and difficulty of closing each gap, ranked.
• Peer benchmarking is your scores compared against agencies of comparable size and exposure.

The only thing standing between “MCSS submission” and “funded business case” is the viewing. Somebody has to look at those scores the right way and translate them into language an exec will sign.

What “the right viewing” actually requires

Three things separate an MCSS submission that funds work from one that gets filed and forgotten.

The first is risk-weighted prioritisation. A list of ten maturity scores doesn’t tell anyone what to do first. Sorting by score, or by gap size, is the obvious move and the wrong one. What matters is which gap, if closed, would reduce the most business risk for the least difficulty. That ranking is a defensible decision, not an opinion. It’s also the answer a CFO is actually trying to get to when they ask “what should we fund?”

The second is translation into business risk language. “We are at CMM 2 on incident response” isn’t a sentence an Audit & Risk Committee chair wants to read. “Our current likelihood of a sustained service outage from a cyber incident is rated Medium-High against our internal tolerance of Low” is. The translation step, from maturity scores to likelihood-and-impact bands against the harms your agency actually carries, is what makes the cyber posture readable by people who aren’t cyber leads. Until that translation is done, the funding conversation can’t start.

The third is consistency. A report that produces a different answer each time you re-run it isn’t a basis for funding decisions. Internal Audit won’t accept it. The Audit & Risk Committee won’t stand behind it. The methodology has to be defensible, repeatable, and free of model creativity. The same scores must always produce the same report; otherwise the whole exercise sits one cynical question away from collapse.

These aren’t new ideas. They’re what good cyber governance has always looked like. What’s new is that MCSS, as a mandated data-collection exercise, finally gives every NZ public sector agency a consistent enough dataset to do this properly.

MCSS as compliance vs MCSS as business case

What this looks like for a CISO at a NZ ministry

Picture a CISO, call her Kiri, at a mid-size ministry. Budget cycle is eight weeks away. She has three initiatives she knows the agency needs: a proper identity uplift, a gap in third-party assurance, and an incident response capability that currently depends on one very tired person.

Last year, she took a risk register to the Leadership Team and asked for an extra two FTE. The CFO said to come back when the ask was quantified. She didn’t have time to quantify it, and the ask died.

This year, MCSS is mandatory. Her GRC analyst runs the assessment and reads the results as a risk position rather than a compliance submission. The three initiatives Kiri already knew mattered come out ranked by the risk they reduce, translated into the business risks the Leadership Team already tracks.

She walks into the budget meeting. She doesn’t open a risk register. She opens the risk matrix, points at the two cells sitting above the tolerance line, and says “here’s what closing these gaps does, and here’s what it costs.” The roadmap is the delivery plan. The CFO doesn’t ask her to come back when the ask is quantified, because the ask is already quantified.

The standards haven’t changed. The scores haven’t changed. The viewing has, and so has the outcome.

The hard bit is the viewing, not the data

MCSS in a spreadsheet gives you a score and very little more. The score goes to NCSC. Your exec asks what it means for funding, and the honest answer is “nothing yet, because you still have to write a business case.” You’ve done the work twice: once to comply, once to actually make it useful.

The reframe collapses those two into one. The compliance submission becomes a by-product, and the funding-ready view is the main output. You do the work once. Because the methodology is consistent, re-running it next quarter with your updated evidence, your new hires, your closed controls, gives you the same shape of document with a fresh risk position. The funding conversation is always one report away.

CISOs in NZ public sector aren’t short of obligations; they’re short of leverage. MCSS is the largest piece of mandated data any NZ agency will collect about its own cyber posture this decade. It would be strange to treat that as a cost and not a lever.

“But we already started in Excel” and other common objections

We’ve already filled out an Excel template. Should we throw that work away?

No, and you shouldn’t have to. The hours your team spent agreeing CMM levels in a spreadsheet are real work, not lost effort. Any platform worth using will accept your existing scores as a starting point. What you add on top is the evidence layer, the risk view, and the ability to compare your position year on year, none of which a spreadsheet can produce. The work already in the Excel file is the reason moving is quick, not a reason to stay.

Isn’t this just a risk report with extra steps?

A risk report describes risk; a business case quantifies it, prioritises it, and asks for money. The difference isn’t cosmetic. A board-ready risk report stops at “here’s what we’re exposed to.” A business case continues: “and here’s what closing these gaps does, here’s what it costs, here’s the order to do it in.” That last leg is what gets signed.

What if our CFO doesn’t accept platform-generated business cases?

The report isn’t the business case; the business case is yours. The report is the evidence pack, the risk position, the prioritised initiatives, the benchmarking, that goes in the appendix and makes the rest of your paper defensible. Every CFO accepts that.

How we approach this at Speculo

Speculo is a security risk and compliance platform for any organisation that needs to understand, evidence, and communicate its security posture. That includes New Zealand government agencies and Pacific island governments working through MCSS and NZISM, and the private sector organisations that need to demonstrate the same standard to work alongside them.

We built it because the sector needed a proper way to do this thinking, and nobody else was building it. So we did.

When an agency runs MCSS through Speculo, it produces a single consistent report: maturity gaps weighted by their contribution to business risk, prioritised by the difficulty of the next move, mapped onto the harms an NZ public sector exec actually loses sleep over. The same scores always produce the same report, which matters more than “AI-powered insight” when the document lands on the Internal Auditor’s desk. The output is meant to go straight into the appendix of a Cabinet paper or a Leadership Team submission, not to sit on a shelf.

Access is rolling out in waves. Current customers and anyone in the active workshop programme are going first. Everyone else can join the waiting list. We’re working through it as fast as we can.

Two ways to start

Book a workshop →

Join the waiting list for early access →

Either route lands you in the same place: your MCSS response, reframed as the business case you’ve been meaning to write.

Chris Hawksworth is the founder of Speculo, a strategic cyber risk and compliance platform built in Wellington, New Zealand.