Runbook 04 — SOC Alert Enrichment, Correlation and Triage

Runbook Information

Runbook Type: SOC Operations / Detection Triage / Security Automation
Difficulty: Intermediate → Advanced
Primary Audience: SOC Analysts / Detection Engineers / Incident Responders / Security Automation Engineers
Security Domains: SOC / SIEM / EDR / Identity Security / Cloud Security / Threat Intelligence / Vulnerability Management
Execution Model: Analyst-assisted alert triage workflow
Primary Goal: Turn raw alerts into context-rich, prioritized, explainable investigations

Purpose

Security monitoring platforms generate alerts from:

SIEM

EDR / XDR

IDENTITY SYSTEMS

FIREWALLS

CLOUD SECURITY TOOLS

EMAIL SECURITY

VULNERABILITY MANAGEMENT

APPLICATION SECURITY

NETWORK DETECTION

But a raw alert rarely contains enough information to make a reliable security decision.

Example:

ALERT:
FAILED LOGIN

USER:
admin01

SOURCE IP:
203.0.113.25

SEVERITY:
MEDIUM

By itself, this tells the analyst very little.

Once enriched:

USER:
admin01

PRIVILEGED:
YES

ACCOUNT:
ENABLED

ASSET:
JUMP01

ASSET CRITICALITY:
CRITICAL

ENVIRONMENT:
PRODUCTION

RELATED ALERT:
SUCCESS AFTER FAILURES

IOC CONTEXT:
REVIEW REQUIRED

OPEN VULNERABILITIES:
1

the analyst has a much stronger basis for triage.

Core Principle

Never assume:

ALERT
=
INCIDENT

Instead:

ALERT
      ↓
VALIDATE
      ↓
ADD CONTEXT
      ↓
CORRELATE
      ↓
ASSESS
      ↓
ANALYST DECISION

SOC Triage Architecture

RAW ALERT
    ↓
VALIDATION
    ↓
NORMALIZATION
    ↓
DEDUPLICATION
    ↓
ENRICHMENT
┌────┼────┬─────┬─────┐
↓    ↓    ↓     ↓     ↓
USER ASSET IOC  VULN  CLOUD
└────┼────┴─────┴─────┘
     ↓
CORRELATION
     ↓
RISK / PRIORITY
     ↓
ANALYST QUEUE
     ↓
INVESTIGATION
     ↓
DISPOSITION
     ↓
ESCALATE / CLOSE

01 — Start with the Alert Source

Identify:

WHICH SECURITY CONTROL
GENERATED THE ALERT?

Examples:

SIEM RULE

EDR DETECTION

CLOUD SECURITY FINDING

IDENTITY RISK ALERT

EMAIL SECURITY ALERT

NETWORK IDS

02 — Record Alert Metadata

Minimum useful metadata:

ALERT ID

SOURCE PLATFORM

RULE ID

RULE NAME

TIMESTAMP

SEVERITY

STATUS

03 — Preserve Detection Rule ID

Example:

AUTH-002

This allows analysts to trace the alert back to:

DETECTION LOGIC

04 — Preserve Detection Version

Include:

rule_version

where available.

This matters because detection logic changes over time.

05 — Preserve Raw Alert

Before transformation:

STORE RAW ALERT

where policy allows.

Use:

RAW
 ↓
COPY
 ↓
NORMALIZE

06 — Validate Required Fields

Typical required fields:

alert_id

timestamp

source

alert_type

severity

07 — Validate Timestamp

Confirm:

VALID FORMAT

KNOWN TIMEZONE

REASONABLE VALUE

08 — Normalize Time

Preferred internal format:

UTC

ISO 8601

Example:

2026-08-29T08:18:00Z

09 — Validate Severity

Normalize into:

critical

high

medium

low

informational

unknown

10 — Preserve Original Severity

Store both:

source_severity

and:

normalized_severity

when appropriate.

11 — Validate Alert Status

Common normalized statuses:

new

in_review

closed

suppressed

unknown

12 — Normalize Identity

Examples:

DOMAIN\Admin01

admin01

admin01@example.com

may refer to the same or different identities.

Prefer stable identity IDs when available.

13 — Normalize Asset

Examples:

web01

WEB01

web01.example.local

Normalize carefully while preserving useful:

FQDN

ASSET ID

14 — Normalize IP Addresses

Validate:

SOURCE IP

DESTINATION IP

using proper IP parsing.

15 — Normalize Indicators

Indicators may include:

IP

DOMAIN

URL

FILE HASH

Use consistent representation before matching.

16 — Quarantine Invalid Alerts

If a record is malformed:

DO NOT
SILENTLY DROP IT

Move it to:

INVALID ALERT QUEUE

with a reason.

17 — Record Validation Reason

Example:

ALERT-1005

