This policy governs how Stravax Group LLC detects, responds to, and reports security incidents and
personal data breaches affecting Stravax Engage, with particular attention to the customer
personal data (name and phone number) processed through the Shopify integration.
1. Scope and definitions
- Security incident: any event that may compromise the confidentiality, integrity, or
availability of Stravax Engage systems or data.
- Personal data breach: a security incident leading to accidental or unlawful destruction,
loss, alteration, unauthorised disclosure of, or access to personal data.
Covered data includes merchant customers' name and phone number, merchants' Shopify Admin API
tokens, and merchant account credentials.
2. Existing technical controls (what we are defending)
Incident response is grounded in controls that already exist in the platform:
- Tenant isolation: every record carries an organisation id and every query is
organisation-scoped; there is no cross-tenant read path. A store's account binding is
established only through a verified Shopify OAuth install, not from client-supplied input.
- Encryption: TLS in transit; Cloudflare D1/R2 platform encryption at rest; Shopify Admin API
tokens additionally AES-256-GCM-encrypted at the application layer
(cred.ts). AES-GCM's authentication tag makes a tampered
ciphertext fail decryption loudly rather than yield garbage.
- Webhook authentication: all inbound Meta and Shopify webhooks are HMAC-verified against the
raw body before any processing; idempotency keys dedupe replays.
- Access logging: an append-only administrative audit log records privileged and compliance
actions (including Shopify data-request events).
- Platform security: Cloudflare provides network-layer protection (WAF, DDoS mitigation) and
managed secret storage; production secrets are never in code or in version control.
3. Detection
Sources that may surface an incident:
- Cloudflare Workers logs and observability, and error-rate or anomaly alerts.
- Application-level errors (for example, unexpected decryption failures, signature-verification
failures, or authorisation errors).
- The administrative audit log.
- Reports from Shopify, Meta, Cloudflare, or another provider.
- Reports from a merchant, a customer, or an external security researcher.
A monitored intake for external reports (security@stravax.ai) must be maintained.
4. Triage and severity
On detection, the responder records the time, the source, and an initial description, then assigns
a severity:
| Severity |
Definition |
Examples |
| SEV-1 (Critical) |
Confirmed or likely breach of customer personal data, cross-tenant data exposure, or token/credential compromise |
A tenant-isolation failure exposing another merchant's customers; leaked Admin API tokens |
| SEV-2 (High) |
Serious risk with no confirmed data exposure yet |
A signature-verification bypass; a privilege-escalation bug found before exploitation |
| SEV-3 (Medium) |
Limited-impact issue, no personal data at risk |
Availability degradation of a non-critical path |
| SEV-4 (Low) |
Minor or informational |
Low-risk finding from a routine review |
Severity is re-evaluated as facts develop; it can be raised or lowered.
5. Containment
Immediate actions, chosen to fit the incident:
- Revoke or rotate affected credentials and secrets (Shopify app secret,
CRM_CRED_KEY, Cloudflare
and provider API tokens). Because Admin API tokens are encrypted with CRM_CRED_KEY, rotating
that key is a strong containment lever for a token-exposure incident.
- Disable the affected route, feature, or integration (for example, pause recovery sends, or
deploy a Worker version that blocks the vulnerable path).
- If cross-tenant exposure is suspected, isolate or suspend the implicated organisation(s).
- Preserve evidence: capture logs and the audit trail before making changes where feasible.
6. Notification
6.1 Affected merchants (our controllers)
For any confirmed or likely personal data breach affecting a merchant's customers, we notify the
merchant without undue delay and no later than 72 hours after becoming aware, providing: the
nature of the breach, the categories and approximate number of records affected, the likely
consequences, and the measures taken or proposed. This meets the commitment in the merchant DPA.
6.2 Affected customers
Where a breach is likely to result in a high risk to affected individuals, we support the merchant
(as controller) in notifying those individuals. We provide the merchant the information they need;
direct customer notification is normally the merchant's decision as controller.
6.3 Platforms and regulators
- Notify Shopify and Meta/WhatsApp where their platform, tokens, or policies are implicated,
within their required timelines.
- Assess and, where required, notify the relevant UAE authority under the UAE Personal Data
Protection Law within the applicable deadline.
7. Remediation
- Deploy the fix and verify it closes the root cause, not just the reported symptom.
- Rotate any remaining exposed secrets.
- Confirm restored tenant isolation and data integrity.
- Remove any data that was improperly created or exposed.
8. Post-incident review
Within two weeks of closing a SEV-1 or SEV-2 incident, conduct a written review covering: timeline,
root cause, what detection and controls worked or failed, customer and data impact, and concrete
follow-up actions with owners and due dates. Feed lessons back into controls, tests, and this
policy.
9. Roles
- Incident lead: coordinates response, decides severity and notification, owns the review.
(For Stravax Group LLC today this is the platform operator/founder; name a specific person.)
- Technical responder(s): perform containment and remediation.
10. Review
This policy is reviewed at least annually and after any SEV-1 incident.