SOC Playbook Template (NIST SP 800-61r3, ATT&CK, D3FEND)

SOC Playbook: [Incident type, for example Cloud access key leak or credential compromise]

Playbook for one incident type that the security operations centre (SOC) runs the same way every time it occurs: triggers and detections, triage questions, severity mapping, containment options with decision points, eradication, recovery, evidence handling, notification clocks, MITRE ATT&CK techniques and MITRE D3FEND countermeasures, and the NIST CSF 2.0 Function behind each step. Based on NIST SP 800-61 Rev. 3 Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile (April 2025), the NIST Cybersecurity Framework (CSF) 2.0 (CSWP 29, February 2024), MITRE ATT&CK Enterprise v20 (October 2026) and MITRE D3FEND 1.6.0. Write one playbook per scenario (cloud key leak, business email compromise, ransomware) and keep the organisation-wide rules in the Incident Response Plan (compliance/incident-response-plan). Replace every [bracketed] value and every row marked Example. Worked examples use Corvid Commerce, a fictional SaaS company running on AWS, and the scenario "long-term cloud access key leaked and used by an unknown party".

Document control

Approvals

Revision history

Contents

1. Purpose, scope and boundaries
2. Playbook card
3. Roles and responsibilities
4. Triggers and detections
5. Triage
6. Severity mapping
7. Containment
8. Eradication
9. Recovery
10. Evidence handling
11. Communication and notification clocks
12. ATT&CK techniques and D3FEND countermeasures
13. CSF 2.0 traceability per step
14. Metrics
15. Testing and maintenance
16. Glossary and references
17. Standard and licence note

1. Purpose, scope and boundaries

This playbook tells the SOC how to respond when a cloud credential that grants programmatic access is exposed or used by someone other than its owner. It covers detection, triage, containment, eradication, recovery, evidence and notification for that one scenario. The organisation-wide rules (authority to act, who declares an incident, regulatory duties, retention of incident records) live in the Incident Response Plan (compliance/incident-response-plan). Where the two disagree, the plan wins and this playbook is corrected.

In scope (Example):

• Long-term access keys of cloud identity and access management (IAM) users, found in public or internal code, build logs, container images, tickets, chat or paste sites.
• Keys or session tokens used from an unexpected network, region or client, even if no leak has been found yet.
• Federated workforce credentials used to obtain cloud console or API sessions after a confirmed account takeover.

Out of scope (use the named playbook instead):

2. Playbook card

3. Roles and responsibilities

Role definitions, handover rules and the battle rhythm are defined in the Incident Commander Handbook (ops/incident-commander-handbook). This table only assigns the scenario-specific work.

R = responsible, A = accountable, C = consulted, I = informed.

On-call contacts (Example):

4. Triggers and detections

4.1 Triggers

4.2 Required telemetry

The steps below assume the following logs are collected and searchable for at least the retention period set in the Security Logging Standard (security/security-logging-standard). If a source is missing, record it as a gap in the incident record; it limits what scoping can prove.

5. Triage

5.1 Triage questions

Answer these in order and record each answer, with the evidence, in the case. Stop and go to section 7 as soon as question 2 is "yes" and question 3 is "yes" or "unknown".

5.2 Triage outcomes

6. Severity mapping

Severity levels, their response (paging, incident commander, status page, executive notification, postmortem) and the upgrade and downgrade rules are owned by the Incident Severity Matrix (ops/incident-severity-matrix). For this scenario, apply the most severe row that matches.

Re-assess severity at each status update. Upgrade as soon as scoping finds privileged use, persistence (new keys, users or roles) or data access.

7. Containment

7.1 Containment options

C3 for the IAM user (Example, containment time 2026-09-15 11:36 UTC): attach as an inline policy named [INC-ID]-deny-older-sessions.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenySessionsIssuedBeforeContainment",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "DateLessThan": { "aws:TokenIssueTime": "2026-09-15T11:36:00Z" }
      }
    }
  ]
}

Notes for C3: temporary credentials are valid until they expire (15 minutes to 36 hours), and deactivating or deleting the long-term key does not end them. Keep the policy in place until the longest possible session issued before containment has expired, then remove it and record the removal in the case. Resource-based policies (for example bucket policies) that trust the principal by ARN still need an explicit deny if C2 is not used.

7.2 Decision points

Decision rules (Example):

1. DP-1: If unexpected use is observed, the security incident lead may deactivate the key without waiting for the owner, even if a production service fails. Inform the incident commander within 5 minutes.
2. DP-2: If no misuse is observed and the key serves production, the owner gets at most 60 minutes to deploy a replacement before C1 is applied anyway. Record the decision and the time.
3. DP-3: Never delete the key, the IAM user or attacker-created resources during containment. Deletion destroys metadata needed for scoping (section 10).
4. DP-4: If the audit trail was stopped or modified, restore logging first (the configuration revert of E4, done early), apply C4 to deny further log changes, then continue. Activity during the gap is treated as unknown and scoped from other sources.

7.3 Containment verification

