Data Processing Agreement (DPA) — G9 Returns

Version: 1.0 · Effective on the merchant's acceptance (recorded in-app).

⚠️ Template, not legal advice. This is a starting template grounded in how G9 Returns actually processes data. Have it reviewed by qualified legal counsel before relying on it, and align it with your master Terms of Service and Privacy Policy.

This Data Processing Agreement ("DPA") forms part of the agreement between G9 AS ("Processor", "we") and the merchant accepting it ("Controller", "you") for the use of the G9 Returns service ("Service"). It governs Processor's processing of personal data on Controller's behalf and reflects Article 28 GDPR (and the Norwegian Personal Data Act).

1. Definitions

"GDPR", "personal data", "processing", "controller", "processor", "data subject", and "personal data breach" have the meanings in Regulation (EU) 2016/679. "Sub-processor" means any processor engaged by Processor. "Protected Customer Data" means Shopify-defined protected customer data.

2. Roles & subject matter

Controller is the controller and Processor is the processor of the personal data described in Annex I. Processor processes that data solely to provide the Service (a self-service returns and exchange portal). This DPA lasts for the term of the Service agreement.

3. Processor obligations

Processor shall:

1. Process only on documented instructions from Controller (this DPA, the Service configuration, and the merchant's use of the Service are the instructions); notify Controller if an instruction infringes applicable law.
2. Ensure persons authorised to process the data are under confidentiality obligations.
3. Implement the technical and organisational security measures in Annex II (Art. 32).
4. Engage Sub-processors only under Section 4.
5. Assist Controller (taking into account the nature of processing) to respond to data-subject requests (access, rectification, erasure, etc.) — implemented via Shopify's customers/data_request and customers/redact flows.
6. Assist Controller with security, breach notification, data-protection impact assessments, and consultations (Art. 32–36).
7. Notify Controller of a personal data breach without undue delay after becoming aware.
8. At Controller's choice, delete or return all personal data at the end of the Service and delete existing copies, unless retention is legally required (see Annex II — Retention).
9. Make available information needed to demonstrate compliance and allow for audits (Section 6).

4. Sub-processors

Controller provides general authorisation for the Sub-processors in Annex III. Processor will inform Controller of intended additions/replacements and give a reasonable period to object. Processor remains liable for its Sub-processors and imposes equivalent data-protection terms on them.

5. International transfers

Where personal data is transferred outside the EEA, Processor relies on an appropriate transfer mechanism (e.g. EU Standard Contractual Clauses / adequacy). Sub-processor locations are listed in Annex III; Processor prioritises EEA/Norway data residency where available.

6. Audits

Processor will respond to reasonable audit requests by providing its security documentation and, where genuinely necessary, supporting an inspection (on reasonable notice, subject to confidentiality and not more than annually except where required by a supervisory authority).

7. Liability & governing law

Liability is as set out in the Service agreement. This DPA is governed by Norwegian law; disputes are subject to the venue agreed in the Service agreement.

Annex I — Details of processing

• Subject matter: provision of the G9 Returns self-service returns/exchange portal.
• Duration: the term of the Service agreement.
• Nature & purpose: look up the shopper's order, verify order ownership, generate a Posten/Bring return label, and process the refund/exchange.
• Categories of data subjects: the Controller's customers/shoppers who initiate a return.
• Categories of personal data: order identifiers; shopper email and shipping postcode/address (used to verify order ownership); item/return details. A pseudonymised customer reference (Shopify customer GID or a salted hash) is stored — not raw customer identifiers. PII is masked/pseudonymised before any AI processing.
• Special categories: none intended.

Annex II — Technical & organisational measures (Art. 32)

• Encryption in transit: TLS/HTTPS everywhere; HMAC-verified webhooks and signed app-proxy sessions.
• Encryption at rest: per-tenant credentials encrypted with AES-256-GCM (AAD-bound to the tenant); database (Neon Postgres) encrypted at rest, including managed backups.
• Tenant isolation: three layers — Postgres Row-Level Security (non-owner role, FORCE RLS), repository scoping, and per-agent scope. Verified against live Postgres.
• Data minimisation: only the fields above are processed; PII is pseudonymised/masked before the AI; the append-only audit log stores no raw PII.
• Access control: staff authenticate via Clerk (strong password policy); admin/provisioning is restricted to a super-admin allowlist; least-privilege DB role.
• Logging & monitoring: append-only pseudonymised event log of processing actions.
• Separation: test and production data are separated (tests run on in-memory/stub stores).
• Resilience / DLP: managed backups + point-in-time recovery; RLS prevents cross-tenant leakage.
• Retention: personal data is retained only as long as needed to provide the Service and is deleted on a */redact request or at the end of the Service (target: deletion within 30 days), unless retention is legally required.
• Sub-processor terms: equivalent data-protection obligations flowed down.

Annex III — Sub-processors

(Vercel and Shopify's transfer mechanisms are not yet confirmed; do the same public-docs check as below before publishing. Posten/Bring and Neon process/store in the EEA/Norway so no third-country transfer mechanism applies.)

Verification notes (2026-08-05):

• Inngest, open gap, not silently assumed. Checked Inngest's published Terms (inngest.com/terms), Privacy Policy (inngest.com/privacy, which hands off to a generic iubenda-hosted policy), Security page (inngest.com/security), and their Vanta-hosted Trust Center (trust.inngest.com, Resources, Controls, and Subprocessors tabs). None mention SCCs, the EU-US Data Privacy Framework, or GDPR transfer mechanisms; the Trust Center's four listed subprocessors (AWS, GCP, Clickhouse, Planetscale) are all marked region "US" with no transfer basis given, and the only downloadable Resources are SOC 2 Type I/II reports and a pentest summary, not a DPA. A direct search of the official DPF registry (dataprivacyframework.gov/list) for "Inngest" returns zero participants. Conclusion: Inngest's EU-US transfer mechanism could not be confirmed from any public source as of today. Table entry is flagged with a // TODO rather than guessed. Ask Inngest directly (hello@inngest.com) for their DPA/SCC documentation before this sub-processor handles EEA personal data at scale.
• Anthropic, corrected. Anthropic's own Privacy Center confirms the operative mechanism is Standard Contractual Clauses: "Anthropic's DPA with Standard Contractual Clauses (SCCs) is automatically incorporated into our Commercial Terms of Service" (Anthropic Privacy Center, "How do I view and sign your Data Processing Addendum (DPA)?", https://privacy.claude.com/en/articles/7996862-how-do-i-view-and-sign-your-data-processing-addendum-dpa). Several third-party compliance blogs (not Anthropic-published) additionally claim Anthropic participates in the EU-US Data Privacy Framework. That claim does not check out: a direct search of the official DPF participant registry (dataprivacyframework.gov/list) for "Anthropic" returns zero results as of 2026-08-05. Treat SCCs (Module 2/3) as the sole confirmed mechanism for Anthropic and do not cite DPF participation for them until/unless they actually appear on the registry.
• Clerk, confirmed. Clerk's own legal page states it "has certified to the U.S. Department of Commerce that it adheres to the EU-U.S. Data Privacy Framework Principles," the Swiss-U.S. DPF Principles, and the UK Extension, effective February 22, 2024 (https://clerk.com/legal/dpf; see also the announcement at https://clerk.com/changelog/2024-02-29). Cross-checked directly against the official DPF registry (dataprivacyframework.gov/list, searched "Clerk"): one active participant, "Clerk," San Francisco CA, status Active on all three frameworks (EU-U.S. DPF, Swiss-U.S. DPF, UK Extension) as of 2026-08-05.