Privacy Policy

This part concerns the website kindfair.net, the sign-in accounts, the contract and account data of the organisations, the technical operation of the platform and enquiries to the provider. The provider itself is responsible for this processing. Part 2 describes how Kindfair processes the data that an organisation keeps in the application.

The PROVIDER is responsible for this website and for the processing described in this part: Kutvention – Inh. Aykut Bicak (sole proprietorship), Seewenjestraße 175A, 28237 Bremen, email support@kindfair.net. Further details are given in the legal notice (Impressum). No data protection officer has been appointed.

The respective ORGANISATION is responsible for the data IN the application — clients, records, personnel files. It decides on the purposes and means; the provider processes the data on its behalf (Art. 28 GDPR). The name, address and contact details of the organisation are given on the organisation’s application form under “Responsible”; otherwise in its own information.

This distinction is not a formality: it determines to whom a data subject turns with a request for access or erasure.

The provider processes the contract and account data of the organisations — name and email address of the contact person, package, start of the cooperation and trial period — in order to conclude and perform the contract for the use of Kindfair. The legal basis is Art. 6(1)(b) GDPR.

After the free trial period, the organisation pays by subscription via the payment service provider Stripe (Stripe Payments Europe, Limited, Dublin, Ireland). For this purpose, Stripe receives the name, address and email address of the organisation or of the contact person, the billing interval, the number of active accounts, the amounts and the payment details that the organisation itself enters with Stripe; the provider does not see the payment details. Names of individual employees and content from the application are not passed on to Stripe. The legal basis is Art. 6(1)(b) GDPR. According to its own classification, Stripe processes the payment details as an independent controller and otherwise on behalf of the provider; Stripe’s privacy notice applies in addition. Stripe may also process data in the USA; this is based on the adequacy decision on the EU-US Data Privacy Framework and the standard contractual clauses of the EU Commission.

The provider stores them for the duration of the contract and thereafter, where statutory retention obligations exist (§ 147 of the German Fiscal Code, AO; § 257 of the German Commercial Code, HGB), until these expire, and otherwise until the end of the regular limitation period (§§ 195, 199 of the German Civil Code, BGB). In the application itself, contract and subscription data are removed as soon as the provider deletes the organisation; what is subject to a retention obligation after that — above all invoices and payment records — is kept at Stripe and in the provider’s accounting.

Name and email address of the contact person are required to conclude the contract; providing them is not required by law. Without them, the provider cannot conclude the contract or set up the organisation’s access. If the organisation does not provide payment details with Stripe after the trial period, it can only use Kindfair in read-only mode, and the contract ends after a further thirty days.

Reports and enquiries to VentionDesk are described in the section “Contact form and error reports”, the technical logs at Vercel, Render and Sentry in the section “Technical logs”.

Technical logs are created during operation: the delivery log at Vercel with the address called up, the runtime logs of the services at Render, and the error reports and the performance measurements on the servers at Sentry. The legal basis is our legitimate interest in secure and error-free operation (Art. 6(1)(f) GDPR). Performance measurements in the browser only take place with your consent (section “Sign-in and cookies”).

The delivery logs at Vercel are deleted after one day at the latest, the runtime logs at Render after 14 days at the latest, and error reports and performance measurements at Sentry after 30 days at the latest.

Where a log contains data from the area of an organisation, the provider processes it on behalf of that organisation.

When you write to us via the contact form or, in the application, via “Report something” (the question mark at the bottom right), we process your details — for the contact form, name, email address and message; for “Report something”, message, email address for queries and your name from your personnel file —, a subject formed from the beginning of the message and technical accompanying data, in order to handle your enquiry and to fix errors. Technical accompanying data are the page called up and, for “Report something”, the screen width, the name and identifier of your organisation, your role in the application, whether you are signed in as the provider, whether the page shows client data and, if you attach one, a screenshot. For “Report something”, the email address field is pre-filled with the address of your account; if it is left empty, the address of your account is transmitted.

We send an automatic acknowledgement of receipt with the case number to the email address provided.

If you send us an email to the address in the section “Controller”, we process your email address, the content of the email including attachments and the details in the email header, such as the time, in order to handle your enquiry. The email goes to our mailbox at Google Workspace; we transfer it to VentionDesk for handling. The legal basis and storage period are the same as for an enquiry via the contact form.

The legal basis is Art. 6(1)(b) GDPR insofar as your enquiry concerns a contract with you — for example as an organisation or before a contract is concluded. If you report as an employee of an organisation, the legal basis is our legitimate interest in handling enquiries and in the error-free operation of the application (Art. 6(1)(f) GDPR); the same applies to all other enquiries.

We use our ticket system VentionDesk to handle them. The contact form is additionally protected against automated requests; this is described in the section “Protection of the public forms”.

Technical accompanying data and screenshots are deleted after 90 days, your enquiry together with our reply six years after the matter is closed (retention of business letters under § 147 of the German Fiscal Code, AO); once a year we delete whatever is older. When an organisation's contract ends, we delete its enquiries unless they are business letters.

