This describes how WarrantyBridge prevents personal data being extracted, leaked, or lost. The strategy is deliberately shaped around a small service run by a single operator: the strongest control available is to hold as little data as possible, in as few places as possible.
Data that is never collected cannot leak. The system has no column for a telephone number, street address, city, or postal code, so no code path can persist one even by mistake. Only the country portion of an address is read; the rest is discarded in memory. Access to protected customer fields is requested from Shopify at the narrowest scope the product needs.
| Boundary | Control |
|---|---|
| Into the system | Only from Shopify, over authenticated and signed channels. Webhook payloads are rejected unless their signature verifies. |
| Within the system | Every query is scoped to a single merchant. Cross-tenant reads are structurally prevented by the shop identifier on every table. |
| Out of the system | No bulk export endpoint exists. The administrative interface returns aggregate counts and single records, never a full customer dump. |
| To third parties | None, beyond the hosting provider. No analytics, advertising, session recording, or error-reporting service receives personal data. |
Every read or write of customer personal data writes an audit entry recording actor, operation, record, and trigger. Because the expected pattern is automated system access driven by orders, human access stands out and is reviewable. The log persists beyond the data it describes.
Merchant API credentials are the highest-value target: they would grant access to a shop's live data at source. They are encrypted with AES-256-GCM before storage, using a key held outside the database, so a database compromise alone does not yield them. Credentials are short-lived and refreshed automatically, which narrows the window a leaked credential remains useful. They are never written to logs.
Application secrets are held in the platform configuration store, never in source control. The repository is private and contains no credential material.
Loss is as much a data protection failure as leakage. The database is backed up automatically with encryption at rest, held within the EU, and restoration is tested before launch and after material changes to the data model. Schema changes ship as ordered, idempotent, recorded migrations, so any environment can be reproduced deterministically.
The one irreplaceable secret is the credential encryption key. It is held outside the database and backed up separately; losing it would render stored merchant credentials undecryptable and require every merchant to reconnect.
Automated retention removes personal data once it is no longer needed, so the volume of data exposed by any future incident shrinks continuously rather than growing without limit. Erasure requests and merchant uninstall take effect immediately regardless of that schedule.
Stated plainly rather than omitted:
Reviewed at least annually and whenever a new category of data, a new sub-processor, or a new export path is introduced.