Skip to main content
This is Good Native’s security incident response policy. It satisfies the incident response policy required by Shopify’s Level 2 protected customer data requirements. It covers how we classify, contain, investigate, and report a security incident across the Bloom app and its infrastructure. An incident is any confirmed or suspected event that threatens the confidentiality, integrity, or availability of the Bloom service or the data it touches - unauthorised access, data exposure, a service outage, or a compromised credential.
Bloom stores no personally identifiable information about shoppers - Notify Me sign-ups pass straight to your Klaviyo account and are never persisted. See Data and privacy. Most incidents therefore involve shop configuration or service availability, not a personal-data breach.

​
Severity scale

Every incident gets a severity on first triage. It sets the response speed and who gets pulled in.
  • Critical. Active unauthorised access to production, confirmed exposure of merchant or shopper data, or a full outage of the Bloom service. Response starts immediately, day or night.
  • High. A likely breach not yet confirmed, a compromised credential, or a partial outage affecting many stores. Response within hours.
  • Medium. A contained issue affecting one store or a single component, with no data exposure. Response within one business day.
  • Low. A near-miss, a minor misconfiguration, or a vulnerability report with no active exploitation. Logged and scheduled.
When unsure, classify up. Severity can be lowered later once scope is confirmed.

​
Roles and responsibilities

Good Native is a small team. One person owns the incident end to end.
  • Incident lead. The founder, or their delegate, takes the lead on any High or Critical incident. They own triage, decisions, the timeline, and all external notifications. Every incident has exactly one lead.
  • Responders. Anyone else pulled in to contain, investigate, or remediate. They report to the lead and don’t notify outside parties on their own.
  • Communications. The lead handles all contact with Shopify, merchants, and processors. One voice avoids mixed messages.
For Low and Medium incidents the same person usually fills every role.

​
Detection and evidence

We spot incidents from these sources:
  • Sentry. Error and exception monitoring across the Bloom Workers. Spikes or new error classes trigger review.
  • Cloudflare. Worker logs, Analytics Engine, and WAF / firewall events for the app’s infrastructure.
  • Shopify. Partner Dashboard activity, app install / uninstall events, and webhook delivery failures.
  • Reports. A merchant, a shopper, Shopify, or a security researcher reporting something directly.
Preserve evidence before you touch anything. The first action on a confirmed incident is to capture state, not to fix it:
  • Export the relevant Cloudflare logs and Sentry issues for the affected window.
  • Screenshot or export Shopify Partner activity and any merchant-reported detail.
  • Record timestamps in UTC, the accounts involved, and what was accessed or changed.
  • Don’t delete logs, rotate away evidence, or redeploy over the affected state until it’s captured.
Cloudflare raw analytics events are retained for 90 days only. Pull anything relevant to an incident out of that window early - it won’t be there later.

​
Response steps

Work the incident in order. The lead records each step with a timestamp.
  1. Contain. Stop the bleeding. Rotate compromised credentials and API tokens, disable the affected Worker route or feature, or block the source at Cloudflare. Containment beats a clean fix.
  2. Investigate. Using the preserved evidence, establish what happened, what was accessed, which stores are affected, and the root cause. Confirm or revise the severity.
  3. Remediate. Fix the root cause - patch the code, close the misconfiguration, revoke the access. Verify the fix in production.
  4. Recover. Restore normal service, confirm monitoring is clean, and watch for recurrence. Re-issue any credentials that were rotated.

​
Breach notification

Notification is the lead’s call and starts as soon as a breach is confirmed - in parallel with containment, not after recovery.
  • Shopify. Report any incident involving Shopify or merchant data to Shopify without undue delay, as required by the Partner Program Agreement and API Licence. Use the Partner Dashboard or partners@shopify.com.
  • Affected merchants. Notify any merchant whose store or data is affected without undue delay. State what happened, what was affected, and what they need to do.
  • Supervisory authority (GDPR). If an incident is a personal-data breach likely to risk individuals’ rights, notify the relevant supervisory authority within 72 hours of becoming aware. Notify affected individuals if the risk is high.
  • Processors. Loop in Cloudflare or Klaviyo if the incident originates in or affects their platform.
Because Bloom holds no shopper PII, GDPR breach-notification duties rarely apply. The 72-hour clock only starts for a confirmed personal-data breach.

​
Post-incident review

Within one week of resolving any High or Critical incident, the lead runs a review. It’s blameless - the goal is a better system, not blame.
  • Timeline. What happened, when, and how we responded.
  • Root cause. Why it happened, not just what broke.
  • Actions. Concrete fixes with an owner and a date - monitoring gaps, missing alerts, process changes.
  • Policy. Update this page if the incident exposed a gap in it.

​
Review schedule

This policy is reviewed at least every 6 months, and after any High or Critical incident. The incident lead owns the review.