To limit the number of enquiries, the application itself stores, for each enquiry via the contact form, two values hashed with a server key — one derived from the IP address, one from its network — and the time, never the address itself; for “Report something”, your user identifier and the time for each report. These records are not passed on to VentionDesk and are deleted after 24 hours.

Whether you write to us is up to you; neither law nor contract obliges you to do so. The contact form only accepts an enquiry with name, email address and message, and without an email address we cannot reply to you.

Please do not send us health data or other special categories of personal data via these channels, and make sure that a screenshot does not show data of other persons.

We protect the contact form, the application form and the page for submitting documents later against automated requests with Cloudflare Turnstile. Cloudflare’s verification program is only loaded when you begin to fill in the form; merely calling up the page does not trigger it. It checks technical characteristics in the browser — according to Cloudflare, the IP address, characteristics of the encrypted connection, the browser identifier and the calling page — and only shows a box to tick in case of doubt.

The result is a verification token that is sent along when the form is submitted. Our server has Cloudflare confirm it before it processes your details; without confirmation nothing proceeds, and you can send again. The server does not additionally transmit your IP address. Signing in to Kindfair does not use Turnstile.

The purpose is that the forms are used by people and not en masse by programs — protection against misuse and overload. The legal basis is our legitimate interest in secure operation (Art. 6(1)(f) GDPR). For the application form and the page for submitting documents later, we carry out the check on behalf of the organisation to which your application is addressed (Art. 28 GDPR); there, the legal basis is that organisation’s legitimate interest in a secure application process. For the verification to work, Cloudflare stores information in the browser within its embedded verification box (cookies or local storage under Cloudflare’s address); Cloudflare does not publish the names and duration of these entries. This happens only for submitting the form that you request (§ 25(2) no. 2 of the German Telecommunications Digital Services Data Protection Act, TDDDG).

The provider of the service is Cloudflare, Inc., San Francisco, USA. Cloudflare checks the characteristics on our behalf; according to its own statement, Cloudflare also uses them as an independent controller to improve the detection of programs. For the transfer to the USA, what the section “Recipients and processors” says about Cloudflare applies.

For development, maintenance and troubleshooting, the provider uses the AI tool Claude Code by Anthropic. Through the provider’s database access it technically has full access to the application’s database, as its owner and therefore bypassing the rights and row-level security of the application; through connections to the provider’s accounts it also reads deployment, error and delivery data of the service providers for delivery, error reports and email sending. Under the provider’s working rules it uses the database access for reading only and only as far as the respective task requires, with queries on structure, identifiers and counts instead of content; it uses it for writing only to apply changes to the structure of the database, or in individual cases on the provider’s express instruction. It does not read reports from the reporting window of the application or enquiries from the contact form. These limits are organisational, not technical. What the tool reads is sent to Anthropic in the USA. The provider uses Claude Code through an account under consumer terms; there is no data processing agreement with Anthropic for this. Read access via this route appears neither in the access log nor in the activity log of the application, traces of it exist only in the logs of the database operator; changes to data are recorded in the activity log with the channel “sql”.

Another AI tool, Codex by OpenAI, works only on the source code of Kindfair; it has no access to the database, to enquiries from the contact form or to reports from the application.

Separate from this is the machine translation of the text fields in records: when text is saved in such a text field, it is automatically sent to the AI model Claude by Anthropic after five minutes and translated once into the language the organisation has set for itself; if a person uses the application in another language, it is also translated into that language when opened. In the Start package, text fields are not translated. Anthropic does not use it to train its models. The translation makes no decision about a person; it is marked as machine-translated, and the original remains the record. Details are given in the section “Recipients and processors”.

Also separate from this is the reading of bank statements, which an organisation can switch on under Finances (off by default): an uploaded bank statement is then sent to a different AI model Claude by Anthropic than the translation, which reads the transactions and suggests a cost category for each one. The result is marked as an AI suggestion; a transaction only counts in the evaluation once a person accepts or corrects it. Anthropic does not use the file to train its models. Details are given in the section “Recipients and processors”.

Signing in works without a password, via a link sent to your work email address. The link is valid for 15 minutes and only on this device.

An account without access — without membership of an organisation, without an open invitation and without access as the provider — is deleted in a nightly run, together with its passkeys and second factor, as soon as the last access ended 30 days ago and neither a sign-in nor a creation took place during this time. Anyone who is invited again afterwards receives a new account.

If you wish, you can sign in with a passkey instead of the link — with your fingerprint, your face or the PIN of your own device. Setting one up is voluntary, under Settings → Security. For this, we only store the public key of the passkey, its identifier, a counter, two technical characteristics for backup to other devices, the device name you choose and the times of creation and last use. Biometric data and the private key never leave the device and do not reach us. The data remain until you remove the passkey or your access ends. For each sign-in with a passkey, a random number is generated, which is deleted upon sign-in, at the latest after five minutes; to prevent misuse, we count the attempts per network address in hashed form and delete the count after 24 hours.

