Signify Insights
Profile
Signify Insights
DiscoverSignify PlaygroundSignify FieldworkSignify LabsSignify KidsSpotlightsAboutSignify SolutionSignify HiveSignify Impact
Signify Fieldwork · Control Risk Analyst
A publishing & interactive-learning property · Philadelphia · est. 2019
Profile

FIELDWORK · SIX WEEKS · SELF-PACED

Control Risk Analyst — a six-week applied programme

Intermediate practitioners moving toward advanced control-risk capability: design, RCSA, testing, residual risk, continuous monitoring, AI controls, board communication.

The platform hosts the spine — briefs, drills, sims, templates, progress — and structures the deep work. It does not host sixty hours of content. Plan roughly ten focused hours a week. Most of it is real work at your own desk; Signify Fieldwork keeps the thread.

6 weeks~10h a week18 modules49 required steps22 drills

Progress0 of 49 required stepsSaving to this browser

Week 1 of 6 · 10.5 hours · 3 modules

Frameworks, taxonomy and control craft

Move from knowing frameworks to applying them surgically: choose what a framework is actually for, classify controls honestly, and write control statements a tester could execute without asking you what you meant.

1.1

Frameworks and governance context

3.5h

How COSO Internal Control, COSO ERM, ISO 31000/31010 and the lines-of-defence model actually interact, where they create value and where they create bureaucracy, and what a risk appetite statement has to say to drive a decision.

  • learnRequired

    Frameworks as instruments, not doctrine

    Read the brief~2 min

    COSO Internal Control, COSO ERM, ISO 31000 and its 31010 toolbox, and the three-lines model are usually taught as rival doctrines. In practice they are instruments, and an instrument is judged by what it measures. COSO Internal Control is an assurance instrument: it asks whether the organization can rely on its reporting, its compliance, its operations. COSO ERM is a strategy instrument: it asks whether risk is being taken deliberately, in the amounts the board intended. ISO 31000 is a process instrument: it describes a repeatable way to identify, analyse and treat risk in any domain, and 31010 is its catalogue of techniques. The three-lines model is an accountability instrument: it says who owns risk, who oversees it, and who checks the checking.

    Friction appears where the instruments overlap. The classic case is a control catalogue built for assurance being asked to carry strategy conversations it was never designed for, or an ERM register so abstract that no control could ever be linked to it. Neither document is wrong; each is being read with the wrong question. Your job as an analyst is to know, for every artefact in front of you, which instrument produced it and which question it can therefore answer.

    Risk appetite that drives a decision

    A risk appetite statement earns its place when someone can point to a decision it changed. "We have low appetite for compliance risk" changes nothing, because nobody was proposing to have a high one. "We will not launch a customer-facing model without a named owner and a rollback path" changes launch plans. The test is always the same: could a reasonable person, holding this statement, decline something concrete? If not, it is wallpaper.

    • COSO IC answers: can we rely on it? COSO ERM answers: are we taking the risk we meant to take?
    • ISO 31000 answers: is the process sound and repeatable? Three lines answers: who owns, who oversees, who assures?
    • Every framework creates bureaucracy the moment it is applied to a question it was not built for.
    • Appetite statements are tested by the decisions they could decline, not by the sentiment they express.

    Watch the edge cases, because they are where doctrine snaps. In an agile or DevOps environment the control points move from documents to pipelines, and a framework applied literally will demand sign-offs the workflow cannot host. In a multi-entity group, or mid-transformation, two frameworks may be live at once and the linkage between them is your problem, not the frameworks'. The skill is surgical application: take the component you need, apply it to the process in front of you, and be able to say why the rest was left in the box.

    Carry this into the drill

    The drill scores how a GRC programme is actually run — ownership, cadence, evidence, tooling. As you answer, notice which framework each question is silently leaning on.

    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.

    Yours to edit — changes stay in this box

  • playRequiredTicks itself

    GRC Maturity Assessment

    A structured pass over how a real GRC programme is run — the fastest way to see frameworks as operating choices rather than posters.

    Open the drill

    Ticks itself when the drill records a result

  • applyRequired

    Annotated framework application notes for one process

    Open the brief

    Choose one process you know well — procure-to-pay, user-access provisioning, month-end close, vendor onboarding. Place it inside each framework in turn and write down what each one asks of it, where they agree, and where they pull in different directions. This is the note set a practitioner keeps, not a report for a committee: short, specific, honest about gaps.

    Aim for two to four pages. The value is in the conflicts column — a process that maps cleanly into every framework has usually been described too vaguely to test.

    What to produce

    • The process, in one paragraph: purpose, systems, volumes, who runs it
    • COSO IC view — which components and principles it touches, and the objective (reporting, operations, compliance) at stake
    • ERM / appetite view — the enterprise risk it rolls up to, and what appetite implies for how tightly it must be controlled
    • ISO 31000/31010 view — which analysis techniques fit this process
    • Three-lines view — who is first line here, who oversees, who assures
    • Conflicts and gaps — where the frameworks disagree or fall silent
    • Keep / leave list — which framework elements you would actually use
    Template · framework-notes
  • checkOptional

    Where your own organisation's framework is load-bearing and where it is decoration

    Open the prompts
    1. Where in your own organization is a framework genuinely load-bearing — remove it and something visible fails?
    2. Where is it decoration — present in documents, absent from decisions?
    3. Name one decision in the last year that an appetite statement actually changed. If you cannot, what would the statement need to say to have changed one?
    4. Which framework conflict from your notes would you raise first, and with whom?
1.2

Control taxonomy and effectiveness

3h

