PriceMux Processor-Level DPIA

Owner: Xynik LLC. Last Review: 2026-05-19 Reviewer / Approver: Matthew Whitley, sole director, Xynik LLC

Voluntary, accountability-driven DPIA under GDPR Art. 35(1) and Recital 89, applying the Art. 35(7) structure even though PriceMux’s processing does not meet a mandatory DPIA threshold under Art. 35(3) (no large-scale special-category data; no systematic monitoring of a publicly accessible area at scale; no profiling with legal or similarly significant effects).

1. Nature, Scope, Context, Purpose (Art. 35(7)(a))

Nature: automated processing of order-level metadata via Shopify webhooks; admin-action audit logging.
Scope: Shopify merchants worldwide; per-order metadata as in Privacy Policy §2. No customer-identifying fields. Level 1 PCD only.
Context: B2B SaaS distributed through the Shopify App Store; merchant is controller, PriceMux is processor.
Purpose: apply merchant-configured pricing rules and enforce subscription tier limits.

2. Necessity and Proportionality (Art. 35(7)(b))

The categories listed in Privacy Policy §2 are the minimum necessary to evaluate pricing rules and enforce tiers. No customer name, email, phone, address, full ZIP, or join key (data minimisation per Art. 5(1)(c)). The retention window in Privacy Policy §4 (up to 13 months of raw per-order rows: 12-month rolling window plus a reconciliation buffer of up to 30 days) is bounded to the minimum required for tier-enforcement disputes and contractual reconciliation (storage limitation per Art. 5(1)(e); ICO guidance).

3. Risks to Data Subjects (Art. 35(7)(c))

Risk	Likelihood	Severity	Notes
(a) Data exposure via sub-processor breach	Low	Low–Medium	No customer-identifying fields stored; re-identification across orders not possible given no join key.
(b) Merchant misconfiguration of pricing rules causing unintended customer impact	Low	Low	Not a privacy risk per se — documented for completeness.
(c) Retention overshoot due to worker failure	Low	Low	Backstop alert and manual deletion procedure.
(d) Single-site loss at Orlando first-party facility	Low	Medium	Recovery posture: re-seed from primary Hostinger production data; accept RPO gap up to last successful primary→standby replication. Operator has consciously accepted single-site failure mode in exchange for keeping backup data inside a first-party facility.

4. Mitigations (Art. 35(7)(d))

Data minimisation: no customer join key; full ZIP dropped at webhook handler; no shipping address.
Encryption: TLS 1.2+ in transit; AES-256 at rest on Postgres and backup volumes.
Webhook integrity: HMAC verification of every Shopify webhook prior to handler execution.
Sub-processor binding: SCC Module 3 for Hostinger and Cloudflare; UK IDTA Addendum VERSION B1.0.
Retention worker: automated, with audit log of deletions; manual backstop for worker failure documented in the operator runbook.
Shopify compliance webhooks: customers/data_request returns either no_customer_data_stored or order_usage_rows_exported together with the matching opaque order GIDs from the tier-counter table (no customer-identifying fields), audited; customers/redact deletes the corresponding OrderUsage rows by order GID match against orders_to_redact; shop/redact cascades shop-scoped table deletion at uninstall + 48 hours.
Audit logging: all merchant admin actions inside the embedded app written to a tamper-evident audit log. Each row is sealed with a SHA-256 row_hash over the prior row’s hash plus the new row’s canonical serialization, producing a per-shop hash chain — any UPDATE or DELETE in the audit table breaks every subsequent hash and is surfaced by the op-audit-log-verify walk. Writes serialize per-shop via a Postgres advisory lock so concurrent writers cannot fork the chain.
Single-site Orlando residual: documented and accepted; mitigated by primary-production redundancy at Hostinger Boston.

5. Stakeholder Consultation (Art. 35(9))

Operator review only at this stage. No consultation with data subjects, because (a) no individuals are identified by the data we process, and (b) the contractual relationship runs through the merchant. Published in summary form (this document); full Annex II detail shared on Merchant request under NDA.

6. Prior Consultation (Art. 36)

Prior consultation with a supervisory authority is not required because no residual high risk remains after mitigations, particularly given the absence of any customer-identifying processing.

7. Review Cadence

Reviewed at least annually and on any of: (a) material change to data categories processed; (b) addition or replacement of a sub-processor; (c) Shopify PCD-level change; (d) substantial change to Orlando facility security posture.