platepilot

Incident response runbook

• Status: M0 process framework; production roster and tools pending

Scope

Use this process for confidentiality, integrity, availability, privacy, safety-copy, provider, or operational events affecting PlatePilot. M0 should contain only synthetic data, but a leaked credential or unsafe future-facing specification still requires response.

Severity guide

Severity	Examples
SEV-1	Confirmed broad restricted-data exposure, active account takeover, destructive corruption, or complete critical-service loss
SEV-2	Limited cross-adult exposure, sustained critical-flow outage, queue runaway, or significant provider compromise
SEV-3	Degraded non-critical function, contained configuration issue, or low-impact unauthorized attempt
SEV-4	No-impact alert, documentation/process defect, or near miss

Severity can increase as evidence changes. Do not delay containment while debating exact classification.

Roles

The future on-call roster and secure contact channel are PENDING. Assign these roles per event; one person may hold more than one in a small response:

• Incident commander: decisions, priorities, timeline
• Technical lead: diagnosis and containment
• Communications lead: approved internal/adult/vendor updates
• Privacy/security lead: evidence, notification assessment, data scope
• Scribe: timestamped actions, hypotheses, and decisions without sensitive payloads

Response

1. Detect and verify: capture time, reporter, affected function, and safe evidence.
2. Classify: identify assets, adults/households, region, provider, and confidentiality/integrity/availability impact.
3. Contain: revoke exposed credentials, disable affected adapter/route, pause queue or release, and preserve manual fallback where safe.
4. Preserve evidence: use approved restricted storage; do not paste photos, tokens, or personal records into tickets/chat.
5. Eradicate: remove the cause, patch, rotate, or isolate. Treat provider claims as evidence to validate.
6. Recover: use reviewed deployment/rollback/restore processes; verify authorization, data integrity, queues, retention, and deletion state.
7. Communicate: factual, time-bounded, non-speculative updates. Legal/privacy determines any required notices.
8. Review: document timeline, root/systemic causes, impact, control gaps, and owned follow-ups.

Privacy event questions

• Did an unauthorized person access a meal photo, diary, identity, household link, token, export, or deletion record?
• Was cross-adult access possible even without confirmed viewing?
• Did logs, backups, caches, vendors, or support tools receive the data?
• Are minors implicated contrary to the adult-only assumption?
• Can the exposure be stopped without destroying evidence?
• Which contractual or legal notification clocks may apply?

Escalation contacts, regulators, response deadlines, cyber-insurance steps, and law-enforcement criteria are PENDING legal/security approval. Do not guess.

Communication template

Status: Investigating | Identified | Monitoring | Resolved
Started:
Current impact:
Affected functions (avoid sensitive details):
Containment:
Adult action, if any:
Next update:

Never promise that no data was affected until evidence supports it. Do not use medical or blame-oriented language.

Exit and follow-up

• Impact and unauthorized access have stopped.
• Recovery checks and heightened monitoring pass.
• Required notifications and provider actions are tracked.
• Temporary access and evidence copies are removed on schedule.
• A blameless review is completed and high-risk actions have owners.
• Threat model, runbooks, tests, and ADRs are updated where assumptions changed.