DATA PROCESSING AGREEMENT

This Data Processing Agreement (the “DPA”) forms part of and is incorporated by reference into the Main Agreement between Flip GmbH (the “Provider”) and the customer identified in the applicable Order Form (the “Customer”). It applies to all Processing of Personal Data carried out by the Provider on behalf of the Customer in connection with the Software Service, irrespective of the Customer’s place of establishment. A single instrument applies to all jurisdictions; jurisdiction-specific requirements take effect through the modular Sections 10 to 12 and the Annexes, which apply only to the extent the relevant law governs a given Processing or transfer.

1.  Subject matter, roles of the parties

1.1  Roles. In respect of the Personal Data Processed by the Provider on behalf of the Customer under the Main Agreement, the Customer is the controller (the “Controller”; under U.S. State Privacy Laws, the “business”) and the Provider is the processor (the “Processor”; under U.S. State Privacy Laws, the “service provider”). Where the Customer itself acts as a processor for a third party, the Provider acts as sub-processor and this DPA applies mutatis mutandis.

1.2  Precedence. This DPA supplements the Main Agreement. In the event of a conflict between this DPA and the other components of the Main Agreement in matters of data protection, this DPA prevails; the Standard Contractual Clauses, the UK Addendum and the Swiss adaptations (Section 10) prevail over this DPA in respect of the transfers they govern. The order of precedence in Section 18.1 of the Terms otherwise applies. The DPA cannot be terminated separately from the Main Agreement.

1.3  Affiliates. Where the Customer permits affiliates to use the Software Service under the Main Agreement, this DPA applies to each such affiliate, which is the Controller for its own Personal Data; the Customer procures that the necessary data-protection arrangements with the affiliate are in place before Processing begins.

2.  Applicable Data Protection Law

“Applicable Data Protection Law” means all data protection and privacy laws applicable to the Processing under this DPA, including as applicable: (a) the EU General Data Protection Regulation (Regulation (EU) 2016/679, “EU GDPR”) and EU/EEA member-state implementing laws; (b) the UK GDPR and the Data Protection Act 2018 (“UK GDPR”); (c) the Swiss Federal Act on Data Protection (“FADP”); and (d) U.S. State Privacy Laws, meaning the California Consumer Privacy Act as amended by the CPRA (“CCPA/CPRA”), the Virginia VCDPA, the Colorado CPA, the Connecticut CTDPA, the Utah UCPA, the Texas TDPSA and any comparable U.S. state privacy law now or hereafter in force; and (e) the EU-U.S. Data Privacy Framework, its UK Extension and the Swiss-U.S. Data Privacy Framework (together, the “DPF”). The substantive obligations of this DPA apply under each of these laws to the extent that law governs the relevant Processing.

3.  Scope of processing; instructions

3.1  Documented instructions. The Provider Processes Personal Data only on the documented instructions of the Controller, unless required to do so by Union, member-state or other applicable law to which the Provider is subject; in that case the Provider informs the Controller of that requirement before Processing, unless the law prohibits it on important grounds of public interest. The Main Agreement (including this DPA, the Service Description and the Order Form) constitutes the Controller’s complete initial instructions. The subject matter, duration, nature and purpose of the Processing, the types of Personal Data and the categories of data subjects are set out in Annex 1. Individual instructions of the Controller that modify or extend the scope of services agreed in the Main Agreement require the Provider’s prior consent; instructions the Provider is required to follow under Applicable Data Protection Law remain unaffected.

3.2  Unlawful instructions. The Provider informs the Controller without undue delay if, in its opinion, an instruction infringes Applicable Data Protection Law, and may suspend execution of that instruction until the Controller confirms it, to the extent required by law. The assessment of whether the Processing is lawful rests with the Controller and is binding on the Provider; the Provider’s review and notification duty under sentence 1 and its obligations under the second subparagraph of Art. 28(3) GDPR remain unaffected.