Instead of using the link or a passkey, you can sign in if you have an account with Google (Google Ireland Limited, Dublin, Ireland), Apple (Apple Distribution International Limited, Cork, Ireland) or Microsoft (Microsoft Ireland Operations Limited, Dublin, Ireland) with exactly the work email address for which access exists here. With a different address — including “Hide My Email” with Apple — no access is created and signing in is not possible. The sign-in itself takes place with the provider: the provider thereby learns that you are signing in to Kindfair and processes the data of your account with it under its own responsibility in accordance with its privacy policy, including in the USA. The provider passes on to Kindfair’s sign-in service your email address, whether it has been verified, an identifier of your account with the provider and — depending on the provider — your name and the address of your profile picture. The sign-in service stores this information with your account until the account is deleted; Kindfair only uses the email address and the identifier for signing in. A password of the provider never reaches Kindfair. If a second factor has been set up, this sign-in also requires the code. Which providers are offered is shown on the sign-in page.

Equally voluntarily, every account can set up a second factor under Settings → Security: a one-time code from an authenticator app. Once it is set up, every sign-in — via link as well as via passkey — additionally requires the code. For this, the secret key of the factor is stored with the sign-in service; the app itself transmits nothing. The factor remains until you remove it, the provider resets it at your request, or your access ends. For the factor you can generate ten recovery codes, with which you can remove it yourself without your phone; for each code only a non-reversible check value is stored, never the code itself. The check values are deleted together with the factor, when new codes are generated, or when your access ends; we count the attempts to redeem a code per account and delete the count after 24 hours.

Each person chooses the language of the interface themselves — in the browser via the person menu, in the app under Settings. The choice is stored with the sign-in service in your account until you choose another one or the account is deleted; the application’s emails and notifications are also sent to you in this language, unless your organisation has written the template itself. A choice made in the app also applies in the browser and is additionally recorded there as the app’s choice; “System language” deletes this record. A choice made in the browser does not apply in the app: as long as you do not choose a language in the app, it follows the language setting of the phone, and in the browser without a choice that of the browser. The device’s language setting is read for this purpose and not stored. Your location plays no role.

Cookies are only set by an action: when submitting the sign-in form, when signing in via Google, Apple or Microsoft, when signing in with a passkey or adding a passkey, when switching the appearance and when making a choice about performance measurement. Anyone who merely calls up the public pages receives none. Anyone who begins to fill in one of the public forms loads the verification by Cloudflare Turnstile; what it stores in the browser is described in the section “Protection of the public forms”. The following paragraphs name each type individually, with purpose and duration. A fixed total number is deliberately not given here: how many there are depends on how often a sign-in link was requested.

The session cookie “sb-<identifier of the database project>-auth-token” holds the access token and the refresh token of the sign-in; for longer values, the parts “.0” and “.1” are added. It carries “Secure” and “SameSite=Lax” and remains on the device for at most 30 days. This limit is sliding: each refresh of the sign-in resets it, so what is limited is the unused device. For accounts with admin rights of an organisation and for the provider, it remains on the device for at most 12 hours from sign-in; a refresh does not extend this period. When the session ends, the application deletes the cookie.

When the sign-in form is submitted and when signing in via Google, Apple or Microsoft, further cookies whose names end in “-code-verifier” are created in the browser. They hold the one-time secret with which the sign-in link or the return from the provider is redeemed: one for each requested sign-in link and each sign-in started via a provider, plus a directory of these processes and an entry for older program versions. Anyone who requests the link several times — because the email did not arrive or the 15 minutes had expired — therefore has several of them side by side; the application keeps the five most recent processes and deletes the older ones. They are deleted after redemption and on sign-out; one that has not been redeemed remains for at most 30 days.

Selecting “Sign in with passkey” or “Add passkey” sets the cookie “kindfair-passkey-anmeldung” or “kindfair-passkey-einrichtung” respectively. It contains only a random identifier of the ongoing process, cannot be read by scripts in the browser, is deleted on completion and is valid for at most 5 minutes.

Switching the appearance — light, dark or automatic — sets the cookie “kindfair-darstellung”. It contains only the selected appearance, cannot be read by scripts in the browser and is valid for 365 days.

Making a choice in the notice “Allow performance measurement?” sets the cookie “kindfair-messung-2”. It contains only “ja” (yes) or “nein” (no) and is valid for 365 days.

All of the cookies mentioned are necessary for the service requested and therefore do not require consent: without them there is no sign-in, no sign-in with a passkey, no remembered appearance and no remembered choice. No cookie is set for advertising, analytics or reach measurement purposes; there is therefore no cookie consent banner.

