A cyber incident rarely stays inside the security team. Several teams may need the same changing facts. NIST describes incident response as work shared across people, teams and third parties, and notes that leadership may hold authority over high-impact actions such as shutting down or rebuilding a critical service.[1]
A coordination Virtual Employee maintains one time-stamped record, chases named owners and makes missing information visible. It does not detect threats, declare an incident, attribute an attacker, isolate systems or decide what the organization tells customers or authorities.
The UK National Cyber Security Centre recommends a central coordination point so findings can be correlated and actions planned.[2] That is the useful design target: one trusted coordination record, not an autonomous incident commander.
The first-hour workflow
- Open a coordination record. Capture the original signal, first observed time, reporter, affected service, evidence location and access restriction. Link to the source instead of smoothing uncertainty into a summary.
- Separate evidence from interpretation. Keep confirmed facts, observations, working hypotheses and decisions in different fields. Every change gets an author and timestamp.
- Create owned tasks. Track technical, service, supplier, legal and communications work. Each task needs one owner, a due time and a visible state.
- Prepare decisions. Give the authorized person the current operational state, supporting evidence, options, likely effects, missing information and the next update time.
- Record the human decision. Preserve who decided, their authority, the effective time and required follow-up evidence.
- Keep the clock running. Remind owners, flag missed updates and issue a fresh coordination pack at the agreed cadence. Do not silently convert a missed answer into approval.
This is not a complete response plan. The organization still needs its own playbooks, evidence procedures, deputies and professional advice.
Filled example: first-hour incident coordination board
This is an illustrative example using fictional systems, people and identifiers. It is not a real breach, customer, client engagement, MAJLS deployment or performance claim.
Verified intake
| Field | Filled value |
|---|---|
| Coordination reference | IR-2026-009, synthetic |
| Original signal | Monitoring team reports suspicious administrator activity plus intermittent portal availability |
| First observed | 29 September 2026, 08:07 Gulf Standard Time |
| Affected service | Cedar customer portal, fictional |
| Reporter | On-duty monitoring analyst |
| Source evidence | Original alert bundle in the restricted incident evidence store |
| Integrity state | Source bundle preserved; collection method recorded; forensic sufficiency not yet assessed |
| Initial service state | Portal reachable intermittently; business impact not yet confirmed |
| Stop condition | Do not copy restricted evidence into general chat or make a breach, severity or attribution statement |
The Virtual Employee opens the record only after the source and access location are present. It records the two signals as observations, not proof of compromise.
Chronological record
| Time | Record type | Entry | Owner or source | State |
|---|---|---|---|---|
| 08:07 | Observation | Monitoring signal received for synthetic admin account ADM-27 | Monitoring analyst | Source linked |
| 08:11 | Observation | Portal checks show intermittent availability | Service operations | Verification in progress |
| 08:16 | Working hypothesis | One event may explain both observations | Incident manager | Unconfirmed; do not repeat as fact |
| 08:22 | Action | Preserve approved identity and access logs for the defined time window | Security operations | Started under pre-approved collection procedure |
| 08:31 | Decision request | Decide whether to declare an incident and activate the incident team | Incident manager | Human decision due 08:40 |
No entry is overwritten. If a working hypothesis is rejected, the record keeps the original wording, rejection time and basis.
First-hour task board
| Workstream | Task | Named owner | Due | Evidence of completion |
|---|---|---|---|---|
| Technical investigation | Validate the signal against preserved identity and service logs | Security operations lead | 08:40 | Source-linked finding signed by owner |
| Service continuity | Confirm user impact and available operating workaround | Portal service owner | 08:35 | Service check and continuity note |
| Supplier coordination | Ask the hosting supplier to preserve relevant platform records | Supplier manager | 08:45 | Supplier case reference and response time |
| Legal and privacy | Review whether facts trigger counsel or privacy-team involvement | Legal and privacy duty owner | 09:00 | Recorded advice route; no legal conclusion drafted by the role |
| Communications | Prepare internal holding copy using only confirmed facts | Communications lead | 09:00 | Draft clearly marked unapproved |
The NCSC advises tracking, documenting, assigning and correlating findings, tasks and communications.[2] The board therefore carries owners and evidence, not just activities.
Decision packet at 08:35
Decision requested: Should the incident manager declare an incident and activate the approved response structure?
- Confirmed: suspicious administrator activity was reported; intermittent availability was independently observed; source records are linked and access-controlled.
- Not confirmed: compromise, data access, common cause, severity, attacker identity and customer impact.
- Options for the decision owner: continue enhanced investigation under the normal security process, or declare an incident and activate the approved incident structure.
- Likely effect: declaration adds the named response roles and update cadence; it does not authorize isolation, external communication or recovery.
- Missing information: validation of the identity logs, scope of service impact and supplier preservation response.
- Decision owner: incident manager named in the approved plan, or the recorded deputy if unavailable.
- Next update: 08:50 GST.
Authority map
| Virtual Employee may do | Named person must decide or approve |
|---|---|
| Create and update the coordination record | Declare or change the status of an incident |
| Request evidence collection already authorized by a playbook | Isolate a critical system or revoke broad access |
| Link findings to their original records | Attribute an attacker or make a legal breach finding |
| Remind owners when an agreed due time passes | Notify customers, regulators, insurers or law enforcement |
| Draft an internal update from confirmed facts | Approve internal or external communications |
| Assemble recovery-readiness evidence | Start recovery, return a service to normal operation or close the incident |
The NCSC says escalation must reach people with authority to make critical decisions.[2] Consequential approval remains with the named human incident manager and other authorized owners. A model-confidence score cannot confer that authority.
Observable escalation rules
Escalate to the named human owner when any of these conditions is recorded:
- a critical service has confirmed or worsening availability impact;
- evidence suggests sensitive data or system integrity may be affected;
- two source-linked findings conflict;
- an evidence owner misses the agreed time;
- the primary decision owner and deputy are unavailable;
- a supplier cannot preserve or supply a required record;
- a policy threshold for legal, privacy, insurance or executive review is met.
These are evidence, time, policy and authority conditions. Model confidence alone never sets severity, authorizes containment, triggers reporting, approves communication, starts recovery or closes the incident.
First-run checklist
- Name the incident manager, deputies and owners for each workstream.
- Define which reversible evidence-collection steps are pre-authorized and which actions always need a fresh human decision.
- Choose the restricted system of record and a secure fallback channel.
- Test unavailable owners, conflicting findings, restricted evidence and channel failure with synthetic records.
- Require a source link, owner and timestamp for every material update.
- Keep closure human-owned and require evidence that approved recovery and communication actions are complete.
The result is a record for the authorized incident team, which still decides what the organization should do.
