Check Designer — Incident Response Policy (Draft)
Status: Draft administrative/security policy — subject to attorney review before commercial launch.
1. Purpose
This policy outlines how the service operator should prepare for, detect, respond to, and learn from security and availability incidents affecting Check Designer. It is a planning document — not evidence of a certified incident management program.
2. Scope
Incidents include but are not limited to:
- Unauthorized access or suspected breach of tenant data
- Loss or corruption of `prod.db` or backups
- Exposure of `.env` secrets (`BANK_DATA_ENCRYPTION_KEY`, `SESSION_SECRET`)
- Ransomware or compromise of production server
- Extended outage of application or TLS
- Abuse of support access approvals
- Billing or platform misconfiguration with customer impact
3. Severity levels (draft)
| Level | Examples | Target response |
|---|---|---|
| Critical | Active breach, prod DB encrypted by attacker, key leak | Immediate containment; executive notification |
| High | Suspected unauthorized support session, restore failure during outage | Same business day |
| Medium | Failed backup, non-prod data exposure | Within 48 hours |
| Low | Single-tenant misconfiguration, failed deploy rollback | Next business day |
*Finalize SLAs with counsel and operations at launch.*
4. Response phases
4.1 Detect and report
- Monitoring: PM2 health, disk space, backup manifest failures, customer reports
- Report to: *[security@example.com — placeholder]*
- Internal escalation: *[on-call contact — placeholder]*
Tenant users should report suspicious activity to their OWNER and to operator support.
4.2 Contain
- Stop writes if needed: `pm2 stop check-designer`
- Revoke active support sessions (OWNER revoke or operator DB action per runbook)
- Rotate `SESSION_SECRET` if session hijack suspected (invalidates cookies)
- Do not rotate `BANK_DATA_ENCRYPTION_KEY` without a re-encryption plan — rotation destroys decryptability of existing ciphertext
- Isolate server from network if compromise confirmed
4.3 Eradicate and recover
- Restore from last known-good backup per `BACKUP_RESTORE_RUNBOOK.md` if integrity compromised
- Patch vulnerability; redeploy known-good release
- Verify `BANK_DATA_ENCRYPTION_KEY` matches backup era before declaring recovery
4.4 Post-incident
- Timeline document (UTC), root cause, affected tenants/data categories
- Update controls and runbooks
- Customer notification if required by law or contract — counsel decides
5. Communications (placeholders)
| Audience | Channel | Owner |
|---|---|---|
| Affected customers | *[Email / status page — TBD]* | *[Role — TBD]* |
| Regulators | *[If required — counsel]* | Legal |
| All customers | *[Status page — TBD]* | Operations |
No notification content in this draft constitutes legal advice.
6. Evidence preservation
- Preserve logs, audit exports, backup manifests, and disk snapshots before destructive recovery
- Avoid copying decrypted bank data into tickets
7. Breach assessment (not legal advice)
Whether an incident triggers breach notification laws depends on data involved, jurisdiction, and risk of harm. Operator must consult qualified counsel — this policy does not automate legal analysis.
8. Testing
- Backup restore drill (isolated test folder) should run periodically per operator runbook
- Tabletop exercise recommended before SaaS launch
9. No certification
This policy does not claim SOC 2 incident management certification, ISO 27001, or regulatory compliance.
*Draft only — no incident tooling added in Phase 2P-A.*