3.3  Place of processing. The Provider Processes Personal Data within the European Union / EEA. Processing outside the EEA takes place only in compliance with Section 10. The Provider hosts the Software Service in a data centre in Europe by default. A different hosting region is provided only at the Controller’s request and under a separate individual agreement between the parties. In that case Section 10 applies to the resulting transfer. By way of derogation from sentence 1, the following applies to the optional web and image search in Flip Fusion: search terms derived from the inputs are transmitted to external search and image services which, in that respect, do not act as the Provider’s sub-processors but as independent controllers under their own terms and may Process those search terms outside the EU/EEA; the Provider does not furnish a transfer mechanism under Section 10 for that transmission. These features are not intended for the entry of Personal Data; the Controller ensures that its users do not enter Personal Data when using them and may have the features disabled at tenant level. Also by way of derogation from sentence 1, the following applies to the SCORM import function of the gyde (Flip Learning) module, to the voice, video and live-streaming functions of the Flip platform and to the source-code repository referred to in Annex 2 (Flip Fusion): these features are provided via sub-processors that also Process Personal Data outside the European Union or the EEA (Annex 3); the transfer is governed by Section 10. The Controller may have the above features, other than the source-code repository, disabled on request; where they are not activated, no processing takes place via them. The source-code repository is functionally required in order to generate apps; it is used only where the Controller has activated Flip Fusion. Voice notes are not covered by this; they are processed by the Provider itself within the European Union.

3.4  Provider’s own processing. Usage Data and account data that the Provider Processes as an independent controller for the operation, security and improvement of the Services (as described in the Terms and the Provider’s privacy policy) fall outside the commissioned Processing under this DPA; the Provider does not use the Customer’s Personal Data to train, fine-tune or improve AI models except as separately agreed. Any use of anonymised data is governed by Section 9.4 of the Terms.

3.5  No AI/ML training on Customer Personal Data. The Provider does not use Customer Personal Data — including prompts, inputs and outputs Processed via the Flip Fusion or gyde Modules — to train, retrain, fine-tune or otherwise develop AI or machine-learning models, and it contracts with its LLM and AI sub-processors on terms that likewise prohibit any use of the inputs and outputs to train their models. The Provider may Process anonymised or aggregated data that does not identify any data subject for statistics, security, operation, error analysis, capacity planning and the improvement and further development of the Services in accordance with Section 9.4 of the Terms; any use of such data to train AI models requires a separate agreement.

3.6  Customer input restrictions. The Controller is responsible for the Personal Data it or its Authorized Users submit to the Services, in particular via free-text prompts in AI-enabled Modules. The Controller shall not submit special categories of Personal Data (Art. 9 GDPR), data relating to criminal convictions and offences (Art. 10 GDPR), payment-card or financial-account numbers, government identifiers, or health data, unless expressly agreed in writing and subject to appropriate safeguards. Where special categories of Personal Data, or data relating to criminal offences or suspected criminal offences (Art. 10 GDPR), are nevertheless submitted in customer content, free-text inputs, incident and reporting flows (Flip Flows) or reference images uploaded in accordance with Annex 1 (Flip Fusion), the Provider Processes them solely on the documented instructions of the Controller and with appropriate safeguards; responsibility for a legal basis and, where applicable, for an exception under Art. 9(2) GDPR as well as for permissibility under Art. 10 GDPR rests with the Controller. This allocation of responsibility does not diminish the Provider’s security obligations under Section 4.

3.7  Error analysis, hardening and quality assurance. The Controller instructs the Provider to Process Personal Data in pseudonymised form also for the purposes of error analysis and remediation, hardening against misuse and attack, and quality assurance of the Services provided to the Controller. That Processing takes place within the commissioned Processing under this DPA and is limited to (a) a narrowly defined, documented group of authorised personnel, (b) separate and secured storage of the attribution data, (c) a prohibition on re-identification, (d) the exclusion of any use to train, fine-tune or develop AI or machine-learning models (Section 3.5), and (e) deletion or anonymisation once the purpose has been achieved and in any event no later than twelve months after collection. Any Processing beyond this for the development or improvement of the Provider’s products for other customers takes place solely on the basis of anonymised data under Section 3.4 of this DPA in conjunction with Section 9.4 of the Terms.

4.  Confidentiality and security of processing

4.1  Confidentiality. The Provider grants access to Personal Data only to personnel and sub-processors bound by confidentiality obligations or under an appropriate statutory duty of confidentiality, and only to the extent necessary for the Services.

4.2  Technical and organisational measures. The Provider implements and maintains the technical and organisational measures set out in Annex 2 in accordance with Art. 32 GDPR (and the equivalent standards under the UK GDPR, the FADP and U.S. State Privacy Laws). The Provider may modify these measures during the term provided the level of protection is not reduced below that agreed. Further information is available in the Provider’s Trust Center at https://trust.getflip.com/.

