Ninja War Room — the incident manual

What War Room is

The incident is the thing everything hangs off. Each incident has its own bridge roles, a live channel, a decision log, one or more response playbooks with owners and due times, regulatory clocks, stakeholder messages that need approval, an action list and a bridge call. Everything anyone does is written to the incident's event log, in order, and that log becomes the after-action timeline.

Declaring an incident

1. Click Declare incident (sidebar or the incident list).
2. Give it a title, a short summary, a type (ransomware, BEC, data breach, cloud account takeover, major outage / DR, and others) and a severity (SEV1 to SEV4).
3. Set became aware at if you knew before now. Regulatory clocks such as GDPR's 72 hours run from awareness, not from when someone opened War Room.
4. Tick test / exercise for drills. Test incidents are banded purple everywhere and every draft message is prefixed [TEST].

Declaring gives the incident a reference (WR-2026-0007), makes you incident commander (or deputy, if you name someone else as IC), starts every response playbook that applies to the type, and starts that playbook's clocks. Incidents are members-only: people who are not on one get "not found", because even the existence of an incident is sensitive. An IC can open an incident read-only to everyone signed in.

Bridge roles and what they can do

Incident commander, Deputy IC

Command: close or reopen, edit the facts, change roles, adjust clock lengths, invite people. Handing command to someone makes the previous IC deputy.

Comms lead, Legal / DPO

Approve stakeholder messages, stop clocks, mark messages sent.

Scribe, Technical lead, Executive liaison, Responder

Write: post, record decisions, work playbook steps, draft messages, add actions.

Observer

Read only.

Estate admins

Act with command and approval rights on any incident, logged as themselves.

Adding people by username

Type a Ninja username in People & invites. War Room suggests people who have signed in before. If the name has never signed in to War Room you get a warning (it may be a typo, and that person would never see the incident), and the channel entry says so. When in doubt, invite them by email.

The channel, status updates and decisions

One channel per incident, live for everyone on it (it reconnects and catches up by itself, so nothing is lost). The composer has three modes:

Message

Talk. Messages go into the report's appendix, not its timeline.

Status update

The official "where we are". It becomes the latest update at the top of the console and feeds the exec and customer templates. Set next update in to make a promise: if it passes with no new update, War Room raises an alert.

Decision

What was decided, the rationale, the alternatives considered, and who decided. This is the decision log, and it goes into the report as its own table.

Everything else appears in the channel automatically: role changes, playbook steps, clocks, comms approvals, invites, bridge joins and alerts. Filter by talk, decisions or system.

