Security Case Management Guide: case lifecycle, evidence, SLAs and audit trails

When an investigation is run from chat threads, spreadsheets and analysts' memories, the organisation cannot prove what it knew, when it knew it, who decided what, or whether the evidence it holds is intact. Security case management is the discipline and tooling that turns alerts and reports into accountable records: a case with an owner, a severity, tasks, observables, evidence with chain of custody, a timeline of actions and decisions, and closure criteria. NIST CSF 2.0 makes it explicit in RS.AN-06: actions performed during an investigation are recorded, and the records' integrity and provenance are preserved. This guide is for SOC and CSIRT leads, incident managers and the engineers who run case platforms. It covers the case lifecycle, data model, evidence handling, SLAs, access control, audit trail, tooling choices, metrics and a rollout plan. Automating response actions is a different problem, covered in the SOAR and Security Automation Guide; this page is about the record of the investigation itself.

Key takeaways

• A case is the system of record, not a chat room. Decisions, evidence references and timestamps belong in one auditable record that survives staff changes and legal scrutiny.
• Lifecycle states need entry and exit criteria. Triage, investigation, containment, recovery and closure should each have defined conditions, so a case cannot be closed without root cause, scope and lessons learned.
• Evidence handling is part of the case. Record who collected what, when, where it is stored, its hash and every custody transfer, following RFC 3227 and ISO/IEC 27037 practice.
• SLAs drive behaviour, so measure the right ones. Time to triage and time to containment by severity matter more than raw ticket closure counts.
• The case platform holds the most sensitive data you have. Restrict access per case, protect the audit log from editing, and treat its API keys and integrations as privileged machine identities.

What case management covers and how it differs from SOAR and ticketing

The FIRST CSIRT Services Framework (v2.1) describes the functions a case record supports without naming a tool: report receipt and triage ("review, categorize, prioritize, and process"), information collection ("intake, catalog, store, and track information related to the information security incident"), tracking of outsourced analysis, tracking mitigation activities until the incident is closed, and tracking "the status of all communication and activities" during coordination. A good case platform is the place those functions leave a record.

Integration rule of thumb: alerts become cases only when a human or a rule decides they merit investigation; remediation tasks for IT are linked tickets, not copies of the case. Sensitive investigation detail (insider suspects, legal advice) should not flow into a general ITSM tool visible to the whole IT department.

The case lifecycle

Escalation and re-opening: any state can escalate severity (RS.MA-04). Re-opening a closed case should create a linked child case or an audited state change, never a silent edit. For the severity scheme itself, use the Incident Severity Classification Matrix Template.

The case record: fields that matter

• Identity of the case: unique ID, title, category (for example a taxonomy aligned to your incident response plan), severity, TLP marking for sharing, owner, deputy, and related case links.
• Timeline: time of first malicious activity (when known), detection, report, triage, declaration, containment, recovery and closure, all in UTC. RFC 3227 recommends recording whether times are system time or UTC.
• Scope objects: affected assets, accounts and identities, data types, business services, and third parties, each linked to inventory records where possible.
• Observables and indicators: IPs, domains, hashes, URLs, account names, with a flag for whether each is a confirmed indicator. Platforms such as TheHive support bulk observable import, including from MISP events, and checks for previously seen observables across cases.
• Tasks: assigned, time-stamped and linked to a playbook step; templates for common case types keep investigations consistent.
• Decisions log: who decided to contain, notify, pay, involve law enforcement or close, when and on what evidence. This is the record regulators and courts ask for.
• Evidence register: see the next section.
• Communications: notifications sent internally and externally (RS.CO-02, RS.CO-03), regulator deadlines and the reference numbers of any reports filed.
• Closure fields: root cause, ATT&CK techniques observed, control gaps, lessons learned and follow-up actions with owners and due dates.

Evidence and chain of custody inside the case

RFC 3227 (Guidelines for Evidence Collection and Archiving, BCP 55, February 2002) remains the clearest short statement of what to record. It asks responders to document where, when and by whom evidence was discovered and collected; where, when and by whom it was handled or examined; who had custody and for what period and how it was stored; and when custody changed hands and how the transfer took place. It also sets the order of volatility, from registers and cache, through memory and process tables, temporary file systems and disk, to remote logs, physical configuration and archival media.

Keep large evidence (disk and memory images) in a dedicated evidence store and record references and hashes in the case, rather than uploading images as case attachments. Detailed acquisition and custody practice is in the Evidence Handling and Chain of Custody Guide. Where counsel directs the investigation, mark privileged material and restrict it; see the Legal Privilege in Incident Response Guide.

SLAs, prioritisation and workload

These values are illustrative starting points, not a standard; set yours from risk appetite, staffing and any regulatory reporting deadlines that apply to you. Regulatory clocks (for example notification windows under data protection or sector rules) should appear as explicit deadline fields on the case, calculated from the moment the organisation became aware, so they cannot be missed.

• Pause rules: define when the SLA clock pauses (waiting for a third party) and require a reason, otherwise pauses hide delays.
• Work in progress limits: cap open critical and high cases per analyst; queue depth beyond that signals a staffing problem, not an analyst problem. See the SOC Staffing and Shift Models Guide.
• Shift handover: every open high or critical case gets a handover note in the case itself, not in a separate document.

