Simple Delivery Security Policies
Adopted: 3 September 2026 Owner: Succi Inc Review: every 12 months, or after any incident
These are the operational policies behind the Level 2 protected customer data declarations. They are deliberately short and specific to how this app actually runs. A policy nobody can follow is worse than none.
1. Data loss prevention
What we are protecting. Delivery addresses (as hashes), approximate coordinates, vehicle registrations, delivery notes. Names, emails and phone numbers are never collected.
Controls in place
| Control | Implementation |
|---|---|
| Minimise what exists | Addresses stored as SHA-256 only; coordinates rounded to ~100 m; registrations kept only for Direct to Boot |
| Delete on schedule | POST /api/retention sweep: registrations 30 days, geocode cache 180 days idle, access log 365 days, out-of-zone 365 days |
| Deny by default | Row Level Security on every table with no policies; anon and authenticated revoked |
| No bulk export | The admin has no "export all" function; data leaves only through Shopify's own order records |
| Separate environments | Production and development are distinct database projects |
| Secrets never in code | All credentials in .env, which is gitignored; no secret is passed on a command line |
What would constitute a loss event. Database credentials leaking, the Shopify API
secret leaking, or an unauthorised export of the Booking table.
If credentials leak. Rotate immediately (Supabase database password, Shopify client secret, Google Maps key), then follow the incident response process below.
2. Security incident response
Definition. Any unauthorised access to, disclosure of, or loss of personal data, or any credential compromise.
Severity
| Level | Example | Response time |
|---|---|---|
| High | Customer data accessed by an unauthorised party | Begin within 1 hour |
| Medium | Credential exposed but no evidence of use | Begin within 24 hours |
| Low | Failed intrusion attempt, suspicious access-log entry | Begin within 5 business days |
Steps
- Contain: rotate affected credentials, revoke sessions, pause the app if data is actively at risk (the admin has a pause switch).
- Assess: use the
AccessLogtable and Supabase logs to establish what was reached and when. - Notify: affected merchants without undue delay; Shopify Partner support where the platform is implicated; the OAIC where the Notifiable Data Breaches scheme applies (serious harm likely).
- Remediate: fix the cause before restoring service.
- Record: write up what happened, what was done, and what changes follow. Review this policy against it.
Contact: succiinc@proton.me
3. Access control
Principle. Only people who need customer data to do their job can reach it, and every access through the app is recorded.
- The app's database is reachable only by its own server-side connection.
- Merchant staff see only their own shop's data, enforced by the shop scoping on every query.
- Opening the bookings screen writes an
AccessLogrow: who, which categories, why, and which booking ids, never the data itself. - Access logs are reviewed when investigating an incident and at each policy review.
Accounts. Every account with access to Supabase, Shopify Partners, or the hosting provider must use a unique password of at least 16 characters generated by a password manager, with two-factor authentication enabled. Shared logins are not permitted.
Leavers. Access is removed the same day someone stops needing it.
4. Backups
Backups are managed and encrypted by Supabase. They inherit the same access restrictions as production. Restores are tested when the schema changes materially.