Chapter 25 — Team studio: build and critique a response workflow
Lesson map
Lesson 25 published. Map, example, EX073.
flowchart TD
N0["Learning outcomes and connection"]
N1["25.1 Studio brief"]
N2["25.2 Critique protocol"]
N3["25.3 Evidence in critique"]
N4["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX073"]
Logical drawing
flowchart LR
N0["Learning outcomes and connection"]
N1["25.1 Studio brief"]
N2["25.2 Critique protocol"]
N3["25.3 Evidence in critique"]
N4["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX073"]
[Learning outcomes and connection]
|
v
[25.1 Studio brief]
|
v
[25.2 Critique protocol]
|
v
[25.3 Evidence in critique]
|
v
[Chapter synthesis]
|
v
[Worked example] --> [Exercise EX073]
Learning outcomes and connection
You will be able to (1) build, as a team, an end-to-end response workflow for one scenario from intake to closure; (2) critique another team's workflow with a structured protocol; and (3) revise your workflow based on critique and evidence. Chapter 24 compared existing playbooks; in this studio you design one and expose it to peers.
25.1 Studio brief
Each team receives a Fernmoor scenario (for example "compromised supplier account uploads a malicious file to the permits portal") and must produce: a swimlane diagram (roles across the top, steps down), the case states it passes through, decision points with owners and authority, the runbooks invoked (existing or new), evidence preserved at each step, communications, and closure conditions. Deliverables must use the Chapter 4 data model and the Chapter 10 charter; deviations must be justified. Team Heron's supplier upload workflow is an example of a studio deliverable that was critiqued and revised.
25.2 Critique protocol
A structured critique keeps feedback useful and humane. Fernmoor's protocol, adapted from design-studio practice: (1) the presenting team walks through the workflow for eight minutes without interruption; (2) reviewers ask clarifying questions only; (3) reviewers give feedback in three labelled forms — "I like…" (specific strength), "I wonder…" (open question), "What if…" (alternative); (4) a reviewer runs one inject through the workflow aloud, and everyone notes where it stalls; (5) the presenting team summarizes what they will change and what they will keep, with reasons. Critique addresses the workflow, not the people.
25.3 Evidence in critique
Opinions are useful, but evidence is better. Where possible, support a critique with data from earlier chapters: "Our detection register shows supplier-account alerts are rare (Chapter 19); your workflow depends on an alert that does not exist." "Chapter 18's test showed isolating a VM takes 6 minutes; your step assumes 1." Team Heron's critique shows the value of evidence: the inject showed that the workflow stalled when the supplier denied uploading anything, which made the missing coordination step clear without anyone arguing about style. The revision added a supplier coordination runbook based on that stall, and the team could point to the inject as the reason.
25.4 Worked example (synthetic): the supplier upload workflow
Fictional. Team Heron's workflow: intake from a malware detection on the portal file store → duty analyst triage → incident lead → disable supplier account → remove file → notify supplier → close.
Critique highlights: - I like: the explicit decision to disable the supplier account with the portal owner's approval recorded. - I wonder: whether any residents downloaded the file before removal — the workflow never asks. - What if: the supplier account was not compromised but the supplier's own system was? Disabling the account would not tell you. - Inject run: "Supplier says nobody at their company uploaded anything." The workflow stalled — no step for coordinated investigation with the supplier, and no contract contact list.
Revision: added steps "preserve the file and portal access logs before removal" and "query portal logs for downloads; if any, escalate to S2 and assess resident notification with privacy officer"; added a supplier coordination runbook referencing the contract's security clause and a verified contact list; closure now requires "download exposure determined". The team recorded which feedback they declined (a suggestion to block all supplier uploads permanently) and why (the business depends on them; compensating control: malware scanning before publication).
25.5 Common errors and limits
- Workflows that end at containment and forget recovery, communication and review.
- Critique that becomes personal or vague ("feels complicated").
- Accepting all feedback without reasoning, producing a bloated workflow.
- No inject run, so stalls stay hidden.
Team Heron's first workflow had two of these: it ended at closing the case without asking whether residents downloaded the file, and its stall stayed hidden until an inject was run. The team also avoided the third by declining a suggestion to block all supplier uploads permanently, recording why, and naming malware scanning before publication as the compensating control.
Exercises — chapter 25
Attempt each exercise before opening the worked results. Every case, organization, person, address and number in an exercise is synthetic unless a cited public source is named.
EX073 — Swimlane. Steps: draw (or tabulate) the revised Heron workflow with roles as lanes. Rubric: 3 = duty analyst, incident lead, portal owner, privacy officer, supplier liaison lanes with ordered steps, decisions and evidence points; 2 = missing a lane; 1 = linear list; 0 = none.
EX074 — Critique. Steps: write two "I like", two "I wonder" and two "What if" items on the revised workflow. Rubric: 3 = specific, workflow-focused, at least one evidence-supported; 2 = generic; 1 = personal or vague; 0 = none.
EX075 — Declined feedback. Steps: write the record for declining one critique. Rubric: 3 = feedback, decision, reason, compensating control, review date; 2 = missing control; 1 = dismissal; 0 = none.
Chapter synthesis
Design workflows end to end with roles, states, decisions, evidence and closure; critique them with a structured, evidence-supported protocol and live injects; and record both accepted and declined feedback with reasons.
Continue studying — chapter 25 of 30
← Chapter 24 · Course chapter index · Chapter 26 →
Continue to the next authored lesson.