Undo History — Data Processing Agreement

Last updated: 27 August 2026.

This DPA is between you (the merchant installing Undo History — the "Controller") and Edwin Guo (ABN 20 938 499 163), a sole trader in New South Wales, Australia, trading as Sushinet ("Sushinet", the "Processor"). It becomes binding when you install the app, and it governs all Merchant Personal Data — your customers' and visitors' personal data that we process on your behalf.

⚠️ Read this first: there is none

Undo History processes no Merchant Personal Data. Annex I's categories are empty, and that is not a drafting shortcut — the app requests only read_products and write_products, so customer data is not merely unused but unreachable, enforced by Shopify rather than by our good intentions.

This document exists anyway, for three reasons: your own procurement may require a DPA from every processor regardless of what it holds; the commitments below (security, breach notice, sub-processor notice, erasure) apply to your catalogue data, which matters to you even though it is not personal data; and if this app ever did gain access to customer data, the contract governing it should already be in place and should have to be amended in public rather than written from scratch.

It covers Undo History and nothing else. Ruleproof and Rules2Tag carry their own Ruleproof privacy policy · Ruleproof DPA · Rules2Tag privacy policy · Rules2Tag DPA — Rules2Tag does process customer data, so its Annexes are not empty and should not be read across to this one. This site and our dealings as a studio are covered by the website privacy policy. What Undo History itself collects, and why, is set out in its privacy policy — this document is the contract, that one is the notice.

Structure and commitments mirror Ruleproof's and Rules2Tag's DPAs; the Annexes differ because the apps hold different data.

1. Roles and instructions

You are the controller; we process only on your documented instructions. Installing the app, switching flagging rules on or off, pressing Revert or Restore, running a catalogue check, and uninstalling are those instructions. We never process your data for our own purposes — no advertising, no resale, no profiling, no training of anything.

2. Confidentiality

Access is limited to persons bound by confidentiality before access is given. Today that is one operator (Annex II).

3. Security

We implement the measures in Annex II — which describes what is actually in place, not an aspirational list. Where a control has a stated limit, the limit is written down rather than implied away.

4. Sub-processors

We currently use none. Annex III is deliberately empty, and in this app error reporting is un-wired rather than outsourced (app/sentry.server.ts is a no-op stub). Before any sub-processor may touch your data we will update Annex III and notify you by email at least 30 days in advance; if you reasonably object on data-protection grounds and we cannot resolve it, you may terminate by uninstalling, which triggers erasure (§6).

5. Assisting you with data-subject requests

Shopify's mandatory webhooks are the channel, and all three are implemented and tested:

• customers/data_request — we hold no data about any customer, so the answer is nil. The request is acknowledged rather than ignored, because Shopify requires the endpoint whether or not it has work to do.
• customers/redact — nothing to erase, same reason. Acknowledged cleanly.
• shop/redact — after uninstall, erasure of every table holding your catalogue data or your session: tracked-field baselines, the change history, product snapshots, your rule settings, the scan bookkeeping, the promotion-attempt log and the OAuth session. A coverage test enumerates every database model and fails if any is neither erased nor explicitly exempted, so a future table cannot be silently forgotten.

We will also reasonably assist you with obligations under GDPR Articles 32–36 and equivalent regimes (security, breach notification, DPIAs), at no charge.

6. Deletion and return

Uninstalling is the instruction to delete. Shopify sends shop/redact 48 hours after uninstall and we erase as described in §5.

⚠️ Exempted, and named rather than buried: billing state, promotion redemptions, pending upgrades and whether you dismissed our review request survive an uninstall. They are keyed by a hash of your shop domain, contain no personal data, and exist precisely to outlive a reinstall — otherwise uninstalling would reissue a free trial and re-ask a merchant who already declined. You may ask us to erase them too: support@sushinet.fyi.

⚠️ Your plan's history window hides old changes; it does not delete them. There is no pruning job in this app, deliberately, so that upgrading restores your full history. If you want data erased before uninstalling, ask and we will erase it.

There is no other retained copy: backups age out on their own schedule (Annex II) and are never restored except in a disaster.

7. Personal data breaches

We notify you within 72 hours of confirming a breach affecting your data, with what was affected, what we did, and what we recommend you do. We do not wait for perfect information to start the clock.

8. Audits

We answer reasonable written audit questions within 30 days.

---

Annex I — Processing details

• Subject matter: recording changes to the Controller's own product catalogue, undoing them on request, and rebuilding products Shopify has permanently deleted.
• Duration: the life of the installation, plus the 48-hour window until shop/redact.
• Nature/purpose: comparing each product's tracked fields against a stored baseline; recording differences; matching them against the Controller's own flagging rules; writing a previous value back to the Controller's own Shopify records when the Controller asks.
• Data subjects: none. The app processes no data about any natural person other than the Controller's own shop domain and OAuth session.
• Categories of personal data: none. For completeness, what IS processed is the Controller's business data: product and variant field values (price, compare-at price, inventory policy, availability, status, title, description, product type, vendor, handle, tags), product snapshots including SKUs and image URLs, rule settings, and the shop domain as tenant key.
• Special categories: none, and none accepted.

Annex II — Technical and organisational measures (actually in place)

• Permission minimisation as the primary control: read_products and write_products only. The app cannot disclose customer data it was never granted access to, and Shopify — not we — enforces that. A test in the codebase fails the build if a customer scope is ever added.
• Single-tenant server (Oracle Cloud), encrypted block storage; TLS 1.2+ for all transport.
• SSH key-only access; password authentication disabled; one operator; no shared accounts.
• Separate system user, database and credentials per app on the shared host.
• HMAC verification on every webhook before any processing.
• Nightly encrypted off-site database backups with bounded retention; backups inherit the erasure obligations of §6.
• Test and production data separated (local development databases never contain merchant data).
• Stated limit: there is no protected-data access log for this app, because it holds no protected customer data to log access to. Direct operator access to the database file over SSH is possible and is not audited. Said plainly rather than covered by a control we do not operate.

Annex III — Sub-processors

None. (See §4 for the 30-day-notice commitment before this list ever gains an entry.)