1. Encryption #
In transit
All communications are encrypted with TLS: between your browser and the platform, and between the platform and the Shopify API.
Access tokens
Access tokens for your Shopify stores are encrypted at application level in the database. They are never displayed again in the interface after being entered, and never written to logs.
At rest
Backup files (NDJSON and media) are protected by the encryption of the underlying storage: server volume encryption, or server-side encryption of the object store where one is used. The service applies no additional encryption layer to those files.
If you store your backups in your own bucket, the encryption policy is the one you apply to that bucket.
2. Isolation between customers #
The platform is multi-tenant by design. Isolation is not display filtering: it is enforced at the database query layer, backed by authorization policies checked for every resource, and covered by dedicated automated tests.
Identifiers exposed in URLs are non-enumerable UUIDs; the readable references shown in the interface give no way to guess another record. Storage is separated per store, and the destination disk can be a space you control.
3. Access control #
- Distinct roles: platform administrator, customer administrator, customer user — with different rights over stores, restores and billing.
- Two-factor authentication (TOTP) can be enabled per account, with a challenge at sign-in.
- Email verification at sign-up; accounts can be deactivated without being deleted.
- Signed download links, valid for fifteen minutes and subject to an authorization check.
4. Logging #
Sensitive actions are recorded in an audit log you can consult: starting and deleting backups, restores, connecting stores, changing accounts. Each entry records the author, the object and the timestamp.
[TO COMPLETE: log retention period — no automatic purge is configured today.]
5. Backup integrity #
- Every backup records, per resource type, the number of records, the number of media and the size obtained: a discrepancy is visible.
- Media are deduplicated by SHA-256 checksum, which also verifies their integrity on download.
- A backup left hanging is detected and marked as failed, with an alert, rather than staying "running" forever.
- A daily check runs an end-to-end backup against the real API, so that a broken interface surfaces before you experience it.
- The export format is open: you can inspect the contents of a backup yourself, without depending on us.
6. Restore safeguards #
A restore writes into a production store: it is the most dangerous operation in the product, and it is treated as such.
- Dry-run by default: nothing is written until the report has been produced and reviewed.
- Confirmation by typing the domain of the target store before any real write.
- PRODUCTION / STAGING badge shown everywhere a write is possible.
- One restore at a time per target store.
- Orders and inventory transfers are never written back.
7. Incident response #
A documented procedure governs qualification, containment, remediation and communication in the event of a security incident.
In the event of a personal data breach:
- notification to the supervisory authority within 72 hours where notification is required;
- notification to affected customers within 48 hours of becoming aware of the incident, with what they need for their own obligations;
- notification to the individuals concerned where the risk to their rights and freedoms is high.
8. Reporting a vulnerability #
If you find a flaw, write to describing the issue and the steps to reproduce it. We acknowledge receipt and keep you informed.
We ask that you do not exploit the vulnerability beyond what is needed to demonstrate it, that you do not access anyone else's data, and that you allow a reasonable period before public disclosure.
Personal data processing is described in the privacy policy; contractual security commitments appear in the annex to the data processing agreement.