Last updated: 2026-10-08
Applies to all Customer Data and any third-party-sourced data (firmographic, contact PII, public records) processed by Ataski roles.
| Data class | Retention | Trigger |
|---|---|---|
| Customer Data (CRM, outreach history, drafts) | While customer subscription active + 30 days post-offboarding | Subscription end |
| Contact PII (recipient name, email, title) — per-tenant scope | Same as parent customer | Subscription end |
| Firmographic cache (non-PII, cross-tenant) | 30 days from the date the fact was last confirmed against its source; an eviction job removes expired rows | Staleness |
| External data-call log (run metadata, per-workspace) | 24 months | Time-based |
| Audit log (system-wide) | 24 months | Time-based |
| Outreach send history (per-tenant) | 24 months | Time-based |
| Discovered prospect never contacted or engaged (Outbound) — found by discovery, never emailed, never replied, not suppressed | 6 months from when it was last collected | Time-based |
| Website visit statistics (public marketing pages) — pages viewed, time on page, scroll depth, clicks, referring site, ad campaign, device type and browser language, under a hashed identifier that rotates daily; no cookies, no IP address stored | 180 days from collection; a nightly job deletes older rows | Time-based |
| Global opt-out register (a hash of the opted-out email address, which is the lookup key, and the address itself, lowercased) | The hash: indefinite (legal obligation under CAN-SPAM + CCPA — an opted-out contact must never be re-contacted, by any Ataski customer). The address itself: removed by a daily job 90 days after the opt-out is processed (see "The public opt-out form" below) | Hash: never auto-purged. Address: time-based |
| Tenant-scoped suppression data | Same as parent customer (deleted with the workspace) | Subscription end |
| Right-to-delete request log | At least 7 years (regulatory evidence) | Time-based |
| Contract extraction records (Contract Intelligence role) — extracted fields, evidence anchors, model version metadata (worker + supervisor model identifiers, internal prompt/schema/classifier versioning), and the detected personal-data category set | Same as parent customer (auto-deleted 30 days after offboarding) | Subscription end |
Outbound discovery finds business contacts for a customer's campaigns. A person it found who was never emailed and never engaged has no ongoing reason to be held, so a daily job deletes them 6 months after they were last collected (a rediscovery restarts the clock): the contact record itself, its enrichment record, any draft written for it that was never sent, and the person details on its pipeline record.
What this job never deletes, by design:
The term is defined once, in code; this document and the recipient-facing privacy notice linked from every non-US first-contact email quote that same number, and an automated test fails the build if they disagree. The job runs in bounded, individually committed batches with an explicit workspace fence on every statement, and each night's work that removed something writes one audit record (counts only, never an address) to the workspace's own audit export.
A daily job walks every active workspace and, for each audit record older than the term above, removes the personal data in place: the acting user reference is set to null and the free-form detail blob is replaced with a single marker recording when the scrub happened.
The record itself is kept. What it is about — when it happened, in which workspace, what kind of actor took what action against which internal identifier, and what it cost — is not personal data, and it is what the audit log exists for: accountability (GDPR Art.5(2)), security monitoring and spend control. Removing the personal data is what the retention term requires (Art.5(1)(e)); destroying the record is not, and the audit log is append-only by design (see the Security page).
The term is defined once, in code, and this document quotes that same number; an automated test fails the build if the two ever disagree.
The job is bounded and resumable: it works in small batches, each committed on its own, so a large first backlog is drained over consecutive nights rather than in one long-running operation. Each night's work that actually removed something writes one audit record saying how much it removed, which appears in the workspace's own audit export.
Not covered by this job: the external data-call log's 24-month term above is not yet enforced by an age-based job. Those rows are run metadata — tool name, input/output hashes, cost, latency, outcome — and carry no contact data; they are also retained (not deleted) when a workspace is offboarded (see the table below). A future revision either extends the job above to that log or corrects the term here.
Some sub-processors hold their own operational copies of data that passed through them. Where a vendor offers an interface that can delete one workspace's copies, the offboarding sweep below uses it: after the workspace's own data is deleted, the sweep asks that vendor to delete the workspace's copies too, and retries until the vendor confirms. Where no such interface exists, the copies expire on the vendor's own retention window. Per-vendor terms are linked from /legal/subprocessors:
| Vendor-side copy | Deleted at offboarding? | Otherwise expires |
|---|---|---|
| Meeting recordings and transcripts (Recall.ai) | Yes — every recording of a meeting assistant dispatched for the workspace (video, audio, transcript, chat) is deleted through the vendor's deletion interface | Per vendor's retention window |
| LLM traces — prompt and completion content (Langfuse) | Yes — every trace labelled with the workspace is deleted through the vendor's deletion interface; the vendor completes the removal shortly after the request (typically within 15 minutes). Traces recorded before workspace labelling was introduced (October 2026) carry no workspace label and cannot be singled out; they expire on the 30-day window | 30 days |
| Error-tracking data (Bugsink) | No — the vendor can only delete a whole error group, which mixes events from every workspace. Events carry no message text, request data or user details; only internal identifiers and the program's stack trace | Rolling: the oldest events are discarded once the project's event cap is reached |
| Transactional email message content (Postmark) | No — the vendor's removal interface works per recipient address and is not enabled on our account | 45 days |
| Product-analytics events (PostHog) | No | Per vendor's retention window, see /legal/subprocessors |
| LLM provider-side prompt/completion copies (Anthropic) | No — the provider offers no deletion interface | Not used for training; at most 30 days |
Each vendor deletion request, and each failed attempt, is recorded in Ataski's own audit log (the workspace's audit log has already been deleted by then), so the deletion remains provable after the workspace is gone.
The 30-day offboarding sweep (next section) deletes the customer's data. A short, closed list of record classes survives it, each with a stated legal basis. Nothing on this list contains recipient contact PII:
| Record class | What survives | Legal basis |
|---|---|---|
| Workspace tombstone | The workspace's own row, kept as proof the workspace existed and was deleted | Accountability, GDPR Art. 5(2) |
| Deletion-request records | The proof-of-erasure skeleton of each right-to-delete request; the requester's email is replaced by a hash | Accountability / proof of erasure, GDPR Art. 5(2); retained at least 7 years |
| Billing and subscription records | Plan and tier history, bundle subscriptions, usage meters, vendor-usage charges, invoice events, and subscription snapshots. Invoice events store an allow-listed projection of the payment processor's object — amounts, currencies, statuses, ids, periods, discounts, tax lines; names, emails, and addresses are dropped before storage | Tax and accounting records, GDPR Art. 17(3)(b); retained 7 years |
| Model-run and external data-call ledgers | PII-free run metadata: tool/model name, input/output hashes, cost, latency, outcome — the anonymized cost/quality ledger | Legitimate interests in cost control and service integrity; contains no personal data |
| Write-intent records | PII-free serialization evidence of the purge itself (object key, writer tag, timestamps), pruned past retention by an administrative job | Accountability for the deletion process, GDPR Art. 5(2) |
| Global opt-out register | A hash of the email address of each recipient who opted out — the lookup key checked before any email from any Ataski workspace is sent — with the reason and the source of the request. The address itself (lowercased) is kept alongside until 90 days after the opt-out is processed, then removed | Legal obligation, CAN-SPAM / CCPA; the hash is retained indefinitely, for that purpose only |
When a customer subscription is cancelled or expires:
/api/export (admin: /app/settings/export.json) for 30 days.The customer is the controller of the personal data in its workspace, so a person's request to delete that data is the customer's to verify and to submit. There are two routes, and they do different things.
The customer's deletion request (workspace data). The customer submits
the person's email address through its authenticated deletion endpoint
(/api/ccpa-delete). Verifying that the requester is the person concerned
is the customer's responsibility as controller; Ataski does not verify the
requester.
Other records in the workspace that may contain the address — for example data synced from a connected accounting system or CRM, or uploaded documents — are outside this job's scope.
The public opt-out form (/privacy/optout). Anyone can submit their
email address there, without an account. The form does not delete data
from any customer's workspace. It:
Data about the person held in a customer's workspace is deleted through that customer's deletion request (above), under the retention terms in the table at the top of this policy, or with the rest of the workspace at offboarding.
External data sources keep their own copies of what passes through them, under their own terms (each vendor's DPA is linked from /legal/subprocessors). The opt-out deletion step above reaches none of them today: - Bright Data: public-web search results and company page extractions; handled by their own GDPR/CCPA controls (vendor responsibility per their DPA) - Apify: the public LinkedIn company and people-at-company lookups run under Ataski's own Apify account, with no LinkedIn login; their results (public company records, and identity records — name, job title, employer, LinkedIn profile URL, location; no email, no phone) are stored in that account and kept under Apify's own terms (its DPA). Ataski does not delete them itself - ZeroBounce: email addresses submitted for verification, kept by ZeroBounce only as its DPA allows - Internal caches (firmographic, email-pattern shapes): purged on the tenant offboarding sweep when the last-referencing tenant is the deleted one