Data Retention Policy & Schedule

SellerSlice LLC — Mission Control

📌 TL;DR — The plain-language version

We are SellerSlice LLC, a Washington State company. Mission Control is our B2B software for Amazon-seller agencies and their clients. We keep data only as long as we have a real reason to, and then we delete it. Here's the short version:

• Your Amazon data is special, and we treat it that way. We use no Restricted SP-API roles, so we hold no buyer names, addresses, emails, or phone numbers. When you disconnect your Amazon account, get offboarded, or close your account, we permanently delete the connection and all the Amazon data we pulled in — within 30 days. We do not "anonymize" it and keep it. Deletion means destroyed, for good.
• We never pool your Amazon data with another client's, ever — not for benchmarking, not aggregated, not de-identified. Your numbers serve you and only you.
• Your own account, billing, and portal data sticks around while you're a customer, then gets cleaned up after you leave — except records we're legally required to keep (taxes, consent proof, security logs, breach records).
• Security and audit logs are kept for at least 12 months, even after you disconnect — Amazon requires this, so it's an explicit exception to our 30-day deletion promise.
• AI prompts are transient — we don't store them to train models, and we contractually forbid our AI vendors from training on your data.
• You can ask us to delete your personal data any time. We honor it within 30 days (some US states allow 45). Use our Data Request form or email privacy@sellerslice.com.

The full schedule, every category, and the jurisdiction-by-jurisdiction detail are below.

Table of Contents

1. Purpose & Scope
2. Our Core Retention Principles
3. The Master Retention Schedule
4. Amazon Information — The Special Rules
5. Two Ledgers: How We Separate Amazon Data From Our Own Operational Data
6. Deletion, De-authorization & How Purges Actually Run
7. AI Inputs & Outputs
8. Consent, Acceptance & Proof Records
9. Breach & Incident Records
10. The Shared Legacy Database
11. Your Rights & How to Exercise Them
12. Jurisdiction-Specific Retention & Deletion Rules
13. Legally-Required Retention Overrides
14. Definitions
15. Changes to This Policy & Changelog
16. Contact

1. Purpose & Scope

1.1 This Data Retention Policy & Schedule explains, for each category of data Mission Control ("the Service") processes, (a) how long we keep it, (b) the criteria we use to decide that period where a fixed number isn't possible, and (c) the event that triggers deletion. It implements the retention commitments stated in our Privacy Policy §5 and §11, and the two cannot drift — where this schedule and the Privacy Policy describe the same category, they are written to say the same thing.

1.2 This policy covers all personal data and business data processed by SellerSlice LLC through Mission Control, including:

• data about our own users (employees and client-portal users);
• billing and subscription data;
• client-portal content (tasks, meetings, brand plans, reports, P&L, copywriting, shipments, promotions);
• Amazon Information sourced via the Amazon Selling Partner API (SP-API) and Amazon Advertising API;
• security and audit logs;
• consent and acceptance proof records; and
• transient AI inputs.

1.3 This policy applies in every jurisdiction in which we operate at launch: the United States (including California's CCPA/CPRA, and Virginia, Colorado, Connecticut, Texas, and other state privacy laws), the United Kingdom, the European Union, Canada (including Quebec's Law 25), Mexico (LFPDPPP), and Australia (Privacy Act 1988 (Cth) and the Australian Privacy Principles). Jurisdiction-specific overlays are in §12.

1.4 Mission Control is B2B only and 18+ only. We do not knowingly process the personal data of minors.

2. Our Core Retention Principles

2.1 Storage limitation. We keep personal data only for as long as necessary for the purposes for which it was collected, consistent with GDPR Art. 5(1)(e), UK GDPR, and the data-minimization expectations of CCPA/CPRA, PIPEDA, Quebec Law 25, the LFPDPPP, and the Australian Privacy Principles (APP 11.2).

2.2 Purpose-bound. When a purpose ends — your subscription terminates, you disconnect an integration, a legal hold lifts — the clock for deleting the associated data starts.

2.3 Amazon Information is contract-restricted, not just privacy-restricted. Amazon's Data Protection Policy ("DPP"), Acceptable Use Policy ("AUP"), and Solution Provider Agreement ("SPA") govern all data exposed through the Amazon APIs — catalog, orders, sales, settlement, financials, ad metrics, ASINs — whether or not it is "personal." These contracts impose duties (delete-on-de-authorization, a destruction standard, a cross-seller use bar) that bite at every API role tier, independent of any privacy law. See §4.