5.  Sub-processors

5.1  General authorisation. The Controller grants the Provider general authorisation to engage sub-processors. The sub-processors engaged at the time of conclusion are listed in Annex 3, maintained as a living list in the Trust Center.

5.2  Flow-down. The Provider imposes on each sub-processor, by written contract, data-protection obligations materially equivalent to those in this DPA, in particular sufficient guarantees as to appropriate technical and organisational measures. The Provider remains fully responsible to the Controller for the performance of each sub-processor’s obligations.

5.3  Changes and objection. The Provider notifies the Controller at least 45 days in advance, in text form (e.g. by email) to the contact address nominated by the Controller for that purpose, of the intended addition or replacement of a sub-processor, and additionally makes a notification service available in the Trust Center. The notice identifies the sub-processor, the purpose of Processing, the location of Processing and the categories of data concerned, and gives the Controller the opportunity to object on reasonable grounds relating to data protection. If the Controller does not object within 30 days of the notice, the change is deemed approved. If the Controller objects on reasonable grounds and the parties cannot resolve the matter, either party may terminate the affected part of the Services on three months’ notice, and the Provider refunds prepaid fees on a pro-rata basis.

5.4  Scope of disclosure; ancillary services. Disclosure under Sections 5.1 and 5.3 follows these tiers: (a) the Provider’s direct sub-processors are always listed by name in the list referred to in Annex 3. (b) For further sub-processors engaged by a sub-processor of the Provider, the following applies: the list referred to in Annex 3 states whether and to what extent Processing takes place outside the EU/EEA. The Provider shall inform the Controller on request of the identity of those further sub-processors, the purpose of Processing, the place of Processing and the categories of data concerned; in line with Guidelines 07/2020 of the European Data Protection Board, the Provider ensures that it holds this information for the entire Processing chain and that the obligations of this DPA are passed down the chain by contract. The right to object under Section 5.3 applies accordingly to changes anywhere in the chain. (c) Otherwise, a reference to the list published by the relevant sub-processor suffices; the Provider ensures by contract that changes are notified to it so that it can pass them on under Section 5.3. Purely ancillary services without a specific connection to the provision of the Services do not constitute sub-processing; this applies in particular to telecommunications, postal, transport and maintenance services and to any other service without access to Personal Data. Irrespective of tiers (a) to (c), the Provider shall, on request, inform the Controller of the complete Processing chain, including the name, address and contact person of the sub-processors involved and a description of the respective Processing.

6.  Assistance with data-subject rights and Controller obligations

6.1  Data-subject requests. Taking into account the nature of the Processing, the Provider assists the Controller by appropriate technical and organisational measures, insofar as possible, in fulfilling the Controller’s obligation to respond to requests to exercise data-subject rights. If a data subject contacts the Provider directly, the Provider forwards the request to the Controller without undue delay and does not respond itself unless authorised.

6.2  Art. 32–36 assistance. The Provider assists the Controller in ensuring compliance with the obligations under Art. 32 to 36 GDPR (security, breach notification, data-protection impact assessments and prior consultation) and the equivalent obligations under the other Applicable Data Protection Laws, taking into account the nature of the Processing and the information available to the Provider. Assistance reasonably necessary for the Controller to meet its statutory obligations is included; assistance that materially exceeds the Provider’s ordinary processes (for example bespoke DPIA support or handling an unusual volume of individual requests) may be provided against reasonable, documented cost, to the extent charging is permitted by Applicable Data Protection Law.

6.3  Regulatory inspections. Where a party is required by law to provide information in connection with the Processing under this DPA or otherwise to cooperate with a supervisory authority or other public authority, the parties will, to the extent legally permitted, (a) support one another and (b) inform one another without undue delay of inspections by a supervisory authority or other official measures insofar as these relate to the Processing under this DPA. Section 10.4 remains unaffected.

7.  Personal data breach

7.1  Notification. The Provider notifies the Controller without undue delay after becoming aware of a personal data breach affecting the Controller’s Personal Data and provides the information reasonably available to enable the Controller to meet its own notification obligations, supplementing that information as it becomes available. The notification includes, to the extent available, the information listed in Art. 33(3) GDPR. The Provider assists the Controller in containing and investigating the incident and in communicating with supervisory authorities and data subjects; it does not make notifications under Art. 33 or Art. 34 GDPR on the Controller’s behalf without the Controller’s instruction. A personal data breach does not include unsuccessful attempts or activities that do not compromise the security of Personal Data (such as failed log-ins, pings, port scans or denial-of-service attempts).

