Security Incident Response Policy

An incident is any actual or reasonably suspected unauthorized access, use, disclosure, alteration, loss, or destruction of Customer Data or of systems that store it (including credentials used to reach connected APIs).

This policy applies to:

• Production application, database, and object-storage systems that hold Customer Data.
• OAuth connections and tokens held by our integration provider (Nango) on our behalf.
• Staff access to production (dashboards, database consoles, logs).
• Personal data of a merchant's customers obtained through Shopify, QuickBooks, uploads, or other connected sources.

• Incident lead: the on-call operator for Sourcebook production (currently the founding team). Owns containment, communication, and close-out.
• Privacy contact: sourcebooksupport@gmail.com for data-subject and merchant privacy questions.
• Security contact: sourcebooksupport@gmail.com for incident reports and vulnerability disclosures.

Anyone who suspects an incident must report it immediately to the security contact. Do not wait for confirmation.

• Critical: confirmed unauthorized access to Customer Data or to production credentials (database, Nango, Shopify/Intuit app secrets).
• High: suspected access, a lost device with production access, or a vulnerability that could expose Customer Data if exploited.
• Medium: failed intrusion attempts, misconfiguration with no evidence of data access, or a single-organization issue contained to that workspace.
• Low: phishing reports, policy violations without data exposure.

We detect incidents through:

• Application and infrastructure logs (hosting, database, authentication).
• Personal-data access logs recording who read Customer Data in the Service (user, organization, resource, time).
• Alerts from subprocessors (Supabase, Nango, email, error monitoring).
• Reports from merchants, users, or third parties to the security contact.

5.1 Contain

• Revoke or rotate compromised credentials: Nango secret key, Shopify and Intuit app secrets, database passwords, and session keys.
• Disconnect or pause affected integrations so no further API pulls occur until the cause is understood.
• Disable affected user accounts and require re-authentication for staff with production access.
• Preserve logs and a snapshot of relevant records; do not wipe evidence.

5.2 Investigate

• Establish what systems and organizations were involved, the time window, and whether Customer Data (including Shopify customer name or email) was accessed or copied.
• Review personal-data access logs, authentication logs, and subprocessor audit trails.
• Document findings as they are confirmed. Speculation stays out of merchant notices.

5.3 Eradicate and recover

• Remove the cause (patch, revoke leftover keys, fix the misconfiguration).
• Restore from known-good backups only if integrity is in doubt, after confirming backups were not also compromised.
• Confirm that production access is limited to named staff accounts.

We notify affected Customers without undue delay after we confirm an incident that compromises their Customer Data. Where law requires a specific clock (including GDPR 72-hour supervisory-authority notice, when it applies), we meet that clock. Notices describe what happened, what data was involved, what we have done, and how to reach us.

We also notify, as applicable:

• Shopify, when an incident involves Shopify protected customer data or app credentials, using Shopify's partner/security reporting channels.
• Intuit, when an incident involves QuickBooks Online data or Intuit app credentials, per Intuit platform rules.
• Nango, when the incident involves their connection infrastructure.
• Law enforcement or regulators when legally required.

We do not notify the public or other Customers about an incident that is confined to one Organization, except as required by law.

Staff access to production Customer Data is limited to people who need it to operate the Service. Production database and dashboard access uses named accounts, not a shared login. We log reads of Customer Data in the product (including lake records that may contain a merchant's customer name or email) with the acting user, organization, resource, and time. We do not put the personal data itself into those logs.

After containment, the incident lead writes a short post-incident note: timeline, root cause, data involved, who was notified, and follow-up work. Critical and high incidents are reviewed so the same gap is not left open.

Report suspected incidents or vulnerabilities to sourcebooksupport@gmail.com. Privacy requests remain sourcebooksupport@gmail.com.

Please include what you observed, when, and any IDs or URLs involved. Do not send live production secrets in email; say that a secret may be exposed and we will arrange a safer channel.