Classify controls rigorously — preventive, detective, corrective; manual, automated, ITGC, application; entity- versus process-level — and hold the line between design effectiveness and operating effectiveness.

  • learnRequired

    Two different questions: is it built right, and did it run

    Read the brief~2 min

    Every control conversation eventually collapses into two questions, and rigour means keeping them apart. Is it built right — would this control, operated exactly as designed, actually address the risk? And did it run — was it performed, every time, by the person, at the frequency, with the evidence the design promises? Design effectiveness and operating effectiveness fail differently, are tested differently, and are fixed differently. A beautifully designed control that nobody performs and a faithfully performed control that never addressed the risk both produce the same bad outcome by different roads.

    The axes of the taxonomy

    Classification is not filing; it is prediction. Knowing a control is preventive tells you it modifies likelihood; detective, that it modifies impact by shortening the time a failure lives; corrective, that it limits damage once found. Knowing it is manual tells you its failure mode is human — fatigue, turnover, judgement drift. Automated, that its failure mode is change — a configuration edit, a migration, a silent job failure. ITGCs sit underneath application controls: when access management or change management fails, every automated control above it becomes suspect at once. Entity-level controls set the climate; process-level controls do the work.

    • Preventive lowers likelihood; detective and corrective lower impact — score them against the term they actually modify.
    • Manual controls fail through people; automated controls fail through change. Test each where it fails.
    • An ITGC failure is never local: it undermines every application control that depends on it.
    • Redundancy shows up as several controls claiming the same risk with the same mechanism — one is real, the rest are fatigue.

    Two early-warning signs are worth memorising. Control fatigue: the same reviewer signing forty reconciliations a month is not performing forty controls, they are performing one habit. Over-engineering: three controls addressing one risk through the same mechanism add cost without adding assurance — a rationalizing eye removes two and strengthens one. Both signs are invisible in a list and obvious in a taxonomy, which is the whole argument for having one.

    Carry this into the drill

    Build & Defend puts you on the design side of this lesson: a budget, a risk set, and the question of which control types earn their cost. Play the first run for design; the attack sequence comes back in module 1.4.

    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.

    Yours to edit — changes stay in this box

  • playRequiredTicks itself

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

    Designing a control set under a budget forces the taxonomy to do real work — every choice is a bet on where the risk actually lives.

    first run — design under budget

    Open the drill

    Ticks itself when the drill records a result

  • playOptionalTicks itself

    Term Match — a terminology memory game

    Ten minutes of vocabulary under time pressure — cheap fluency in the terms the rest of the programme assumes.

    vocabulary warm-up

    Open the drill

    Ticks itself when the drill records a result

  • applyRequired

    Taxonomy reference sheet for a sample process

    Open the brief

    Take the process from module 1.1 and classify every control you can identify in it along each axis: preventive / detective / corrective, manual / automated / ITGC / application, entity- versus process-level, key versus non-key. Then add the column that makes it a reference sheet rather than an inventory: what each control's classification predicts about how it fails and how it should be tested.

    Where you cannot classify a control, say so — an unclassifiable control is usually an unwritten one, and that is a finding, not a formatting problem.

    What to produce

    • Control list for the chosen process (aim for the real population, not a sample)
    • Classification per control across all four axes
    • Predicted failure mode per control, one line each
    • Implied test approach per control, one line each
    • Flags — redundancy candidates, fatigue risks, unclassifiable items
    Template · taxonomy-sheet
1.3

Process mapping and control-statement craft

4h

Produce auditable process maps and narratives, then write control statements that pin down who, what, when, how, evidence, frequency and owner. The documentation pitfalls in this module are the ones that create false assurance.

  • learnRequired

    A statement nobody can test is worse than no statement

    Read the brief~2 min

    A control statement is a testable claim, and everything about how it is written either helps or obstructs the test. "Management reviews the reconciliation" cannot be tested: which manager, which reconciliation, reviewed for what, how often, and what trace does the review leave? The craft is pinning down seven things without mercy: who performs it, what they do, when and how often, how they do it, what evidence it leaves, what triggers escalation, and who owns it when it breaks. A statement that answers all seven can be walked through, tested, and defended. A statement that answers four produces false assurance — the most expensive product a control environment can make.

    Narratives and maps that can be audited

    The process narrative exists so that a stranger can find the control. Write it as the work actually happens — systems named, handoffs explicit, volumes and timing real — and place each control at the exact point in the flow where it operates. The walkthrough is the narrative's test: take one transaction end to end and watch whether reality matches the document. Where it diverges, the narrative is wrong, and every control statement hanging off it inherits the error.

    • Seven anchors: who, what, when/frequency, how, evidence, escalation, owner. Missing anchors are where testing dies.
    • Write narratives from the transaction's point of view, not the org chart's.
    • The most dangerous pitfall is the aspirational statement — describing the control someone intends to perform rather than the one performed.
    • Key controls are the few whose failure leaves the risk substantially uncovered; mark them, because testing effort follows the mark.

    Link every statement to the objective or assertion it protects. A control that maps to no assertion is either mislabelled housekeeping or a control for a risk nobody has admitted to having — both worth knowing. This linkage is what lets you answer the only question a sceptical reviewer really has: if this control failed, what, precisely, could now go wrong?

    Carry this into the drill

    The clinic drill hands you weak statements and scores your rewrites against the same seven anchors — it was built for this module, so expect it to be opinionated.

    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.

    Yours to edit — changes stay in this box

  • playRequiredTicks itself

    The Control Statement Clinic — make it testable

    Rewriting broken statements against a rubric is the fastest rep for this module's core skill — precision under the seven anchors.

    the drill built for this module

    Open the drill

    Ticks itself when the drill records a result

  • applyRequired

    Process narrative plus initial control statements

    Open the brief

    Map your chosen process end to end and write the narrative a stranger could follow, then draft initial control statements for every control the map surfaces. Hold each statement to the seven anchors from the lesson. This is the document set the rest of the programme builds on — the catalogue that follows and the testing stage both stand on it.

    What to produce

    • Process map — swimlanes or numbered flow, systems and handoffs named
    • Narrative — the transaction's journey, controls placed where they operate
    • Control statements — one per control, all seven anchors present
    • Assertion / objective linkage per statement
    • Key-control designation with one line of reasoning each
    Template · process-narrative
  • checkRequired

    Self-critique your statements against the clarity, completeness and testability rubric

    Open the prompts
    1. Take your three most important statements: can each be tested by a stranger using only what is written?
    2. Which anchor do you most often leave implicit — evidence, frequency, owner? What does that say about how your organization documents?
    3. Walk one real transaction against your narrative. Where did reality diverge, and which statements does that divergence infect?
    4. Which statement, if you are honest, describes an intention rather than a practice?

Week 2 of 6 · 9.5 hours · 3 modules

Catalogue, calibration and synthesis

Build the single source of truth. A rationalized catalogue linked to processes and risks, residual risk calibrated on evidence rather than optimism, and a document set you would defend in a room.

2.1

Building and rationalizing the catalogue

4h

