Cyber Defence Analyst — a six-week applied programme

Control, vulnerability, threat, event, incident, risk — six words every team uses slightly differently, and what breaks when they do.

• ✓
  learnRequired

  The six words, and the handovers they break

  Read the brief~2 min

  Nobody loses an incident over vocabulary, and plenty of teams lose an hour of one. The handover that goes wrong is almost always a word that meant something slightly different at each end of it — a detection engineer says event, an incident responder hears incident, and a manager three levels up hears breach and starts making calls.

  The six that cause the trouble

  • Vulnerability: a weakness that could be exploited. It exists whether or not anyone has found it, and its severity rating says nothing about your estate.
  • Threat: someone or something with the capability and intent to exploit it. A vulnerability with no threat is a maintenance item.
  • Risk: the two together, against an asset that matters, after the controls you already have. This is the only one of the six that is a business statement.
  • Event: something happened and it was logged. Most of what you look at.
  • Alert: an event a rule thought was worth your attention. The rule is frequently wrong, and that is a property of the rule.
  • Incident: someone has decided this is real and something must be done. Note that this is a DECISION, made by a person, at a time that gets written down.

  Why the last one matters most

  Incident is the only word on the list whose meaning is set by a human act rather than by a fact. That is why declaring one feels heavy, why teams delay it, and why the delay is what later looks bad. Knowing that declaring is a decision — with a person and a timestamp attached — is most of what separates a team that handles its first real one well from a team that discovers the question at 2am.

  Carry this into the drill

  The Scramble covers forty terms across governance, risk, audit and security. Play it for the ones you half-know rather than the ones you use daily — those are the ones that go wrong in a handover. The Crossword is the same ground in a different shape if you want a second pass.

  Go deeper — with your own AICopy-paste prompt

  The brief above is the spine. This is a full study prompt for whichever assistant you already use — it carries your programme, this module and what the brief just covered, so the lesson comes back tailored rather than generic. Pick how you want it, edit anything, then copy.

  WrittenInfographicBoth

  You are an experienced control-risk practitioner and an exceptional teacher. Teach me one topic properly — the way a senior colleague would over a long coffee, not the way a textbook would. MY CONTEXT - Programme: Cyber Defence Analyst — a six-week applied programme (6 weeks, ~10h a week, self-paced). - Level: Practitioners rather than executives: detection and response analysts, incident responders, identity and platform engineers with a security remit, and GRC people who need to be credible with all of them. - Week 1 of 6: The queue, and the judgement it demands — Start where the work actually starts: a shared vocabulary, a queue longer than the shift, and the two decisions a defender makes hundreds of times a week — is this real, and does it go first. - Module 1.1: The language you will be held to - Today's topic: The six words, and the handovers they break - I am studying alone, applying this to my own organisation, and nothing I produce is graded. Assume I am a working professional, not a student: skip the motivational framing and the history lesson unless the history changes what I should do. WHAT I ALREADY HAVE (do not simply repeat this — go past it) - The six that cause the trouble - Vulnerability: a weakness that could be exploited. It exists whether or not anyone has found it, and its severity rating says nothing about your estate. - Threat: someone or something with the capability and intent to exploit it. A vulnerability with no threat is a maintenance item. - Risk: the two together, against an asset that matters, after the controls you already have. This is the only one of the six that is a business statement. - Event: something happened and it was logged. Most of what you look at. - Alert: an event a rule thought was worth your attention. The rule is frequently wrong, and that is a property of the rule. - The point I am meant to carry into practice: The Scramble covers forty terms across governance, risk, audit and security. Play it for the ones you half-know rather than the ones you use daily — those are the ones that go wrong in a handover. The Crossword is the same ground in a different shape if you want a second pass. WHAT I WANT FROM YOU 1. The core idea in five sentences, in plain language, including the one distinction practitioners most often get wrong here. 2. Why it matters in practice: what actually goes wrong when this is done badly, with two realistic short scenarios — one financial services, one outside it. 3. The mechanics, step by step, at the level of detail I could follow at my desk tomorrow. Show the judgement calls, not just the procedure, and say what a good answer looks like versus a defensible-but-weak one. 4. At least one fully worked example with realistic specifics — names, numbers, evidence, dates. Show your reasoning as you go, including where you would push back on your own conclusion. 5. The five most common mistakes, each with the tell that gives it away and the correction. 6. How this connects to the rest of control risk: what it depends on upstream and what breaks downstream if I get it wrong. 7. What competent practitioners genuinely disagree about here, and how I should decide for my own context. 8. A short glossary of any term you use that a regulator, an auditor and a business owner would each define differently. 9. Six self-test questions that require judgement rather than recall — hold the answers back until I have attempted them, then mark my reasoning, not just my conclusion. OUTPUT FORMAT: written explanation. Long-form prose with headed sections, worked examples and tables where a table genuinely helps. No images. HOW TO WORK WITH ME - Ask me up to three questions about my sector, my organisation's size and my current maturity BEFORE you start, then tailor everything to my answers. - Prefer concrete specifics over hedged generalities. If something depends on context, say which context and why. - Flag anything that is genuinely contested, jurisdiction-specific or changing, and tell me what would make you change your answer. - If I have got something wrong in what I said I already know, correct me directly. - Do not invent standards, clause numbers, statistics or citations. If you are unsure of a reference, say so plainly instead. - After the lesson, quiz me the way this module's drill would (scramble, crossword): give me a situation, make me decide, then challenge the decision I make. - Finish by helping me plan my deliverable for this module: Team glossary, with the three terms you use inconsistently named. Ask what my process is, then outline what mine should contain and what would make it weak.

  Copy promptYours to edit — changes stay in this box

• ✓
  playRequiredTicks itself

  The Practitioner's Scramble

  Forty terms across four packs, read from a clue and spelled out. The vocabulary a defender is held to, including the governance half most practitioners pick up by osmosis and get slightly wrong.

  Open the drill

  Ticks itself when the drill records a result

• ✓
  playOptionalTicks itself

  The Practitioner's Crossword

  Optional: four full puzzles over the same language in a different shape. Worth it if the Scramble showed you gaps — recall and recognition are different, and a handover needs the first.

  Open the drill

  Ticks itself when the drill records a result

• ✓
  applyRequired

  Team glossary, with the three terms you use inconsistently named

  Open the brief

  Write the one-page glossary for your own team. Not a textbook list — the terms your team actually uses, with the definition you will all now use.

  The valuable part is naming three terms your team currently uses inconsistently. Ask two colleagues to define each one separately before you write anything; the disagreement is the finding.

  What to produce

  • The six core terms, with your team's agreed definition of each
  • Three terms your team defines inconsistently, with the two definitions you actually collected
  • For each: the one you are adopting, and why
  • Who declares an incident in your team, and what that declaration requires
  • The severity or priority scale you use, with what each level means in hours
  • Where the glossary lives so a new joiner finds it in week one

  Template · team-glossary

Triage under volume: the benign twin problem, and why a severity rating is not evidence.

• ✓
  learnRequired

  Every real alert has a near-identical harmless twin

  Read the brief~2 min

  Triage is a volume problem disguised as an analysis problem. There is always a way to be right about a single alert given an hour; there is never an hour. What you are building is a disposition rule you can apply in ninety seconds and defend afterwards.

  Every real alert has a near-identical harmless twin

  This is the structural difficulty and it does not go away with better tooling. PowerShell downloading a file is an attack and a software deployment. A service account authenticating from a new host is lateral movement and a failover. The distinguishing detail is almost never in the alert — it is in what else that account did in the preceding ten minutes, and looking is what costs the time you do not have.

  • The severity field is the rule author's guess, made without your estate in front of them. Treat it as a hint about the rule, not as information about the event.
  • Batch the twins. If two alerts have the same shape, work out the distinguishing question once and write it down, rather than re-deriving it forty times.
  • Escalating everything is the same as escalating nothing, and it costs more, because it also spends the responder's willingness to believe you.
  • Closing an alert is a decision with your name on it. The habit worth building is a one-line reason, always — it takes eight seconds and it is the only thing that makes a queue reviewable.

  Watch your own drift

  Accuracy on the last ten alerts of a shift is usually worse than on the first ten, and almost nobody measures it. Fatigue moves you toward whichever disposition is cheapest — usually close — and the alert that mattered is as likely to arrive at hour seven as hour one.

  Carry this into the drill

  The Alert Queue runs forty alerts across twelve shapes, every real one paired with a benign twin whose severity rating does not help. At the end it reports the number nobody measures: your accuracy on the final ten against your first ten.

  Go deeper — with your own AICopy-paste prompt

  The brief above is the spine. This is a full study prompt for whichever assistant you already use — it carries your programme, this module and what the brief just covered, so the lesson comes back tailored rather than generic. Pick how you want it, edit anything, then copy.

  WrittenInfographicBoth

  You are an experienced control-risk practitioner and an exceptional teacher. Teach me one topic properly — the way a senior colleague would over a long coffee, not the way a textbook would. MY CONTEXT - Programme: Cyber Defence Analyst — a six-week applied programme (6 weeks, ~10h a week, self-paced). - Level: Practitioners rather than executives: detection and response analysts, incident responders, identity and platform engineers with a security remit, and GRC people who need to be credible with all of them. - Week 1 of 6: The queue, and the judgement it demands — Start where the work actually starts: a shared vocabulary, a queue longer than the shift, and the two decisions a defender makes hundreds of times a week — is this real, and does it go first. - Module 1.2: Forty alerts, one shift - Today's topic: Every real alert has a near-identical harmless twin - I am studying alone, applying this to my own organisation, and nothing I produce is graded. Assume I am a working professional, not a student: skip the motivational framing and the history lesson unless the history changes what I should do. WHAT I ALREADY HAVE (do not simply repeat this — go past it) - Every real alert has a near-identical harmless twin - The severity field is the rule author's guess, made without your estate in front of them. Treat it as a hint about the rule, not as information about the event. - Batch the twins. If two alerts have the same shape, work out the distinguishing question once and write it down, rather than re-deriving it forty times. - Escalating everything is the same as escalating nothing, and it costs more, because it also spends the responder's willingness to believe you. - Closing an alert is a decision with your name on it. The habit worth building is a one-line reason, always — it takes eight seconds and it is the only thing that makes a queue reviewable. - Watch your own drift - The point I am meant to carry into practice: The Alert Queue runs forty alerts across twelve shapes, every real one paired with a benign twin whose severity rating does not help. At the end it reports the number nobody measures: your accuracy on the final ten against your first ten. WHAT I WANT FROM YOU 1. The core idea in five sentences, in plain language, including the one distinction practitioners most often get wrong here. 2. Why it matters in practice: what actually goes wrong when this is done badly, with two realistic short scenarios — one financial services, one outside it. 3. The mechanics, step by step, at the level of detail I could follow at my desk tomorrow. Show the judgement calls, not just the procedure, and say what a good answer looks like versus a defensible-but-weak one. 4. At least one fully worked example with realistic specifics — names, numbers, evidence, dates. Show your reasoning as you go, including where you would push back on your own conclusion. 5. The five most common mistakes, each with the tell that gives it away and the correction. 6. How this connects to the rest of control risk: what it depends on upstream and what breaks downstream if I get it wrong. 7. What competent practitioners genuinely disagree about here, and how I should decide for my own context. 8. A short glossary of any term you use that a regulator, an auditor and a business owner would each define differently. 9. Six self-test questions that require judgement rather than recall — hold the answers back until I have attempted them, then mark my reasoning, not just my conclusion. OUTPUT FORMAT: written explanation. Long-form prose with headed sections, worked examples and tables where a table genuinely helps. No images. HOW TO WORK WITH ME - Ask me up to three questions about my sector, my organisation's size and my current maturity BEFORE you start, then tailor everything to my answers. - Prefer concrete specifics over hedged generalities. If something depends on context, say which context and why. - Flag anything that is genuinely contested, jurisdiction-specific or changing, and tell me what would make you change your answer. - If I have got something wrong in what I said I already know, correct me directly. - Do not invent standards, clause numbers, statistics or citations. If you are unsure of a reference, say so plainly instead. - After the lesson, quiz me the way this module's drill would (alert-queue): give me a situation, make me decide, then challenge the decision I make. - Finish by helping me plan my deliverable for this module: Triage playbook for your five most common alert shapes. Ask what my process is, then outline what mine should contain and what would make it weak.

  Copy promptYours to edit — changes stay in this box

• ✓
  playRequiredTicks itself

  The Alert Queue — 40 alerts, one analyst

  One shift, forty alerts, twelve shapes, and a benign twin for every real one. The closest thing available to the actual job, including the part where you get worse as the shift goes on.

  Open the drill

  Ticks itself when the drill records a result

• ✓
  applyRequired

  Triage playbook for your five most common alert shapes

  Open the brief

  Take your five most common alert shapes and write the disposition rule for each: the distinguishing question, where you look to answer it, and what you do in each branch.

  Each rule has to be executable in about ninety seconds by someone who is not you. If it needs your judgement to work, it is a note rather than a playbook.

  What to produce

  • Your five most common alert shapes, by volume over a real month
  • For each: the benign twin, described specifically
  • For each: the one question that separates them
  • For each: exactly where you look to answer it, named system by system
  • For each: the action in each branch, including who you contact
  • The time budget per shape, and whether it is honest
  • What you would need to automate the distinguishing lookup

  Template · triage-playbook
• ✓
  checkRequired

  Your accuracy on the last ten against your first ten

  Open the prompts

  1. What was your accuracy on the last ten against the first ten, and which disposition did you drift toward?
  2. Which alert shape do you spend the most total time on, and is that the same as the one that has ever mattered?
  3. How many of your closures in the last month carry a reason someone else could read?
  4. If you were off for two weeks, which of your five rules would break in your absence?

Exploitability, exposure and compensating controls — and a queue that never empties, which means every escalation is taken from something else.

