In transit. All traffic uses HTTPS. The application refuses plain HTTP. The database connection requires encryption and rejects TLS below version 1.2.
At rest. The database uses Azure SQL Transparent Data Encryption, which encrypts data files, transaction logs, and backups. Merchant API credentials receive a second, independent layer: they are encrypted with AES-256-GCM before being written, using a key held outside the database in the application's configuration store. A database copy alone therefore does not yield usable credentials.
Access to production personal data is limited to the sole operator of Gulbrandsen Apps ENK. There are no other accounts with data access. Administrative accounts — cloud, source control, and app platform — use unique passwords held in a password manager, with multi-factor authentication enabled.
The application itself authenticates every administrative request with a short-lived signed token issued by Shopify, verified on each call. There are no shared passwords, API keys, or long-lived credentials in the application surface.
Every read or write of customer personal data is recorded in an append-only audit log capturing who acted, which operation ran, which customer record was involved, and what triggered it. The log holds no personal data itself, and it survives erasure and deletion of the records it describes — an audit trail that disappeared with its subject would be worthless.
Development uses a local database and a Shopify development store containing only synthetic data. No production personal data is copied into development or testing at any time. Production credentials are held only in the production configuration store and never in source control.
The system has no storage for telephone numbers, street addresses, cities, or postal codes. Only the country portion of an address is read, and the remainder is discarded before persistence. Access to protected customer fields is requested from Shopify at the minimum scope needed.
Azure SQL takes automated backups, encrypted with the same Transparent Data Encryption as the live database. Backups are held within the EU. Restoration is tested before launch and after any material change to the data model.
Source is version controlled in a private repository. Secrets are excluded from source control; the application reads them from environment configuration. Database schema changes ship as numbered, idempotent migration scripts applied in order and recorded, so the schema of any environment is reproducible and auditable.
Any unauthorised access to, disclosure of, alteration of, or loss of personal data; loss or compromise of a credential granting such access; or any suspected compromise of hosting or source-control accounts.
| Stage | Target | Action |
|---|---|---|
| Detect | — | Alert from monitoring, a report from a merchant or customer, or a provider notification |
| Contain | Within 1 hour | Revoke affected credentials, rotate the encryption key if implicated, restrict network access, take the service offline if containment requires it |
| Assess | Within 12 hours | Determine which data and which merchants are affected, using the access log to establish scope |
| Notify merchants | Within 24 hours | Inform every affected merchant with the facts known, so they can meet their own 72-hour obligation as controller |
| Notify authority | Within 72 hours | Where Gulbrandsen Apps ENK acts as controller, notify Datatilsynet |
| Remediate | — | Fix the cause, verify the fix, restore service |
| Review | Within 14 days | Written post-incident review: cause, timeline, what prevented earlier detection, what changes follow |
A merchant notification states what happened, when it happened and when it was discovered, which categories of data and roughly how many records are affected, the likely consequences, the measures taken, and a contact point.
If the credential encryption key is suspected compromised, it is rotated and every stored merchant credential is re-encrypted. Merchants may need to reopen the app to re-establish their connection; they will be told if so.
This policy is reviewed at least annually, and after any incident or material change to the architecture.
Please report suspected vulnerabilities to security@warrantybridge.app. We aim to acknowledge within two working days. We will not pursue action against good-faith research that respects customer privacy and avoids service disruption.