BeneVets, Inc. - Data Retention Schedule (Document 14)

§ 1. In Plain English

In plain English: This schedule says how long BeneVets keeps each kind of information, why we keep it that long, and what causes us to delete it. Most personal data tied to a user account is kept while the account is active and for a short window afterward, then either deleted or stripped of identifying details. Some categories must be kept longer because federal or state law requires it (for example, audit logs and donation records). A few categories you can ask us to delete right away (for example, your DD-214, your symptom log, and your tracked conditions), and we will, unless a court order or legal hold requires us to keep them. Backups are not searched and edited; they age out and overwrite on their own rotation. When we cannot delete a record (because a law requires us to keep it), we anonymize it instead, so the audit chain stays intact but the personal connection to you is broken.

This schedule is the single source of retention truth for BeneVets. The Privacy Policy, Donor Privacy Policy, and Document Retention Policy all defer to this document for specific durations.

§ 2. Defined Terms (Schedule-Specific)

Capitalized terms not defined here have the meaning given in Document 02 (Privacy Policy) or Document 01 (Terms of Service).

• "Account Closure Event" means the moment at which the User clicks "Delete my account" in the Profile surface, the moment at which a verified Privacy Request requesting deletion is approved, or the moment at which the Board of Directors directs deletion under a documented administrative-closure procedure.
• "Active" means, as to an account, that the account has not been the subject of an Account Closure Event and that the account is not in the 30-day soft-delete window. As to a Helper link, that the link has not been revoked. As to a donation appeal, that the appeal cycle has not closed.
• "Anonymization" means the one-way transformation of a record so that it can no longer be associated, directly or through reasonable means, with a particular User. The technique applied at BeneVets is described in § 7 below.
• "Calendar Day" means a 24-hour period beginning at 00:00:00 UTC. Where a period is stated in calendar days, weekends and federal holidays are counted.
• "Business Day" means Monday through Friday, excluding U.S. federal holidays as listed in 5 U.S.C. § 6103, in the Pacific Time Zone.
• "Hard Deletion" means irreversible removal from all live application databases and live object storage such that the record cannot be reconstituted by ordinary application or operator action. Hard Deletion does not, by itself, reach into immutable backup media; see § 8.3.
• "Legal Hold" means a documented directive from the CEO, Secretary, or retained counsel suspending normal deletion for a defined scope of records pending litigation, audit, investigation, regulatory inquiry, or subpoena response.
• "Soft-Delete Window" means the 30 Calendar Day period immediately following an Account Closure Event, during which the User may recover the account by re-authenticating.
• "WORM" means write-once, read-many storage in which records cannot be modified or deleted by ordinary operator action prior to expiry of the retention period.

§ 3. Scope

This schedule applies to all Personal Information and operational records held by BeneVets, Inc. in connection with the Service, including but not limited to:

1. Every Prisma model defined in the production schema, current and future (see § 5 for the model-by-model treatment).
2. All session and authentication state.
3. All audit log entries.
4. All application telemetry, route-level analytics, and error monitoring data.
5. All file storage envelopes (DD-214 envelopes, profile photos, generated PDFs).
6. All transactional and marketing email logs.
7. All donor and donation records once donation processing activates.
8. All corporate governance records of BeneVets, Inc.

This schedule does not apply to:

• Records held by subprocessors under their own retention policies, except to the extent those policies are constrained by the Data Processing Agreement between BeneVets and the subprocessor. Subprocessor-side retention is enumerated in Document 04 (Sub-processor List).
• VA-side records held by the U.S. Department of Veterans Affairs as a third-party recipient and source. VA retention is governed by VA records schedules, not by this document.

§ 4. Legal-Basis Taxonomy

Every retention period in the master table in § 5 is justified by one (and sometimes more than one) of the following legal bases. The shorthand label is used in the "Legal basis" column.

Where two bases compete (for example, a User-Request deletion against a Legal-Federal recordkeeping obligation), the longer-retention basis prevails and the affected record is anonymized at the User-Request trigger if anonymization preserves the underlying purpose. See § 7.

§ 5. Master Retention Table

Conventions used in the table:

