# Skill 1 — Organisation Risk Discovery

**What this does:** paste this whole document into Claude (or another capable AI assistant) as your first message, then answer its questions. It builds you a first-draft, sector-aware risk list grounded in your own organisation's context — not a generic template. Treat the output as a strong starting draft for a workshop with your own people, not a finished risk register.

**Part of the "From Compliance to Competitive Advantage" GovIS goodie bag (7 Aug 2026).** Use it on its own, or feed its output into Skill 2 (control weighting) and Skill 3 (business case).

---

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

---

You are helping a New Zealand public-sector (or public-sector-adjacent) organisation build a first-draft cyber security risk list. You are not a lawyer, auditor, or insurer, and you should say so if asked to act as one. Work in three steps. Do not skip ahead — ask your questions, wait for real answers, then reason from them.

### Step 1 — Understand the organisation

Ask me the following questions, one group at a time (don't dump all of them at once — it reads better in conversation), and wait for my answers before moving on. If I don't know an answer, note it as a gap rather than guessing on my behalf.

**Who you are:**
1. Organisation name and sector (central government agency, local council/CCO, health, education, critical infrastructure, other).
2. Your organisation's website URL, if you have web access — use it to understand what services/functions the organisation actually delivers, not just its name.
3. Rough size: FTE count band, and whether you operate from one site or many.

**Scope of this assessment:**
4. What's actually in scope here? At minimum: **public-facing/externally-facing systems** — anything reachable from the internet (websites, portals, APIs, anything a member of the public or a regulated entity can touch). Tell me if you also want to include **core internal systems that aren't directly internet-facing** — internal file shares, internal databases, the corporate network, OT/SCADA reached only via an internal path. If you're not sure, start with public-facing systems only and say so explicitly — that matches where MCSS itself sets its own floor (business-critical and externally-facing systems), and you can widen scope in a later pass. Whatever you choose, I'll say so on every output so nobody mistakes a scoped assessment for a complete one.

**How security is resourced today:**
5. Do you have a dedicated, named security person or team? Or is security a part-time responsibility layered onto someone else's job?
6. Is IT delivered in-house, fully outsourced, or a mix? Name the model, not just "we have IT."
7. Do you have any existing framework or standard you assess against today — MCSS, NZISM, ISO 27001, CIS Controls, something else, or nothing formal yet?

**How security is governed and reported today:**
8. Does cyber security reporting reach the Board / Executive / Audit & Risk Committee? How often, and in what form (a slide, a paper, a dashboard, an anecdote in AOB)?
9. How would you honestly describe your current reporting maturity — ad hoc and reactive, a fixed annual return, or a regular structured report with real metrics?
10. Any recent incidents, near misses, or audit findings you're comfortable sharing? (These are gold for calibrating urgency — don't skip this one if you have something.)

**What actually matters if it breaks:**
11. What are the two or three services or systems that would hurt the most — operationally, reputationally, or for the public you serve — if they were disrupted or their data exposed? (Note whether each one is public-facing or internal — it'll matter once we get to Step 3.)

### Step 2 — Correlate sector threats

Using the sector named in Step 1, reason about (and where you have live web access, briefly research) the threat patterns that actually apply to organisations like this one — not a generic "everyone faces ransomware" list. Consider:

- Recent, real incidents affecting similar NZ or comparable-jurisdiction organisations in this sector (name them if you find them, and say whether you're citing a primary or secondary source).
- What that sector holds or controls that makes it a target (patient data, ratepayer/citizen PII, critical service uptime, supply-chain trust, payment data, safety-of-life systems).
- Whether the organisation's answers in Step 1 (thin security resourcing, outsourced IT, weak board visibility, etc.) make it a *softer* target than sector peers, or well-placed against typical attack paths.

State your reasoning, not just a conclusion — the organisation should be able to see *why* you landed on each threat.

### Step 3 — Produce the candidate risk list

Produce 6–10 candidate risks (fewer for a very small/simple organisation, more for a large or multi-service one), each as an ISO 31000-style if/then risk statement. Two rules for how to frame them:

- **Always include at least one resiliency/continuity risk.** Don't let the list become all-breach, all-the-time — a risk framed around the organisation's ability to keep operating or recover quickly (not just "an attacker gets in") belongs on every list, even a short one.
- **Frame every risk at the enterprise level, not a business-unit level.** Even when the underlying exposure sits in one team or system (a payments team's inbox, one plant's OT network), state the risk as something the *whole organisation* carries, not a problem that belongs to that unit. "The organisation's exposure to fraudulent payment redirection" — not "the finance team's email risk." The organisation is answerable for the consequence regardless of which unit the gap happens to sit in.

Use this table format:

| Risk name | Statement (if X happens, then Y) | Consequence | Key Risk Driver | Threat basis |
|---|---|---|---|---|

Column definitions:
- **Risk name** — short, enterprise-level label.
- **Statement** — the if/then causal narrative: what happens, and what follows from it.
- **Consequence** — the actual impact if this materialises, framed in outcome terms an executive would recognise (service downtime, safety incident, financial loss, regulatory/reputational exposure) — distinct from the statement, this is specifically "how bad, in what currency of harm."
- **Key Risk Driver** — the single underlying factor that most determines whether this risk materialises or how bad it gets. Usually a control gap, a structural dependency, or an absence of oversight — not a restatement of the risk itself. ("No enforced MFA on finance-adjacent accounts" is a key risk driver; "phishing happens" is not — it's too generic to act on.)
- **Threat basis** — tie back to your Step-2 reasoning: why this threat is real for this organisation's sector and profile.

Close with a short, honest note on what's still missing — any Step-1 question I couldn't answer well, and what that gap means for how much weight to put on this draft before it goes in front of people. Always restate the scope from Step 1.4 plainly here too: if this list only covers public-facing systems, say so explicitly, and note that internal-only risks (insider access, lateral movement once past the perimeter, internal-only OT/SCADA paths) aren't represented and would need a separate pass.

---

**Design note (self-contained — no other files needed to use this prompt):** the if/then risk-statement format and the "consequence vs. key risk driver" distinction come from established risk-statement practice (ISO 31000-style causal framing, distinguishing *what happens* from *why it happens* from *what it costs*). Splitting them into separate columns forces each risk to name a specific, actionable driver rather than settling for a generic threat label — a risk whose driver is "no enforced MFA" points straight at what to fix; a risk whose driver is just "cyberattack" doesn't.
