Data Processing Agreement

Version: 2026-05-01 Effective date: 2026-05-01 Status: Draft — currently under legal review. Not yet ratified by external counsel.

This Data Processing Agreement (the "DPA") is entered into between Keygum AB ("Processor," "Keygum") and the business customer identified on the Keygum account (the "Controller," "Customer"). It forms an integral part of the Terms of Service (the "Agreement") and applies to the extent the Processor processes personal data on behalf of the Controller under the Agreement.

This DPA is drafted to satisfy Article 28 of Regulation (EU) 2016/679 (the "GDPR"). Where a term is defined in the GDPR and not here, the GDPR definition applies. In the event of a conflict between this DPA and the Agreement regarding the processing of personal data, this DPA governs.

1. Subject matter, nature, purpose, duration

• Subject matter. Processing of personal data in connection with the Keygum Service as described in the Agreement.
• Nature. Collection, storage, structuring, transmission, consultation, and erasure of personal data; forwarding of content to third-party social-media Platforms on Controller instruction.
• Purpose. To enable the Controller to publish, schedule, manage, and analyse content across social-media Platforms through a unified API.
• Duration. For so long as the Processor processes personal data on behalf of the Controller under the Agreement, extended by any post-termination retention periods set out in Section 9.

2. Types of personal data and categories of data subjects

Types of personal data processed (the Controller may instruct processing of additional data at its discretion; the Processor does not select the data):

• identifiers carried inside published content (names, handles, profile-image URLs, mentions, tags);
• OAuth access and refresh tokens associated with the Controller's Platform accounts (encrypted at rest);
• Platform account metadata returned to the Service (account IDs, display names, avatar URLs);
• analytics metrics retrieved from Platforms (engagement counts, impression counts, reach, views, reactions);
• any other personal data the Controller chooses to upload inside Customer Content.

Categories of data subjects:

• individuals whose personal data appears in Customer Content (authors, subjects, mentioned persons);
• end audiences of the Controller's Platform posts whose interactions the Platform reports back (limited to data the Platform's own terms permit us to receive);
• the Controller's authorised personnel (where their personal data is ancillary to processing, for example, an operator's user-ID appears in an audit-log entry).

Keygum does not knowingly process special-category data under Article 9. The Controller is responsible for ensuring Customer Content does not contain special-category data where doing so would exceed the Controller's own lawful basis for the processing.

3. Controller and Processor obligations

3.1 Controller obligations

The Controller warrants that:

(a) it has a valid legal basis under Article 6 (and where applicable, Article 9) for the processing it instructs; (b) it has complied with its own GDPR obligations, including the transparency obligations to data subjects under Articles 13 and 14; (c) its instructions to the Processor comply with the GDPR and other applicable law; (d) its authorised personnel accessing the Service have received appropriate instruction and confidentiality obligations.

3.2 Processor obligations

The Processor will:

(a) process personal data only on documented instructions from the Controller, including those set out in the Agreement and the Service's standard configuration. The Service's documented, default processing behaviour constitutes a documented instruction for the purposes of Article 28(3)(a); (b) process personal data solely in connection with the Service, and not for its own purposes — except for the aggregated, non-personal-data processing described in the Privacy Notice; (c) ensure that persons authorised to process the personal data have committed themselves to confidentiality (either by contract or statutory obligation); (d) implement appropriate technical and organisational measures under Article 32 to meet the requirements of the GDPR (see Annex II); (e) respect the conditions for engaging sub-processors set out in Section 4; (f) assist the Controller, by appropriate technical and organisational measures, in fulfilling its obligation to respond to data-subject rights requests (see Section 5); (g) assist the Controller in ensuring compliance with Articles 32 to 36 (security, breach notification, data-protection impact assessments, prior consultation); (h) at the Controller's choice, delete or return all personal data at the end of the service, and delete existing copies, unless retention is required under applicable law or Section 9; (i) make available to the Controller all information necessary to demonstrate compliance with Article 28, and allow for and contribute to audits under Section 8.