Status moves through declared → investigating → contained → recovering → resolved → closed (any order: reality isn't linear). Only the IC or deputy can close or reopen. A closed incident is read-only.

Response playbooks

Versioned playbooks for ransomware, business email compromise, data breach, cloud account takeover and major outage / DR. Each incident gets its own copy. Every step has a phase, an owner role (assigned to whoever holds that role), a due time counted from when the playbook started, and a checkbox. Steps can be in progress, done or skipped, with a note. Start another playbook on the same incident at any time.

Some steps are linked to a clock (completing "submit the regulator notification" stops the GDPR clock as met) or to a message template (the step points you at the regulator draft).

Regulatory and contractual clocks

Clocks come with playbooks: the GDPR / UK GDPR Art. 33 72-hour notification clock (from awareness), a BEC funds-recall window (24 h), an outage RTO (4 h by default). Each shows its deadline and time left, amber inside its warning window, red in its final hour and once breached.

• Met: stop it when the obligation is met (or tick the linked step).
• Not applicable: needs a note saying why. Record the reasoning as a decision too.
• Set hours (IC or deputy): change the length, for example to a contract's own RTO. Changing the awareness time moves every awareness-based clock.

The report lists every clock and whether it was met on time, met late, or not applicable.

Alerts: overdue steps and clocks

War Room checks every open incident every minute and raises an alert when:

• a playbook step passes its due time and is still pending or in progress;
• a clock enters its warning window: the last 25% of the clock, but at least 1 hour and at most 24 hours (the 72 h GDPR clock warns 18 h out, a 24 h clock 6 h out, a 4 h RTO 1 h out);
• a clock enters its final hour, and when it is breached;
• a promised next status update is overdue.

Each alert shows up three ways: a red ALERT entry in the channel (so it is in the after-action timeline), a Needs attention banner in the console, and a badge on the incident in the list. It is also emailed to the IC, the deputy and, for a step, its assignee (clock alerts also go to the comms lead and legal), at the address from their Ninja account.

Stakeholder messages and approval

Templates for the executive update, the legal brief, the regulator notification (Art. 33), the customer / data-subject notice and the all-staff notice. A draft is filled from the incident: summary, impact, customer impact, latest update, recent decisions, clocks. Anything War Room cannot know is left as a highlighted [[TO CONFIRM: …]] marker, and a message cannot be approved while any marker is left.

1. Draft from a template (or write a custom message), then edit it.
2. Approve: by default two-person. Someone with approval rights who did not draft or edit the message must approve it. They can also request changes.
3. Send it yourself (War Room does not send stakeholder messages) using Copy text, then Mark as sent with the channel (email, phone, portal, status page…) and recipients.

Approved but not yet sent? Back to draft withdraws the approval. A sent message cannot be withdrawn: send a correction.

Solo override

At 3 a.m. the IC may be the only person on the incident. If you are the incident commander and the only member (or an estate admin), a message you drafted shows Approve solo…. You must type why it cannot wait for a second person. The override is:

• badged SOLO OVERRIDE on the message, with your reason;
• posted in the channel as "SOLO OVERRIDE: … approved by … without a second person. Reason: …";
• listed in the after-action report under Two-person rule overrides, and marked in the approver column.

As soon as a second person is on the incident, solo approval is no longer offered. Placeholders still block it.

Inviting people by email

Enter a name and email, choose the kind of invite and how long the link lasts (4 hours to 7 days, default 24 h), and Send invite.

Ninja account

For someone with a Ninja login. Choose their bridge role. Opening the link while signed in adds them to the incident with that role. If they aren't signed in they are asked to sign in and then brought back. The link works once.

Guest

For someone without one: outside counsel, the insurer's breach coach, an IR firm, a client's CISO. See guests.

The invite is emailed, and the link is also shown to you once so you can send it another way. If email isn't configured the page says so and you copy the link. Invites are listed with their state (pending, accepted, revoked, expired) and how many times a guest joined the call. Revoke ends a link, or a guest's access, immediately.

Guests (no Ninja account)

A guest opens their link and is in: no account, no password. They are clearly badged GUEST by the name and email you invited, on the call ("Name (guest)") and in the channel.

• By default a guest can join the bridge call and read the status updates.
• You can also let them read the channel, or read and post in it.
• A guest never sees another incident, the incident list, playbooks, comms drafts, actions or anything admin. Their access is scoped to the one incident, time-limited, and revocable.
• The link is personal. Once opened, it becomes a guest session in that browser and disappears from the address bar.

Every invite, acceptance, bridge join and revocation is in the channel, and the after-action report lists who was invited, when they joined the call, and when their access ended.

The bridge call

Join bridge call in the console opens the incident's own call (created on first use). Everyone on the incident can join, and so can guests from their page. Camera, microphone and screen share are in the control bar. If your browser blocks sound, a Click to hear the call button appears. Every join is recorded for the attendance list in the report.

After-action report

One click produces WR-…-after-action.md from the record:

• summary, type, severity, status, IC, aware / declared / closed times, what happened, impact;
• the bridge roles; regulatory clocks and whether each was met on time;
• the decision log; the full timeline (including alerts);
• playbooks, step by step, with who completed what and when;
• stakeholder messages sent (who approved, via what, to whom), and any two-person rule overrides;
• bridge call attendance and every invite and guest;
• open actions (including unfinished steps), and the channel log as an appendix.

Incidents are never deleted: they are evidence. Test incidents stay flagged and closed.

Automatic intake from NinJAFUNK

Other systems (NinJAFUNK first) can open an incident on their own. The endpoint is machine-to-machine, authenticated with a shared key in the X-Intake-Key header, never a user session. It is off until a key is set (it answers 503); Scott's todooo/enable-warroom-intake.sh generates the key on the box, sets the organisation name used in regulator and customer drafts, and restarts the api.

The body carries source, external_id, title, summary, and optionally type, severity, link and observables. Intake is idempotent on (source, external_id): a retry returns the same incident. An intake incident starts with no playbooks and, unless a default commander is configured, "needs triage: assign an incident commander". It is visible to admins until someone takes command.

Legacy: video rooms and room playbooks

The original War Room was a set of standalone video rooms with in-room panels (timeline, IOCs, room playbooks, a breach tracker). They still work and sit under Legacy in the sidebar, but real incidents are run from Incidents. The room chat and breach tracker in legacy rooms are local to your browser and nobody else sees them.

Access & security

• Members sign in with the Ninja account (Signal SSO). The session cookie is ninja-warroom-token.
• Guests have a separate session that works only for their incident's guest pages, and it is re-checked on every request, so revoking or expiry takes effect at once.
• The event log is append-only and ordered. It is the audit trail and the source of the report.