• "Life of account" means the period from account creation through the Account Closure Event.
• "+N years" means N calendar years measured from the Account Closure Event.
• "On request" means the User may, by exercising rights under Cal. Civ. Code § 1798.105 or Wash. Rev. Code § 19.373.030, accelerate deletion of the row regardless of the default trigger. "On request - same as account" means the User cannot accelerate deletion below the default while the account is Active because the data is core to providing the Service.
• Sensitivity tiers: T1 Public, T2 Internal-Operational, T3 Personal Information, T4 Sensitive Personal Information, T5 Government-ID / Financial-Account.

§ 5.1 User Identity and Profile

§ 5.2 Authentication and Sessions

§ 5.3 Documents and Files

§ 5.4 Health and Crisis

§ 5.5 Claims and Intent-to-File

§ 5.6 Account-Linking ("Helpers")

§ 5.7 Communications

§ 5.8 Analytics and Telemetry

§ 5.9 Audit and Compliance

§ 5.10 Donor (When Donation Processing Activates)

These rows reflect the forward-state when on-site donation processing or off-platform donor stewardship begins. Until donation processing activates, the only donor records BeneVets holds are those of donors who arrived via external channels and elected to receive donor email.

§ 5.11 Governance and Corporate

§ 6. Retention Exceptions

A retention period stated in § 5 may be extended, but not shortened, by any of the following.

§ 6.1 Legal Hold

When BeneVets reasonably anticipates or is on notice of litigation, audit, regulatory inquiry, government investigation, or any other matter under which a duty to preserve evidence has attached, the CEO, the Secretary, or retained counsel will issue a written Legal Hold notice. The hold suspends the deletion triggers in § 5 for the defined scope until the hold is released in writing.

The destruction-of-evidence prohibition in 18 U.S.C. § 1519 (Sarbanes-Oxley § 802) applies to any record in the scope of a contemplated federal investigation, audit, or proceeding. Operationally:

• Holds are documented in the LegalHold register and propagated as deletion-suppression flags on affected rows.
• Holds are reviewed at least every 180 calendar days for continued necessity.
• Hold release is also documented; on release, the affected records resume their normal § 5 trigger calculus.
• Records placed under hold while they would otherwise be in the 30-day Soft-Delete Window are preserved past the window; Hard Deletion is deferred until the hold is released, at which point the original deletion proceeds within 30 calendar days.

§ 6.2 Subpoena, Court Order, or Law-Enforcement Preservation Request

A duly served subpoena, court order, search warrant, or preservation request under 18 U.S.C. § 2703(f) extends retention of the scoped records for the period stated in the instrument, or for the period required by applicable law, whichever is longer. BeneVets logs the request in the LegalHold register with a lawEnforcementRequest flag and routes the request through retained counsel.

§ 6.3 Active Claim or Dispute

While a claim, dispute, complaint, or BBB / state-attorney-general inquiry involving the User remains open, all records reasonably related to the claim are retained until 90 calendar days after final resolution, including the period for filing any appeal.

§ 6.4 Active Fundraising Appeal or Annual Reporting Cycle

Donor data scheduled to expire mid-appeal or mid-Form-990-cycle is retained through the close of the appeal or the filing of the Form 990 covering that fiscal year, whichever applies.

§ 6.5 Active Safety Follow-Up

A crisis-keyword scanner trigger or inference scheduled to expire while an active safety follow-up is documented in CrisisTrigger.safetyFollowupOpen = true is retained for the duration of the follow-up plus 30 calendar days, then expires.

§ 7. Anonymization Versus Deletion

§ 7.1 When Anonymization Is Used

Where a regulatory or operational basis forbids deletion (notably the hash-chained AuditLog), or where deletion would destroy a record that BeneVets must retain to defend the integrity of the platform (notably revoked AccountLink audit trail and scammer reports), the personal nexus of the record is severed at the user-deletion event while the operational record is preserved.

§ 7.2 Anonymization Technique

The User identifier embedded in a record subject to Anonymization is replaced with a one-way hash:

anonymized_user_id = HMAC-SHA-256(per-record-salt, original_user_id)

