Rules2Tag — Data Processing Agreement

Last updated: 17 August 2026.

This DPA is between you (the merchant installing Rules2Tag — 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.

It covers Rules2Tag and nothing else. Ruleproof carries its own privacy policy and DPA; this site and our dealings as a studio are covered by the website privacy policy. What Rules2Tag 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 DPA (our other app); 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, defining tag rules, running a backfill or sweep, and uninstalling are those instructions. We never process Merchant Personal Data for our own purposes — no advertising, no resale, no profiling beyond the rule evaluation you configured.

2. Confidentiality

Access to Merchant Personal Data 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 access log's coverage, for example), the limit is written down rather than implied away.

4. Sub-processors

We currently use none. Annex III is deliberately empty. Before any sub-processor may touch Merchant Personal 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 full erasure (§6).

5. Assisting you with data-subject requests

Shopify's mandatory webhooks are the channel, and they are implemented, tested, and logged:

• customers/data_request — we count every row held about the named customer and alert the operator, who supplies the answer to you within 30 days.
• customers/redact — immediate, permanent erasure of that customer's profile, ledgers, managed-tag rows and any still-queued job naming them.
• shop/redact — after uninstall, erasure of every table this app holds for your store. 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 everything (§5). There is no retained copy: backups age out on their own schedule (Annex II) and are never restored except in a disaster, in which case redactions received since the backup are replayed from the access log's record of them.

7. Personal data breaches

Defined in our internal security policy, and binding here: 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, and Shopify's own Protected Customer Data review process applies to us continuously.

---

Annex I — Processing details

• Subject matter: automatic tagging of the Controller's customers, orders and products.
• Duration: the life of the installation, plus the 48-hour window until shop/redact.
• Nature/purpose: evaluating merchant-defined rules against record attributes; writing tags back to the Controller's own Shopify records; maintaining the derived per-customer profile that makes lifetime-history rules possible.
• Data subjects: the Controller's customers and checkout visitors.
• Categories of data: order facts (totals, dates, line-item ids, discount codes, gateway, shipping/billing country, company name); customer email, email-verified and marketing-consent state, default-address postcode, tax-exempt flag, Shopify tags; derived aggregates (lifetime spend, order count, last-order and last-abandonment dates). Not processed: names, phone numbers, payment card data.
• Special categories: none, and none accepted.

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

• 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.
• Data minimisation by design: fields no rule reads are not stored (no names, no phones); raw webhook payloads are scrubbed from the job queue at completion.
• Append-only access log of every deliberate touch of protected data — counts and reasons, never ids. Stated limit: direct operator database access over SSH is not captured by it.
• Nightly encrypted off-site database backups with bounded retention (see scripts/ and the backup unit); backups inherit the erasure obligations of §6.
• Test and production data separated (local dev databases never contain merchant data).

Annex III — Sub-processors

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