STATUS:
INVALID

REASON:
Timestamp could not be parsed

18 — Deduplicate Alerts

Duplicate alerts may be caused by:

RETRIES

FORWARDER DUPLICATION

MESSAGE REDELIVERY

MULTIPLE COLLECTORS

19 — Use Stable Deduplication Keys

Preferred:

ALERT ID

when globally reliable.

Otherwise use a fingerprint.

20 — Example Fingerprint

Potential fields:

source

rule_id

user

asset

indicator

time_bucket

21 — Avoid Over-Deduplication

These:

FAILED LOGIN

SUCCESSFUL LOGIN

are related events.

They are not duplicates.

22 — Preserve Duplicate Count

Instead of simply deleting duplicates, track:

duplicate_count

first_seen

last_seen

where useful.

23 — Begin Enrichment

After normalization:

ALERT
 ↓
WHO?
 ↓
WHAT ASSET?
 ↓
WHAT INDICATOR?
 ↓
WHAT VULNERABILITIES?
 ↓
WHAT CLOUD CONTEXT?

24 — Identity Enrichment

Query an authoritative identity source.

Collect:

IDENTITY ID

USERNAME

DEPARTMENT

ACCOUNT TYPE

ENABLED STATUS

PRIVILEGED STATUS

OWNER / MANAGER

25 — Privileged Identity

If:

privileged = true

increase analyst attention.

Do not automatically conclude:

COMPROMISE

26 — Disabled Identity

An event involving:

DISABLED ACCOUNT

may deserve review.

Possible causes:

STALE EVENT

SERVICE DEPENDENCY

MISCONFIGURATION

UNEXPECTED ACCOUNT USE

27 — Service Accounts

Treat:

SERVICE ACCOUNT

differently from:

HUMAN USER

because expected behavior differs.

28 — Identity Context Failure

If identity lookup fails:

IDENTITY CONTEXT
=
UNAVAILABLE

not:

USER IS LOW RISK

29 — Asset Enrichment

Collect:

ASSET ID

HOSTNAME

ENVIRONMENT

CRITICALITY

OWNER

INTERNET EXPOSURE

ASSET TYPE

30 — Critical Asset

Examples:

DOMAIN CONTROLLER

JUMP HOST

DATABASE SERVER

PAYMENT SYSTEM

PRODUCTION API

may require higher triage priority.

31 — Environment

Differentiate:

PRODUCTION

STAGING

DEVELOPMENT

TEST

32 — Internet Exposure

Ask:

IS THE ASSET
INTERNET-FACING?

This can materially change risk context.

33 — Unknown Asset

If asset inventory lookup fails:

asset_found = false

Treat as:

CONTEXT GAP

not:

LOW-RISK ASSET

34 — IOC Enrichment

Potential sources:

INTERNAL THREAT INTELLIGENCE

COMMERCIAL FEED

OPEN-SOURCE FEED

SANDBOX RESULTS

35 — Collect IOC Metadata

Useful fields:

INDICATOR

TYPE

SOURCE

CONFIDENCE

CLASSIFICATION

FIRST SEEN

LAST SEEN

EXPIRATION

36 — IOC Match Principle

Remember:

IOC MATCH
≠
CONFIRMED COMPROMISE

37 — No IOC Match Principle

Also:

NO IOC MATCH
≠
BENIGN

38 — IOC Lookup Failure

Distinguish:

NO MATCH

from:

LOOKUP FAILED

39 — IOC Freshness

A stale indicator may have less value than a recently observed one.

Review:

last_seen

and source reliability.

40 — Vulnerability Enrichment

For affected assets collect:

OPEN VULNERABILITIES

CRITICAL VULNERABILITIES

CVSS

KNOWN EXPOSURE

REMEDIATION STATUS

41 — Vulnerability + Alert Context

Example:

SUSPICIOUS PROCESS
+
CRITICAL VULNERABILITY

may deserve stronger investigation than either finding alone.

42 — Vulnerability Presence Is Not Exploitation

Do not assume:

VULNERABILITY EXISTS
=
VULNERABILITY EXPLOITED

43 — Cloud Context

For cloud alerts collect:

PROVIDER

ACCOUNT / SUBSCRIPTION / PROJECT

RESOURCE ID

RESOURCE TYPE

PUBLIC EXPOSURE

ENCRYPTION

IDENTITY

SECURITY FINDINGS

44 — Cloud Scope

Always establish:

WHICH ACCOUNT?

WHICH SUBSCRIPTION?

WHICH PROJECT?

45 — Cloud Ownership

Determine:

RESOURCE OWNER

APPLICATION OWNER

PLATFORM OWNER

46 — Cloud Finding Correlation

Example:

IDENTITY ALERT
+
PRIVILEGED CLOUD USER
+
MFA CONTROL FAILURE