Design a coherent catalogue as the single source of truth — risk, process, control, evidence, owner, monitoring — then rationalize it: remove and combine without opening gaps, and spot what is a genuine automation candidate.

  • learnRequired

    Rationalization without gaps

    Read the brief~2 min

    The catalogue is the single source of truth or it is nothing. One row per control; linked left to the risk it treats and the process it lives in; linked right to its evidence, its owner, and how it is monitored. The moment a second list exists — the audit team's version, the compliance team's version — every update becomes a synchronisation problem and every report becomes an argument. Architecture first: risk, process, control, evidence, owner, monitoring, one spine.

    Rationalization without gaps

    Catalogues grow by accretion — every incident, audit and regulation adds controls, and nothing ever removes one. Rationalization is the deliberate act of removal, and it is only safe when done against the linkage. A control may be removed when the risk it treats is fully covered by another control of equal or better reliability, and combined when two rows describe one activity performed once. The rationalization log is not bureaucracy; it is the proof, months later, that removal was a decision and not an accident. SOX programmes, IPO readiness and transformations all run this play, because a catalogue nobody prunes eventually collapses under its own testing cost.

    • Remove only against demonstrated coverage; combine only genuinely identical activity.
    • Every removal gets a log entry: what went, why, what now covers the risk.
    • The automation candidates are the high-frequency, rule-based, data-complete controls — flag them now, design them in the monitoring stage.
    • A catalogue's health metric is not its size; it is the fraction of rows a tester could act on unaided.

    Rationalizing also surfaces the opposite finding: risks with no control at all, hidden until the linkage made the empty cell visible. Record those too. A rationalized catalogue is smaller, but its real property is that its gaps are known ones.

    Carry this into the drill

    Run Build & Defend in full this time — design the set, then let the attack sequence audit your coverage. Follow it with Rate the Risk to pressure-test how you rank what remains.

    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.

    Yours to edit — changes stay in this box

  • playRequiredTicks itself

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

    The attack sequence is a free audit of your catalogue instincts — it finds the gap you rationalized into existence.

    full run — design, then face the attack sequence

    Open the drill

    Ticks itself when the drill records a result

  • playRequiredTicks itself

    Rate the Risk

    Rating risks in quick succession exposes whether your ranking follows exposure or follows adjectives.

    Open the drill

    Ticks itself when the drill records a result

  • applyRequired

    Mini catalogue of 10–20 controls plus a rationalization log

    Open the brief

    Build a mini catalogue of ten to twenty controls for your process, fully linked — risk, process step, control, evidence, owner, monitoring. Then rationalize it: remove and combine where the lesson's rules allow, and keep the log. Flag automation and continuous-monitoring candidates while you are in the rows; the monitoring stage picks them up.

    What to produce

    • Catalogue — one row per control, all six linkage columns populated
    • Rationalization log — every removal and combination, with the coverage argument
    • Gap list — risks left without a control, stated plainly
    • Automation / CCM candidate flags with one line of reasoning
    • Before / after count and what the reduction cost in coverage (ideally: nothing)
    Template · catalogue
2.2

Residual-risk calibration

3.5h

Score residual risk defensibly and find out where your instinct is sound and where the alarming-sounding option is winning.

  • learnRequired

    Likelihood times impact, after the controls in place

    Read the brief~2 min

    Residual risk is what remains after the controls that actually operate, not after the controls on paper. The model is short — inherent risk, modified by control effectiveness, leaves residual — but every term hides a judgement. Inherent scoring imagines the process with no controls at all, which nobody has ever seen, so anchor it in exposure: volumes, values, velocity. Effectiveness comes from the design and operating conclusions you can defend, not from familiarity. And the modification is asymmetric: preventive controls pull likelihood down, detective and corrective controls pull impact down, and a scale that ignores which term moved will mis-rank the portfolio.

    Where instinct fails

    Calibration research and every risk workshop ever run agree on the failure pattern: dramatic, nameable risks are over-weighted and boring, structural ones under-weighted. A ransomware headline outranks a mis-posted journal in every gut ranking, while the journal error's expected annual cost may be ten times higher. The discipline is scoring the boring thing on its numbers and the scary thing on its numbers, and letting appetite — not adrenaline — set the threshold for action.

    • Score inherent on exposure you can evidence; score effectiveness on conclusions you have tested.
    • Track which term a control moves — likelihood or impact — and let the residual reflect it.
    • Aggregation needs a rule: worst-of, weighted, or scenario-based — pick one and say so.
    • When your ranking and the scoring model disagree, write down why before overriding either. The reflection is the calibration.

    Hybrid scoring — a qualitative scale with quantitative anchors ("4 means more than $1m or regulatory reporting") — is usually the honest middle: precise enough to rank, humble enough to admit the judgement inside. Whatever scale you choose, its real test is the pairwise one: take any two rows and ask whether the ordering survives explanation to a sceptic.

    Carry this into the drill

    Which Is Riskier? runs exactly that pairwise test on you, and keeps score. Expect to find one systematic bias; the reflection in the deliverable is where you name 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.

    Yours to edit — changes stay in this box

  • playRequiredTicks itself

    Which Is Riskier? — a calibration drill

    Pairwise calibration with a scoreboard — the drill that shows you your own bias faster than any lecture.

    Open the drill

    Ticks itself when the drill records a result

  • applyRequired

    Residual-scored catalogue plus a calibration reflection

    Open the brief

    Score the full mini catalogue: inherent, control effectiveness, residual, with the scale you can defend. Then write the calibration reflection — a page on where your instinct and the model disagreed, which of the drill's findings about your bias showed up here, and what you did about it.

    What to produce

    • Scoring scale definition, with quantitative anchors
    • Catalogue with inherent / effectiveness / residual per row
    • Likelihood-versus-impact note per major control
    • Aggregation rule, stated
    • Calibration reflection — instinct versus model, bias observed, adjustment made
    Template · residual-scoring
2.3

Synthesis — foundations and design

2h

Portfolio review against the checklist, and a light scope for the assessment work that follows.

  • checkRequired

    Portfolio self-review against the foundations checklist

    Open the prompts
    1. Lay this stage's four deliverables side by side: do the framework notes, the taxonomy sheet, the narrative and the scored catalogue describe the same process, or four slightly different ones?
    2. Which single control statement improved most in this stage? What changed in how you wrote it?
    3. Where is the weakest link in your catalogue's linkage — risk to control, or control to evidence?
    4. Pick the process for the RCSA and testing stage: same one deeper, or a second one for range? One line on why.

Week 3 of 6 · 10.5 hours · 3 modules

RCSA: method, formulation, facilitation

Make the assessment itself a control. Set the methodology, write risks and controls that can actually be tested, and run a workshop that produces conclusions rather than consensus.

