# HIFP — Data Lifecycle SLA v0.1 **Purpose.** Specify retention, deletion, backup, disaster recovery, export, portability, and residency SLAs with named owners and enforcement — at the level a chain BA, SOC 2 auditor, or a user asking "when does this actually happen" can point at. **Date.** 2026-09-02 **Version.** 0.1 — draft. Authored by Brandon; requires (a) founding backend-engineer review of RTO/RPO feasibility on chosen AWS RDS tier, (b) counsel review of retention floor interactions with state privacy laws. **Companion.** [[HIFP-compliance-foundation-v0.1]] §4, [[HIFP-security-architecture-v0.1]] §3, [[HIFP-product-design-v3.1]] §6 (data model tables), [[HIFP-POV-v3.1]] §9 Pillar 4. --- ## Executive Frame (SCQ) **Situation.** POV v3.1 pillar 4 promises "export or delete your data any time" with a 30-day active-deletion window. Compliance Foundation v0.1 §4 asserts 30-day active / 90-day cold / 7-year audit floor. Product Design v3.1 §6 defines the tables that hold each data class. **Complication.** The promises exist across three docs; the actual SLAs — owners, enforcement, reporting, disaster-recovery targets, export format schema, cross-jurisdiction residency — do not exist as one contract. **Question.** What is the minimum unified SLA doc that a chain BA, SOC 2 auditor, or user can point at as the single source of truth for "when and how does HIFP handle my data across its full lifecycle"? **Answer.** Six-part SLA covering retention (by data class), deletion (user-initiated + admin + cryptographic destruction), backup + disaster recovery (with quantified RTO / RPO), export + portability (versioned schema + 24-hour SLA), residency (US-only at MVP; explicit international posture in Y2), and enforcement (Vanta/Drata continuous + quarterly manual review) — each with a named owner and audit interlock. --- ## Governing Thought **Every data-lifecycle event at HIFP has a numeric SLA, a named owner, an enforcement mechanism, and an audit interlock — with retention driven by data class, deletion driven by user right, backups driven by RTO/RPO, and residency driven by jurisdiction.** Three consequences follow: 1. **User promises are enforceable, not aspirational.** A user requesting deletion gets a machine-readable confirmation with the completion date; a user requesting export gets a validated JSON schema output; a user auditing their history gets an unedited replay. Each has a stopwatch on it. 2. **Compliance retention and user preference are reconciled explicitly.** The 7-year audit-log floor coexists with the 30-day deletion SLA via a defined anonymization mechanism (hash user identifiers, purge salts, retain event metadata). No implicit conflicts. 3. **RTO/RPO are numeric, not a hope.** Postgres RDS PITR + cross-region snapshots + documented restore procedure make a 15-minute RPO and 4-hour RTO achievable at MVP scale. --- ## §1 · Retention SLAs (by data class) | Data class | Storage | Default retention | User override | Owner | |---|---|---|---|---| | **Tier-1 PHI/PII** — biomarkers, meds, family history, wearable streams, EHR-sourced, advanced-diag, agent turns | Postgres + S3 | Life of account + 30 days grace after deletion request | User-initiated deletion honored | Data Steward (CTO/CPO) | | **Tier-2 financial** — portfolio, income, plan outputs, invoices | Postgres | Life of account + 30 days grace | User-initiated deletion honored | Data Steward | | **Tier-3 operational** — audit metadata, model versions, tier-event stream | Postgres | **7 years** (SOC 2 audit-log floor) | Not user-controllable; anonymized post-account-deletion | Compliance Officer | | **Financial records** — invoices, refunds, tax records | Postgres + Stripe | **7 years** (US tax law) | Not user-controllable | Finance | | **Backups (Tier-1 + Tier-2)** | AWS S3 + Glacier | 90 days rolling + point-in-time to 35 days | User-deletion propagates on next rotation | Platform Engineer | | **LLM provider retained content** | Anthropic / OpenAI zero-retention endpoints | Zero retention on request-path; audit-log on HIFP side | User-deletion request forwarded to LLM provider | Data Steward | --- ## §2 · Deletion SLAs **User-initiated deletion.** - **Confirmation to user:** within **15 minutes** (email + in-app). - **Active systems purge (Postgres + Redis + LLM-provider audit forwarding):** within **30 days**. - **Cold backups + S3:** within **90 days** (bounded by next backup rotation). - **Cryptographic key destruction** (per-tenant CMK at Series B; envelope keys at MVP): within **90 days**. - **User receives final confirmation** with completion date + affected data class list. - **Owner:** Data Steward (CTO/CPO). **Enforcement:** Vanta control check on deletion queue depth. **Admin-initiated deletion** (compliance / legal hold expiry). - Requires two-person integrity: Data Steward + General Counsel (or delegated). - SLA: same as user-initiated once approved. **Cryptographic key destruction.** - Per-tenant key deletion makes prior backups unreadable per tenant at Series B; at MVP, envelope-key destruction achieves the same at the data-key level. - Certified by KMS audit-log entry retained for 10 years. **Anonymization for compliance-retained rows.** - User identifiers hashed with per-user salt; salt purged at deletion; hash retained for 7-year audit floor. - Event metadata (kind, timestamp, verdict) retained; content (agent turn text, plan output) purged. - Documented in Compliance Foundation §4. --- ## §3 · Backup + Disaster Recovery **Backup posture.** - **Postgres:** RDS automated backups with 35-day point-in-time recovery. Cross-region snapshot to secondary AWS region (us-east-1 primary → us-west-2 DR) every 24 hours. Snapshots retained 90 days rolling; monthly full retained 12 months. - **S3 object storage:** cross-region replication to DR region, versioning enabled, MFA-delete on delete operations. - **Vault / Secrets Manager:** AWS-native replication to DR region; recovery-key sealed in offline safe (two-person integrity). **Disaster recovery targets.** - **RPO (data-loss window):** **15 minutes** — driven by RDS transaction-log shipping to standby. - **RTO (recovery time):** **4 hours** for full production restore to DR region. **1 hour** for single-service failover (application layer to standby ECS cluster). - **DR drill cadence:** quarterly tabletop; annual full failover exercise. **Owner:** Platform Engineer. **Enforcement:** Vanta control on backup completion + monthly restore-verification. --- ## §4 · Export + Portability **JSON export.** - **Format:** versioned schema (`hifp-export-v1.json.schema.json`). Includes account metadata, all consent history, all connections + panels + streams, all plan snapshots, all agent turns, all audit events (user's own), all household-membership records. - **SLA:** delivered within **24 hours** of user request; larger accounts (>1 GB) within 72 hours with a progress notification. - **Delivery:** signed S3 URL, expires 7 days after issuance; email notification. - **Validation:** consumers of the export can validate against the published JSON schema (available at `hifp.example/schemas/export/v1`). **PDF portable summary.** - **Format:** printable plan brief (mirrors advisor-share format). - **SLA:** on-demand generation, <10 seconds. **Portability to third parties.** - Advisor JSON export subset (eMoney / RightCapital compatible) — same schema, filtered to plan output only, no raw biomarkers unless user opts in. - Physician-share PDF — clinical-context format, aggregate cohort or individual per user choice. **Owner:** Product Engineer (share flow). **Enforcement:** e2e test on export completeness + schema validation on every release. --- ## §5 · Data Residency **MVP posture.** - **US-only.** All data (Tier-1, Tier-2, Tier-3, backups, DR) stays in US AWS regions (us-east-1 primary, us-west-2 DR). - **International users blocked at edge** via Cloudflare geo-block. Waitlist form for EU/UK. **Y2 posture (international activation).** - **EU users:** primary storage in eu-west-1 with EU-only backup + DR (eu-central-1). GDPR SCCs for any US-to-EU cross-border transfer. - **UK users:** primary storage in eu-west-2. UK-GDPR posture per Compliance Foundation §1. - **Chain-partner data residency requirements** honored per BAA. **Owner:** Compliance Officer + Platform Engineer joint. **Enforcement:** per-user residency flag in `user` table + service routing at API gateway. --- ## §6 · Enforcement + Reporting **Continuous enforcement (Vanta or Drata).** - Deletion queue depth (alert if > 100 pending > 24 hours) - Backup completion status (alert on any missed run) - Restore-verification (monthly automated restore-and-diff on a synthetic dataset) - Export SLA hit rate (alert if p95 > 24 hours over any 7-day window) - Encryption-at-rest verification (KMS audit) **Manual review (quarterly).** - Sample 20 deletion requests; verify propagation to cold backups. - Sample 10 exports; verify schema compliance. - Review DR drill results; escalate any target miss. **Reporting cadence.** - **User-visible:** each user's deletion + export events appear in their History page. - **Compliance-officer-visible:** monthly SLA-hit-rate dashboard, quarterly manual-review results. - **External:** annual data-lifecycle report published on `hifp.example/trust` (aggregate metrics only). --- ## §7 · Owner RACI | Function | R | A | C | I | |---|---|---|---|---| | Retention policy | Data Steward | CTO/CPO | Compliance Officer, GC | Board | | Deletion queue operations | Data Steward | CTO/CPO | — | User | | Backup + DR | Platform Engineer | CTO/CPO | Compliance Officer | Board | | Export + portability | Product Engineer | CPO | Data Steward | — | | Residency | Platform Engineer | Compliance Officer | GC | — | | SLA reporting | Compliance Officer | CEO | Data Steward | Board | --- ## §8 · What v0.1 Explicitly Defers - **RTO/RPO validation on chosen RDS tier** — target 15-min RPO / 4-hr RTO; validate against `db.r6g.xlarge` or successor at MVP scale. - **Cross-region latency implications** — measure and publish. - **Actual JSON export schema** — draft during MVP build; publish at v1 lock. - **Chain-partner-specific residency contract riders** — negotiate per chain during BAA process. - **Automated restore-verification tooling** — build vs. buy decision during MVP eng.