• Key status shows inactive (or deny policy attached) and the change appears in the audit log.
• No successful API call by the principal after the containment time, under any key ID: the long-term key and every temporary session key (prefix ASIA) whose session was issued to the user or to a role it can assume (query re-run 15 and 60 minutes later).
• Every GetSessionToken and GetFederationToken call signed with the key during the exposure window is listed in the scoping record (T3), with the session expiry time.
• The aws:TokenIssueTime deny policy is attached to the IAM user, and AWSRevokeOlderSessions to every role in the principal's trust path.
• Attacker-created resources isolated and tagged incident=[INC-ID].

8. Eradication

9. Recovery

9.1 Recovery steps

1. Deploy the replacement credential, or preferably workload identity, through the normal change process with an expedited approval.
2. Confirm that the business service is healthy against its service level objectives.
3. Verify the integrity of restored or replaced resources: images from the trusted registry, infrastructure from code, data checked against the last known-good backup where data modification was possible.
4. Keep heightened monitoring for [Example: 14 days]: a temporary detection on any use of the old key ID, on the attacker's source networks and on identity changes in the affected accounts.
5. Update the status page and internal stakeholders according to the cadence of the current severity.

9.2 Recovery decision

The incident commander decides to start recovery when containment is verified and eradication steps E1 to E4 are complete. If the attacker had administrative access, the security incident lead must also agree that no persistence remains.

9.3 Exit criteria

• No unexpected use of any affected credential for [Example: 72 hours] after eradication.
• All triage questions answered, with remaining unknowns recorded.
• Notification decisions recorded with their legal basis (section 11).
• Root-cause fix (E6) done, or tracked with an owner and a date.
• Postmortem scheduled using the Postmortem template (dev/postmortem).

10. Evidence handling

Follow the evidence rules of the Incident Response Plan. For this scenario, collect at least the following before eradication:

Chain of custody rules:

• Store evidence in a dedicated forensic account or bucket with object lock, access limited to the response team.
• Record each transfer (who, when, why) in the case.
• Keep evidence for the period set in the Incident Response Plan, or longer if legal counsel places a hold.

11. Communication and notification clocks

The Incident Response Plan (compliance/incident-response-plan) defines which laws, contracts and regulators apply and who decides. This scenario can start the clocks below. Record the "awareness" time in the case, because most clocks run from it.

Internal communication follows the cadence of the current severity level. Never include the key value, full key ID or attacker indicators in open channels; use the private incident channel.

12. ATT&CK techniques and D3FEND countermeasures

ATT&CK Enterprise v20 uses Stealth (TA0005) and Defense Impairment (TA0112) where earlier releases used Defense Evasion. Several techniques were renumbered in that change; for example disabling cloud logs is now T1685.002 under Defense Impairment. Check each ID before reuse. The pairing of each technique with a D3FEND countermeasure below is this playbook's choice of the countermeasure it applies; use the D3FEND site to explore further countermeasures for each technique.

13. CSF 2.0 traceability per step

14. Metrics

Example (Corvid Commerce, Q3 2026): 4 cases. Median time to contain was 42 minutes (values 18, 35, 49 and 95 minutes; the median of the two middle values 35 and 49 is 42; INC-2026-0412 was the 49-minute case). Active long-term keys fell from 120 to 84, a ratio of 0.70.

15. Testing and maintenance

• Run a discussion-based exercise of this scenario at least once a year using the Tabletop Exercise template (security/tabletop-exercise).
• Validate the linked detections with test events after each change to the logging pipeline, using the test cases in section 8 of each Detection Rule Specification (security/detection-rule-spec).
• After every real incident, the postmortem owner checks each step of this playbook against what happened and proposes changes.
• Re-check ATT&CK and D3FEND IDs at each ATT&CK release (normally twice a year) and record the version in Document control.

Change log of lessons applied (Example):

16. Glossary and references

Standard and licence note

Based on NIST SP 800-61 Rev. 3 (April 2025) and the NIST Cybersecurity Framework 2.0 (CSWP 29, February 2024), which are works of the United States Government and not subject to copyright in the United States. Function and Subcategory IDs are cited; all explanations are original text. MITRE ATT&CK technique and tactic names and IDs are used under the ATT&CK terms of use: The MITRE Corporation (MITRE) hereby grants you a non-exclusive, royalty-free license to use ATT&CK® for research, development, and commercial purposes. Any copy you make for such purposes is authorized provided that you reproduce MITRE's copyright designation and this license in any such copy. "© 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation." MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. MITRE D3FEND technique names and IDs are used under the D3FEND Terms of Use (non-exclusive, royalty-free licence for research, development and commercial purposes, provided MITRE's copyright designation and that licence are kept); © 2025 The MITRE Corporation; MITRE D3FEND is a trademark of The MITRE Corporation. AWS is a trademark of Amazon.com, Inc. or its affiliates, and other product names are trademarks of their owners; this template is not affiliated with or endorsed by them. The AWS IAM behaviour in section 7 follows the AWS IAM User Guide as checked in October 2026. Legal deadlines are kept in the Incident Response Plan; this is a documentation format, not legal advice. Check the current official versions at nist.gov, attack.mitre.org and d3fend.mitre.org before use. Original text written for this collection. Template licence: MIT.