may require elevated review.

47 — Detection Context

Enrich the alert with:

RULE PURPOSE

DATA SOURCE

RULE VERSION

EXPECTED FALSE POSITIVES

KNOWN EXCEPTIONS

48 — Why Detection Context Matters

A rule detecting:

MULTIPLE FAILED LOGINS

may be expected during:

PASSWORD EXPIRY

VPN TROUBLESHOOTING

SERVICE MISCONFIGURATION

49 — Review Rule Documentation

Analyst should know:

WHAT BEHAVIOR
THE RULE WAS DESIGNED
TO DETECT

50 — Business Context

Useful business data may include:

CHANGE WINDOW

MAINTENANCE WINDOW

AUTHORIZED SCAN

PENETRATION TEST

KNOWN DEPLOYMENT

USER TRAVEL

51 — Authorized Activity

Example:

VULNERABILITY SCANNER

may generate traffic that resembles reconnaissance.

Validate source before escalating.

52 — Exceptions

Review approved:

SUPPRESSIONS

RISK ACCEPTANCES

EXCEPTIONS

53 — Exception Requirements

Every exception should have:

OWNER

JUSTIFICATION

SCOPE

EXPIRATION

54 — Avoid Permanent Exceptions

An exception from:

LAST YEAR

may no longer be valid.

55 — Begin Correlation

Correlation asks:

WHAT ELSE IS RELATED?

56 — Correlation Dimensions

Common:

USER

ASSET

SOURCE IP

DESTINATION IP

INDICATOR

RULE

TIME

CLOUD RESOURCE

57 — Same User Correlation

Example:

FAILED LOGIN

MFA FAILURE

SUCCESSFUL LOGIN

PRIVILEGE CHANGE

in a short time window.

58 — Same Asset Correlation

Example:

SUSPICIOUS PROCESS

NETWORK ALERT

VULNERABILITY FINDING

on:

WEB01

59 — Same Source IP

Example:

SOURCE IP
203.0.113.25

appears across:

MULTIPLE USERS

This may indicate broader activity or benign shared infrastructure.

Investigate context.

60 — Same Indicator

A domain or hash observed on multiple assets may justify grouping.

61 — Time-Window Correlation

Always consider:

TIME

62 — Example Authentication Sequence

08:15
FAILED LOGINS

08:18
SUCCESSFUL LOGIN

same:

USER

SOURCE IP

deserves more attention than events separated by months.

63 — Choose Time Window by Use Case

Examples:

5 MINUTES

15 MINUTES

30 MINUTES

1 HOUR

There is no universal correct window.

64 — Sequence Matters

These:

FAILED LOGIN
 ↓
SUCCESS

have different meaning from:

SUCCESS
 ↓
FAILED LOGIN

65 — Correlation Does Not Prove Causation

Remember:

RELATED IN TIME

does not automatically mean:

SAME ATTACK

66 — Build Investigation Timeline

Example:

08:15
Multiple failed logins

08:18
Successful login

08:21
EDR alert on JUMP01

08:24
Cloud authentication alert

67 — Timeline Helps Analysts

It helps answer:

WHAT HAPPENED FIRST?

WHAT HAPPENED NEXT?

WHICH EVENTS MAY BE RELATED?

68 — Case Candidate

Related alerts may become:

CASE CANDIDATE

not automatically:

INCIDENT

69 — Grouping Logic

Possible grouping criteria:

SAME USER

SAME ASSET

SAME INDICATOR

RELATED RULES

SHORT TIME WINDOW

70 — Avoid Over-Grouping

Do not group all:

WEB SERVER ALERTS

into one case just because they involve web servers.

71 — Avoid Under-Grouping

Do not force analysts to investigate:

10 RELATED ALERTS

independently if one grouped story is clearer.

72 — Alert Priority vs Severity

Distinguish:

SOURCE SEVERITY

from:

TRIAGE PRIORITY

73 — Example

MEDIUM ALERT
+
PRIVILEGED IDENTITY
+
CRITICAL ASSET
+
RELATED EVENTS

can become:

HIGH TRIAGE PRIORITY

74 — Build Transparent Priority Model

Potential factors:

ALERT SEVERITY

ASSET CRITICALITY

IDENTITY PRIVILEGE

INTERNET EXPOSURE

IOC CONTEXT

VULNERABILITY CONTEXT

CORRELATED ALERTS

75 — Example Training Weights

Example only:

CRITICAL ALERT
50

HIGH ALERT
40

MEDIUM ALERT
25

PRIVILEGED IDENTITY
+15

CRITICAL ASSET
+15

INTERNET-FACING
+10

HIGH-CONFIDENCE IOC
+10

CRITICAL VULNERABILITY
+15

76 — Risk Model Warning

These are:

TRAINING EXAMPLES