3.1

RCSA methodology and taxonomy

3h

Design the methodology before you run the workshop: scoring scales, taxonomy, evidence expectations, and who owns which judgment.

  • learnRequired

    The methodology is the control over the RCSA

    Read the brief~2 min

    An RCSA produces judgements, and judgements are only as comparable as the method that produced them. That is why the methodology is the control over the RCSA: it fixes the scales before anyone scores, the taxonomy before anyone names a risk, the evidence expectations before anyone claims effectiveness, and the ownership of each judgement before the meeting where it will be contested. Skip the methodology and you still get numbers — you just cannot compare them across units, quarters, or the two facilitators who ran the sessions.

    Choosing the spine

    There are four workable spines. Process-based walks the flow and asks what can fail at each step — concrete, but blind to risks that live between processes. Objective-based starts from what must go right — strategic, but abstract fast. Risk-based starts from a taxonomy of named risks — comparable across units, but only as good as the taxonomy. Control-based starts from the catalogue you built in the foundations stage — efficient, but silently assumes the catalogue is complete. Mature programmes hybridise: a risk taxonomy for comparability, walked through processes for concreteness, reconciled to the catalogue for coverage.

    • Fix scales, taxonomy, evidence expectations and judgement ownership before the first workshop.
    • Taxonomy pitfalls: categories that overlap, categories nobody's risk fits, and a level of detail nobody can score at.
    • Alignment runs upward — the RCSA's ratings must aggregate into the ERM view and speak the appetite statement's language.
    • Full RCSAs set the baseline; focused RCSAs maintain it. Running full everywhere every year is how programmes become theatre.

    Decide the cadence on risk, not on habit. A stable back-office process may earn a focused refresh every other year; a process mid-transformation earns a full assessment now and a follow-up when the dust settles. The methodology document is where that reasoning lives, so the next analyst inherits a rationale rather than a ritual.

    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.

    Yours to edit — changes stay in this box

  • learnOptional

    Reading: how an operating model carries or fails an RCSA

    Read the brief~2 min

    Before drafting your own methodology, read how an operating model carries — or quietly fails — an RCSA programme. The piece linked below walks the structural choices: where the second line sits, who owns the taxonomy, how assessment output reaches decisions. Read it with your own organization in mind and note the one structural gap that would most distort an RCSA you ran tomorrow.

    Open the reading — GRC Operating Model
    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.

    Yours to edit — changes stay in this box

  • applyRequired

    Draft RCSA methodology plus taxonomy notes

    Open the brief

    Draft the RCSA methodology for a pilot area — the process you mapped earlier or a unit you know. It should be short enough to be read and complete enough to be followed by a facilitator who is not you. Attach taxonomy notes: the categories you will assess against, with the overlaps and gaps you already anticipate.

    What to produce

    • Purpose and scope of the pilot RCSA — what is in, what is out, why
    • Spine and rationale — process / objective / risk / control-based, or the hybrid, and why it fits this area
    • Scoring scales for likelihood, impact and control effectiveness, with anchors
    • Evidence expectations — what a rating must be able to point to
    • Judgement ownership — who scores, who challenges, who signs
    • Cadence — full versus focused, and the trigger for each
    • Taxonomy notes — categories, known overlaps, known gaps
    Template · rcsa-methodology
3.2

Risk and control formulation, and workshop prep

3.5h

Write risks that describe an event with a cause and a consequence, not a topic — then plan a workshop that will not simply ratify what people already believe.

  • learnRequired

    A risk is an event, not a subject heading

    Read the brief~2 min

    "Cyber risk" is a subject heading. "A privileged account is compromised through a phished credential, and payment instructions are altered before release" is a risk: an event, with a cause, and a consequence someone can price. The event-cause-consequence discipline is not pedantry — it is what makes everything downstream possible. You can link a control to an event; you cannot link one to a heading. You can score the consequence; you cannot score a topic. Every vague risk in a register is a place where assessment quietly became decoration.

    Preparing a workshop that will not just agree with itself

    Workshops fail socially before they fail analytically, and the failure is prepared in advance or prevented in advance. Map the stakeholders: who owns the process, who will defend it, who has seen it fail, and who has the incentive to keep ratings green. Bring pre-work data — incidents, losses, KRIs, audit findings — because a workshop scoring against evidence argues with the evidence, while a workshop scoring from memory agrees with the loudest memory in the room. Draft the risks in event form before the session; the room's job is to correct and score them, not to compose from a blank page under time pressure.

    • Risk = event + cause + consequence. If you cannot say what happened, it is not yet a risk.
    • Each risk drafted links forward to the controls that claim to treat it — empty linkage is a finding before the workshop starts.
    • Pre-work data is the antidote to scoring by anecdote.
    • Anticipate resistance by name: who benefits from amber, who from green, and what question each will need answered.

    The agenda itself is a control. Time-box scoring per risk, put the contested ones early while attention is fresh, and script the facilitator's prompts for the failure modes module 2.3 covers. A workshop that runs on a designed agenda produces ratings; one that runs on conversation produces minutes.

    Carry this into the drill

    The crossword is an optional warm-up — the vocabulary of formulation, at speed, before you draft your own set.

    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.

    Yours to edit — changes stay in this box

  • playOptionalTicks itself

    The Practitioner's Crossword

    Optional vocabulary warm-up — the formulation terms this module leans on, fixed through recall rather than reading.

    vocabulary warm-up

    Open the drill

    Ticks itself when the drill records a result

  • applyRequired

    Formulation set of 8–12 risks plus a workshop plan

    Open the brief

    Formulate eight to twelve risks for your pilot process in strict event-cause-consequence form, each linked to the catalogue controls that claim to treat it. Then build the workshop plan you would actually run: agenda, participants and their likely positions, pre-work data list, and scoring aids.

    What to produce

    • Risk set — 8–12 risks, event + cause + consequence, no headings
    • Control linkage per risk, with gaps marked honestly
    • Participant map — role, stake, anticipated position
    • Pre-work data list — incidents, losses, KRIs, findings to circulate
    • Agenda with time-boxes and contested items placed first
    • Scoring aids — the scales from 2.1, printed for the room
    Template · formulation-set
3.3

Facilitated RCSA execution

4h

