During an incident, operators are under time pressure — every minute a bad campaign runs increases complaints and risks ESP account action. A pause mechanism that requires navigating to an undocumented admin page, writing a SQL UPDATE, or finding the right API endpoint in source code adds minutes to incident response. NIST SP 800-53 IR-4 (Incident Handling) requires that containment actions are pre-planned and executable without discovery overhead. An admin UI button with no runbook entry fails because the runbook is what makes it findable under pressure.
Medium because an undocumented quick-disable mechanism is operationally equivalent to no mechanism — operators cannot use what they cannot find under incident pressure.
Document the quick-disable procedure in your incident runbook with a ready-to-run command. For API-based pause:
# Emergency: pause campaign immediately
curl -sS -L -X PATCH https://your-api.com/api/admin/campaigns/CAMPAIGN_ID \
-H "Authorization: Bearer $ADMIN_TOKEN" \
-H "Content-Type: application/json" \
-d '{"status": "paused"}'
Or the safe SQL equivalent if direct DB access is needed:
UPDATE campaigns SET status = 'paused', paused_at = NOW() WHERE id = 'CAMPAIGN_ID';
The procedure must appear in docs/runbooks/deliverability-incident.md or equivalent — an undocumented admin UI does not pass this check.
ID: operational-resilience-email.incident-response.quick-disable-single-campaign
Severity: medium
What to look for: This check pairs with blast-radius containment but verifies the operator experience. Enumerate all quick-disable mechanisms: an admin UI button or CLI command that pauses a campaign immediately, an API route that is documented and accessible during an incident, or an emergency runbook entry that specifies the exact command or URL. Count the number of documented mechanisms. The goal is that an operator under pressure can disable one campaign in under 60 seconds without needing to find the right table and write SQL.
Pass criteria: There is a documented, non-code-deploy mechanism to disable a single campaign in under 60 seconds. This is either an admin UI action, a documented API call (with example curl command), or a safe one-liner database command in the runbook. The mechanism must be documented — an undocumented admin page does not count as pass.
Fail criteria: No documented quick-disable mechanism exists. Disabling a campaign requires finding and editing the database directly with no documented query. Or the mechanism exists but takes more than 60 seconds.
Skip (N/A) when: The system only ever runs one campaign at a time (full pause is sufficient) — confirmed by the application architecture.
Detail on fail: "No quick-disable mechanism documented — operator would need to find the correct database table and write an UPDATE query under incident pressure" or "Admin UI exists but campaign pause is buried 4 levels deep with no runbook shortcut"
Remediation: Document the quick-disable in the runbook:
# Emergency: pause campaign immediately
curl -sS -L -X PATCH https://your-api.com/api/admin/campaigns/CAMPAIGN_ID \
-H "Authorization: Bearer $ADMIN_TOKEN" \
-H "Content-Type: application/json" \
-d '{"status": "paused"}'
Or safe SQL if direct DB access is needed:
UPDATE campaigns SET status = 'paused', paused_at = NOW() WHERE id = 'CAMPAIGN_ID';