not universal SOC standards.

77 — Cap Priority Score

Example:

0–100

78 — Example Priority Bands

80–100
P1 — Immediate Analyst Review

60–79
P2 — High Priority

40–59
P3 — Standard Review

0–39
P4 — Low Priority

79 — Explain Every Score

Analysts should see:

WHY?

Example:

HIGH ALERT
+40

PRIVILEGED USER
+15

CRITICAL ASSET
+15

RELATED ALERT
+5

TOTAL
75

80 — Avoid Opaque Scores

Bad:

RISK = 91

Good:

RISK = 91

REASONS:
...

81 — Avoid Double Counting

Check whether vendor alert severity already includes:

ASSET IMPORTANCE

IOC CONFIDENCE

before adding those again.

82 — Risk Model Version

Track:

risk_model_version

83 — Why Versioning Matters

If scoring changes next month, historical priority must remain explainable.

84 — Build Analyst Queue

Sort alerts by:

PRIORITY

AGE

BUSINESS CRITICALITY

according to SOC policy.

85 — Queue Fields

Recommended:

ALERT ID

TIME

PRIORITY

RISK SCORE

SOURCE

RULE

USER

ASSET

INDICATOR

OWNER

AGE

RECOMMENDATION

86 — Queue Aging

Track:

TIME SINCE ALERT CREATED

87 — Queue SLA

Use approved organizational targets.

Example conceptually:

P1
FASTEST REVIEW

P2
RAPID REVIEW

P3
STANDARD

P4
ROUTINE

88 — Do Not Invent Universal SLAs

Different organizations have different:

STAFFING

RISK TOLERANCE

BUSINESS REQUIREMENTS

89 — Triage Recommendation

Automation may recommend:

REVIEW AUTHENTICATION HISTORY

REVIEW ENDPOINT TELEMETRY

CHECK RELATED ALERTS

VALIDATE IOC

CHECK CHANGE WINDOW

CONTACT ASSET OWNER

90 — Recommendation vs Decision

Automation can say:

RECOMMEND ESCALATION REVIEW

but should not automatically say:

CONFIRMED COMPROMISE

without supporting investigation.

91 — Analyst First Review

For each alert, verify:

ALERT IS VALID

DATA IS COMPLETE

SOURCE IS TRUSTED

TIMESTAMP IS CORRECT

92 — Validate Detection Evidence

Ask:

WHAT RAW EVENT
TRIGGERED THE RULE?

93 — Review Original Events

Whenever possible inspect:

UNDERLYING LOG

PROCESS EVENT

AUTHENTICATION EVENT

CLOUD AUDIT EVENT

not only the alert summary.

94 — Determine Whether Activity Occurred

Sometimes:

ALERT

may be generated from:

MALFORMED DATA

TEST EVENT

STALE RECORD

95 — Review Identity Behavior

Ask:

IS THIS NORMAL
FOR THE USER?

Consider:

USUAL LOCATION

USUAL DEVICE

USUAL APPLICATION

USUAL TIME

96 — Review Asset Behavior

Ask:

IS THIS EXPECTED
FOR THIS SYSTEM?

97 — Review Administrative Activity

Privileged systems often legitimately perform unusual operations.

Correlate with:

CHANGE TICKET

MAINTENANCE

ADMIN ACTIVITY

98 — Review Network Context

Potential questions:

SOURCE INTERNAL OR EXTERNAL?

DESTINATION EXPECTED?

PORT EXPECTED?

OTHER CONNECTIONS?

99 — Review Endpoint Context

For endpoint alerts:

PROCESS

PARENT PROCESS

USER

FILE HASH

SIGNER

NETWORK CONNECTION

may be relevant.

100 — Stay Within Authorized Investigation Scope

Use approved:

EDR

SIEM

LOGGING

INVENTORY

and sanctioned forensic procedures.

101 — Review Cloud Activity

For cloud-related alerts inspect:

IDENTITY

API ACTION

SOURCE

RESOURCE

REGION

ACCOUNT / PROJECT

102 — Review Vulnerability Context

Ask:

DOES THE AFFECTED ASSET
HAVE RELEVANT OPEN FINDINGS?

103 — Avoid Vulnerability Assumptions

A vulnerable host plus an alert does not prove exploitation.

Use it as:

RISK CONTEXT

104 — Review IOC Context

Check:

SOURCE

CONFIDENCE

FRESHNESS

CLASSIFICATION

105 — Multiple Intelligence Sources

One source may disagree with another.

Record the disagreement instead of forcing certainty.

106 — Build Analyst Notes

Recommended structure:

SUMMARY

EVIDENCE

IDENTITY CONTEXT

ASSET CONTEXT

IOC CONTEXT

VULNERABILITY CONTEXT

RELATED EVENTS

TIMELINE