2.4 Deletion means destruction. When we say we delete data, we mean a real, irreversible delete aligned with NIST SP 800-88 media-sanitization guidance — not orphaning records, not removing pointers, and (for Amazon Information) not "anonymizing." Per the Amazon DPP, "data anonymization is not considered an acceptable method for Amazon information deletion."

2.5 No cross-client use of Amazon data. Amazon Information for one client is never aggregated across clients, never used for cross-client benchmarking, and never disclosed to another client — including in aggregated or de-identified form (AUP §4.4, §4.6; SPA §D-7.1, §D-7.5).

2.6 Legally-required retention overrides deletion — but only for the specific record. Where law or a binding contract requires us to retain a record longer than the period below (e.g., tax records, the Amazon ≥12-month security-log floor, consent and breach proof), the legal requirement controls for that record only, we restrict access to it, and it is carved out of the 30-day de-authorization and erasure cascades. This carve-out is narrow and record-specific; it is never a license to retain anything else. See §13.

3. The Master Retention Schedule

The following table is the authoritative per-category schedule. Periods and triggers are re-verified against the source regulation and the Amazon DPP/AUP/SPA noted in each row. The 30-day deletion triggers below are always subject to the legally-required retention overrides in §13 (tax, security-log floor, consent/breach proof), which are carved out of the deletion cascade.

4. Amazon Information — The Special Rules

This section is the heart of this policy. Amazon Information is governed by Amazon's Data Protection Policy, Acceptable Use Policy, and Solution Provider Agreement (text effective 25 November 2025). These obligations are independent of, and additional to, every privacy law.

4.1 No buyer PII. Mission Control uses no Restricted SP-API roles. As a result, we hold no buyer personally identifiable information — no buyer name, address, email, or phone number. The 30-day buyer-PII purge in row 5 is therefore moot in practice, but we state it for completeness and will re-attach the full PII regime the instant any order, financial, or settlement table is found to hold buyer PII.

4.2 Delete-only on de-authorization. On any de-authorization, disconnection, or account closure, all Amazon Information for that (client, region) — including the encrypted refresh-token/credential row and all ingested catalog, orders, sales, settlement, financial, ad-metric, ASIN, and Data Kiosk data — is destroyed within 30 days (Amazon DPP §1.7), except the ≥12-month security/audit-log floor in row 6, which is carved out per §13 to satisfy Amazon's own log-retention requirement. Deletion is a real, NIST SP 800-88-aligned delete. "Removing pointers to Amazon S3 objects and orphaning data in the service account are not acceptable delete actions."

4.3 "Anonymize" is not deletion — and is not an option here. Amazon states verbatim that "data anonymization is not considered an acceptable method for Amazon information deletion" (DPP). Mission Control therefore deletes Amazon Information on de-authorization. We do not anonymize-and-retain it. (An anonymized-retention carve-out exists in our Privacy Policy only for non-Amazon business records.)

4.4 Used solely for the authorizing client. Amazon Information is used solely to support that Authorized User's own business with Amazon (AUP §4.4/§4.6; SPA §D-7.1/§D-7.5). It is never aggregated across clients, never used for cross-client benchmarking, and never disclosed to any other client — including aggregated or de-identified. The controlling test is purpose/beneficiary, not identifiability, so de-identification does not cure a cross-client use.

4.5 Per-client performance metrics while authorized. We do retain per-client listing-performance metrics (including before/after change-impact analysis) while that client's authorization is active, solely for that client. These purge on de-authorization with the rest of Amazon Information (row 4).

4.6 12-month log floor & 24-hour incident clock. Security and audit logs covering Amazon Information are retained for ≥ 12 months (DPP §2.6). This floor is an explicit exception to the 30-day de-authorization and erasure cascades (§13) — we do not purge a de-authorized client's security/audit logs at 30 days, because doing so would breach the DPP. Any security incident affecting Amazon Information is reported to security@amazon.com within 24 hours of detection (DPP §1.6). We maintain a named Amazon security point of contact (IMPOC), reachable via privacy@sellerslice.com.

5. Two Ledgers: How We Separate Amazon Data From Our Own Operational Data

