Data Retention & Deletion Policy

SendTax retains customer data only as long as a defined purpose or legal obligation requires, then disposes of it verifiably. This policy is a companion to our Privacy Policy (which governs what we collect and why) and to our Information Security, Access Control, Encryption, and Incident Response policies.

Items marked Roadmap are not yet in production.

---

1. Purpose

This policy defines how long SendTax retains the data it holds, what triggers deletion, and how customers can exercise their rights to access, correct, and erase their information. It supports the commitments made in our Information Security policy and aligns with SOC 2 Common Criteria CC6.5, C1.1, and C1.2 and Privacy criterion P4.2.

SendTax handles taxpayer data subject to specific regulatory retention obligations. This policy reflects those obligations and adds SendTax-specific commitments where appropriate.

---

2. Principles

1. Purpose-bound retention. We retain personal data only as long as we have a defined purpose for holding it — service delivery, legal compliance, or product-improvement work the customer has explicitly consented to.
2. Legal obligations override convenience. Where U.S. or other applicable tax-data law requires us to retain a record longer than the customer might prefer, the legal minimum wins and we keep the record until the obligation expires.
3. Right to know, right to correct, right to delete. Customers may request access, correction, and (subject to § 5) deletion of their data. We respond on the timelines required by applicable law.
4. Documented purges. Automated retention sweeps run on a defined cadence, log their actions, and are auditable.
5. Honest disposal. When we say data is deleted, the disposal method makes that true, with the exception of backup-aging behavior described in § 7.

---

3. Categories of data and retention periods

SendTax categorizes customer data by purpose. Each category has a retention period set by a combination of business need, legal obligation, and product-improvement consent. Periods marked (Roadmap) are commitments we are implementing; current behavior is described in § 4 and § 9.

3.1 Service data (the default category)

What it is: account profile, contact details, tax-return data being prepared, supporting documents, audit-log entries for activity on the account.

Retention: Up to 7 years after the last activity on the account, unless a longer retention period is required by law or contract. This default tracks the commitment in our public Privacy Policy and is enforced in code by the ACCOUNT_RETENTION_DAYS / DOCUMENT_RETENTION_DAYS settings (2,557 days ≈ 7 years).

Why this number: Matches AICPA professional guidance for tax-data retention; exceeds the IRC § 6107(b) three-year minimum applicable to certain preparer records; and accommodates most state tax-agency requirements and typical IRS statute-of-limitations windows. Customers may request earlier deletion under § 5, subject to the legal-obligation carve-outs in § 3.2.

3.2 IRS-mandated e-file records

What it is: taxpayer authorizations and supporting records that the IRS requires authorized e-file providers to retain — including Form 8878 (e-file signature authorization for application for extension), Form 8879 (e-file signature authorization for individual returns), and any equivalent state authorizations.

Retention: 3 years from the later of (a) the return due date or (b) the IRS-received date, per IRS Publication 1345.

Override: This retention obligation overrides any customer request to delete the affected records earlier. We will tell the customer that the obligation applies, what records are affected, and when the obligation expires.

3.3 Identity documents

