Data processing agreement (DPA)

Parties

This data processing agreement (DPA) applies between the care service that uses Farola, as controller (Art. 4(7) GDPR), and 997 Ventures UG (haftungsbeschränkt), Sonnenhof 13, 67677 Enkenbach-Alsenborn, Germany (HRB 33133), represented by Finn Lauppert von Peharnik, as processor (Art. 4(8) GDPR). Contact: info@farolacare.com.

It gives concrete form to the obligations under Art. 28 GDPR for all personal data we process within Farola on behalf of the care service. The care service remains the sole controller: it decides on the purposes and means of the processing; we process only on its documented instructions.

Draft for legal review. This is a version 1.1 template, not yet cleared by a lawyer. Acceptance takes place in the product (Section 13); until it is cleared by a lawyer the draft notice remains.

Section 1 Subject matter and duration of the processing

(1) The subject matter is the provision of Farola as software for home care services: dispatch and round planning, the live map, the caregiver app, functions for clients and relatives, the capture and analysis of conversations at the client's home, and the storage required for this. Farola runs alongside the existing care software and replaces neither billing nor certified care documentation.

(2) The processing lasts as long as the care service uses Farola. It ends when the use ends; Section 9 (return and deletion) then applies.

(3) We process personal data only within this DPA and the documented instructions of the controller. If we consider an instruction to infringe the law, we say so and may suspend its execution until the matter is resolved.

Section 2 Nature and purpose of the processing

The processing serves solely to provide Farola to the care service, in particular:

• Planning and running rounds and visits (who drives when to whom, with which vehicle), including estimating travel times.
• Showing caregivers and vehicles on the live map during a running round.
• Providing the caregiver app (round, navigation to the client's home, status updates, voice notes).
• Receiving requests from clients and relatives and assigning them to visits.
• Recording, transcribing and structured analysis of conversations at the client's home and maintaining a context memory per client, in each case only with documented consent (Annex A).
• Sending necessary notifications (such as arrival times) and system e-mails.

AI and voice functions are governed separately in Annex A. The purposes are exhaustive; the data is not used for our own purposes, in particular not to train AI models.

Section 3 Types of data and categories of data subjects

(1) Data subjects are the care service's clients, their relatives and contact persons, the caregivers, and the users of the dashboard (management, dispatch).

(2) Depending on the function, the following are processed in particular:

Master data

Names, addresses, contact details, access notes for the home, relationships (relatives).

Health data (Art. 9 GDPR)

Care level, care and visit needs, observations, conversation content and its analysis, the context memory per client.

Caregivers' location data

Positions during a running round (employee data protection, Section 26 BDSG); vehicle positions between the start and end of a round.

Conversation recordings

Audio at the client's home, only after consent, and the transcript and analysis produced from it.

Usage and sign-in data

Phone number matching, device identifier, session tokens (only as a hash), roles, technical log data.

(3) Health data is a special category of personal data (Art. 9 GDPR) and is handled with particular care. Strict data minimisation applies: each function processes only the data it needs.

Section 4 Obligations of the processor

• We process data only on the documented instructions of the controller (Art. 28(3)(a) GDPR), including for transfers to third countries (Section 11).
• Persons obliged to confidentiality: everyone dealing with the data is obliged to confidentiality (Art. 28(3)(b), Art. 29, Art. 32(4) GDPR) and bound by professional secrecy (Section 5).
• We take the technical and organisational measures under Art. 32 GDPR (Section 6).
• We support the controller in responding to requests from data subjects (Art. 12 to 23 GDPR) with appropriate technical and organisational measures.
• We support the controller in its obligations under Art. 32 to 36 GDPR (security, breach notification, data protection impact assessment, prior consultation).
• We report any personal data breach to the controller without undue delay after becoming aware of it, with the information needed for notification under Art. 33 GDPR.
• We engage sub-processors only in accordance with Section 10.
• After the end of the processing, we return or delete the data at the controller's choice (Section 9).
• We make available to the controller the information needed to demonstrate compliance and allow reviews (Section 8).

Section 5 Professional secrecy (Section 203 German Criminal Code)

(1) The controller's caregivers, as members of a health profession with state-regulated training, are bound by the duty of confidentiality under Section 203(1) of the German Criminal Code (StGB). The data processed within Farola constitutes other people's secrets within the meaning of that provision.

(2) We and our staff are other participating persons within the meaning of Section 203(3) StGB. We expressly oblige everyone who is given access to this data to secrecy (Section 203(4) StGB) and inform them that unauthorised disclosure is a criminal offence. This obligation continues after the activity ends.

(3) If we engage further participating persons (sub-processors, Section 10), we oblige them to secrecy in the same way. The controller may disclose the secrets to us to the extent necessary for the use of Farola (Section 203(3) sentence 2 StGB).

Section 6 Technical and organisational measures

We take measures appropriate to the state of the art under Art. 32 GDPR, giving special regard to the protection of special categories (Art. 9 GDPR). The processing takes place in the European Union.

Access control (systems)

Access to systems only after authentication; session tokens are stored only as a hash; app sessions are bound to a device and can be revoked individually.

Access control (data)

Roles in the dashboard (Admin, Dispatch, Read-only); caregivers see only their own round; every access is checked on the server.

Separation control

One care service is one tenant; database policies (row level security) and tenant-bound keys keep the tenants' data apart.

Transfer control

Transport encryption (TLS); encryption of data at rest at the infrastructure providers; audio in private storage with short-lived, signed access links.

Input control

Servers set the authoritative timestamps; changes to care entries are logged (who, what, when).

Availability control

Managed, backed-up database in the EU; regular backups; a round that has been loaded stays visible in the app even without a network.

Data minimisation

Each interface returns only the fields needed for the purpose; location only during a round; recordings only with consent.

Protection of special data

No health data, names, addresses or transcript excerpts in error logs, file names or address lines; file and record names use technical identifiers (UUID).

Error monitoring

Before anything is sent to error monitoring, secrets, tokens and transcripts are removed; personal data does not reach the logs.

On AI calls: pseudonymising the names is not required; here, processing exclusively on EU infrastructure provides the safeguard (Annex A). We keep the measures up to date; the level of security in force at any time must not be undercut.

Section 7 Rights and obligations of the controller

• The controller is responsible for the lawfulness of the processing and for fulfilling data subjects' rights.
• It obtains the necessary consents, in particular for recording clients' conversations, and ensures the employment-law basis for tracking (caregivers' location data is subject to co-determination, Section 87 BetrVG; Farola is built so that a works agreement can clearly limit tracking).
• It issues instructions in principle in text form or via Farola's settings and names the persons authorised to instruct.
• It informs us without undue delay if it detects errors or irregularities in the processing.

Section 8 Reviews and evidence

(1) We demonstrate compliance with this DPA, as a rule by information, current descriptions of the measures under Section 6, and available certificates or audit reports, including those of the sub-processors.

(2) If this evidence is not sufficient, we allow reviews by the controller or an auditor it appoints who is bound to confidentiality. Reviews take place after notice, during normal business hours, without disrupting operations and, where practical, remotely. On-site reviews are possible to the extent necessary.

(3) Without particular cause, reviews are limited to once per calendar year. Where there is concrete cause, for example after a data breach, they are possible at any time.

(4) Support within the scope owed by law and one review per calendar year are free of charge for the controller. Effort beyond this for reviews and support is remunerated by time at market rates.

Section 9 Return and deletion

(1) Statutory retention obligations for the data processed on the controller's behalf, in particular for care documentation under SGB V and SGB XI and under tax and commercial law, lie with the controller alone. Farola is not the controller's legally required care documentation system; it runs alongside the controller's care software and does not replace it (GTC Section 3). The processor has no statutory retention obligation of its own within the meaning of Art. 28(3)(g) GDPR.

(2) After the end of the use, we return or delete all personal data at the controller's choice, including any copies, unless a statutory retention obligation of the controller prevents this. A return is made on request in a common, machine-readable format over a secure transfer channel. [[A self-service export by the controller is not yet set up; we will add the delivery procedure here.]]

