Data Retention and Disposal Policy
Organization: System4IPS (operated by DiBro Holdings Inc.) Document version: 1.0 Effective date: May 1, 2026 Next review date: May 1, 2027 Document owner: Max Bertman, President
1. Purpose
This Data Retention and Disposal Policy defines how long System4IPS retains different categories of data processed by the Billing Portal (the "Application"), and how that data is securely disposed of when retention requirements are met.
The policy is designed to:
- Comply with applicable legal and regulatory requirements (Nacha, ESIGN, state data privacy laws)
- Minimize the volume of sensitive data held at any given time
- Enable consumer rights requests (access, deletion, portability)
- Ensure that disposed data cannot be recovered or reconstructed
2. Scope
This policy applies to all data processed by the Application, including:
- Consumer financial data received from Plaid (bank account numbers, routing numbers, account holder names)
- Consumer payment instrument identifiers received from Stripe
- Consumer identity information (name, email, business name)
- Authorization records (Nacha consent, signed agreements)
- Audit logs and operational telemetry
This policy does not apply to data processed outside the Application's scope (e.g., general System4IPS business records, accounting records, franchisor-software invoice data — those are governed by separate retention schedules).
3. Retention Schedule
| Data Category | Retention Period | Rationale | Disposal Method |
|---|---|---|---|
| Bank account numbers (encrypted) | Until consumer is enrolled in Webster e-Treasury (the system of record), then immediately deleted | Minimize sensitive data held; Webster becomes system of record after enrollment | Set encrypted columns to NULL in database; ciphertext is unrecoverable without separately-stored key |
| Bank routing numbers | Until consumer is enrolled in Webster e-Treasury, then deleted | Same as account numbers | Database row update |
| Account holder names | Same as account numbers | Privacy minimization | Database row update |
| Plaid access tokens | Discarded immediately after initial use; never persisted to the database | Plaid data is captured once at onboarding and not re-fetched | Variable scope expires; never written to disk |
| Stripe customer identifiers | Retained for the lifetime of the customer relationship plus 2 years | Required for processing recurring charges and supporting refund/dispute resolution | Database row deletion |
| Stripe payment method identifiers | Retained while payment method is on file; deleted when consumer requests removal or relationship ends | Required for charge functionality | Database row update |
| Card metadata (brand, last 4, expiration) | Same as Stripe payment method identifiers | Display purposes only; non-sensitive | Database row update |
| Consumer name, email, business name | Retained for the lifetime of the customer relationship plus 2 years | Required for billing operations and audit trail | Database row deletion |
| Onboarding tokens | Marked used or expired within 7 days of issuance; row retained for audit purposes | One-time use; expiration enforced in code | Token marked used; row retained |
| Nacha authorization records | Minimum 2 years after the date of authorization OR 2 years after revocation, whichever is later (per Nacha Operating Rules) | Federal Nacha rule requirement; required for dispute defense | Database row deletion after retention period; PandaDoc-signed proposals retained per PandaDoc retention |
| Reveal log entries (audit trail of admin reveals) | 2 years from event | Audit and dispute defense | Database row deletion |
| Charge log entries (audit trail of card charges) | 2 years from event, or longer if part of an active dispute | Audit, accounting, dispute defense | Database row deletion |
| HTTP access logs (Vercel) | Per Vercel default retention (currently approximately 30 days) | Operational diagnostics; minimal sensitive data | Vendor-managed deletion |
| Email delivery logs (Resend, when enabled) | Per Resend default retention | Delivery troubleshooting | Vendor-managed deletion |
4. Disposal Procedures
4.1 Encrypted Bank Account Numbers
When a consumer has been successfully enrolled in Webster e-Treasury (the bank-side system of record), the administrator marks the consumer record accordingly. The Application then sets the encrypted account number, IV, and authentication tag database columns to NULL in a single atomic update. Because the encryption key is stored separately in the deployment platform's secret store, the resulting NULL'd ciphertext is unrecoverable even if the database were later compromised.
4.2 Database Row Deletion
When a record reaches the end of its retention period, it is deleted using a hard DELETE against the database. The database provider (Supabase) does not retain deleted rows in user-accessible storage; backup snapshots include deleted rows for the duration of the backup retention window (currently 7 days for point-in-time recovery), after which they are no longer recoverable.
4.3 Backup Disposal
Database backups beyond the 7-day point-in-time recovery window are deleted by the database provider on a rolling basis. No long-term backups are retained outside of operational necessity.
4.4 Local Workstation Data
No consumer data is intentionally stored on the administrator's local workstation. Browser cache and session data on the administrator's workstation are cleared periodically and on system restart.
5. Consumer-Initiated Deletion Requests
Consumers may request deletion of their personal data at any time by emailing privacy@system4ips.com. Upon receiving a verified deletion request, System4IPS will:
- Within 5 business days: Acknowledge receipt of the request
- Within 30 days (or 45 days if the request is complex): Complete the deletion or provide a written explanation if deletion cannot be performed
- Notify sub-processors: Request deletion from Stripe, Plaid, and other sub-processors that hold consumer data on our behalf
5.1 Exceptions to Deletion
Certain data may be retained beyond a deletion request when required by law or for legitimate business purposes:
- Nacha authorization records during their mandatory 2-year retention window (federal regulatory requirement)
- Records subject to active legal hold or pending dispute
- Anonymized or aggregated data that cannot reasonably be linked back to the consumer
- Tax and accounting records required by IRS or state law
When data is retained under an exception, the consumer is informed of the basis and the period of retention.
6. Verification of Disposal
Disposal is verified through:
- Database queries: Periodic queries to confirm that records past their retention date have been deleted (run quarterly)
- Audit log review: Confirmation that no NULL'd encrypted columns contain residual data
- Vendor attestations: Where deletion is performed by a sub-processor, reliance on that vendor's documented retention and deletion practices (per their SOC 2 reports or equivalent)
7. Roles and Responsibilities
| Role | Responsibility |
|---|---|
| Information Security Officer | Overall accountability for this policy; review and update annually |
| Privacy Officer | Handling consumer deletion and access requests |
| System Administrator | Executing scheduled deletion jobs and verifying disposal |
For System4IPS at its current size, all three roles are filled by Max Bertman, President.
8. Policy Review and Maintenance
This policy is reviewed at minimum annually, and additionally upon:
- Any change to applicable retention requirements (new state laws, Nacha rule updates, etc.)
- Addition or removal of a data category
- Any consumer complaint or audit finding related to retention or disposal
The current version of this policy is maintained at docs/data-retention-policy.md in the Application's source repository.
9. Approval
Approved by:
Max Bertman President, DiBro Holdings Inc. (operating as System4IPS) Date: May 1, 2026