• ✓
  learnRequired

  Severity is not priority

  Read the brief~2 min

  A remediation queue is a scarcity problem, and the scarce thing is other people's attention. Every escalation is taken from something else on the list, which means the honest question is never is this bad but is this worse than what it displaces.

  Severity is not priority

  A CVSS base score describes a vulnerability in the abstract. It knows nothing about whether the affected system is reachable, whether the exploit needs credentials you do not hand out, whether a public proof-of-concept exists, or whether something already stands in the way. Sorting the queue by that number is the single most common way a team ends up patching the 9.8 nobody can reach while the internet-facing 6.1 waits.

  • Reachability first. Who can touch this — the internet, the corporate network, an authenticated user, a local administrator?
  • Exploitability second. Is there working exploit code, and has anyone used it? Observed in the wild is the phrase that buys a maintenance window.
  • Compensating controls third, and honestly. A control compensates only if it operates at a precision that would actually catch this — monthly review against a daily exposure is a hope.
  • Findings with no score lose to findings with one. The domain admin account with a 2019 password has no CVE and will sit below a batch of mediums forever unless someone puts it there deliberately.

  Accepting is a real answer

  Some findings should be accepted, recorded, owned and given a review date. A queue that never accepts anything grows without limit and becomes a document nobody reads. The failure is not accepting; it is accepting silently, so that nobody can find the decision later or notice when the reasoning stops being true.

  Carry this into the drill

  Patch or Wait puts twelve findings in one finite queue and counts your over-escalation rate — the crit with no reachable path pulled out of cycle while the internet-facing medium with a public exploit waits its turn. Rate the Risk is the generic version of the same judgement if you want a second angle.

  Go deeper — with your own AICopy-paste prompt

  The brief above is the spine. This is a full study prompt for whichever assistant you already use — it carries your programme, this module and what the brief just covered, so the lesson comes back tailored rather than generic. Pick how you want it, edit anything, then copy.

  WrittenInfographicBoth

  You are an experienced control-risk practitioner and an exceptional teacher. Teach me one topic properly — the way a senior colleague would over a long coffee, not the way a textbook would. MY CONTEXT - Programme: Cyber Defence Analyst — a six-week applied programme (6 weeks, ~10h a week, self-paced). - Level: Practitioners rather than executives: detection and response analysts, incident responders, identity and platform engineers with a security remit, and GRC people who need to be credible with all of them. - Week 1 of 6: The queue, and the judgement it demands — Start where the work actually starts: a shared vocabulary, a queue longer than the shift, and the two decisions a defender makes hundreds of times a week — is this real, and does it go first. - Module 1.3: Deciding what to fix first - Today's topic: Severity is not priority - I am studying alone, applying this to my own organisation, and nothing I produce is graded. Assume I am a working professional, not a student: skip the motivational framing and the history lesson unless the history changes what I should do. WHAT I ALREADY HAVE (do not simply repeat this — go past it) - Severity is not priority - Reachability first. Who can touch this — the internet, the corporate network, an authenticated user, a local administrator? - Exploitability second. Is there working exploit code, and has anyone used it? Observed in the wild is the phrase that buys a maintenance window. - Compensating controls third, and honestly. A control compensates only if it operates at a precision that would actually catch this — monthly review against a daily exposure is a hope. - Findings with no score lose to findings with one. The domain admin account with a 2019 password has no CVE and will sit below a batch of mediums forever unless someone puts it there deliberately. - Accepting is a real answer - The point I am meant to carry into practice: Patch or Wait puts twelve findings in one finite queue and counts your over-escalation rate — the crit with no reachable path pulled out of cycle while the internet-facing medium with a public exploit waits its turn. Rate the Risk is the generic version of the same judgement if you want a second angle. WHAT I WANT FROM YOU 1. The core idea in five sentences, in plain language, including the one distinction practitioners most often get wrong here. 2. Why it matters in practice: what actually goes wrong when this is done badly, with two realistic short scenarios — one financial services, one outside it. 3. The mechanics, step by step, at the level of detail I could follow at my desk tomorrow. Show the judgement calls, not just the procedure, and say what a good answer looks like versus a defensible-but-weak one. 4. At least one fully worked example with realistic specifics — names, numbers, evidence, dates. Show your reasoning as you go, including where you would push back on your own conclusion. 5. The five most common mistakes, each with the tell that gives it away and the correction. 6. How this connects to the rest of control risk: what it depends on upstream and what breaks downstream if I get it wrong. 7. What competent practitioners genuinely disagree about here, and how I should decide for my own context. 8. A short glossary of any term you use that a regulator, an auditor and a business owner would each define differently. 9. Six self-test questions that require judgement rather than recall — hold the answers back until I have attempted them, then mark my reasoning, not just my conclusion. OUTPUT FORMAT: written explanation. Long-form prose with headed sections, worked examples and tables where a table genuinely helps. No images. HOW TO WORK WITH ME - Ask me up to three questions about my sector, my organisation's size and my current maturity BEFORE you start, then tailor everything to my answers. - Prefer concrete specifics over hedged generalities. If something depends on context, say which context and why. - Flag anything that is genuinely contested, jurisdiction-specific or changing, and tell me what would make you change your answer. - If I have got something wrong in what I said I already know, correct me directly. - Do not invent standards, clause numbers, statistics or citations. If you are unsure of a reference, say so plainly instead. - After the lesson, quiz me the way this module's drill would (patch-or-wait, sample-or-skip): give me a situation, make me decide, then challenge the decision I make. - Finish by helping me plan my deliverable for this module: Prioritised remediation list for one real scan output. Ask what my process is, then outline what mine should contain and what would make it weak.

  Copy promptYours to edit — changes stay in this box

• ✓
  playRequiredTicks itself

  Patch or Wait — a vulnerability triage drill

  Twelve findings and one queue: a 9.8 behind an authentication wall, a 6.1 that is internet-facing and weaponised, a container image that was never deployed. It counts over-escalation, because escalating everything is the failure that feels like diligence.

  Open the drill

  Ticks itself when the drill records a result

• ✓
  playOptionalTicks itself

  Rate the Risk

  Optional: residual-risk rating in the abstract, across areas rather than findings. Useful as a contrast — it is the general skill that vulnerability triage is a specific, harder case of.

  Open the drill

  Ticks itself when the drill records a result

• ✓
  applyRequired

  Prioritised remediation list for one real scan output

  Open the brief

  Take one real scan output — a page of it is enough — and re-order it by hand. For every item that moved, write the reason it moved.

  Then find the finding with no score at all. There is almost always one, it is almost always known to someone, and it is almost always not on the list.

  What to produce

  • The scan, its scope, and the order it arrived in
  • Your re-ordering, with the reason each item moved
  • For each of the top five: reachable by whom, exploitable how, and what already stands in the way
  • What you are accepting, with an owner and a review date against each
  • The findings with no CVSS that belong on this list, and where they came from
  • What the re-ordering displaced, named explicitly
  • The one thing you would automate to make this repeatable next month

  Template · remediation-queue

Identity graphs, group nesting, and the service account nobody owns.

• ✓
  learnRequired

  Disabling the breached account reduces the reach by nothing

  Read the brief~2 min

  Most intrusions are a legitimate credential doing legitimate things in an order nobody intended. That is why the perimeter stopped being a network boundary: the attacker is not breaking in through anything, they are signing in and then walking.

  Disabling the breached account reduces the reach by nothing

  The instinct when an account is phished is to disable it, and it is usually the wrong first move — not because it is harmful but because it is beside the point. A service-desk account with no admin rights of its own reaches everything it reaches through group nesting and a service account nobody owns. Disabling the entry point leaves the path intact for the next credential that lands on it.

  • Nesting compounds silently. A group added to a group added to a group grants rights nobody granted deliberately, and no single change in that chain looks wrong in isolation.
  • Service accounts are the usual bridge: over-privileged because it was quicker, never rotated because something depends on it, unowned because the person who created it left.
  • The question is not who is compromised but what is now reachable, and by what sequence.
  • Cutting three well-chosen edges usually reduces reach further than disabling thirty accounts, and it survives the next phishing email.

  Draw it before you need it

  Attack-path mapping is cheap and almost nobody does it while calm. An afternoon with the directory and one privileged group will tell you more about your real exposure than a quarter of vulnerability scanning, and the map does not go stale as fast as you would expect.

  Carry this into the drill

  Blast Radius walks a phished service-desk account through the identity graph and asks you to cut exactly three edges. Note how little disabling the breached account achieves — that result is the module in one number.

  Go deeper — with your own AICopy-paste prompt

  The brief above is the spine. This is a full study prompt for whichever assistant you already use — it carries your programme, this module and what the brief just covered, so the lesson comes back tailored rather than generic. Pick how you want it, edit anything, then copy.

  WrittenInfographicBoth

  You are an experienced control-risk practitioner and an exceptional teacher. Teach me one topic properly — the way a senior colleague would over a long coffee, not the way a textbook would. MY CONTEXT - Programme: Cyber Defence Analyst — a six-week applied programme (6 weeks, ~10h a week, self-paced). - Level: Practitioners rather than executives: detection and response analysts, incident responders, identity and platform engineers with a security remit, and GRC people who need to be credible with all of them. - Week 2 of 6: Identity, the real perimeter — Most intrusions are a legitimate credential doing legitimate things in an order nobody intended. Walk the path, cut the right edges, and get the fix actually made. - Module 2.1: Walking the path - Today's topic: Disabling the breached account reduces the reach by nothing - I am studying alone, applying this to my own organisation, and nothing I produce is graded. Assume I am a working professional, not a student: skip the motivational framing and the history lesson unless the history changes what I should do. WHAT I ALREADY HAVE (do not simply repeat this — go past it) - Disabling the breached account reduces the reach by nothing - Nesting compounds silently. A group added to a group added to a group grants rights nobody granted deliberately, and no single change in that chain looks wrong in isolation. - Service accounts are the usual bridge: over-privileged because it was quicker, never rotated because something depends on it, unowned because the person who created it left. - The question is not who is compromised but what is now reachable, and by what sequence. - Cutting three well-chosen edges usually reduces reach further than disabling thirty accounts, and it survives the next phishing email. - Draw it before you need it - The point I am meant to carry into practice: Blast Radius walks a phished service-desk account through the identity graph and asks you to cut exactly three edges. Note how little disabling the breached account achieves — that result is the module in one number. WHAT I WANT FROM YOU 1. The core idea in five sentences, in plain language, including the one distinction practitioners most often get wrong here. 2. Why it matters in practice: what actually goes wrong when this is done badly, with two realistic short scenarios — one financial services, one outside it. 3. The mechanics, step by step, at the level of detail I could follow at my desk tomorrow. Show the judgement calls, not just the procedure, and say what a good answer looks like versus a defensible-but-weak one. 4. At least one fully worked example with realistic specifics — names, numbers, evidence, dates. Show your reasoning as you go, including where you would push back on your own conclusion. 5. The five most common mistakes, each with the tell that gives it away and the correction. 6. How this connects to the rest of control risk: what it depends on upstream and what breaks downstream if I get it wrong. 7. What competent practitioners genuinely disagree about here, and how I should decide for my own context. 8. A short glossary of any term you use that a regulator, an auditor and a business owner would each define differently. 9. Six self-test questions that require judgement rather than recall — hold the answers back until I have attempted them, then mark my reasoning, not just my conclusion. OUTPUT FORMAT: written explanation. Long-form prose with headed sections, worked examples and tables where a table genuinely helps. No images. HOW TO WORK WITH ME - Ask me up to three questions about my sector, my organisation's size and my current maturity BEFORE you start, then tailor everything to my answers. - Prefer concrete specifics over hedged generalities. If something depends on context, say which context and why. - Flag anything that is genuinely contested, jurisdiction-specific or changing, and tell me what would make you change your answer. - If I have got something wrong in what I said I already know, correct me directly. - Do not invent standards, clause numbers, statistics or citations. If you are unsure of a reference, say so plainly instead. - After the lesson, quiz me the way this module's drill would (blast-radius): give me a situation, make me decide, then challenge the decision I make. - Finish by helping me plan my deliverable for this module: Attack-path sketch for one privileged group in your own directory. Ask what my process is, then outline what mine should contain and what would make it weak.

  Copy promptYours to edit — changes stay in this box

• ✓
  playRequiredTicks itself

  Blast Radius — an identity attack-path sim

  A phished account with no admin rights of its own, and the path it can actually take through the identity graph. Cut three edges, then see how much of the reach was built by group nesting and a service account nobody owns.

  Open the drill

  Ticks itself when the drill records a result

• ✓
  applyRequired

  Attack-path sketch for one privileged group in your own directory

  Open the brief

  Pick one privileged group in your own directory and sketch the path to it. Who is in it, who is in the groups that are in it, and which service accounts hold it.

  Then name the three edges you would cut. Include what would break if you cut them, because that is the reason they are still there.

  What to produce

  • The group, what it grants, and on which systems
  • Direct members, and nested members with the chain drawn out
  • Service accounts holding it, with their owner — or the honest admission that there is not one
  • The shortest path from an ordinary user account to this group
  • The three edges you would cut, in order
  • What breaks if you cut each, and who you would need to agree
  • What this map would look like if you re-drew it in three months

  Template · attack-path

Joiners, movers, leavers, and the entitlement review that rubber-stamps because its evidence could never be challenged.