ASSESSMENT

NEXT ACTION

107 — Separate Facts from Interpretation

Example:

FACT:
User admin01 authenticated at 08:18 UTC.

INTERPRETATION:
Authentication may be related to preceding failures.

108 — Why This Matters

It prevents:

ASSUMPTION

from becoming:

EVIDENCE

109 — Assign Disposition

Common examples:

TRUE POSITIVE

FALSE POSITIVE

BENIGN TRUE POSITIVE

EXPECTED ACTIVITY

INSUFFICIENT EVIDENCE

ESCALATED

110 — True Positive

The detection correctly identified behavior that requires security handling.

111 — False Positive

The detection incorrectly identified benign activity as matching the detection logic.

112 — Benign True Positive

The detection correctly observed behavior, but the activity was legitimate.

Example:

AUTHORIZED SECURITY SCAN

113 — Expected Activity

Examples:

APPROVED ADMIN CHANGE

PLANNED MAINTENANCE

AUTHORIZED TEST

114 — Insufficient Evidence

Do not force a binary answer when:

DATA IS INCOMPLETE

115 — Incident Escalation

Escalate when:

SUPPORTED EVIDENCE

meets your organization’s incident criteria.

116 — Escalation Flow

ALERT
 ↓
TRIAGE
 ↓
CORRELATE
 ↓
ANALYST ASSESSMENT
 ↓
INCIDENT CRITERIA MET?
   ↙          ↘
 YES          NO
 ↓             ↓
ESCALATE      CLOSE /
             MONITOR

117 — Escalation Package

Include:

ALERT IDS

TIMELINE

USERS

ASSETS

INDICATORS

EVIDENCE

RISK CONTEXT

ANALYST NOTES

118 — Avoid Over-Escalation

Escalating every alert creates:

INCIDENT FATIGUE

119 — Avoid Under-Escalation

Do not close because:

ONLY ONE ALERT EXISTS

if the evidence itself is strong.

120 — Closure Documentation

Record:

DISPOSITION

REASON

EVIDENCE

ANALYST

TIME

121 — False Positive Feedback

When false positives occur:

REVIEW RULE

122 — Detection Tuning Questions

Ask:

IS THRESHOLD WRONG?

IS DATA NORMALIZED CORRECTLY?

IS EXCEPTION NEEDED?

IS CONTEXT MISSING?

123 — Do Not Disable Rules Blindly

A noisy rule may still detect real threats.

Tune carefully.

124 — Suppression

If needed:

SPECIFIC

TIME-LIMITED

OWNED

REVIEWED

125 — Suppression Example

Safer:

Suppress alerts from approved scanner
for defined addresses
until defined expiry

Not:

Ignore scanning alerts forever

126 — Analyst Feedback Loop

ALERT
 ↓
TRIAGE
 ↓
DISPOSITION
 ↓
FEEDBACK
 ↓
RULE TUNING
 ↓
BETTER DETECTION

127 — Track Detection Metrics

Useful:

ALERT VOLUME

TRUE POSITIVE RATE

FALSE POSITIVE RATE

ESCALATION RATE

BENIGN TRUE POSITIVE RATE

128 — Mean Time to Triage

Conceptually:

TRIAGE START
-
ALERT CREATION

129 — Mean Time to Escalate

Conceptually:

ESCALATION TIME
-
ALERT CREATION

130 — Queue Size

Track:

TOTAL OPEN

P1

P2

P3

P4

131 — Queue Age

Useful metrics:

OLDEST ALERT

AVERAGE AGE

ALERTS OVER SLA

132 — Detection Source Health

An alert source can fail silently.

Monitor:

LAST ALERT

LAST EVENT

EXPECTED VOLUME

133 — Sudden Alert Drop

Could mean:

NO ATTACKS

or:

BROKEN DETECTION PIPELINE

134 — Sudden Alert Spike

Could indicate:

REAL ACTIVITY

RULE CHANGE

DUPLICATE DATA

SOURCE ISSUE

135 — Measure Enrichment Coverage

Track:

IDENTITY ENRICHMENT %

ASSET ENRICHMENT %

IOC ENRICHMENT %

VULNERABILITY ENRICHMENT %

136 — Example

Asset enrichment:
96%

Identity enrichment:
91%

IOC lookup completion:
80%

137 — Context Quality

An alert with:

HIGH SCORE

and:

LOW CONTEXT COMPLETENESS

should be interpreted carefully.

138 — Build Context Completeness

Possible factors:

IDENTITY AVAILABLE

ASSET AVAILABLE

IOC CHECK COMPLETE

VULNERABILITY DATA AVAILABLE

139 — Never Hide Missing Context

Show:

VULNERABILITY CONTEXT
UNAVAILABLE

140 — SOC Automation Boundaries

Good automation:

