When a case in ANCHOR meets the incident threshold — confirmed breach, active threat actor, spreading compromise, or significant business impact — the analyst promotes it to SHIELD with a single action. The full case record carries forward automatically — every note, every piece of evidence, every linked alert, and the complete investigative history. At declaration, severity is assessed against defined criteria and a tier is assigned — P1 through P4 — which determines the response template, escalation path, and SLA thresholds that govern the response from that moment forward.

SHIELD supports four severity tiers — P1 through P4. P1 represents a critical incident with active threat actor presence, confirmed data exfiltration, or significant business impact requiring immediate executive involvement. P2 represents a high severity incident with confirmed compromise and contained but unresolved threat activity. P3 represents a medium severity incident with suspected compromise requiring investigation and structured response. P4 represents a low severity incident with minimal business impact and a clear resolution path. Each tier carries defined escalation paths, notification requirements, SLA thresholds, and response templates.

Everything the case built in ANCHOR carries forward automatically — every investigation note, every evidence attachment, every linked alert, the complete status history, the full analyst assignment record, and the SLA compliance data from the case phase. The incident record in SHIELD begins with the complete investigative context already in place. The response team starts fully informed rather than reconstructing what the investigation team already knew.

Every declared incident in SHIELD has a designated Incident Commander responsible for overseeing the full response. Supporting analysts are assigned to specific workstreams — containment, eradication, communications, and evidence collection — with their assignments visible to the full team in real time. Every action is logged against the analyst who took it with timestamp and outcome recorded. The response workspace shows every open task, every completed action, and every pending decision in a single view, giving the Incident Commander real-time situational awareness without having to chase status updates from every team member.

When an incident is declared, SHIELD automatically surfaces the runbook associated with the incident type and severity. The runbook opens within the incident workspace — phase by phase, step by step — with each action tracked to completion and timestamped as it is verified. Required steps cannot be bypassed without a recorded justification. Optional steps can be skipped with a single action. The full execution record — every step, every analyst, every timestamp, every deviation — becomes part of the incident record and feeds directly into post-incident review and compliance reporting.

SHIELD builds the incident timeline automatically as the response progresses — every action, every decision, and every development recorded with timestamp and analyst attribution the moment it happens. There is no separate documentation step and no reconstruction after the fact. The timeline that exists at closure is the timeline that was built during the response — accurate to the second and complete by design. It exports in formats suitable for regulatory submission, legal proceedings, post-incident review, and executive briefing.

Evidence attaches directly to the incident record as it is collected — forensic images, memory captures, log exports, network captures, screenshots, and supporting documents. Every attachment is timestamped, attributed to the analyst who added it, and organized chronologically within the incident timeline. Evidence is searchable by type, analyst, and date range. It remains permanently attached to the incident record — it cannot be separated from the investigation it belongs to — and is available for export in formats suitable for legal and regulatory use.

SHIELD maintains a dedicated communications log within every incident record — capturing every stakeholder notification, status update, and external communication associated with the incident. Notifications are templated by severity and incident type, pre-populated with current incident status, and sent directly from within the platform. The log captures who was notified, what they were told, when the notification was sent, and who sent it. Regulatory notification deadlines triggered by the incident are tracked and surfaced before they are missed, ensuring compliance obligations are met without requiring the response team to manage them manually.

SHIELD organizes the containment and eradication phase around a structured checklist tied to the incident type and severity. Each action — system isolation, account suspension, network segmentation, credential rotation, malware removal — is tracked as a discrete task with an assigned analyst, a target system or resource, a completion status, and a verification step. The Incident Commander sees the real-time containment picture — what is done, what is in progress, and what still needs attention — without having to ask. The response does not move to recovery until every containment and eradication action is documented as complete and verified.

Closure requires a documented disposition — what happened, what was done, and why the incident is considered resolved. Every metric associated with the incident — time to declare, time to contain, time to eradicate, time to recover, and total incident duration — is captured and fed into SCOUT's reporting layer. The SLA record is finalized. The incident record is sealed and preserved. SHIELD then initiates the post-incident review workflow automatically, ensuring that the learning phase follows the response phase without requiring a separate decision to make it happen.

SHIELD initiates a structured post-incident review workflow at incident closure — a defined process that examines the complete incident record and produces documented findings covering what happened, what worked, what failed, and what needs to change. Every finding is assigned an owner and a remediation deadline. Detection gaps feed into BLADE. Process failures feed into ANCHOR. Threat model updates feed into TIME. The review produces a Post-Incident Report that exports in formats suitable for executive briefing, regulatory submission, and board reporting.

SHIELD captures a comprehensive set of incident metrics automatically — mean time to declare, mean time to contain, mean time to eradicate, mean time to recover, total incident duration, SLA compliance by severity tier, escalation rates by incident type, runbook adherence rates, and post-incident review completion rates. These metrics feed directly into SCOUT's reporting layer, producing the operational performance data SOC managers need to run the program and the evidence CISOs need to brief the board — without requiring a separate reporting project to produce them.

SHIELD sits at the center of the SCOUT response chain. It receives promoted cases from ANCHOR with full investigative context, surfaces relevant threat intelligence from CIPHER to inform response decisions, incorporates threat model context from TIME to understand blast radius and lateral movement risk, links hunt findings from PROWL that contributed to detection, and feeds post-incident findings into BLADE for detection engineering improvements. Every incident SHIELD processes makes the detection, hunting, and modeling capabilities of the full SCOUT platform stronger.

SHIELD supports regulatory compliance in three ways. First, every action taken during an incident is recorded in an immutable audit log with timestamp and attribution — producing the documented evidence regulators require without additional effort from the response team. Second, regulatory notification deadlines triggered by the incident are tracked within the platform and surfaced before they are missed — ensuring compliance obligations are met under the pressure of an active response. Third, the Post-Incident Report generated at closure exports in formats suitable for regulatory submission — providing the complete, formatted documentation that demonstrates the incident was handled in accordance with applicable requirements.

Yes. SHIELD manages every active incident in parallel — each with its own response workspace, its own timeline, its own team assignments, its own runbook execution record, and its own SLA clock. The manager view surfaces all active incidents simultaneously — by severity, by phase, and by SLA health — giving the SOC lead the situational awareness to allocate resources across multiple concurrent responses without losing visibility into any of them. Each incident remains fully isolated in its own record while remaining visible in the aggregate view that leadership needs.