• ✓
  learnRequired

  A review nobody could fail is a control that does not exist

  Read the brief~2 min

  Access accumulates. People move teams and keep what they had, projects end and their groups do not, contractors leave and their accounts are disabled but not their service principals. None of this is anyone's fault and all of it is somebody's problem, usually yours, usually during an incident.

  A review nobody could fail is a control that does not exist

  The quarterly entitlement review is the most widely performed and least effective control in the industry. A manager receives a list of names and group identifiers, has no way to know what any of them grant, and approves all of it in four minutes. The review happened, the evidence exists, and nothing was checked.

  • Give the reviewer meaning, not identifiers. What does this grant, who else has it, when did this person last use it?
  • Last-used data changes the conversation more than any other single field. Access unused for ninety days is a question that answers itself.
  • Reviewing everything quarterly guarantees a rubber stamp. Review the privileged tenth properly and the rest annually.
  • The evidence has to survive being challenged. An undated screenshot of a group membership proves nothing, and an export from a system nobody validated proves less than it appears to.

  Three answers, not two

  The failure mode of a review is rarely a wrong approval. It is an approval that could not have been anything else, because the row carried a group identifier and no description, no owner and no last-use data. Approve, revoke and re-scope all assume you can see enough to decide; the fourth answer — that the evidence does not reach the question — is the one that sends a review back rather than completing it, and it is the one nobody uses.

  Carry this into the drill

  Grant or Revoke runs twelve rows and counts how often you approved something you could not have judged. Rely or Reject is the optional companion — an audit drill, sharper on the narrower question of whether a single piece of evidence would survive being challenged at all.

  Go deeper — with your own AICopy-paste prompt

  The brief above is the spine. This is a full study prompt for whichever assistant you already use — it carries your programme, this module and what the brief just covered, so the lesson comes back tailored rather than generic. Pick how you want it, edit anything, then copy.

  WrittenInfographicBoth

  You are an experienced control-risk practitioner and an exceptional teacher. Teach me one topic properly — the way a senior colleague would over a long coffee, not the way a textbook would. MY CONTEXT - Programme: Cyber Defence Analyst — a six-week applied programme (6 weeks, ~10h a week, self-paced). - Level: Practitioners rather than executives: detection and response analysts, incident responders, identity and platform engineers with a security remit, and GRC people who need to be credible with all of them. - Week 2 of 6: Identity, the real perimeter — Most intrusions are a legitimate credential doing legitimate things in an order nobody intended. Walk the path, cut the right edges, and get the fix actually made. - Module 2.2: Access that expires - Today's topic: A review nobody could fail is a control that does not exist - I am studying alone, applying this to my own organisation, and nothing I produce is graded. Assume I am a working professional, not a student: skip the motivational framing and the history lesson unless the history changes what I should do. WHAT I ALREADY HAVE (do not simply repeat this — go past it) - A review nobody could fail is a control that does not exist - Give the reviewer meaning, not identifiers. What does this grant, who else has it, when did this person last use it? - Last-used data changes the conversation more than any other single field. Access unused for ninety days is a question that answers itself. - Reviewing everything quarterly guarantees a rubber stamp. Review the privileged tenth properly and the rest annually. - The evidence has to survive being challenged. An undated screenshot of a group membership proves nothing, and an export from a system nobody validated proves less than it appears to. - Three answers, not two - The point I am meant to carry into practice: Grant or Revoke runs twelve rows and counts how often you approved something you could not have judged. Rely or Reject is the optional companion — an audit drill, sharper on the narrower question of whether a single piece of evidence would survive being challenged at all. WHAT I WANT FROM YOU 1. The core idea in five sentences, in plain language, including the one distinction practitioners most often get wrong here. 2. Why it matters in practice: what actually goes wrong when this is done badly, with two realistic short scenarios — one financial services, one outside it. 3. The mechanics, step by step, at the level of detail I could follow at my desk tomorrow. Show the judgement calls, not just the procedure, and say what a good answer looks like versus a defensible-but-weak one. 4. At least one fully worked example with realistic specifics — names, numbers, evidence, dates. Show your reasoning as you go, including where you would push back on your own conclusion. 5. The five most common mistakes, each with the tell that gives it away and the correction. 6. How this connects to the rest of control risk: what it depends on upstream and what breaks downstream if I get it wrong. 7. What competent practitioners genuinely disagree about here, and how I should decide for my own context. 8. A short glossary of any term you use that a regulator, an auditor and a business owner would each define differently. 9. Six self-test questions that require judgement rather than recall — hold the answers back until I have attempted them, then mark my reasoning, not just my conclusion. OUTPUT FORMAT: written explanation. Long-form prose with headed sections, worked examples and tables where a table genuinely helps. No images. HOW TO WORK WITH ME - Ask me up to three questions about my sector, my organisation's size and my current maturity BEFORE you start, then tailor everything to my answers. - Prefer concrete specifics over hedged generalities. If something depends on context, say which context and why. - Flag anything that is genuinely contested, jurisdiction-specific or changing, and tell me what would make you change your answer. - If I have got something wrong in what I said I already know, correct me directly. - Do not invent standards, clause numbers, statistics or citations. If you are unsure of a reference, say so plainly instead. - After the lesson, quiz me the way this module's drill would (grant-or-revoke, rely-or-reject): give me a situation, make me decide, then challenge the decision I make. - Finish by helping me plan my deliverable for this module: Redesign one access review so its evidence would survive being questioned. Ask what my process is, then outline what mine should contain and what would make it weak.

  Copy promptYours to edit — changes stay in this box

• ✓
  playRequiredTicks itself

  Grant or Revoke — an access review drill

  Twelve rows from a review, where the third option — the evidence does not reach the question — is right more often than anyone uses it. It counts your rubber-stamp rate: how often a review produces evidence of a control operating while nothing was actually checked.

  Open the drill

  Ticks itself when the drill records a result

• ✓
  playOptionalTicks itself

  Rely or Reject — an evidence-reliability drill

  Optional, and openly a borrowing: eighteen pieces of evidence judged on provenance rather than format. The setting is audit, and it is the sharper instrument on one narrow question — whether the artefact in front of you could survive being challenged.

  Open the drill

  Ticks itself when the drill records a result

• ✓
  applyRequired

  Redesign one access review so its evidence would survive being questioned

  Open the brief

  Take one access review your organisation actually runs and redesign it so a reviewer could genuinely fail something.

  The test: would the evidence survive someone hostile asking how you know? Not a regulator — a colleague who thinks the review is theatre and wants to prove it.

  What to produce

  • The review as it runs today: scope, cadence, who reviews, what they see
  • What a reviewer currently cannot tell from the information given
  • The redesign: what each row shows, including last-used and what the access grants in plain words
  • The new scope and cadence — what is reviewed properly, what annually
  • The evidence produced, and its provenance: source system, date, who extracted it, whether the population was validated
  • The revocation path: what happens to a rejected line, and how you prove it happened
  • One row you expect the new review to catch that the old one passed

  Template · access-review
• ✓
  checkOptional

  What your last review actually proved

  Open the prompts

  1. Take your last completed access review. What did it actually prove?
  2. How long did the reviewer spend, and how many lines did they approve per minute?
  3. Which piece of your review evidence would you not want to defend, and why is it still the evidence?
  4. Who in your organisation has access they have not used in ninety days, and could you answer that today?

The finding nobody actions: severity language, the owner's incentives, and negotiating without spending credibility you will need later.

• ✓
  learnRequired

  A finding is a request, and requests can be written badly

  Read the brief~2 min

  Finding it is the easy half. The finding that sits open for eight months is not open because the owner is negligent — it is open because it arrived as a demand from a team with no authority over their roadmap, written in language that made the work sound larger than it is.

  A finding is a request, and requests can be written badly

  The version that gets actioned names the specific change, estimates the work honestly, says what happens if it waits, and gives the owner a way to agree without conceding that they were wrong. The version that sits open describes a category of risk in the passive voice and asks for remediation.

  • Severity inflation is the fastest way to stop being believed. If everything is critical, the owner sorts your findings by whichever is easiest, which is the opposite of what you wanted.
  • Know the owner's incentives. They are measured on delivery and uptime, and your fix is neither until you connect it to one.
  • Offer the smaller version. A partial fix that ships this sprint beats a complete one that never does, provided you record what remains.
  • Never win the argument at the owner's expense in front of their manager. You will need them next quarter, and they know it.

  Hold the position, not the tone

  There is a difference between conceding the finding and conceding the framing. You can accept a longer timeline, a smaller scope or a compensating control without accepting that the finding was wrong — and being pleasant about the first three is what buys you the credibility to be immovable on the fourth.

  Carry this into the drill

  Agree the Finding is an audit negotiation, and it is a borrowing — the setting is an audit finding put to a department head. The moves are the ones a security finding needs: every reply moves both your credibility and the room.

  Go deeper — with your own AICopy-paste prompt

  The brief above is the spine. This is a full study prompt for whichever assistant you already use — it carries your programme, this module and what the brief just covered, so the lesson comes back tailored rather than generic. Pick how you want it, edit anything, then copy.

  WrittenInfographicBoth

  You are an experienced control-risk practitioner and an exceptional teacher. Teach me one topic properly — the way a senior colleague would over a long coffee, not the way a textbook would. MY CONTEXT - Programme: Cyber Defence Analyst — a six-week applied programme (6 weeks, ~10h a week, self-paced). - Level: Practitioners rather than executives: detection and response analysts, incident responders, identity and platform engineers with a security remit, and GRC people who need to be credible with all of them. - Week 2 of 6: Identity, the real perimeter — Most intrusions are a legitimate credential doing legitimate things in an order nobody intended. Walk the path, cut the right edges, and get the fix actually made. - Module 2.3: Getting the fix actually made - Today's topic: A finding is a request, and requests can be written badly - I am studying alone, applying this to my own organisation, and nothing I produce is graded. Assume I am a working professional, not a student: skip the motivational framing and the history lesson unless the history changes what I should do. WHAT I ALREADY HAVE (do not simply repeat this — go past it) - A finding is a request, and requests can be written badly - Severity inflation is the fastest way to stop being believed. If everything is critical, the owner sorts your findings by whichever is easiest, which is the opposite of what you wanted. - Know the owner's incentives. They are measured on delivery and uptime, and your fix is neither until you connect it to one. - Offer the smaller version. A partial fix that ships this sprint beats a complete one that never does, provided you record what remains. - Never win the argument at the owner's expense in front of their manager. You will need them next quarter, and they know it. - Hold the position, not the tone - The point I am meant to carry into practice: Agree the Finding is an audit negotiation, and it is a borrowing — the setting is an audit finding put to a department head. The moves are the ones a security finding needs: every reply moves both your credibility and the room. WHAT I WANT FROM YOU 1. The core idea in five sentences, in plain language, including the one distinction practitioners most often get wrong here. 2. Why it matters in practice: what actually goes wrong when this is done badly, with two realistic short scenarios — one financial services, one outside it. 3. The mechanics, step by step, at the level of detail I could follow at my desk tomorrow. Show the judgement calls, not just the procedure, and say what a good answer looks like versus a defensible-but-weak one. 4. At least one fully worked example with realistic specifics — names, numbers, evidence, dates. Show your reasoning as you go, including where you would push back on your own conclusion. 5. The five most common mistakes, each with the tell that gives it away and the correction. 6. How this connects to the rest of control risk: what it depends on upstream and what breaks downstream if I get it wrong. 7. What competent practitioners genuinely disagree about here, and how I should decide for my own context. 8. A short glossary of any term you use that a regulator, an auditor and a business owner would each define differently. 9. Six self-test questions that require judgement rather than recall — hold the answers back until I have attempted them, then mark my reasoning, not just my conclusion. OUTPUT FORMAT: written explanation. Long-form prose with headed sections, worked examples and tables where a table genuinely helps. No images. HOW TO WORK WITH ME - Ask me up to three questions about my sector, my organisation's size and my current maturity BEFORE you start, then tailor everything to my answers. - Prefer concrete specifics over hedged generalities. If something depends on context, say which context and why. - Flag anything that is genuinely contested, jurisdiction-specific or changing, and tell me what would make you change your answer. - If I have got something wrong in what I said I already know, correct me directly. - Do not invent standards, clause numbers, statistics or citations. If you are unsure of a reference, say so plainly instead. - After the lesson, quiz me the way this module's drill would (agree-finding): give me a situation, make me decide, then challenge the decision I make. - Finish by helping me plan my deliverable for this module: Rewrite one stalled finding so its owner can act on it. Ask what my process is, then outline what mine should contain and what would make it weak.

  Copy promptYours to edit — changes stay in this box

• ✓
  playRequiredTicks itself

  Agree the Finding — an audit negotiation

  A finding presented to someone who pushes back, where every reply moves two meters at once. A borrowing from the audit catalogue — the setting is an audit engagement, the skill is exactly the one a security finding stalls for want of.

  Open the drill

  Ticks itself when the drill records a result

• ✓
  applyRequired

  Rewrite one stalled finding so its owner can act on it

  Open the brief

  Take one of your own findings that has been open too long and rewrite it so its owner can act on it.

  Then take it to them. The rewrite is the exercise; the conversation is the point, and it usually takes fifteen minutes.

  What to produce

  • The finding as originally written, quoted
  • How long it has been open, and what has happened to it
  • The owner, their objectives this quarter, and where your fix touches them
  • The rewrite: the specific change, the honest estimate, the consequence of waiting
  • The smaller version you would accept, and what would remain open
  • The compensating control you would accept instead, if any
  • What you will not concede, and the sentence you will use

  Template · finding-rewrite
• ✓
  checkOptional

  Why your last three findings stalled

  Open the prompts

  1. Why did your last three stalled findings stall? Be specific, and do not answer with the owner's attitude.
  2. In the negotiation, where did you lose credibility, and was it worth what you gained?
  3. What proportion of your findings are rated high or critical, and what does that proportion do to how they are read?
  4. Which owner in your organisation actions your findings fastest, and what is different about how you write to them?

Quarantine, escalate, release — and the false-positive rate as a budget you are spending on somebody's morning.

