3.3 Integration readiness checklist — SOC

Data Onboarding

1

SIEM/SOAR connector for the ADR solution is deployed and sending data

See vendor-specific integration links in 3.4.

2

Log source is validated: events are parsing correctly with expected fields

Spot-check: app name, vuln type, severity, source IP, request URI.

3

Alert deduplication rules configured (avoid duplicate tickets for the same exploit)

ADR may fire per-request; you want per-incident.

Naming & Context

4

Application naming convention matches what AppSec uses in ADR metadata

Cross-check with AppSec (3.2 #1).

5

CMDB identifiers or asset tags mapped to ADR application names

Enables auto-enrichment in SIEM.

6

Application owner lookup is functional (ADR alert → who owns this app?)

SOC analysts must know who to escalate to in < 2 minutes.

Triage & Response

7

Alert severity mapping documented (ADR severity → SOC priority / SLA)

Align with AppSec Lead (use 3.2 #8).

8

Triage decision tree for ADR alerts is written or imported

See 3.4 for a starter template.

9

Runbook templates imported into SOAR (or documented if no SOAR)

At minimum: “ADR Exploit Detected” and “ADR Block Mode Triggered” runbooks.

10

Analysts briefed on what ADR alerts look like and what fields matter

Key difference from WAF/EDR: ADR tells you the function and vuln type, not just the request.

Operational Readiness

11

Escalation path defined: SOC → AppSec → Engineering

Especially for Block Mode incidents and zero-days.

12

Tested end-to-end: triggered test exploit → alert in SIEM → triage → escalation

Match with AppSec’s 3.2 #11 test.

13

On-call/escalation contacts for AppSec team documented and accessible

In your SOAR, runbook, or wiki. Not in someone’s head.