Obsedia Email Retention and Deletion Policy
Version 1.1 · Last updated: 22 October 2026 · Effective from first publication
This policy explains the retention and deletion rules for Obsedia Email, provided by Genius Nutrition SRL, trading as OBSEDIA. It supplements our Privacy Policy and DPA. It distinguishes retained service information, temporary exports, restricted evidence and independently held copies.
1. Principles and instructions
Data must have an identified purpose, an authorised owner and an appropriate retention criterion. Installing the application does not authorise keeping every category forever. A merchant can request return or deletion through the supported application/Shopify functions or privacy@obsedia.ai, subject to identity verification and applicable legal obligations.
The periods below are policy limits and review rules, not a representation that every category has a built-in automatic expiry. A controlled administrative procedure may implement a period where an automatic mechanism is not available. A shorter valid instruction, applicable law or Shopify requirement takes priority. Information genuinely anonymised so that individuals are no longer identifiable falls outside personal-data retention; a hash or pseudonymous identifier is not assumed to be anonymous merely because a name was removed.
2. Retention schedule
| Information | Normal retention rule | Review, deletion or exception |
|---|---|---|
| Merchant account, installation and sender settings | While the account is active and the information is required for the service | Remove or minimise after termination and completion of valid deletion instructions. Retain only separately justified business, legal or security records. Review account necessity at least annually. |
| Connected contacts, consent evidence, product interests and customer lifecycle facts | While the merchant actively uses them for an authorised, current purpose | Review necessity at least annually. A valid erasure instruction can require earlier deletion. Loss of consent prevents marketing; it is not a basis to keep unrelated customer detail. |
| Unsubscribe, hard-bounce, complaint and deletion-prevention records | While needed to prevent prohibited sending or reimport for that merchant | Keep only identifiers, state and evidence necessary for that protection. Review at least annually and at account closure; remove when the purpose or legal need ends. Do not reactivate a recipient by expiry or import alone. |
| Campaign drafts, revisions, templates, chat and media | While the merchant uses or retains the relevant creative workspace | Review inactive material at least annually. Remove under a valid instruction or account cleanup. A saved template is not a reason to retain an unrelated recipient list. |
| Detailed delivery, open, click, attribution and completed automation history | Up to 24 months from the relevant event for merchant reporting and lifecycle support | Delete or minimise earlier when instructed or no longer needed. Longer retention requires a specific documented instruction or applicable legal basis and a review date. Aggregated anonymous statistics may remain. |
| Authenticated application API access records | Up to 12 months after a completed access event | Keep unresolved security, integrity or dispute records only under a scoped, reviewed hold. Operational workers and privileged infrastructure access require their own records; this row is not a claim that the merchant API journal covers them. |
| Ordinary support correspondence | Up to 24 months after the matter closes | Retain a smaller necessary record longer only for a documented legal, security or contractual reason. Do not retain attached customer datasets merely because a support ticket exists. |
| Security-incident investigation records | Up to three years after closure | Minimise content; longer periods require a legal obligation or concrete claim/hold. Review active cases and holds at least monthly. |
| Private customer privacy exports | Seven days from creation | Exports are available only through authorised access while valid; expired exports are removed by the privacy processing path. A recipient's downloaded copy is outside this expiry mechanism. |
| Completed privacy-request receipts | Thirty days after completion for residual deduplication receipts | Identifying fields and the request payload are removed at completion. A receipt expiry is separate from the retention of narrowly needed deletion-prevention hashes. |
| Unfinished privacy, delivery, upload or usage reconciliation records | Only while necessary to resolve the identified outcome or justified hold | Block affected activity as appropriate. Assign an owner, keep the minimum evidence, review at least monthly and escalate when a legal response deadline is at risk. No blanket indefinite hold is permitted. |
| Financial, tax, approved purchase and adjustment evidence | The period required for the applicable record category and law, or a longer documented dispute/legal hold | Romanian mandatory accounting registers and supporting accounting documents are generally retained for five years calculated from 1 July of the year following the relevant financial year; some financial statements/reporting categories have a ten-year statutory period. Separate required accounting evidence from reusable customer marketing data. Do not apply these periods to an entire contact database. Communicate applicable restrictions when responding to a request. |
| Infrastructure, provider and backup records | Applicable documented provider schedule and any lawful, purpose-specific recovery or preservation requirement | See Section 5. Service deletion does not promise immediate physical removal from every provider log, recipient mailbox or backup. |
These limits govern the service from this policy's effective date. We must assess and bring older retained records within the same rules rather than representing historical records as already purged.
3. Unsubscribe, uninstall and erasure are different
Unsubscribe updates a contact's future marketing eligibility. It does not cancel a purchase or erase every legal or operational record. We may retain minimal suppression evidence to honour the choice.
Uninstall disconnects the verified installation and stops new authorised store activity. A message or AI operation already accepted by an external provider may still complete. Uninstall is not a refund request and does not prove that every stored record has been removed.
Customer erasure removes or minimises the matching person's application records according to the verified request and its proper scope. The workflow respects native customer identity so that a recycled email address or delayed request does not erase a different person's information. A privacy request concerning an order is applied to the relevant customer/order scope.
Store erasure uses the verified Shopify shop-redaction request or another appropriately verified deletion instruction. The application checks installation identity, reinstallations and outstanding work before removing the tenant's origin media and tenant-owned records. An ambiguous old request must be reconciled before it is applied to a new installation.
The service processes lawful erasure instructions without undue delay and subject to applicable deadlines. Our normal handling objective is to complete ordinary verified requests within 30 days of receipt; this is an operating objective, not an additional exemption from a shorter legal or Shopify requirement. If scope, identity, law or an unresolved outcome affects completion, we must communicate the reason and next steps instead of describing a pending request as complete.
4. Lawful holds and incomplete outcomes
A hold must identify the information involved, reason, authority, responsible person, start date, review date and release condition. Examples include a legally required preservation, a genuine dispute, an unconfirmed provider submission or incomplete financial reconciliation. A commercial balance or pending adjustment does not justify unrestricted retention of unrelated personal data.
Where technically appropriate, activity is suppressed or blocked while evidence is reconciled. No automatic resend, credit release or deletion of necessary outcome evidence may bypass the uncertainty safeguards. Operators must use the supported reconciliation process and escalate any potential conflict with a privacy deadline. On release, complete the outstanding deletion or minimisation and record the result.
5. Backups, restored data and external copies
Backups are restricted recovery copies, not ordinary campaign audiences. Automated backup schedules, exceptional manual snapshots, archive/PITR data and object-storage copies can have different lifecycles. A daily or weekly backup label does not establish the expiry of a manual copy. Manual preservation requires a defined purpose and monthly review; it must end when that purpose and any applicable obligation end.
During any unavoidable backup retention, access must be restricted to recovery, security or a legal requirement. A restoration must be isolated and validated, and later erasure and suppression instructions must be reapplied before affected data returns to normal processing. Recovery copies must not be used to restart marketing to deleted or opted-out contacts.
Actual provider retention, encryption and disposal controls must be documented for the selected service. We do not promise that every backup is physically purged within a fixed number of days solely because an origin record was deleted. Contact privacy@obsedia.ai for the applicable schedule and any specific hold relevant to a request.
Email recipients, their email providers, external image caches and third-party linked services may retain independent copies. OBSEDIA cannot recall a delivered email or remotely erase those independently held copies. We delete origin assets and provide appropriate information or assistance within our control.
6. Requests, return and confirmation
Send a request to privacy@obsedia.ai with the merchant's Shopify domain, the action required and enough information to locate the account or subject. Do not include passwords, API keys, payment-card details or identity documents in an initial request. We may ask for proportionate verification.
The merchant remains responsible for its own customer records and notices. We can assist with a supported export or return before deletion; the merchant must retrieve the return within the agreed secure-access period. We will not disclose another merchant's information or an entire audience to a requester entitled only to their own data.
A deletion confirmation must state the scope completed, date, any necessary residual records/holds and the limits relating to backups or independent copies. “Request received” and “processing” are not completion confirmations. Exceptions must be explained to the extent legally permitted and reviewed when the relevant reason ends.