• ✓
  learnRequired

  Your false-positive rate is a tax on the whole company

  Read the brief~2 min

  Phishing triage is the highest-volume judgement in most security functions and the one most often treated as beneath attention. It is not: it is where a defender's calibration is trained, because you get feedback on hundreds of decisions a month and almost nobody looks at the aggregate.

  Your false-positive rate is a tax on the whole company

  Quarantining a legitimate invoice costs someone an afternoon and costs you a little of the goodwill that makes people report the next suspicious message. Releasing a real one costs considerably more. Both directions have a price, and the instinct to quarantine liberally because it feels safe is spending the budget that keeps your reporting channel alive.

  • Header analysis is fast and decisive far more often than practitioners expect. Authentication results, the true sending domain and the return path answer most of the queue.
  • The display name is worth nothing. It is attacker-controlled and it is what the recipient looked at.
  • Look at who else got it. A single recipient and a hundred are different situations, and the answer is one query away.
  • Release with a note beats release silently. If it comes back, the note is what makes the second look fast.

  Report the rate, not the count

  Most teams report messages quarantined, which measures effort. The number that means something is how often you were wrong in each direction, and publishing it — including when it moves the wrong way — is what turns a queue into a control someone can reason about.

  Carry this into the drill

  Phishing Triage: 60 Seconds gives you six inboxes and a clock, and reports your false-positive rate alongside your catch rate. The pairing is the point — a catch rate on its own can be bought by quarantining everything.

  Go deeper — with your own AICopy-paste prompt

  The brief above is the spine. This is a full study prompt for whichever assistant you already use — it carries your programme, this module and what the brief just covered, so the lesson comes back tailored rather than generic. Pick how you want it, edit anything, then copy.

  WrittenInfographicBoth

  You are an experienced control-risk practitioner and an exceptional teacher. Teach me one topic properly — the way a senior colleague would over a long coffee, not the way a textbook would. MY CONTEXT - Programme: Cyber Defence Analyst — a six-week applied programme (6 weeks, ~10h a week, self-paced). - Level: Practitioners rather than executives: detection and response analysts, incident responders, identity and platform engineers with a security remit, and GRC people who need to be credible with all of them. - Week 3 of 6: The inbox: phishing, BEC and an AI adversary — The highest-volume attack surface in every organisation, and the one where the decisive control is usually a process rather than a detection. - Module 3.1: Sixty seconds a message - Today's topic: Your false-positive rate is a tax on the whole company - I am studying alone, applying this to my own organisation, and nothing I produce is graded. Assume I am a working professional, not a student: skip the motivational framing and the history lesson unless the history changes what I should do. WHAT I ALREADY HAVE (do not simply repeat this — go past it) - Your false-positive rate is a tax on the whole company - Header analysis is fast and decisive far more often than practitioners expect. Authentication results, the true sending domain and the return path answer most of the queue. - The display name is worth nothing. It is attacker-controlled and it is what the recipient looked at. - Look at who else got it. A single recipient and a hundred are different situations, and the answer is one query away. - Release with a note beats release silently. If it comes back, the note is what makes the second look fast. - Report the rate, not the count - The point I am meant to carry into practice: Phishing Triage: 60 Seconds gives you six inboxes and a clock, and reports your false-positive rate alongside your catch rate. The pairing is the point — a catch rate on its own can be bought by quarantining everything. WHAT I WANT FROM YOU 1. The core idea in five sentences, in plain language, including the one distinction practitioners most often get wrong here. 2. Why it matters in practice: what actually goes wrong when this is done badly, with two realistic short scenarios — one financial services, one outside it. 3. The mechanics, step by step, at the level of detail I could follow at my desk tomorrow. Show the judgement calls, not just the procedure, and say what a good answer looks like versus a defensible-but-weak one. 4. At least one fully worked example with realistic specifics — names, numbers, evidence, dates. Show your reasoning as you go, including where you would push back on your own conclusion. 5. The five most common mistakes, each with the tell that gives it away and the correction. 6. How this connects to the rest of control risk: what it depends on upstream and what breaks downstream if I get it wrong. 7. What competent practitioners genuinely disagree about here, and how I should decide for my own context. 8. A short glossary of any term you use that a regulator, an auditor and a business owner would each define differently. 9. Six self-test questions that require judgement rather than recall — hold the answers back until I have attempted them, then mark my reasoning, not just my conclusion. OUTPUT FORMAT: written explanation. Long-form prose with headed sections, worked examples and tables where a table genuinely helps. No images. HOW TO WORK WITH ME - Ask me up to three questions about my sector, my organisation's size and my current maturity BEFORE you start, then tailor everything to my answers. - Prefer concrete specifics over hedged generalities. If something depends on context, say which context and why. - Flag anything that is genuinely contested, jurisdiction-specific or changing, and tell me what would make you change your answer. - If I have got something wrong in what I said I already know, correct me directly. - Do not invent standards, clause numbers, statistics or citations. If you are unsure of a reference, say so plainly instead. - After the lesson, quiz me the way this module's drill would (phishing-triage): give me a situation, make me decide, then challenge the decision I make. - Finish by helping me plan my deliverable for this module: Your own disposition rule set, with the false-positive budget stated. Ask what my process is, then outline what mine should contain and what would make it weak.

  Copy promptYours to edit — changes stay in this box

• ✓
  playRequiredTicks itself

  Phishing Triage: 60 Seconds

  Six inboxes, a ticking clock, and the false-positive rate reported next to the catch rate. The volume decision under the time pressure it actually carries.

  Open the drill

  Ticks itself when the drill records a result

• ✓
  applyRequired

  Your own disposition rule set, with the false-positive budget stated

  Open the brief

  Write your own disposition rule set: what you quarantine, what you escalate, what you release, and the checks that decide.

  State the false-positive budget explicitly — the rate above which you would change the rules rather than accept it. A budget nobody wrote down is a budget nobody is spending deliberately.

  What to produce

  • The checks you run, in order, with the time each takes
  • The quarantine criteria — specific, so someone else applies them the same way
  • The escalation criteria, and who receives it
  • The release criteria, and what note goes with it
  • Your false-positive budget as a rate, and what you do at the threshold
  • How the rate is measured and where it is published
  • The check you would add if you had another thirty seconds per message

  Template · disposition-rules

Business email compromise: out-of-band verification, and why process beats detection on this one.

• ✓
  learnRequired

  The message that is not malicious in any technical sense

  Read the brief~2 min

  Business email compromise is the attack that beats good security teams, because there is usually nothing to detect. No attachment, no link, no malware, sometimes not even a spoofed domain — just a real conversation, or a convincing imitation of one, asking for something reasonable at a moment when it would be reasonable.

  The message that is not malicious in any technical sense

  That is why the decisive control is a process rather than a detection. Out-of-band verification of any payment detail change, using a number from your own records rather than from the message, defeats the entire category — and it defeats it whether or not your filtering caught anything.

  • Timing is the tell more often than content. The request that arrives during the payment run, before a holiday, or while the approver is travelling is not a coincidence.
  • Urgency plus a change of channel is the signature: can you do this by end of day, and reply to me here rather than there.
  • A thread you were already in is the hardest version, and it is increasingly common. Compromise of a supplier's mailbox means the history is genuine and the last message is not.
  • Verify the change, not the message. The question is never is this email real, it is have these bank details changed, asked of a number you already had.

  Design for the person, not the analyst

  The control has to work for a finance clerk under deadline pressure who does not want to insult a supplier. That means it has to be quick, mandatory, and impossible to be embarrassed by — which is a design problem, not an awareness problem, and treating it as awareness is why so many organisations have trained everyone and changed nothing.

  Carry this into the drill

  Inbox Under Siege is the flagship: a working mail client, the hour before a payment run, eight messages, some written by an AI adversary. Notice what you trusted and why — the debrief is more useful than the score.

  Go deeper — with your own AICopy-paste prompt

  The brief above is the spine. This is a full study prompt for whichever assistant you already use — it carries your programme, this module and what the brief just covered, so the lesson comes back tailored rather than generic. Pick how you want it, edit anything, then copy.

  WrittenInfographicBoth

  You are an experienced control-risk practitioner and an exceptional teacher. Teach me one topic properly — the way a senior colleague would over a long coffee, not the way a textbook would. MY CONTEXT - Programme: Cyber Defence Analyst — a six-week applied programme (6 weeks, ~10h a week, self-paced). - Level: Practitioners rather than executives: detection and response analysts, incident responders, identity and platform engineers with a security remit, and GRC people who need to be credible with all of them. - Week 3 of 6: The inbox: phishing, BEC and an AI adversary — The highest-volume attack surface in every organisation, and the one where the decisive control is usually a process rather than a detection. - Module 3.2: The hour before the payment run - Today's topic: The message that is not malicious in any technical sense - I am studying alone, applying this to my own organisation, and nothing I produce is graded. Assume I am a working professional, not a student: skip the motivational framing and the history lesson unless the history changes what I should do. WHAT I ALREADY HAVE (do not simply repeat this — go past it) - The message that is not malicious in any technical sense - Timing is the tell more often than content. The request that arrives during the payment run, before a holiday, or while the approver is travelling is not a coincidence. - Urgency plus a change of channel is the signature: can you do this by end of day, and reply to me here rather than there. - A thread you were already in is the hardest version, and it is increasingly common. Compromise of a supplier's mailbox means the history is genuine and the last message is not. - Verify the change, not the message. The question is never is this email real, it is have these bank details changed, asked of a number you already had. - Design for the person, not the analyst - The point I am meant to carry into practice: Inbox Under Siege is the flagship: a working mail client, the hour before a payment run, eight messages, some written by an AI adversary. Notice what you trusted and why — the debrief is more useful than the score. WHAT I WANT FROM YOU 1. The core idea in five sentences, in plain language, including the one distinction practitioners most often get wrong here. 2. Why it matters in practice: what actually goes wrong when this is done badly, with two realistic short scenarios — one financial services, one outside it. 3. The mechanics, step by step, at the level of detail I could follow at my desk tomorrow. Show the judgement calls, not just the procedure, and say what a good answer looks like versus a defensible-but-weak one. 4. At least one fully worked example with realistic specifics — names, numbers, evidence, dates. Show your reasoning as you go, including where you would push back on your own conclusion. 5. The five most common mistakes, each with the tell that gives it away and the correction. 6. How this connects to the rest of control risk: what it depends on upstream and what breaks downstream if I get it wrong. 7. What competent practitioners genuinely disagree about here, and how I should decide for my own context. 8. A short glossary of any term you use that a regulator, an auditor and a business owner would each define differently. 9. Six self-test questions that require judgement rather than recall — hold the answers back until I have attempted them, then mark my reasoning, not just my conclusion. OUTPUT FORMAT: written explanation. Long-form prose with headed sections, worked examples and tables where a table genuinely helps. No images. HOW TO WORK WITH ME - Ask me up to three questions about my sector, my organisation's size and my current maturity BEFORE you start, then tailor everything to my answers. - Prefer concrete specifics over hedged generalities. If something depends on context, say which context and why. - Flag anything that is genuinely contested, jurisdiction-specific or changing, and tell me what would make you change your answer. - If I have got something wrong in what I said I already know, correct me directly. - Do not invent standards, clause numbers, statistics or citations. If you are unsure of a reference, say so plainly instead. - After the lesson, quiz me the way this module's drill would (inbox-under-siege): give me a situation, make me decide, then challenge the decision I make. - Finish by helping me plan my deliverable for this module: Payment-verification control design for one real payment path. Ask what my process is, then outline what mine should contain and what would make it weak.

  Copy promptYours to edit — changes stay in this box

• ✓
  playRequiredTicks itself

  Inbox Under Siege

  A working email client, the hour before a payment run, and eight messages of which some were written by an AI. Inspect, verify, decide what to trust — under the exact conditions where the process is the only control that works.

  Open the drill

  Ticks itself when the drill records a result

• ✓
  applyRequired

  Payment-verification control design for one real payment path

  Open the brief

  Design the verification control for one real payment path in your organisation. Follow the money: who can change bank details, on whose instruction, through which system.

  Then walk it with the person who actually does it. The gap between the documented process and their Tuesday is where the attack lands.

  What to produce

  • The payment path, end to end, with every person and system named
  • Who can change payment details, and what currently authorises that
  • The verification step: what is checked, against what source, by whom
  • Why the source cannot come from the requesting message
  • How long it takes, and how that fits a real deadline
  • The escalation when verification fails or cannot be completed
  • What the person doing it today does differently from the documented process

  Template · payment-verify
• ✓
  checkRequired

  What you trusted, and what made you trust it

  Open the prompts

  1. Which message did you trust, and what specifically made you trust it?
  2. In your own payment path, what would an attacker need to know to make the request look ordinary — and how much of it is public?
  3. Could someone in your finance team refuse a payment request from your CEO without feeling they were taking a risk?
  4. If a supplier's mailbox were compromised tomorrow, which of your controls would still work?

AI-assisted social engineering, and the failure modes of AI-assisted defence — which are the ones you own.

• ✓
  learnRequired

  Both sides now have the same writing tool

  Read the brief~2 min

  The language tell is gone. Spelling errors, awkward phrasing and cultural slips were never good indicators and they are now no indicator at all. Everything that made a phishing message look like a phishing message was a limitation of the attacker's tooling, and that limitation has been removed.

  Both sides now have the same writing tool

  Which is fine, because the durable indicators were never linguistic. Where did it come from, does the authentication pass, has this address ever written to us, is this request a change to something financial, and does the timing fit something the attacker could have known. None of that improves when the prose does.

  The failure modes you own

  The more interesting half is AI on YOUR side of the fence. A model summarising an alert, drafting a triage note or explaining a log line fails in four distinguishable ways, and each needs a different control. Treating them as one thing — the AI was wrong — produces no action anyone can take.

  • Fabrication: a plausible thing that does not exist. A CVE number in the right format for a vulnerability nobody filed.
  • Staleness: true once. Advice about a product version, an API or a regulation that has since moved.
  • Faulty reasoning: real inputs, invalid inference. The one that survives review, because every component checks out.
  • Should-have-declined: an answer where the honest response was that it could not know — which is most of what it is asked about your specific estate.

  Open the reading — Your AI Agents Are Employees Now. Audit Them Like It.

  Carry this into the drill

  Confidently Wrong makes you sort eight answers into those four modes. Do it before you write your rules of engagement — the categories are what turn a vague policy about checking outputs into a specific one.

  Go deeper — with your own AICopy-paste prompt

  The brief above is the spine. This is a full study prompt for whichever assistant you already use — it carries your programme, this module and what the brief just covered, so the lesson comes back tailored rather than generic. Pick how you want it, edit anything, then copy.

  WrittenInfographicBoth

  You are an experienced control-risk practitioner and an exceptional teacher. Teach me one topic properly — the way a senior colleague would over a long coffee, not the way a textbook would. MY CONTEXT - Programme: Cyber Defence Analyst — a six-week applied programme (6 weeks, ~10h a week, self-paced). - Level: Practitioners rather than executives: detection and response analysts, incident responders, identity and platform engineers with a security remit, and GRC people who need to be credible with all of them. - Week 3 of 6: The inbox: phishing, BEC and an AI adversary — The highest-volume attack surface in every organisation, and the one where the decisive control is usually a process rather than a detection. - Module 3.3: When the adversary writes better than you do - Today's topic: Both sides now have the same writing tool - I am studying alone, applying this to my own organisation, and nothing I produce is graded. Assume I am a working professional, not a student: skip the motivational framing and the history lesson unless the history changes what I should do. WHAT I ALREADY HAVE (do not simply repeat this — go past it) - Both sides now have the same writing tool - The failure modes you own - Fabrication: a plausible thing that does not exist. A CVE number in the right format for a vulnerability nobody filed. - Staleness: true once. Advice about a product version, an API or a regulation that has since moved. - Faulty reasoning: real inputs, invalid inference. The one that survives review, because every component checks out. - Should-have-declined: an answer where the honest response was that it could not know — which is most of what it is asked about your specific estate. - The point I am meant to carry into practice: Confidently Wrong makes you sort eight answers into those four modes. Do it before you write your rules of engagement — the categories are what turn a vague policy about checking outputs into a specific one. WHAT I WANT FROM YOU 1. The core idea in five sentences, in plain language, including the one distinction practitioners most often get wrong here. 2. Why it matters in practice: what actually goes wrong when this is done badly, with two realistic short scenarios — one financial services, one outside it. 3. The mechanics, step by step, at the level of detail I could follow at my desk tomorrow. Show the judgement calls, not just the procedure, and say what a good answer looks like versus a defensible-but-weak one. 4. At least one fully worked example with realistic specifics — names, numbers, evidence, dates. Show your reasoning as you go, including where you would push back on your own conclusion. 5. The five most common mistakes, each with the tell that gives it away and the correction. 6. How this connects to the rest of control risk: what it depends on upstream and what breaks downstream if I get it wrong. 7. What competent practitioners genuinely disagree about here, and how I should decide for my own context. 8. A short glossary of any term you use that a regulator, an auditor and a business owner would each define differently. 9. Six self-test questions that require judgement rather than recall — hold the answers back until I have attempted them, then mark my reasoning, not just my conclusion. OUTPUT FORMAT: written explanation. Long-form prose with headed sections, worked examples and tables where a table genuinely helps. No images. HOW TO WORK WITH ME - Ask me up to three questions about my sector, my organisation's size and my current maturity BEFORE you start, then tailor everything to my answers. - Prefer concrete specifics over hedged generalities. If something depends on context, say which context and why. - Flag anything that is genuinely contested, jurisdiction-specific or changing, and tell me what would make you change your answer. - If I have got something wrong in what I said I already know, correct me directly. - Do not invent standards, clause numbers, statistics or citations. If you are unsure of a reference, say so plainly instead. - After the lesson, quiz me the way this module's drill would (confidently-wrong, audit-prompt-lab): give me a situation, make me decide, then challenge the decision I make. - Finish by helping me plan my deliverable for this module: Rules of engagement for AI in your own triage workflow. Ask what my process is, then outline what mine should contain and what would make it weak.

  Copy promptYours to edit — changes stay in this box