3.3 Notification of unlawful instructions

The Processor must immediately notify the Controller if, in its opinion, an instruction from the Controller infringes the GDPR or other applicable Union or Member-State data-protection law.

4. Sub-processors

4.1 General authorisation

The Controller grants the Processor a general written authorisation under Article 28(2) to engage sub-processors, subject to the conditions in this Section.

4.2 Current sub-processor list

The current list of sub-processors, including their purpose and location, is set out in Annex III. The Privacy Notice mirrors this list for convenience.

4.3 Change notice

The Processor will give the Controller at least thirty (30) days' prior notice before adding a new sub-processor or materially changing the scope of an existing sub-processor's processing. Notice is given by email to the billing contact and by update to the Annex III list published on the Service.

4.4 Objection

During the notice period the Controller may object on reasonable grounds. The parties will cooperate in good faith to resolve the objection. If no resolution is reached, the Controller may terminate the Agreement under the Terms Section 6; neither party owes the other damages for a termination under this sub-section.

4.5 Sub-processor obligations

The Processor will ensure that each sub-processor is bound by a written agreement that imposes data-protection obligations no less protective than those in this DPA, as required by Article 28(4). The Processor remains liable to the Controller for the acts and omissions of its sub-processors to the same extent it would be liable for its own acts and omissions.

5. Data-subject rights assistance

The Service provides self-serve tooling that enables the Controller to:

• access, correct, or delete data held for a specific Customer Account through the dashboard;
• disconnect Platforms and revoke OAuth tokens from the dashboard;
• export audit-log data and analytics snapshots on request (via support email until the v2 self-serve export tooling ships).

Where a data-subject request is received by the Processor but was intended for the Controller, the Processor will, without undue delay, forward the request to the Controller and will not respond to the data subject without the Controller's instruction. The Processor will assist the Controller in responding to data-subject rights requests to the extent reasonably necessary and technically feasible. Assistance that requires more than five (5) person-hours of engineering effort on any single request may be charged at our standard professional-services rate with advance written notice and Controller approval.

6. Personal-data breach notification

6.1 Notification window

The Processor will notify the Controller without undue delay, and in any event within seventy-two (72) hours after becoming aware of a personal-data breach affecting Customer Content. Notification will be sent to the billing contact and, where configured, to a security-contact email address.

6.2 Contents of notification

The notification will include, to the extent known:

(a) the nature of the breach, categories and approximate number of data subjects and records concerned; (b) the likely consequences of the breach; (c) the measures taken or proposed to address the breach and mitigate its effects; (d) the name and contact details of a point of contact for further information.

Where the information cannot be provided at the same time, it will be provided in phases without further undue delay.

6.3 Cooperation

The Processor will cooperate reasonably with the Controller's own breach-response, including regulator inquiries and data-subject communications. The Processor does not assume the Controller's Article 33 notification obligations — those remain with the Controller.

7. Technical and organisational measures

The Processor implements the measures set out in Annex II — Technical and Organisational Measures. The Processor may update Annex II over time, provided the updated measures maintain at least the same level of protection. Material reductions in the level of protection require the Controller's prior written consent.

8. Audit rights

8.1 Controller audit

The Controller may audit the Processor's compliance with this DPA at most once per calendar year, with thirty (30) days' prior written notice. The audit must:

• be conducted during the Processor's normal business hours;
• be performed by the Controller's own personnel or a mutually acceptable independent third-party auditor bound by a non-disclosure agreement;
• not unreasonably interfere with the Processor's operations or the confidentiality of other Customers' data;
• respect any restrictions the Processor reasonably imposes to protect confidential information, sub-processor commitments, and security controls.

The Controller bears its own audit costs. Where the Processor reasonably incurs costs (for example, engineering time to retrieve evidence, host the auditor) the Processor may invoice its standard professional-services rate with advance written notice.

8.2 Certifications in lieu of audit

