Ferry — Security Incident Response Policy

Effective date: 3 August 2026 Owner: Prendit EOOD (Прендит ЕООД) · security contact: security@ferrycommerce.com

1. Purpose & scope

This policy defines how we detect, respond to, and report security incidents affecting Ferry — in particular any breach of the personal data (customer name, address, phone, email) or merchant credentials we process. It covers all Ferry Cloudflare Workers (the Shopify app and its sibling services), their D1/R2/KV/Queue/Durable-Object storage, courier and third-party API integrations, and the source-code repository.

2. What counts as an incident

Any actual or suspected event that compromises the confidentiality, integrity or availability of personal data or systems, e.g.: unauthorised access to D1/R2/KV; leaked secrets — application/platform API secrets, the data-encryption key, merchant courier credentials, provider tokens, administrative bearer tokens, or webhook secrets; an exploited vulnerability; credential compromise; or a sub-processor breach notification.

3. Roles

For a small team one person may hold both roles; the point is a single accountable owner.

4. Response procedure

1. Detect & report — anyone noticing an incident reports it to security@ferrycommerce.com immediately. Sources include Cloudflare observability/alerts, error spikes, and third-party notices.
2. Triage & classify — assess what data/systems are affected and assign severity:
   • SEV-1 — confirmed breach of personal data or merchant credentials (notification duties in §5 apply);
   • SEV-2 — suspected breach, or an exploitable weakness with access to personal data (treat as SEV-1 until disproven);
   • SEV-3 — security event with no personal-data exposure (handled as an ordinary fix, still recorded).
3. Preserve evidence — before remediation where feasible, capture the relevant logs, request records and affected-data inventory (what/whose data, over what window) — this feeds both the §5 notifications and the post-incident review.
4. Contain — stop the bleeding: rotate exposed secrets, revoke tokens/credentials, disable the affected path, block the actor.
5. Eradicate & recover — fix the root cause, restore clean state, verify integrity.
6. Notify (see Section 5).
7. Post-incident review — within 5 business days: timeline, root cause, and concrete follow-up actions to prevent recurrence.

5. Notification

• Merchants (controllers): notify affected merchants without undue delay after confirming a personal-data breach, per the DPA, with the nature of the breach, likely consequences, and measures taken.
• Supervisory authority: where we are controller and the breach is likely to result in a risk to individuals, notify the Bulgarian КЗЛД within 72 hours of becoming aware.
• Shopify / sub-processors: notify as required by their terms.

6. Secret-exposure quick runbook

If any secret from §2 is exposed:

1. Rotate it at the source (the platform dashboard, the provider’s portal, or — for courier credentials — the merchant re-entering them).
2. Update the deployed secret store.
3. Encryption-key caveat: rotating the data-encryption key makes previously-encrypted data unreadable — a re-encryption migration is planned first, never a blind production rotation.
4. Invalidate anything derived from the secret (sessions/tokens) and monitor for misuse.

7. Prevention (standing controls)

• Secrets are never committed to source control; production secrets live only in the platform secret store.
• Encryption at rest and in transit; least-privilege access; strong auth + 2FA on Cloudflare, Shopify Partner and GitHub accounts.
• Separate test/production data; dependency and access review.

8. Review

Reviewed at least annually and after any significant incident.