Run the session: anchoring, optimism, the loudest voice, and the participant who scores everything amber. Facilitation is where a good methodology is won or lost.

  • learnRequired

    The four ways a workshop scores itself wrong

    Read the brief~2 min

    A workshop is an instrument that measures a room, and rooms have systematic errors. Four recur everywhere. Anchoring: the first number spoken becomes the gravity well for every number after it — so collect initial scores silently, before anyone speaks. Optimism: the people who run a process rate it the way they hope it runs — so put the pre-work evidence on the table before scoring, not after. The loudest voice: seniority and volume substitute for evidence — so the facilitator polls the quiet and makes disagreement cheap. And the all-amber participant: amber offends nobody and commits nobody — so force ranking within the amber band, where the real ordering hides.

    Facilitating under pressure

    Time pressure and resistance are the normal weather. The facilitator's craft is consistency under both: the same scale applied the same way to the tenth risk as the first, disagreement recorded rather than smoothed, and every rating captured with its rationale in the room — because a rating whose reasoning is reconstructed afterwards is fiction with a number on it. Horizon items — the emerging risks nobody can score yet — get parked visibly, not scored vaguely.

    • Silent initial scoring beats anchoring; evidence before scoring beats optimism.
    • Poll the quiet on purpose; the loudest view is already in the room.
    • Break the amber habit by ranking within the band.
    • Capture rationale live. The register you write is the workshop's only surviving witness.

    Debrief yourself afterwards while it is fresh: which failure mode appeared, what you did, what you would script differently. Facilitation improves by post-mortem, and the module's deliverable asks for the honest version.

    Carry this into the drill

    Revisit Which Is Riskier? mid-scoring if the session is yours to run — it resets your own calibration before you challenge anyone else's.

    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.

    Yours to edit — changes stay in this box

  • playOptionalTicks itself

    Which Is Riskier? — a calibration drill

    Optional mid-module recalibration — worth a run just before you score or challenge live ratings.

    revisit during scoring

    Open the drill

    Ticks itself when the drill records a result

  • applyRequired

    RCSA register excerpt with ratings and rationale

    Open the brief

    Run the session — facilitated with colleagues if you can, role-played solo against your participant map if you cannot. Produce the register excerpt: the scored risks with rationale captured as it happened, plus a short facilitation debrief naming which failure modes appeared and how you handled them.

    What to produce

    • Register excerpt — each risk with inherent and residual ratings and control-effectiveness view
    • Rationale per rating, captured in-session
    • Disagreements recorded as disagreements, with both positions
    • Parked horizon items
    • Facilitation debrief — failure modes observed, interventions used, what you would change
    Template · rcsa-register

Week 4 of 6 · 9.5 hours · 3 modules

Testing, deficiencies and synthesis

Test design and operation with enough rigour that the conclusions survive challenge, rate what you find by severity rather than by comfort, and integrate it into one residual-risk view.

4.1

Design and operating-effectiveness testing

4h

Build a test plan and execute it. Judge evidence on provenance rather than format, and treat information produced by the entity as the completeness-and-accuracy problem it is.

  • learnRequired

    Inquiry, observation, inspection, reperformance — and what each one can carry

    Read the brief~2 min

    Evidence has a hierarchy, and every testing decision is a position on it. Inquiry — asking — is the weakest form: necessary for understanding, never sufficient for a conclusion. Observation carries more: you watched it happen, though only that once. Inspection of evidence carries more still: the artefact exists independent of anyone's account. Reperformance is the strongest: you did what the control does and reached the same result. Design testing walks one instance end to end to conclude the control, operated as described, addresses the risk. Operating testing samples the population to conclude it actually ran, consistently, over the period. Different questions, different evidence, different failure modes.

    IPE — the problem inside the evidence

    Information produced by the entity is the trap inside otherwise clean testing. The exception report you tested against, the population list you sampled from, the query output the reviewer signed — each was produced by a system and a parameter set, and your conclusion silently assumes both were complete and accurate. Treat IPE as its own test: where did this data come from, what logic filtered it, who can change that logic, and how do you know this run included everything it should? A perfect test over an incomplete population is a wrong answer delivered with confidence.

    • Rank your evidence: inquiry < observation < inspection < reperformance. Conclusions inherit the rank of their weakest link.
    • Design asks: would it work? Operating asks: did it run? Never let one answer stand in for the other.
    • Sampling needs a defensible basis — population completeness first, then size, then selection method.
    • Full-population analytics beat sampling where the data allows; they also move the entire burden onto IPE quality.

    Document as you go, to the standard of a stranger reperforming your test from the workpaper alone: what you tested, from what population, selected how, against what attribute, with what result and what conclusion. That standard is not bureaucracy — it is module 2.5's severity debate, pre-won.

    Carry this into the drill

    Rely or Reject drills exactly this hierarchy — evidence after evidence, keep or throw. Tie-Out is the optional deep cut for the reperformance instinct.

    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.

    Yours to edit — changes stay in this box

  • playRequiredTicks itself

    Rely or Reject — an evidence-reliability drill

    The evidence-reliability drill built for this module — provenance over format, decision by decision.

    the drill built for this module

    Open the drill

    Ticks itself when the drill records a result

  • playOptionalTicks itself

    Tie-Out — a forensic deduction

    Optional forensic workout — reperformance thinking on a puzzle that punishes taking numbers on trust.

    Open the drill

    Ticks itself when the drill records a result

  • applyRequired

    Testing workpapers for 3–5 key controls

    Open the brief

    Select three to five key controls from your catalogue and test them: design via walkthrough, operating via a sampled or full-population approach you can defend. Write the workpapers to the reperformance standard, and give IPE its own explicit treatment wherever your evidence came out of a system.

    What to produce

    • Test plan — controls selected and why, approach per control
    • Design walkthrough documentation per control
    • Operating test — population, completeness argument, sample basis, attributes, results
    • IPE assessment for every system-produced item relied on
    • Conclusions per control, exceptions stated plainly
    Template · workpaper
  • checkRequired

    Would your conclusion survive someone re-performing your test

    Open the prompts
    1. Hand your best workpaper to an imagined stranger: could they reperform the test and reach your conclusion without asking you anything?
    2. Where is the weakest evidence rank in your chain, and does your conclusion honestly acknowledge it?
    3. For each IPE item: what exactly convinces you the population was complete?
    4. Which exception did you come closest to explaining away, and what does that impulse tell you?
4.2

Deficiency severity and remediation

3.5h