To keep Amazon's contract rules airtight, Mission Control architecturally separates two kinds of data and never blends them. Note that the "Ledger A / Ledger B" distinction is about Amazon-data containment only — it does not describe client-portal content or AI outputs, which are ordinary Customer Data governed by the §3 contract-term retention (rows 2, 3, 11).

5.1 A metric that counts our own events is Ledger A and is freely retainable. A metric whose value is computed from Amazon-sourced figures is Ledger B and inherits the §4 rules — it is not "free operational data" merely because it lives in a project-metrics table.

5.2 We enforce this with separate tables/columns and an automated check that a Ledger-A metric may never read a Ledger-B column. On a client's de-authorization, any internal aggregate that drew on that client's Ledger-B figures is recomputed to strip their contribution — we do not freeze a de-authorized seller's Amazon-derived values inside a stored aggregate.

6. Deletion, De-authorization & How Purges Actually Run

6.1 The 30-day clock. Whether the trigger is a delete-on-request, an Amazon de-authorization, an integration disconnect, or account closure, the deletion completes within 30 days and is permanent — subject only to the legally-required retention overrides in §13 (tax records, the Amazon ≥12-month security/audit-log floor, and consent/breach proof), which are carved out of the cascade and access-restricted.

6.2 What runs on de-authorization. Revoking a Seller or Ads connection (and the offboarding lifecycle) triggers: (a) hard-deletion (or NULL-then-delete) of the encrypted credential row, and (b) a cascade purge of all ingested Amazon Information for that (client, region) — orders, settlement/financial data, ad metrics, catalog, ASIN data, and Data Kiosk outputs. Security/audit logs are excluded from this purge and retained per the §13 / row-6 floor.

6.3 Soft-delete & offboarding lifecycle. Account-level contact and branding data follow the client soft-delete/purge lifecycle; the offboarding workflow coordinates final data disposition and the Amazon-data cascade together.

6.4 CSV cleanup. Redundant CSV-sourced rows that have been superseded by API data are auto-deleted as part of routine data hygiene.

7. AI Inputs & Outputs

7.1 Mission Control uses four AI vendors/layers: Anthropic (copy generation/research), OpenAI (scoring/embeddings), xAI/Grok (web/X search for the internal Morning Review/News feature only — not client-data processing), and the Vercel AI Gateway (inference routing layer). See the Sub-processors page and the AI Disclosure.

7.2 Inputs are transient. Prompts are processed for the request and are not retained by us to train, fine-tune, or improve any model. We do not use Customer Data or Amazon-sourced data to train, fine-tune, or improve any third-party model, and this prohibition is contractually flowed down to our AI sub-processors.

7.3 Vendor retention tiers. Vendor-side input retention is governed by no-training / zero-or-short-retention tiers.

7.4 Outputs. AI outputs that become client-portal content (generated copy, MR scores, report text) are retained as ordinary Customer Data / client-portal content (§3, rows 2/3/11) — not as Ledger A — and purge within 30 days of offboarding. AI features are advisory/decision-support — a human reviews output before any account action — so no legally-significant automated decision is made by AI on its own (GDPR Art. 22).

8. Consent, Acceptance & Proof Records

8.1 Cookie/consent proof. We retain consent proof records (banner/policy version, categories granted/refused, GPC-override choices, timestamp, mechanism, IP/UA, withdrawal events) for ≥ 24 months. We re-prompt for cookie consent every 6 months, and immediately on a material policy-version change — but the re-prompt does not delete prior proof.

8.2 Subscription & terms-acceptance proof. Terms- and auto-renewal-acceptance proof (version strings, timestamp, user, IP/UA) is retained for 3 years, or 1 year after termination, whichever is longer, aligned to the CA ARL.

8.3 The consent log is excluded from erasure. Because the consent/proof log is the very evidence we are legally obligated to keep to demonstrate consent (GDPR Art. 6(1)(c) / Art. 7(1)), it is held on its own lawful basis and is excluded from the general erasure cascade. An erasure request does not destroy the proof we are required to retain; we retain the minimum proof record and erase the rest. (Breach/incident records are likewise excluded from erasure, but on a different legal-obligation basis — see §9 and §13 — not under this §8.3 consent rationale.)

9. Breach & Incident Records

We maintain incident records (including risk assessments and actions taken) to satisfy parallel obligations across jurisdictions, on a legal-obligation basis that is independent of the §8.3 consent-proof rationale:

• Canada (PIPEDA): record of every breach kept for ≥ 24 months (s 10.1 / SOR/2018-64).
• Quebec (Law 25 s 3.8): a mandatory register of all confidentiality incidents, any severity, maintained on an ongoing basis.

Because these records sit on a statutory record-keeping obligation, they are retained outside the 30-day erasure/de-auth cascade (§13), independent of the consent-log exclusion in §8.3.

Our breach-notification clocks are documented separately in the Privacy Policy and DPA (six distinct clocks: Amazon 24h; GDPR/UK Art. 33 72h to supervisory authority; processor→controller without undue delay; Australia NDB 30-day assessment then ASAP to the OAIC and individuals; Mexico de forma inmediata to titulares; Canada OPC + Quebec CAI in parallel). Do not conflate the Amazon 24-hour clock with the GDPR 72-hour clock.

10. The Shared Legacy Database

Mission Control shares a database with the legacy ARCProgramPointSystem platform. Deletion cascades must propagate across the shared schema, not just the Mission Control tables. Before any deletion period in this document is relied upon as a promise, engineering verifies that legacy triggers, functions, views, and RLS policies on the affected tables do not silently retain data that this schedule says is deleted.

11. Your Rights & How to Exercise Them

11.1 You can ask us to access, correct, delete, or port your personal data, and to object to or restrict certain processing. We honor verified requests within 30 days (up to 45 days for certain US states; jurisdiction-specific timers in §12).

11.2 How to ask. Submit our Data Request form or email privacy@sellerslice.com. We offer at least two submission methods, support authorized agents, verify identity, and provide an internal appeal path if we deny a request. No account creation is required to make a request.

11.3 We do not sell or share your personal information (as "sell" and "share" are defined under CCPA/CPRA), and we honor the Global Privacy Control (GPC). In this product, a GPC signal (GPC=1) does more than bind sale/share and targeted-advertising opt-outs: it also defaults the Analytics cookie category OFF. You may affirmatively re-enable analytics, and that choice is recorded as overriding the GPC default for analytics only (sale/share/targeted-ads remain suppressed) — the override is itself written to the consent-proof log (§8.1 / Row 9). See the Cookie Policy for the full mechanism and the Privacy Policy.

11.4 Deletion and Amazon data. A deletion request triggers the same delete-only cascade described in §6 — including the encrypted credential row and all ingested Amazon Information — subject only to the legal-hold/legally-required overrides in §13 (including the ≥12-month security/audit-log floor) and the consent-proof exclusion in §8.3.

12. Jurisdiction-Specific Retention & Deletion Rules

The master schedule (§3) applies everywhere. The following overlays add jurisdiction-specific timers and obligations.

12.1 United States (CCPA/CPRA + VA/CO/CT/TX and other state laws)