That applies to cookies. For the performance measurements sent to Sentry (section “Recipients and processors”), the application reads technical characteristics of the device in the browser — type of connection, size of the working memory, number of processor cores. This happens only with your consent (§ 25(1) TDDDG, Art. 6(1)(a) GDPR): without a choice and after a refusal, nothing is measured. Error reports are independent of this: they carry only what is necessary to fix an error — error message, program location, the address of the page and the version of the application —, no characteristics of the device and no history of use before the error. You can change your choice here or via “Cookie settings” among the legal notices at any time; the withdrawal applies from then on. If you are signed in, the application additionally records each choice as proof of consent (Art. 7(1) GDPR): your account, “ja” or “nein”, the version of the notice, its language and the time — no device and no address. The proof is deleted together with your account. Without signing in, there is no proof other than the cookie itself.

The sign-in does not reveal with which organisation an address is registered. The sign-in screen answers every address in the same way, whether or not access exists for it. To someone who calls the sign-in interface directly, however, its response may reveal whether access already exists for an address — an account or an invitation.

The “Kindfair” app for iPhone and — as soon as it is released — for Android is a second access to the same application: the same accounts, the same rights, the same data. What you record in the app about supported persons, records, expenses, absences or calendar entries is processed by the provider on behalf of your organisation, as in the browser (Part 2).

In the app, you sign in with the six-digit code contained in the same email as the sign-in link, with a passkey via Face ID, on Android via fingerprint, face recognition or the screen lock, or via Apple, Google or Microsoft as described in the section “Sign-in and cookies”; “Sign in with Apple” runs on the iPhone through the device itself, Google and Microsoft — on Android all three — in a sign-in window of the system that shares no cookies with the browser. For the code, the app sends your work email address to the sign-in service; the email is sent via Resend, as in the browser (section “Recipients and processors”). With a passkey, the device checks your face or fingerprint itself; the app and the provider receive no biometric data, only the signature with which your passkey confirms the sign-in. The legal basis is our legitimate interest in giving the employees of the organisations secure access to their work tool (Art. 6(1)(f) GDPR).

After sign-in, the app stores the access token and the refresh token in the keychain of the iPhone, on Android encrypted with a key from the Android Keystore. It can only be read while the device is unlocked, is not included in any backup or transferred to any other device, and is valid for at most 30 days from the last refresh, for accounts with admin rights of an organisation and for the provider at most 12 hours from sign-in; on sign-out, the app deletes it. Also stored on the device is whether you have switched notifications on or off. Storing on the device is strictly necessary for the sign-in you requested and does not require consent (§ 25(2) no. 2 TDDDG). In addition, the app remembers in the same storage under “kindfair.wiedererkennung” with which account a session last existed on this device, your first name, the name of your organisation and the identifier of the passkey you use on this device — so that the sign-in recognises you and assigns the passkey of this device. These details remain when a session merely expires and are deleted as soon as you sign out in the app.

After sign-in, the operating system asks whether the app may send notifications; you can switch them off and on again at any time under “More” → “Notifications”. Only if you allow this does the app obtain a device identifier — on the iPhone from Apple, on Android from Google — and register it with the provider. For each device, this identifier, your account, the environment (test or production) and the times of registration and of the last refresh are stored. After each email that Kindfair sends you, the provider sends a notification via the Apple Push Notification service, on Android via Google’s Firebase Cloud Messaging, always with the same text: “New message in Kindfair”. It names no name, no reason and no period; at most it carries the information which page of the app opens when it is tapped, such as “Absence” — without any information about an individual case. The identifier is deleted when you switch off notifications, when you sign out in the app, when Apple or Google rejects it as invalid, when the device has not checked in for 90 days, and together with your account. It is refreshed each time the app starts while you are signed in. Notifications only exist if you allow them; the legal basis is our legitimate interest in drawing your attention to new items (Art. 6(1)(f) GDPR), and the access to the device takes place for the service that you request by giving permission (§ 25(2) no. 2 TDDDG). Recipients and the transfer to the USA are named in the section “Recipients and processors”.

The app accesses the camera, photo library and microphone only when you add a photo or video to a record or a photo to a receipt; the first time, the operating system asks for your permission, which you can withdraw at any time in the settings of the device. The microphone only records the sound of a record video. Only the recordings that you take or select — for a record, several at once from the library — are uploaded, into the storage of your organisation; the app does not see other photos in your library. The app removes the recording location that a photo or video from the library may carry before uploading; it does not accept photos in formats for which this is not possible. If you photograph a receipt on the iPhone, the text recognition of the iPhone reads the amount, date and merchant from the image in order to pre-fill the fields; this takes place solely on the device, the image is not sent to anyone for this purpose, and only what you save with the receipt is stored. On Android, there is no such recognition; there you fill in the fields yourself. Part 2 applies to the content.

Under “More” → “Help”, you send a report to the provider’s support — as via the question mark in the browser. Transmitted are your text, the address for queries, your name, your organisation and your role, the name of the screen and the version of the app; a screenshot only if you yourself attach one from the library. How the report is processed further is described in the section “Contact form and error reports”.

