Data Processing Agreement

Version 1 · Effective from 2026-05-01

Current version

Summary: Initial publication.

DRAFT — for demo and vendor-risk-review purposes only. This document has not yet been reviewed by counsel. Final wording will be substituted before pilot launch. Do not rely on this draft for any binding commercial decision.

Data Processing Agreement

Effective from 1 May 2026 — Version 1

This Data Processing Agreement (the "DPA") governs the processing of personal data by Fintum Market Intelligence GmbH ("we", "Processor") on behalf of the customer entity that has accepted this DPA in the platform shell ("you", "Customer", or "Controller"). It forms an integral part of the Master Subscription Agreement between the parties (the "Agreement").

This DPA is concluded in accordance with Article 28 of the EU General Data Protection Regulation (GDPR) and is structured to align with Module 2 (controller-to-processor) of the EU Standard Contractual Clauses approved by Commission Implementing Decision 2021/914.

1. Parties

Controller: the customer entity identified in the platform shell at acceptance time. The Controller's full legal name, legal form, country, and registry identifier are recorded in the acceptance audit record.

Processor: Fintum Market Intelligence GmbH Abt-Plazidus-Str. 24 97359 Schwarzach am Main Germany Managing Director: David Siegl Registered: Amtsgericht Würzburg, HRB [[FILL: HRB-Nummer]] USt-IdNr.: [[FILL: USt-IdNr]] Data Protection Officer: dpo (at) fintum-mi.com

2. Subject matter and duration

The Processor processes personal data on behalf of the Controller solely for the purpose of providing the Service described in the Agreement (the Market Intelligence platform). This DPA remains in force for the same term as the Agreement and survives termination only to the extent strictly necessary for the deletion or return of personal data as set out in §13.

3. Nature and purpose of the processing

The Processor processes personal data to:

  • Authenticate the Controller's Authorized Users and maintain their sessions
  • Operate the dashboards, query interface, and Download Hub functionality the Controller has subscribed to
  • Apply the Controller's role-based access policies and audit user actions
  • Send transactional notifications to Authorized Users (invitations, security alerts, agreement acceptance confirmations)
  • Provide technical and customer support requested by the Controller's administrators
  • Maintain backups, secure-delete obsolete data, and respond to operational incidents

The Processor does not process personal data for any other purpose, and in particular does not use Controller personal data to train models, build derivative datasets, or enrich any profile outside the scope of the Agreement.

4. Categories of personal data

The Processor processes the following categories of Controller personal data:

  • Identity and contact: full name, work email address, role within the Controller's organisation, optional profile metadata (timezone, locale, language preference)
  • Authentication: salted password hash (where the Authorized User uses password authentication), MFA secrets (encrypted at rest), WebAuthn credentials, SSO subject identifier
  • Session and security: access timestamps, IP address, device fingerprint, user agent, geographic country derived from IP, audit-log entries of sensitive operations
  • Support correspondence: the contents of any message an Authorized User sends through a support channel and any attachments they include
  • Preferences and configuration: dashboard layouts, saved queries, notification toggles, billing contact

The Processor does not intentionally process special categories of personal data within the meaning of Article 9 GDPR. If such data appears in support correspondence or in user-generated content, the Processor handles it under the security safeguards in §8 and the deletion provisions in §13.

5. Categories of data subjects

The data subjects are the Controller's Authorized Users — the natural persons the Controller has authorised to access the Service through invitation, role assignment, or onboarding flow.

6. Documented instructions

The Processor processes personal data only on the Controller's documented instructions, including with regard to international transfers, unless the Processor is required by EU or Member State law to which it is subject to process the data otherwise. In the latter case, the Processor informs the Controller of that legal requirement before processing, unless the law prohibits such information on important grounds of public interest.