Rate severity honestly — design versus operating, and what actually reaches material weakness — then design remediation that addresses the cause rather than the symptom.

  • learnRequired

    Severity is a judgment you have to be able to defend twice

    Read the brief~2 min

    You will defend a severity judgement twice: once to the process owner who thinks it is too harsh, and once to a reviewer — audit committee, external auditor, regulator — who must be convinced it is not too kind. A judgement that survives both conversations was built on the same three questions every severity framework encodes: what could go wrong because this control failed, how big could it plausibly get, and what else stands between the failure and the harm. A design deficiency means the control never could have worked; an operating deficiency means it could have and did not. They aggregate differently — several small operating failures in one area can amount to a design problem wearing a disguise.

    The line to material weakness

    In ICFR terms, the escalation from deficiency to significant deficiency to material weakness turns on the reasonable possibility of a material misstatement going undetected — a magnitude-and-likelihood judgement, made with compensating controls honestly weighed and honestly tested. The recurring temptation is to let a compensating control carry more than it was ever tested for. The recurring negotiation is with an owner for whom the rating is personal. Hold the judgement to the framework, in writing, and both conversations become shorter.

    • Severity = plausible magnitude × likelihood of non-detection, after compensating controls you have actually tested.
    • Design versus operating changes the fix: redesign versus re-perform and re-train.
    • Aggregate honestly — clusters of small failures are telling you something structural.
    • Root cause before remediation: a fix that addresses the symptom schedules the recurrence.

    Remediation quality is a severity question in disguise. An action plan with a named owner, a date, and a definition of done that a tester could verify closes findings; a plan that says "management will reinforce" closes nothing and will be back next cycle with interest. Design the remediation against the root cause, and design the retest before the fix ships.

    Carry this into the drill

    The Material-Weakness Memo puts you inside the escalation judgement; Agree the Finding puts you across the table from the owner. Both conversations from the lesson, playable.

    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.

    Yours to edit — changes stay in this box

  • playRequiredTicks itself

    The Material-Weakness Memo — SOX 404 disclosure sim

    The escalation judgement, lived — magnitude, likelihood and compensating controls under disclosure pressure.

    Open the drill

    Ticks itself when the drill records a result

  • playRequiredTicks itself

    Agree the Finding — an audit negotiation

    The owner negotiation, lived — holding a rating without losing the relationship or the finding.

    Open the drill

    Ticks itself when the drill records a result

  • applyRequired

    Deficiency assessment plus a remediation plan with owners

    Open the brief

    Rate every exception from your 2.4 testing: deficiency class, design or operating, severity with the reasoning that survives both defences. Then build the remediation plan — root cause, owner, date, definition of done, and the retest that will confirm it.

    What to produce

    • Deficiency log — each exception classified and severity-rated with rationale
    • Design/operating call per item, with the aggregation view across items
    • Compensating controls considered, and the evidence they were tested
    • Remediation plan — root cause, action, owner, date, definition of done
    • Retest plan per remediation
    Template · deficiency
4.3

Synthesis — assessment and testing

2h

Integrate the register, the testing results and the remediation plan into one residual-risk view, and scope the capstone.

  • checkRequired

    Integrated residual-risk view, and capstone scoping

    Open the prompts
    1. Integrate: does the residual view from the register still hold once the testing results and deficiencies are laid against it, or did testing prove some effectiveness assumptions wrong?
    2. Which single rating changed most between workshop and testing, and what does that gap teach you about the workshop?
    3. Draft the one-paragraph residual-risk position you would give a CRO today.
    4. Scope the capstone: which scenario family from module 3.5 fits your pilot process, and what will you need to have ready?

Week 5 of 6 · 10.5 hours · 3 modules

Monitoring, AI and complex domains

Make the work continuous, then take it where control thinking is least mature: automated monitoring, AI and emerging technology, and the cross-cutting domains nobody quite owns.

5.1

Continuous controls monitoring

3.5h

Move from periodic testing to monitoring: what to instrument, what threshold, and who works the queue when it fires.

  • learnRequired

    A monitor nobody triages is a log

    Read the brief~2 min

    Continuous monitoring is periodic testing with the period removed — and everything that made testing rigorous still applies, at machine speed. A monitor is four design decisions: what signal to instrument, what threshold turns signal into exception, what workflow the exception lands in, and who works that queue with what deadline. Miss the fourth and you have built a log: technically continuous, practically ignored, and worse than the periodic test it replaced, because now everyone believes the control is watched.

    What earns automation

    The controls worth monitoring continuously select themselves: high-frequency, rule-expressible, and running on data that is complete and timely. Access revocation on leavers, segregation conflicts, payment-threshold breaches, journal entries with suspicious properties. Rule-based tests are transparent and auditable; analytic and model-driven tests find what rules cannot describe, at the price of explainability — a price module 3.2 tells you how to think about. Frequency follows risk velocity: identity events in near real time, financial-close checks daily or by cycle. Monitoring a slow risk in real time buys alert fatigue, not assurance.

    • Design in this order: signal, threshold, workflow, owner. Stop if any of the four has no answer.
    • Thresholds are calibration decisions — start where the queue is workable, tighten as false positives fall.
    • Poor data quality does not weaken a monitor; it silently inverts it into false assurance.
    • Automation introduces its own risks — the rule that drifts from the policy, the job that fails quietly. Monitor the monitor.

    Be explicit about what stays manual: judgement-heavy controls, low-frequency events, data too dirty to trust. The CCM design that admits its boundary is the one an auditor can rely on — and the ROI case writes itself from the testing hours the automated portion genuinely retires.

    Carry this into the drill

    The Alert Queue is the fourth design decision made visceral — forty alerts, one analyst, and a triage discipline to build before you design queues for other people.

    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.

    Yours to edit — changes stay in this box

  • playOptionalTicks itself

    The Alert Queue — 40 alerts, one analyst

    Optional: working a live queue teaches threshold design from the receiving end — the side most CCM designers have never sat on. Eight minutes, and it changes how you set a threshold for somebody else.

    Open the drill

    Ticks itself when the drill records a result

  • applyRequired

    CCM approach for a subset of the pilot catalogue

    Open the brief

    Take the automation candidates you flagged while building the catalogue and design the CCM approach for that subset: signal, threshold, exception workflow and ownership per control, with cadence matched to risk velocity and an honest boundary around what remains manual.

    What to produce

    • Candidate subset from the catalogue, with selection reasoning
    • Per control: data source, signal logic, threshold and its calibration plan
    • Exception workflow — queue, owner, SLA, escalation
    • Cadence matrix — frequency per control, justified by risk velocity
    • Data-quality assessment per source
    • The manual remainder, stated, with why
    • ROI sketch — testing effort retired versus build and run cost
    Template · ccm-approach