LOOKUP DATA

NORMALIZE

CORRELATE

PRIORITIZE

GENERATE CASE CANDIDATE

141 — High-Impact Response

Require stronger governance for:

DISABLE ACCOUNT

ISOLATE HOST

BLOCK NETWORK INDICATOR

DELETE FILE

ROTATE CREDENTIAL

142 — Human-in-the-Loop

Preferred:

AUTOMATION
   ↓
RECOMMEND
   ↓
ANALYST VALIDATES
   ↓
APPROVED RESPONSE

143 — Response Recommendation

Example:

Review identity activity and related endpoint telemetry.
Consider escalation according to the approved incident
response process if corroborating evidence is confirmed.

144 — Avoid Prescriptive Automated Disruption

Do not automatically generate generic instructions like:

BLOCK IP NOW

DISABLE USER NOW

ISOLATE SERVER NOW

without validated evidence and approved process.

145 — Evidence Preservation

For important alerts preserve:

RAW ALERT

SOURCE EVENTS

NORMALIZED RECORD

ENRICHMENT

CORRELATION

ANALYST NOTES

146 — Evidence Hashing

Where required, use:

SHA-256

for integrity reference.

147 — Chain of Custody

A hash alone does not establish a complete chain of custody.

Follow approved incident response evidence procedures.

148 — Investigation Package

Example:

CASE-001/
|
+-- raw-alert.json
|
+-- normalized-alert.json
|
+-- timeline.csv
|
+-- identity-context.json
|
+-- asset-context.json
|
+-- ioc-context.json
|
+-- analyst-notes.md

149 — Access Control

Investigation data may be sensitive.

Restrict:

WHO CAN VIEW

WHO CAN EDIT

WHO CAN DELETE

150 — Audit Trail

Track:

ALERT RECEIVED

ENRICHMENT PERFORMED

ANALYST ASSIGNED

DISPOSITION

ESCALATION

CLOSURE

151 — Case Ownership

Every active investigation should have:

OWNER

152 — Reassignment

Record:

FROM

TO

TIME

REASON

153 — Collaboration

Some alerts require:

IDENTITY TEAM

CLOUD TEAM

ENDPOINT TEAM

APPLICATION TEAM

NETWORK TEAM

154 — Route Based on Context

Example:

CLOUD CONFIGURATION ALERT
→ CLOUD SECURITY

IDENTITY ALERT
→ SOC / IAM

ENDPOINT MALWARE ALERT
→ SOC / IR

155 — Routing Is Not Escalation

Assignment to another team does not automatically mean:

SECURITY INCIDENT

156 — Re-Triage

Alerts may need re-triage when:

NEW EVIDENCE ARRIVES

NEW IOC DATA ARRIVES

ASSET CRITICALITY CHANGES

RELATED ALERT APPEARS

157 — Dynamic Priority

Priority can change.

Example:

P3

becomes:

P1

after new related events appear.

158 — Track Priority Changes

Record:

OLD PRIORITY

NEW PRIORITY

REASON

TIME

159 — Alert Aging

An old unreviewed alert may deserve attention because:

QUEUE PROCESS FAILED

not because the security behavior became more severe.

160 — Stale Alerts

For very old alerts, ask:

IS INVESTIGATION STILL ACTIONABLE?

IS DATA STILL AVAILABLE?

IS THIS A PROCESS GAP?

161 — Automated Closure

Be cautious.

Do not close alerts solely because:

NO IOC MATCH

NO RELATED ALERTS

LOW SCORE

unless a well-governed use case specifically supports that decision.

162 — Quality Assurance

Periodically sample:

CLOSED LOW-PRIORITY ALERTS

to ensure important activity is not being missed.

163 — Triage QA

Review:

DISPOSITIONS

EVIDENCE QUALITY

ESCALATION CONSISTENCY

DOCUMENTATION

164 — Analyst Calibration

Multiple analysts should interpret:

PRIORITY

DISPOSITION

ESCALATION

consistently.

165 — Use Playbooks

For common alerts maintain playbooks such as:

SUSPICIOUS AUTHENTICATION

MALWARE ALERT

PHISHING

CLOUD IDENTITY ALERT

NETWORK ALERT

166 — Playbook vs Runbook

This runbook defines:

OVERALL TRIAGE PROCESS

A playbook can define:

ALERT-SPECIFIC INVESTIGATION

167 — Authentication Triage Example

AUTH ALERT
   ↓
VALIDATE USER
   ↓
CHECK PRIVILEGE
   ↓
CHECK SOURCE
   ↓
CHECK RELATED FAILURES
   ↓
CHECK SUCCESSFUL LOGIN
   ↓
CHECK DEVICE
   ↓
CHECK CLOUD / VPN ACTIVITY
   ↓
ASSESS

168 — Endpoint Triage Example