If the app crashes or an error occurs in it that it cannot handle, it sends a crash report to Sentry in its EU region (section “Recipients and processors”). It contains the error message, the location in the program where the error occurred, the version of the app, the environment (test or production), the operating system with its version and the device model. Before sending, the app removes email addresses, access keys, identifiers of records and the parameters in addresses from the error message. The report names neither your account nor the name of your device and contains no history of which screens you opened before or what you typed, no screenshot and no recording of your use. If the system-level part of the app crashes, the report is sent at the next start; it may then additionally carry information about the memory of the device and a random identifier that the crash reporting generates for this installation of the app and that designates neither your account nor your device. Sentry does not store the IP address of the connection. The legal basis is our legitimate interest in an app that works without errors (Art. 6(1)(f) GDPR); the app reads the device model and operating system because a crash cannot be fixed without them (§ 25(2) no. 2 TDDDG). Sentry deletes the reports after 30 days at the latest. Versions of the app built before 20 October 2026 do not send crash reports.

The app contains no advertising, no tools for analytics or reach measurement and no tracking across apps or websites of other providers. It does not request your location and does not read contacts; tapping a telephone number only opens the Phone app. The “Route” button for a shift opens Apple Maps on the iPhone and Google Maps on Android with the location of the accommodation as the destination; the app sends nothing to the provider for this, and Apple and Google are themselves responsible for what the maps app does with the destination and your location. If you have allowed sharing analytics data with app developers in the settings of the iPhone, Apple provides the provider with aggregated usage figures and crash reports; on Android, Google does the same if you have allowed the device to send usage and diagnostics data. Apple and Google are each responsible for this themselves.

For Apple’s and Google’s review of the app, there is a single review account in a review organisation of the provider that contains only fictitious data. Only this account signs in to the app with a password instead of the code — for this, after the address has been entered, the app asks the provider whether it is the review account —; the provider has the password generated by the system and renews it after each review; only a hash value of it is stored, and every sign-in with it is logged. The provider does not issue a password for other accounts; there, this path only leads to a rejection.

You obtain the app via the App Store, the Android app via Google Play. The data generated in the process — Apple or Google account, download and purchase — are processed by Apple and Google under their own responsibility.

The data are stored at Supabase in the region eu-central-1 (Frankfurt am Main). The contractual partner is Supabase Pte. Ltd., Singapore; there is no company in the EU. Access by Supabase for maintenance and support is also possible from countries outside the EU, including the USA, where authorities may demand access under local law. The transfer is based on the standard contractual clauses of the EU Commission (Implementing Decision (EU) 2021/914).

The scheduled services run at Render (Render Services, Inc., San Francisco, USA) in the Frankfurt region.

The application itself is operated at Vercel (Vercel Inc., Covina, USA); its server functions run in the region fra1 (Frankfurt am Main). Vercel receives requests from outside the EU at locations close to the requesting person.

Emails are sent via Resend (Plus Five Five, Inc., San Francisco, USA). Sending takes place from the region eu-west-1 (Ireland); Resend stores the emails, including recipient address, subject and content, as well as delivery logs, webhook data and account data in the USA; emails and logs are deleted after 30 days.

Error reports and sampled performance measurements are sent to Sentry (Functional Software, Inc., San Francisco, USA) in its EU region: technical information and the address of the page. In the browser, measurements only take place with your consent. On the servers of the application and the services, the provider measures a sample of 10 percent of requests without consent: the path called up including the details in the address, the duration of the individual steps, the result and technical headers such as the browser identifier — without the content of the request, without cookies and without sign-in data. The legal basis for this is our legitimate interest in secure and error-free operation (Art. 6(1)(f) GDPR). Email address, IP address and username are removed from error reports and performance measurements before they are sent; the application does not set an identifier of the signed-in person. For performance measurements, Sentry derives an approximate location (city) from the connection upon receipt and stores it with the measurement — for a measurement in the browser from your connection, for a measurement on the server from that of the server; Sentry does not store the IP address itself. Error reports carry no location. Crash reports of the app also go to Sentry (section “App for iPhone and Android”).

Cloudflare Turnstile (Cloudflare, Inc., San Francisco, USA) protects the contact form, the application form and the page for submitting documents later against automated requests; what is processed in the process is described in the section “Protection of the public forms”.

The provider backs up the files stored in the application every night at Cloudflare (Cloudflare, Inc., San Francisco, USA) in a storage area in the EU. They are encrypted beforehand; only the provider has the key, and Cloudflare sees neither the content nor the name of a file. Deleted and changed files remain there for 30 days and are then deleted.

Push notifications to the iPhone app are delivered by Apple (Apple Distribution International Limited, Cork, Ireland, with Apple Inc., Cupertino, USA). Transmitted are the device identifier of the iPhone, the neutral text “New message in Kindfair” in the language of the recipient and, where provided, the path of the page of the app that opens when tapped, for example “Absence” — no name, no reason, no period, no identifier of a case. Apple may process the data in the USA; according to Apple’s privacy policy, the basis is the standard contractual clauses of the EU Commission.

