Security Incident Response Policy — G9 Returns

Version: 1.0 · Owner: G9 AS (Processor) · Applies to the G9 Returns service.

⚠️ Template, not legal advice. This is a starting template grounded in how G9 Returns actually processes data and operates. Have it reviewed by qualified legal counsel before relying on it, and align it with your master Terms of Service, Privacy Policy, and the Data Processing Agreement. Notification timelines and legal obligations (especially the 72-hour authority deadline) must be confirmed against current law for each jurisdiction you operate in.

This policy describes how G9 AS ("we", the Processor under the DPA) detects, responds to, and learns from security incidents affecting the G9 Returns service ("Service"). It exists to protect merchants (our Controllers) and their shoppers (the data subjects), and to discharge our obligations under Article 28, 32–34 GDPR, the Norwegian Personal Data Act, and the DPA.

1. Scope & definitions

This policy covers any event affecting the confidentiality, integrity, or availability of the Service or the personal data it processes, across our production stack: Vercel (hosting), Neon (Postgres, EU eu-central), Clerk (staff auth), Inngest (background jobs/webhooks), Anthropic (AI assessment, PII-minimised input), Shopify, and Posten/Bring. (See DPA Annex III for the authoritative sub-processor list.)

Security incident — any actual or reasonably suspected event that compromises, or threatens to compromise, the security of the Service or its data. Examples: unauthorised access to a system or credential, exploitation of a vulnerability, malware, a successful or credible-attempt account takeover, denial of service, a leaked secret, or a failure of a security control (e.g. an RLS regression). Not every security incident involves personal data.

Personal data breach (Art. 4(12) GDPR) — a security incident leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data processed by the Service. This is the subset of security incidents that can trigger notification obligations (Sections 6–7).

Near miss — a control that failed but where compensating controls prevented impact (e.g. an attempt blocked by RLS). Logged and triaged, but generally not notifiable.

The data we hold (relevant to breach impact). Per DPA Annex I: order identifiers; shopper email and shipping postcode/address (used to verify order ownership); item/return details; and a pseudonymised customer reference (Shopify customer GID or a salted hash) — not raw customer identifiers. PII is masked/pseudonymised before any AI processing, and the append-only audit log stores no raw PII. Per-tenant credentials are encrypted with AES-256-GCM (AAD-bound to the tenant). These facts directly shape breach risk assessment in Section 5.

2. Roles & responsibilities

In our current team size the IL may hold several of these roles, but the decision authority (declare, set severity, notify) always rests with the named Incident Lead.

3. Lifecycle

`` detect → triage / severity → contain → eradicate → recover → post-incident review ``

Each step below is concrete to the G9 Returns stack.

3.1 Detect

Sources of detection:

• Alerts/anomalies from Vercel, Neon, Clerk, or Inngest dashboards.
• The append-only pseudonymised event log — unexpected processing actions, access patterns, or volume.
• Failed/abnormal webhook signatures (HMAC verification failures) or app-proxy session anomalies.
• A reconcile-job mismatch (e.g. GET /api/WebhooksEvents?success=false for FrontSystems) that looks security-relevant rather than operational.
• A report from a sub-processor, a merchant, a shopper, or a security researcher.

Anyone who notices a candidate incident raises it immediately to the Incident Lead (email marius@g9.no, or the agreed internal channel). When in doubt, raise it — a near miss is cheap to close, an unreported breach is not.

3.2 Triage & severity

The IL confirms whether this is a real incident, then classifies it. Two questions drive everything that follows: (a) is personal data involved? and (b) what is the severity?

The personal-data-breach clock and the 72-hour assessment (Sections 6–7) begin the moment we become aware that a breach is likely — not when triage finishes. Triage must therefore happen fast and in parallel with containment.

3.3 Contain

Stop the bleeding before perfecting the diagnosis. Containment actions, chosen by the IL:

• Revoke/rotate credentials. Rotate the affected per-tenant AES-256-GCM keys/secrets, Clerk sessions, sub-processor API keys, or webhook signing secrets. Force re-auth where needed.
• Cut access. Remove a compromised staff member from the super-admin allowlist; tighten the least-privilege DB role; disable an affected token.
• Isolate. Pause the relevant Inngest functions, take an endpoint offline via Vercel, or disable a tenant's processing if cross-tenant exposure is suspected.
• Preserve first. Snapshot logs and relevant state (Section 8) before destructive steps.

3.4 Eradicate

Remove the root cause: patch the vulnerability, fix the RLS/repository-scoping/agent-scope defect, remove malicious artefacts, close the access path, and verify the fix (ideally with a regression test — RLS isolation already has live tests; extend them). Confirm no persistence remains.

3.5 Recover