What it is: documents used for identity verification (e.g., driver's-license images, identity-verification scans).

Retention: Retained only as long as needed for identity verification; target deletion is verification completion + 90 days (IDENTITY_RETENTION_DAYS). The purge task is implemented and runs daily in dry-run pending production enablement (IDENTITY_DOCUMENT_PURGE_ENABLED). (Roadmap)

Why this number: Data minimization. Identity documents have a narrow operational purpose and should not be retained long-term.

3.4 Anonymized training contributions

What it is: anonymized document artifacts that customers explicitly contributed to the SendTax model-improvement program, stored in Cloudflare R2 under the contributions bucket prefix.

Retention: 1,095 days (3 years) from contribution approval, configured by the TRAINING_ARTIFACT_RETENTION_DAYS setting and enforced by an automated daily purge task (purge-expired-training-contributions). At expiration, the R2 artifact is deleted, the wrapped DEK and storage pointer are cleared on the contribution row, a purged_at timestamp is stamped, and the labeler image cache is invalidated. Derivative label metadata (annotations describing what was in the document) is retained for model-lineage purposes; the underlying document is gone.

Why this number: Aligned with the FTC Safeguards Rule's retention-minimization expectations and with the consent text customers see when they opt in.

Customer override: Contributors may withdraw a contribution at any time through the separate withdrawal flow, which deletes the artifact and removes the labels regardless of the 3-year window.

3.5 Authentication and identity records

What it is: account identifiers, sign-in history, MFA enrollment state. Most of this data lives in Clerk (our identity provider) rather than in SendTax-controlled databases.

Retention: Governed by Clerk's data-handling terms while the SendTax account is active. On account closure, the Clerk-side identity is removed via the Clerk API; the SendTax-side mirror record is soft-deleted immediately (see § 4) and hard-deleted at the expiration of the § 3.1 window.

3.6 Audit logs

What it is: server-side records of security-relevant actions — sign-in events, role changes, administrative actions, sensitive data access (see Information Security § 8).

Retention: Retained for at least 3 years. Where audit entries describe records held under a longer retention obligation (e.g., § 3.1 service data), they are retained at least as long as those records, so audit trails covering retained records always outlive them. The retention floor is an operational commitment, not a code-enforced purge; audit rows are not deleted by application code. Audit logs may be retained longer for ongoing investigations or litigation holds.

3.7 Incident response records

What it is: declared security incidents and their append-only update timelines, as described in our Incident Response Policy.

Retention: Retained indefinitely. The audit value of a complete incident history outweighs the storage cost, and customers benefited from past notifications should always be able to see the public record of what happened.

3.8 Operational telemetry

What it is: error reports (Sentry), application performance metrics, request logs.

Retention: Per the provider's default retention (Sentry, Fly.io logs). Scrubbed of known sensitive fields before transmission. Generally 90 days for application logs and Sentry events, unless a longer retention is operationally necessary for a specific debugging investigation.

3.9 Customer support communications

What it is: support emails and in-product feedback messages.

Retention: 3 years.

3.10 Billing records

What it is: invoices, payment records, and tax records associated with SendTax's own business operations.

Retention: 7 years, consistent with SendTax's own tax-compliance obligations.

3.11 Marketing and website analytics

What it is: non-identifying website analytics (e.g., Google Analytics 4 page views).

Retention: 14 months, matching the Google Analytics 4 default.

3.12 Backups

What it is: point-in-time database snapshots produced by Fly.io Managed Postgres, and R2 object durability.

Retention: Per the managed-service plan's published retention window. Backups inherit any retention obligation of the underlying record, but because they are point-in-time and not per-record, we do not selectively expunge an individual customer's data from historical backups. Backups age out of the retention window on the provider's schedule. See § 7 for the practical implications of backup persistence on customer deletion requests.

---

4. The deletion lifecycle

When a customer deletes their SendTax account, deletion happens in two stages.

4.1 Stage 1 — Immediate (soft delete)

On receipt of the user.deleted event from Clerk (which fires when a customer deletes their account from Clerk's hosted account UI), or on equivalent customer-initiated action:

• The Clerk-side identity is removed by Clerk.
• The SendTax-side User or Filer mirror record is marked is_active = False.
• All active sessions for the principal are revoked.
• Existing firm-to-filer links are moved to the ENDED state.
• The account becomes inaccessible to its former owner.

At this point the customer's data is no longer visible or usable in the product. The retention period for any records subject to a legal obligation (e.g., IRS-mandated e-file records) continues to run.

4.2 Stage 2 — Permanent (hard delete)

After the applicable retention period elapses:

• Tax-return data and supporting documents that are no longer subject to a legal retention obligation are hard-deleted.
• The R2 storage objects for those documents are deleted.
• The wrapped DEKs for those documents are removed along with their database rows, rendering the document ciphertext unrecoverable from SendTax systems (see § 8).
• Audit-log entries describing those records are retained for the separate audit-log retention window (see § 3.6), but reference only opaque identifiers, not the contents of the documents.

The automated sweep that performs Stage 2 is implemented and runs daily on the worker schedule. It currently operates in dry-run mode — logging the accounts, documents, and identity records it would purge, with a queryable audit row per candidate — pending production enablement of its retention flags (RETENTION_HARD_DELETE_ENABLED, RETENTION_DOCUMENT_PURGE_ENABLED, IDENTITY_DOCUMENT_PURGE_ENABLED). Customer-requested deletions are honored on the § 5 timelines regardless of the sweep's mode. (Roadmap)

4.3 Individual document deletion

Filers can delete individual documents from their account at any time. When a filer deletes a document:

• The document's database row is removed, which removes the wrapped DEK stored on that row.
• The corresponding object in Cloudflare R2 is deleted.
• The action is recorded in the audit log.
• Because the wrapped DEK is unique to the document and is removed along with the row, the underlying ciphertext is rendered unrecoverable from SendTax systems, independent of when R2 finishes propagating the object deletion (see § 8 and Encryption Policy § 8.5).

4.4 Cascade behavior

When a database record that owns dependent records is deleted, SQLAlchemy cascade rules ensure dependent rows are deleted with the parent. This applies to relationships including User → Filer, Filer → Document, and User → External Identity. Cascading deletion is the standard data-integrity behavior; it does not by itself constitute disposal under this policy unless the parent record is itself being disposed of.

---

5. Customer rights

SendTax honors the data-subject rights described in our Privacy Policy:

These rights apply to all customers. Customers in jurisdictions with specific statutory data-subject rights (GDPR, UK GDPR, CCPA / CPRA, VCDPA, CPA, CTDPA, UCPA, and other comparable laws) may have additional rights described in the Privacy Policy; we honor those on the timelines those statutes require.

5.1 Limits

Some deletion requests cannot be honored in full while a legal obligation applies. Where that is the case, we:

1. Acknowledge the request within the statutory timeline.
2. Identify the specific records covered by the obligation.
3. Identify the specific statute and the date the obligation expires.
4. Honor deletion of any records not covered by the obligation.
5. Automatically complete deletion of the held-back records when the obligation lapses.

---

6. Verification of deletion requests

To prevent unauthorized erasure, we require deletion requests to be verifiable. Standard verification methods:

• A request sent from the email address associated with the SendTax account.
• A request made while signed in to the SendTax product.
• For requests received through other channels, a brief challenge-response confirming control of the account's contact details.

We do not require government-issued identification for routine deletion requests, in keeping with data-minimization principles. We may require additional verification for requests touching IRS-mandated records or unusually large data exports.

---

7. Backups

Customer data deleted from SendTax production systems may persist in Fly.io Managed Postgres backups until those backups are naturally aged out per the managed service's retention schedule. We do not selectively edit or scrub backups, as this is operationally infeasible and not industry-standard practice.

The practical implication: when a customer deletes their data, the data is removed from active systems immediately, but a copy may exist in backup storage for the duration of Fly.io's backup window. After the backup ages out, no recoverable copy exists on SendTax-controlled systems. Cloudflare R2 object deletion takes effect according to R2's published behavior; we do not maintain a separate backup of R2 objects, so document deletion in the application deletes the R2 object directly.

---

8. Disposal methods

SendTax uses the following disposal methods, applied as appropriate to the data category:

• Database row deletion. A DELETE statement removes the row and any cascaded child rows. Used for hard-deletion of customer data, account records (post-grace), and other structured records.
• Per-document DEK invalidation through row deletion. When a document database row is deleted, the wrapped DEK stored on that row is destroyed with it. Because each document has a unique DEK that exists nowhere else, this renders the document's ciphertext unrecoverable from SendTax systems, regardless of whether the underlying R2 object has been fully propagated. We do not currently destroy Key Encryption Key (KEK) versions in Google Cloud KMS as a routine disposal mechanism, since per-document DEK uniqueness makes this unnecessary for document-level deletion; KMS key-version destruction remains available for bulk-deletion scenarios (for example, mass tenant offboarding). See Encryption Policy § 8.5.
• Object storage deletion. R2 objects are deleted via the R2 API. The cryptographic protection above provides defense against any propagation lag.
• Soft-delete flagging. Records that need a grace period (e.g., user accounts) are flagged inactive in the database while retaining the underlying data, until the grace period passes and the record is eligible for hard-deletion.
• Provider-side aging. For data held by sub-processors (Clerk auth logs, Resend email records, Sentry telemetry, Fly.io backups), disposal occurs per the provider's published retention behavior.

---

9. Automated retention enforcement

Retention is enforced by code, not by memory. SendTax operates the following automated mechanisms; those marked dry-run are built and on the daily schedule but gated off pending production enablement.

Every purge run logs structured events recording what was deleted and how many records were affected, enabling after-the-fact audit. Once each dry-run mechanism is enabled in production, this policy will be revised to reflect active enforcement and the (Roadmap) markers removed.

---

10. Special situations

10.1 Litigation hold

Where SendTax receives a credible litigation hold, governmental preservation order, or comparable legal instruction, the affected records are placed on hold and exempted from automated retention sweeps for the duration of the hold. The hold is logged and reviewed at least quarterly to confirm it is still in effect. Records under legal hold are not deleted even if they have aged past their normal retention period.

10.2 Sub-processor data

Personal data that flows to a sub-processor (e.g., a document held in R2, an email sent via Resend) is governed by both this policy and the sub-processor's own retention terms. Where customer-initiated deletion at SendTax results in corresponding deletion at a sub-processor, the cascade is engineered into the integration. Sub-processor copies that age out per the provider's own schedule are out of our direct control. The current list of sub-processors is published on our Sub-processors page.

10.3 Anonymized and aggregated data

Once data has been irreversibly anonymized — meaning it can no longer be associated with a specific individual even when combined with other data we hold — it is no longer "personal data" for the purposes of this policy and may be retained indefinitely. Examples: fully de-identified statistics about product usage, model-evaluation metrics derived from training contributions, error counts.

---

11. Exceptions

Any deviation from this policy — for example, extending retention of a specific record set for an active investigation or compliance review — requires:

1. Approval from a second SendTax operator.
2. A documented justification recorded with the change.
3. A defined re-evaluation point.

Exceptions are reviewed at the next policy review and are not allowed to become permanent without explicit re-authorization.

---

12. Enforcement

Violations of this policy may result in revocation of access, termination of employment or contract, and, where applicable, civil or criminal referral.

---

13. Related policies

• Information Security — umbrella policy.
• Access Control — audit-log retention floor and customer-account deletion.
• Encryption — disposal mechanisms involving wrapped DEKs (§ 8.5).
• Incident Response — incident-record retention.
• Privacy Policy — customer-facing rights, the legal basis for processing, and the consumer-facing summary of this retention schedule.

---

14. Document control

This policy is reviewed at least semi-annually, and additionally whenever a regulatory retention obligation changes, a new data category is introduced that does not fit the categories in § 3, a retention-enforcement mechanism is added or changed, or one of the dry-run sweeps in § 9 is enabled in production. Material changes are noted in the version line at the top of this document.

---

15. Contact