EDR ALERT
   ↓
VALIDATE DEVICE
   ↓
CHECK USER
   ↓
CHECK PROCESS
   ↓
CHECK PARENT
   ↓
CHECK HASH
   ↓
CHECK RELATED NETWORK
   ↓
CHECK OTHER HOST ALERTS
   ↓
ASSESS

169 — Cloud Triage Example

CLOUD ALERT
   ↓
IDENTIFY PROVIDER
   ↓
IDENTIFY ACCOUNT
   ↓
IDENTIFY IDENTITY
   ↓
IDENTIFY RESOURCE
   ↓
CHECK PUBLIC EXPOSURE
   ↓
CHECK LOGGING
   ↓
CHECK RELATED ACTIVITY
   ↓
ASSESS

170 — Vulnerability Alert Example

VULNERABILITY ALERT
   ↓
VALIDATE FINDING
   ↓
IDENTIFY ASSET
   ↓
CHECK CRITICALITY
   ↓
CHECK INTERNET EXPOSURE
   ↓
CHECK OWNER
   ↓
CHECK RELATED SECURITY ALERTS
   ↓
PRIORITIZE

171 — IOC Alert Example

IOC ALERT
 ↓
VALIDATE INDICATOR
 ↓
CHECK SOURCE
 ↓
CHECK CONFIDENCE
 ↓
CHECK FRESHNESS
 ↓
SEARCH RELATED EVENTS
 ↓
IDENTIFY AFFECTED ASSETS
 ↓
ASSESS

172 — SOC Triage Decision Tree

ALERT ARRIVES
      ↓
VALID?
  ↙       ↘
NO        YES
↓          ↓
QUARANTINE DUPLICATE?
           ↙       ↘
          YES       NO
           ↓         ↓
         MERGE     ENRICH
                     ↓
                CONTEXT COMPLETE?
                 ↙         ↘
               NO           YES
               ↓             ↓
          MARK UNKNOWN    CORRELATE
               ↓             ↓
               └──────┬──────┘
                      ↓
                  PRIORITIZE
                      ↓
                  INVESTIGATE
                      ↓
               INCIDENT CRITERIA?
                 ↙          ↘
               YES           NO
               ↓              ↓
            ESCALATE       DISPOSITION

173 — Triage Checklist

For every alert:

174 — Analyst Investigation Template

Use:

ALERT ID:

SOURCE:

RULE ID:

TIMESTAMP:

SEVERITY:

TRIAGE PRIORITY:

USER:

PRIVILEGED:

ACCOUNT STATUS:

ASSET:

ASSET CRITICALITY:

ENVIRONMENT:

INTERNET-FACING:

SOURCE IP:

IOC CONTEXT:

VULNERABILITY CONTEXT:

CLOUD CONTEXT:

RELATED ALERTS:

TIMELINE:

KNOWN CHANGES:

EXCEPTIONS:

KEY EVIDENCE:

ASSESSMENT:

DISPOSITION:

ESCALATION:

ANALYST:

REVIEW TIME:

175 — Case Candidate Template

CASE CANDIDATE ID:

RELATED ALERTS:

PRIMARY USER:

PRIMARY ASSET:

INDICATORS:

FIRST EVENT:

LAST EVENT:

PRIORITY:

CORRELATION REASON:

EVIDENCE SUMMARY:

ANALYST REVIEW REQUIRED:
YES

176 — Closure Template

ALERT ID:

DISPOSITION:

CLOSURE REASON:

SUPPORTING EVIDENCE:

FALSE POSITIVE:
YES / NO

DETECTION TUNING NEEDED:
YES / NO

FOLLOW-UP:

ANALYST:

CLOSED AT:

177 — Escalation Template

INCIDENT CANDIDATE:

ALERT IDS:

SUMMARY:

TIMELINE:

IDENTITIES:

ASSETS:

INDICATORS:

CORRELATED EVENTS:

BUSINESS CONTEXT:

RISK FACTORS:

EVIDENCE:

RECOMMENDED NEXT STEP:

ANALYST:

178 — Triage Quality Metrics

Track:

ALERTS TRIAGED

MTTT

ESCALATION RATE

FALSE POSITIVE RATE

ENRICHMENT COVERAGE

QUEUE AGE

SLA BREACHES

179 — Do Not Optimize Only for Speed

Fast triage with poor decisions is not success.

Balance:

SPEED

QUALITY

CONSISTENCY

EVIDENCE

180 — Automation Metrics

Useful:

DEDUPLICATION RATE

ENRICHMENT SUCCESS RATE

CORRELATION HIT RATE

AUTOMATED PRIORITY COVERAGE

API FAILURE RATE

181 — Monitor Automation Bias

Analysts may over-trust:

AUTOMATED PRIORITY

Training should reinforce:

