# Skill 2 — Control Weighting & Target Maturity

**What this does:** takes a risk list (ideally from Skill 1, or your own) and a control set (MCSS's 10 standards by default, or your own control catalogue) and produces a worksheet: which controls actually reduce which risks, how much each one matters, and what maturity level is realistically the right target for *your* organisation — not a generic benchmark.

**Run this after Skill 1.** Have your risk list and your current MCSS (or other framework) self-assessment to hand.

---

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

---

You are helping a New Zealand public-sector organisation turn a risk list into a prioritised, weighted control worksheet. Work in four steps, in order. Ask for anything you need before proceeding rather than assuming it.

### Step 0 — Inputs

Ask me for:
1. The risk list (from Skill 1, or my own — paste it in).
2. The control set I'm assessing against — by default, use the 10 MCSS standards (Risk Management, Security Awareness, Assets and their Importance, Secure Configuration of Software, Patching, Multi-Factor Authentication, Detect Unusual Behaviour, Least Privilege, Data Recovery, Response Planning); if I have my own control catalogue (NZISM, ISO 27001 Annex A, CIS Controls, an internal list), use that instead — don't force MCSS if it's not what I have.
3. My current maturity per control. If I have a self-assessment already, even a rough one, use it (note it as rough if so). If I don't, run a quick check before proceeding: for each control in scope, ask me which of these best describes today, using this scale:

   | Level | Name | What it looks like |
   |---|---|---|
   | 0 | Non-existent | Nothing in place |
   | 1 | Informal | Ad hoc, depends on specific people, not written down |
   | 2 | Planned & Tracked | Documented, repeatable, meets core requirements — the MCSS-mandated floor |
   | 3 | Standardised | Consistent and governed across the whole organisation |
   | 4 | Quantitatively Controlled | Actively measured and monitored |
   | 5 | Optimising | Continuously improved based on that measurement |

   If I say "I don't know" for a control, don't guess on my behalf and don't skip it — record it as **0** and flag it in the output as *unassessed, not confirmed absent* so it's visibly different from a control I've actually confirmed is at zero.
4. My organisational profile from Skill 1 (or ask the same short set of questions again if I haven't run Skill 1): dedicated security resource or not, IT model, board reporting maturity, sector, size.

### Step 1 & 2 — Map controls to risks, and weight them

For each risk in my list, select the controls (from my chosen control set) that genuinely reduce it. Don't pad the list — every control you include must have a real, explainable mechanism for reducing that specific risk. For each mapped control, note whether it acts **before** the event (reduces likelihood — patching, MFA, access control, hardening, awareness) or **at/after** the event (reduces impact — backup, recovery, incident response, detection, notification). A control can do both, but reserve that for genuine cases, not the default.

Then, for every control mapped to a risk, assign an integer weight 1–10 for how materially it reduces *that specific risk* — not how important the control sounds in general. Use this taxonomy:

| Weight | Meaning |
|---|---|
| 9–10 | Core control — this risk is largely about whether this control works |
| 7–8 | Strong contributor |
| 5–6 | Moderate contributor |
| 3–4 | Minor/supporting — real but secondary |
| 1–2 | Marginal — state why you're including it at all, or drop it |

Show your reasoning for any weight of 8 or above — that's where the priority calls actually get made later.

Present this stage as one table, titled **"Risk Control Mapping and Per-Risk Weights"**, one row per risk:

| Risk | Risk Description | Consequence | Mapped Controls (L/I) | Weight |
|---|---|---|---|---|

- **Risk / Risk Description / Consequence** — carry these straight over from my risk list (from Skill 1's output, or my own) if I have them in that shape; if I only gave you a rough risk list, restate them in this shape from what I gave you rather than leaving the columns blank.
- **Mapped Controls (L/I)** — the controls from this risk's mapping, in the same order as the Weight column, each tagged L or I.
- **Weight** — the weights, same order as Mapped Controls, so the two columns read as paired lists.

### Step 3 — Determine a realistic target maturity, per control, for THIS organisation

This is the step that must not default to a generic benchmark. Using the organisational profile from Step 0.4, reason explicitly about what target maturity is realistic and appropriate — using something like this logic, and stating your reasoning, not just a number:

- **No dedicated security resource + outsourced IT + no/weak board reporting** → a realistic near-term target for most controls is around **CS-CMM Level 2 (Planned & Tracked)** — the MCSS-mandated floor — with only the highest-weighted controls (9–10) pushed toward Level 3.
- **A named security lead, in-house or well-managed outsourced IT, some board visibility** → Level 3 (Standardised) is a realistic target across most high-weight controls, Level 2 for lower-weight ones.
- **A dedicated security team, regular structured board/Audit & Risk Committee reporting, and/or high sector threat exposure (critical infrastructure, health, high-value data)** → push high-weight (8+) controls toward Level 4 (Quantitatively Controlled); don't default everything there — that's expensive and not always warranted.
- Regardless of profile, a control with weight 9–10 against a risk with severe consequences should never be left at Level 1 (Informal) as a long-term target, even in a thin-resourced organisation — flag it as a priority gap instead of silently downgrading the ambition. When a control maps to several risks at different weights, judge this exception on the **single highest weight×severity combination across all of its risk mappings**, not an average — one severe, high-weight mapping is enough to trigger the exception even if the control's other mappings are minor.

State the target as a range if you're uncertain, and say explicitly where you're making a judgement call versus reading it directly from the organisation's answers.

### Step 4 — Output

Produce one worksheet, one row per control:

| Control | Risk(s) it reduces | Weight(s) | Current maturity (self-assessed) | Realistic target maturity | Gap | Urgency (High/Med/Low, with a one-line reason) | Rough effort to close (0–100, with a one-line reason) |
|---|---|---|---|---|---|---|---|

Sort the output by weight × gap, highest first — that's the org's honest priority order, not an alphabetical control list.

Close with "Where I'd actually start" — 3–5 controls, **as short bullets, one per control, 1–2 sentences each** (not one dense paragraph). Each bullet: which control, why this one specifically (weight, effort, or urgency — say which), and what it would look like to say out loud to a non-technical executive. If your honest recommendation differs from the pure weight × gap sort (e.g. a cheaper, faster control beats a higher-sorted but slower one), say so explicitly and say why — that tension is useful information, not something to smooth over.

---

**Design note (self-contained — no other files needed to use this prompt):** the weight taxonomy (1–10, banded by how core the control is to the risk) and the target-maturity reasoning (read from the organisation's own resourcing profile rather than a fixed size category) are both deliberately built to work standalone, without any external benchmark set or calibration data behind them. That's a real trade-off worth naming: a dedicated risk platform with a large calibrated control catalogue can sanity-check these numbers against hundreds of prior assessments; this prompt can't, because it has nothing to compare against except the reasoning you can see it doing in front of you. Treat every weight and target maturity here as a considered starting draft, not a certified benchmark — the value is in surfacing the *reasoning*, which a workshop with your own people can then sharpen.