Push notifications to the Android app are delivered by Google via Firebase Cloud Messaging (Google Ireland Limited, Dublin, Ireland, with Google LLC, Mountain View, USA) as soon as the Android app is released. Transmitted are the device identifier, the same neutral text and, where provided, the same path of a page of the app — no name, no reason, no period, no identifier of a case. Google may process the data in the USA; the basis is the adequacy decision on the EU-US Data Privacy Framework, under which Google LLC is certified, and additionally the standard contractual clauses of the EU Commission in Google’s data processing terms.

Anyone who signs in via Google, Apple or Microsoft is redirected to the chosen provider for signing in; the provider acts under its own responsibility, not on behalf of Kindfair. What it learns and what it passes on to Kindfair is described in the section “Sign-in and cookies”.

The text fields in the checklist of a record are translated by an AI model Claude by Anthropic (Anthropic Ireland, Limited, Dublin, Ireland, with Anthropic, PBC, San Francisco, USA). Automatically transmitted are the text of a text field five minutes after saving and the language the organisation has set for itself; if a person uses the application in another language, also this translation and the language of the person when opened. Translation only starts once the administration of the organisation has confirmed the data processing agreement in the version that names Anthropic, and not in the Start package. Beforehand, Kindfair replaces the name of the supported person and recognisable addresses, phone numbers, email addresses and account numbers with neutral markers and inserts them again after the translation; other details in the text, such as names of other persons, are not replaced. Anthropic processes the text in the USA and at other locations outside the EU, does not use it for training and, according to its own statement, deletes it after 30 days at the latest. The transfer is based on the standard contractual clauses of the EU Commission in Anthropic’s data processing agreement. Kindfair stores the translations with the record and deletes them as soon as the text changes or the record is deleted.

If an organisation has switched on automatic reading under Finances (off by default), every bank statement it uploads as a PDF or photo is sent to a different AI model Claude by Anthropic. The whole file with all transactions is transmitted — booking date, purpose, name of the counterparty, amount and balances — without names being replaced beforehand. Reading only starts once the administration of the organisation has confirmed the data processing agreement in the version that names this purpose. Anthropic returns the transactions it has read with a suggested cost category; Kindfair stores them as suggestions with the bank statement, and a person accepts or corrects them. Processing, deletion at Anthropic and the basis of the transfer are the same as for the translation; for each call Kindfair records only the number of tokens and the cost, no content.

For Vercel, Render, Resend, Sentry and Cloudflare, a transfer to the USA is based on the adequacy decision of the EU Commission on the EU-US Data Privacy Framework of 10 July 2023, under which the companies are certified, and additionally on the standard contractual clauses of the EU Commission.

Emails to the address in the legal notice go to the provider’s mailbox at Google Workspace (Google Ireland Limited, Dublin, Ireland). Google may also process them in data centres outside the EU; the basis is the standard contractual clauses of the EU Commission in Google’s data processing terms.

Reports from the report window of the application, enquiries from the contact form and emails to the address in the legal notice go to our ticket system VentionDesk. We operate VentionDesk ourselves; it is not a processor. The recipients are the service providers on which it runs: the interface and the ticket intake run at Render in the Frankfurt region, the web interface at Vercel with server functions in the region fra1 (Frankfurt am Main). The reports and their attachments such as screenshots are stored at Supabase in the region eu-central-1 (Frankfurt am Main), in a separate project apart from that of the application. The acknowledgement of receipt is sent via Resend from the region eu-west-1 (Ireland); here too, according to its own statement, Resend stores the emails including their content in the USA. Error reports from VentionDesk are sent to Sentry in its EU region.

Data processing agreements under Art. 28 GDPR are in place with Supabase, Vercel, Render, Resend, Sentry, Google and Cloudflare; they also apply to the operation of VentionDesk. A data processing agreement is in place with Anthropic for the translation and for reading bank statements.

Payments by the organisations are handled by Stripe (Stripe Payments Europe, Limited, Dublin, Ireland); details are given in the section “Contract and account data”.

Beyond these service providers, data are only transmitted to bodies towards which there is a statutory obligation to provide information or evidence — in particular the funding body under § 62 et seq. of Book VIII of the German Social Code (SGB VIII).

The respective organisation is responsible for the data that it keeps in the application; the provider processes them on its behalf. This part describes how the application handles these data. The purposes and legal bases are determined by the respective organisation.

Social data from assistance and youth welfare services are processed: client files and assistance planning, shift planning and the team calendar, accommodation, records of the types that the organisation defines — such as handover, move-in and move — including free-text fields, personnel files, absences, expenses and billing, the finances of the organisation with bank statements and bank transactions — if the organisation switches it on, with an AI suggestion of the cost category for each transaction, which a person accepts or corrects — as well as the invoices that freelance staff issue to the organisation — with name, private address, tax number or VAT identification number and the bank details from the personnel file.