• Per-category retention disclosed above satisfies CPRA's retention-disclosure requirement.
• Rights-request response within 30 days, extendable to 45 days where the applicable state law permits (e.g., the CCPA's additional 45-day period with notice to the consumer). We do not promise a flat 90-day window; any further extension is taken only where a specific statute expressly authorizes it.
• California uniquely covers B2B contacts and employees — their data follows the same schedule.
• Subscription-consent proof retained per the CA ARL (§8.2).

12.2 United Kingdom & European Union (UK GDPR / EU GDPR)

• Storage limitation (Art. 5(1)(e)); per-category periods above are the retention disclosure under Art. 13(2)(a).
• Erasure (Art. 17) honored within 30 days, subject to §8.3, §9, and §13.
• EU Art. 27 representative and UK representative: contact details are published in the Privacy Policy §16 once appointed.

12.3 Canada — PIPEDA + Quebec Law 25

• Breach records: ≥ 24 months (PIPEDA s 10.1 / SOR/2018-64); Quebec confidentiality-incident register maintained on an ongoing basis (s 3.8). These sit outside the erasure cascade per §9/§13.
• Quebec portability (in force Sept 2024), de-indexing/erasure (art 28.1), and automated-decision contestation (art 12.1) are surfaced in the Privacy Policy.
• Quebec s 17 cross-border transfer: before any Quebec-client PI reaches the US stack, a Privacy Impact Assessment + written agreement must exist; new US sub-processors trigger a fresh PIA (s 3.3).
• Quebec Law 25 s 3.1 Person in charge of the protection of personal information (privacy officer): Jordache Perozzo, President (privacy@sellerslice.com).

12.4 Mexico — LFPDPPP

• ARCO request timers differ from elsewhere: respond within 20 business days; implement granted requests within 15 business days (not the 30 calendar days used elsewhere).
• A Spanish-language Aviso de Privacidad separates necesarias from voluntarias purposes; transfers to US sub-processors and AI vendors are disclosed with accept/reject.
• A new purpose triggers fresh consent before Mexican-client data is used for it.
• Named internal privacy contact / Departamento de Datos Personales: privacy@sellerslice.com.

12.5 Australia — Privacy Act 1988 (Cth) + APPs

• APP 11.2 retention limitation: the §6 delete-on-disconnect cascade is the mechanism that satisfies our APP 11.2 commitment for AU individuals; the historical revoke-only behavior would have breached it.
• NDB scheme: suspicion of an eligible breach triggers a 30-day assessment, then notification to the OAIC and affected individuals as soon as practicable.
• Overseas-disclosure transparency (APP 5 / APP 1.4(f) / APP 8) naming the United States as the likely recipient country is in the Privacy Policy; APP 8.1 "reasonable steps" rest on DPAs binding each US sub-processor (we do not disclaim s 16C liability).
• Automated-decision-making disclosure obligations apply by 10 December 2026 for any qualifying AI feature.

13. Legally-Required Retention Overrides

Where a law or binding contract requires us to keep a record longer than the schedule in §3, the legal requirement controls for that specific record, access to it is restricted, and that record is carved out of the 30-day de-authorization and erasure cascades so the deletion promises in §4, §6, and §11 are not contradicted. The carve-out is narrow and record-specific. Examples:

• Security & audit logs — ≥ 12 months (row 6; Amazon DPP §2.6). This is a floor and an explicit exception to the 30-day de-auth/erasure cascade: a de-authorized client's Amazon-activity logs are retained to the floor even though the underlying Amazon Information is deleted at 30 days. Held on a contractual/security basis, access-restricted.
• Billing/tax records — 7 years (row 7). Held on US/WA tax-law basis.
• Subscription-consent proof — 3 years / 1 year post-termination (row 8; CA ARL). Held to demonstrate auto-renewal consent.
• Consent proof logs — ≥ 24 months (row 9). Excluded from the erasure cascade per §8.3 (GDPR Art. 6(1)(c) / Art. 7(1) duty to demonstrate consent).
• Breach / incident records — ≥ 24 months (row 12). Excluded from the erasure cascade on a separate legal-obligation basis — PIPEDA s 10.1 / SOR 2018-64 and Quebec Law 25 s 3.8 (mandatory incident register) — not under the §8.3 consent rationale. See §9.
• Amazon legally-required retention carve-out — only the period law requires, access-restricted (Amazon DPP retention carve-out). This is not a general license to retain Amazon Information past de-authorization; it is a narrow, law-mandated exception only.

A legal hold (e.g., litigation or regulatory investigation) suspends deletion for the records under hold until the hold lifts.

14. Definitions

• Amazon Information — any data exposed through the Amazon SP-API, Amazon Advertising API, Amazon Portals, or Amazon's public-facing websites, per Amazon DPP §4, regardless of whether it is personal.
• Customer Data — data a client (or their portal users) submits to, or that we generate within, the Service on the client's behalf (including client-portal content and AI outputs that become portal content); the client owns it (see Terms §7).
• De-authorization — revocation of a client's SP-API or Ads API authorization, by the client, by Amazon, or through offboarding/account closure.
• Ledger A / Ledger B — see §5. "Ledger A" is reserved strictly for Mission Control's own operational event-count metrics; it does not mean client-portal content or AI outputs (those are Customer Data).
• NIST SP 800-88 — the US standard for media sanitization we align deletion to.
• PII — personally identifiable information.
• RROSH — "real risk of significant harm," the Canadian PIPEDA breach-notification threshold.

15. Changes to This Policy & Changelog

We may update this policy as our practices, sub-processors, or the law change. Material changes are versioned, dated, and announced; the version and effective date at the top always reflect the current text, and prior versions are archived. The version string here is read from the same canonical legal-versions source as the Privacy Policy, Terms, and Cookie Policy, so the recorded version cannot drift from the displayed text. Changelog owner: SellerSlice LLC privacy team (privacy@sellerslice.com).

16. Contact

SellerSlice LLC, a Washington State (USA) limited liability company.