where per-record-salt is a random 256-bit value generated at the moment of anonymization and stored only with the anonymized record. The mapping (anonymized_user_id, original_user_id) is not retained: the original identifier is overwritten with NULL and the row's anonymizedAt timestamp is set. Because the salt is unique per anonymization event and the original identifier is destroyed, the hash cannot be reversed by BeneVets, by a subprocessor, or by anyone with read access to the database.

Records anonymized in this way:

• preserve the audit chain (the hash-chained log remains intact because the hashed identifier still satisfies the hash chain),
• preserve the row count for compliance reporting,
• cannot be re-associated with the User after anonymization, even by BeneVets,
• and, per Cal. Civ. Code § 1798.140(o), constitute "deidentified" information when the technical and administrative safeguards in this section are also enforced.

§ 7.3 Records Subject to Anonymization Rather Than Hard Deletion

• Hash-chained AuditLog entries that reference the deleted User.
• AccountLink records in REVOKED status referencing the deleted User (after the 24-month abuse-investigation window).
• ScammerReport records in which the deleted User is the reporter (the reported party's identity is preserved unchanged).
• CrossAccountRead audit entries beyond the 7-year link-end window if SOC 2 readiness requires longer.

§ 7.4 Records Subject to Hard Deletion (Not Anonymization)

All records in § 5 not listed in § 7.3 are subject to Hard Deletion on their stated trigger. In particular, ProfileVault envelopes (DD-214, SSN, bank), SymptomLog entries, TrackedCondition entries, and profile photos are always Hard Deleted, never anonymized.

§ 8. Deletion Mechanics

§ 8.1 User-Initiated Deletion

1. User clicks "Delete my account" in the Profile surface and confirms.
2. An Account Closure Event is recorded. The account immediately enters the 30-Calendar-Day Soft-Delete Window. Sessions are revoked. The User cannot sign in by password. The User can recover the account by completing a recovery flow that requires email re-verification.
3. On day 31, a scheduled job performs Hard Deletion on the categories listed in § 5 whose trigger is "Account Closure Event," and starts the longer retention clocks (e.g., the 7-year FormSubmission clock, the 24-month AuditLog anonymization clock).
4. The User receives a confirmation email at the address of record at the time of the Account Closure Event. The email contains the date of Hard Deletion and the categories preserved under longer retention.

§ 8.2 Privacy-Request Deletion (Cal. Civ. Code § 1798.105, § 1798.130(b); Wash. Rev. Code § 19.373.030)

1. The request is received through the Profile surface, the privacy@benevets.org mailbox, or the toll-free intake line if and when activated.
2. Identity verification is performed per Cal. Code Regs. tit. 11, § 7060.
3. Receipt is acknowledged in writing within 10 Business Days per Cal. Civ. Code § 1798.130(a)(2)(A).
4. The substantive response and deletion are completed within 45 Calendar Days of receipt, extendable once by an additional 45 Calendar Days when reasonably necessary per Cal. Civ. Code § 1798.130(b), with notice to the User.
5. The User-Request deletion accelerates the "User-Request" trigger rows in § 5 (DD-214, ProfileVault SSN/bank, SymptomLog, TrackedCondition, profile photo) regardless of any otherwise applicable longer trigger, subject only to active Legal Hold under § 6.1, regulatory exception under Cal. Civ. Code § 1798.105(d), or law-enforcement preservation under § 6.2.
6. Where a User requests deletion of a record subject to a longer regulatory retention that cannot be honored (for example, an AuditLog entry), BeneVets performs Anonymization under § 7 at the request resolution and communicates that anonymization, not deletion, is the available remedy.

§ 8.3 Backups, Archives, and Replicas

Deletion of a record from the live application database propagates immediately to read replicas through ordinary replication.

Backup tapes, snapshots, and archival object-storage versions that contain the record at the moment they were captured are not edited. Backups age out and are overwritten on the documented backup rotation:

• Daily snapshots: rolling 14 calendar days, then overwrite.
• Weekly snapshots: rolling 8 weeks, then overwrite.
• Monthly snapshots: rolling 12 months, then overwrite.
• Annual snapshots: rolling 7 years, then overwrite. (Required to satisfy the AuditLog and FormSubmission retention floors.)

A User-Request deletion does not trigger a search-and-destroy operation against the backup set, except where Wash. Rev. Code § 19.373.030(2)(c)(iv) requires it for consumer health data. For SymptomLog and TrackedCondition records, BeneVets will, upon a verified User-Request deletion, place a deletion-on-restore flag on the relevant record ID such that if the affected backup is ever restored, the record is re-deleted before the restore is opened to application traffic. This satisfies the "extraordinary procedure" contemplated by Wash. Rev. Code § 19.373.030(2)(c)(iv) while preserving the integrity of the backup chain.

§ 8.4 Subprocessor Propagation

When a record subject to Hard Deletion exists at a subprocessor (for example, an email transmission log at Resend, or a Sentry error event), BeneVets issues a deletion-propagation request through the subprocessor's documented mechanism within 30 calendar days of the originating deletion. Subprocessor expiry on the subprocessor side is also relied upon. The Sub-processor List (Document 04) reflects each subprocessor's confirmed propagation latency.

§ 9. Cross-References

This schedule is cross-referenced by, and operates in concert with, the following BeneVets documents:

• Document 02 - Privacy Policy §§ 3-11 (retention column entries defer to this schedule).
• Document 04 - Sub-processor List (subprocessor-side retention durations and propagation latency).
• Document 07 - Helper / Account-Linking Terms § 3, § 4, § 8 (AccountLink retention and cross-account read audit).
• Document 09 - Donor Privacy Policy § 5, § 6 (donor and donation retention).
• Document 13 - Security and Vulnerability Disclosure Policy § 5-§ 9 (session, audit, incident retention).
• Document 15 - Automated Decision-Making and AI Notice § 4, § 5 (crisis-keyword retention and right-to-limit).
• Document 17 - Conflict of Interest Policy (annual disclosure retention).
• Document 18 - Whistleblower and Document Retention Policy (corporate-governance and whistleblower retention).

To the extent any other document states a retention period that conflicts with this schedule, this schedule controls and the other document is to be conformed.

§ 10. Schedule Maintenance

1. Annual review. The Secretary, supported by the Treasurer and the operational owner, reviews this schedule no later than the second board meeting of each calendar year.
2. Out-of-cycle review. Required upon any of: (a) a material change to the Prisma schema introducing a new data category, (b) activation of donation processing, (c) activation of SMS, (d) a new regulatory obligation (state privacy law expansion, IRS or VA regulatory change), (e) onboarding or offboarding of a subprocessor, (f) a security incident touching retention.
3. Board ratification. Changes that lengthen or shorten any retention period at or above 7 years, that touch a "Permanent" row, or that change the deletion trigger on a T4 or T5 row require Board ratification. Other changes (clarifications, new T2 rows added under existing trigger logic, citation updates) may be approved by the Secretary with notice to the Board at the next meeting.
4. Version control. Each revision increments the document version. The prior version is preserved in the Legal-Drafts/_archive/ directory.
5. Audit log of revisions. Each revision is logged in AuditLog with the actor, the section changed, and the rationale.

§ 11. Forward-State Items to Update

The following rows are written to be activated, not removed, at the listed milestones. They are listed here so the reviewer knows what to look for.

1. Donation processing activation: § 5.10 rows shift from "forward-state" to active. Add DonorPaymentToken propagation row to Document 04. Confirm Stripe DPA retention.
2. SMS activation: Add a new sub-table in § 5.7 for SMS transmission metadata (carrier handoff logs, opt-in-evidence record). The prior-express-written-consent evidence record must be set to "Life of opt-in + 4 years" per 47 U.S.C. § 227 statute-of-limitations practice.
3. SOC 2 readiness: Activate the WORM mirror on AuditLog. Add AuditLogMirror row and confirm 7-year minimum on the WORM device.
4. HIPAA business-associate posture (if ever): Add a new sub-table with PHI categories; conform to 45 C.F.R. § 164.530(j) (6-year retention of HIPAA policies, procedures, and disclosure accountings).

End of Document 14 - Data Retention Schedule.