Privacy Policy

1Who we are, and which hat we are wearing

Starship is operated by SAFETYCHECK, a société par actions simplifiée registered in Arras under number 909 494 882, with its registered office at 26 avenue Alfred Van Pelt, 62300 Lens, France. “Starship” and “Starship Security” are its commercial names. You can reach us at support@starshipsecurity.co for anything on this page, including any request described in section 9.

Which data-protection role we hold depends on whose data it is, and the distinction decides who you should talk to:

Store data — we are a processor

Everything we back up belongs to the merchant's store. The merchant is the controller: they decide that the store is backed up, what is backed up, how long it is kept and when it is erased. We act on their instructions and on Shopify's, and on nobody else's, under the Data Processing Agreement. If you are a shopper who bought from a store and you want to know what is held about you, the store is the party that owes you an answer; section 8 explains what happens on our side when they ask us.

Portal accounts — we are the controller

The name, email address and sign-in identity of the people who use the Starship portal are ours to answer for. So are our server and audit logs.

2What we collect

2.1 Account data

When someone creates a Starship account we hold their email address, their display name, the workspaces they belong to and their role in each, and the sign-in method they used. Authentication itself is run by Clerk (section 7); we never see or store a password.

We also keep an append-only audit log of what was done in the product — who ran a backup, who ran a restore, who read an archive containing personal data — with the account that did it and when. Its entries are hash-chained so that they cannot be altered after the fact. That log is what lets a merchant, or us, prove after the fact what happened to their data.

2.2 Store data

Once a merchant installs the app on their Shopify store and authorises it, we read the store through Shopify's Admin API using the permissions they granted at install, and keep a copy.

What that copy contains is not a fixed list in this document, on purpose: it changes as the product covers more of a store, and a list frozen here would quietly become false. The categories the app captures are shown by name, individually, inside the product itself — in the coverage report the merchant is given at onboarding and in the vault — and that display is generated from the same registry the backup engine runs on, so the two cannot disagree. What is captured falls into these families:

Customers and orders are what Shopify classifies as protected customer data, and they are treated differently from everything else throughout this document — see sections 5, 6 and 8.

We read only what the merchant's install granted. We do not buy data, we do not enrich it from other sources, we do not combine one store's data with another's, and we do not use any of it to train machine-learning models.

2.3 What we do not collect

We do not receive or store payment card numbers or bank details from a store: Shopify does not expose them and we do not ask for them. We do not place advertising or cross-site tracking cookies on the portal; the cookies it does set are the ones that keep you signed in.

3Why we process it, and on what basis

We do not sell personal data, and we do not share it for advertising.

4Where the data lives

Each workspace picks a location when it is created. Today the only location we can actually serve is Paris, France — inside the European Union, under the GDPR — so every workspace's data is in Paris, whichever of the choices was made.

The choices are not all the same thing, and the product says which is which at the moment of choosing:

• Paris is open. Choosing it stores your data there.
• Frankfurt, Dublin and Stockholm can be chosen before they open. Choosing one records it as your requested location and stores your data in Paris until it opens — still inside the European Union, under the same law, and never outside it. The picker says so on the screen, in those words, before the workspace is created. Moving the data once the location opens is a migration we run.
• Every location outside the European Union — including London, Zurich, the United States, Canada, Brazil, Singapore, Sydney, Tokyo and Mumbai — is listed but cannot be chosen. We will not answer a request for the United States by quietly storing the data in Europe, so the row is shown as not yet available instead.

The copies themselves are held in two places, both in the location the data is actually served from:

• a dedicated regional database, one per location, holding the records and the audit log; and
• a private object-store bucket in the same project, holding the bulk exports, media and theme files. Nothing in that bucket is publicly readable: it is reached only through short-lived signed URLs issued to a signed-in member of the workspace that owns it.

Each workspace's rows are separated from every other workspace's at the database level, and every business table carries the workspace identifier so that separation is enforced by the database rather than remembered by the application.

Our subprocessors (section 7) are established in the United States and operate infrastructure globally. Where any processing by them takes place outside the European Economic Area, it is covered by the European Commission's Standard Contractual Clauses under their respective data processing agreements. Backup content itself stays in the European Union, in the location it is served from.

5How it is protected

• Customer records are encrypted by the application, not just by the disk. Each individual customer's archived record is encrypted under a key belonging to that customer alone, which is itself wrapped by a key belonging to the store. Storage-level encryption at rest is also on, but it is not what this claim rests on — the ciphertext is written encrypted by the app before it reaches the database.
• Where we need to find or de-duplicate a customer by email address, we store a keyed hash of the address rather than the address itself.
• The Shopify access token for a store is stored encrypted, and is never selectable by the portal.
• All traffic is over TLS. The bucket is private. Access to the product is scoped to the workspace you are a member of.
• Every read of an archive containing personal data is written to the audit log described in section 2.1.