5.2

AI and emerging-technology controls

4h

Control design where the system is probabilistic: what a model's failure modes are, which of them a control can reach, and what has to be true before a use case is allowed to proceed.

  • learnRequired

    Controls for a system that is confidently wrong

    Read the brief~2 min

    Traditional controls assume deterministic systems: same input, same output, testable once. A model breaks the assumption — it is probabilistic, it drifts, and its signature failure is being confidently wrong: fluent, plausible output with no warning light attached. Control design for AI therefore starts from failure modes, not from features. Hallucination and confident error; manipulation of inputs, including instructions smuggled into the data the system reads; drift as the world moves away from the training data; and shadow deployment — the use cases nobody registered, which are the ones with no controls at all.

    The control set that reaches them

    The practical stack is unglamorous and effective. An inventory with a named owner per system — you cannot control what you have not listed, and shadow AI is an inventory failure before it is anything else. A gate before deployment: what must be true — evidence of testing, defined boundaries, a human checkpoint where stakes demand one — before a use case proceeds. Output evidence standards, so "the model said so" never enters a workpaper. Third-party assurance for the models you rent, read as critically as any SOC report. And monitoring with a kill switch: drift metrics watched by a named owner, and a rollback path rehearsed before it is needed. Classification regimes in the EU AI Act's style add the outside-in view — obligations scale with the risk class of the use, not the elegance of the model.

    • Inventory + named owners first; every other AI control depends on knowing the population.
    • Gate use cases on evidence, boundaries and human checkpoints — before deployment, not after incident.
    • AI can also run controls — continuous testing, anomaly detection — and each such use is itself a use case for the gate.
    • Residual risk never reaches zero on a probabilistic system; say so in the rating rather than rounding it away.

    The double-entry rule keeps you honest: every place AI strengthens the control environment, write down the new risk it introduced — the drifting test, the poisoned data source, the reviewer who stopped reviewing because the machine seemed sure. This module's drills exist because the judgement here is young; reps are how it ages.

    Carry this into the drill

    Three required drills: audit a machine, sit the use-case gate, and name the failure mode when the output is confidently wrong. The sorter and the prompt lab are optional extensions.

    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.

    Yours to edit — changes stay in this box

  • playRequiredTicks itself

    Auditing the Machine

    Auditing an AI system end to end — inventory, evidence and boundaries under examination conditions.

    Open the drill

    Ticks itself when the drill records a result

  • playRequiredTicks itself

    The Use-Case Gate — an AI governance committee sim

    The governance committee sim — deciding what must be true before a use case ships, with the trade-offs live.

    Open the drill

    Ticks itself when the drill records a result

  • playRequiredTicks itself

    Confidently Wrong — naming the AI failure mode

    Naming the failure mode fast — the recognition skill every AI control conversation starts from.

    Open the drill

    Ticks itself when the drill records a result

  • playOptionalTicks itself

    Classify the Use Case — EU AI Act Sorter

    Optional: classify use cases the EU AI Act's way, to feel how obligations scale with risk class.

    Open the drill

    Ticks itself when the drill records a result

  • playOptionalTicks itself

    The Prompt Lab — prompting for internal auditors

    Optional: prompting as an audit skill — getting reliable work out of an unreliable narrator.

    Open the drill

    Ticks itself when the drill records a result

  • applyRequired

    AI control design package for one use case

    Open the brief

    Design the control package for one concrete AI use case — an agentic finance workflow, a customer-facing assistant, a model-driven monitoring tool. Cover the full stack from the lesson, and close with the residual-risk statement that admits what remains.

    What to produce

    • The use case — purpose, autonomy level, blast radius if wrong
    • Inventory entry and named owner
    • Failure-mode analysis — which of the module's modes apply, and how
    • Gate criteria — what must be evidenced before deployment
    • Runtime controls — output standards, human checkpoints, monitoring metrics, kill switch and rollback
    • Third-party reliance and the assurance obtained
    • New risks introduced by the AI itself
    • Residual-risk statement
    Template · ai-control-package
5.3

Complex and cross-cutting domains

3h

Where controls span systems, entities and third parties, and where the blast radius of one failure is the thing you are actually assessing.

  • learnRequired

    Cross-cutting risk is a linkage problem, not a domain problem

    Read the brief~2 min

    Some risks refuse to stay in their domain, and treating them domain by domain is how they win. An identity compromise is an IT event, then a payments event, then a disclosure event — the risk is the path, and the analyst's question is where along the path a control could break the chain. Attack-path thinking generalises past cyber: for any scenario, chart the sequence from initial failure to final harm, place the existing controls on the chart, and the gaps announce themselves. The blast radius of the first failure — how far it reaches before something contains it — is often the real thing you are assessing.

    Third parties, transformations, resilience

    Cross-cutting risk concentrates at the seams. Third parties: you can outsource the activity but not the accountability, so reliance on a vendor's controls means reading their SOC report the way you would read your own testing — scope, period, exceptions, and the complementary controls it quietly assumes you operate. Transformations and cutovers: the migration window is a temporary control vacuum, and cutover controls — reconciliation of migrated balances, dual-running, rollback criteria — exist precisely because the old assurance has stopped and the new has not started. Resilience: some events will land regardless, and the containment and recovery controls deserve the same design rigour as prevention.

    • Chart the path, place the controls on it, and read the gaps — linkage analysis, not domain analysis.
    • A SOC report is evidence to be tested, not comfort to be filed; its complementary-user-entity controls are your controls.
    • Cutover windows need their own control set with an expiry date.
    • Blast radius is a designable property: segmentation, limits and checkpoints shrink it before the incident chooses its own size.

    The deliverable for this module is a memo, because cross-cutting analysis is only useful once it can be handed to the several owners it implicates — each of whom sees only their segment of the path.

    Carry this into the drill

    The third-party self-assessment maps your reliance seams, and is the one to do. Blast Radius walks an identity attack path and The Breach Room pressure-tests decision-making mid-incident — both optional, and both worth the time if the scenario you chose runs through identity or a live incident.

    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.

    Yours to edit — changes stay in this box

  • playOptionalTicks itself

    Blast Radius — an identity attack-path sim

    Optional: an identity attack path, step by step — containment thinking against a moving failure. The clearest place to watch this module's linkage argument play out, on the domain where a path is easiest to see.

    Open the drill

    Ticks itself when the drill records a result

  • playRequiredTicks itself

    How ready is your data privacy function?

    A structured pass over your third-party reliance — where the seams are and what stands at each one.

    Open the drill

    Ticks itself when the drill records a result

  • playOptionalTicks itself

    The Breach Room — a C-suite tabletop

    Optional: C-suite decisions mid-breach — resilience judgement under incomplete information.

    Open the drill

    Ticks itself when the drill records a result

  • applyRequired

    Scenario control-analysis memo

    Open the brief

    Pick one scenario — an identity attack path through your pilot process, a critical-vendor failure, or a cutover — and write the control-analysis memo: the path charted, controls placed, gaps named, and recommendations with the residual impact of each stated.

    What to produce

    • Scenario and why it matters to this process
    • The path — initial event to final harm, step by step
    • Existing controls placed on the path, with honest effectiveness notes
    • Gaps, and the blast radius they permit
    • Recommendations — control, owner, and residual impact after each
    • One page. Memos that run longer stop being read by the owners who must act
    Template · scenario-memo