Restore normal operation safely: redeploy clean, restore from Neon managed backups / point-in-time recovery if integrity was affected, re-enable paused jobs, and monitor closely for recurrence for a defined watch period. Confirm the compromised credentials are fully retired.

3.6 Post-incident review

Within 5 business days of closure (sooner for SEV-1), the IL runs a blameless review covering: timeline, root cause, what detection/containment worked or didn't, data impact, notifications made, and concrete follow-up actions with owners and dates. Output is recorded in our internal incident log. Track remediation actions to completion.

4. Severity-to-action quick reference

5. Personal-data-breach assessment

For any incident where personal data may be involved, the IL assesses risk to data subjects, because that risk determines what we must do. We document the assessment regardless of outcome.

Factors that reduce assessed risk in our architecture — and which the IL should evaluate case-by-case, not assume:

• Pseudonymisation: we store a customer reference (GID/salted hash), not raw customer identifiers; the audit log holds no raw PII.
• Encryption: per-tenant credentials are AES-256-GCM with tenant-bound AAD; the database is encrypted at rest. If only ciphertext was exposed and keys remained protected, the risk to data subjects may be low.
• Tenant isolation: three-layer RLS (FORCE RLS non-owner role + repository scoping + per-agent scope), proven against live Postgres, constrains cross-tenant blast radius.

Factors that raise risk: exposure of shopper email and shipping address together (identifying + contactable), exposure of decryption keys alongside ciphertext, cross-tenant disclosure, or any alteration/loss affecting integrity. Note that even pseudonymised data plus a re-identification path is still personal data — do not over-rely on pseudonymisation to conclude "no breach".

The IL records: what data, whose, how many data subjects (per affected tenant), the likely consequences, and the conclusion (no breach / breach, low risk / breach, high risk).

6. Notifying affected merchants (Controllers)

Under the DPA §3.7, as Processor we notify the affected Controller(s) of a personal data breach without undue delay after becoming aware. We do not notify supervisory authorities or data subjects directly on a Controller's behalf — that is the Controller's decision and obligation; we assist them (Art. 28(3)(f)).

Our notification to each affected merchant includes, as far as known and updated as we learn more:

• The nature of the breach and the categories and approximate number of data subjects and records affected (for that tenant).
• The likely consequences.
• The measures taken or proposed (containment, eradication, recovery) and any recommended steps for the merchant.
• A named contact point at G9 for follow-up.

We send the first notification as soon as we have enough to be useful, even if details are incomplete, and follow up as the picture firms up. Because RLS scopes data per tenant, we can usually identify exactly which merchants are affected and notify only those, with tenant-specific detail. Notifications go to the merchant's designated security/admin contact.

7. Authority notification (72 hours)

Where a breach is likely to result in a risk to the rights and freedoms of natural persons, GDPR Art. 33 requires the controller to notify the competent supervisory authority without undue delay and, where feasible, not later than 72 hours after becoming aware. In Norway the authority is Datatilsynet.

• As Processor, the 72-hour authority filing is the Controller's legal obligation. Our job is to give the affected Controller(s) what they need to meet it in time — which is why Section 6 stresses prompt, early notification.
• If, for a given deployment, G9 acts as controller for any processing (confirm with counsel — by default we are processor), we file directly with Datatilsynet within the 72-hour window.
• Where a breach is likely to result in a high risk to data subjects, the controller must also communicate it to the affected data subjects (Art. 34); we support that communication.

The 72-hour clock and the controller/processor split must be confirmed with counsel for each jurisdiction and deployment. Treat this section as a checklist, not a legal determination.

8. Evidence & logging

• Preserve before remediating. Snapshot relevant logs and state before destructive containment/eradication. Primary sources: the append-only pseudonymised event log (no raw PII), Vercel deployment/function logs, Neon logs and point-in-time recovery state, Clerk auth logs, Inngest run history, and webhook signature-verification records.
• Chain of custody. The Scribe records who collected what, when, and from where. Keep evidence access-controlled and minimal.
• Privacy in the response itself. Investigation must respect the same data-minimisation rules as the Service: do not export raw PII into ad-hoc files, tickets, or chat. Reference data by pseudonymous identifiers wherever possible.
• Retention of incident records. Incident timeline, assessment, notifications, and review are retained in our internal incident log for as long as needed for accountability and legal defence, consistent with DPA Annex II — Retention.

9. Contact path

• Report a security incident or vulnerability: security@g9.no (or marius@g9.no as the current Incident Lead). Merchants may also use their established support channel — anything flagged as security-relevant is routed to the Incident Lead immediately.
• Merchant breach notifications are sent to each affected tenant's designated security/admin contact; merchants should keep that contact current in-app.
• Sub-processor incidents: we monitor and act on notifications from the sub-processors in DPA Annex III and fold them into this lifecycle.

End of policy — Version 1.0. Review at least annually and after any SEV-1 incident.