<!-- Copyright (c) 2026 defconxt. All rights reserved. -->
<!-- Licensed under AGPL-3.0 — see LICENSE file for details. -->
---
name: implementing-incident-ticket-management
description: >-
  Incident ticket lifecycle management for SOC operations including ticket
  creation standards, escalation workflows, SLA tracking, evidence attachment,
  status transitions, closure criteria, and integration between SIEM platforms
  and ITSM tools like ServiceNow and Jira.
domain: cybersecurity
subdomain: soc-operations
tags:
  - incident-tickets
  - soc
  - itsm
  - servicenow
  - jira
  - escalation
  - sla
  - case-management
version: "1.0"
author: defconxt
license: AGPL-3.0
metadata:
  mitre-attack: []
---

# Implementing Incident Ticket Management

## Overview

Incident ticket management ensures every security event is tracked from
detection through resolution with full audit trail. Proper ticketing enables
SLA enforcement, workload distribution, metric collection, and regulatory
compliance. This skill covers ticket lifecycle standards, SIEM-to-ITSM
integration, and quality gates for security incident documentation.

## Prerequisites

| Requirement | Purpose |
|---|---|
| ITSM platform (ServiceNow/Jira) | Ticket creation and tracking |
| SIEM (Splunk ES/Elastic/Sentinel) | Alert-to-ticket automation |
| SOAR platform (optional) | Automated ticket creation |
| Escalation matrix | Routing and assignment rules |

## Key Concepts

### Ticket Lifecycle States

```
INCIDENT TICKET LIFECYCLE:
├── New — Alert promoted to incident, ticket created
│   Required: title, severity, category, source alert IDs
├── Assigned — Analyst takes ownership
│   Required: owner, initial assessment, investigation plan
├── In Progress — Active investigation underway
│   Required: evidence collection, timeline updates, IOCs
├── Escalated — Transferred to higher tier or external team
│   Required: escalation reason, receiving team, handoff notes
├── Pending — Awaiting external input or action
│   Required: who/what is pending, expected response time
├── Resolved — Threat contained, root cause identified
│   Required: root cause, containment actions, remediation plan
└── Closed — Post-incident review complete
    Required: lessons learned, detection improvements, final timeline
```

### Ticket Quality Standards

```
MINIMUM TICKET FIELDS:
  Title:        [Severity] [Category] — Brief description
  Severity:     P1 Critical | P2 High | P3 Medium | P4 Low
  Category:     Malware | Phishing | Unauthorized Access | Data Exfil | DoS
  Source:       Alert ID(s) from SIEM
  Affected:     Systems, users, data classification
  Timeline:     Detection time, first indicator, key events
  IOCs:         IPs, domains, hashes, filenames
  Evidence:     Screenshots, log excerpts, PCAP references
  Actions:      Steps taken with timestamps
  Root Cause:   What happened and why (on resolution)

QUALITY GATE CHECKLIST:
  □ Title follows naming convention
  □ All mandatory fields populated
  □ Evidence attached (not just referenced)
  □ Timeline entries have timestamps
  □ IOCs extracted and formatted
  □ Affected assets identified with criticality
  □ Resolution includes verification steps
```

### ServiceNow Integration

```bash
# Create security incident via API
curl -s -X POST "${SNOW_URL}/api/now/table/sn_si_incident" \
  -H "Authorization: Bearer ${SNOW_TOKEN}" \
  -H "Content-Type: application/json" \
  -d '{
    "short_description": "[P2] Phishing — Credential harvesting campaign",
    "severity": "2",
    "category": "Phishing",
    "assignment_group": "SOC Tier 1",
    "description": "Multiple users reported phishing emails..."
  }'

# Attach evidence to incident
curl -s -X POST "${SNOW_URL}/api/now/attachment/file" \
  -H "Authorization: Bearer ${SNOW_TOKEN}" \
  -H "Content-Type: multipart/form-data" \
  -F "table_name=sn_si_incident" \
  -F "table_sys_id=${INCIDENT_ID}" \
  -F "file=@evidence_screenshot.png"
```

### Jira Security Incident Workflow

```bash
# Create incident issue
curl -s -X POST "${JIRA_URL}/rest/api/3/issue" \
  -H "Authorization: Bearer ${JIRA_TOKEN}" \
  -H "Content-Type: application/json" \
  -d '{
    "fields": {
      "project": {"key": "SEC"},
      "issuetype": {"name": "Security Incident"},
      "summary": "[P2] Phishing — Credential harvesting campaign",
      "priority": {"name": "High"},
      "labels": ["soc", "phishing", "active"]
    }
  }'
```

### Splunk ES to Ticket Automation

```spl
-- Notables ready for ticket creation
| from datamodel:"Notable"
| where urgency IN ("critical","high") AND status="new"
| eval ticket_title=urgency." - ".rule_name." — ".src." → ".dest
| table _time, ticket_title, urgency, rule_name, src, dest, user
```

## Workflow

1. **Create** — Generate ticket from promoted alert with required fields
2. **Assign** — Route to appropriate analyst based on category and severity
3. **Investigate** — Update ticket with findings, evidence, timeline entries
4. **Escalate** — Transfer with context when tier boundary reached
5. **Resolve** — Document root cause, containment, and remediation
6. **Review** — Quality gate check before closure
7. **Close** — Archive with lessons learned and metric data

## Verification

| Check | Method |
|---|---|
| Ticket created for all TP alerts | Alert-to-ticket ratio audit |
| Mandatory fields populated | Quality gate automated check |
| Evidence attached | Attachment count > 0 on closure |
| SLA tracked per severity | SLA breach report review |
| Escalation context complete | Receiving team can continue without callback |
