Check Designer — Account & Data Deletion Request Policy (Draft)
Status: Draft administrative policy — subject to attorney review before commercial launch.
1. Purpose
This policy explains how customers and individuals request data export or deletion/redaction review in Check Designer. It reflects current implementation: there is no self-service automated tenant wipe, no automatic hard-delete of production data, and no automatic backup erasure.
In-app guidance appears under Settings → Legal & compliance → Data export / deletion requests (Phase 2P-C). This page is also available at `/legal/account-deletion`.
2. Request types
| Type | Description | Current fulfillment |
|---|---|---|
| Operational export | Customer copies data using in-app backup tools | OWNER/ADMIN with backup permission; see §4 |
| Formal export review | Operator prepares or approves an export scope after written request | Manual — no automated export package generator |
| User removal | Remove one user from a tenant | In-app user admin (deactivates access) |
| Record deletion | Delete specific accounts, templates, queue rows | In-app where APIs and permissions allow |
| Tenant offboarding | Organization-wide deletion or redaction | Manual operator review — not a one-click delete |
| Backup purge | Remove historical backup files | Manual operator — not triggered by app requests |
3. Who may submit requests
| Requester | Authority | Channel |
|---|---|---|
| Tenant OWNER | Full organization scope | *support@example.com* or *privacy@example.com* (placeholders) |
| Tenant ADMIN | May request on behalf of organization per internal policy | Same channels; operator may require OWNER confirmation for destructive scope |
| Individual user | Own access only | Contact tenant OWNER first; then operator if needed |
| Data subject (privacy law) | Identity verification required | *privacy@example.com* (placeholder) |
Not accepted via app form today: There is no in-app ticket or API that executes deletion. Email or support process only (placeholders until launch).
4. What the application provides today (no automation)
| Capability | Automation | Notes |
|---|---|---|
| Remove / deactivate a user | In-app | May leave audit references |
| Delete tenant-scoped records | In-app per permissions | Does not purge all history types |
| SQLite database download | In-app | Instance-wide on shared hosting — all tenants in file |
| Project JSON export | In-app | Redacts account numbers and signatures in JSON |
| Delete entire tenant + all rows | None | Operator manual process |
| Erase operator backups | None | Backups age out per retention policy separately |
| Hard-delete production `prod.db` rows on request | None | Review may use redaction/suspend instead |
5. Manual request process (operator / admin review)
Phase 2P-C documents this workflow only. It is not implemented as software automation.
| Step | Action |
|---|---|
| 1 | Intake — Written request with tenant name, requester email/role, scope (user / tenant / specific data categories), and export vs deletion/redaction |
| 2 | Verify — Confirm OWNER/ADMIN authority or data-subject identity |
| 3 | Scope — List systems affected: active DB, audit log, printed history, billing metadata, support sessions, logs, backups |
| 4 | Legal / retention check — Printed checks, financial records, audit trail, legal hold, unresolved billing |
| 5 | Plan — Export package (if any), deactivation, field redaction, tenant suspend, or row delete — avoid promising immediate hard-delete |
| 6 | Execute — Operator actions under change control; no unattended production scripts without approval |
| 7 | Confirm — Written response to requester; document exceptions and retained categories |
| 8 | Audit — Operator ticket record (future in-app audit action optional; not required today) |
Target timeframe: *[e.g., 30 business days — define with counsel at launch]*
6. Deletion vs deactivation vs redaction
Fulfillment often means one or more of the following — not necessarily immediate physical erase:
| Outcome | Meaning |
|---|---|
| Deactivation | User cannot log in; tenant may be suspended |
| Redaction | Identifiable fields cleared or replaced while retaining non-identifying audit/print metadata where required |
| Soft delete | Records hidden from UI but retained in DB |
| Hard delete | Rows removed from active database — operator-only, with retention review |
Printed check history, audit logs, and billing/subscription records may be retained for compliance, fraud prevention, or dispute resolution even when a user or tenant is deactivated.
7. Backups and retention
- Deleting or redacting data in the active database does not remove copies in operator backups.
- Backups are not automatically purged when a deletion request is received.
- Historical backups may age out per `DATA_RETENTION_POLICY.md` and operator disk policy (e.g., 30+ days).
- A separate backup purge request requires explicit operator action and counsel approval.
Encryption: Restoring or retaining backups without `BANK_DATA_ENCRYPTION_KEY` does not enable decrypt; key loss is separate from deletion policy.
8. Export before deletion
Customers should obtain needed exports before requesting destructive scope when legally permitted:
- Project JSON — redacted sensitive fields; suitable for template/project portability review
- Database download — highly sensitive; instance-wide on multi-tenant hosts
Formal export packages (if offered) are manual and may exclude categories under retention hold.
9. Denial or limitation
Requests may be denied or limited when:
- Legal hold or regulatory retention applies
- Identity or authority cannot be verified
- Deletion would affect other tenants on a shared instance
- Contractual minimum retention or open billing disputes apply
- Request asks for immediate backup destruction incompatible with disaster recovery policy
10. Platform operator data
Billing metadata, platform audit entries, and support session history may reference tenant or user IDs after deactivation. Operator may anonymize references per internal procedure.
11. Future workflow (planned — not implemented)
A future phase may add ticket intake, admin review UI, export package builder, redaction/deactivation checklist, and audit trail entries — without unattended hard-delete of production or backups unless explicitly approved.
None of this is implemented in Phase 2P-C.
12. Contact (placeholder)
Privacy / export / deletion: *privacy@example.com* General support: *support@example.com*
*Draft only — Phase 2P-C added Settings guidance and policy text. No deletion automation, no hard-delete scripts, no backup purge automation.*