How PrintKit protects merchant and shopper data
PrintKit runs on your storefront and touches your customers' data, so protecting that data is built into how the app works — not bolted on afterward. This page explains, in plain language, the commitments we make to every merchant who installs PrintKit and to their shoppers. Every statement here reflects how the app is actually built and operated.
We collect only what an order needs. No phone numbers, no addresses, no payment details.
AES-256-GCM at rest with a separate key per store; TLS + HSTS in transit.
One store's data can never be read by another — enforced with cryptography, not just rules.
Every access to personal data is logged, and your data is fully purgeable on request.
PrintKit is deliberately data-minimizing: it stores only what it needs to produce a job and hand it to your bench. For a custom order that means the design file and its settings (size, product, color, placement and options), plus the customer name and email the shopper submits so you know who ordered what.
We never collect:
Collecting less is the simplest protection there is: data we don't hold can't be exposed.
At rest, customer personal data — the shopper's email, their saved design state, and uploaded artwork — is encrypted with AES-256-GCM. Each store gets its own separate encryption key, so protection is scoped to a single merchant rather than shared across the platform.
In transit, all traffic is served over HTTPS/TLS, with HSTS enabled so browsers refuse to connect any other way. There is no plaintext path to the application.
PrintKit is multi-tenant, and keeping stores separated is a hard boundary. Each merchant's data is scoped to their own store, and because every store is encrypted under its own key, that separation is cryptographic — not just a logical filter. One store's data simply cannot be read using another store's key. A merchant can never see another merchant's configuration, designs, or orders.
Every time customer personal data is accessed — decrypting an email or reading a customer name into a work ticket, PDF, export, or draft order — PrintKit writes an append-only audit entry. The log records metadata only (which store, which field, the purpose, and when) and never the personal data itself, so the audit trail cannot become a second copy of the data it protects. These entries are retained for 90 days.
PrintKit takes encrypted backups daily, protected with a dedicated backup key kept separate from the key that protects live data — a stolen backup is useless without it. Backups aren't assumed to work; they're restore-tested. Our most recent verified restore was July 2026, and we re-verify on at least a quarterly cadence.
PrintKit handles Shopify's mandatory privacy webhooks automatically — the customer data request, customer redact, and shop redact flows — so data-access and data-erasure requests are actioned without manual steps. Every such request is written to an internal audit trail so we can demonstrate it was received and honored.
Shoppers who want their data deleted should contact the store they ordered from; the merchant triggers deletion through Shopify, which reaches PrintKit through these webhooks. Merchants can also request deletion directly at the address below.
PrintKit maintains a written incident-response policy. If a data incident affects your store, we will notify you without undue delay after becoming aware — targeting within 72 hours — with the information reasonably available to help you meet your own obligations, and we cooperate with Shopify's incident processes. Incident contact: support@printkit.tech.
Everything above is governed by a formal internal Data Protection & Data Loss Prevention (DLP) Policy that is reviewed at least annually, and after any material change to how we handle data, encryption, or hosting. It is the control document behind the answers PrintKit gives for Shopify's Protected Customer Data requirements.