Escalation working example

Step 1. Confirm criteria met

Pre-defined criteria check: confirmed malicious activity ✓, business-critical systems affected ✓ (PCI-scoped platform), lateral movement ✓ (federated SSO from compromised identity). Three triggers. No discretion required; escalation is automatic.

Step 2. Choose the path

Internal: Tier 2 incident responder, on-call. External: Compliance notified (PCI clock already started during Scope). Legal counsel looped in (GDPR triggers active). Cloud finance platform vendor request escalated. No law-enforcement engagement at this stage.

Step 3. Build the packet

Nine sections, written and attached:

• Summary: phishing-driven intrusion, 2 hosts compromised, federated SSO into PCI-scoped platform, P1.
• Timeline: 08:32 initial macro execution → 09:11 alert fired → 09:23 federated SSO → 14:00 P1 declared.
• Entities: 3 primary, 3 secondary, 1 downstream system.
• Evidence chain: EDR, network, identity, mailbox, SaaS. ATT&CK chain documented.
• Risk verdict: high impact, high likelihood, P1.
• Containment taken: dlin’s account disabled, two hosts isolated, federated SSO session terminated. Cloud platform queries paused.
• Artifacts: file hashes, domain IoCs, screenshot of the originating email, ATT&CK technique chain.
• Open questions: cloud platform vendor response pending; mobile device activity not yet reviewed.
• Communication record: 14:02 SOC manager paged; 14:08 Tier 2 IR notified; 14:18 compliance flagged (PCI clock); 14:22 legal looped in (GDPR triggers); 14:35 cloud finance platform vendor request opened.

Step 4. Notify stakeholders

Tier 2 IR notified directly. Compliance notified with regulatory implications. Legal looped in. SOC manager informed for shift visibility. The vendor request to the cloud platform is sent in parallel.

Step 5. Transition cleanly

The triage analyst stays on standby for questions but does not continue the investigation. The IR responder owns the case from here. The triage record is locked, the handoff packet is the authoritative reference, and Tier 2 begins work from a complete starting point rather than from scratch.

Step 1. Confirm closure criteria met

Closure criteria check: no confirmed malicious activity ✓, no impact to business-critical systems ✓, no lateral movement ✓, no persistence or credential access ✓, residual risk explicitly bounded ✓. Five criteria. The case meets the bar for documented close, not escalation.

The methodology does not treat “close at triage” as a lesser outcome. It demands the same evidentiary standard: five named criteria, each backed by Uncover findings, each defensible to a peer or auditor.

Step 2. Choose the path

Internal: the detection-engineering team is notified because the rule that fired is over-broad for macOS developer hosts. External: no compliance notification (no regulated data in scope). Manager: SOC manager informed for shift-visibility and review-queue assignment, not for action. User: no user notification; the activity was legitimate, no disruption needed.

The “path” for a close-at-triage is a quieter set of channels than an IR escalation, but it is not zero. Every channel that does receive a notice gets a specific, named reason.

Step 3. Build the closure record

All nine handoff-packet sections, written and attached, same structure as a full escalation, with the verdict reversed:

• Summary: EDR alert on a developer macOS workstation; signed Cursor IDE helper matched an Empire behavioral pattern at the surface, but signature, install path, peer baseline, and absence of persistence all support legitimate IDE behavior. Closed at triage with documented confidence and explicit coverage gaps.
• Timeline: 14:03 alert fired → 14:08 Alert phase complete → 14:22 Subject complete → 14:30 Scope complete → 14:58 Uncover complete → 15:10 Risk verdict → 15:18 closure approved by SOC manager.
• Entities: 1 user, 1 host, 1 vendor binary. No secondary entities required by the evidence.
• Evidence chain: EDR process tree, network destinations, signing chain, MDM compliance record, peer-group baseline. ATT&CK chain explicitly empty, the activity does not map to any technique.
• Risk verdict: low impact, low likelihood, low residual risk. Verdict justified in case notes.
• Containment taken: none. The activity was legitimate; no isolation, no account changes, no policy action.
• Artifacts: EDR query, signing-chain validation, peer-baseline comparison, vendor-endpoint TLS metadata. All linked from the case.
• Open questions: none requiring further investigation. One detection-engineering improvement ticket created (rule tuning for macOS developer host class).
• Communication record: SOC manager notified 15:11 (case visibility). Detection-engineering team notified 15:14 (rule-tuning request). No user notification, no compliance notification, no vendor notification.

Step 4. Notify the right people

Quiet, targeted, and traceable. The SOC manager gets shift visibility. Detection engineering gets the rule-tuning ticket with the specific signal that produced the false-positive. Nobody else needs to be told; loud notifications for a documented false-positive close train the team to discount future ones.

Step 5. Hand to Documentation

The Documentation phase picks up the closure record and finalizes it as the audit-quality event report. The triage analyst stays available for the closure review but does not continue the case, there is nothing to continue. The detection-engineering ticket becomes a separate workstream owned by that team.