Start Building

Lesson 40: Vendor Breach Notification Cascade Template for RPG Live-Ops Security Incidents

Lesson 39 made subprocessor drift visible. Lesson 38 made DSAR execution routable. This lesson answers the emergency question: what do we reopen first when a vendor says there was unauthorized access?

You get one cascade template that prevents parallel panics, double notifications, and accidental deletion of evidence.

Dragon pixel illustration for vendor breach notification cascade lesson

What you will build

By the end of this lesson, you will have:

  1. A vendor_breach_cascade_checklist.md with ordered steps from intake to stabilization
  2. A required incident_register.csv row schema that links vendor notice IDs to internal owners
  3. Automatic reopen rules for the Lesson 36 processor inventory, Lesson 39 subprocessor register, Lesson 38 DSAR risk tracker, and Lesson 37 hold register
  4. A comms rule that separates internal coordination from player-facing statements so legal review stays in front

Step 1 - Open the incident row before you forward the email

Create one row immediately with:

field purpose
incident_id stable internal ID (INC-2026-0418-01)
vendor_notice_id vendor ticket or bulletin reference
first_internal_timestamp_utc clock start for your response
assumed_data_classes gameplay telemetry, support transcripts, warehouse aggregates, credentials
severity_hypothesis limited, broad, unknown
owner_security single accountable security lead
owner_legal_privacy single accountable policy lead

No engineering work begins until this row exists. Forwarding vendor mail without a row is how teams lose audit trails.

Step 2 - Run the cascade in strict order

Execute these steps in order. Skipping breaks downstream evidence.

  1. Preserve evidence — export vendor notice, freeze affected log retention buckets where contract allows, snapshot current subprocessor register version hash.
  2. Mark DSAR risk yellow — open DSAR queue gets a global yellow until scope is understood, even if no new requests arrived.
  3. Reopen subprocessor register — force map_update_status to pending for any product line mentioned in the notice, even if the vendor claims no subprocessors changed.
  4. Legal-hold triage — compare incident scope to Lesson 37 register. If overlap is plausible, open a hold review task before any mass deletion jobs run.
  5. Technical containment — rotate credentials, disable risky automation, or isolate integrations only after steps 1 through 4 have owners.

This order protects forensics and policy lanes before fast technical wins.

Step 3 - Author vendor_breach_cascade_checklist.md

Use short checkboxes per hour bucket for the first day:

  • T+0 to T+2h — incident row, evidence preservation, vendor acknowledgment sent
  • T+2h to T+8h — DSAR yellow applied, subprocessor register reopened, hold triage started
  • T+8h to T+24h — technical containment plan approved by security plus legal
  • T+24h to T+72h — inventory deltas merged or explicitly deferred with written risk acceptance

Adjust hour windows to your jurisdiction guidance. The structure matters more than exact numbers.

Step 4 - Tie back to launch control

Add three fields to your weekly launch packet when any incident row is open:

  • open_vendor_incident_count
  • highest_severity_hypothesis
  • dsar_queue_risk_due_to_incident (none, yellow, red)

If dsar_queue_risk_due_to_incident is red, block promotion until legal assigns a dated recovery plan.

Step 5 - Player-facing comms guardrail

This lesson does not give you marketing copy. It gives you a rule:

Internal technical facts do not become public player statements until the policy lane publishes approved language.

Keep drafts in a separate doc with watermark DRAFT - NOT APPROVED until sign-off.

Common mistakes

Mistake: Engineers patch first, legal learns later

Fix: Steps 1 through 4 exist so containment does not destroy discoverability.

Mistake: Treating vendor severity labels as your own

Fix: Keep severity_hypothesis independent until your map review finishes.

Mistake: Forgetting to version DSAR templates after the incident

Fix: If scope changed, bump Lesson 38 packet version and note incident_id in the changelog.

Pro tips

  • Store vendor PDFs with the same hashing habit you use in Lesson 39.
  • Run a tabletop exercise once per quarter with a fake INC row so the cascade stays muscle memory.
  • Link each containment action to a ticket ID in the incident row notes field.

Mini challenge

  1. Draft one INC row for a fictional analytics vendor notice.
  2. Walk the cascade through step 3 only on paper and mark which Lesson 36 rows would reopen.
  3. Write one sentence your policy lane would require before any public post.

FAQ

Does every vendor notice require a public player announcement?

No. Jurisdiction, scope, and contract terms differ. This template keeps internal work ordered until legal decides.

What if the vendor is silent but logs show odd access?

Treat it as an incident anyway. Open the row with vendor_notice_id set to internal_detection and follow the same cascade.

Who owns the cascade if the team is two people?

Same person can hold two owner fields temporarily, but the checklist still runs in order. Do not merge steps.

Lesson recap

You now have a breach cascade that reconnects security reality to the governance artifacts you already built: subprocessors, DSAR routing, holds, and launch control. That is how small teams avoid thrash under pressure.

Next lesson teaser

Next lesson: Lesson 41: Regulator and Partner Notification Evidence Packet for Jurisdiction Triggers in RPG Live-Ops adds a notification packet template, jurisdiction trigger matrix, partner notice register, and attachment-version controls so filing clocks stay auditable.

Related learning