8.  Return and deletion

8.1  Deletion. On termination or expiry of the Main Agreement, and unless storage is required by law, the Provider deletes or anonymises the Personal Data Processed on behalf of the Controller. The Controller may export its data during the term and within the retrieval period and switching-assistance period provided for in the Main Agreement, and may request a copy at any time up to the end of those periods; deletion takes place without undue delay after those periods expire, unless the relevant Service Description specifies a longer maximum period for individual data categories. Such maximum periods are stated exhaustively in the Service Description, prevail over this Section and do not exceed six months from the end of the Main Agreement. The Provider provides evidence of deletion on request. Copies contained in routine backups are overwritten in accordance with the backup periods stated in the relevant Service Description; until overwritten they are blocked against random access and remain subject to the obligations of this DPA; documentation evidencing lawful Processing may be retained.

9.  Audits and evidence of compliance

9.1  Evidence. The Provider makes available to the Controller the information necessary to demonstrate compliance with Art. 28 GDPR (and the equivalent provisions of the other Applicable Data Protection Laws), including, where available, its ISO/IEC 27001 certification and SOC 2 reports via the Trust Center.

9.2  Inspections. The Controller may conduct one audit per contract year and, in addition, an audit following a personal data breach or at the request of a competent supervisory authority. For that purpose the Controller (or an independent auditor it appoints, who must not be a competitor of the Provider and must be bound by confidentiality) may conduct an audit during the Provider’s regular business hours, on reasonable prior notice (as a rule at least two weeks), without disrupting operations and preserving the confidentiality of the Provider’s and other customers’ data. The Provider need not disclose information relating to other customers or trade secrets not directly relevant to the audit. The Provider may satisfy an audit in whole or in part by producing current certifications and audit reports under Section 9.1 to the extent these cover the subject matter of the audit; the Controller decides on this acting reasonably. Audits going beyond the above scope are carried out against reimbursement of the Provider’s reasonable, documented cost.

10.  International transfers (modular)

This Section applies only to the extent Personal Data protected by the EU GDPR, the UK GDPR or the FADP is transferred to, or accessed from, a country not recognised as providing an adequate level of protection. The applicable module is deemed entered into and incorporated by reference and is completed by Annex 4; where more than one mechanism could apply, a single mechanism applies in the order DPF (where the importer is certified) → EU SCCs → UK Addendum → Swiss adaptations for the respective data.

10.0  Data Privacy Framework (primary, where available)

Where Personal Data is transferred to a sub-processor in the United States that is self-certified under the DPF for the relevant category of data, that transfer is made in reliance on the DPF, with the mechanisms in Sections 10.1 to 10.3 applying as a fallback should the DPF cease to provide a valid basis. Where a sub-processor Processes Personal Data exclusively within the EU/EEA, there is no transfer within the meaning of this Section 10; it does apply, however, where the sub-processor or an affiliate of it can access Personal Data from a third country. The list referred to in Annex 3 states which sub-processors Process outside the EU/EEA or may access Personal Data from there.

10.1  EU/EEA — Standard Contractual Clauses

For transfers of Personal Data subject to the EU GDPR to the Provider from a third country, and for transfers from the EEA to the Provider where the Provider exceptionally Processes outside the EEA, the EU Standard Contractual Clauses (Commission Implementing Decision (EU) 2021/914, the “EU SCCs”) are incorporated and completed as set out in Annex 4, with Module Two (Controller-to-Processor) applying to the commissioned Processing, Module Three (Processor-to-Processor) applying where the Customer is itself a processor, and Module One (Controller-to-Controller) applying to the Provider’s independent-controller Processing under Section 3.4. Clause 17: the EU SCCs are governed by the law of Germany. Clause 18(b): the courts of Germany. The docking clause (Clause 7) applies. For transfers by the Provider to sub-processors in third countries, the Provider enters into the EU SCCs (Module Three) directly with the relevant sub-processor; the Controller authorises and instructs the Provider to do so. Annex 4 applies to those transfers mutatis mutandis.

10.2  United Kingdom — UK Addendum / IDTA