At the Processor's election, the Processor may satisfy an audit request by providing a current SOC 2 Type II report, ISO/IEC 27001 certificate, or equivalent third-party attestation covering the scope of the audit request. The Processor will provide such attestations where available.

8.3 Regulator audit

Nothing in this Section limits audits or inspections that a supervisory authority is legally entitled to conduct.

9. Return or deletion of data

On termination of the Agreement, and at the Controller's choice in writing, the Processor will either:

(a) return all personal data to the Controller in a structured, commonly-used, machine-readable format; or (b) delete all personal data.

In the absence of a choice within thirty (30) days of termination, the Processor defaults to deletion. Deletion and return are complete when the data has been removed from primary storage. The Processor's backups are purged on their standard rotation schedule, a process that may take up to one hundred and twenty (120) days after the deletion or return instruction.

Legally-required retention (for example, invoicing records under Bokföringslagen) is excluded from the deletion obligation for the minimum period required by law. Such records are held in Stripe and the Processor's bookkeeping software, not in the Processor's primary database.

10. International transfers

Where the Processor transfers personal data to a sub-processor located outside the EEA, the Processor will rely on one or more of the following transfer mechanisms:

(a) an adequacy decision of the European Commission; (b) Standard Contractual Clauses (Implementing Decision (EU) 2021/914) between the parties or their authorised intermediaries, as the case requires; (c) an approved code of conduct or certification mechanism.

The parties agree that, to the extent this DPA involves a transfer of personal data that requires SCCs under Article 46, the relevant SCC module is hereby incorporated by reference:

• Controller-to-Processor transfers: Module 2 of the SCCs.
• Processor-to-Processor transfers to our sub-processors: Module 3, with the Controller authorising the Processor to enter into Module-3 SCCs with each downstream sub-processor.

The dockable parts of the SCCs (clauses 7 (docking), 9 (sub-processor authorisation), 11 (redress), 13 (supervisory authority), 17 (governing law), 18 (forum and jurisdiction), and Annexes I–III) are deemed filled as described in Annex I — SCC filling.

Where a UK transfer is involved, the International Data Transfer Addendum issued by the UK Information Commissioner is incorporated by reference and the UK-issued version of Annex I applies.

Where a Swiss transfer is involved, the SCCs apply with the modifications set out in the Federal Data Protection and Information Commissioner's guidance of 27 August 2021 (reference to the Swiss FDPA, the Swiss FDPIC as supervisory authority, and Swiss-governing-law for claims by Swiss data subjects).

11. Liability and indemnity

Each party's liability under this DPA is subject to the aggregate liability cap and excluded-damages carve-outs set out in the Agreement (Terms Sections 8.1 and 8.2), except where applicable law prohibits such a cap (for example, GDPR Articles 82(4) and 82(5) in respect of joint-and-several liability to data subjects).

12. Term, survival, and order of precedence

This DPA takes effect on the effective date and remains in force for the duration of the Agreement and any post-termination retention period under Section 9. The following Sections survive termination: 5 (in respect of data-subject requests received before termination), 6 (in respect of breaches affecting data held during the Agreement), 8, 9, 10, and 11.

Order of precedence:

1. Applicable mandatory law.
2. This DPA (including the Annexes).
3. The Standard Contractual Clauses, where incorporated.
4. The Agreement.

Annex I — Filling of Standard Contractual Clauses

A. List of parties

Data exporter: the Controller identified on the Customer Account, at the address it provided at signup. Contact: the billing contact email. Role: controller.

Data importer: Keygum AB, registered office: Stockholm, Sweden. Contact: privacy@keygum.com. Role: processor.

B. Description of transfer

• Categories of data subjects: as set out in DPA Section 2.
• Categories of personal data: as set out in DPA Section 2.
• Special-category data: Keygum does not knowingly process special-category data; the Controller is responsible for excluding such data from Customer Content where its own lawful basis does not cover it.
• Frequency of transfer: continuous, for the duration of the Agreement.
• Nature of processing: collection, storage, structuring, transmission, consultation, and erasure of personal data; forwarding to the sub-processors listed in Annex III on Controller instruction.
• Purpose: enabling the Controller to publish and manage content across social-media Platforms through a unified API.
• Retention: as set out in DPA Section 9 and Privacy Notice Section 6.