The Controller's documented instructions are constituted by:

  1. The Agreement and this DPA, including all Annexes
  2. The Controller's configuration of the Service through the platform's administrative interfaces (user invitations, role assignments, license allocations, data-scope settings, notification preferences)
  3. Specific written instructions communicated through privacy (at) fintum-mi.com or through the platform's support channel and acknowledged by the Processor

If the Processor believes that an instruction infringes the GDPR or other applicable data-protection law, it informs the Controller without delay.

7. Confidentiality

The Processor ensures that every person it authorises to process Controller personal data — employees, contractors, and the personnel of any subprocessor — has committed themselves to confidentiality, either contractually or under a statutory obligation of confidence, and is bound by that obligation for the duration of the engagement and after its termination.

8. Security of processing (Art. 32 GDPR)

The Processor implements appropriate technical and organisational measures to ensure a level of security appropriate to the risk of the processing. These measures are described in Annex II and include, at minimum:

  • Encryption of personal data at rest using AES-256 with AWS KMS-managed keys, and in transit using TLS 1.2 or higher with modern cipher suites
  • Strict role-based access control with least-privilege defaults; multi-factor authentication required for any administrative access
  • An append-only audit log capturing every administrative action and every access to Customer personal data, with cryptographic immutability enforced at the database level
  • Tested backups with point-in-time recovery
  • Documented vulnerability-management programme with regular dependency scanning and a quarterly penetration-testing cadence
  • A documented incident-response plan including 72-hour breach-notification escalation
  • Regular security training for personnel; annual review of all access grants

The Processor reviews these measures periodically and updates them in light of the state of the art, the costs of implementation, and the nature of the processing.

9. Personal data breach notification

The Processor notifies the Controller without undue delay, and in any event within 72 hours, after becoming aware of a personal data breach affecting Controller personal data. The notice describes:

  • The nature of the breach including, where possible, the categories and approximate number of data subjects and personal data records concerned
  • The likely consequences of the breach
  • The measures taken or proposed by the Processor to address the breach and to mitigate its possible adverse effects
  • The contact point through which more information can be obtained

The Processor cooperates with the Controller in fulfilling the Controller's own notification obligations under Articles 33 and 34 GDPR.

10. Assistance to the Controller

Taking into account the nature of the processing and the information available to it, the Processor assists the Controller in:

  • Responding to requests from data subjects exercising their rights under Articles 15 to 22 GDPR (§11 below describes the dedicated channel)
  • Ensuring compliance with the security obligation in Article 32 GDPR
  • Notifying personal data breaches under Articles 33 and 34 GDPR
  • Carrying out data-protection impact assessments under Article 35 GDPR
  • Conducting prior consultations with the supervisory authority under Article 36 GDPR

11. Data subject requests

The Processor passes on to the Controller, without undue delay, any request from a data subject that the Processor receives directly. The Processor does not respond to such a request itself unless the Controller has expressly authorised that response.

The Controller can self-serve common Article 15 / 16 / 17 requests through the platform's administrative interfaces (user data export, user data deletion). For cases that require Processor assistance, the Controller contacts privacy (at) fintum-mi.com; the Processor responds within five business days with a feasibility assessment and a target completion date.

12. Subprocessors (Art. 28 (2) and (4) GDPR)

The Controller grants the Processor general written authorisation to engage subprocessors, subject to the conditions of this section.

The list of authorised subprocessors at any given time is published at /legal/subprocessors/v1. The Processor maintains the same Article 28 obligations toward each subprocessor that this DPA imposes on the Processor itself.

The Processor notifies the Controller of any addition or replacement of a subprocessor at least 30 calendar days in advance through:

  • An updated version of the Subprocessor list at its permanent URL
  • An email to the Controller's primary administrative contact
  • An in-platform banner visible to every Company Admin of the affected Controller

The Controller may object on legitimate data-protection grounds within the 30-day notice period by writing to privacy (at) fintum-mi.com. The parties engage in good-faith discussion to resolve the objection. If no resolution is reached, the Controller may terminate the affected portion of the Service without penalty under the Agreement.