The purposes and legal bases are determined by the respective organisation. Typically, these are the provision of support and the obligations to provide evidence to the funding body, based on Art. 6(1)(b) and (c) and Art. 9(2)(b) and (h) GDPR in conjunction with § 35 of Book I of the German Social Code (SGB I), §§ 61 et seq. SGB VIII and § 22 of the German Federal Data Protection Act (BDSG). At the organisation, the data are subject to social secrecy (Sozialgeheimnis).

No automated decision-making or profiling within the meaning of Art. 22 GDPR takes place.

Each organisation is a separate tenant. Every table carries the identifier of the tenant, and the database itself enforces the separation (row-level security) — not just the interface. The tenant sees exclusively its own data.

Within an organisation, the role applies in addition: the fixed roles carer, planner and admin and custom roles that the administration of the organisation tailors per operation, for example for bookkeeping — at most with the rights of an admin and never with the settings, the keys for the programming interface or the change, access and activity logs. A carer sees only the support teams of which they are a member, and of other staff only picture, telephone, email and job title; so does a custom role, as long as the administration does not give it the rights “Read clients of all teams” or “Read full files of others”.

A new tenant starts empty. An empty tenant with an admin account is created — no data of other tenants is visible.

Every change to a data record in the functional areas and to the contract status of the organisation (package, contact person) is recorded with time, acting person, table, previous and new state. The change log is deleted after 12 months. Entries can only be appended to the log; changing and deleting are withdrawn from all roles.

If a data record containing social or personnel data is deleted, the database removes its content from the change log at the same time; all that remains there is that it was deleted, when and by whom. An individual entry is cleaned up only by the provider, on the express instruction of the organisation, and the provider records the intervention.

If the provider opens the view of an organisation (“Open as tenant”), the access is recorded with start, expiry and reason. The admin of the organisation sees it in the activity log of the application; on request, the provider gives information about reason and scope. No message is sent for each access. The access ends automatically. The provider can also open a blocked organisation in this way in order to wind up the cooperation; the access is then recorded in the same way.

The provider sees accounts, packages and accesses — content of an organisation in the application only via such a logged access. Outside this path, the provider accesses the database or file storage directly only to remedy a malfunction, to restore data or on express instruction; the organisation has given general instructions for these cases in the data processing agreement. The provider records every such access with time, occasion and scope and informs the organisation about it on request.

What is recorded is not only who changed something, but also who opened a client or personnel file and who retrieved a file containing personal data. Every export of the entire data of an organisation is also recorded — who, when, for which organisation and with how many files and gaps, without content; this includes an aborted or incomplete export.

The record is aggregated: the same person, the same file and a quarter of an hour result in one entry. The log is therefore not a click log and is not intended for monitoring behaviour or performance. It is read by the administration of the organisation; any person can learn from the administration on request who has opened their own personnel file.

It is kept for twelve months and then deleted. The period does not depend on the periods of the files and documents it names, because it does not serve the file but its control; an entry may therefore remain for a shorter or longer time than the file itself.

One limit belongs to this: what is recorded is access via this application. Direct access to the database with a technical key does not appear here; the provider records it in accordance with the section “Logging” and informs the organisation about it on request. Nor do the accesses of the AI tool used in development, which Part 1 describes in the section “AI tools and machine translation”.

For the data categories in the following list, a retention period with a legal basis is stored. The organisation sets the duration; the legal basis cannot be changed. Not every data set has a period in this list: none is currently stored for calendar entries and bank statements; for the log of the provider’s accesses, open invitations, sign-in accounts without access and further technical data, fixed periods of the system apply that the organisation does not set — they are named in the section “Enforcement of deletion”. Invoices from freelance staff are accounting vouchers of the organisation (§ 147 AO) and, like expenses, belong to the “Pay and payroll records”; they are not deleted automatically, but manually by the administration of the organisation.

An admin of the organisation can permanently delete a client or personnel file at any time; the organisation checks whether a retention obligation stands in the way. If the provider deletes an organisation as a whole, its files are deleted with it. And with a personnel file, its shifts in client files are removed as well.

30 days before the retention of a client file ends, a reminder is sent to the admins of the organisation. It calculates with the set period “Client file and documentation” from the end of support, and without its own setting with the default from the following list; a file without a recorded end of support does not receive one. The file is not deleted automatically.

The following list shows the system default. Your own organisation may have set longer periods.

Only what a nightly run in the application covers is deleted automatically: applications including documents six months after the decision, without a decision six months after receipt; the photos and videos attached to records, including records of custom types, together with their files after the period “Photo documentation of handovers” set by the organisation has expired (default 12 months from the date of the record) — the record itself remains and only notes the day on which its recordings were deleted; the access log after 12 months; the change log together with the records of clean-ups after 12 months; the log of notifications sent after 6 months; the technical records of the application form, of the page for submitting documents later, of “Report something” and of the contact form after 24 hours. The files of the applications are deleted at the same time, as are their requests for further documents and the links for submitting them.