(3) We delete the personal data [[X]] days after the end, or, if earlier, [[…]] days after an export confirmed by the controller. Copies in backups are overwritten by rotation at the latest [[…]] after the end and, until then, are used only to restore on instruction. On completion we confirm the deletion on request in text form (time and scope).

(4) Farola already deletes certain data automatically during the term: conversation recordings once the agreed period has passed (30 days by default, Annex A), location data after seven days. Entries the controller has taken into its own care documentation are subject to its instructions and the statutory periods.

(5) The controller is responsible for keeping the exported records itself for the duration of its statutory retention periods.

Section 10 Sub-processors

(1) The controller gives general authorisation for the use of the providers listed in Annex 1: sub-processors. Annex 1 is part of this DPA.

(2) Before adding or replacing a sub-processor, we inform the controller and obtain its consent. Consent is given in the product by the administration, by accepting the new DPA version (Section 13). Until consent is given, the new or replaced provider is technically locked; no personal data flows to it, and only the already authorised sub-processors remain in use. The rest of Farola remains usable during this time. Providers marked as planned in Annex 1 become active only after this consent.

(3) We conclude a contract with every sub-processor that imposes at least the same data protection obligations on it as this DPA imposes on us (Art. 28(4) GDPR), including the obligation to professional secrecy (Section 5).

(4) Ancillary services such as pure telecommunications, post or maintenance are not sub-processing, provided there is no access to the controller's personal data.

Section 11 International data transfers

(1) The processing takes place in the European Union. The database, the files and the AI functions (Vertex AI) are in the EU.

(2) If we use a provider whose parent company is in a third country (for example in the USA), any transfer relies on an adequacy decision, failing that on the EU-US Data Privacy Framework for certified providers or on the European Commission's Standard Contractual Clauses together with additional safeguards. The relevant basis per provider is named in Annex 1.

(3) If a provider's transfer basis changes, we notify this without undue delay, at the latest within 30 days of becoming aware.

Section 12 Liability

Liability is governed by the statutory provisions, in particular Art. 82 GDPR. We are liable for the fault of our staff and of the sub-processors we engage as for our own fault. Internally, liability is apportioned in accordance with Art. 82(5) GDPR.

Section 13 Conclusion and changes

(1) This DPA is concluded in the product. On registration or first sign-in, the controller's administration accepts this DPA and the terms and conditions and acknowledges the privacy policy, via three non-pre-ticked checkboxes. Only a person with the Administrator role can accept; other roles see a notice, but not the acceptance dialog. The version in force is published on this page and provided to the controller as a file on request.

(2) Every acceptance is logged in an append-only and immutable manner (no overwriting, no deletion) with the name, e-mail and role of the accepting person, the time, the accepted version and the previously valid version. The accepting person receives a confirmation of this by e-mail. The controller can view the log of its acceptances in the settings.

(3) For material changes to this DPA or its annexes, in particular new types of data, new sub-processors or new processing locations, we inform the controller's administration by e-mail on the day of the announcement, with a reminder after 14 days, and show a notice in the dashboard. The changed processing stays technically locked until the administration accepts the new version in the product; until then only the already authorised processing remains active, and the rest of Farola remains usable.

(4) Not a material change but a clarification of the description are wordings that describe an already agreed processing more precisely (such as naming concrete fields, storage locations or steps that are already the subject of this DPA), and the correction of typographical errors and references. A clarification changes neither the subject matter, the purpose, the types of data or the categories of data subjects, nor the sub-processors, the processing locations, the protection level of the technical and organisational measures, or the rights and obligations of the parties. Every clarification is documented with a date and is available on this page; it needs no renewed acceptance. Every other change is material and is accepted under paragraph 3.

Section 14 Final provisions

• German law applies.
• In the event of conflict between this DPA and other agreements of the parties, the provisions of this DPA prevail for data protection.
• Should any provision be invalid, the validity of the remaining provisions is not affected.
• Amendments and additions require text form.

Annex 1: sub-processors

The current list of sub-processors with purpose, types of data, location, transfer basis and DPA status is available at sub-processors. It is part of this DPA.

Annex A: AI and voice functions