If no objection is received during the notice period, the Controller is treated as having approved the change as of the effective date.

13. Return or deletion of personal data

Upon termination of the Agreement, and at the Controller's choice, the Processor either:

  • Returns all Controller personal data to the Controller in a structured, commonly used, machine-readable format within 30 calendar days, then deletes existing copies (subject to §13.2 below); or
  • Deletes all Controller personal data within 30 calendar days.

Deletion is effected through cryptographic erasure of the database storage and overwrite of any cached copies. The Processor confirms the deletion in writing.

13.1

The 30-day window begins on the later of (i) the effective termination date of the Agreement and (ii) the date on which the Controller communicates its choice between return and deletion. If the Controller does not communicate a choice within 30 days of termination, the Processor proceeds with deletion.

13.2

The Processor retains personal data only insofar as Union or Member State law to which it is subject requires storage of the data, in particular under § 257 HGB (10-year retention of commercial documents) and § 147 AO (tax retention). For data retained under such an obligation, the Processor:

  • Restricts processing strictly to what the legal obligation requires
  • Continues to apply the security safeguards in §8
  • Deletes the data without further request once the retention period expires

13.3

Audit-log entries that reference Controller personal data are retained for 10 years from the event date in line with §13.2. Their immutability is preserved by the security controls in Annex II.

14. Audits and inspections

The Processor demonstrates compliance with the obligations laid down in this DPA by:

  • Making available to the Controller all information necessary to demonstrate compliance with Article 28 GDPR
  • Allowing for and contributing to audits, including inspections, conducted by the Controller or another auditor mandated by the Controller, at the Controller's cost and on at least 30 days written notice, no more often than once per 12 months unless required by a supervisory authority

The Processor may satisfy the audit obligation by providing current third-party audit reports — currently a SOC 2 Type II report and an ISO 27001 certificate maintained by [[FILL: assessor name]] — alongside the relevant policy documentation. A Controller that requires a more invasive audit may conduct one at its own cost subject to coordination on scope, timing, and the protection of other customers' data.

15. International transfers

For each subprocessor named in /legal/subprocessors/v1 the processing location and the applicable transfer mechanism are documented in that list. As of the effective date of this version, every subprocessor processes Controller personal data exclusively within the European Union and no third-country transfer mechanism is required.

If the Processor needs to engage a subprocessor outside the European Economic Area in the future, or to relocate processing of an existing subprocessor outside the EEA, the change follows the procedure in §12 and is supported by an appropriate transfer mechanism under Chapter V of the GDPR (typically the EU Standard Contractual Clauses 2021/914 supplemented by appropriate technical and organisational measures).

16. Liability

The liability of the parties under this DPA is governed by the limitation-of-liability clause of the Agreement, except that no contractual cap applies to liability that cannot lawfully be limited — including, but not limited to, claims arising from breach of confidentiality, gross negligence or intent, and any liability that under § 309 or § 444 of the German Civil Code (BGB) cannot be limited.

17. Order of precedence

In the event of any conflict between this DPA, the Agreement, and any individually-signed addendum or order form, precedence is determined as follows, with the most specific document prevailing:

  1. An individually-signed amendment to this DPA referencing the conflicting provision by section number
  2. This DPA
  3. The Master Subscription Agreement
  4. Any other ancillary document

18. Governing law and jurisdiction

This DPA is governed by the laws of the Federal Republic of Germany, excluding the United Nations Convention on Contracts for the International Sale of Goods. The exclusive place of jurisdiction for any dispute arising out of or in connection with this DPA is Frankfurt am Main.

19. Term and termination

This DPA enters into force on the date the Controller accepts it through the platform shell and remains in force for the duration of the Agreement. Termination of this DPA without simultaneous termination of the Agreement is not possible — the protections in this DPA are tied to the underlying Service relationship.

---

Annex I — Description of the Processing