• ✓
  playRequiredTicks itself

  Confidently Wrong — naming the AI failure mode

  Eight answers from a model that sounds equally sure of all of them, sorted into fabrication, staleness, faulty reasoning and should-have-declined. Each needs a different control, which is why the AI was wrong is not a finding anyone can act on.

  Open the drill

  Ticks itself when the drill records a result

• ✓
  playOptionalTicks itself

  The Prompt Lab — prompting for internal auditors

  Optional: seven real tasks with four candidate prompts each, where the tempting answer is the wrong one. Framed for internal audit, and the prompting judgement transfers directly to triage work.

  Open the drill

  Ticks itself when the drill records a result

• ✓
  applyRequired

  Rules of engagement for AI in your own triage workflow

  Open the brief

  Write the rules of engagement for AI use in your own triage workflow. What it may be used for, what it may never be used for, and what has to be verified before its output goes into a ticket.

  Tie each rule to a failure mode. A rule that does not name which of the four it addresses is a preference, and it will be ignored the first time it is inconvenient.

  What to produce

  • What AI is currently used for in your workflow, including the unofficial uses
  • Permitted uses, with the failure mode each carries
  • Prohibited uses, with the reason stated in one line each
  • The verification required before output reaches a ticket, per use
  • What must never be pasted into an external model, named specifically
  • How an AI-assisted conclusion is marked so a reader knows
  • Who reviews these rules, and what would trigger a change

  Template · ai-roe

Containment against preservation, and the decisions that cannot be unmade.

• ✓
  learnRequired

  Pulling the plug destroys the evidence you will need

  Read the brief~2 min

  It is almost always Friday, and that is not superstition. Attackers time encryption for when the fewest people are watching and the longest window exists before anyone with authority is reachable. Your runbook has to work with the people who are actually on shift at 9pm.

  Pulling the plug destroys the evidence you will need

  The instinct is to disconnect everything, and it trades away the thing that tells you how far this goes. Memory is lost, volatile artefacts are lost, and the question you will be asked all week — what did they take before they encrypted — becomes unanswerable. Isolate at the network layer where you can, capture before you kill, and record the order you did things in.

  • Containment and preservation both matter and they conflict. Decide the trade in advance rather than at 9pm, and write down which you chose.
  • Encryption is the last stage. By the time files change, the actor has usually been present for days and has taken what they wanted — which is why exfiltration is the question, not restoration.
  • Backups are a hypothesis until tested. Recovery time from an untested backup is unknown, and unknown is not a plan you can give anyone.
  • The first hour's log is worth more than anything you write later. Timestamps, decisions, who was told. Assign a scribe before you need one.

  Know who can authorise what

  The decisions that stall a first hour are almost never technical. Can we take this system down. Can we tell the customer. Can we call the insurer. If the answer to who authorises that is discovered live, you lose the hour that mattered most.

  Carry this into the drill

  Tabletop: Friday-Night Ransomware puts you in the incident commander's chair with branching decisions and a scored debrief. Watch where you traded preservation for speed, and whether you would defend that trade on Monday.

  Go deeper — with your own AICopy-paste prompt

  The brief above is the spine. This is a full study prompt for whichever assistant you already use — it carries your programme, this module and what the brief just covered, so the lesson comes back tailored rather than generic. Pick how you want it, edit anything, then copy.

  WrittenInfographicBoth

  You are an experienced control-risk practitioner and an exceptional teacher. Teach me one topic properly — the way a senior colleague would over a long coffee, not the way a textbook would. MY CONTEXT - Programme: Cyber Defence Analyst — a six-week applied programme (6 weeks, ~10h a week, self-paced). - Level: Practitioners rather than executives: detection and response analysts, incident responders, identity and platform engineers with a security remit, and GRC people who need to be credible with all of them. - Week 4 of 6: Ransomware and incident command — The first hour, the command structure that survives day four, and the clock the people upstairs are watching while you work. - Module 4.1: Friday night - Today's topic: Pulling the plug destroys the evidence you will need - I am studying alone, applying this to my own organisation, and nothing I produce is graded. Assume I am a working professional, not a student: skip the motivational framing and the history lesson unless the history changes what I should do. WHAT I ALREADY HAVE (do not simply repeat this — go past it) - Pulling the plug destroys the evidence you will need - Containment and preservation both matter and they conflict. Decide the trade in advance rather than at 9pm, and write down which you chose. - Encryption is the last stage. By the time files change, the actor has usually been present for days and has taken what they wanted — which is why exfiltration is the question, not restoration. - Backups are a hypothesis until tested. Recovery time from an untested backup is unknown, and unknown is not a plan you can give anyone. - The first hour's log is worth more than anything you write later. Timestamps, decisions, who was told. Assign a scribe before you need one. - Know who can authorise what - The point I am meant to carry into practice: Tabletop: Friday-Night Ransomware puts you in the incident commander's chair with branching decisions and a scored debrief. Watch where you traded preservation for speed, and whether you would defend that trade on Monday. WHAT I WANT FROM YOU 1. The core idea in five sentences, in plain language, including the one distinction practitioners most often get wrong here. 2. Why it matters in practice: what actually goes wrong when this is done badly, with two realistic short scenarios — one financial services, one outside it. 3. The mechanics, step by step, at the level of detail I could follow at my desk tomorrow. Show the judgement calls, not just the procedure, and say what a good answer looks like versus a defensible-but-weak one. 4. At least one fully worked example with realistic specifics — names, numbers, evidence, dates. Show your reasoning as you go, including where you would push back on your own conclusion. 5. The five most common mistakes, each with the tell that gives it away and the correction. 6. How this connects to the rest of control risk: what it depends on upstream and what breaks downstream if I get it wrong. 7. What competent practitioners genuinely disagree about here, and how I should decide for my own context. 8. A short glossary of any term you use that a regulator, an auditor and a business owner would each define differently. 9. Six self-test questions that require judgement rather than recall — hold the answers back until I have attempted them, then mark my reasoning, not just my conclusion. OUTPUT FORMAT: written explanation. Long-form prose with headed sections, worked examples and tables where a table genuinely helps. No images. HOW TO WORK WITH ME - Ask me up to three questions about my sector, my organisation's size and my current maturity BEFORE you start, then tailor everything to my answers. - Prefer concrete specifics over hedged generalities. If something depends on context, say which context and why. - Flag anything that is genuinely contested, jurisdiction-specific or changing, and tell me what would make you change your answer. - If I have got something wrong in what I said I already know, correct me directly. - Do not invent standards, clause numbers, statistics or citations. If you are unsure of a reference, say so plainly instead. - After the lesson, quiz me the way this module's drill would (ransomware-friday): give me a situation, make me decide, then challenge the decision I make. - Finish by helping me plan my deliverable for this module: First-hour runbook for your own environment: who, what, in what order. Ask what my process is, then outline what mine should contain and what would make it weak.

  Copy promptYours to edit — changes stay in this box

• ✓
  playRequiredTicks itself

  Tabletop: Friday-Night Ransomware

  You are the incident commander on a Friday night, with branching decisions, a nervous board and a debrief that scores your calls. The first hour, played at the speed the first hour actually moves.

  Open the drill

  Ticks itself when the drill records a result

• ✓
  applyRequired

  First-hour runbook for your own environment: who, what, in what order

  Open the brief

  Write the first-hour runbook for your own environment. Not a policy — an ordered list of actions with a name against each, usable by whoever is actually on shift at 9pm on a Friday.

  Include the authorisations. For every action that needs permission, name who can give it and how they are reached out of hours.

  What to produce

  • Trigger: what makes this a ransomware incident rather than an alert
  • The first ten actions in order, with a role against each
  • Where you isolate, and what you capture before you do
  • The preservation decision you have pre-made, and its reasoning
  • Authorisations: system shutdown, customer contact, insurer notification — who, and how reached at 9pm Friday
  • The scribe: who, and what they record
  • Out-of-band communications, on the assumption the estate is untrusted
  • The three things you would need to check about your backups before any of this is credible

  Template · first-hour

Incident command with a finite team, a regulator clock, and staff who have to still be functioning on day four.

• ✓
  learnRequired

  The commander who is also the best engineer is neither

  Read the brief~2 min

  A major incident is a resource-allocation problem wearing a technical costume. The team is finite, four things want it at once, and the constraint that surprises people is not skill or tooling — it is that humans stop being useful after about sixteen hours and an incident can run for two weeks.

  The commander who is also the best engineer is neither

  The most common failure in a first serious incident is the senior technical person taking command and then disappearing into the most interesting technical problem. Command is a separate job: holding the picture, allocating people, deciding what is not being done, and talking to the people who need to know. It is deliberately less interesting than the work.

  • Name the roles before the incident: commander, communications, scribe, technical lead. Four names, with alternates, on one card.
  • Rotate deliberately, on a schedule, starting before anyone is tired. A handover at hour eighteen because someone collapsed is a handover done badly.
  • Decide what is NOT being done and say it out loud. Silent deprioritisation is how the regulator notification gets missed while everyone works on recovery.
  • The regulator clock, the customer clock and the recovery clock run simultaneously and do not care about each other.

  Carry this into the drill

  The War Room moves a finite team across recovery, customers, the regulator clock and staff, round by round. The lesson is usually in the round where you left one of the four with nobody on it.

  Go deeper — with your own AICopy-paste prompt

  The brief above is the spine. This is a full study prompt for whichever assistant you already use — it carries your programme, this module and what the brief just covered, so the lesson comes back tailored rather than generic. Pick how you want it, edit anything, then copy.

  WrittenInfographicBoth

  You are an experienced control-risk practitioner and an exceptional teacher. Teach me one topic properly — the way a senior colleague would over a long coffee, not the way a textbook would. MY CONTEXT - Programme: Cyber Defence Analyst — a six-week applied programme (6 weeks, ~10h a week, self-paced). - Level: Practitioners rather than executives: detection and response analysts, incident responders, identity and platform engineers with a security remit, and GRC people who need to be credible with all of them. - Week 4 of 6: Ransomware and incident command — The first hour, the command structure that survives day four, and the clock the people upstairs are watching while you work. - Module 4.2: Taking command - Today's topic: The commander who is also the best engineer is neither - I am studying alone, applying this to my own organisation, and nothing I produce is graded. Assume I am a working professional, not a student: skip the motivational framing and the history lesson unless the history changes what I should do. WHAT I ALREADY HAVE (do not simply repeat this — go past it) - The commander who is also the best engineer is neither - Name the roles before the incident: commander, communications, scribe, technical lead. Four names, with alternates, on one card. - Rotate deliberately, on a schedule, starting before anyone is tired. A handover at hour eighteen because someone collapsed is a handover done badly. - Decide what is NOT being done and say it out loud. Silent deprioritisation is how the regulator notification gets missed while everyone works on recovery. - The regulator clock, the customer clock and the recovery clock run simultaneously and do not care about each other. - The point I am meant to carry into practice: The War Room moves a finite team across recovery, customers, the regulator clock and staff, round by round. The lesson is usually in the round where you left one of the four with nobody on it. WHAT I WANT FROM YOU 1. The core idea in five sentences, in plain language, including the one distinction practitioners most often get wrong here. 2. Why it matters in practice: what actually goes wrong when this is done badly, with two realistic short scenarios — one financial services, one outside it. 3. The mechanics, step by step, at the level of detail I could follow at my desk tomorrow. Show the judgement calls, not just the procedure, and say what a good answer looks like versus a defensible-but-weak one. 4. At least one fully worked example with realistic specifics — names, numbers, evidence, dates. Show your reasoning as you go, including where you would push back on your own conclusion. 5. The five most common mistakes, each with the tell that gives it away and the correction. 6. How this connects to the rest of control risk: what it depends on upstream and what breaks downstream if I get it wrong. 7. What competent practitioners genuinely disagree about here, and how I should decide for my own context. 8. A short glossary of any term you use that a regulator, an auditor and a business owner would each define differently. 9. Six self-test questions that require judgement rather than recall — hold the answers back until I have attempted them, then mark my reasoning, not just my conclusion. OUTPUT FORMAT: written explanation. Long-form prose with headed sections, worked examples and tables where a table genuinely helps. No images. HOW TO WORK WITH ME - Ask me up to three questions about my sector, my organisation's size and my current maturity BEFORE you start, then tailor everything to my answers. - Prefer concrete specifics over hedged generalities. If something depends on context, say which context and why. - Flag anything that is genuinely contested, jurisdiction-specific or changing, and tell me what would make you change your answer. - If I have got something wrong in what I said I already know, correct me directly. - Do not invent standards, clause numbers, statistics or citations. If you are unsure of a reference, say so plainly instead. - After the lesson, quiz me the way this module's drill would (war-room, breach-tabletop): give me a situation, make me decide, then challenge the decision I make. - Finish by helping me plan my deliverable for this module: IC role cards — commander, comms, scribe, technical lead — with real names in them. Ask what my process is, then outline what mine should contain and what would make it weak.

  Copy promptYours to edit — changes stay in this box