For transfers of Personal Data subject to the UK GDPR, the parties enter into the International Data Transfer Addendum to the EU SCCs issued by the UK Information Commissioner (Version B1.0, in force 21 March 2022, the “UK Addendum”), which is incorporated and completed as set out in Annex 4 and appends to the EU SCCs in Section 10.1. Alternatively, where the parties so agree in Annex 4, the Information Commissioner’s International Data Transfer Agreement (IDTA) applies in place of the UK Addendum.

10.3  Switzerland — FADP adaptations

For transfers of Personal Data subject to the FADP, the EU SCCs apply with the adaptations set out in Annex 4: the Swiss Federal Data Protection and Information Commissioner (FDPIC) is the competent supervisory authority for Swiss transfers; references to the GDPR are understood as references to the FADP; and the SCCs protect the data of legal entities and of natural persons until the revised FADP is fully in force.

10.4  Government and law-enforcement access (supplementary measures)

The Provider has not created, and is under no obligation to create, any back door or similar means of access to Personal Data for any public authority. If the Provider or a sub-processor receives a legally binding request from a public authority (including under U.S. FISA §702, Executive Order 12333 or the CLOUD Act) to disclose Personal Data Processed under this DPA, the Provider shall, unless legally prohibited: (a) notify the Controller without undue delay and, where possible, before disclosure; (b) inform the authority that it acts as a processor on the Controller’s behalf and, where lawful, redirect the request to the Controller; (c) review the request’s legality and challenge it where it is unlawful, overbroad or fails to observe due process, pursuing available appeals; and (d) disclose only the minimum Personal Data legally required. Where prohibited from notifying, the Provider shall make lawful efforts to obtain a waiver and shall document its legal assessment for the Controller. The Provider records the binding access requests it receives and makes summary transparency information available on request, and it imposes materially equivalent obligations on sub-processors that Process Personal Data outside the EEA.

10.5  Transfer impact assessments

The Provider supports the Controller’s transfer impact assessments in line with EDPB Recommendations 01/2020 by providing information on the Services, the sub-processors, the location of Processing and the technical, contractual and organisational supplementary measures (including encryption in transit and at rest, access controls and the measures in Annex 2), together with the Provider’s experience of government access requests. To the extent the Provider Processes Personal Data within the EU/EEA, EU/EEA Controllers require no transfer impact assessment for the Provider’s Processing; for the features referred to in Section 3.3 that involve Processing outside the EEA, the Provider provides the information under sentence 1; for UK and Swiss Controllers the assessment concerns the export from the United Kingdom or Switzerland to the Provider in the EU.

10.6  Fallback

If a transfer mechanism relied upon under this Section is invalidated, suspended or enjoined, the parties shall cooperate in good faith to implement an alternative lawful mechanism without undue delay; pending that, the Provider may suspend the affected transfers and related Processing without thereby being in breach of the Main Agreement.

11.  United States State Privacy Laws (module)

11.1  Roles. To the extent a U.S. State Privacy Law applies to the Customer’s use of the Software Service, the Customer is the “business”/“controller” and the Provider is the “service provider”/“processor” with respect to the Personal Data (“personal information”) contained in Customer Content. Terms such as “business”, “service provider”, “sell” and “share” have the meanings given in the CCPA/CPRA (Cal. Civ. Code § 1798.140) and the equivalent terms in the other U.S. State Privacy Laws.

11.2  Restricted purpose. The Provider Processes such personal information only to provide the Services under the Main Agreement and for the business purposes specified therein, on the Customer’s documented instructions, and not for any other purpose.

11.3  No sale / no share. The Provider does not sell and does not share Customer Content or any personal information contained in it within the meaning of the U.S. State Privacy Laws, does not retain, use or disclose it for cross-context behavioural or targeted advertising, for its own commercial purposes unrelated to the Services, or outside the direct business relationship with the Customer, and does not combine it with personal information from other sources, in each case except as those laws permit.

11.4  Assistance, sub-processors, oversight. The Provider notifies the Customer if it can no longer meet these obligations, assists the Customer with consumer-rights requests, imposes materially equivalent obligations on its sub-processors, and grants the Customer the right to take reasonable steps to ensure the Provider’s use is consistent with the Customer’s obligations and to stop and remediate unauthorised use. Where this DPA and this Section both apply, the standard affording the higher level of protection prevails.

12.  Liability, governing law and final provisions