FieldValue
Categories of data subjectsThe Controller's Authorized Users (employees, contractors, and other natural persons the Controller has authorised to access the Service)
Categories of personal dataAs listed in §4 of this DPA
Special categoriesNone intentionally processed
Frequency of the processingContinuous, for the duration of the Agreement
Nature of the processingAuthentication, session management, dashboard delivery, query handling, audit, transactional email, support correspondence, backup, deletion
Purpose of the processingPerformance of the Master Subscription Agreement
Duration of the processingTerm of the Agreement plus the deletion / retention windows in §13
Controller contactThe Controller's primary administrative contact registered in the platform
Processor contact{{email:privacyfintum-mi.comprivacy (at) fintum-mi.com}}; DPO at {{email:dpofintum-mi.comdpo (at) fintum-mi.com}}

Annex II — Technical and Organisational Measures

A. Pseudonymisation and encryption

  • Personal data at rest is encrypted using AES-256 with AWS KMS-managed keys; key material is never exported from the KMS service.
  • Personal data in transit is protected by TLS 1.2 or higher with modern cipher suites (no SSL, no TLS 1.0/1.1, no export-grade cryptography).
  • Authentication secrets (password hashes, MFA secrets, WebAuthn credentials) are encrypted with a separate per-deployment key tied to the application's `MFA_ENCRYPTION_KEY` rotation schedule.
  • Pseudonymisation is applied wherever it is technically feasible without impairing the Service — most notably to research and analytics queries that aggregate over user behaviour, where individual identifiers are stripped before aggregation.

B. Confidentiality, integrity, availability, resilience

  • Confidentiality: Role-based access control with least-privilege defaults; production access requires multi-factor authentication and is logged in the immutable audit log; office and remote-work endpoints are managed through a centrally-administered MDM with full-disk encryption.
  • Integrity: Append-only audit log with database-level immutability triggers; database row-level checksums on all tables containing personal data; periodic integrity verification on backups.
  • Availability: Multi-AZ deployment in `eu-central-1`; automated failover; tested point-in-time recovery; documented Disaster Recovery procedure with quarterly drills.
  • Resilience: Capacity headroom maintained for traffic spikes; rate limits enforced at the edge to absorb credential-stuffing and DDoS volumes; circuit breakers around external dependencies.

C. Restoration of availability and access

  • Continuous database backups with point-in-time recovery for the most recent 35 days.
  • Daily snapshot retention for 90 days; weekly snapshots for 12 months.
  • Documented runbooks for the most likely failure modes; cross-trained on-call rotation; incident-response post-mortems published internally.

D. Process for regularly testing, assessing, and evaluating

  • Annual external penetration test by an independent assessor.
  • Quarterly internal vulnerability scans of the application and the underlying infrastructure.
  • Continuous static application security testing (SAST) and software-composition analysis (SCA) on every commit.
  • Annual SOC 2 Type II audit; annual ISO 27001 surveillance audit; certificates available on request.
  • Annual review of these technical and organisational measures by the Data Protection Officer.

E. User identification and authorisation

  • Unique account per Authorized User; no shared accounts.
  • Multi-factor authentication required for all administrative roles; supported for end users.
  • Risk-based authentication step-up on new device or new geographic country.
  • Centralised role-based access control with quarterly access reviews.

F. Data minimisation

  • The platform collects only the personal data necessary to deliver the Service. Optional profile fields are exactly that — optional — and are not used to gate functionality.
  • Logs and audit entries record only the minimum metadata needed for security and compliance; bodies of payloads are not logged unless an audit-categorised action specifically requires it.

G. Subprocessor management

The current list of subprocessors and the management procedure (§12 of this DPA) are published at /legal/subprocessors/v1.

Annex III — List of Subprocessors

The list of subprocessors authorised under §12 of this DPA is the document at /legal/subprocessors/v1. That URL is the single source of truth and is updated through the change-notification flow described in §12.