• ✓
  playRequiredTicks itself

  The War Room — an incident-command sim

  Command of a major outage with a finite team across recovery, customers, the regulator clock and staff endurance. It makes the allocation trade explicit, which is the part a technical responder has usually never had to make.

  Open the drill

  Ticks itself when the drill records a result

• ✓
  playOptionalTicks itself

  The Breach Room — a C-suite tabletop

  Optional: the same class of crisis from the board's side of the table. Worth an hour because it shows what the people you are escalating to are deciding, and why they keep asking the question you have already answered.

  Open the drill

  Ticks itself when the drill records a result

• ✓
  applyRequired

  IC role cards — commander, comms, scribe, technical lead — with real names in them

  Open the brief

  Build the incident command role cards for your organisation: commander, communications, scribe, technical lead, with real names and alternates.

  Each card says what that role decides, what it does not, and who it talks to. One side of paper, because it will be read under pressure by someone who has not read it before.

  What to produce

  • The four roles, with a primary and two alternates each
  • For each: the decisions it owns
  • For each: the decisions it explicitly does not own
  • For each: who it communicates with, and how often
  • The rotation schedule, and who calls it
  • How the roles are activated, and by whom
  • The out-of-hours contact route for every name on the card
  • What happens if the commander is unreachable

  Template · ic-roles

What material means to the people who have to file, and what a responder owes them and when.

• ✓
  learnRequired

  You do not make the materiality call; you start it

  Read the brief~2 min

  While you are working the incident, somebody upstairs is deciding whether it has to be disclosed, and they are deciding it on information you supply. Understanding what they need, and when, is part of the job — and getting it wrong looks like concealment even when it was only a responder being careful.

  You do not make the materiality call; you start it

  Materiality is a securities judgement, not a technical one, and it belongs to people with counsel in the room. What belongs to you is the trigger: the small set of facts that oblige you to tell them, whether or not you are confident, and whether or not the picture is complete.

  • Waiting for scope is the most common form of unreasonable delay. They can decide on partial facts; they cannot decide on facts they do not have.
  • Operational severity and materiality are different axes. A contained incident touching a small number of the wrong records can be material; a large outage may not be.
  • Several clocks start at once — securities disclosure, privacy notification, contract notice, sector regulators — and each has its own trigger and owner.
  • Everything you write during the incident is discoverable. Write facts with timestamps, mark inferences as inferences, and never speculate in a channel.

  Give them the five facts

  The useful escalation is short and factual: what we know, how we know it, what we do not know, what we are doing about that, and when you will next hear from us. That shape, repeated on a rhythm, is worth more than a comprehensive report that arrives after the decision was due.

  Carry this into the drill

  The Disclosure Window is a C-suite sim and it is a borrowing — you are playing the seat above yours. Play it for what the people receiving your escalation are actually deciding, and how much the timing of your information changes their options.

  Go deeper — with your own AICopy-paste prompt

  The brief above is the spine. This is a full study prompt for whichever assistant you already use — it carries your programme, this module and what the brief just covered, so the lesson comes back tailored rather than generic. Pick how you want it, edit anything, then copy.

  WrittenInfographicBoth

  You are an experienced control-risk practitioner and an exceptional teacher. Teach me one topic properly — the way a senior colleague would over a long coffee, not the way a textbook would. MY CONTEXT - Programme: Cyber Defence Analyst — a six-week applied programme (6 weeks, ~10h a week, self-paced). - Level: Practitioners rather than executives: detection and response analysts, incident responders, identity and platform engineers with a security remit, and GRC people who need to be credible with all of them. - Week 4 of 6: Ransomware and incident command — The first hour, the command structure that survives day four, and the clock the people upstairs are watching while you work. - Module 4.3: The clock upstairs - Today's topic: You do not make the materiality call; you start it - I am studying alone, applying this to my own organisation, and nothing I produce is graded. Assume I am a working professional, not a student: skip the motivational framing and the history lesson unless the history changes what I should do. WHAT I ALREADY HAVE (do not simply repeat this — go past it) - You do not make the materiality call; you start it - Waiting for scope is the most common form of unreasonable delay. They can decide on partial facts; they cannot decide on facts they do not have. - Operational severity and materiality are different axes. A contained incident touching a small number of the wrong records can be material; a large outage may not be. - Several clocks start at once — securities disclosure, privacy notification, contract notice, sector regulators — and each has its own trigger and owner. - Everything you write during the incident is discoverable. Write facts with timestamps, mark inferences as inferences, and never speculate in a channel. - Give them the five facts - The point I am meant to carry into practice: The Disclosure Window is a C-suite sim and it is a borrowing — you are playing the seat above yours. Play it for what the people receiving your escalation are actually deciding, and how much the timing of your information changes their options. WHAT I WANT FROM YOU 1. The core idea in five sentences, in plain language, including the one distinction practitioners most often get wrong here. 2. Why it matters in practice: what actually goes wrong when this is done badly, with two realistic short scenarios — one financial services, one outside it. 3. The mechanics, step by step, at the level of detail I could follow at my desk tomorrow. Show the judgement calls, not just the procedure, and say what a good answer looks like versus a defensible-but-weak one. 4. At least one fully worked example with realistic specifics — names, numbers, evidence, dates. Show your reasoning as you go, including where you would push back on your own conclusion. 5. The five most common mistakes, each with the tell that gives it away and the correction. 6. How this connects to the rest of control risk: what it depends on upstream and what breaks downstream if I get it wrong. 7. What competent practitioners genuinely disagree about here, and how I should decide for my own context. 8. A short glossary of any term you use that a regulator, an auditor and a business owner would each define differently. 9. Six self-test questions that require judgement rather than recall — hold the answers back until I have attempted them, then mark my reasoning, not just my conclusion. OUTPUT FORMAT: written explanation. Long-form prose with headed sections, worked examples and tables where a table genuinely helps. No images. HOW TO WORK WITH ME - Ask me up to three questions about my sector, my organisation's size and my current maturity BEFORE you start, then tailor everything to my answers. - Prefer concrete specifics over hedged generalities. If something depends on context, say which context and why. - Flag anything that is genuinely contested, jurisdiction-specific or changing, and tell me what would make you change your answer. - If I have got something wrong in what I said I already know, correct me directly. - Do not invent standards, clause numbers, statistics or citations. If you are unsure of a reference, say so plainly instead. - After the lesson, quiz me the way this module's drill would (disclosure-window): give me a situation, make me decide, then challenge the decision I make. - Finish by helping me plan my deliverable for this module: Escalation criteria: the five facts that trigger a materiality call. Ask what my process is, then outline what mine should contain and what would make it weak.

  Copy promptYours to edit — changes stay in this box

• ✓
  playRequiredTicks itself

  The Disclosure Window — SEC Item 1.05 simulation

  A borrowing by seat: this is the executive's sim, played from the responder's side. Twelve checkpoints across ninety-six hours, so you can see what your escalation does to the decision it feeds — and what silence does to it.

  Open the drill

  Ticks itself when the drill records a result

• ✓
  applyRequired

  Escalation criteria: the five facts that trigger a materiality call

  Open the brief

  Write the escalation criteria: the five facts that, once known, oblige you to tell the people who make the disclosure call.

  Then name the route. Who exactly, by what channel, within what period, and what you send if you cannot reach them.

  What to produce

  • The five triggering facts, written so they need no judgement to apply
  • Who is told, by name and role, and their alternate
  • The channel, and its out-of-band fallback
  • The period: how long after a trigger is known
  • The standing report shape: known, how known, unknown, doing, next update
  • The parallel clocks that also start, with their owners
  • What you do NOT put in writing, and where judgement calls are recorded instead

  Template · escalation-criteria
• ✓
  checkOptional

  Who upstairs learns first, and how

  Open the prompts

  1. In your organisation, who learns first, and is that the person who can start the disclosure clock?
  2. What is the longest plausible gap between your team knowing a triggering fact and the right person hearing it?
  3. Which of your incident channels would you be comfortable reading back in a deposition?
  4. Which parallel clock are you most likely to miss, and who owns it?

Control selection and defence in depth, and where money stops buying risk reduction.

• ✓
  learnRequired

  Depth is about independence, not about count

  Read the brief~2 min

  Every control set is a bet placed with somebody else's money about which attack arrives. The uncomfortable part is that you will be judged on the one that does, not on the portfolio — which is an argument for being able to explain the reasoning, not for spreading the money evenly.

  Depth is about independence, not about count

  Three controls that all depend on the same agent running on the same endpoint are one control with three names. Defence in depth means an attacker's single successful move does not disable the next layer — so the question for any proposed addition is what it shares a failure with, not what it detects.

  • Prevention that is easy to bypass and detection that nobody works are both zero. Budget the response capacity alongside the tool, or you have bought a licence.
  • The cheapest controls are usually configuration, not products: multi-factor authentication, tiered administration, removing local admin, blocking macro execution.
  • Ask what an attacker does INSTEAD once a control is in place. If the alternative path is cheap for them, you have moved the problem rather than reduced it.
  • Diminishing returns are real and arrive faster than vendors suggest. The fourth endpoint capability usually buys less than the first hour of log retention.

  Carry this into the drill

  Build & Defend has you spend a finite budget on a control set and then watch a real attack sequence test it. Note which of your purchases never came into play — that is the money the reasoning got wrong. Who Can See This is the optional check underneath the whole exercise: what your configuration already grants, before you buy anything.

  Go deeper — with your own AICopy-paste prompt

  The brief above is the spine. This is a full study prompt for whichever assistant you already use — it carries your programme, this module and what the brief just covered, so the lesson comes back tailored rather than generic. Pick how you want it, edit anything, then copy.

  WrittenInfographicBoth

  You are an experienced control-risk practitioner and an exceptional teacher. Teach me one topic properly — the way a senior colleague would over a long coffee, not the way a textbook would. MY CONTEXT - Programme: Cyber Defence Analyst — a six-week applied programme (6 weeks, ~10h a week, self-paced). - Level: Practitioners rather than executives: detection and response analysts, incident responders, identity and platform engineers with a security remit, and GRC people who need to be credible with all of them. - Week 5 of 6: Build and defend — From responding to designing: a finite budget, a stack with gaps in it, and a supply chain you do not control. - Module 5.1: Spending a finite budget - Today's topic: Depth is about independence, not about count - I am studying alone, applying this to my own organisation, and nothing I produce is graded. Assume I am a working professional, not a student: skip the motivational framing and the history lesson unless the history changes what I should do. WHAT I ALREADY HAVE (do not simply repeat this — go past it) - Depth is about independence, not about count - Prevention that is easy to bypass and detection that nobody works are both zero. Budget the response capacity alongside the tool, or you have bought a licence. - The cheapest controls are usually configuration, not products: multi-factor authentication, tiered administration, removing local admin, blocking macro execution. - Ask what an attacker does INSTEAD once a control is in place. If the alternative path is cheap for them, you have moved the problem rather than reduced it. - Diminishing returns are real and arrive faster than vendors suggest. The fourth endpoint capability usually buys less than the first hour of log retention. - The point I am meant to carry into practice: Build & Defend has you spend a finite budget on a control set and then watch a real attack sequence test it. Note which of your purchases never came into play — that is the money the reasoning got wrong. Who Can See This is the optional check underneath the whole exercise: what your configuration already grants, before you buy anything. WHAT I WANT FROM YOU 1. The core idea in five sentences, in plain language, including the one distinction practitioners most often get wrong here. 2. Why it matters in practice: what actually goes wrong when this is done badly, with two realistic short scenarios — one financial services, one outside it. 3. The mechanics, step by step, at the level of detail I could follow at my desk tomorrow. Show the judgement calls, not just the procedure, and say what a good answer looks like versus a defensible-but-weak one. 4. At least one fully worked example with realistic specifics — names, numbers, evidence, dates. Show your reasoning as you go, including where you would push back on your own conclusion. 5. The five most common mistakes, each with the tell that gives it away and the correction. 6. How this connects to the rest of control risk: what it depends on upstream and what breaks downstream if I get it wrong. 7. What competent practitioners genuinely disagree about here, and how I should decide for my own context. 8. A short glossary of any term you use that a regulator, an auditor and a business owner would each define differently. 9. Six self-test questions that require judgement rather than recall — hold the answers back until I have attempted them, then mark my reasoning, not just my conclusion. OUTPUT FORMAT: written explanation. Long-form prose with headed sections, worked examples and tables where a table genuinely helps. No images. HOW TO WORK WITH ME - Ask me up to three questions about my sector, my organisation's size and my current maturity BEFORE you start, then tailor everything to my answers. - Prefer concrete specifics over hedged generalities. If something depends on context, say which context and why. - Flag anything that is genuinely contested, jurisdiction-specific or changing, and tell me what would make you change your answer. - If I have got something wrong in what I said I already know, correct me directly. - Do not invent standards, clause numbers, statistics or citations. If you are unsure of a reference, say so plainly instead. - After the lesson, quiz me the way this module's drill would (build-defend, who-can-see-this): give me a situation, make me decide, then challenge the decision I make. - Finish by helping me plan my deliverable for this module: Control-set proposal for one system, with the trade-offs written down. Ask what my process is, then outline what mine should contain and what would make it weak.

  Copy promptYours to edit — changes stay in this box

• ✓
  playRequiredTicks itself

  Build & Defend — design a control set, then get attacked

  Spend a finite budget on the controls you choose, then watch an attack sequence test the design. Shared with the control-risk programme, which used it for control design in the abstract; here it is the native version of the same exercise.

  Open the drill

  Ticks itself when the drill records a result

• ✓
  playOptionalTicks itself

  Who Can See This — a cloud exposure drill

  Optional: twelve cloud and SaaS configurations, and one question each — who can actually reach this. Worth doing before you propose a control set, because a budget spent on detection while a default sharing setting is doing the exposing is a budget spent in the wrong place.

  Open the drill

  Ticks itself when the drill records a result