12.1  Liability. Liability under this DPA is subject to the limitations and exclusions in Section 15 of the Terms (including the 200 % aggregate cap for breaches of data-protection obligations and the carve-out preserving data subjects’ statutory claims under Art. 82 GDPR). Claims against the Provider under this DPA may be brought only by the Customer that is party to the Main Agreement; nothing in this DPA restricts the rights of a data subject or a supervisory authority.

12.2  Governing law. This DPA is governed by the law that governs the Main Agreement to which it is attached — German law, the law of England and Wales, or the law of the State of New York, as applicable — except that the mandatory governing law of the EU SCCs (Germany), the UK Addendum (the laws of England and Wales) and the Swiss adaptations applies to those instruments and to disputes concerning the transfers they govern.

12.3  Incorporation. This DPA is the data processing agreement referred to in the data-protection section (Section 11) of the Provider’s English-language General Terms and Conditions (EU, UK and US). It is published for customers established in the European Union or the EEA outside Germany at https://www.getflip.com/legal/dpa-eu/, for customers established in the United States at https://www.getflip.com/legal/dpa-us/, and for customers established in the United Kingdom or in other countries outside the European Union and the EEA at https://www.getflip.com/legal/dpa-uk/. All versions are identical in content; the applicable module (EU, UK, Switzerland or US) is determined in accordance with Section 2. The German-language version of equivalent content, which applies to the Provider’s German General Terms and Conditions, is published at https://www.getflip.com/de/legal/avv/. Where a separately published module DPA contains diverging provisions, this DPA prevails unless the module DPA affords a higher level of protection. The Annexes form an integral part of this DPA.

12.4  Data Protection Officer. The Provider’s Data Protection Officer can be reached at: Data Protection Officer, Flip GmbH, Rotebühlstraße 50, 70178 Stuttgart, Germany, datenschutz@getflip.com.

12.5 Amendments to this DPA. Amendments to this DPA require agreement of the parties in text form (e.g. by email). By way of exception, the Provider may amend this DPA unilaterally where necessary to implement mandatory legal requirements, to comply with a decision of a supervisory authority or a court, or to replace a transfer mechanism that has been invalidated, provided the agreed level of protection is not reduced; the Provider notifies the Controller thereof without undue delay in text form (e.g. by email). In all other respects Section 17 of the Terms applies mutatis mutandis.

Annex 1 — Details of Processing

Subject matter and duration

The subject matter and duration of the Processing are determined by the Main Agreement. For the provision of the Flip Software Service as software-as-a-service, the Provider is granted access to the Controller’s Personal Data to the limited extent necessary, in particular: receipt and Processing of user master data (title, first name, last name, business email address); creation and maintenance of the user list, set-up of users, roles and permissions and creation of access information; operation of the communication and collaboration functions of the Platform, including newsfeed, chats, tasks and forms, and Processing of the content generated by users in the course of that use; operation of the Modules booked, as set out in the table below (Flip Flows, Frontline Identity, Flip Fusion, gyde/Flip Learning); provision of support and maintenance services including remote diagnosis; deletion of users and data on request; and hosting and back-up of the system. The scope of Processing is determined conclusively by the Main Agreement, the Order Form and the Service Description.

Purpose

Processing of Personal Data of the Controller’s personnel and other Authorized Users for the purpose of providing the Flip Software Service in accordance with the Main Agreement, including any Modules booked (Flip Platform, Flip Flows, Frontline Identity, Flip Fusion, gyde/Flip Learning).

Module-specific processing

The following table reflects the additional Processing introduced by individual Modules; it is supplemented by the applicable Service Description. Any deviation from this Annex requires agreement of the parties under Section 12.5.

Types of Personal Data

Categories of data subjects: employees and other Authorized Users of the Controller (and, where applicable, persons specially connected to the Controller, e.g. applicants, alumni, temporary agency workers and engaged external service providers), as well as external participants in and registrants for seminars, sessions and learning offerings (gyde/Flip Learning).

Special categories of data: not the subject of the commissioned Processing; in accordance with Section 3.6 the Controller shall not submit special-category, criminal-offence, health, financial-account or government-identifier data except as expressly agreed and safeguarded. Where such data is nevertheless contained in customer content, free-text inputs, incident and reporting flows (Flip Flows) or uploaded reference images (Flip Fusion), the Provider Processes it solely in accordance with Section 3.6. Biometric confirmation used for passkey login (Frontline Identity) is performed on the end device and is not transmitted to or Processed by the Provider, and therefore does not constitute Processing of special-category data by the Provider.

