3.2 Integration readiness checklist — AppSec
Persona: AppSec Leader
Complete this checklist before ADR alerts start flowing to the SOC.
# | Check | Done? | Notes |
Naming & Metadata | |||
1 | Application names in ADR match the naming convention the SOC uses (and CMDB, if applicable) | If not, map them now. The SOC can’t triage what they can’t identify. | |
2 | Each application has a technical owner assigned in the ADR metadata | SOC needs to know who to call at 2 AM. | |
3 | Application environment tags are set (prod, staging, dev) | SOC must distinguish prod alerts from dev noise. | |
4 | Business criticality tier is assigned per application (Tier 0/1/2) | Drives alert severity mapping in the SIEM. | |
Policy Configuration | |||
5 | Decided which applications start in Monitor mode vs. Block mode | See the decision matrix in 3.5. | |
6 | Process for documenting Block Mode exceptions is established (for when false-positive patterns are discovered during validation) | You’ll discover FPs during Phase 2 — have the process ready before you need it. | |
7 | Alert routing rules configured (which alerts go to SIEM vs. remain in the Contrast platform) | Not every finding needs to wake up the SOC. | |
8 | Severity mapping defined: ADR severity → SIEM alert priority | Align with SOC Lead (use 3.3 #5). | |
Operational Readiness | |||
9 | Documented the rollback process for Block Mode (who, how, how fast) | Engineering must be in this loop. | |
10 | Identified an AppSec on-call or escalation contact for the SOC | SOC cannot resolve app-layer incidents alone. | |
11 | Tested ADR alerting end-to-end in a staging/test environment | Fire a test exploit. Did the SOC see it? |