• ✓
  applyRequired

  Control-set proposal for one system, with the trade-offs written down

  Open the brief

  Write the control-set proposal for one system you actually own or support. A budget, a set, and the trade-offs written down.

  The section that matters is what you chose not to buy and why. That is the part that makes the proposal defensible in a year, when something gets through.

  What to produce

  • The system, what it holds or does, and who would want it
  • The attack paths you are defending against, in order of likelihood
  • The control set proposed, with cost against each
  • For each control: what it shares a failure mode with
  • The response capacity assumed — who works what this generates
  • What you chose not to buy, and the reasoning
  • What an attacker would do instead, given this set
  • The one addition you would make if the budget rose ten per cent

  Template · control-set

Stack composition, and the channels a formation leaves open.

• ✓
  learnRequired

  Your coverage map is a map of what you can see

  Read the brief~2 min

  Coverage maps lie by omission. They show what your tools observe, laid out as though that were the territory — and the channels nobody instrumented do not appear as gaps, they simply do not appear.

  Your coverage map is a map of what you can see

  The useful exercise is inverted: start from the attack techniques rather than from the tools, and mark which ones you would find out about, by what signal, and how quickly. The answers cluster — most estates are dense on endpoint and thin on identity, or dense on perimeter and blind to anything east-west.

  • Formation matters more than individual quality. A strong endpoint capability with no identity telemetry leaves an entire class of intrusion invisible.
  • Coverage without retention is not coverage. Finding it in the logs matters only while the logs exist.
  • Alerting on a signal is not the same as collecting it. Plenty of estates hold the evidence and have no rule that looks at it — which is recoverable in an investigation and useless in prevention.
  • Name the channels you have deliberately left uncovered. An undocumented gap becomes a surprise; a documented one becomes a budget conversation.

  Carry this into the drill

  Starting XI has you choose a formation and fill eleven places from a transfer budget, then watch the attack play down the pitch. The channels that get breached are the ones your formation left open, which is the whole argument in one image.

  Go deeper — with your own AICopy-paste prompt

  The brief above is the spine. This is a full study prompt for whichever assistant you already use — it carries your programme, this module and what the brief just covered, so the lesson comes back tailored rather than generic. Pick how you want it, edit anything, then copy.

  WrittenInfographicBoth

  You are an experienced control-risk practitioner and an exceptional teacher. Teach me one topic properly — the way a senior colleague would over a long coffee, not the way a textbook would. MY CONTEXT - Programme: Cyber Defence Analyst — a six-week applied programme (6 weeks, ~10h a week, self-paced). - Level: Practitioners rather than executives: detection and response analysts, incident responders, identity and platform engineers with a security remit, and GRC people who need to be credible with all of them. - Week 5 of 6: Build and defend — From responding to designing: a finite budget, a stack with gaps in it, and a supply chain you do not control. - Module 5.2: Picking the line-up - Today's topic: Your coverage map is a map of what you can see - I am studying alone, applying this to my own organisation, and nothing I produce is graded. Assume I am a working professional, not a student: skip the motivational framing and the history lesson unless the history changes what I should do. WHAT I ALREADY HAVE (do not simply repeat this — go past it) - Your coverage map is a map of what you can see - Formation matters more than individual quality. A strong endpoint capability with no identity telemetry leaves an entire class of intrusion invisible. - Coverage without retention is not coverage. Finding it in the logs matters only while the logs exist. - Alerting on a signal is not the same as collecting it. Plenty of estates hold the evidence and have no rule that looks at it — which is recoverable in an investigation and useless in prevention. - Name the channels you have deliberately left uncovered. An undocumented gap becomes a surprise; a documented one becomes a budget conversation. - The point I am meant to carry into practice: Starting XI has you choose a formation and fill eleven places from a transfer budget, then watch the attack play down the pitch. The channels that get breached are the ones your formation left open, which is the whole argument in one image. WHAT I WANT FROM YOU 1. The core idea in five sentences, in plain language, including the one distinction practitioners most often get wrong here. 2. Why it matters in practice: what actually goes wrong when this is done badly, with two realistic short scenarios — one financial services, one outside it. 3. The mechanics, step by step, at the level of detail I could follow at my desk tomorrow. Show the judgement calls, not just the procedure, and say what a good answer looks like versus a defensible-but-weak one. 4. At least one fully worked example with realistic specifics — names, numbers, evidence, dates. Show your reasoning as you go, including where you would push back on your own conclusion. 5. The five most common mistakes, each with the tell that gives it away and the correction. 6. How this connects to the rest of control risk: what it depends on upstream and what breaks downstream if I get it wrong. 7. What competent practitioners genuinely disagree about here, and how I should decide for my own context. 8. A short glossary of any term you use that a regulator, an auditor and a business owner would each define differently. 9. Six self-test questions that require judgement rather than recall — hold the answers back until I have attempted them, then mark my reasoning, not just my conclusion. OUTPUT FORMAT: written explanation. Long-form prose with headed sections, worked examples and tables where a table genuinely helps. No images. HOW TO WORK WITH ME - Ask me up to three questions about my sector, my organisation's size and my current maturity BEFORE you start, then tailor everything to my answers. - Prefer concrete specifics over hedged generalities. If something depends on context, say which context and why. - Flag anything that is genuinely contested, jurisdiction-specific or changing, and tell me what would make you change your answer. - If I have got something wrong in what I said I already know, correct me directly. - Do not invent standards, clause numbers, statistics or citations. If you are unsure of a reference, say so plainly instead. - After the lesson, quiz me the way this module's drill would (starting-xi): give me a situation, make me decide, then challenge the decision I make. - Finish by helping me plan my deliverable for this module: Coverage map of your own stack against what it does not watch. Ask what my process is, then outline what mine should contain and what would make it weak.

  Copy promptYours to edit — changes stay in this box

• ✓
  playRequiredTicks itself

  Starting XI — pick your cyber line-up

  Your security stack as a team sheet: pick a formation, fill the eleven from a budget, then watch which channels the attack comes down. A fast way to see that composition beats individual quality.

  Open the drill

  Ticks itself when the drill records a result

• ✓
  applyRequired

  Coverage map of your own stack against what it does not watch

  Open the brief

  Map your own stack against what it does not watch. Work from techniques inward rather than from tools outward, or you will produce a diagram of your purchase history.

  For each gap, note whether you would find out later from logs, or not at all. Those are very different gaps and they cost different amounts to close.

  What to produce

  • The techniques you consider realistic for your organisation
  • For each: would you detect it, by what signal, and how quickly
  • For each: if not detected, would you find it afterwards in logs
  • Retention against each signal, honestly
  • Signals you collect but have no rule for
  • The gaps you are accepting deliberately, with the reason
  • The single cheapest change that closes the most gaps

  Template · coverage-map

Supply chain, fourth parties, concentration and exit.

• ✓
  learnRequired

  Their incident is your incident, on their timetable

  Read the brief~2 min

  Most of your attack surface is now operated by someone else. Their patching, their identity hygiene, their incident response, their subcontractors — and your ability to influence any of it was mostly fixed at contract signature, by people who were not thinking about this.

  Their incident is your incident, on their timetable

  When a supplier is compromised you learn late, from a notification written by their counsel, and you act on information you cannot verify. What determines how badly that goes is preparation done long before: knowing what they hold, what they connect to, and how you would cut them off.

  • Tier by what they touch, not by what you pay them. The cheapest vendor with a persistent connection into your estate outranks the expensive one that sends invoices.
  • Fourth parties are where the concentration hides. Several independent-looking suppliers frequently sit on the same underlying platform.
  • Ask how you would find out. A supplier with no notification obligation and no contact route is one you learn about from the news.
  • Exit is a control. A vendor you could not leave inside six months is a dependency, and dependencies get repriced at the worst moment.

  The technical half of a governance programme

  Third-party risk is usually run as a questionnaire exercise, and the questionnaire is not the useful part. The useful part is technical and it is yours: what connectivity exists, what credentials they hold, what data flows, and what happens to all three when the relationship ends.

  Carry this into the drill

  The third-party self-assessment covers eight domains including concentration, exit and the fourth-party chain. Run it against your own estate rather than answering it as a supplier would — the gaps you find are the ones the questionnaire never asks.

  Go deeper — with your own AICopy-paste prompt

  The brief above is the spine. This is a full study prompt for whichever assistant you already use — it carries your programme, this module and what the brief just covered, so the lesson comes back tailored rather than generic. Pick how you want it, edit anything, then copy.

  WrittenInfographicBoth

  You are an experienced control-risk practitioner and an exceptional teacher. Teach me one topic properly — the way a senior colleague would over a long coffee, not the way a textbook would. MY CONTEXT - Programme: Cyber Defence Analyst — a six-week applied programme (6 weeks, ~10h a week, self-paced). - Level: Practitioners rather than executives: detection and response analysts, incident responders, identity and platform engineers with a security remit, and GRC people who need to be credible with all of them. - Week 5 of 6: Build and defend — From responding to designing: a finite budget, a stack with gaps in it, and a supply chain you do not control. - Module 5.3: The chain you do not control - Today's topic: Their incident is your incident, on their timetable - I am studying alone, applying this to my own organisation, and nothing I produce is graded. Assume I am a working professional, not a student: skip the motivational framing and the history lesson unless the history changes what I should do. WHAT I ALREADY HAVE (do not simply repeat this — go past it) - Their incident is your incident, on their timetable - Tier by what they touch, not by what you pay them. The cheapest vendor with a persistent connection into your estate outranks the expensive one that sends invoices. - Fourth parties are where the concentration hides. Several independent-looking suppliers frequently sit on the same underlying platform. - Ask how you would find out. A supplier with no notification obligation and no contact route is one you learn about from the news. - Exit is a control. A vendor you could not leave inside six months is a dependency, and dependencies get repriced at the worst moment. - The technical half of a governance programme - The point I am meant to carry into practice: The third-party self-assessment covers eight domains including concentration, exit and the fourth-party chain. Run it against your own estate rather than answering it as a supplier would — the gaps you find are the ones the questionnaire never asks. WHAT I WANT FROM YOU 1. The core idea in five sentences, in plain language, including the one distinction practitioners most often get wrong here. 2. Why it matters in practice: what actually goes wrong when this is done badly, with two realistic short scenarios — one financial services, one outside it. 3. The mechanics, step by step, at the level of detail I could follow at my desk tomorrow. Show the judgement calls, not just the procedure, and say what a good answer looks like versus a defensible-but-weak one. 4. At least one fully worked example with realistic specifics — names, numbers, evidence, dates. Show your reasoning as you go, including where you would push back on your own conclusion. 5. The five most common mistakes, each with the tell that gives it away and the correction. 6. How this connects to the rest of control risk: what it depends on upstream and what breaks downstream if I get it wrong. 7. What competent practitioners genuinely disagree about here, and how I should decide for my own context. 8. A short glossary of any term you use that a regulator, an auditor and a business owner would each define differently. 9. Six self-test questions that require judgement rather than recall — hold the answers back until I have attempted them, then mark my reasoning, not just my conclusion. OUTPUT FORMAT: written explanation. Long-form prose with headed sections, worked examples and tables where a table genuinely helps. No images. HOW TO WORK WITH ME - Ask me up to three questions about my sector, my organisation's size and my current maturity BEFORE you start, then tailor everything to my answers. - Prefer concrete specifics over hedged generalities. If something depends on context, say which context and why. - Flag anything that is genuinely contested, jurisdiction-specific or changing, and tell me what would make you change your answer. - If I have got something wrong in what I said I already know, correct me directly. - Do not invent standards, clause numbers, statistics or citations. If you are unsure of a reference, say so plainly instead. - After the lesson, quiz me the way this module's drill would (third-party-risk): give me a situation, make me decide, then challenge the decision I make. - Finish by helping me plan my deliverable for this module: Tiering and monitoring plan for your top ten technology vendors. Ask what my process is, then outline what mine should contain and what would make it weak.

  Copy promptYours to edit — changes stay in this box

• ✓
  playRequiredTicks itself

  How ready is your data privacy function?

  A structured pass across the eight domains of a managed third-party programme. Shared with two other programmes, which read it as governance; here it is the technical inventory of who is inside your estate and how you would remove them.

  Open the drill

  Ticks itself when the drill records a result

• ✓
  applyRequired

  Tiering and monitoring plan for your top ten technology vendors

  Open the brief

  Build the tiering and monitoring plan for your top ten technology vendors — top by access, not by spend.

  For each, answer the question that decides everything: how would you find out they had been compromised, and how fast could you cut them off?

  What to produce

  • The ten vendors, ranked by what they touch
  • For each: connectivity, credentials held, data flowing
  • For each: their notification obligation and your named contact
  • For each: how you would isolate them, and how long it takes
  • Fourth-party concentration: which of the ten sit on shared infrastructure
  • What you monitor on an ongoing basis, and what you only check at onboarding
  • The exit position for the top three

  Template · vendor-plan
• ✓
  checkRequired

  The vendor you could not exit

  Open the prompts

  1. Which vendor could you not exit inside six months, and what would that cost you in a renegotiation?
  2. For your top three, how would you actually learn they had been breached?
  3. Which supplier holds credentials into your estate that nobody has reviewed this year?
  4. How many of your ten sit on the same underlying platform, and did you know before you looked?

DORA and the shift from best-effort resilience to a regulated one, with testing that has to prove something.

