Privacy
Privacy Policy.
Version of 27 October 2026
Deleting your account, step by step on iPhone, Android and the web, or by email: Delete your Kata account.
1 Controller
BSNS GmbHBirkenstrasse 47
6343 Rotkreuz, Switzerland
contact@yourkata.com
BSNS GmbH is the controller for the processing described in this policy. It covers the websites yourkata.com and docs.yourkata.com, the Kata web app at app.yourkata.com, and the Kata mobile apps for iOS and Android, including the Apple Watch app and the widgets that come with the iOS app.
BSNS GmbH has not appointed, and is not required to appoint, a statutory data protection officer. For every privacy matter, contact@yourkata.com is the direct line to the people responsible.
2 The short version
Your health data belongs to you. All logs, chats, photos and Kata's memory of you are written to your device, not into a content database of ours: in the browser and in the mobile apps alike. We never advertise to you, never sell data, and never profile your health data. The only measurement we run is basic, aggregate visitor analytics on this marketing website (Google Analytics), which you can decline in the banner and which never touches your health or account data (section 4). Beyond the email address and account identifier that sign you in, and the operational records described in sections 9 to 11 and 16, two things leave your device: your message to Kata, sent to our AI provider to generate your reply, which does not use it for training and deletes it within 30 days, while we keep no copy of it; and, in the web app and the Android app, one restore snapshot of your account, encrypted on your device before it is uploaded, under a key we never receive. We hold that snapshot as ciphertext, we have no technical means to open it, and your photos are never in it (section 7). Two features you switch on yourself add more, deliberately: Kata Duo shares one yes-or-no value a day with the partners you invite and nothing about what you did (section 14), and a secure share lets you send a summary you assemble to a person you name: it is sealed on your device and the link to it leaves from your device, so it stays unreadable to us as well (section 15).
3 Legal framework
We process personal data in accordance with the Swiss Federal Act on Data Protection (FADP, revised version in force since 1 September 2023) and, where it applies to users in the European Economic Area, the EU General Data Protection Regulation (GDPR). Where this policy names a legal basis, it refers to Art. 6(1) GDPR; under the FADP, the processing described here is covered by the principles of Art. 6 FADP and does not rely on consent unless stated.
4 Website visits
- Analytics: this website uses Google Analytics (provided by Google Ireland Limited) to measure visits and traffic in aggregate: pages viewed, approximate region from a shortened IP address, device and browser type, and how you arrived. It sets its own cookies. This is anonymous, aggregate usage data about the website only; it is never linked to your Kata account and never includes health or personal-account data. It loads only if you accept it in the consent banner, and you can decline. Legal basis: your consent (Art. 6 (1) (a) GDPR; Swiss FADP).
- Consent banner: analytics load only after you accept. Your choice, accepted or declined, is remembered as a single flag in your browser’s localStorage, and until you accept no analytics cookies are set and no analytics data is sent. Clearing that storage lets you choose again.
- Hosting: Vercel Inc., USA, delivers the website and processes technical server logs (IP address, request time, user agent) to run and defend the service (legitimate interest). Processing can take place in the EU and the US; transfers are covered by the EU standard contractual clauses and the Swiss transborder data flow rules.
- Fonts are self-hosted and delivered by the same hosting as the pages. No third-party font service is contacted, and no request of yours reaches one.
5 Website forms (contact and partnership)
If you use the contact or partnership form, we process the details you submit (name, email address, topic, company where given, and your message) to answer your request (performance of a contract or steps prior to entering one; legitimate interest for general enquiries). The messages are delivered to our mailboxes by Resend, Inc., USA, acting as our processor, and are kept as long as needed to handle the conversation and any follow-up. Form data is never used for advertising and never shared beyond this purpose.
6 App: account data
To create and secure your account we process your email address, a user identifier (your account ID), the authentication method and authentication timestamps, on every surface (web and mobile apps). Authentication is provided by Supabase, acting as our processor, with the project hosted in Switzerland (Zurich region). You can sign in with email and password, Google, Apple or a magic link; when you use a third-party sign-in, that provider confirms your identity to us and we store only your email address and account ID. If you sign in with Apple and choose Hide My Email, Apple gives us a private relay address instead of your real email; our transactional emails are sent to that relay and forwarded by Apple to you. Supabase holds no readable health data. What else sits in that database is described in sections 7 and 9 to 16: the sealed snapshot of the web app and the Android app, which we cannot open, the operational records listed there and, if you use Kata Duo or Kata Groups, one yes-or-no value a day.
The free trial of Kata Plus and the rewards of Invite a friend (section 13) are granted once per person. So that this still holds after an account is deleted, we keep keyed fingerprints of the deleted account's email address and of the Apple or Google sign-in accounts linked to it. A keyed fingerprint is an HMAC, a one-way hash computed with a secret key of ours: it cannot be turned back into the address or the sign-in account, and all it can show is that the same value has come back. We keep these fingerprints for 24 months after the deletion and use them for one purpose only: to check whether a new account belongs to someone who already had the trial or an invite reward, in which case the new account gets neither again. Legal basis: our legitimate interest in preventing abuse of our free offers (Art. 6 (1) (f) GDPR; Swiss FADP).
7 Your health data and where it lives
Kata is local-first on every surface. All health logs (weight, food, water, training, sleep, supplements), your chat history, Kata’s memory of you, your photos and your decisions log are written to your device: in the browser’s storage in the web app (localStorage for settings and structured logs, IndexedDB for larger content such as photos) and in the app’s local storage on iOS and Android. That is the only place any of it exists in readable form. We run no content database, and there is nothing on our side that we could open, read or hand over. If you delete the app or clear its site data, it is gone; the built-in export exists so you can back it up first.
In the web app and the Android app one thing does leave your device, and this is exactly what it is. So that a cleared browser, a new computer or a new phone does not mean a lost history, these two apps keep a single restore snapshot of your account, which we store as one row per account, because neither a browser nor an Android phone gives Kata a private per-user cloud to lean on. The iOS app sends no such snapshot to us: it writes a backup file to its own Documents folder on your iPhone (section 11). Before the snapshot leaves your device it is encrypted there with AES-256-GCM, under a random 256-bit key that is generated on your device, kept in the device’s secure storage and shown to you once as your recovery code. That key is never sent to us in any form: not in the row, not in a column, not in a request header, not in a log.
In the Android app that key is kept in two places, neither of them ours: on the phone, sealed under a key that the Android Keystore holds, and in Google Block Store, a store for small secrets that Google Play services keeps with your Google account, under Google's terms. The second copy is what lets a new Android phone, set up from your Google account, get the key back on its own and open your snapshot; where your phone supports it, Google encrypts that copy end to end with your screen lock. Deleting your account in the app removes the key from both places. Where Block Store is not available, your recovery code is the way to open the snapshot on another device.
The row holds the sealed envelope and nothing else: a format marker, a version number, the algorithm name, the random initialization vector, the ciphertext, the time it was sealed and the schema version of the data inside. No key, no key identifier, no hash of the key, no salt and no check value is stored beside it, so there is nothing on our side against which a guess could even be tested. We hold ciphertext we have no technical means to read, and only you hold what opens it. Your photos are never part of this snapshot, and neither are the values you import from Apple HealthKit or Google Health Connect. Row-level security is the second lock: the row is tied to your signed-in account and no other account can reach it. It is refreshed after you change something, at most once every quarter of an hour (every two minutes in a new account's first hour), and every six hours when nothing has changed; each refresh overwrites the last, and it is deleted with your account. If your device cannot encrypt, nothing is uploaded at all.
Health data you import from Apple HealthKit or Google Health Connect is treated like every other health entry: it lives on your device and is never stored on our servers. When you ask Kata a question, the imported values that question needs are sent with it to our AI provider to answer it (section 8). We never store them, never sell them and never use them for advertising.
8 AI coach
When you talk to Kata, your message and the minimum context needed to answer it, including any Apple HealthKit, Google Health Connect or WHOOP values the question needs, are transmitted over an encrypted connection to our AI provider (currently Anthropic PBC, USA) to generate the reply. Anthropic does not use these requests to train its models and deletes them within 30 days. We do not store the content of these requests on our servers; we record only aggregate token counts per account for cost control. Questions you ask on the Apple Watch are handled the same way. Voice input is turned into text before it reaches us: by Apple's speech recognition in the iOS app, by your phone's speech recognizer in the Android app, which on most Android phones is provided by Google and may process the audio on Google's servers, and by your browser's speech recognition in the web app, each under its provider's own terms. Photos are analyzed the same way as messages, only when you send them.
9 Abstracted product signals
To improve Kata, understand our audience and enforce fair use, we store a small set of abstracted signals per account. They are linked to your account identifier, so they are pseudonymous personal data, but they hold no names and no content: a daily heartbeat with the platform, the app version and a country code derived on our server; app-open counts and last-active timestamps; aggregate AI usage numbers (token counts per account, never message content); an abstract persona summary that the app computes on your device (an archetype word plus coarse traits such as activity level, top sport types, eating consistency, sleep pattern, current phase, optional self-stated gender, country and timezone); invite and voucher attribution; and your subscription plan.
Explicitly not held in readable form on our servers: your chats and conversation history, your health logs, Kata’s memory of you and your decisions log. Your photos are never stored on our servers. The rest reaches us only inside the encrypted account snapshot described in section 7, as ciphertext we cannot open. The persona summary is computed on your device, and none of the signals listed here can be used to reconstruct any of it. Legal basis: our legitimate interest in operating and improving the service (Art. 6 (1) (f) GDPR; Swiss FADP).
Two further things on our servers are health-derived without being product signals, because they exist only for as long as you ask for them: the daily yes-or-no value of Kata Duo (section 14) and the sealed summary of a secure share (section 15). They are named here so this section stays a complete picture of what we hold, and each is described in full in its own section.
10 Consent records
When you accept the Terms of Service or give a consent in the app, we store the record of that acceptance: the document version, the timestamp, the surface (web, iOS or Android) and the language you accepted in. These records prove contract formation and the consents you gave. Legal basis: performance of a contract and compliance with legal obligations (Art. 6 (1) (b) and (c) GDPR; Swiss FADP). They are kept for as long as your account exists. When you delete your account, they are kept apart from everything else, linked only to the keyed fingerprint of your email address (section 6) and your former account ID, for ten years, the general limitation period under Swiss law, and then deleted.
11 Mobile apps: permissions and push notifications
- Push notifications: if you enable them, a device push token tied to your account is processed to deliver notifications, via Google Firebase Cloud Messaging on both iOS and Android (on iOS it relies on the Apple Push Notification service underneath). The token is an identifier used solely to deliver the notifications Kata authors: it is never used for tracking or advertising, we run no Firebase Analytics, and no personal or health data is sent to Firebase, only the token and the notification text. Tokens are deleted when you disable notifications or delete your account. So that notifications arrive as you set them, we also store your notification preferences with your account: the categories you chose, quiet hours, how often, your language and your time zone. A send ledger recording which notification went out when is kept for 21 days, so nothing arrives twice.
- Backup file (iOS): the iOS app writes a backup of your local Kata data, photos included and HealthKit values left out, as a file in the app's own Documents folder on your iPhone. It is not sent to us, and Kata stores nothing in your personal iCloud. If your iPhone's own iCloud device backup is switched on, Apple includes that file in it like any other app data, under your Apple Account and Apple's terms. You can also export a copy yourself.
- Backup files and Google backup (Android): the Android app writes backups of your local Kata data, photos included and Health Connect values left out, as files in its own private storage on your phone, once a week unless you choose another frequency. They are not sent to us. If Android's own backup to your Google account is switched on, it carries these files and nothing else of Kata's: the app's live storage, which holds the Health Connect values, stays out of it, and so does the copy of the snapshot key sealed by the Android Keystore (section 7). That backup sits under your Google account and Google's terms. When you move to a new phone of your own directly, by cable or over Wi-Fi, Android carries the backup files and the app's live storage across without storing them anywhere in between. You can also export a copy yourself.
- Camera, microphone and photo library: accessed only when you actively take or attach a photo, scan a barcode, or speak to Kata. The access happens locally on your device; content is transmitted only at the moment you send it to Kata (section 8) and is not stored by us. When you speak, your speech is turned into text by Apple's speech recognition (iOS), by your phone's speech recognizer (Android), which on most Android phones is provided by Google and may process the audio on Google's servers, or by your browser's speech recognition (web). Each may process the audio under its provider's own terms; Kata receives only the resulting text.
- Barcode scanner: barcodes are read on your device by Google ML Kit, and no camera image is sent anywhere for it. To look the product up, your device then sends the barcode number to Open Food Facts, which, as with any web request, also receives your IP address. The score is computed on your device.
- Apple HealthKit and Google Health Connect: health data you choose to import stays on your device like all health content (section 7). When you ask Kata a question, the values that question needs are sent with it to our AI provider to answer it (section 8). We never store it on our servers, never sell it and never use it for advertising.
- Google Health Connect (Android): if you connect it, Kata reads, and never writes, the types you allow among these: steps, active energy, distance, workouts with their heart rate, weight, height, sleep with its stages, resting heart rate and heart rate variability. It reads only while the app is open, and no further back than 30 days before you first allowed it, as Kata does not ask Health Connect for older history. The values are kept in the app's local storage on your phone. They never enter the Google backup or the encrypted snapshot, and they never feed the persona summary of section 9. They leave your phone only with a question to Kata that needs them, sent with it to our AI provider exactly as Apple Health values are (section 8), or in an export or a direct transfer to a new phone that you start yourself. Disconnecting in the app gives Kata's permissions back to Health Connect and, if you choose, removes the imported values from Kata; you can also withdraw access in Health Connect at any time.
- Apple Watch app: the watch app signs in by taking over the session of your paired iPhone, or with an email sign-in where that is not possible. It reads HealthKit data on the watch, such as heart rate and HRV, to answer you, and never writes to it. A question you ask on the watch is sent, with the values it needs, to our AI provider exactly like a message in the app (section 8).
- The privacy labels shown in the Apple App Store and Google Play describe the same practices as this policy. Should a label and this policy ever appear to differ, this policy is the authoritative description of what we do.
12 WHOOP integration
Connecting WHOOP is optional. The OAuth tokens are stored on your device, unreadable to scripts where the platform allows it, and bound to your Kata account, so they work only for the account that connected them; they are not stored in any server database. They are used solely to fetch your recovery, sleep, strain, HRV, resting heart rate, skin temperature and workout data from the WHOOP API (WHOOP, Inc., USA) through our server, which passes the data on to your device without storing it. When you ask Kata a question, the WHOOP values it needs are sent with it to our AI provider as context (section 8). You can revoke the connection at any time in the app or in your WHOOP account settings.
13 Invite a friend
If you invite a friend, we process the invited email address and the state of the reward (Months given and earned) to run Invite a friend. Invited addresses are used for the invitation and reward matching only, never for marketing lists.
14 Kata Duo and Kata Groups
Kata Duo is optional and only exists once you start it: you share an invitation link, and whoever accepts it becomes one of at most five duo partners. To run a pairing we store the two account identifiers, the random invitation code, whether the pairing is still pending or active, one flag per side for hiding a partner on your own profile, and the times the pairing was created and joined. The name you give a partner is not part of that: it stays on the device you typed it on, your partner never sees it, and neither do we.
What Duo actually shares is one row per person per day, holding your account identifier, the date and a single yes-or-no value: whether you kept your form that day. Your device works that value out from your own local day, and it says nothing about what you did. No log, no number, no score, no streak, no content of any kind, and nothing about what was kept. A day with nothing logged produces no row at all, which is why the third state your partner sees is an honest grey rather than a claim. Only an account you have an active pairing with can read your rows, and that boundary is enforced in the database itself; when either side ends the duo, the pairing and the visibility go at once, in both directions.
Legal basis: your consent, given when you create or accept a duo invitation and withdrawn by ending the duo (Art. 6 (1) (a) and, because the value is derived from your health use, Art. 9 (2) (a) GDPR; Swiss FADP). Retention: as part of its daily write the app deletes your own rows once they are older than 21 days, so at most about three weeks of yes-or-no values exist at any time. Ending a duo removes the pairing immediately, and everything goes when you delete your account.
Kata Groups is the same mechanism for more than two people, and it holds no more than Kata Duo does. When you start a group we store a group identifier, a group name and a label for the one thing the group tracks, the random invitation codes, and, for each member, an account identifier, a per-group display name and whether that member hides their value from the group. What a group shares is the same single yes-or-no value per member per day, whether that member kept the day, and nothing about what anyone did: no log, no number, no score, no content of any kind. Only members of a group can read that group's rows, and that boundary is enforced in the database itself. Whether you hide your value from a group is known to you alone: the other members are never shown that choice, and to them a hidden value looks exactly like a day with nothing logged. Your values and your membership go the moment you leave the group or delete your account. The legal basis, and the derivation of the value from your health use, are the same as for Kata Duo above.
15 Secure share with a doctor or another person you choose
You can send a summary of exactly what you select to a person you name, typically a doctor. It happens only when you ask for it, and it happens like this. The summary is assembled on your device and encrypted there with AES-256-GCM. The key is placed in the share link itself, in the fragment that browsers never transmit to a server. That link is put together on your device and you send it yourself, from your device, in the message and through the channel you choose: neither the link nor the key ever passes through our servers. We store one row per share: the ciphertext, your account identifier as its owner, a salted SHA-256 hash of the recipient’s email address, the expiry, the time the share was created and the time it was first opened.
The recipient’s address itself is not stored, only that hash, salted with the share’s own identifier so it cannot be resolved against a table of common addresses. It exists so the access code reaches the invited inbox and no other. We send no invitation ourselves: the only email we send for a share is that access code, when the recipient asks for it. To open a share the recipient confirms the invited address with a 6-digit code, so we also hold the bookkeeping that check needs: a hash of the active code, its ten-minute expiry, the number of wrong attempts against it, which is capped at five, the number of codes sent and the time of the last one. The code is single use and the code itself is never stored. Everything else is ciphertext: we have no technical means to read the summary, and nor does anyone without the link.
Legal basis: your consent, given each time you create a share and withdrawn by revoking it (Art. 6 (1) (a) and Art. 9 (2) (a) GDPR; Swiss FADP). Retention: a share expires 14 days after you create it, and an expired row is deleted outright the next time it is touched. You can revoke a share in the app at any moment, which deletes the row and the ciphertext with it, and shares go with your account when you delete it. Once a share has ended, we keep only its random identifier and the time it ended, linked to nobody, so that its link can never open anything again. Creating shares is limited to ten per account per day.
16 Payment and subscription data
When you take a paid plan, we process the data needed to run your subscription: your plan and its status, the billing period, the currency and country used for tax, a customer and subscription identifier, and a record of payments and refunds. We do not receive or store your full card number; card details are handled by the payment provider.
- Web purchases: payments are processed by Stripe (Stripe Payments Europe, Ltd., Ireland, with Stripe, Inc., USA), which handles your card details and calculates applicable tax. We receive confirmation of the subscription and the limited billing details above, never the full card number.
- App Store purchases, in the iOS app from iPhone version 1.0.1: Apple is the seller and processes the payment; we receive the verified subscription status (product, period, renewal and cancellation) needed to unlock your plan, not your payment details.
- Google Play purchases, in the Android app from a later version: Google is the seller and processes the payment; we receive the verified subscription status needed to unlock your plan, not your payment details.
Legal basis: performance of your subscription contract and compliance with our legal obligations, including tax and accounting retention (Art. 6 (1) (b) and (c) GDPR; Swiss FADP). Billing records are kept for the statutory retention periods.
Corporate wellness: if an organisation such as your employer covers your plan, we store your membership in that organisation (the email address it invited, whether the seat is invited, joined or removed, the date of each of these steps, and the plan its deal grants) so the coverage can be applied and withdrawn. For an invitation sent by email, we also store when it was last mailed and how many times. We keep a record of every change to the membership (invited, joined, left, removed) and to the organisation’s deal, so that seats and invoices can be checked; it carries account identifiers, never your email address and nothing about your health. What the organisation’s manager sees about any one person is membership only: for each person it invited, the email address it invited (someone who joined by link or code appears without one), whether the seat is invited, joined or removed, the dates of those steps, and, for an open invitation, whether it has expired or was withdrawn and when and how often it was mailed. For the group, the manager sees the seats in use against the seats the deal covers, and activation and engagement as counts. Every count about activity is computed only from members who confirmed their email address and actually used Kata in the period shown, never from the managers themselves, and appears only when at least five such members stand behind it, so nobody can be singled out. The organisation never sees your health data, your logs, your chats or Kata’s memory of you: none of that exists on our servers in readable form, for the organisation any more than for us. Legal basis: performance of the contract that covers your seat (Art. 6 (1) (b) GDPR; Swiss FADP). Leaving the organisation, or being removed from it, ends the coverage and leaves your own data untouched.
Gifts. When you give Kata Plus as a gift, we process what you enter for it: the length, the card design and its language, your name and the recipient's name as you want them on the card, your note, how the gift arrives, the recipient's email address if we are to email it, and the day to send it. The payment provider gives us your email address and name for the receipt and, for a card by post, the postal address. If you are signed in, the gift is linked to your account so you see it there. Unlike your health data, a gift is kept on our servers (Supabase, Zurich region), because the person you give it to opens it from there. We use it only to deliver the gift: to show the card and your note to whoever opens it, to email it, to print and post the card, to send you the receipt and the notes that it was claimed and that the card was posted, and to handle refunds and questions. You only ever learn that your gift was claimed, and when, never anything about the account that claimed it. Legal basis: the contract with you (Art. 6 (1) (b) GDPR; Swiss FADP).
Receiving a gift. If someone gives you a gift by email, we use your email address and the name they wrote only to send you that one gift email, and their note only to show it to you; your address is added to no list. When you claim the gift, we record which account claimed it and when, so the months can be added. We do not read the note for any other purpose and never use it for coaching, personalisation or marketing. Legal basis: our legitimate interest in delivering a gift that was bought for you (Art. 6 (1) (f) GDPR; Swiss FADP), and the contract with you once you claim it (Art. 6 (1) (b) GDPR).
17 Recipients and transfers abroad
- Supabase (authentication, and the database holding the operational records described in this policy, the encrypted account snapshot of the web app and the Android app, the Kata Duo and Kata Groups pairings and daily values, and the sealed secure shares): project hosted in Switzerland, Zurich region.
- Anthropic (AI processing for the coach): USA; requests are not used for training and are deleted within 30 days.
- ElevenLabs (Kata voices, on the paid plans only: reading your weekly review and letters aloud, Mégane's occasional voice notes, and the spoken replies when you Talk with Kata): USA, transient processing only, the text is turned into audio and not stored.
- Resend (transactional email, including the access code for a secure share): USA.
- Vercel (hosting): EU and USA.
- Stripe (payment processing for web purchases, gifts included): Stripe Payments Europe, Ltd., Ireland, with processing by Stripe, Inc., USA.
- The postal service that carries a printed gift card (Swiss Post, and the postal operator of the destination country), with the card, the note and the postal address only.
- Apple and Google (payment and subscription processing for purchases made in the App Store and Google Play, once the apps offer them): USA.
- Google Analytics (aggregate website usage measurement, only with your consent): Google Ireland Limited, Ireland, with processing by Google LLC, USA.
- Google / Firebase Cloud Messaging (push notification token delivery on iOS and Android; no analytics): USA.
- Apple (Apple Push Notification service underlying iOS push, Sign in with Apple and its private email relay, speech recognition in the iOS app, and your own iCloud device backup, which may include the app's backup file): USA.
- Google (Sign in with Google, and in the Android app: the phone's speech recognizer where Google provides it, Google Block Store, which keeps the snapshot key with your Google account, and your own Google device backup, which may include the app's backup files): USA.
- Your browser's speech recognition (voice input in the web app), provided by the browser's maker under its own terms.
- Google ML Kit (barcode reading for the scanner): runs on your device; no camera image is sent for it.
- Open Food Facts (product lookup for the scanner, sent from your device with the barcode and your IP address): France.
- WHOOP (the WHOOP API, only if you connect WHOOP): USA.
Where data reaches providers in the USA, the transfer is safeguarded by the EU standard contractual clauses and, where certified, the Swiss-U.S. Data Privacy Framework. We do not sell or rent personal data, and no other recipients exist.
18 Retention
Account data is kept for as long as your account exists and deleted when you delete the account, apart from the keyed fingerprints of section 6, which are kept for 24 months after the deletion and then deleted. Consent records are kept for as long as your account exists and, after its deletion, for ten years, linked only to the keyed fingerprint of your email address and your former account ID (section 10). Form correspondence is kept as long as needed to handle the request. Aggregate token counts are kept for cost accounting. Billing and payment records are kept for the statutory tax and accounting retention periods. Push tokens are deleted when notifications are disabled or the account is deleted; notification preferences are kept for as long as your account exists, and the send ledger for 21 days. Our AI provider deletes the requests it processes within 30 days. The daily heartbeat and the persona signals of section 9 are kept for as long as your account exists and deleted with it. Health data on your device is retained solely by you. The encrypted account snapshot (section 7) is a single row that each backup overwrites and that is deleted with your account; we hold no readable copy of your health data at any point. Kata Duo values are deleted once they are older than 21 days, and a pairing with all its values goes the moment either side ends the duo (section 14). A secure share expires 14 days after it is created, and its row, ciphertext included, is deleted then or the moment you revoke it; only its random identifier stays behind, linked to nobody, so its link never opens again (section 15). A gift's record (its code, the length, what was paid, the buyer's email address and the dates) is kept for the statutory accounting period. The names, the note and the recipient's email address are deleted 90 days after the gift was claimed or refunded, or when it expires unclaimed; a postal address is deleted 90 days after the card was posted. When the account that claimed a gift is deleted, the gift's link to it is removed (section 16).
19 Security and data incidents
All transport is encrypted (TLS). The server holds the minimum data described above, protected by access controls and the security programs of our processors. The strongest measure is architectural: your health content is either not on our servers at all or lies there only as ciphertext to which we hold no key, so a breach on our side cannot expose it.
Should a security incident nevertheless affect personal data we hold, we will assess it without undue delay and notify the competent supervisory authority and, where required, the affected persons, in accordance with Art. 24 FADP and, where applicable, Art. 33 and 34 GDPR.
20 Your rights
You have the right to access, rectification, erasure and portability of your personal data, and the right to object to processing. Since almost all data lives on your device, most of these rights are in your own hands: export, correct or wipe your data directly in the app. For anything relating to your account or a form you submitted, write to contact@yourkata.com. You may also lodge a complaint with the Swiss Federal Data Protection and Information Commissioner (FDPIC) or, where the GDPR applies, with your local supervisory authority.
21 Changes
We will update this policy when the service changes. The current version, with its date, is always published on this page. Material changes are announced in the app.
22 Governing law
This policy and any privacy dispute are governed by Swiss law. The engineering view of the same facts lives in the Your data docs.