Raxx · internal docs

internal · gated ↑ index

Data Retention Policy — Raxx

Version: 1.0.0 Last Updated: 2026-05-11 UTC Owner: Operator (Kristerpher) Next review: 2027-05-01 UTC (annual)

Status: ACTIVE as of v1 launch. This policy documents retention commitments referenced in the privacy policy (docs/legal/policies/privacy-policy-v1.md, Section 5). Automated retention enforcement is deferred to 2026-Q3 (#1631). During the deferral window, retention is enforced manually per Section 4 of this doc.

This document does NOT constitute legal or tax advice. Tax-retention periods should be confirmed with the project CPA. See BLR DIY privacy memo PR #1646, ADR-0076 §OQ-4.

Cross-references

1. Retention Periods by Data Category

Data category Retention period Action at expiry Notes
Customer PII (email, name, billing address: line1, line2, city, state, postal, country) Account active + 7 years post-close Anonymize: email → anonymized-<uuid>@deleted.local; name, address fields → NULL 7-year floor is tax law minimum; country field — confirm with CPA whether needed post-anonymization for tax nexus
Invoice and transaction records 7 years post-transaction NEVER deleted; PII linkage anonymized (customer name/email removed from display) but invoice rows retained IRS Publication 583; state-equivalent record-keeping requirements
Payment event history (late_payment_count, chargeback_count, failed_charge_count) Account active + 7 years post-close Anonymize with billing_customer row (zeroing counts is acceptable; do NOT delete rows needed for dispute resolution) Aligns with billing record floor; needed for chargeback dispute defense
Acquisition source (acquisition_source) Account active + 2 years post-close Null or delete field value Proportionate to business analytics purpose; longer retention not justified
Customer segment (customer_segment) Account active + 2 years post-close Null or delete field value Proportionate to configuration purpose
Strategy configuration data Account active + 90 days post-cancellation Delete or archive to cold storage 90-day window allows user to export before data is purged
Usage and session logs 90 days Delete Security monitoring and debugging; proportionate to purpose
Audit log entries (billing_action_log) 7 years minimum Retain; do NOT delete Compliance evidence; legal claim defense
DSR request records (FreeScout tickets tagged dsr-request + billing_action_log entries) 7 years from request date Retain GDPR accountability principle (Art. 5(1)(f)); evidence of compliance
Error monitoring logs (Sentry) 90 days Deleted by Sentry automatically (Sentry default retention) Configure Sentry data retention to 90 days if not already set
Login and session tokens Session end (essential); up to 90 days for persistent preference cookies Expire automatically Managed by application session/cookie logic
Transactional email delivery logs (Postmark) 45 days Deleted by Postmark automatically (Postmark default) Postmark default retention; adjust if needed for debugging SLA

2. Justifications Per Category

2.1 Tax and Financial Records — 7-Year Floor

Legal basis: IRS Publication 583 ("Starting a Business and Keeping Records"), Section: "How Long to Keep Records":

"Keep records for 3 years from the date you filed your original return or 2 years from the date you paid the tax, whichever is later, if you file a claim for credit or refund after you file your return. Keep records for 7 years if you file a claim for a loss from worthless securities or bad-debt deduction."

The IRS recommends 7 years as the safe harbor for businesses with any bad debt or deduction exposure. For a SaaS business with recurring billing and chargeback exposure, 7 years is the defensible minimum.

State equivalents: California (FTB) and most state revenue agencies align with the federal 7-year floor for business records. Operator CPA to confirm applicable state obligations.

Refs: - IRS Publication 583 (2023): https://www.irs.gov/publications/p583 - IRS General Business Records: https://www.irs.gov/businesses/small-businesses-self-employed/how-long-should-i-keep-records - California FTB Record Keeping: https://www.ftb.ca.gov/file/business/business-basics/record-keeping.html

2.2 GDPR Storage Limitation — Art. 5(1)(e)

GDPR Article 5(1)(e) requires that personal data be "kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data are processed."

For Raxx, each retention period is justified as follows:

Category Storage limitation justification
Customer PII (7 years) Necessary for tax compliance obligation (Art. 6(1)(c)) and legitimate interest in financial record-keeping (Art. 6(1)(f)); anonymization (not deletion) achieves the storage limitation goal while preserving audit trail
Invoice records (7 years) Legal obligation (Art. 6(1)(c)) — tax law mandates these records; storage limitation principle satisfied by anonymizing PII linkage, not the financial data itself
Usage/session logs (90 days) Proportionate to security monitoring and debugging purpose; no legitimate interest justifies longer retention
Strategy data (90 days post-cancel) Proportionate to user export window; after 90 days, the contract purpose has ended and legitimate interest does not justify retention
Acquisition source (2 years) Proportionate to business analytics purpose; 2 years provides sufficient growth-trend analysis without retaining longer than necessary

2.3 CCPA / CPRA Disclosure Requirements

CCPA (Cal. Civ. Code § 1798.100 et seq.) requires that businesses disclose the retention period for each category of personal information in their privacy policy, or the criteria used to determine the period.

Raxx's privacy policy (docs/legal/policies/privacy-policy-v1.md, Section 5) discloses the retention table above. This satisfies the CCPA disclosure requirement.

Note: Raxx is almost certainly not a CCPA-covered business at v1 (self-determination per docs/legal/artifacts/cpra-threshold-self-determination.md). The disclosure is maintained as best practice regardless.

CPRA 2026 updates: CPRA extended the CCPA right to access lookback to data collected since January 1, 2022. Any DSR access request must cover data from that date forward, regardless of when the customer signed up.

3. Automation Trigger Threshold

The automated retention job (#1631) is deferred to post-launch. The earliest any customer data approaches the 7-year mark is approximately:

Calendar reminder: 2031-Q1 (approximately 2031-03-01 UTC) — verify that the automated retention job (#1631) is built, tested, and operational before any customer data reaches the 7-year mark.

Until the automated job is operational, retention enforcement is manual (Section 4 below).

The warning threshold is set at the 5-year mark (not the 7-year mark) to allow 2 years of runway for the job to be built, tested, and deployed before any actual data expires.

4. Manual Enforcement (Pre-Automation Era)

Until the automated retention job ships (#1631), retention is enforced as follows:

4.1 Regular manual review

Frequency: Annual (calendar reminder: 2027-05-01 UTC, 2028-05-01 UTC, etc.)

Review steps:

  1. Query billing_customer for rows where updated_at (or account_closed_at, if implemented) is older than 7 years and anonymized_at IS NULL.
  2. For each such row: follow the anonymization process in docs/ops/runbooks/manual-dsr-handling.md Section 3.3.
  3. Query for strategy configuration data older than 90 days post-cancellation and delete/archive.
  4. Query for usage/session log data older than 90 days and delete.
  5. Confirm Sentry and Postmark automatic retention settings are still configured correctly.

4.2 Manual retention SQL — identify overdue anonymizations

-- Find billing_customer rows past the 7-year retention limit
-- Adjust 'account_closed_at' to the correct column name when it exists
-- Until account_closed_at is implemented, use updated_at as a proxy
SELECT
    id,
    email,
    created_at,
    updated_at,
    anonymized_at
FROM billing_customer
WHERE anonymized_at IS NULL
  AND updated_at < NOW() - INTERVAL '7 years'
ORDER BY updated_at ASC;

4.3 Edge cases for manual process

Situation Process
Customer requests early anonymization Use DSR process in docs/ops/runbooks/manual-dsr-handling.md Section 3.3
Account closed but customer wants extended retention Operator-handled; document the request and justification; update audit log
Account closed with disputed payments Retain per Section 1 (legal claims exemption); document the hold reason in billing_action_log
Customer's data is subject to a legal hold Do NOT anonymize until legal hold is released; document in billing_action_log with hold reason

5. Annual Policy Review

This policy must be reviewed annually against:

  1. Actual practice: Does what we do match what this policy says? Query retention dates; verify automatic deletions are firing.
  2. Regulatory changes: Have GDPR, CCPA, or IRS guidance changed in a way that affects our retention periods?
  3. Product changes: Have new data categories been introduced that are not covered by this policy? (Any new data-collection field added to the schema must be reviewed against this policy before shipping — add to PR template.)
  4. CPA confirmation: Re-confirm with project CPA that the 7-year floor still covers all applicable tax obligations.

Review schedule:

Review date Action
2027-05-01 UTC Annual review — year 1 post-launch
2028-05-01 UTC Annual review — year 2
2031-03-01 UTC Special review — confirm automated job (#1631) is operational before first data hits 7-year mark
At first enterprise deal Trigger Tier B attorney review (BLR recommendation: DIY path PR #1646)

6. Open Questions (Requiring CPA Confirmation)

The following retention decisions are flagged for CPA confirmation before the annual review or before automated enforcement begins:

  1. address_country post-anonymization: The anonymization SQL in the DSR SOP nulls address_country. However, this field may be needed for tax nexus reporting after account closure. CPA to confirm whether address_country must be retained post-anonymization.

  2. Payment event count retention period: late_payment_count, chargeback_count, failed_charge_count are retained 7 years (aligned with billing records). CPA to confirm whether these operational metrics are "books and records" under 26 U.S.C. § 6001 and IRS Publication 583, or whether a shorter period is justified.

  3. Chargeback documentation retention: Stripe chargeback evidence may need to be retained for bank/Stripe dispute processes beyond 7 years in some cases. CPA to confirm minimum retention for financial dispute purposes.

This policy cross-references: - docs/legal/policies/privacy-policy-v1.md — public-facing retention commitment - docs/ops/runbooks/manual-dsr-handling.md — DSR process including early anonymization - docs/legal/artifacts/ropa-template.md — GDPR Art. 30 records with retention periods per processing activity - Issue #1631 — automated retention job (deferred to post-launch)