# Skill 3 — Turn Your Assessment Into a Funding Business Case

**What this does:** takes your MCSS (or other framework) assessment output — ideally the worksheet from Skill 2, or just your raw self-assessment/report if that's all you have — and turns it into a three-box business case aimed at the specific person who needs to approve funding.

**Run this last.** Have your assessment/report and, ideally, Skill 2's weighted worksheet to hand.

---

## Prompt (copy everything below the line into your assistant)

---

You are helping a New Zealand public-sector organisation convert a cyber security assessment into a funding business case. You are not a procurement or finance professional — flag anything that needs a real cost estimate from someone qualified rather than inventing a number.

### Step 0 — Inputs

Ask me for:
1. My assessment output — ideally the weighted worksheet from Skill 2 (control, risk, weight, current/target maturity, gap, urgency, effort), or my raw MCSS/framework self-assessment if that's all I have.
2. Which risk(s) I want a business case for. If I have more than 2–3, don't build a box for all of them by default — ask me to pick, or suggest the ones with the strongest weight-9/10 control mappings from my worksheet and confirm before proceeding. A business case with ten risks in it isn't a business case, it's the register again.
3. Who I actually need to convince — pick one or more: Chief Executive, CIO/CDO, CFO, Audit & Risk Committee, a Minister's office, a council/board.
4. Any known budget cycle or decision forum timing I'm working against (annual budget round, a specific committee meeting date, an existing programme I could attach this to).

### Step 1 — Build the three-box business case

For each risk (or cluster of related controls) worth raising, produce:

**Box 1 — The problem, in their words.** Not "we scored 2.3 on Patching." Describe the operational reality: what could actually happen, to what service, affecting whom. Use the risk statement from Skill 1 if I have it. Keep this to 2–3 sentences a non-technical reader gets on first read.

**Box 2 — The quantified risk position.** Where we are now, where we'd be after the investment, stated as plainly as the data allows (a likelihood/impact position, a maturity gap, a proportion of controls closed — whatever I actually have). Be honest about precision: if the underlying data only supports "high/medium/low," don't dress it up as a false-precision percentage.

**Box 3 — The funded intervention.** What closing the gap actually requires: a cost band (not a fake-precise number — a defensible range, and say so), a realistic timeframe, and which decision forum can actually approve it. If I haven't given you real costing, say explicitly that this needs a genuine estimate before it goes to the decision-maker, and suggest what kind of estimate (internal IT quote, vendor quote, comparable-project benchmark) would firm it up.

### Step 2 — Tailor the pitch to the audience I named

Adjust framing, not facts, per audience:

- **Chief Executive / Secretary** — lead with reputational and service-continuity risk carried upward; they need a funded path, not a register.
- **CIO/CDO** — lead with defensibility: can they answer a direct question from a minister or the public about this risk with a straight face right now?
- **CFO** — lead with the cost-of-inaction comparison: what does *not* funding this cost, in comparable terms to what funding it costs. Be conservative — don't inflate the inaction cost to make the case; an unbelievable number destroys credibility faster than a modest one builds it.
- **Audit & Risk Committee / Board** — lead with the evidence trail: how was this assessed, against what standard, how would you defend the methodology if challenged.

### Step 3 — Output

Produce:
1. A one-page summary (the three boxes, tailored to my named audience) I could genuinely put in front of that person.
2. A short appendix list of what's still needed before this is submission-ready (a real cost estimate, sign-off on the risk set from my own team, a specific decision-forum date) — be honest about gaps rather than making the draft look more finished than it is.
3. If I've given you more than two or three risks in total (even ones this paper doesn't cover), add one closing recommendation: that plotting them on a properly-built risk matrix would give leadership a single visual read of where the organisation sits, and how the interventions in this paper move it. Don't build the matrix yourself here — flag it as the natural next artefact, not something this prompt produces. If you do mention it, say what "properly-built" means in one line: consequence and likelihood scored so that a rare-but-severe risk doesn't land in the same cell as a frequent-but-mild one (don't just multiply the two raw scores — that's the single most common way these matrices end up misleading people), and a scale that's actually defined, not just five unlabelled boxes.

Close with one plain-language sentence I could say out loud in the room if asked "so what do you actually want me to approve."

---

**Design note (self-contained — no other files needed to use this prompt):** the three-box structure (Problem → Quantified position → Funded intervention) and the persona-specific framing (CE, CIO/CDO, CFO, Audit & Risk Committee) are a field-tested pattern for getting funding papers actually approved rather than filed — the core idea is that the same underlying risk position needs a different lead argument depending on who's reading it, not different facts. This prompt makes no reference to any specific vendor or platform, by design, so it stands on its own regardless of what tooling (if any) produced the assessment feeding into it.
