Loading...
Last updated: 2026-06-02
This policy describes how Podley prepares for, detects, responds to, and learns from security incidents affecting the confidentiality, integrity, or availability of the data we process - including merchant accounts, OAuth tokens, and protected customer data such as names, email addresses, and shipping addresses. It applies to all Podley systems, staff, and subprocessors.
A security incident is any event that compromises, or credibly threatens to compromise, the data or systems Podley is responsible for. That includes unauthorized access or disclosure, loss or corruption of data, leaked credentials or keys, successful or attempted intrusions, and material vulnerabilities in our code or our subprocessors. We treat suspected incidents as real until triage proves otherwise.
| Level | Definition | Examples | Response target |
|---|---|---|---|
| SEV-1 - Critical | Confirmed or highly likely unauthorized access to, loss of, or disclosure of protected customer data, OAuth tokens, or encryption keys. | Exposed encryption key; a database read that bypasses Row-Level Security; a leaked Shopify or Gmail token; exfiltration of case records or customer photos. | Response begins immediately, 24/7. |
| SEV-2 - High | A material vulnerability or partial compromise that could lead to a SEV-1 if unaddressed, with no confirmed data exposure yet. | A privilege-escalation bug; an authentication bypass on a non-data endpoint; a subprocessor reporting a breach that may touch our data. | Response begins within hours of confirmation. |
| SEV-3 - Medium / Low | A security weakness with limited or no blast radius, or a suspicious event that needs investigation but shows no sign of data access. | A dependency CVE with no reachable exploit path; isolated anomalous login activity; a misconfiguration caught before reaching production. | Triaged within one business day. |
Incidents surface through automated monitoring (Sentry error and anomaly alerts, uptime checks, Supabase database and auth logs, dependency vulnerability alerts) or through a human report to security@podley.app. Anyone - staff, a merchant, or an outside researcher - can report a suspected incident, and every report is acknowledged.
The incident lead opens a timestamped incident record, assigns a severity (above), and determines the scope: which systems, which merchants, and whether protected customer data is involved. The record tracks every action taken, by whom, and when.
Stop the bleeding first. Depending on the vector this means rotating the affected secret (the encryption key supports dual-key rotation so token ciphertext can be re-keyed without downtime), revoking compromised OAuth tokens, disabling an affected endpoint or account, or rolling back a bad deploy. Row-Level Security and least-privilege service roles limit how far any single compromise can reach.
Remove the root cause - patch the vulnerability, fix the misconfiguration, or invalidate the leaked credential - and confirm the same path cannot be used again.
Restore normal operation from a known-good state, using our encrypted daily backups where data integrity is in question, and verify that monitoring is clean before closing the active response.
Where an incident affects merchant or customer data, we notify affected merchants (see commitments below). For mandatory data-deletion and data-subject obligations we use the GDPR compliance webhooks already wired into the app.
Within ten business days of resolving a SEV-1 or SEV-2, we run a blameless post-mortem: timeline, root cause, what worked, what did not, and concrete follow-up actions with owners. Findings feed back into detection, controls, and this policy.
If we confirm a security incident that has compromised a merchant’s data or their customers’ protected data, we will notify the affected merchant without undue delay, and within 72 hours of confirming the breach. The notice will describe, to the extent known: what happened, what data was involved, the likely impact, the steps we have taken to contain and remediate it, and what (if anything) the merchant should do. Where the law requires it, we will also notify the relevant supervisory authority within the timeframes set by GDPR, CCPA, and other applicable regulations, and we will support merchants in meeting their own notification obligations as the data controller.
Each incident has a single accountable incident lead who coordinates the response, communications, and the post-mortem. Preventative controls reduce both the likelihood and the blast radius of incidents: encryption of data at rest (AES-256-GCM for tokens) and in transit (TLS), Supabase Row-Level Security on every read, least-privilege service roles, separated test and production environments, access logging with PII truncation, encrypted backups, and strong authentication for staff. Subprocessors and the data each handles are documented on our subprocessors page.
This policy is reviewed at least once a year and after every SEV-1 or SEV-2 incident, so that what we learn from real events is reflected in how we prepare for the next one.
If you believe you have found a vulnerability or a security incident affecting Podley, email security@podley.app. We acknowledge reports, investigate promptly, and will not pursue good-faith researchers who follow responsible-disclosure practices.
See also: Privacy Policy · Subprocessors · Trust overview