The same run deletes technical data after fixed periods that the organisation does not set: the activity log 12 months after the entry; the log of retrievals via the Kindfair API 30 days after the retrieval; the records of accesses by the provider (“Open as tenant”) 6 months after the end of the access; the technical records of exports of the entire data 6 months after they started; deputyships 30 days after they expire; blocked and expired API keys together with their retrievals 90 days after blocking or expiry; invitations that have not been accepted 30 days after they were sent; the access of a person who has left to the organisation 30 days after leaving; a sign-in account that no longer has any access 30 days after the end of the last access; the recipient and error text in the log of notifications sent 30 days after sending; the device identifiers for notifications of the app 90 days after the device last checked in; and files in the storage to which no data record belongs any more 7 days after they were last written. When a sign-in account no longer has any access is described in Part 1 in the section “Sign-in and cookies”.

The change log records the previous state of a data record with every change. If a data record containing social or personnel data is deleted, all that remains there is that it was deleted, when and by whom — not its content.

Shifts in the deployment plan are anonymised once the period “Working time records” has expired (default 24 months from the end of the month): a nightly run removes the assigned person, including from the change log. The supported person, day and time slot remain for documentation and analyses.

The client file is expressly NOT deleted automatically. Retention under § 62 et seq. SGB VIII does not end on a date that can be calculated — it depends on whether proceedings are still ongoing. The decision is made manually; this applies to “Client file and documentation”, “Assistance planning and reports”, “Client billing records”, “Personnel file” and “Pay and payroll records”.

Like the client file, after the period has expired the application also submits “Client billing records” and “Pay and payroll records” to the admins of the organisation for review; a reminder is sent 30 days beforehand. These data, too, are only deleted manually.

An erasure request under Art. 17 is examined individually regardless of this: statutory retention obligations take precedence over it.

The application form can be reached without signing in. It is only activated once the organisation has stored its name, address, a contact and its supervisory authority; the form names these details. The organisation processes the details in order to decide on the application; the legal basis is Art. 6(1)(b) GDPR. After a rejection, it retains them for the defence against claims under the German General Equal Treatment Act (AGG) (Art. 6(1)(f) GDPR); they are deleted by the nightly run after six months. The provider protects the form and the page for submitting documents later against automated requests on behalf of the organisation; this is described in Part 1 in the section “Protection of the public forms”.

If documents are missing, the organisation can request them. The applicant then receives an email with a link via which they upload exactly the requested documents without signing in. The page behind the link names only the organisation and the types of documents requested, nothing from the application. The uploaded files are then stored with the application and deleted together with it.

The link is valid for 14 days from the first email and can be submitted exactly once; opening the page does not use it up. It is stored only as a hash value (SHA-256), not in plain text. After an acceptance or a rejection, it no longer accepts anything. After 7 days without the requested documents, a reminder with a new link is sent, which is valid until the same day; it is only possible to submit once via both links together.

To slow down the systematic trying out of links, every call of the page is recorded with a sender identifier hashed from the IP address with a server key — never with the address itself. The records are deleted after 24 hours.

One limit belongs to this: the access is contained in the link, namely after the character “#”. The browser does not send this part to the server; it therefore does not appear in the access log of the delivery, but it does appear in the text of the email, including during email delivery, and may appear in the browser history. The page removes it from the address bar after opening and sends it to the server only when checking and submitting. Links that were sent before 27 September 2026 still carry the access in the address; calling them up appears once in the access log of the delivery. It is removed from error reports and performance measurements before they are sent, and the page does not pass on its address to other websites as the origin.

There is a right of access, rectification, erasure, restriction of processing, data portability and objection. Consent given can be withdrawn at any time with effect for the future.

For social data, the special rules of §§ 83 et seq. of Book X of the German Social Code (SGB X) also apply; they may restrict the right of access and the right to erasure as long as statutory retention periods are running.

Requests concerning the social data in the application are to be addressed to the responsible organisation. Requests concerning this website and the contract and account data of the organisations are to be addressed to the provider; the contact details are given in the section “Controller” and in the legal notice.

The provider responds to a request within one month (Art. 12(3) GDPR). If there are doubts as to whether the request comes from the data subject, it asks beforehand. If it receives a request concerning the data of an organisation, it forwards it to that organisation.

Every data subject can lodge a complaint with a data protection supervisory authority, in particular in the Member State of their habitual residence, their place of work or the place of the alleged infringement.

For the processing for which the provider is responsible, the supervisory authority at its registered office is competent: Der Landesbeauftragte für Datenschutz und Informationsfreiheit der Freien Hansestadt Bremen, Georgstraße 122-124, 27570 Bremerhaven.

For the data in the application, the competent authority depends on the registered office of the responsible organisation; for a church organisation, it is the church data protection supervisory authority. The organisation names which one it is in its own information and on the application form.

This statement is dated 21 October 2026.