(1) Farola uses AI exclusively via Vertex AI in the EU region: transcription of conversations, structured text analysis and the assistant. No API keys are used (authentication via ADC or Workload Identity Federation).

• Real names may appear in AI calls; processing exclusively on EU infrastructure provides the safeguard, and pseudonymisation is not required.
• No training and no further use of the data at the provider.
• Conversation recordings only after documented, revocable consent (client and caregiver), checked in the app and on the server. Without consent there is no recording.
• Audio is deleted automatically once the period expires (30 days by default) after transcription and analysis; a withdrawal deletes audio and transcript.
• Analyses are suggestions and are approved by a person before they are adopted; the context memory is maintained, not the audio.
• Dictation and assistant queries are not stored: one call to the EU model, then discarded.

(2) Addresses are geocoded server-side via Google Places; only the typed address snippet with a session token is transmitted, no name and no identifier. Farola calculates travel times from the distance; if routing is enabled, only rounded coordinates go to the routing service, no names, addresses or identifiers.

(3) When the caregiver taps “Navigation starten” in the caregiver app, the app opens Google Maps on their device (as an app or via a web link). Only the visit's destination (coordinate or address) is handed over, never a name, no identifier and nothing from the record. Google is then its own controller; this is not processing by us.

(4) A phone AI (incoming and outgoing calls) is prepared but not yet active. It will only be put into operation after the controller consents to the sub-processors concerned (Annex 1) and, where necessary, after the parties to the call consent.

Annex 3: Church and public carriers

This annex applies in addition if the controller is a church or public carrier. The controller selects its carrier type in the settings; the following provisions and the functions available to it then apply accordingly.

(1) Catholic carriers (KDG): if the controller is a body within the scope of the Act on Church Data Protection (KDG), the obligations of this DPA also apply as obligations under Section 29 KDG; references to the GDPR are to be read as references to the corresponding provisions of the KDG. We inform the controller without undue delay if, in our view, an instruction infringes the KDG, and we support it towards the church data protection supervision responsible for it with the information and evidence under Section 8.

(2) Protestant carriers (DSG-EKD): if the controller is a body within the scope of the Church Act on Data Protection of the EKD (DSG-EKD), the obligations of this DPA also apply as obligations under Section 30 DSG-EKD; references to the GDPR are to be read as references to the DSG-EKD. We oblige the persons involved in the processing to data secrecy and support the controller towards the competent church data protection supervision.

(3) Public carriers (social data): if the controller is a body named in Section 35 SGB I, we process social data within the meaning of Section 67(2) SGB X. We uphold the social secret (Section 35 SGB I) and oblige the staff involved in the processing to the social secret before they take up their work; the obligation continues after the activity ends. Under Section 80(2) SGB X, social data may be processed only in the European Union, the European Economic Area or a state with an adequacy decision under Art. 45 GDPR; the Standard Contractual Clauses alone may be regarded as insufficient for this. The notification under Section 80(1) SGB X lies with the controller; we provide the necessary information for it (measures under Section 6, types of data, categories of data subjects, sub-processors) on request and notify changes to sub-processors early enough for a fresh notification to be possible before they take effect. The processor's supervisory authority is the authority competent under Section 40 BDSG (Section 80(4) sentence 3 SGB X).

(4) US nexus: Farola runs on EU infrastructure; the database, file storage and the AI functions (Vertex AI) process in the EU. Several of these services (Supabase, Vercel, Google Cloud with Vertex AI and Google Places, and Resend) process in the EU but have a US parent company; the transfer basis is the Standard Contractual Clauses (Annex 1). Under Section 80(2) SGB X the Standard Contractual Clauses alone may be regarded as insufficient. For public carriers, Farola currently locks only the telephony and monitoring services marked as planned in Annex 1; the other, EU-hosted services with a US parent remain active.

[[Lawyer review: admissibility of the EU-hosted services with a US parent for public carriers under Section 80(2) SGB X; procedure if needed]]

[[Open for legal review: does acceptance via the checkbox in the product (Section 13) satisfy the written-form requirement of Section 29 KDG or the text-form requirement of Section 30 DSG-EKD, or is a separate written agreement required for church carriers?]]