Data Deletion & Retention Policy
Effective 19 August 2026
Nateq is a customer-communication platform. Our customers (the “organization”) use it to talk to their own end users. In data-protection terms the organization is the controller of that conversation data and Nateq is the processor — we act on their instructions. This policy explains what gets deleted, when, how thoroughly, and what we are obliged to keep.
One distinction matters throughout: for the organization’s own account, user, and billing data, Nateq is the controller and decides directly. For the conversation data the organization holds about its end users, Nateq is the processor and acts only on instruction. Where the two are treated differently below, it is for this reason.
The three ways data is deleted
Deleting an individual person’s data
An organization can permanently erase a single contact — the person they were talking to — along with everything derived from them. This is how a GDPR Article 17 (“right to be forgotten”) or CCPA deletion request is serviced. It is initiated by the organization, because they are the controller; Nateq executes it.
Closing a workspace
An organization owner can delete their entire workspace and all data in it. This begins a 30-day grace period during which it can be cancelled. After that window it is executed and cannot be undone.
Automatic retention limits
An organization can configure how long conversations, tickets, call recordings, and dormant contact records are kept. Anything older than the configured window is deleted automatically. This is optional and off unless the organization turns it on.
Deletion is permanent, not a hidden flag
When data is deleted under this policy it is removed, not marked as hidden. There is no “deleted” flag leaving the underlying record readable in our systems.
Deletion is not limited to our primary database. A single erasure removes the data from every place we hold a copy:
| Where | What is removed |
|---|---|
| Primary database | Contact record, conversations, messages, tickets, notes, and every derived record |
| File storage | Uploaded files, attachments, avatars, call recordings, and raw inbound email — the stored objects themselves, not merely the references |
| Search index | Every indexed copy of the contact and their message content |
| AI memory store | Conversation context retained to give the AI assistant continuity |
| Caches and sessions | Session records, cached conversation data, widget identifiers |
Each of these is verified individually, and the deletion is only recorded as complete when every one of them has confirmed success. If any single store fails, the request is marked partially completed and retried — it is never silently reported as done.
Timing
| Action | When it happens |
|---|---|
| Individual data deletion | Begins immediately; completed within 30 days at the latest |
| Workspace deletion | 30-day cancellable grace period, then executed |
| Automatic retention deletion | Runs continuously against the organization’s configured windows |
| Residual copies in backups | Age out within 35 days — see Backups below |
What we keep, and why
Deletion is thorough but not unlimited. The following are retained because the law requires it or because deleting them would destroy the evidence that the deletion happened. Nothing outside this list survives an erasure.
Invoices, payments, and tax records
Retained for seven years, the period required by US federal and Wyoming state accounting and tax law. These are records of the organization’s commercial relationship with us — deleting an individual person’s data never touches billing. When a workspace is closed, its invoices are detached from the workspace and kept in a billing archive.
The deletion record itself
We keep a record that a deletion was requested and carried out, because accountability rules require us to be able to demonstrate compliance. This record does not contain the deleted person’s details — the subject is referenced only by a one-way cryptographic hash, so the record can prove an erasure happened without reproducing the data it erased.
Aggregate statistics
Counts and metrics (how many conversations were handled in a given month, for example) are preserved in a de-identified form so an organization’s historical reporting does not silently change. These contain no identifiers of any kind — not a name, not an email, not even the hash above.
Security and operational logs
Records of administrative and security-relevant events — sign-ins to a workspace, API key use, billing changes — are kept for 12 months to support security investigation and fraud prevention. These concern the organization’s own staff accounts, not the end users they converse with: erasing an individual person’s data does not touch them. They are deleted on the same schedule when a workspace is closed.
Data under legal hold
If data is subject to an active legal obligation to preserve it — litigation, a regulatory investigation — deletion is blocked until that obligation lifts. The requester is told the request was refused and why. It is never silently ignored or quietly dropped.
Backups
Backups are the one place we cannot surgically edit. Restoring, altering, and re-securing a historical snapshot to remove one record would put the integrity of every other customer’s data at risk.
Instead: backups are encrypted, are not accessible to the running application, and are restored only in a disaster-recovery scenario. Deleted data ages out of the backup rotation within 35 days, after which no copy remains. In practice it is usually sooner; 35 days is the outer limit we commit to rather than an average.
We state this plainly rather than claiming an instantaneous deletion everywhere, because the latter would not be true of any system that keeps backups.
How securely data is deleted
Records are permanently removed from all live systems at the moment of deletion.
In addition, message and email content is encrypted at rest under an encryption key unique to each individual, which is itself sealed under a master key held outside the database. When that person’s data is deleted, their key is destroyed. In our live systems the content becomes unreadable at that moment, independently of the record removal above, and a copy of our database obtained without the master key yields nothing.
This does not, on its own, reach backups. The per-person keys are stored in the same database that holds the content, so a backup snapshot taken before an erasure contains both, and the erasure cannot reach into that snapshot to destroy the key. Backups therefore remain governed by the section above: the residual copy ages out within 35 days, and that — not the key destruction — is the commitment we make about backups.
We draw this distinction rather than claiming key destruction erases backups instantly, which is a common description of this technique but would not be true of our current architecture.
Third parties that process data
Delivering messages means other companies handle some of that data. Where a provider offers a way to delete data on request, we use it. Where one does not, we say so here rather than implying a deletion we cannot perform.
| Provider | Purpose | Deletion |
|---|---|---|
| Object storage (AWS S3) | Files, attachments, recordings | Deleted on request |
| Search index (Typesense) | Making conversations searchable | Deleted on request |
| AI memory store | Conversation continuity for the AI assistant | Deleted on request |
| Meta / WhatsApp | Delivering WhatsApp messages | Meta retains message history on its own systems under its own policy. No mechanism is available to us to erase it on request. |
| Postmark | Sending and receiving email | Retains copies of sent and received mail under its own retention policy. Per-message deletion is not available to us. |
| Google (Gemini) | AI assistant responses | Used under paid API terms: content is not used to train Google’s models and no copy is retained on our behalf. Google may hold content briefly for its own abuse monitoring. |
| Slack | Optional notifications to a customer’s own Slack | Messages delivered into a customer’s own Slack workspace are under that customer’s control, not ours. |
| LiveKit | Voice calls | Handles call connections. Recordings, where made, are stored in our own file storage and deleted with everything else. |
If a provider is added, this table is updated before it processes any data.
How to request deletion
If you are an end user
— someone who contacted a business that uses Nateq — your request goes to that business, not to us. They decide and instruct us; we carry it out. We cannot delete their records on our own initiative, and contacting us directly will only result in us referring you to them. If you do not know who they are, contact us at legal@nateq.io and we will help you identify the right organization.
If you are a Nateq customer
You can:
- delete an individual contact from the contact detail screen;
- configure automatic retention limits in Settings → Data & Privacy;
- close your workspace entirely from the same screen (owner only).
Deleting an individual person’s data and closing a workspace are irreversible. Both require re-entering your password at the moment you perform them, and both ask you to type the name of what you are deleting. This is deliberate friction: these actions cannot be undone.
Proof of deletion
Every completed deletion produces a downloadable certificate recording what was deleted, when, from which systems, and where a third party’s own retention still applies. It identifies the person only by the one-way hash described above, so it can be handed to an auditor or regulator without re-exposing the data it certifies as erased.
Contact
Questions about this policy, or about a specific deletion request:
NATEQ LLC
Wyoming, United States
Privacy / data protection contact: legal@nateq.io
We update this policy when what we actually do changes. Material changes are communicated to customers before they take effect.