6How long we keep it

Backups are kept for 90 days by default, then deleted. Retention is a setting on the store, bounded between 7 and 3650 days; every workspace is on the 90-day default today. A backup past its retention window is deleted whole — its rows and the objects behind them — by a scheduled job, not merely hidden.

The customer and order archives work differently. They hold the most recently captured version of each customer and each order, for as long as the store is connected to Starship, until an erasure removes it (section 8) or the store's data is deleted.

If any page or listing elsewhere states a different default, this page is the one that matches the software.

Two things deliberately outlive the data they describe, and neither contains personal data in the clear:

• Audit entries. Proving that an erasure happened is part of performing it, so the chained log entry survives the record it refers to.
• The erasure guard. When a shopper is erased we keep an identifier and a keyed hash of their email address, and nothing else, for one purpose: to make sure a later restore can never put them back. Discarding it would make the erasure undoable, which would be a worse outcome than keeping the two values.

7Who else processes it

We will update this list before adding a subprocessor that touches backup content. Merchants get 30 days' notice of such a change, as set out in the Data Processing Agreement, which also gives each provider's location.

8The requests Shopify forwards to us, and what we do with each

Shopify requires every app to handle three requests. This is what ours actually does with each one — not a restatement of the requirement.

A shopper asks a store what it holds about them

customers/data_request. The merchant, not us, owes that shopper an answer — so we do not contact the shopper. We record the request against the store the moment it arrives, marked received, together with an audit entry noting that personal data was touched and that the answer is due within 30 days. It stays marked received until a person has actually handed the material over; a webhook cannot mark its own obligation discharged. The merchant collects their share of the material from the app. If the store was never connected to Starship, nothing is held, and that is itself the complete answer. A request that arrives while the app is uninstalled from the store is not recorded today, although we still hold the store's data until shop/redact removes it (below).

A shopper exercises their right to erasure

customers/redact. This is the one that matters most, and it is not a soft delete.

1. We first write the guard described in section 6, so that no restore can ever put that shopper back — before anything is destroyed, because a guard written after a failure is a guard that was never written.
2. We then destroy that shopper's encryption key: the wrapped key is overwritten and the row stamped as destroyed. The key existed in plaintext only inside the request that created it, and nothing can reconstruct it.

The effect is that every archive sealed under that shopper's own key — in every backup, and in every export already downloaded — becomes ciphertext that no longer has a key, without a single archive being rewritten. That is their customer record, and the copies of the orders they placed while signed in to the store that we held at the time of the request. The audit entry recording it is written into the chained log, so the proof outlives the data.

A merchant's store data has to go

shop/redact. Shopify sends this 48 hours after an uninstall. We record the request while the store still exists to point at, then delete the store and everything that hangs off it — snapshots, archives, keys — in a single transaction that writes its audit entry before it deletes anything, so a crash leaves either both or neither. The files in the object store cannot be reached by a database delete, so the store's prefix is queued and a scheduled sweep removes the objects. Finally the store's sessions and its claim on the workspace are released. If any part of the erasure fails we deliberately return an error so Shopify redelivers it, rather than acknowledging an erasure that did not happen.

An uninstall on its own is not an erasure. Merchants uninstall by accident, uninstall to reinstall, and uninstall while changing plans; deleting on that first signal would mean an accidental click costs a merchant every backup they have. The 48-hour gap is Shopify's, and we use it as intended.

9Your rights, and how to use them

If you are in the EEA or the UK you have the right to access your personal data, to have it corrected or erased, to restrict or object to its processing, and to receive it in a portable form. Comparable rights exist under other laws, including for California residents.

If you are a shopper who bought from a store

Ask the store. They are the controller, and Shopify's mechanism above reaches us automatically once they act. You can also write to us at support@starshipsecurity.co and we will pass your request to the merchant and tell you we have done so; what we may not do is act on a controller's data on the instruction of someone who is not the controller.

If you are a merchant or a portal user

Write to support@starshipsecurity.co. We answer within 30 days. Uninstalling the app starts the erasure in section 8; you do not have to wait for it if you want your data gone sooner — ask us.

You also have the right to complain to your data protection authority. In France, that is the CNIL.

10Changes to this policy

We will change this page when the software changes, and the date at the top will say when. Where a change materially affects merchants we will tell them rather than relying on them to re-read this page.