AUTOMATION SUPPORTS
ANALYST JUDGMENT

182 — Manual Override

Analysts should be able to:

INCREASE PRIORITY

DECREASE PRIORITY

REMOVE CORRELATION

ADD CONTEXT

with documented reason.

183 — Feedback on Scoring

When analysts repeatedly override a rule, review the model.

184 — Detection Improvement Loop

ALERT
 ↓
TRIAGE
 ↓
DISPOSITION
 ↓
METRICS
 ↓
RULE REVIEW
 ↓
NORMALIZATION REVIEW
 ↓
ENRICHMENT REVIEW
 ↓
IMPROVED DETECTION

185 — Data Quality Escalation

If alert quality degrades:

STOP TRUSTING
AUTOMATED PRIORITIZATION

until the issue is understood.

186 — Example Data Problem

80% OF ALERTS
SHOW UNKNOWN ASSET

Possible issue:

CMDB API FAILED

HOSTNAME FORMAT CHANGED

NORMALIZATION BUG

187 — SOC Tool Failure

If enrichment API fails:

DO NOT DROP ALERT

Continue with:

PARTIAL CONTEXT

188 — Critical Context Failure

If a required source fails for a high-impact response:

STOP AUTOMATED RESPONSE

REQUIRE ANALYST REVIEW

189 — Security Principle

MISSING EVIDENCE
SHOULD REDUCE CONFIDENCE,
NOT CREATE FALSE CONFIDENCE

190 — Common Triage Mistakes

Avoid:

ALERT = INCIDENT

SEVERITY = PRIORITY

IOC MATCH = COMPROMISE

NO IOC MATCH = SAFE

UNKNOWN ASSET = LOW RISK

NO RELATED ALERTS = BENIGN

VULNERABILITY = EXPLOITED

NO HUMAN REVIEW

NO TIMELINE

NO EVIDENCE PRESERVATION

NO DISPOSITION FEEDBACK

191 — Common Automation Mistakes

Avoid:

AUTO-CLOSING LOW SCORES

AUTO-BLOCKING IOCS

AUTO-DISABLING USERS

NO APPROVAL

NO EXPLAINABILITY

NO FAILURE HANDLING

NO DATA FRESHNESS

NO AUDIT TRAIL

192 — Analyst Mental Model

For every alert ask:

IS IT REAL?
      ↓
IS IT DUPLICATE?
      ↓
WHO IS INVOLVED?
      ↓
WHAT ASSET?
      ↓
HOW IMPORTANT?
      ↓
WHAT INDICATOR?
      ↓
WHAT OTHER CONTEXT?
      ↓
WHAT ELSE HAPPENED?
      ↓
WHEN?
      ↓
HOW STRONG IS THE EVIDENCE?
      ↓
WHAT PRIORITY?
      ↓
WHAT DECISION IS SUPPORTED?

193 — Final Security Equation

ALERT
+
IDENTITY CONTEXT
+
ASSET CONTEXT
+
IOC CONTEXT
+
VULNERABILITY CONTEXT
+
CLOUD CONTEXT
+
CORRELATION
+
BUSINESS CONTEXT
+
ANALYST JUDGMENT
=
BETTER TRIAGE

194 — Key Lesson

The central lesson is:

CONTEXT
TURNS ALERTS
INTO INVESTIGATIONS

But context alone does not automatically establish:

INCIDENT

Runbook Outcome

After completing this runbook, your SOC should have a repeatable process for:

VALIDATING ALERTS

NORMALIZING SECURITY DATA

REMOVING DUPLICATES

ENRICHING IDENTITIES

ENRICHING ASSETS

ENRICHING IOCS

ADDING VULNERABILITY CONTEXT

ADDING CLOUD CONTEXT

CORRELATING RELATED ACTIVITY

BUILDING TIMELINES

ASSIGNING EXPLAINABLE PRIORITY

CREATING ANALYST QUEUES

DOCUMENTING DISPOSITIONS

ESCALATING SUPPORTED INCIDENTS

What’s Next?

➡️ Runbook 05 — Vulnerability Prioritization and Remediation Automation

The next runbook will define a repeatable vulnerability-management workflow:

SCANNER FINDING
      ↓
VALIDATE
      ↓
NORMALIZE
      ↓
DEDUPLICATE
      ↓
ASSET CONTEXT
      ↓
BUSINESS CRITICALITY
      ↓
EXPOSURE
      ↓
THREAT CONTEXT
      ↓
REMEDIATION SLA
      ↓
PRIORITIZE
      ↓
ASSIGN OWNER
      ↓
TRACK
      ↓
VERIFY
      ↓
CLOSE

The goal will be to move beyond simply sorting vulnerabilities by severity and instead build an explainable, ownership-driven remediation process based on real asset and business risk.