Access control, audit trail and the identities behind the platform

• Need to know per case: insider, HR, executive and legal cases must be restricted to named people; default visibility for routine cases can be team-wide. Review membership of restricted cases at closure.
• Immutable audit log: every create, edit, state change, attachment, export and permission change should be logged with user and time, and the log should be outside the reach of case editors (NIST SP 800-53 AU-9 Protection of Audit Information; AU-10 Non-repudiation for decisions that may be contested).
• Retention: set retention by case category and legal requirement (AU-11 Audit Record Retention), with legal hold overriding deletion.
• Strong authentication: SSO with phishing-resistant MFA for analysts, and break-glass local accounts stored offline for when the identity provider is the thing under attack.
• Integration credentials: SIEM, EDR, SOAR, email and threat intelligence integrations authenticate with API keys or service accounts that can read and write every case. Give each integration its own credential, scope it to the minimum, store it in a vault and rotate it. A stolen case platform key reveals your investigations to the attacker. See the Service Account Security Guide.
• Out-of-band operation: if the attacker may be in email or chat, run critical cases from a platform and communication channel they cannot reach, and record that decision in the case.

Choosing and running a case platform

Small versus large: a small team can run case management in an ITSM security module or an open source platform with strict restricted-case settings and a separate evidence store. A large SOC needs case templates per incident type, automated case creation from correlated alerts, reporting across hundreds of cases, and integration with SOAR and the TIP. Whatever the size, plan for the case platform being unavailable during a major incident and keep an offline fallback (a printed or offline template) for critical cases.

Rollout plan

1. Define the model: lifecycle states, mandatory fields per state, categories and severity, aligned to the incident response plan and NIST SP 800-61 Rev. 3 (a CSF 2.0 Community Profile published April 2025).
2. Configure access: SSO, MFA, roles, restricted case groups and audit log export to the SIEM.
3. Build templates: start with phishing, malware on endpoint, account compromise and data exposure; each with tasks, evidence prompts and closure checks. The SOC Runbook Template helps.
4. Pilot: run one shift or one incident type for four weeks; review records for completeness and fix the template, not the analysts.
5. Integrate: alert-to-case creation, MISP or TIP observable lookups, ITSM links for remediation tasks, each with its own vaulted credential.
6. Migrate and retire: move open investigations, archive old spreadsheets read-only with a pointer to the new system, and keep the old tool's export for retention purposes. Roll back by reverting case creation rules to the previous queue if the new platform fails during the pilot.

Detection and measurement

• Mean and 90th percentile time to triage, by severity, against SLA.
• Time from declaration to containment, by severity and category.
• Case record completeness: percentage of closed cases with root cause, scope, decision log and lessons learned filled in (target 100 per cent for high and critical).
• Evidence integrity: percentage of evidence items with an acquisition hash and complete custody record.
• Reopen rate: cases reopened within 30 days, a sign of premature closure.
• Follow-up action closure: percentage of post-incident actions completed by due date.

Alert the SOC on unusual activity in the case platform itself: bulk exports, permission changes on restricted cases, new API keys and logins from new locations. Broader SOC measures are in the Security Operations Metrics Guide.

Framework mapping

Common failure patterns

• Decisions made off the record: containment and notification choices agreed in a call and never written into the case, leaving no defensible account later.
• Closing on containment: cases closed once the host is reimaged, without root cause or scope, so the same entry point is used again.
• Evidence as attachments: images and logs uploaded into the case without hashes or custody records, or kept on an analyst's laptop.
• Everyone can see everything: an insider or executive case readable by the whole SOC, or synced into ITSM where the subject can see it.
• Shared integration key: one admin API key used by every integration and stored in a script, giving anyone who finds it read access to every investigation.
• Records that support concealment: when an incident is handled outside normal records and notification decisions are not documented, the consequences can be severe. In the Uber Breach 2016, the intrusion was handled through a bug bounty payment and NDAs and not disclosed for a year; the former chief security officer was later convicted of obstruction and misprision of a felony.

Practitioner checklist

• Define lifecycle states with entry and exit criteria and mandatory fields for each.
• Add a decisions log and regulatory deadline fields to every case template.
• Keep an evidence register with hashes and custody transfers, and store images in a controlled evidence store.
• Set severity-based triage, update and containment targets, with audited SLA pauses.
• Restrict sensitive cases to named members and review access at closure.
• Export the case platform audit log to the SIEM and protect it from case editors.
• Give each integration its own scoped, vaulted credential and rotate it.
• Require root cause, scope and lessons learned before closing high and critical cases.
• Prepare an out-of-band and offline fallback for when the platform or identity provider is compromised.

Standards and references

• FIRST: CSIRT Services Framework Version 2.1
• NIST: SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management
• NIST: Cybersecurity Framework 2.0
• NIST: SP 800-53 Rev. 5
• IETF: RFC 3227 Guidelines for Evidence Collection and Archiving
• ISO: ISO/IEC 27035-1:2023 Information security incident management, Part 1
• StrangeBee: TheHive documentation
• DFIR-IRIS: IRIS incident response investigation system

Related NHI Mgmt Group resources: SOAR and Security Automation Guide · Incident Response Guide · Evidence Handling and Chain of Custody Guide · SOC Guide