• ✓
  learnRequired

  Best effort stopped being a defence

  Read the brief~2 min

  Resilience used to be a maturity conversation — something you improved when there was budget, argued for with anecdotes about other people's outages. In regulated sectors it is now an obligation with named requirements, evidence expectations and a reporting clock, which changes who you are talking to and what counts as done.

  Best effort stopped being a defence

  The shift that matters for a practitioner is evidential. It is no longer enough for the recovery plan to exist and the team to believe in it; the requirement is testing that would have revealed a failure, with a record of what was tested, what broke and what changed as a result. A test that everything passes is a test that was designed to be passed.

  • Know your critical functions, in the business's language rather than by system name. The obligation attaches to what the organisation does for customers, not to your asset inventory.
  • Recovery objectives are commitments, and an untested one is a guess. Measure the actual time, once, and use that number.
  • Third-party ICT risk is inside the perimeter of these regimes. Your supplier's resilience is now your reportable problem.
  • Incident reporting timelines are short and they start at classification. If nobody owns classifying, the clock runs while everyone works.

  Where a defender adds most

  In making the testing real. The gap between a documented recovery plan and an executed one is where every resilience programme actually fails, and the person who can run the restore and report the honest number is worth more to the programme than the person who writes the policy.

  Carry this into the drill

  The DORA readiness scan covers governance, ICT risk, incident reporting, resilience testing and third-party risk. Run it against your own estate honestly — the value is the gap list, not the score.

  Go deeper — with your own AICopy-paste prompt

  The brief above is the spine. This is a full study prompt for whichever assistant you already use — it carries your programme, this module and what the brief just covered, so the lesson comes back tailored rather than generic. Pick how you want it, edit anything, then copy.

  WrittenInfographicBoth

  You are an experienced control-risk practitioner and an exceptional teacher. Teach me one topic properly — the way a senior colleague would over a long coffee, not the way a textbook would. MY CONTEXT - Programme: Cyber Defence Analyst — a six-week applied programme (6 weeks, ~10h a week, self-paced). - Level: Practitioners rather than executives: detection and response analysts, incident responders, identity and platform engineers with a security remit, and GRC people who need to be credible with all of them. - Week 6 of 6: Resilience, detection engineering and the close — Resilience as a regulated obligation, the detections that decide what you ever find out about, and a defence review that puts the whole programme against one real system. - Module 6.1: Resilience as an obligation - Today's topic: Best effort stopped being a defence - I am studying alone, applying this to my own organisation, and nothing I produce is graded. Assume I am a working professional, not a student: skip the motivational framing and the history lesson unless the history changes what I should do. WHAT I ALREADY HAVE (do not simply repeat this — go past it) - Best effort stopped being a defence - Know your critical functions, in the business's language rather than by system name. The obligation attaches to what the organisation does for customers, not to your asset inventory. - Recovery objectives are commitments, and an untested one is a guess. Measure the actual time, once, and use that number. - Third-party ICT risk is inside the perimeter of these regimes. Your supplier's resilience is now your reportable problem. - Incident reporting timelines are short and they start at classification. If nobody owns classifying, the clock runs while everyone works. - Where a defender adds most - The point I am meant to carry into practice: The DORA readiness scan covers governance, ICT risk, incident reporting, resilience testing and third-party risk. Run it against your own estate honestly — the value is the gap list, not the score. WHAT I WANT FROM YOU 1. The core idea in five sentences, in plain language, including the one distinction practitioners most often get wrong here. 2. Why it matters in practice: what actually goes wrong when this is done badly, with two realistic short scenarios — one financial services, one outside it. 3. The mechanics, step by step, at the level of detail I could follow at my desk tomorrow. Show the judgement calls, not just the procedure, and say what a good answer looks like versus a defensible-but-weak one. 4. At least one fully worked example with realistic specifics — names, numbers, evidence, dates. Show your reasoning as you go, including where you would push back on your own conclusion. 5. The five most common mistakes, each with the tell that gives it away and the correction. 6. How this connects to the rest of control risk: what it depends on upstream and what breaks downstream if I get it wrong. 7. What competent practitioners genuinely disagree about here, and how I should decide for my own context. 8. A short glossary of any term you use that a regulator, an auditor and a business owner would each define differently. 9. Six self-test questions that require judgement rather than recall — hold the answers back until I have attempted them, then mark my reasoning, not just my conclusion. OUTPUT FORMAT: written explanation. Long-form prose with headed sections, worked examples and tables where a table genuinely helps. No images. HOW TO WORK WITH ME - Ask me up to three questions about my sector, my organisation's size and my current maturity BEFORE you start, then tailor everything to my answers. - Prefer concrete specifics over hedged generalities. If something depends on context, say which context and why. - Flag anything that is genuinely contested, jurisdiction-specific or changing, and tell me what would make you change your answer. - If I have got something wrong in what I said I already know, correct me directly. - Do not invent standards, clause numbers, statistics or citations. If you are unsure of a reference, say so plainly instead. - After the lesson, quiz me the way this module's drill would (dora-ready): give me a situation, make me decide, then challenge the decision I make. - Finish by helping me plan my deliverable for this module: Gap list against the eight domains, with named owners. Ask what my process is, then outline what mine should contain and what would make it weak.

  Copy promptYours to edit — changes stay in this box

• ✓
  playRequiredTicks itself

  Are You Actually DORA-Ready?

  A structured scan across the eight domains of DORA readiness. It is written as a self-assessment, which suits the module: the output you want is a gap list you can put owners against, not a grade.

  Open the drill

  Ticks itself when the drill records a result

• ✓
  applyRequired

  Gap list against the eight domains, with named owners

  Open the brief

  Turn the scan into a gap list with a named owner and a date against every line.

  Add one test you could actually run this quarter that would reveal a failure rather than confirm a belief. Name what you expect to break.

  What to produce

  • Your critical functions, named in business terms
  • The systems each depends on, including third parties
  • Recovery objectives against each, and whether the number was measured or assumed
  • The gap list from the scan, with owner and date per line
  • Who classifies an incident for reporting purposes, and how fast
  • The one test you will run this quarter, and what you expect to break
  • What evidence that test will produce, and where it will live

  Template · dora-gaps

Brittle, noisy, or watching the wrong thing — the three ways a rule fails while being carried as coverage — and the metrics that would have told you.

• ✓
  learnRequired

  A rule that matches today's sample and nothing else

  Read the brief~2 min

  Everything in week one was about consuming detections. This is about writing them, which is a different skill and the one that determines what you ever find out about. A queue can only be as good as the rules feeding it, and most rules are written once, by whoever noticed the problem, and never revisited.

  A rule that matches today's sample and nothing else

  The characteristic failure is brittleness: keying on the artefact you happened to see rather than the behaviour it is an instance of. A rule for procdump.exe accessing lsass is evaded by a rename, which is the first thing anyone does. The durable version describes the behaviour — a handle opened on lsass with read rights by a process outside the expected set — and the tool name stops mattering.

  • Brittle: one attacker change evades it. Ask what you would change if you were them, then check whether the rule survives it.
  • Noisy: it fires so often the queue mutes it. A rule producing four thousand events a day is not coverage, it is a filter someone will disable in a week.
  • Wrong signal: no amount of tuning helps, because the event being watched is not where the behaviour shows. Scheduled task creation is the classic — the signal is in the task's content.
  • Some behaviours have no benign twin at all — clearing the security log, deleting shadow copies. Those rules ship as written, and they are the cheapest coverage you will ever get.

  The numbers that would have told you

  Time to detect and time to respond are the ones that get reported; detection coverage against a technique framework and per-rule false-positive rate are the ones that change decisions. A rule with a hundred per cent false-positive rate over six months is not a rule, and nobody notices unless someone measures per-rule.

  Carry this into the drill

  Ship or Tune puts twelve proposed detections in front of you and counts how often you shipped one as written that needed widening or narrowing. Take the four-way judgement into the Apply step — ship, widen, narrow, rewrite.

  Go deeper — with your own AICopy-paste prompt

  The brief above is the spine. This is a full study prompt for whichever assistant you already use — it carries your programme, this module and what the brief just covered, so the lesson comes back tailored rather than generic. Pick how you want it, edit anything, then copy.

  WrittenInfographicBoth

  You are an experienced control-risk practitioner and an exceptional teacher. Teach me one topic properly — the way a senior colleague would over a long coffee, not the way a textbook would. MY CONTEXT - Programme: Cyber Defence Analyst — a six-week applied programme (6 weeks, ~10h a week, self-paced). - Level: Practitioners rather than executives: detection and response analysts, incident responders, identity and platform engineers with a security remit, and GRC people who need to be credible with all of them. - Week 6 of 6: Resilience, detection engineering and the close — Resilience as a regulated obligation, the detections that decide what you ever find out about, and a defence review that puts the whole programme against one real system. - Module 6.2: Writing the detection, and proving it works - Today's topic: A rule that matches today's sample and nothing else - I am studying alone, applying this to my own organisation, and nothing I produce is graded. Assume I am a working professional, not a student: skip the motivational framing and the history lesson unless the history changes what I should do. WHAT I ALREADY HAVE (do not simply repeat this — go past it) - A rule that matches today's sample and nothing else - Brittle: one attacker change evades it. Ask what you would change if you were them, then check whether the rule survives it. - Noisy: it fires so often the queue mutes it. A rule producing four thousand events a day is not coverage, it is a filter someone will disable in a week. - Wrong signal: no amount of tuning helps, because the event being watched is not where the behaviour shows. Scheduled task creation is the classic — the signal is in the task's content. - Some behaviours have no benign twin at all — clearing the security log, deleting shadow copies. Those rules ship as written, and they are the cheapest coverage you will ever get. - The numbers that would have told you - The point I am meant to carry into practice: Ship or Tune puts twelve proposed detections in front of you and counts how often you shipped one as written that needed widening or narrowing. Take the four-way judgement into the Apply step — ship, widen, narrow, rewrite. WHAT I WANT FROM YOU 1. The core idea in five sentences, in plain language, including the one distinction practitioners most often get wrong here. 2. Why it matters in practice: what actually goes wrong when this is done badly, with two realistic short scenarios — one financial services, one outside it. 3. The mechanics, step by step, at the level of detail I could follow at my desk tomorrow. Show the judgement calls, not just the procedure, and say what a good answer looks like versus a defensible-but-weak one. 4. At least one fully worked example with realistic specifics — names, numbers, evidence, dates. Show your reasoning as you go, including where you would push back on your own conclusion. 5. The five most common mistakes, each with the tell that gives it away and the correction. 6. How this connects to the rest of control risk: what it depends on upstream and what breaks downstream if I get it wrong. 7. What competent practitioners genuinely disagree about here, and how I should decide for my own context. 8. A short glossary of any term you use that a regulator, an auditor and a business owner would each define differently. 9. Six self-test questions that require judgement rather than recall — hold the answers back until I have attempted them, then mark my reasoning, not just my conclusion. OUTPUT FORMAT: written explanation. Long-form prose with headed sections, worked examples and tables where a table genuinely helps. No images. HOW TO WORK WITH ME - Ask me up to three questions about my sector, my organisation's size and my current maturity BEFORE you start, then tailor everything to my answers. - Prefer concrete specifics over hedged generalities. If something depends on context, say which context and why. - Flag anything that is genuinely contested, jurisdiction-specific or changing, and tell me what would make you change your answer. - If I have got something wrong in what I said I already know, correct me directly. - Do not invent standards, clause numbers, statistics or citations. If you are unsure of a reference, say so plainly instead. - After the lesson, quiz me the way this module's drill would (ship-or-tune, road-to-the-final): give me a situation, make me decide, then challenge the decision I make. - Finish by helping me plan my deliverable for this module: Three detections for one behaviour in your own estate, with their evasions named. Ask what my process is, then outline what mine should contain and what would make it weak.

  Copy promptYours to edit — changes stay in this box

• ✓
  playRequiredTicks itself

  Ship or Tune — a detection-writing drill

  Twelve proposed detections and one call on each: ship it, widen it, narrow it, or rewrite it because it is watching the wrong thing. It counts how often you waved one through, which is the failure that shows up on a coverage report as success.

  Open the drill

  Ticks itself when the drill records a result

• ✓
  playOptionalTicks itself

  Road to the Final — a knockout tournament

  Optional, and a good last exercise: a knockout across cyber, audit, AI governance, resilience and privacy, where every tie is a decision under pressure. After six weeks in one discipline it is worth being asked something from the four next door.

  Open the drill

  Ticks itself when the drill records a result

• ✓
  applyRequired

  Three detections for one behaviour in your own estate, with their evasions named

  Open the brief

  Pick one behaviour you care about in your own estate and write three detections for it at different points on the path — early and noisy, mid and specific, late and certain.

  For each, name the evasion. If you cannot describe how an attacker sidesteps it, you have not finished thinking about it and it will be the rule that was green on the coverage report.

  What to produce

  • The behaviour, described independently of any tool or artefact
  • The three detections, with the signal each uses
  • For each: the evasion, described specifically
  • For each: the expected volume, and who works it
  • For each: what a true positive looks like in the queue, so the analyst knows
  • The test cases: three that should fire, three that should not
  • How you would know in six months whether the rule was still working

  Template · detection-set

One system, reviewed end to end with everything the programme built, and a plan for what you do next.

• ✓
  applyRequired

  Capstone: a defence review of one system end to end

  Open the brief

  Take one real system and review its defence end to end. Everything the programme built feeds this: the triage playbook, the remediation queue, the attack-path sketch, the access review, the verification control, the first-hour runbook, the IC role cards, the escalation criteria, the control-set proposal, the coverage map, the vendor plan, the DORA gaps and the detections.

  The work is reconciliation, not repetition. Your artefacts will disagree — the coverage map will claim a signal the detections do not use, the runbook will assume an authorisation the role cards do not grant. Finding those is the exercise.

  Finish with one page for the executive who would have to disclose an incident on this system. If they cannot understand the exposure without the appendices, it is not finished.

  What to produce

  • The system, what it holds or does, and who would want it
  • Attack paths in, ranked, with the identity paths drawn
  • Detections covering each path, with the gaps named
  • The response plan: first hour, command roles, escalation triggers
  • Third-party exposure and what happens when the supplier is the incident
  • Resilience: recovery objectives, tested or assumed, and the honest number
  • Where two of your own artefacts contradicted each other, and which was wrong
  • The prioritised list of what you would fix, with what it displaces
  • One page for the executive: the exposure, the three things that matter, the decision you are asking for

  Template · capstone
• ✓
  playOptionalTicks itself

  How ready is your data privacy function?

  Optional. Score your own organisation against the six CSF Functions — including Govern, which is where most programmes are thinnest.

  Open the drill

  Ticks itself when the drill records a result

• ✓
  checkRequired

  Reflection and personal development plan

  Open the prompts

  1. Which of your six weeks' artefacts turned out to be load-bearing for the capstone, and which have you not opened since you wrote them?
  2. Where did two of your own artefacts contradict each other, and which one was wrong?
  3. What did you find you could not do — an access, a skill, a relationship — and what is the smallest next step toward it?
  4. Which of the two counted mistakes was yours: over-escalating in the queue, or shipping a rule as written? What does that tell you about where you are cautious and where you are quick?
  5. Six months from now, what evidence would show this programme changed how something was defended?