C. Competent supervisory authority

Integritetsskyddsmyndigheten (IMY), Sweden.

Annex II — Technical and organisational measures

The Processor implements the following measures. Unless otherwise specified, each measure is current at the effective date of this DPA; the Processor may update measures over time, provided the level of protection is not materially reduced (see DPA Section 7).

Access control

• Named individual accounts for every Processor employee with access to production systems; no shared credentials.
• Multi-factor authentication required for every account with production access; passkey (WebAuthn) encouraged as the primary second factor.
• Role-based access control; access limited to the minimum needed for the individual's job role.
• Quarterly access review; access removed promptly on role change or departure.

Encryption

• TLS 1.3 in transit on all external connections; internal service-to-service traffic encrypted where it crosses a trust boundary.
• AES-256-GCM at rest for sensitive fields (OAuth tokens, internal secrets); per-field random IV; keys managed through server-side secrets injection and rotated at least annually.
• Database-disk-level encryption at the hosting-provider layer.

Network and infrastructure

• WAF and DDoS protection at the edge (Cloudflare).
• Least-privilege network segmentation between application tier and database tier; no direct internet exposure of database servers.
• Patch cadence: critical CVEs patched within 48 hours of a fix being available; high-severity CVEs within 7 days; others within the next release cycle.

Application security

• Dependency scanning on every pull request (pnpm audit); builds fail on HIGH-or-above findings.
• Secrets-leak scanning on every pull request (gitleaks); builds fail on any finding.
• Peer-review required on every change to the main branch.
• Zod schema validation on every trust-boundary crossing (API input, webhook payload, database read).
• Rate limiting and IP-based anti-abuse controls.

Logging and audit

• Structured logs scrubbed at the writer edge to redact credentials, session identifiers, API keys, payment data, and other sensitive fields.
• Audit-log entries for security-relevant events (sign-in, 2FA step-up, API-key creation and revocation, profile disconnect, billing changes).
• IP addresses and user-agent strings are salted-hashed before being written to the audit log; raw values are retained only in short-lived web-server access logs.

Backups and resilience

• Daily encrypted database backups; weekly full backups retained for 90 days.
• Backup-restoration drill at least annually.
• Documented incident-response runbook; tabletop exercises at least annually.

Personnel

• Confidentiality obligations in every employment and contractor agreement.
• Annual privacy and security training for every employee with production access.
• Background checks where permitted by local law for employees with production access.

Physical security

• Facilities managed by the hosting providers in Annex III. The Processor does not operate its own data centres.

Vendor management

• Sub-processor due-diligence review on engagement; annual review thereafter.
• Every sub-processor bound by a written DPA with obligations no less protective than this DPA.

Responsible disclosure

• security@keygum.com monitored for vulnerability reports.
• A published responsible-disclosure policy with a 90-day coordinated-disclosure window.

Annex III — Sub-processor list

The canonical list is maintained in @keygum/shared/legal's SUB_PROCESSORS export and mirrored in the public Privacy Notice. An addition or material change follows the notice-and-objection procedure in DPA Section 4.3.

Open items pending legal review

• Whether the general-authorisation model under Annex 4.1 needs a named-sub-processor-per-Controller option for enterprise customers.
• Whether Annex II's annual-audit frequency (Section 8.1) is aligned with the processing-scale threshold under Article 28(3)(h).
• Whether Module 3 SCC flow-down (Section 10) is correctly structured for each category of downstream sub-processor, especially the Platforms.
• Whether the Annex II TOMs are specific enough to survive an ICO or IMY inspection, and whether any measures should be promoted from "current state" to binding minimum.
• Whether the 120-day backup-purge window (Section 9) needs to be shortened or explicitly identified as a named exception under Article 17.

Keygum AB, Sweden — privacy@keygum.com