Legal

Security Incident Response Policy

Last updated: 30 July 2026 · Owner: Incident Commander · Reviewed annually and after any SEV1

Squid Solutions B.V.

Goudvinklaan 92, 3722 VE Bilthoven, The Netherlands · Registration 42033298

Security and incident contact: legal@squidsupport.ai

1. Purpose and scope

This policy defines how Squid Support detects, triages, contains, remediates, and reports security and availability incidents affecting the platform, its merchants, and the personal data we process.

It covers every production surface: the support dashboard, the embeddable chat widget, the customer return portal, the email channel, the Shopify app and its webhooks, and all backend services and integrations. Production runs on Google Cloud in europe-west1 (EU).

2. Severity levels

Level	Definition	Concrete examples
SEV1 — Critical	Confirmed or highly likely exposure or compromise of data or credentials; active breach. Immediate response, all other work stops.	Cross-tenant data exposure (an organization-scoping failure surfacing one merchant's conversations or customers to another); leak of `SECRET_KEY`, `ENCRYPTION_KEY`, or stored OAuth tokens; active intrusion or data exfiltration.
SEV2 — High	Serious single-tenant impact or prolonged core-service outage, with no confirmed cross-tenant exposure.	A merchant's conversations or customers corrupted, mis-merged, or wrongly deleted; prolonged AI or inbound-email outage; Shopify webhook processing failing such that GDPR requests go unhandled.
SEV3 — Degraded	Non-critical feature degraded; a workaround exists; no data risk.	Shipment-tracking lookups failing; return-portal export failing; a dashboard view rendering slowly.

Severity is assigned at triage and may be escalated or de-escalated as facts change. When in doubt, treat it as the higher severity.

3. Detection

Error monitoring — backend and chat-widget exception reporting, including compliance-tagged events such as GDPR webhook failures.
Cloud monitoring — uptime checks and alerts on production services and their dependencies.
Metrics and logs — aggregated metrics, traces, and logs.
Merchant and user reports — to legal@squidsupport.ai or via in-product support.
Internal observation — by staff during operations, deploys, or review.

4. Roles

Incident Commander (IC) — owns incident response and is primary on-call. The IC coordinates triage, containment, communications, and the post-mortem, and is the single decision-maker for the duration of an incident.
Escalation path — where the IC is unreachable, the emergency developer contact registered with our app platform is the fallback responder. The IC's first action on any SEV1 is to record the incident in writing so a second responder can pick it up cold.
Communications — the IC, or a delegate named in the incident record, owns all merchant, platform, and supervisory-authority notification.

5. Response procedure

1. Assess and triage

Confirm the incident is real, assign a severity, open an incident record, and start a UTC timeline. Identify affected tenants, data categories, and surfaces.

2. Preserve evidence before remediating

See Section 7. Take an on-demand database backup at the start of any SEV1 or SEV2 — this is mandatory, not optional.

3. Contain

Roll back the deployment to the last known-good revision if a deploy caused the incident. This is the fastest containment available and should be considered first.
Revoke platform access tokens for affected installations and force a fresh authorization. Stored offline tokens are encrypted at the application layer.
Rotate the compromised key, using a previous-key fallback so existing encrypted data still decrypts while new writes use the new key. Rotating the signing key logs out every user immediately; rotating the integration-credential key does not.
Rotate exposed third-party credentials at the provider first, then in our secret store, adding versions individually rather than republishing in bulk.
Disable the affected feature or integration, or block the offending traffic, where a targeted fix is not immediately available.

4. Eradicate and remediate

Remove the root cause — patch the code path, fix the mis-scoped query, revoke leaked secrets everywhere they appear — and verify the fix through a controlled deploy.

5. Notify

Execute Section 6.

6. Post-mortem

Complete within 5 business days of resolution (Section 8).

6. Notification commitments

Affected merchants — notified within 72 hours of confirming an incident affecting their data, stating the nature of the incident, the categories of data involved, and the remediation taken. As a processor we notify the merchant-controller without undue delay so they can meet their own obligations.
Platform partners — for incidents affecting an app integration or protected customer data obtained through it, we notify the platform in line with its app requirements.
Supervisory authority — where an incident is a personal-data breach likely to result in a risk to individuals, we notify the competent authority under GDPR Art. 33 (generally within 72 hours of becoming aware) and affected data subjects under Art. 34 where required. Our establishment is in the Netherlands; the Autoriteit Persoonsgegevens is the relevant authority for our own controller-side obligations.

7. Evidence preservation

Capture before any destructive remediation, and do not alter or delete logs or affected records until capture is complete:

Application and request logs from the production environment.
The audit log — retained 90 days. Export the relevant window immediately if the incident may span that boundary.
Personal-data-access events — emitted whenever staff access a customer's stored data, showing who accessed what and when.
Database backups — automated daily backups are enabled on production with 30-day retention. An on-demand backup at the start of a SEV1 or SEV2 is the way to freeze state between nightly backups. Take one first.

8. Post-mortem

Completed within 5 business days of resolution. Blameless — focused on systems and process, not individuals. Every post-mortem records the timeline, the impact (who and what was affected, how many tenants and records, data categories, duration), the technical root cause and contributing factors, an assessment of how detection and response performed, the remediation and preventive action items with owners and due dates, and the notifications made.

9. Review

Reviewed at least annually, and after any SEV1 incident, by the Incident Commander. Material changes are reflected in the “Last updated” date above.