Week 6 of 6 · 9.5 hours · 3 modules

Communication, capstone and close

Land it where decisions get made. Communicate to executives who will act on it, prove the whole method end to end on one capstone, and leave with a development plan you will actually follow.

6.1

Executive communication and influence

2.5h

Say it in a page, show the residual position honestly, and hold the judgment when it is challenged by someone with more authority than you.

  • learnRequired

    Defending a judgment without either caving or digging in

    Read the brief~2 min

    The audience for a residual-risk view has sixty seconds and authority you do not. Both facts shape the craft. The page must open with the position — where residual risk sits against appetite, what changed, what needs deciding — because a memo that saves its conclusion for the end has bet everything on being read to the end. The visual must show the honest picture: residual against appetite, direction of travel, the items outside tolerance, with nothing rounded toward green for comfort. Editorial clarity is a control against your own material: every sentence either informs the decision or leaves.

    Holding the judgement

    The challenge will come — from a CFO who wants the rating softer, a committee member testing whether you flinch. Caving trades your credibility for the room's comfort; digging in trades the relationship for the point. The third way is the professional one: restate the evidence, name what new evidence would change your view, and offer the decision honestly — "the rating stands on what we tested; accepting the risk is the committee's call to make, and I will record it." Influence without authority is built exactly here, one held judgement at a time, and through the culture levers around the paper: named ownership, findings framed as shared problems, credit given loudly when an owner fixes something early.

    • Lead with the position; support with the evidence; end with the decision required.
    • The residual visual shows position against appetite and direction of travel — the two things a board can act on.
    • Answer challenge with evidence and the conditions for changing your view, never with volume.
    • Escalation is a service to the decision-maker, not an act of aggression — write it that way.

    Sixty hours of analysis earn their keep in this one page. Write it as though the reader will make a real decision from it — because the good ones do.

    Carry this into the drill

    The Regulator's Interview is the required rep — held judgement under hostile questioning. The Earnings Hot Seat is the optional harder 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.

    Yours to edit — changes stay in this box

  • playRequiredTicks itself

    The Regulator’s Interview — SEC enforcement deposition sim

    Deposition-grade questioning of your judgements — the defence skill this module exists to build.

    Open the drill

    Ticks itself when the drill records a result

  • playOptionalTicks itself

    The Earnings Hot Seat — Reg FD under live Q&A

    Optional: the same discipline under live Q&A pressure, where hedging and over-claiming both cost you.

    Open the drill

    Ticks itself when the drill records a result

  • applyRequired

    Board memo plus a residual-risk visual

    Open the brief

    Convert the pilot's accumulated work into the board package: a one-page memo and a single residual-risk visual. Then pressure-test it — read it aloud as the committee would, and cut what did not survive.

    What to produce

    • One-page memo — position, evidence, decisions required
    • Residual-risk visual — position against appetite, direction of travel, out-of-tolerance items flagged
    • The three hardest questions you expect, with your answers drafted
    • What new evidence would change each major rating — written down before anyone asks
    Template · board-memo
6.2

Capstone

6h

One process, end to end: mapped, catalogued, rationalized, scored, tested, rated, monitored, and written up for a board.

  • applyRequired

    Full capstone package

    Open the brief

    One process, end to end, done as if it were the engagement. Choose a scenario with genuine complexity — an agentic-AI deployment in a core process, a transformation of a high-risk process, multi-entity IPO readiness, or a cyber-enabled operational scenario — and produce the complete, defensible package. Everything the programme built is in scope, and the package should read as one argument, not six attachments.

    Budget the six hours as deep-work blocks. The synthesis is the point: the linkage from risk to control to test to residual to recommendation should be traceable in both directions by a reader you never meet.

    What to produce

    • Scenario definition and scope
    • Risk and control catalogue for the scope, linked and rationalized
    • RCSA-style assessment — inherent, effectiveness, residual, with rationale
    • Testing and/or CCM approach, executed or specified to executable detail
    • Deficiency and remediation roadmap
    • AI and emerging-tech considerations where the scenario touches them
    • Board memo and residual-risk visual for the scenario
    • Traceability — any rating followed back to its evidence in two steps
    Template · capstone
  • checkRequired

    Self-assess the capstone against the rubric

    Open the prompts
    1. Linkage: pick any residual rating in the package and walk it back to evidence. How many steps did it take, and were any of them assertions?
    2. Calibration: which rating would a hostile reviewer attack first, and does your rationale already contain the answer?
    3. Practicality: could the remediation roadmap be executed by the owners named, with the resources implied?
    4. Communication: does the memo stand alone — could the committee act on it without opening the appendices?
    5. Defensibility: what is the weakest judgement in the package, and have you said so in the package itself?
6.3

Close — and what you do next

1h

Reflection, and a development plan you will actually follow.

  • checkRequired

    Reflection and personal development plan

    Open the prompts
    1. Name the three capabilities that moved most across the programme, with the deliverable that proves each.
    2. Which drill result surprised you most, and what practice has it changed?
    3. Write the development plan you will actually follow: the next credential or domain (CRISC alignment is the natural fit), the drills worth returning to quarterly, and the one workplace artefact you will upgrade first with what you built here.
    4. Six months from now, what evidence would show this programme worked?

Finish it, and it is on the record

When every required step is done, a printable completion certificate appears on your profile — self-attested, honest about what it is, and yours to keep. Apply and Check steps are yours to mark; Play steps tick themselves when a drill records a result.

Open your profile