Annex 2 — Technical and organisational measures (Art. 32 GDPR)

Confidentiality — access & admittance

• Regular employee training (at least annually) on information security and handling of customer personal data

• At the Provider's Stuttgart headquarters: access-control system with badge scanner; key management; video surveillance of entrances; visitor regulation and escort; central authorisation and blocking of access cards upon report of loss or theft

• Personal, individual log-in; multi-factor authentication enforced via conditional access policies, excluding SMS and telephone sign-in as a factor; role-based authorisation process; need-to-know limitation; password parameters; password manager; separate privileged admin account with phishing-resistant multi-factor authentication restricted to FIDO2; access-rights reviews at least annually and quarterly for privileged access, with automatic revocation of access not re-certified; automatic and immediate deactivation of user accounts on termination of employment; auto-lock; firewall; anti-virus; mobile-working policy; encryption of mobile devices

Confidentiality — separation & pseudonymisation

• Separation of customer data at tenant level; access authorisations by functional responsibility; separate development and production environments; automatically provisioned, isolated test environments per change

• Pseudonymisation of customer data where possible; where pseudonymisation is applied: separate and secured storage of the allocation data; deletion/anonymisation at sub-processors on erasure request or churn

Integrity

• Role-based access rights; encryption of data in transit (TLS in line with the state of the art) and at rest (database and object-storage encryption, AES-256 or stronger); storage-encryption keys are managed by the cloud provider (platform-managed keys), while application-level secrets are managed and rotated separately; system-side logging of access and retrieval; document-management system with change history; logging of data transfers; four-eyes principle; deletion in accordance with a documented deletion concept such that the data no longer exists or is no longer recognisable; secure wiping and re-imaging of end-user devices prior to reuse or disposal

Availability & resilience

• Security concept for software and IT applications; backup procedure and retention for Customer Data; virus protection and firewall; disaster-recovery plan; regular data-recovery testing with logging

Review, assessment & evaluation

• Concept for regular internal and external audits of the TOMs; regular management reporting; emergency tests; annual penetration tests; documented incident-response process

Instruction & order control

• Art. 28 DPAs with sub-processors; process for issuing/following instructions; designated contacts; confidentiality obligations; DPO (Art. 37 GDPR) and information-security officer; record of processing activities (Art. 30 GDPR); breach documentation and escalation; process for forwarding data-subject requests; regular review of critical contractors

Module-specific measures — Flip Fusion

• API keys stored via the dedicated connection feature are held securely and are, as a rule, not included in inputs to the language model; this does not apply to interfaces where the key forms a technical part of the request URL and is therefore processed within the context of the generated app. The Provider additionally screens inputs automatically for exposed credentials; complete detection is not warranted. The Controller ensures that credentials are stored only via that feature and not in free-text fields

• Chat history is passed to the language model only to the extent required to generate or amend the relevant generated app

• Access to the language model is routed exclusively through a central AI gateway; inference is stateless and Customer Data is not used to train models. Technical metadata (timestamps, status information) is logged at the gateway

• Fusion-related data is deleted from backups no later than 30 days after deletion in the production system; the prompt used to generate or amend an app and the generated source code are additionally stored in a source-code repository (sub-processor per Annex 3) and are deleted when the relevant Fusion session is deleted

Annex 3 — Sub-processors

The authoritative, living list of sub-processors is maintained in the Provider’s Trust Center: https://trust.getflip.com/. The list published there at the time of conclusion constitutes the sub-processors approved under Section 5.1. Any change is subject to Section 5.3 and, where it gives rise to a transfer to a third country, to Section 10.

Annex 4 — Transfer-mechanism module selections

A. Parties

B. EU SCCs (Section 10.1)

C. UK Addendum (Section 10.2)

D. Switzerland (Section 10.3)

Competent authority: the Swiss Federal Data Protection and Information Commissioner (FDPIC); references to the GDPR read as references to the FADP; protection extends to data of legal entities until the revised FADP is fully in force.

E. Data Privacy Framework (Section 10.0)

Where a U.S. sub-processor is self-certified under the DPF for the relevant data category, transfers rely on the DPF as the primary mechanism; the SCCs / UK Addendum / Swiss adaptations above apply as fallback. The Provider monitors the continued validity of the DPF adequacy decision and each sub-processor’s active certification.