Security Incident Response Policy

1. Scope

This policy covers the CreditDesk application, its supporting infrastructure (application servers, PostgreSQL database, Redis, object storage, secret storage), and the personal data it processes on behalf of merchants: buyer name, buyer email, company name, and order and payment amounts.

A security incident is any event that compromises, or is reasonably suspected of compromising, the confidentiality, integrity, or availability of that data or the systems holding it. A personal data breach is the subset of incidents involving accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data.

2. Roles and responsibilities

• Incident Lead — a single named individual is accountable for each incident from declaration to closure. They decide severity, coordinate the response, and own all notification decisions. The role is held by the operator of CreditDesk and is transferred explicitly in writing if unavailable.
• Responder — performs technical containment and remediation. On a small team this may be the same person as the Incident Lead; where it is, a second reviewer signs off on the post-incident review.
• Communications owner — responsible for merchant, Shopify, and regulator notifications, and for keeping a single written record of what was communicated and when.

3. Severity scale

• SEV1 — Confirmed or probable unauthorised access to personal data or credentials. Examples: exposure or theft of Shopify access tokens or the at-rest encryption key, unauthorised access to the production database, or data belonging to one merchant being served to another. Response begins immediately, at any hour.
• SEV2 — A control that protects personal data has failed, without confirmed exposure. Examples: a tenant-scoping violation reaching production, a defect that sends a buyer email to the wrong recipient, an exposed non-production credential, or a dependency advisory affecting a component that handles personal data. Response begins within one business day.
• SEV3 — Security-relevant defect or degradation with no realistic path to data exposure. Examples: an isolated failed background job, an expired certificate on a non-production endpoint, or a low-severity dependency advisory. Handled through normal work tracking.
• Severity is assigned on the worst credible outcome given what is known, and is raised or lowered explicitly as facts change. When the severity is genuinely unclear, the higher level applies until it is ruled out.

4. Detection

Incidents are detected through monitoring and through reports from people outside the team. Both routes are treated as equally valid.

• Application error monitoring on the web and worker processes, with alerting on unhandled exceptions.
• Structured application logs and infrastructure logs retained centrally.
• Health checks on the application, database, and queue.
• Product-specific alarms that indicate a control has failed: any unscoped (cross-tenant) database query, ledger reconciliation drift beyond tolerance, checkout enforcement failing open, and metafield staleness beyond its budget.
• An immutable audit log of privileged and data-changing actions.
• Reports from merchants, buyers, Shopify, or security researchers, sent to security@getcreditdesk.com. Reports are acknowledged within two business days.

5. Required actions

Every declared incident follows these steps in order. Steps may run in parallel but none may be skipped; skipping one is recorded with a reason.

• Declare — record the time, reporter, and initial severity. Open a single running timeline that every subsequent finding is appended to.
• Preserve evidence — before changing anything, capture the relevant logs and take a database snapshot. Remediation must not destroy the record of what happened.
• Contain — stop ongoing harm using the least destructive effective action. Available actions include revoking the affected merchant's access tokens, rotating the at-rest encryption key, rotating database and third-party credentials, disabling outbound collections email globally or per merchant, removing checkout enforcement so no buyer is wrongly blocked, and taking the application offline.
• Eradicate — identify and remove the root cause, not only its symptom.
• Recover — restore normal service, verify the ledger reconciles against Shopify, and confirm the failed control is working again.
• Notify — see section 6.
• Review — see section 7.

6. Escalation and notification

• SEV1 is escalated to the Incident Lead immediately on detection. SEV2 is escalated within one business day. SEV3 requires no escalation.
• Affected merchants are notified without undue delay once an incident is confirmed to involve their data, in plain language: what happened, what data was involved, what has been done, and what if anything they need to do.
• Shopify is notified through Partner support when an incident involves protected customer data obtained through Shopify APIs, or Shopify-issued credentials.
• Where a personal data breach is likely to result in a risk to individuals, the relevant supervisory authority is notified within 72 hours of becoming aware of it, in line with GDPR Article 33. Where the risk is high, affected individuals are informed as well. Merchants are controllers of their buyers' data and CreditDesk is a processor, so notifications are coordinated with the merchant rather than issued around them.
• Notification is never delayed to complete an investigation. Incomplete information is communicated as incomplete and updated as facts are established.

7. Post-incident review

Every SEV1 and SEV2 incident gets a written review within ten business days of closure. The review records the timeline, the root cause, why existing detection did or did not catch it, and specific corrective actions with owners and dates. Reviews examine the systems and decisions that allowed the incident, not individual blame — the goal is that the same failure cannot recur silently.

Corrective actions are tracked to completion alongside normal engineering work and are not closed by the incident being resolved.

8. Supporting controls

This policy relies on controls that are implemented and verifiable in the running system:

• Personal data is encrypted in transit (TLS only) and at rest, including database storage, cache, object storage, and backups. Shopify access tokens are additionally encrypted at the application layer with a rotatable key.
• Every database query for merchant-owned data is constrained to a single merchant, enforced in code and covered by an automated test that fails the build otherwise.
• Webhook payloads are signature-verified before being parsed.
• Test and production data are fully separated: staging has its own database, cache, and secrets, and no production data is copied into it.
• Data is retained only as long as needed: all merchant data is purged 30 days after uninstall, and immediately on a redaction request.
• Database backups support point-in-time recovery with a 30-day window, and restores are exercised periodically.

9. Reporting a vulnerability

Please report suspected vulnerabilities or incidents to security@getcreditdesk.com. We aim to acknowledge within two business days and will keep you updated as we investigate. We will not pursue action against researchers who report in good faith, avoid privacy violations and service degradation, and give us reasonable time to remediate before disclosing publicly.