# SOC response workpack

Turn an alert into an incident decision, evidence and a recovery test.

SecNet.Work | 2026.10 | 2026-10-21

An alert does not establish a confirmed incident or its full scope. Analysts distinguish hypotheses from evidence; the incident lead coordinates business impact and response authority. NIST SP 800-61 Rev. 3, final in April 2025, connects response with wider risk management. This account-compromise example keeps timeline, response and learning together.

## Work boundary
Enterprise SOC and incident teams. Do not upload real keys, session tokens or personal logs; evidence remains in the organization’s authorized repository.

## Process

### 1. Enrich the alert
Validate user, device, source, time zone and detection reason. Explicitly state telemetry gaps. An unusual location alone is not evidence of malicious intent; correlate it with other signals.

Expected evidence: Alert ID and scoped initial record

### 2. Establish decision and scope
Separate suspicion, verified findings and affected assets. Assign severity and authority using the organizational plan. Legal and notification assessment depends on relevant scope and actual findings.

Expected evidence: Incident decision and timeline

### 3. Contain
Choose account, session and device controls with business impact in mind. Record who authorized each action and when it ran. A password change may not automatically revoke existing tokens in every system.

Expected evidence: Authorized action and execution result

### 4. Test persistence and recovery
Inspect persistence paths such as new app permissions, forwarding rules and identity changes. Observe the same signals after recovery. A clean view does not establish safety in unmeasured areas.

Expected evidence: Persistence review and retest

### 5. Translate learning into actions
Explain detection and delay. Assign owners and dates for logging gaps, control corrections and exercises. A lessons-learned meeting does not mean actions are complete.

Expected evidence: Action, owner and verification plan

## One control, three perspectives

### Operator
Which finding is verified?
Separate hypothesis from evidence.
Evidence: Sourced timeline

### Auditor
Is the response traceable?
Link decision and execution within the incident.
Evidence: Authorization and execution record

### Leader
When can operations safely recover?
Agree recovery criteria with the owner.
Evidence: Residual risk and recovery test

## Evaluate evidence

**Claim:** Compromised sessions were revoked.

**Weak support:** A password-changed screenshot.

**Stronger support:** Identity-provider revocation, target-session scope and verification that the old session cannot access are available.

**Rationale:** Password change and token revocation may be different operations. Measure system-specific results.

## Decision desk
A user has an unusual sign-in and a new forwarding rule.
Start: start

### start
First decision?

- **Correlate signals and establish scope and authority** (good)
  You are examining both findings in one incident context. Now verify the applied control.
  Next: verify

- **Only change the password and close** (risk)
  Forwarding and active sessions may persist. Closure requires scoped verification.
  Next: repair

- **Close without a rationale** (incomplete)
  Deferring an open issue is not closure evidence. Record the uncertainty, owner and next verification step.
  Next: revise

### verify
The password changed, but an old session remains active.

- **Perform authorized revocation and persistence review** (good)
  You tie the control to actual access. Keep the incident open until revocation and forwarding checks are verified.
  Next: planned

- **Accept the claim without testing** (risk)
  The initial claim and observed result differ. Support closure with a repeatable check in the same scope, rather than a promise or ticket status.
  Next: revise

### repair
An export trace appears after closure.

- **Reassess, preserve evidence and escalate to the relevant team** (good)
  The finding may change scope. Authorized teams reassess data impact and notification needs.
  Next: planned

- **Delete the earlier record and close** (risk)
  Deleting the earlier decision undermines learning and accountability. Link the new action to the prior record and keep the rationale and residual risk visible.
  Next: revise

### supported
This decision is supported by the evidence in the example. Verify closure conditions in your own scope.

### revise
The decision lacks support. Record the rationale and required evidence, then reassess.

### planned
A remediation path is defined. Keep the matter open until implementation and verification are complete.

## Worked example
Entirely fictional.
- Time / zone: 10:15 UTC
- Source: Synthetic identity log
- Finding: Old session active
- Hypothesis: Token may persist
- Decision: Revoke and test
- Authority: Incident lead
- Action: Fictional IR-014
- Verification: Old session access rejected

## Closure checklist
- [ ] Time zones consistent.
- [ ] Findings and hypotheses separated.
- [ ] Action authority and evidence trail recorded.
- [ ] Recovery and learning actions tracked.

## Official sources
- [NIST SP 800-61 Rev. 3 — Final, April 2025](https://csrc.nist.gov/pubs/sp/800/61/r3/final)
- [NIST Cybersecurity Framework 2.0](https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final)

https://secnet.work/learn/toolkits/soc-response