Privacy Policy

This policy explains what personal data Cravora collects, why we use it, who we send it to, how long we keep it, and what you can ask us to do about it. It covers the Cravora website, the mobile apps, and the services behind them.

We have written it to describe the product as it is built, not as we hope it will be. Where a practice is not yet in place, or a control does not exist, we say so plainly rather than leave you to assume otherwise. That is deliberate: a privacy policy that overstates its protections is worse than one that admits a gap.

Three sections below cover specific places: Europe and the United Kingdom, the United States, and India. If you live in one of them, that section adds to everything here and takes priority over the general text wherever the two differ.

If you signed up for Cravora yourself, PairOx Pty Ltd, which operates Cravora and is the company named in the company details at the top of this policy, is the controller of your personal data. We decide what is collected and why, and you can bring any question or request straight to us.

If your employer, insurer, or another organisation gives you access to Cravora, that sponsor and Cravora each carry responsibility for different parts of the processing. Which part belongs to which of us is set out in our written agreement with that sponsor. Their benefits or HR contact can tell you their side of it.

We do not disclose your individual health data to your employer, your insurer, or any sponsor. The only exceptions are where you tell us to share something with them, or where the law requires the disclosure.

We do tell a sponsor who is enrolled. An administrator at your organisation can see a roster of its members, showing each person's name, email address, department, and the date they joined. So the fact that you have a Cravora account, and since when, is visible to them by name. Their wellness figures are only ever shown to that administrator in groups, on the terms described in the sharing section below.

We collect data you give us directly, data the devices you connect send us, and data generated automatically as you use the apps. Not every category applies to every person. What we hold depends on which features you actually use.

Some of it is health data, which most privacy laws treat as special-category or sensitive information. That includes your reproductive health records and your answers to the mental-health questionnaires in the app, which are kept item by item and not only as a total. The onboarding profile steps also collect something that is special-category in its own right without being health data: the race or ethnicity you tick, which Article 9 of the GDPR protects the same way, together with the gender identity and pronouns you enter alongside it. An identity document and the selfie taken with it would be sensitive in the same way, and in some places carry their own biometric rules; nothing in the app asks you for either today, and the first item below says what exists behind that.

Most privacy laws require your explicit consent before data like this is processed, and in Europe and the United Kingdom that is the basis we rely on. Here is how consent actually works in the product today.

For a few things there is a real switch, and we record both the granting and the withdrawal. Health Insights, which allows analysis of your health data for personalised insights, sits under Privacy in your settings and starts switched off. Anonymised research sharing is a real switch too, but it is not on that tab: on the web it is on the wearables privacy screen, and in the mobile app it is in settings. It also starts switched off. Crash Reporting is a real switch too, under Privacy in your settings, and it is the one that does not start off: until you turn it off we send the errors your browser hits, the console errors and warnings on the page and the requests that come back a failure to our error-reporting provider, and, where you have accepted analytics cookies as well, the timings of the pages you open. Turning it off is recorded like the others. That answer is held in your browser and cleared when you sign out, so on the pages you can reach signed out we report again until you sign back in. Health analytics and personalised recommendations are different again. You meet them once, as boxes on the onboarding privacy step that start unticked, and afterwards you withdraw them from the consent log in your settings rather than from a switch. Each of those is recorded when you turn it on and recorded again when you turn it off, and that history is part of what you can export.

There are no separate collection switches for symptom tracking, vital signs, medication adherence or activity data anywhere in the product, and nothing is recorded for them to withdraw. What you enter in the app — a symptom, a blood-pressure reading, a dose — is an entry you made, not a category you consent to us collecting. What you do control is each entry: a symptom, a mood, pain, energy or nutrition entry, a manually entered vital sign, a single dose, a day's progress toward a goal, a past habit check-in and every other entry you log yourself can be deleted on its own, in either app, and most kinds can also be corrected. The one exception is the reflections saved with a weekly habit review, which have no delete of their own. The section on your rights says where, and what a deletion does not reach. A health goal and a health alert can each be deleted one at a time, or cleared all at once, from the screen that lists them. Deleting a medication, which both apps let you do, takes its dose logs with it, and the delete control on the connected-devices privacy screen clears what your devices sent us — the readings, sessions, workouts, scores, cycle records and breathing and meditation sessions — and revokes every connection with it. Until recently that control also erased the sleep journal, body measurements and health goals you had written yourself, under a heading about device data; it no longer does.

That onboarding step has three more boxes: marketing, anonymised research, and whether your data may be shared with partners. All three start unticked, and a fourth, marked Required, cannot be switched off because it is the basis on which we run the service at all. Take the partners box: we store your answer and you can withdraw it from the consent log, but nothing in the product reads it. Ticking it turns no sharing on, and leaving it unticked is not what limits what we share. The section on who we share data with describes what actually leaves us.

The AI coach is the exception. No consent record is captured for it. You consent by choosing to use it, and the only control is to stop using it, with one exception: your health score is given to the coach only while Health Insights is on. Deleting what it has stored depends on where you are. In the mobile app you can delete a whole conversation, which removes it and its messages from our database. On the web there is no per-conversation delete: Delete on one of your own coach messages marks it deleted and leaves what you wrote in our database, so the only way to clear your coach history there is to delete your whole account, which we carry out after a 30-day grace period. Deleting a conversation or a message does not remove a safety record made from it, which is described below.

• Identity and contact details: your name, email address, phone number, date of birth, country and language, and your password, which we store only as a hash. There is no social sign-in. The buttons for Google, Apple, Facebook, GitHub, Microsoft and LinkedIn were removed and the endpoint behind them refuses every request, so none of those companies receives your name, your email address or a token from us, and none of them learns that you use Cravora. You sign in with an email address and password. If your employer, insurer or other sponsor has set up single sign-on, you can sign in through their identity provider instead. When you do, their system asserts your email address to us, along with anything else it chooses to send, and it necessarily learns each time you sign in to Cravora. We do not control what it records about that, or who at your organisation can see it; their IT or HR contact can tell you. Signing in with an email address and password stays available either way. On identity verification: there is no identity check in the app today. We ship an endpoint that files an identity document — a passport, driving licence, national ID or state ID — with its number and a selfie, and any signed-in account can reach it, but no screen calls it, no verification company is contacted, and nothing checks what it files. We say so here rather than tell you no such path exists.
• Account and profile: your preferences, app settings, and any links between a guardian and a dependant. The profile steps in onboarding also ask for, and we then hold, your gender, gender identity and pronouns, your race or ethnicity, your height and weight, your postal address, your occupation, employment status, education level and housing status, your household income and income bracket, your employer's name, and whether you are a union member, a veteran or serving. Our servers will also store a citizenship, marital status or disability status if one is ever sent to them; nothing in the web app asks you for those three, and the screens in the native iOS app that ask about marital status and disability keep your answers on the device and send them nowhere. We also hold personal data about people who are not Cravora users, because you gave it to us: for each emergency contact you add, their name, their relationship to you, their phone number and, if you enter one, their email address. We do not tell them we hold it. We use those numbers to send the alerts described below, which means they reach the SMS provider that sends them. Emergency contacts are not the only non-users we hold data about. The family step in onboarding asks you to add family members, and for each one we store the name you type, their relationship to you, their date of birth, the age we work out from that date, and the gender you pick. The screen offers spouse or partner, child, parent, sibling, grandparent, grandchild and other, but we keep only five relationship values: a grandparent is stored as a parent, and a grandchild as a child. We do not tell those people we hold this either. The endpoint behind that step accepts and stores far more than the screen asks for — health conditions and special needs, an insurance provider and policy number, an employer, a pediatrician, a school or daycare, immunisation records, a custody arrangement, whether the person is pregnant and their due date, a care level, a living arrangement, and whether you hold power of attorney or act as their health proxy. No screen in the app asks you for any of that today, so nothing fills those fields.
• Health and wellness data: your coach conversations, health journal and symptom entries, medications and doses you log, body measurements, your mood, pain and energy logs, your food and hydration logs, your sleep records, your digestive and bowel logs, your asthma, diabetes and other chronic-condition records, the photos and voice notes you attach to a health record, your answers to the mental-health questionnaires in the app, question by question, together with the score they add up to, your reproductive health data if you use those trackers, meaning cycle, fertility, pregnancy and menopause, and the wearable streams you choose to connect, such as steps, sleep, heart rate, blood pressure, ECG, glucose, stress, recovery, and workouts. The lifestyle step in onboarding belongs in this category too, and it has not been named here before. It asks for, and we then hold, how often you exercise and how active you are, your fitness and nutrition goals, whether you have a gym membership or a personal trainer, the dietary preferences you pick from a fixed list of nine, how much water you drink and how regular your meals are, your usual sleep hours, how well you sleep and your bedtime routine, whether you smoke and whether you want to stop, how often you drink alcohol, and your stress level and your work-life balance. The endpoint behind that step used to accept thirty answers more than the screen asks for, and no longer does. It took recreational drug use, prescription misuse, cannabis use, a substance-use-disorder history and the treatment and support that went with it; sleep disorders and sleep aids; fuller detail on smoking and drinking than the screen collects, including years smoked, packs a day, quit attempts, e-cigarettes and smokeless tobacco, drinks per occasion and binge drinking; and answers about your sexual and reproductive health — whether you were sexually active, the contraception you used, your family planning, your pregnancy history and when you were last tested for a sexually transmitted infection. Those columns have been dropped from our database and the endpoint now refuses any answer the screen does not ask for, so nothing can fill them again. What we still hold about your smoking and your drinking is health data, and is protected in the same way as the rest of this section.
• Benefits and insurance: your plan and eligibility, the benefits you look at, and any marketplace enrolments. Your insurance card is worth naming on its own. The card step in onboarding keeps the member, policy and group numbers, the insurer's name and the effective and expiry dates. On the insurance card screen you can also upload photographs of the front and back of the card. We read those on our own servers rather than at an outside company, and we delete the image file once that reading has finished, whether it succeeded or failed.
• Payment: your subscription and purchase records, which means the amount, the currency, the status, and the references Stripe gives us for your customer, subscription, invoice and payment. Stripe handles the card itself. We hold no card details at all, not even the last four digits.
• Usage and device: the events the app sends, performance data, your device and operating system, IP address, approximate location, and cookie or SDK identifiers. Two places ask for your exact position, and they do not behave the same way. If you press the 'use my location' button in the guided provider search, your browser asks your permission and your coordinates are put into the address of the search results page, which our servers see; nothing on that page reads them, so they change nothing about what you are shown. The map view on the benefits page asks for your position the moment you open it, with no button to press, and those coordinates do not come to us — they stay in your browser, where they centre the map and filter what it shows. Opening that map also loads Google's maps script into your browser, so Google learns your IP address. There is no provider map.
• Communications and support: the messages you send our support team, the delivery logs for the notifications we send you, and, if you use the community, your posts, your comments and your direct messages. It also covers what you tell our moderators. When you report a post, a comment or a group, we keep which item you reported, the reason it was filed under, any detail you type, and a snapshot of what you reported — the post or comment as it was written, or the group's name — together with the account answerable for it. We keep that snapshot even if the content is later edited or taken down. If we remove something of yours and you appeal, we keep what you write in the appeal and the copy of the removed content, and the moderator who decides sees both beside your name.
• Safety records: if the crisis scan described below finds something in a message you write to the coach, if a mental-health questionnaire returns a positive answer on the self-harm question, or if a blood-glucose reading reaches us above 250 mg/dL or below 70 mg/dL, we store a record of it. That record holds your account, what was detected, and the material behind it: for a coach message, the message you wrote in full and word for word, not a trimmed excerpt; for a questionnaire, your score on the self-harm item and your total; for a blood-glucose reading, the reading, its units and the fact that an app signed in to your account reported it. Our trained reviewers see that record next to your name and your email address. Two of those three need saying plainly, because nothing we ship feeds them. No screen in the app sends us that questionnaire today. The endpoint that records a PHQ-9 or GAD-7 is live, any signed-in account can reach it, and it does exactly what is described here — but the web app's assessments tab is an empty placeholder, and the questionnaire screen in the native iOS app scores your answers on your own device and sends nothing. The blood-glucose endpoints are live in the same way, and no screen in our web or mobile app posts a reading to them.
• Consent and compliance records: which version of this policy and the terms you accepted and when, the consents you gave or withdrew, parental consent records, and audit logs.

We use your data to run the service you asked for, to keep it safe, and to meet obligations the law puts on us. In Europe and the United Kingdom each purpose rests on a specific legal basis, listed below.

For most health data our basis is your explicit consent. Withdrawal stops the processing from that point on; it does not undo processing that already happened while your consent was in place. The safety processing is the exception. The crisis scan that runs on every message you write to the coach, the same treatment of a positive self-harm answer on a mental-health questionnaire, the review by our staff of a flagged record — including the record that a critical blood-sugar reading posted to our health endpoints by an app signed in to your account now opens — and the text messages to your emergency contacts that a coach signal or a critical device reading is built to trigger (text messaging is not switched on yet, so none is sent today), all rest on our legitimate interest, and yours, in preventing serious harm, and on vital interests in an emergency. They do not rest on your consent, none of them has a switch, and you cannot withdraw them while you use those features.

Where a feature does have a switch, turning it off is the withdrawal. But do not assume a switch stops processing simply because it is there, so here is what each of the ones this section names actually does. Three of them refuse something. Health Insights is on your privacy settings screen and starts off; while it is off, some of our insight features refuse to run on your health data. One thing deliberately survives that refusal, because safety and supply output is not personalisation: critical risk alerts, drug-interaction warnings, duplicate-medication warnings and the reminder that a prescription needs refilling still reach you whatever you have chosen. It reaches the AI coach only in part. Every message you send the coach still carries your tracking data to give it context, whatever you have chosen here, but your health score, with the scores it is built from, is worked out and added only while Health Insights is on, and turning the switch off stops that from your next message, including in earlier coach replies that could have repeated it. Anonymised research sharing, which is on the privacy screen for connected devices on the web and in settings in the mobile app, caps what a researcher can see: turn it off and you stop counting towards the consented population a researcher's cohort query is limited to. No records of yours are read either way, because the cohort figures a researcher sees today are deterministic placeholders rather than real patient data.

Save search history, on the same privacy settings screen as Health Insights, is the third, and unlike Health Insights it starts switched on, for everyone, in every country. While it is on, a search you run in the benefits area is recorded against your account — that you searched, how many results came back, roughly how long what you typed was and how many filters you had set — and your browser keeps its own copies as well, the last ten searches on the benefits screen and the last five in the app-wide search box. The words you typed are no longer stored against your account, though searches recorded before we made that change still hold them. While it is off nothing is recorded against your account, and the next time you open one of those screens your browser's copies are cleared and no new ones are kept.

Two more are recorded and nothing else. Health analytics and personalised recommendations are asked once, during onboarding, and you can withdraw either from the consent log in your settings. We record the granting and the withdrawal, that record is auditable and it goes into the copy of your data you can ask us for, and personalised recommendations is read in one further place, to work out the privacy score we show you. Past that, nothing in the product consults either one before collecting or processing anything. Withdrawing one changes the record of your decision, not what we do.

The symptom, vital-sign, medication-adherence and activity collection consents are different again. Our servers no longer define those consents and the endpoint that recorded them is deleted, so nothing is recorded for them and nothing in the product reads them. And there is no screen that offers them anywhere in the product — not on the web, and not in our mobile app. We would rather say that than leave you looking for a control that does not exist.

The AI coach is a gap of its own. There is no switch that stops the coach sending your health data to its providers; the one part of it that follows a switch is your health score, which is sent only while Health Insights is on. The way to stop that flow is to stop using the coach and delete what it has stored. The section on the coach below names the other AI features that work the same way.

Analytics needs a separate word. No cookie category is pre-ticked: analytics, functional and marketing all start switched off, in every country, and if you have made no choice at all they are treated as off. The analytics that run in your browser only run once you turn them on, with one exception: on our public website, and on the sign-in, sign-up and other account screens, each page times how long it takes to load and posts those timings, with the page's address, back to our own servers, where they go into our application logs, which Datadog receives where we have configured it. A copy goes to Google as well, but only where you have turned analytics on, and never from the sign-in, sign-up and other account screens. The record of each onboarding step our own servers send — which used to be sent whatever you had chosen — now needs your consent as well, and separately needs an operator switch that is off by default and is off today, so nothing is sent from our servers at the moment.

Two flows sit outside that switch, and we would rather tell you than let you assume otherwise. First, our own servers record some product events against your account whatever you have chosen — the benefit cards you click and the clicks that take you out to a provider's own website among them. The cookie switch decides what runs in your browser and what leaves for an analytics vendor; it does not decide whether we record. Your searches used to be in that set and are not any more: save search history decides those. Second, where we have switched on event forwarding to Segment, that forwarding reads the events we have already stored and sends them on with your account id attached, without checking your cookie answer. It does check three other things: your searches go only while save search history is on, nothing at all goes for an account that has objected to our product analytics, and nothing recorded before we made this change is forwarded for anyone. There is no switch for that objection on any screen, so the way to make one is to write to privacy@cravora.com — and say in the same message if you want your stored events removed as well.

• Creating and securing your account and providing the core service. Basis: performance of our contract with you, plus legal obligation for some security and record-keeping.
• Running the AI wellness coach and the health and wellness features. Basis: our contract with you for the service and, for the health data, explicit consent. For the analysis of your health data into personalised insights, that consent is the separate Health Insights switch, which starts off and whose granting and withdrawal we both record. Safety and supply output is outside that switch on purpose: critical risk alerts, drug-interaction warnings, duplicate-medication warnings and the warning that a prescription is due for a refill run whether Health Insights is on or off, on our legitimate interest in preventing harm rather than on your consent. For the AI coach itself there is no switch yet, so the consent there is the one you give by choosing to use it, with one exception: the health score the coach is given is Health Insights processing, so it is worked out and sent only while that switch is on, and it stops when you turn the switch off.
• Connecting and processing the wearable data you link. Basis: your explicit consent, given by connecting the device.
• Verifying who you are where a feature requires it. Basis: our contract with you, and our legitimate interest in preventing fraud and impersonation. Today that means your email address, and a one-time code to your phone where a feature asks for one. Document-based identity verification does not actually run: the endpoint that takes an identity document and a selfie stores what you send it, the wiring to an outside verification vendor is present but switched off, and nothing in the product checks the document afterwards. We used to name a legal obligation here as well. Nothing is being discharged while no check runs, so we have dropped it.
• Helping you find benefits, providers, coaching, and marketplace offers. Basis: our contract with you, and your consent where health data is involved.
• Taking payment and preventing fraud. Basis: our contract with you, and our legitimate interest in preventing fraud.
• Product analytics and improving the service. Basis: your consent, for the analytics that run in your browser and for the onboarding events our servers send. Those onboarding events used to rest on our legitimate interest and now follow the same switch. A third set does not follow it. Our own servers store some product events against your account whether or not you have turned analytics on: the benefit cards you view and click, the claims you record, the kinds of filter you apply — the name of the field, never the value you chose — and the clicks that take you out to a provider's own website, which record which benefit you left from and when, and, when you switch insurance plan, the yearly saving we estimated for it and which plans you moved between. Your searches in the benefits area are in this set too, but with a switch: they are recorded only while save search history is on in your privacy settings, which starts on. Even then we no longer keep what you typed — a search record holds the number of results, the number of filters and a rough length for your words; searches recorded before that change still hold the words themselves. Basis for that set: our legitimate interest in understanding how the product is used. You can object at privacy@cravora.com, and be clear what that does: from then on nothing of yours is forwarded to Segment, including events we stored earlier and had not yet sent. It does not stop us recording them, and it does not delete what we already hold — ask in the same message if you want either of those. Where we have switched on event forwarding, those stored events are what gets sent to Segment, except where your objection or that switch holds them back.
• Marketing emails and messages. Basis: your consent, which you can withdraw at any time.
• Stopping bulk automated sign-ups, using a third-party CAPTCHA on the sign-up form and the public contact form. Basis: our legitimate interest in keeping the service usable and secure.
• Scanning your coach messages for crisis signals, treating a positive self-harm answer on a mental-health questionnaire the same way, putting the flagged record, and the record a critical blood-glucose reading creates, in front of our trained reviewers, and alerting your emergency contacts where a coach signal or a reading sent to us by an app signed in to your account is critical. Text messaging is not switched on yet, so today that alert is not sent and no emergency contact is told anything; the rest of this item describes the alert as it will work once it is. Basis: our legitimate interest, and yours, in preventing serious harm, and vital interests in an emergency. None of it has a switch. That alert also processes your emergency contact's own data. We hold the phone number you gave us for them, and we text them that we have detected an urgent situation for you. The first message names you by first name. Where the trigger was a coach signal or a critical blood-glucose reading and the alert is not resolved, we text again at about fifteen and thirty minutes; those messages name you in full, say you have not responded — and, if nothing reached you at all, that we could not deliver the alert to you on any channel — and say how long ago we raised it. A critical reading of any other kind, a heart rate included, is not followed up that way: those contacts are texted once. If we hold no name for you, none of those texts names you. They agreed to none of it — you gave us their number — and because it is a safety message we send it outside the opt-in check and the daily limit that hold back our other texts. Basis for that: vital interests, theirs and yours, in an emergency. Please tell anyone you list as a contact that you have listed them, and what they may receive.
• Legal compliance and defending legal claims. Basis: legal obligation and our legitimate interests.

When you write to the wellness coach, your message is sent to a third-party AI provider so it can generate the reply. For typed messages that provider is either OpenAI or Anthropic, and none of it runs on models we host ourselves.

A voice provider receives the coach's replies only if you have switched Read aloud on, under Accessibility in your settings. It starts switched off, and while it is off nothing is sent to be spoken. With it on, and where one is configured, each reply is sent to ElevenLabs or Google Cloud Text-to-Speech so it can be read to you. With it on and neither configured, your own device speaks the reply: it goes no further than our own servers, and no outside company receives it.

The microphone button in the coach half works, and it fails without telling you. Pressing it does ask your browser for the microphone, and it does record you while the timer runs. That recording is then never transcribed, because the key the transcription needs is not available in your browser, and it never leaves your device: it is held only in the page and goes when you close it. Nothing on screen explains why nothing happened. We should also be straight about what exists behind it. We ship an endpoint that sends a recording to OpenAI to be transcribed, and any ordinary member account can reach it, though the portal accounts we issue to employers, coaches, partners and researchers cannot; nothing in the app calls it today. We name OpenAI here rather than tell you no such path exists.

There is also a knowledge-base lookup on this path, and it does not run. We built a step that would send your message to OpenAI a second time to be turned into a numerical embedding, and send that embedding to a vector-database provider to search our own knowledge base. Neither Pinecone nor Weaviate is installed in the product, so the vector-database client cannot even be created: the lookup fails before your message is sent anywhere, and the coach answers without it. No embedding of your message reaches OpenAI, Pinecone or Weaviate today. If we switch that step on, we will say so here first.

We send your message exactly as you wrote it, together with the profile the coach uses to answer: your age, your country and region, the conditions you have recorded, your goals, your health score with the scores it is built from and their trends, but only while Health Insights is on under Privacy in your settings (while it is off, or if we cannot check the setting, the coach is told instead that no score is included and why, and is asked not to work one out), the medications and doses you have logged, your recent symptoms with their dates and severity, your upcoming appointments including the provider's name, the benefits available to you, and the readings from any device you have connected, such as steps, sleep, and resting and average heart rate. Your display name is attached to that. If you have not set a display name, your email address is attached instead. This describes what the coach sends today and may not be exhaustive.

Not every message carries all of it. When what you write reads as a symptom report, as something you are feeling, as a goal, or as preparation for an appointment, the coach takes a different route that sends less: your message and the last five or ten turns of the conversation, plus the titles of your goals on the goal route, and the names only of your medicines and symptoms on the appointment route. Every other message, including medication questions, benefit questions and general health questions, carries the full list above. That list is the most that is sent, not the least.

Earlier turns go with it. Each time you write, up to fifty messages from that conversation, yours and the coach's, are sent to the AI provider again alongside the new one. In a conversation longer than fifty turns it is the fifty earliest that are re-sent, so whatever you disclosed at the start of a thread keeps leaving with every message you send in it. While Health Insights is off, a reply of the coach's that could have drawn on your health score — one written while the switch was on, or before we began marking which replies had the score — is left out of what is re-sent, and a short note saying so goes in its place; your own messages are re-sent as you wrote them.

We do not strip, mask, tokenise, or replace any of it first. There is no de-identification step anywhere on this path. You should not type anything into the coach that you would not want a third-party provider to receive.

This applies to every member, including members under eighteen. An account can be opened from the age of thirteen, and the coach draws no distinction: a thirteen-year-old's conditions, medications, symptoms, wearable readings and age go to the same third-party AI provider on the same terms as an adult's. Nothing on the coach path checks a member's age or looks for a parent's consent before sending.

Something else happens to every message you send the coach, and you should know it before you use it. Before your message goes anywhere else, we scan it for signs of a crisis: suicidal thoughts, self-harm, domestic violence, substance abuse, or a medical emergency. That scan runs automatically, on every message, and it runs on our own servers. Most messages match nothing and no record is made. If a message does match, three things follow. We show you crisis resources. We write a record to our database holding your account, what was detected, and the message you wrote, the whole of it, word for word, not an extract. And we put that record in a queue that our trained staff work through, emailing our administrators that it is waiting, which means a person at Cravora reads your message in full alongside your name and your email address.

If the signal is assessed as critical, meaning a plan, the means, the intent and a timeline are all present in what you wrote, we go further, and we do it without asking you at that moment. We email our administrators. The design also sends a text message to the emergency contacts saved on your account, but text messaging is not switched on in Cravora yet: until it is, no text goes to your contacts, nobody outside Cravora is told, and in an emergency you need to call your local emergency number yourself. Here is how that text will work once it is switched on. Who gets that text depends on something you may never have set. If you have marked a contact primary and that contact has a phone number, your primary contacts are texted first. If you have not marked anyone primary, and nothing marks one for you, every contact on your account is texted straight away. If the alarm is still unresolved we text that first group again about fifteen minutes later, and every contact on your account about thirty minutes later. The first text names you by first name; the two later ones name you in full. All of them ask the person to check on you, and none of them carries what you wrote. We do this to prevent serious harm. It still means information about you reaches another person without your agreement in the moment, which is why it is set out here rather than buried.

Two things happen without the coach being involved at all, and they are not the same as each other.

If you complete a PHQ-9 questionnaire in the app and answer its self-harm question, item 9, with anything above zero, we write the same kind of record, holding your score on that item and your total, and the same staff review it. The GAD-7 has no self-harm question and never triggers this. A flagged questionnaire reaches the review queue and nothing else: it sends no text message to anyone.

A critical health reading is different again. If a blood-glucose reading that reaches us is above 250 mg/dL or below 70 mg/dL, or a heart rate is above 120 or below 50, we text those same emergency contacts, again without asking you first. Each such reading also alerts you. Unless it is folded into an alert already open, which is described below, we send you a push notification and, if we hold your phone number, a text message, and both carry the reading itself and what we say it means. Both are marked urgent, so they reach you even if you have Do Not Disturb on, have switched that kind of notification off, or have reached your daily message limit. A heart rate above 100 or below 60 alerts you the same way but texts nobody else. Until text messaging is switched on, none of the text messages in this paragraph is sent, to you or to anyone else.

A critical blood-glucose reading goes further. It opens a record holding your account and the reading, on the same crisis table our trained staff review as a coach crisis, and we email our administrators that it is waiting, so a member of our staff can read the reading beside your name and your email address. One limit on that is worth knowing: the queue screen they work from lists only records still marked pending, and a reading whose alert reached you or one of your contacts is marked escalated at once, so it drops off that screen. And unless the alert is resolved we text your emergency contacts again about fifteen minutes later, and every contact on your account about thirty minutes later, naming you in full. What resolves an alert is the action on it that says you are OK, and that action works only on the Emergency Escalation entry in your notifications list in the web app; on the alert itself, and on the button on your phone's notification, the press is recorded on your account and usually stops nothing. A second blood-glucose reading of the same kind within the hour is normally folded into the alert already open: you get a push carrying the new reading, but no text message to you about it, no second record and nobody else contacted — and if that check cannot be run we start a second round instead. A critical heart rate is not treated this way: it writes no record for our staff, and no follow-up text goes out after the first one. Until text messaging is switched on, none of these texts is sent.

Be careful about which readings that runs on, because it is narrower than it sounds. It runs on readings sent to our health endpoints by an app signed in to your account, such as your phone's health app, and those endpoints act on the reading without checking that any device is connected. It does not run on the wearables you connect by signing in to the maker's account, such as Dexcom, FreeStyle Libre, Fitbit, Garmin, Oura or Withings. We store those readings, and we never check them against these thresholds. Nothing is watching them for you. You do not have to have opened the coach for any of this to happen.

The coach is informational. It is not a clinician, it does not diagnose, it does not prescribe, and it can be wrong. Every coach surface tells you that you are talking to an AI system rather than a person. Nothing the coach produces is used to make a decision about you by automated means alone where that decision would have a legal effect or similarly significant consequences.

Using the coach is your choice, and it is the main control over this. One thing is not your choice at the moment it happens: the coach can start a conversation with you. Where a check-in has been scheduled on your account, a job that runs every minute sends the same profile to the AI provider and writes the reply into a new conversation while you are not there. There is a Coach settings screen for those check-ins, with quiet hours, an active-hours window, daily limits and a switch for each kind of check-in, and it decides nothing. What you save there is stored and never read back, and the screen shows you our fixed values rather than the ones you saved. The job uses those fixed values instead: no quiet hours at all, a window of 08:00 to 20:00 in the timezone saved on your account, or UTC if we hold none, and a cap per day of one daily check-in, ten medication reminders, three health insights and one of each other kind. Switching a kind of check-in off on that screen does not stop it. Until we connect that screen, email privacy@cravora.com and ask us to stop the check-ins on your account.

Several other features send health information to the same AI provider without going through the chat, and they do not all work the same way. The AI summary on your insights panel has a switch: it runs only while Health Insights is turned on under Privacy in your settings, and it starts off, so turning it off stops that summary. The others have no switch. The analysis of any lab result or medical document you upload has none. Nor do the appointment-preparation tools, which send your recent symptom logs, up to twenty of your health journal entries, the medicines you have logged with their doses, the conditions you have recorded, your age, and the appointment itself, including the provider's name and the notes you wrote on it. Nor does the AI-guided insurance enrolment recommendation, which sends your health and plan profile. One more has no screen at all. We ship an endpoint that writes a coaching note about the habits you are tracking, and calling it sends the AI provider, for each habit you have active, its name, its description, its category, your current and longest streak, your completion rate and your total completions. Any signed-in account can reach it for its own habits, and an administrator can reach it for anyone's. Nothing in the app calls it today, and it has no switch either. So: turn Health Insights off to stop the insights summary and the health score the coach is given, and if you do not want your health information sent to a third-party AI provider in the form described above, do not use the coach, document analysis, the appointment-preparation tools, or the AI enrolment recommendation.

Strictly necessary cookies keep you signed in and keep the service secure. They are always on and cannot be switched off, because without them the product does not work.

Beyond those, you choose. The analytics category decides whether Google Analytics and PostHog load in your browser: with it off, neither one loads. They are loaded on our public website and also on the onboarding, welcome and payment screens, which sit in the same part of the app; they are not loaded on the sign-in and sign-up screens, and not on the rest of the signed-in app. The functional category decides whether PostHog captures your interactions automatically. It only has an effect where you have turned analytics on as well, because with analytics off PostHog is never loaded at all. There are no advertising pixels or ad-network trackers in the product.

Be precise about what those switches do. They decide what loads when a page opens, and your choice is read at that moment. Turning analytics on does not start Google Analytics or PostHog in the tab you are already looking at, and turning analytics off does not remove a script that has already loaded there. From the next time a page is genuinely loaded, the choice you last saved is the one that applies. One consequence is worth spelling out: moving around Cravora does not reload the page, so a PostHog that started on our public pages or on the onboarding screens keeps running in that same tab after you move into the signed-in app, and goes on capturing there until the page is reloaded.

Four third-party things sit outside those categories entirely. A fifth, Sentry, sits partly inside them, and we set out below which half is which.

The first is the CAPTCHA on the sign-up form and the public contact form. It is Google reCAPTCHA. The code carries unused wiring for hCaptcha and Cloudflare Turnstile, but nothing in the product selects either of them, so neither company receives anything today. The challenge itself runs in your browser, before you have an account and before any consent choice of yours exists, so Google receives your IP address that way, and it sets Google's cookies. On the public contact form we also send Google your IP address when we check the result; on the sign-up form our check sends Google only the token. We use it to stop bulk automated sign-ups, and there is no switch for it today.

The second is Google Maps. If you switch the Benefits page to its map view, it asks your browser for your exact position as soon as it opens, with nothing for you to press, and we load Google's map code straight from maps.googleapis.com, so Google receives your IP address and learns the request came from Cravora. If you allow the position request, we hand your coordinates to that Google map code running in your browser, to centre the map and to place a 'Your location' marker on it. What that Google code then sends back to Google is not something we control. We do not send your coordinates to our own servers and we do not store them, and nothing on that page uses them to work out which benefits are near you. This one runs inside the signed-in app, it is not covered by the cookie categories, and there is no switch for it today.

The third is not a script at all. If you use Cravora in Chinese, Japanese or Korean, your browser fetches the fonts for those characters straight from Google's font servers at fonts.gstatic.com, so Google receives your IP address. That happens on every screen in those languages, signed in or not. Those are the only fonts we load from Google at all; every other font is served from us.

The fourth is a video player. Some help pages carry a tutorial video hosted by YouTube or Vimeo. Nothing is requested from either company when the page opens: what you see is a still panel drawn by us, which names the company before you press anything. Press play and we load that company's player, which tells them your IP address and lets them set their own cookies. We use YouTube's youtube-nocookie.com address, which reduces what they set, and we ask Vimeo not to track; neither stops the company setting anything, and neither stops it receiving your IP address. Nothing is remembered, so the next video you meet starts as a still panel again. The thumbnail pictures on the video, resource and community story pages are fetched by our servers and served from us, so opening one of those lists sends nothing to the companies that host them. None of this is covered by the cookie categories; the press is the choice.

The fifth is Sentry, and it is the one thing on this list that your answer here decides, in part. Where a Sentry connection is configured, Sentry's error reporting loads on every page whatever you have chosen here, but what it sends follows a different control: the Crash Reporting switch under Privacy in your settings, which starts on. While that switch is on we send Sentry the errors your browser hits, the console errors and warnings, the requests that come back a failure, and the address of the page you were on; turning it off stops all of it. That answer is held against your account and mirrored into a cookie in the browser you signed in on, so it applies everywhere on Cravora in that browser, our public pages included. Pressing Sign out removes that cookie, and in a browser nobody has signed in on there is no answer to read and the reporting goes on. How long the pages you open take to load is measured too, and that needs both the Crash Reporting switch on and the analytics category accepted here. So does the session replay: nothing is recorded for anyone who has declined analytics, has not answered, or has Crash Reporting off, and turning either one off stops the recorder in the page you are looking at rather than at the next reload — which is not true of the Google Analytics and PostHog scripts described above. With both on, the recorder runs in every session you open, and nothing is sent from a session in which nothing goes wrong. Once something does go wrong, the part held in memory is sent and the recording then continues, and keeps being sent every few seconds, for the rest of that session. Withdrawing either consent discards what it was holding if nothing had gone wrong, and sends the last part if something had. We set all of it out in the section on who we share with.

Our own servers can also send PostHog a record of each onboarding step you complete, keyed to your account, and can store that record in our own database. Both follow the analytics category exactly as the browser scripts do: turn analytics off, or make no choice at all, and neither happens. We should be plain about the rest of it, because 'follows your choice' would otherwise imply more than it does: this sending is off entirely at the moment. Each half is behind its own switch our operators set — one for the sending, one for the storing — both are off by default, and while they are off nothing is sent or stored no matter what you have chosen. If we turn it on, what is described here is what will happen.

Google Analytics is loaded in its GA4 form, which truncates IP addresses before storing them, and we set the IP anonymisation flag as well. One thing we want to be precise about: the app does not set Google's cross-device advertising signals either way. Whether they are active is governed by the settings on our Google Analytics account rather than by anything in the product.

The preferences panel also shows a marketing category. Be aware that it currently switches nothing on or off, because no marketing or advertising vendor is loaded by the product today. We record the choice you make so that it already applies if that ever changes.

Two things about how long your answer lasts. It is stored in a cookie on the device you answered on, and that cookie lasts a year. We do not ask you again in that time, and we do not ask you again when this policy changes. And it is stored on the device rather than against your account, so it does not follow you to another browser or another phone; on a device that has not answered, everything that is not strictly necessary is treated as off.

In Europe, the United Kingdom, and other opt-in regions we ask before setting anything that is not strictly necessary. No cookie category is pre-ticked anywhere: analytics, functional, and marketing all start switched off in every country, and if you have made no choice at all, all three are treated as off.

Several in-app privacy toggles do not follow that rule. Save search history, save browsing history and share my country all start switched on, for everyone, in every country. Our code treats save browsing history and share my country as functional preferences rather than as tracking consents, so no regional rule touches them. Save search history is a tracking consent in our code now, but it still starts on, for everyone, in every country: the stored default is on, and we record on that basis before you have opened this screen. The one place the European rule reaches it is Reset to defaults on that screen, which switches it off for anyone we place in Europe or the United Kingdom, or cannot place at all. The Europe and United Kingdom section sets that out.

Save browsing history still decides nothing. We keep no browsing-history record for it to turn off, the only thing that reads it is the privacy score shown on the same screen, and turning it off records your preference and nothing more. We will say so here when that changes.

Save search history now decides three things at once. While it is on, a search you run in the benefits area is recorded against your account, and your browser keeps its own copies as well — the last ten searches on the benefits screen, and the last five in the app-wide search box. What we record against your account is no longer the words you typed or the values of your filters: it is how many results came back, a band for the length of what you typed, and how many filters you had set. While it is off, none of that is recorded, the copies your browser is already holding are cleared the next time you open one of those screens, and the searches we have already stored are not passed on to Segment. Your answer applies from the moment you save it. It does not undo a recording that already happened, and it does not remove the searches already stored against your account.

We have also taken several controls off the privacy settings screen, because nothing in the product ever read them: show profile photo, show activity status, anonymous mode, discoverable by others, and the three Only Me, Friends, Community and Public choosers for health, activity and profile data. What you had already stored for them is untouched and still comes out in a data export. Profile visibility keeps its control and loses its claim: it is still recorded against your account, but nothing consults it to decide who can see you, and the only thing that reads it is the privacy score on the same screen. Show in leaderboards also stays, and it stays an older second control that nothing reads. And a privacy record created by opening that screen now starts with the same values as one created anywhere else in the product: the screen no longer writes its own, so profile visibility starts as private rather than as 'friends', and the values behind show activity status and discoverable by others start off rather than on.

If you have an account, you can change any of this at any time in your privacy settings. If you do not, there is a gap you should know about: once you have answered the cookie banner it does not come back, and we have no cookie-preferences control on our public pages. So without an account the only ways to change the answer you gave are to clear this site's data in your browser, which puts you back to everything non-essential being off, or to write to privacy@cravora.com.

We share personal data with the service providers listed below, each of which processes it on our behalf for one specific job. We should be straight with you about the list itself: it is not yet our complete register of processors. We are still working through the remaining vendors, deciding for each one whether it actually receives your data or is only a dependency, and we will not call this section exhaustive until that is finished. One recipient we can name right now, because our Terms of Service already names it, is missing from the list below: api.qrserver.com, an outside QR-code service. When we show the QR code for your referral link, our servers send that link to it so it can draw the code. The QR button on the benefits comparison screen goes further: it opens that service in your own browser with the address of the page you are on inside the request, so the service receives that address and your IP address.

We also share it with the independent providers, coaches, insurers, pharmacies, and marketplace sellers you choose to engage, who then act on their own account and under their own privacy policies, and with regulators or law enforcement where the law requires it or where it is needed to protect someone's safety. If Cravora is ever merged or acquired, your data may pass to the successor, still governed by this policy.

A family member you invite is a recipient too, and that belongs here rather than being left for you to find. When you create a family share, on the sharing screen under your connected devices, you choose which categories it covers and whether that person can write as well as read. The share does nothing until they accept it. Once they have, and while it stays active, a share covering medications lets them see the names, doses and frequencies of the medicines you are taking and your adherence figures, and the family dashboard shows them how many upcoming appointments, active medications and active goals you have, together with a score we calculate from those counts. Where you granted writing as well, they can log a dose or set a reminder straight onto your medication record, and nothing asks you at the time. Removing the share on that same screen ends all of it. One switch you should not rely on: the connected-devices privacy screen shows a Share with family switch, which starts off, and it decides nothing. No code reads it, so turning it on grants nobody access, and leaving it off stops nobody who holds a share you created and they accepted.

Some of it goes to other Cravora users. If you use the community, what you post, what you comment on and what you send as a direct message goes to the people you send it to. A post also carries the name and the profile picture held on your account, shown to every signed-in member who can see the post, and it carries the country and city held on your account. Your privacy settings show Share country and Share city switches, and Share city starts off, but nothing in the code that creates a post reads either of them: the country and city are attached either way, so those two switches are not controls over what a post carries. Leaderboards work differently. No account is on a public leaderboard until you join it from the leaderboard screen itself, and what it shows then is a handle you chose, or the word Anonymous, next to your score. Your real name is never published there. The Show in leaderboards switch on the privacy screen is an older second control that nothing reads.

One sharing path is not triggered by a choice you make at the time. If the coach's crisis scan flags something you wrote, if a mental-health questionnaire returns a positive self-harm answer, or if a critical blood-glucose reading is sent to us by an app signed in to your account, our own trained reviewers can read that record — the full text of your message, or the reading and its units — next to your name and your email address, and our administrators are emailed that a review is waiting. That email names how serious the flag is and what kind of crisis it concerns, so our email provider sees those words; it does not name you. If a coach signal is assessed as critical, or if a reading sent to us by an app signed in to your account is critical, we also email our administrators, and the design sends a text message to the emergency contacts saved on your account. Text messaging is not switched on yet, so today no such text is sent; once it is, who gets that text works like this. If you have marked at least one contact as primary and that contact has a phone number, your primary contacts are texted first. If you have not, every contact you have saved is texted straight away — and because nothing marks a contact primary unless you tick that box yourself, that is the usual case. Where the alert came from a coach signal or a critical blood-glucose reading and you have not acted on it, we text that same first group again about fifteen minutes later, and every contact you have saved about thirty minutes later. A critical reading of any other kind, a heart rate included, is not followed up that way: those contacts are texted once. Those texts go out through our SMS provider, like any other message we send.

We do not sell your personal data, for money or for anything else of value, and we do not share it for cross-context behavioural advertising. That is a statement about how the product is built: there are no advertising pixels and no ad-network trackers anywhere in it.

On sponsor reporting: where an employer or insurer pays for your access, any group-level report is designed to withhold its wellness metrics for any group smaller than ten people, although the number of people in the group is still shown. Group-level reporting IS produced today: an employer administrator sees, live on every request, how many seats are used, how many members are active, and a per-department breakdown that includes the exact number of people in each department. The wellness metrics for a department smaller than ten are withheld; the headcount is not. Separately from any report, an administrator at your organisation can see the member roster described in the section on who is responsible for your data.

• Vercel, which hosts and runs the application, and the managed database provider that stores what is in it. We will name that second one here as soon as the register described above is finished.
• Stripe, for taking payments.
• No outside identity vendor. The wiring for Stripe Identity, Jumio and Onfido exists in the code but none of it is switched on, so none of those companies receives your images. If an identity check is run, the document photo and any selfie stay with us, and anyone who looks at them is our own staff. We should also say what the product actually does today: no screen in the app asks you for a document photo or a selfie. The endpoint that records an identity check is reachable by any signed-in account, but nothing in the app calls it, and there is no staff review queue in the product that reads what it stores. If that changes, or if we ever send these images to a vendor, we will name it here first.
• Twilio, or Amazon SNS where that is configured, for text messages and one-time passcodes, including the crisis alerts to your emergency contacts. Some of those texts can carry health information, by a route worth spelling out. If you text INFO to our number, we text back your most recent notification — and for a medication reminder that is the drug name and the dose. If you text SNOOZE, that reminder is queued to be sent again with text message as one of its channels, so the drug name and the dose can arrive that way too. We do not otherwise send medication reminders by text: they go to your device as a push and in-app notification. Prescription notices are not sent at all today, by text or by anything else. Neither provider is switched on yet, so no text message of any kind is sent today.
• Our email provider, which is SendGrid, Amazon SES or Resend depending on how the service is configured, for every email we send you. That covers verification, security alerts, parental-consent links and marketing messages, and it also covers messages carrying health information: an appointment confirmation names the appointment, and a health report you ask us to email you goes out as a PDF of the sections and dates you chose. We do not send medication reminders or weekly summaries by email today. Separately, if you sign up for our newsletter, and where we have configured it, we send Mailchimp your email address, your first and last name and your language, and we tell Mailchimp when you unsubscribe. If instead you ask us to contact you through our lead form, we send your country as well. More things count as unsubscribing than the link in the mail, so here is the whole list. Whether you unsubscribe from a link in the mail, turn the Newsletter or Promotional switch off in your notification settings, turn Email off on that same screen, withdraw the marketing consent in your consent log — which is also what leaving the marketing box unticked when you sign up records — restore a settings file that turns one of those three switches off, or have another device you are signed in on sync that preference across, we send Mailchimp one instruction: mark this contact unsubscribed. Nothing else about you travels with it, and the contact is named by the MD5 fingerprint of your email address, which is how Mailchimp identifies a contact — a way of naming you, not a protection, since it is computed from the address itself. Where no Mailchimp account is configured for the service none of this happens at all and no request leaves us; and where you were never added to that audience the request finds no contact and changes nothing. You are in that audience only if you confirmed a sign-up from your inbox: because your address belongs to a Cravora account, both our newsletter form and our lead form answer a sign-up by emailing you a confirmation link, and nothing reaches Mailchimp until you click it. So the instruction finds nobody if you never signed up, and equally if you signed up and never confirmed.
• Firebase Cloud Messaging and Apple's Push Notification service, for push notifications to Android and iOS devices respectively. Some of those notifications carry health information: the appointment reminder we schedule for 24 hours before an appointment you book goes out by push as well as by email, and it puts the appointment as it is titled and the name of the provider you are seeing into the notification itself, so Google and Apple carry those words. In our mobile apps a third company sits in front of both. When you allow notifications, your device registers with Expo, which issues the push token we send to — so Expo receives the push token your device's operating system issued, together with the identity of our app.
• Upstash, where that is configured, which holds our cache and the list of sign-in tokens we have revoked. Your session records themselves are in our own database.
• Sentry, for error and crash reporting, and for session replay, where a Sentry connection is configured. Error reporting now follows the Crash Reporting switch under Privacy in your settings, which starts on. While it is on, what it sends is the errors your browser hits, the console errors and warnings on the page, the requests that come back a failure, and — where you have accepted analytics as well — the timings of the pages you open. Turning it off stops all of that. There is a limit, and it is ours rather than yours: your answer travels in a cookie we write when you sign in and clear when you sign out, and where that cookie is missing we report rather than stay silent, so on the marketing pages, the sign-in page and anything else you open while signed out this reporting runs whatever you chose. Session replay needs that switch on as well, and it additionally follows the analytics cookie category. If you have not accepted analytics, or have made no choice at all, nothing is recorded. If you have accepted it, the recorder runs in every session you open and holds the last minute or so of it in memory. Nothing is sent from a session in which nothing goes wrong. **But the first thing that does go wrong changes what happens for the rest of that session:** the part held in memory is sent to Sentry, and from then on the recording no longer stops at a rolling minute — it continues, and is sent every few seconds, across the pages you visit afterwards, until you close the tab. If you withdraw your consent before anything has gone wrong, what is being held in memory is discarded rather than sent. If you withdraw after, the last part is sent as well, and then it stops. The text on the page is masked and images and video are blocked, but the page layout, your clicks and navigation, console errors and failed network requests are captured, and the address of each page you visit goes with them. Turning analytics off stops the recorder in the page you are looking at, without waiting for a reload. The recordings leave through our own domain rather than going to Sentry directly from your browser. Datadog, where that is configured, receives our server-side application logs, which carry your account id, your IP address and the requests you make. Our security alerting is a further recipient, and one of its alerts is about you. When five sign-in attempts on your account fail in a row, we raise an alert whose text is the number of attempts and the email address that was tried. Where we have configured a Slack channel for it, that text is posted to Slack; where we have configured an operations mailbox, it is emailed there through the email provider named above. Nothing about your health is in it, and there is no switch for it. The IP address the attempts came from and the browser string are held on the alert but are not put in that text: they go into the application logs described just above. We also wire PagerDuty and an on-call phone number to take alerts of higher severity, but this alert is never rated that high, so neither of them receives it.
• Google, for four things that load in your browser and that no cookie category covers. First, the CAPTCHA: it is Google reCAPTCHA and nothing else. Where a reCAPTCHA site key is configured, the sign-up form loads Google's reCAPTCHA script when the form is shown, and the public contact form loads it when you send the form, which gives Google your IP address before you have an account. When we check the result of the contact form we send Google your IP address again; the sign-up check sends only the token. We carry unused code for hCaptcha and Cloudflare Turnstile, but no form in the product selects either of them. Second, Google Maps: if you switch the Benefits page to map view, your browser loads Google's maps script, which gives Google your IP address and the page you are on, and your browser asks you for your location. If you allow it, we ask for your precise coordinates and hand them to that Google script, to centre the map and to place a 'Your location' marker. This is separate from the location settings in your privacy settings, which the map does not read, and there is no switch for it today. Google Maps also gets where you are going when you press Directions on a benefit you claim in person, or Get Directions on a provider's office. That opens a Google Maps page in a new tab, which gives Google your IP address and carries the location we hold for that place in the page address — for a provider's office, the street address, or the exact coordinates where we have them. Nothing is sent until you press it. Third, if you read Cravora in Chinese, Japanese or Korean, the typefaces for those scripts are fetched from Google's font servers when a page needs them, which gives Google your IP address. Fourth, the appointment you just booked. When you book an appointment from a benefit, the confirmation screen offers an Add to calendar button, and nothing is sent unless you press it and choose Google. If you do, we open a Google Calendar page in a new tab, which gives Google your IP address, and the address of that page carries the type of appointment, the date and time, and the name and street address of the place you are going. It does not carry the reason for the visit you typed. If you choose the download instead, the file is written on your own device and we send nothing to Google — but the file itself carries the reason for the visit, so whatever calendar you open it in will get it. This is not the calendar connection described further down: nothing is linked to a calendar account.
• PostHog and Google Analytics, for product analytics. This happens only once you have turned analytics on — in your browser, and now for the onboarding events our servers send as well, which used to be sent whatever you had chosen. PostHog can also record a replay of your session: the PostHog setup that runs in your browser does not switch recording off and sets no masking of its own beyond PostHog's own defaults, so if recording is switched on for our PostHog project, the text on the page is captured as you see it. Whether it is switched on is decided by the settings on our PostHog account rather than by anything in the app, and PostHog only loads where the analytics category applies. Segment is a third analytics recipient, and it does not follow that category. Where our administrators have connected a Segment account and an administrator runs a sync for it, the analytics events we have already stored against your account are forwarded to Segment with your account identifier attached, whatever you have chosen about cookies. That is not a few kinds of event: it is everything we hold for you in the window that sync covers — the benefits you view and open, the filters you set, the claims you start, the bookings and the clicks that take you out to a provider's site, the onboarding steps you finish, and your searches. Four things are held back. Your searches go only while Save Search History is on, and what goes is the shape of the search — the number of results, the number of filters, and a band for how long your query was — rather than the words you typed. Turn that switch off and the searches we have already stored stop being forwarded from that moment. If you have objected to our product analytics, nothing of yours is forwarded at all. Nothing recorded before the cut-off we set when we shipped this change is forwarded, for anyone, whatever they have chosen. And events we cannot tie to an account are not forwarded either, including the ones left behind by an account we have erased; those used to be sent under the name 'anonymous'. What Segment received before these limits took effect stays with Segment.
• Our AI provider, either OpenAI or Anthropic, for the wellness coach, on the terms described above.
• No embedding provider and no vector database receives anything on this path today. We built a step that would send your coach message to OpenAI a second time to be turned into a numerical embedding, and send that embedding to Pinecone or Weaviate to search our knowledge base. Neither vector-database client is installed in the running product, so the step fails before any of it is sent: OpenAI does not receive your message a second time, and neither Pinecone nor Weaviate receives anything. If we connect it we will name the provider here first.
• ElevenLabs or Google Cloud Text-to-Speech, whichever is configured, which receive the full text of the coach's reply so it can be read aloud — and only while you have Read aloud switched on, which starts off. OpenAI, which receives a recording sent for transcription. The microphone button in the coach is broken and sends nothing, so in practice no audio reaches OpenAI today; the endpoint that would send it is reachable by any signed-in account, which is why OpenAI is still named here.
• The wearable and health-device providers you choose to connect: Amazfit, Apple Health, Dexcom, Fitbit, FreeStyle Libre, Garmin, Google Fit, Kardia, Kinsa, Omron, Oura, Polar, Qardio, Samsung Health, Suunto, WHOOP, Withings, and the Withings blood-pressure monitor. And the calendar you choose to connect: Google Calendar, Outlook or Apple Calendar, where connecting asks that provider for read and write access to your calendar.

Cravora is used worldwide, and your data is transferred internationally. We do not hold data separately by region: there is a single primary database serving everyone, and the providers listed above process data wherever they operate. This policy does not name the countries your data is stored in, and the company that runs that database is not named here yet either.

The Where your data is stored screen in the settings of our website now says what this section says, and links here. The settings screen in our mobile app does not yet. It names a primary and a backup storage region and a cloud provider for your country, gives your country a compliance status, names the regulations it says apply, and for some countries says your data must be kept locally. None of that describes today, and none of it is enforced by anything in the product. There is one database serving every country, nothing tests a destination before your data leaves, nothing blocks a transfer, and nothing records which country a particular piece of your data went to. Your health data does cross borders, including to our AI providers. This section is the accurate one, and we are correcting the mobile screen.

Where we move personal data out of the European Economic Area, the United Kingdom, or India, we have not put a transfer safeguard of our own in place. We have not negotiated or signed the European Commission's Standard Contractual Clauses, the United Kingdom's International Data Transfer Addendum, or any equivalent clauses with our providers. Where a provider's own published terms already contain clauses of that kind, those terms govern the transfer, and we have not worked through our providers one by one to establish which of them do. What stands behind these transfers today is your consent to the processing described in this policy. We do not ask you for a separate consent before your data crosses a border.

We should be straight with you about where this stands. The written data-processing agreements and transfer clauses with our individual service providers are still being put in place. Until each is signed, the terms governing a given provider are that provider's own published terms rather than a contract we have negotiated. Those terms are also what decides what happens to your data once it arrives. The requests we send our AI providers carry no instruction about how long your message and the health profile sent with it may be kept, and none forbidding their use to train that provider's models. The retention periods set out later in this policy describe our own database, not a copy held by a provider. If any of this matters to your decision to use Cravora, write to privacy@cravora.com and we will tell you where a specific provider stands.

We keep personal data for as long as we need it for the purposes above and no longer, with one qualification: some records carry a legal minimum, and the nightly clean-up below will not act on those before it. Health records and audit logs carry that minimum. It binds that nightly job only. It holds nothing back when you ask us to erase your account. Audit logs survive an erasure anyway, for a different reason: we take your account id off the row and keep the row, and the nightly job strips the remaining identifying detail once the log is seven years old. Health records do not survive it. When you delete your account we erase them outright, however recent they are, and nothing in that code checks the six-year floor first. Analytics and notification logs run the other way, with a hard maximum.

A scheduled job runs every night at 03:00 UTC, applies the periods below, and deletes or anonymises what has passed them. Read the periods as the policy we enforce from now on, rather than as a description of clearing-out that has already taken place.

One limit on that job belongs here rather than in the small print. Each night it reads the shorter windows people have set for themselves, and it reads at most five hundred of the accounts that have saved any, in a fixed order by account id, starting from the beginning of that same list every night rather than carrying on from where it stopped. Once more than five hundred people have saved a window, the ones past that point never have theirs applied. The platform maximums below do not go through that scan: they run against everyone's rows, oldest first, in bounded batches, so a large backlog takes several nights to clear.

One thing no period on this page reaches. Your messages to the coach, and the health profile we build to answer them, are sent to a third-party AI provider as you wrote them. Nothing in our deletion or clean-up code contacts that provider. So when a period below expires, and when you delete your account, only our own copy goes. The provider's copy is kept and deleted on the provider's terms, not ours.

• Behavioural analytics: hard-deleted at 730 days, roughly two years, or sooner if you choose a shorter window in your data settings, within the limit described above. Deleting your account does not delete these events. It takes your account id off the row and leaves the rest — the event and its type, your country, your device, browser and operating system, and the time — to reach the 730-day limit on its own. One part of the row does not survive an erasure, and it used to. Each event carries a details field, called properties in your data export, and for a search it held the words you typed; searches stored before we stopped keeping that text still hold it until the 730 days, or a shorter window of yours, reaches them. The erasure now empties that field on every one of your analytics rows before your account id comes off. That takes the counts and identifiers other event types keep there as well, which we accept rather than keep your words. One neighbouring record is under no period at all. When a crisis escalation is raised for you by the coach or by a mental-health questionnaire, we write a tracking row on our coach analytics table alongside it, holding the escalation's id, the risk level, the kind of signal it was and, where the trigger was a mental-health questionnaire, your score on the self-harm question and your total. Nothing sweeps that table on any schedule. Deleting your account removes the escalation record itself but leaves that row in place with your account id taken off it.
• Notification delivery logs: hard-deleted at 90 days, or sooner if you choose a shorter window.
• Evidence that you withdrew a consent: the original grant, once marked withdrawn, is purged about three years after you withdrew it. Withdrawing also writes a second, separate record at that moment — the consent type, the time, the IP address and the browser you withdrew from — and nothing purges that one today, so treat it as kept until you delete your account.
• Health and wellness records: kept indefinitely by default, as your own health archive. A six-year medical-record floor stops anything being removed earlier, and although you can choose a shorter window in your data settings, that floor still applies. We have not yet built the step that would archive or anonymise a record once it passes the floor, so in practice nothing removes these unless you delete your account. The same data settings screen shows a Chat history window, which starts at one year. Nothing enforces it: no scheduled job deletes your coach conversations on that schedule, so choosing a shorter one there does not shorten how long we keep them. The retention field on the connected-devices privacy screen is not read by anything either. Of the four windows on that screen, only the activity and notification ones ever cause data to be deleted, and then only within the limit described above.
• Audit logs: kept for at least six years, and anonymised once they are older than seven.
• Account data: kept while your account is open. There are two delete controls in the product and they do different things. Delete account, in your account or data settings, erases nothing that day. It schedules the erasure for thirty days later, and the nightly job carries it out then, removing or anonymising your data. The six-year floors above do not restrain that erasure: your health records go however recent they are. What survives it is set out on this page — the payment records, the audit logs, and the rows further down where we break the link to you rather than delete them. One more survives where we hold it: if your address ever bounced, was reported as spam or was unsubscribed, we keep that suppression record — the address, the reason and what the mail provider told us — so erasing your account does not start the messages again. And one thing survives because the erasure writes it: a record that the erasure happened. It holds the date it was asked for and the date it was carried out, whether it was you, our staff or the nightly job that carried it out, and a summary of what was removed and what was deliberately kept. It is keyed by the internal identifier we held for the account, not by your name or your email address, and if you typed a reason when you asked us to delete the account we do not keep those words — only the fact that a reason was given. Until we changed this, that record was destroyed by the very erasure it describes, so if you wrote to us afterwards to ask whether your account had really been deleted, we had nothing on file to answer with. Now we do. The erasure can still be stopped inside those thirty days. Scheduling it signs you out, so instead of a button in the app we email you a single-use link, good for the whole thirty days: opening it and giving your account password calls the erasure off. If it never arrived, ask for another from the page the link points at, or from the sign-in screen, which tells you the date, or email privacy@cravora.com and we will stop it by hand. The delete-my-data control on the employer, provider, coach, partner, researcher and moderator portal settings screens works the other way: it erases straight away, with no thirty-day hold and no way back. Either control has a consequence beyond your own data: if you created a community group, erasing destroys that group and with it every post, comment, invitation and membership in it, including what other people wrote there. The photos and the document number from an identity check sit under no period on this page. We keep them while your account is open, and they are deleted when your account is erased.
• Payment records: one of several things deleting your account does not remove. We keep them for tax and accounting, and to answer a late refund or chargeback. They never carried your name in the first place. Deleting your account breaks the link between the record and you, leaving the amount, the currency, the date, the status, the Stripe references, and a short description of what the payment was for — the wording Stripe put on the invoice where it gave us one, otherwise a note we write ourselves, such as the plan you were on or that the row is a refund or a dispute fee. Beside them we keep a small billing register: one row for each subscription or checkout you started, holding the references Stripe gave us for it and for your customer record there, and what we did to stop it and settle it when you closed your account — when, who did it (if it was you, the internal identifier we held for your account, the same identifier the record of an erasure is kept under), the amount we refunded and Stripe's reference for that refund. It never held your name or your email address. We keep it for the same reasons, and so that a charge or refund that reaches us after an erasure can still be matched and reversed; deleting your account breaks its link to you in the same way. When your account is erased we also have Stripe remove your name, email address, phone number and address from your customer record there and take your saved cards off it; Stripe keeps its own record of the payments themselves, under its own terms. We have set no end date for these. The nightly job never deletes rows from the payments table or the billing register — it only settles what the register records — so unlike everything else on this list they are kept indefinitely. They are also not the only survivors. Your audit logs stay, with your account id removed but the IP address and the device string on them intact until the seven-year anonymisation described above. So do rows on roughly three dozen other tables where we break the link to you rather than delete the row: the direct messages other people sent you, your ratings of help articles and providers, invitations you sent to a group, and support tickets you were assigned. We remove most of the free text you wrote on those rows, but not all of it. Prose you wrote in a professional capacity is deliberately kept, such as a reusable support reply or a review note you signed off. And if you claimed a listing in our provider directory, we cannot yet establish who wrote its text, so the name, licence number and biography on that listing stay visible to other users after you erase.

Row-level security is switched on across our database, table by table, so an ordinary request returns only the rows the person making it is entitled to. That means your own rows, plus anything you have granted access to, such as a verified clinician or a coach you have shared with, and the aggregate figures an employer administrator may see.

One group belongs in that list and is not in it: our own. The database rules let a Cravora administrator read, change and delete the account row of any user, which holds your name, your email address, your phone number, and the country, region and city on your account. Administrators and moderators can also open your support tickets, the messages and attachments on them, and your live chat sessions with our support team and everything said in them. There is no rule of that kind on your health tables. Your health journal, your symptom, mood and cycle logs, your medications, your coach conversations and your safety records give an administrator nothing on the strength of their role.

That is not the whole answer, and the rest belongs here rather than only in our terms. Our server code can open a separate, marked service context, and every table's rules grant that context full access, health tables included. It does so in a few hundred named places: the scheduled clean-up, deletion and anonymisation jobs, webhooks from our payment, email and device partners, the plumbing behind sign-in and notifications, our analytics across all accounts, our admin console, and a small number of staff review screens. Every one of them is named in our code at the point where it runs, and every one of them can read rows that are not yours. On those paths what a person can see is limited by the permission check in our application code, not by the database rule described above.

Four staff queues hold something you wrote, and people work through them. The crisis-review queue is the one described in the sections on what we collect and who we share it with: our administrators read the message that tripped the crisis scan, in full, or the critical blood-glucose reading that opened the record, next to your name and your email address. If you report an answer the AI coach gave you, we keep that answer word for word along with your reason and any notes you added, and an administrator or a moderator reads it next to your name and your email address. If you flag a post, a comment or a group in the community, we keep a copy of what you flagged — the post or comment itself, or the group's name — and an administrator or a moderator reads it next to the name and email address of the person who wrote it and of the person who reported it. And if we take something of yours down and you appeal, a moderator reads what you wrote in the appeal, next to the content that was actioned and your name.

In production the application refuses to start if it is handed a database role capable of bypassing those rules, unless we deliberately set an override in our own deployment configuration. It also refuses to start if that same role is the one holding the service credentials, or if the ordinary and the service connection are configured as one and the same. Outside production those conditions are logged and the app starts anyway.

The access tokens for the wearable accounts you connect are encrypted with AES-GCM at the application layer before they are stored, so a copy of the database on its own does not let anyone pull your device data. Two other items are protected the same way: the messages between you and a provider, and your two-factor authentication secrets. Your account recovery codes are held differently and more strictly. We keep only a one-way hash of each, so they cannot be read back out of our database by anyone, including us.

Our site and our apps are served over HTTPS, and we send your browser a strict-transport header so that it will not fall back to an unencrypted connection to us. We keep an audit log of privileged actions taken inside the application.

One of those actions is worth naming rather than leaving you to discover it: an administrator can be granted a session that signs in as you. It is switched off in our deployment configuration by default, and while it is off no such session can be started at all. Where it is switched on, the administrator has to give a written reason, a second and different administrator has to approve it, nobody can approve their own request, the session expires on a fixed clock, and the request, the approval, the start and the end are each written to our admin log.

We would rather set out what such a session can actually see than leave you with "your account as you see it", which is wrong in both directions. These are refused outright while it runs: your coach conversations and their attachments, your community, chat and appointment messages, your support chats and your support tickets, your payment and billing screens, your insurance card, your emergency medication card, your generated health and wearable reports, and any bulk export, download or erasure of your data. These are not refused: your health journal, your symptom, mood, pain and energy logs, your cycle, fertility, pregnancy and menopause entries, your health photos, and your medication list. An administrator in that session reads those exactly as you do.

We want to be precise about what we are not claiming. Your health journal, your symptom logs, your medication records, and your coach conversations are stored as ordinary database columns. They are not encrypted field by field. We are also not making a claim to you about disk-level encryption of the database itself, because that is a property of our hosting provider rather than a control we operate.

No system is perfectly secure, and we cannot promise absolute security. If a breach affects your personal data, we will notify the relevant regulators and you, where the law requires it.

Most of this you can do yourself, in the web app. Your privacy settings hold your consent choices and cookie categories, and the export lives there too, under Privacy. The data section offers the same export, the same button behind it: in either place it gives you a JSON file or a short CSV summary as a direct download. One condition applies to it, and to deleting your account: both refuse until you have confirmed your email address.

Deleting your account is in the data section and in your account settings, and it is not immediate. Pressing it schedules the erasure for thirty days' time and marks the account for deletion, so your sessions stop working and you cannot sign back in. Nothing is removed in the meantime: your records sit as they are for those thirty days, and the nightly job removes or anonymises them at the end of it, subject to the retention floors described above. You cannot call it off from inside the app, because scheduling it signs you out. What stops it is the single-use cancellation link we email you the moment you press the button: it is good for the whole thirty days, and opening it and entering your account password calls the erasure off. If your account has no password we email you a short code to enter instead, and you can ask for a fresh link from the page the first one points at. If no email arrives, write to privacy@cravora.com and we will stop it for you.

Both are in our mobile app too, under Settings. Export Your Data there makes the same JSON export as the web app, saves it as a file on your phone and opens your phone's share options, so you can keep it or send it on; like the web export, it needs a confirmed email address. Delete Account there schedules the same thirty-day erasure the web buttons do.

You can also correct or delete the entries you logged yourself, one at a time, without deleting your account. In the web app you can correct or delete each symptom; each mood, pain, energy, nutrition and bowel log; each cycle, fertility, pregnancy and menopause entry; each diabetes, blood-pressure and asthma log; each custom-metric reading; each sleep-journal night, body measurement and health journal entry; each side effect you reported; each dose you recorded; each day's progress you logged toward a goal; and each past habit check-in, from the screen that lists it, and you can delete any of them from your health timeline. For a health photo you can change its category and tags or delete it, but not swap the image. Two kinds can be deleted but not edited: a questionnaire result, because its score was worked out from your answers, and a digestive log. On most tracker screens you can also clear every entry of that kind at once, once you have confirmed your email address. In the mobile app you can correct what its logging screens record, correct a blood-pressure, glucose, custom-metric or goal-progress value, change what was recorded for a dose, correct or delete a past habit check-in from the Goals tab and a goal's progress from that goal, and delete any entry from your timeline; the other kinds are corrected on the web. A deleted entry is removed from the live service at once, not after thirty days. Copies of it can stay in our database backups for as long as those backups are kept, and we have not yet set a limit on how long that is. When you delete a dose, or correct it to taken, late or skipped, the in-app alert a caregiver received saying you missed it is removed as well, and deleting a medication removes those alerts for every one of its doses. Correcting a dose back to not taken does not send its reminder or a caregiver alert again. The symptom summary on an appointment's preparation screen is worked out from your current entries each time you open it rather than kept, and correcting or deleting a symptom removes the items of an appointment's preparation checklist that were written from it. If you correct or delete progress you logged toward a goal, the goal's progress is worked out again from what remains, and a completion, or a milestone with a target, that it no longer reaches is withdrawn; correcting progress upward does not complete the goal or reach a milestone for you. Points you were already awarded stay. Deleting an entry does not reach these: the record our staff keep when a questionnaire you completed was flagged for a safety check, a coach conversation that quoted the entry, the weekly habit-review summaries we have already worked out from your habit check-ins, the goal part of the daily health scores we have already stored, and copies that have already left us, such as a file you downloaded or records a clinician you connected has already pulled. A reading a connected device sent still cannot be corrected or deleted on its own, and neither can the reflections saved with a weekly habit review.

There are three limits on the export, and you should know all of them.

First, the JSON file is the fuller of the two, but it is not everything we hold. It reads a fixed list of fifty-three record types, out of roughly one hundred and fifty that can hold data about you, and we have not yet brought it into line with everything account deletion removes. It carries your profile, your wearable data, your sleep sessions, workouts, stress readings and recovery scores, your blood-pressure, ECG and glucose readings, your body measurements, your breathing and meditation sessions, your sleep journal, your health goals and the health alerts you created, your cycle records and the dates we predicted from them, your medications and dose logs, appointments, symptom logs, the lifestyle answers you gave during onboarding, health journal entries, goals and the progress you logged toward them, habits and habit logs, achievements, insurance plans and coverage gaps, benefits and enrolments, your points and redemptions, your referrals, your consent history, your audit log, and the product-analytics events we record against your account: which benefit cards you view and click, which kinds of filter you use, and that you ran a search, though not the words you typed. It also carries every other kind of entry you log yourself: your mood, pain, energy, nutrition, bowel and digestive logs, your day-by-day cycle, fertility, pregnancy and menopause logs, your diabetes, blood-pressure and asthma logs, your custom metrics, the records of your health photos, your mental-health questionnaire answers and scores, and the side effects you reported. It does not carry the image files of your health photos, your voice notes, your safety records, your support messages, your community posts and messages, or your payment records.

Second, the CSV option is only a summary: your name, your email, and five counts, which are wearable data points, medication logs, appointments, goals and habits. It is not a copy of your records, and it does not count everything else we hold.

Third, neither file includes your coach conversations, even though this policy lists them as health data we hold.

Under Health and then Devices, the device data privacy screen carries an Export All Data button beside the control that deletes those records. It gives you the same JSON file the export under Privacy does, and everything that screen's delete destroys is in it: the two read one list, so we cannot remove a kind of record there without it also being in the file you can download. Until recently that button failed every time it was pressed, and the file it was trying to build would have held one of the kinds of record the delete beside it removes.

The health section holds two further exports of your own records, in other formats. Under Health and then Export, the journal export covers your symptom, pain, mood, energy, nutrition and bowel logs, your sleep journal, and your health journal entries; the device export beside it covers the readings from the wearables you have connected. The journal export has two limits of its own: it always covers the last twelve months and gives you no way to change that window, and whichever of CSV, JSON or FHIR you choose, what downloads is wrapped in JSON. Neither export is a copy of everything we hold, and neither includes your coach conversations.

Write to privacy@cravora.com for anything the export does not reach, and we will send it to you.

If yours is a dependent account linked to somebody else's, two of the screens described here are not shown to you: the data section and the consent log. Your privacy settings, the switches in them and the export are all still there, and you can still delete your account from your account settings.

For anything else you cannot do in the app, write to privacy@cravora.com. We will ask you to confirm your identity first, so that we never hand your data to somebody else, and we will respond within the time your law allows.

Exercising any of these rights costs you nothing, and we will not give you a worse service for having asked.

• Access: ask what we hold about you and receive a copy.
• Correction: have inaccurate or incomplete data fixed.
• Deletion: have your data erased, subject to the retention floors we are legally required to observe.
• Portability: export your data as JSON and take it elsewhere, bearing in mind that the JSON covers a fixed list of fifty-three record types rather than everything we hold. The CSV option is a summary of five counts rather than a copy of your records, and neither format yet includes your coach conversations.
• Restriction: ask us to pause processing while a dispute or a correction is worked out.
• Objection: object to processing we base on our legitimate interests, and to direct marketing at any time.
• Withdraw consent: what that is worth depends on which consent. Health Insights and sharing with your healthcare providers, both under Privacy in your settings, and anonymised research sharing, on the device data privacy screen under Health on the web and in settings in the mobile app, are real switches: turning one off is recorded, and it stops the processing. Withdrawing does not affect what happened before you withdrew it. Health analytics and personalised recommendations are asked for once at sign-up and have no switch afterwards. You can withdraw them in your consent log, but no processing in the product is gated on either one, so all that changes is our record and the privacy score we show you. Crash reports are the exception, and they are now a real switch: Crash Reporting sits under Privacy in your settings, it starts on, and turning it off is recorded the same way the switches above are. It stops the reporting described in the collection section, and the session recording with it, on every page you open while signed in. Your answer travels in a cookie we set when you sign in and clear when you sign out, and where there is no such cookie we report rather than stay silent, so on pages you open while signed out that reporting runs whatever you chose. For symptom tracking, vital signs, medication adherence, activity data, performance metrics, feature usage, preferences and usage patterns we record no consent at all. The Advanced tab still shows Anonymous Usage Analytics and Performance Monitoring switches: each saves your choice against your account, nothing in the product reads either, and so neither stops anything. What governs the analytics scripts in your browser is the analytics cookie category, and what your connected devices send follows the sync switch on each connection, under Integrations in your settings. Marketing is partly better than it was, and it is worth being exact about which part. Two of the four switches under Marketing and updates in your notification settings — Product updates and Health tips — write a preference and no consent record, so a withdrawal made there appears neither in your consent history nor in your export. Newsletter and Promotional offers write a preference too, until you turn the last one of the pair off: that save goes in your consent history and in your export, because a withdrawal of marketing consent is a statement about both of those classes at once. It is recorded as a withdrawal where your marketing consent was in force, and as a refusal where it was not in force and we hold no marketing record for you at all; where it was not in force and we already hold one, we add nothing to it. Turning the Email switch off is not recorded as a marketing withdrawal either: it silences the channel and leaves both marketing switches where they were. What any of these switches stop is also narrower than their names suggest: we check them only for a message that declares which of the four classes it belongs to, and today exactly one message we send declares one — the welcome mail for a newsletter or marketing-form sign-up, which declares Newsletter or Promotional offers according to the form you used. Nothing we send declares Product updates or Health tips, so those two switches stop no message of ours today. Revoking marketing in your consent log goes on the record too, and it turns Promotional and Newsletter off for you in one step. What stops our marketing email outright is the unsubscribe link in the header of every non-urgent message we send — the one your mail app's own Unsubscribe button uses — and the visible link in the newsletter welcome footer. Your mail app's own button stops all our non-urgent email to that address by itself, and so does turning the Email switch off in your notification settings, which leaves verification and security email untouched. Either link, opened by hand, takes you to a page instead, and pressing the confirm button there stops the same mail. The consent log's Revoke button used to be a different act from the switch, and it is not any more. For Health Insights and for sharing with your healthcare providers the switch was what we read, so revoking in the log recorded the withdrawal, told you it had worked, and moved nothing. Revoking in the log now moves the same thing the switch moves, in one step: Health Insights stops the analysis, provider sharing suspends every clinician's access, anonymised research takes you out of the research population and turns the switch off with it, and crash reporting stops the reporting in the browser you are using rather than waiting for your next sign-in. Three entries there are not yours to withdraw from that screen, and it now says so instead of accepting the click. Essential is the basis on which we run the service rather than a consent, so ending it means deleting your account; Functional and Analytics are cookie categories, and that answer is held per browser rather than per account. Each of the three links you to the control that does decide. A record written by an earlier version of the app is refused there too, and the log says so without a link: nothing now reads it, so there is no control left to send you to and nothing left to withdraw. The AI coach is the exception to nearly all of it: it has no consent switch of its own, so the only way to stop the coach sending your data to its providers is to stop using the coach. Your health score is the one part of what it sends that follows a switch: the coach is given it only while Health Insights is on, and turning Health Insights off stops it from your next message, including in earlier coach replies that could have repeated it.
• Complain: take it to your data protection authority, which in Australia is the Office of the Australian Information Commissioner (oaic.gov.au). Outside India and Australia you need neither our permission nor our involvement. In India the Act asks you to raise the grievance with us first, and the Data Protection Board of India is the step after that. In Australia the Commissioner normally expects you to complain to us first and to give us 30 days to respond.

If you are in the European Economic Area, Switzerland, or the United Kingdom, the GDPR or the UK GDPR applies to you. The legal bases we rely on are the ones set out above. For health data that basis is your explicit consent, except where we act on vital interests in an emergency or on a legal obligation.

That consent is not the same everywhere in the product, and this is the section where you should hear it rather than take it on trust. Health Insights has a switch, under Privacy in your settings on the web, and we record your consent when you grant it and record it again when you withdraw it. Anonymised research sharing has one too — on the device data privacy screen on the web, and in settings in the mobile app — recorded the same way in both directions. A switch with the same name, Share for Research, also sits on the journal privacy screen, and that one saves only a value for the screen to show you: turning it off there records nothing and withdraws nothing. Health analytics and personalised recommendations are asked for once, on the onboarding privacy step, and have no switch afterwards, so the answer you gave there is the only record and revoking it in the consent log in your settings is the only way to take it back. Our servers used to define nine narrower collection consents as well, and nothing you could reach in the app granted or withdrew any of them. Eight are now retired — performance metrics, feature usage, symptom tracking, vital signs, medication adherence, activity data, preferences and usage patterns. Nothing records or withdraws one any more, so nothing new for them reaches your consent log and there is nothing there you can act on. The ninth went the other way: crash reports now has a switch, under Privacy in your settings on the web, and we record your consent when you grant it and record it again when you withdraw it. It starts on, and turning it off stops us receiving the errors, console messages, failed requests and page timings from a browser you are signed in on, and the session recording with them. Four features that send your health data to our AI provider have no switch: the coach, apart from your health score, which it is given only while Health Insights is on; the analysis of a lab result or medical document you upload, the appointment-preparation tools, and the AI enrolment recommendation. For those we capture no consent record of any kind. The only consent is your decision to use the feature, and the only way to withdraw it is to stop using it. You can delete a coach conversation, but nothing recalls what was already sent to the provider. And one processing of health data rests on none of the three bases above: we scan every message you send the coach for crisis signals, and we treat a positive self-harm answer on a mental-health questionnaire the same way. Where a scan matches we write a record holding what you wrote and our trained staff read it, whether or not the signal is assessed as critical. Outside a genuine emergency we do that on our legitimate interest, and yours, in preventing serious harm. There is no setting that turns it off.

You hold all the rights listed above, and you can complain to your national supervisory authority, or to the Information Commissioner's Office in the United Kingdom, without coming to us first. We do not carry out solely automated decision-making that produces legal effects for you. Some automated acts come close enough that we will not leave them out of this section: if the crisis scan assesses what you wrote to the coach as critical, our servers email our administrators and are built to text the emergency contacts saved on your account, with no person reviewing that assessment before the text goes out. Text messaging is not switched on yet, so today none of the texts described in this paragraph is sent. The only thing that holds it back is a fifteen-minute pause after an alert about the same kind of crisis that actually reached somebody. A blood-glucose reading that reaches us from the mobile app is treated the same way when it is above 250 or below 70 mg/dL: your emergency contacts are texted, a record is opened for our staff, our administrators are emailed that it is waiting, and again no person sees the reading first. That one is held back only while an earlier alert about the same kind of reading, from within the past hour, is still unacknowledged. A heart rate that reaches us from the mobile app, above 120 or below 50 beats per minute, texts those same contacts off that number alone, with no account taken of rest or exercise and no person seeing it first, and, unlike the glucose alert, it is not held back by an earlier one. The section on the AI coach sets out what the coach text says and who receives it. If this happens to you and you believe the assessment was wrong, write to privacy@cravora.com.

Consent here is opt-in and granular. No cookie category arrives pre-ticked: analytics, functional and marketing all start switched off, and if you have chosen nothing, all three are treated as off.

Sending data across borders is probably the subject you came to this section for, and this section does not soften what the section on it says. Your data is transferred internationally, and the written data-processing agreements and transfer clauses with our individual service providers are still being put in place; until each is signed, the terms governing that provider are its own published terms. The coach is the sharpest case: nothing on that path checks where you are, so your message and the profile sent with it go to whichever AI provider our configuration names, wherever you live.

There are two gaps here, and the first has narrowed. Save search history and save browsing history both used to start switched on for everyone, in every country, including the EEA and the United Kingdom, because our code treated them as functional preferences rather than as tracking consents. Save search history is not one of those any more: it now decides whether a record of your search is kept against your account, whether the records already kept are passed on to Segment, and whether your browser keeps its own lists of recent searches, which turning it off also clears. So our code counts it as a tracking consent, and the regional rule that forces those off covers the EEA, the United Kingdom and anywhere we cannot place you. Be exact about how far that goes, because it is not as far as it sounds. The rule only supplies the value the privacy settings screen starts from, and the screen loads your stored row over it. That row starts on: the column still defaults to on in every country, and the row is created the first time anything reads your privacy settings, before you have chosen anything. So in practice the rule shows through when you press Reset to defaults, which in the EEA and the United Kingdom turns save search history off. Save browsing history still starts on everywhere, and it still decides nothing, because there is no browsing-history record for it to turn off. The second gap is that our list of opt-in countries does not include Switzerland. That used to change nothing you would notice, because every setting the rule reaches already started off for everyone; save search history is the first that does not, so a Reset to defaults in Switzerland leaves it on where the same press in the EEA or the United Kingdom turns it off. You can change any of these at any time in your privacy settings.

Where a member state sets a digital-consent age higher than our own threshold, we apply the higher one.

One record deserves naming under the storage-limitation rule. When the crisis scan flags something you wrote to the coach, the record we keep holds that text word for word. Deleting the conversation it came from does not delete that record: the link between the two is cleared and the record stays. Our nightly retention job covers behavioural analytics, notification logs, withdrawn consents, audit logs and health journal records; crisis records are on none of those lists, so no retention period applies to them. They are not in the export you can run yourself either. A critical blood-glucose reading writes a record in the same place, holding what was measured rather than anything you wrote, and the same applies to it. Write to privacy@cravora.com to ask what is held and to make an erasure or restriction request.

One honest gap more: we have not appointed a Data Protection Officer, an Article 27 representative in the European Union, or a United Kingdom representative. Where any of those becomes mandatory for us, we will appoint one and name them here. In the meantime, privacy@cravora.com reaches the people who actually handle these requests, and requests sent there are answered under the statutory timelines.

United States privacy laws, including the California Consumer Privacy Act as amended by the CPRA, treat health information as sensitive personal information. That includes your reproductive health records if you use the cycle, fertility, pregnancy or menopause trackers, and your scores on the mental-health questionnaires in the app. So are your identity document and the selfie taken with it. So is your precise location: the near-me option in the guided provider search asks your browser for your exact coordinates and puts them into the address of the results page it sends you to, and the map view on the benefits page asks for them again to centre that map. So is the racial or ethnic background you can tick on the demographics step of onboarding, which we store on your profile; you can leave that blank, and one of the boxes is Prefer not to disclose. What we collect, where it comes from, and why we use it are set out above.

We do not sell your personal data, and we do not share it for cross-context behavioural advertising. That reflects the product as built rather than a policy promise: there are no advertising pixels and no ad-network trackers in it, and Google Analytics is loaded in its GA4 form, which truncates IP addresses. Two things sit close to that line, and we would rather name them than leave you to find them. Where you have turned analytics on, we send Google's analytics tag a few conversion-style events, such as a newsletter sign-up or a contact-form submission, and, on every page you open outside our sign-in and sign-up screens, five page-speed measurements labelled with that page's address; we cannot promise Google makes no advertising use of what that tag receives. And opening the map view on the benefits page loads Google's map script into your browser whatever cookie choices you have made: that request tells Google your IP address and that it came from Cravora, and we then hand your coordinates to Google's map code running in your browser to centre the map, where what that code sends back to Google is not something we control. Google Maps is not named in the list of processors above, which that section already tells you is unfinished. On one point we should not overstate: the app does not set Google's cross-device advertising signals either way. Whether they are active is governed by the settings on our Google Analytics account rather than by the product.

California law also gives you the right to opt out of sale and sharing and to limit how sensitive personal information is used, and it expects a business to offer specific controls for that. We have to be honest with you here. Cravora does not currently provide a Do Not Sell or Share My Personal Information control, does not provide a Limit the Use of My Sensitive Personal Information control, and does not detect or act on Global Privacy Control browser signals. Those controls are not built. We will say so here when they are.

What does work today works for residents of every state: use the export and deletion tools in the app, within the three limits described above, and write to privacy@cravora.com to know, access, correct, or delete, or to ask what we have disclosed and to whom. We will not discriminate against you for exercising any of it. On HIPAA: where you sign up for Cravora directly as a consumer, Cravora is not a covered entity or a business associate and HIPAA does not govern that data. The FTC Health Breach Notification Rule and state consumer health privacy laws do.

If you are in India, the Digital Personal Data Protection Act, 2023 applies to your personal data. As a Data Principal you can obtain information about how we process your data, have it corrected or completed, have it erased, seek grievance redressal, and nominate someone to exercise your rights if you die or become incapacitated. Access is available in the app as an export, within the three limits on that export described above. You can correct your profile in the app, and you can delete a medication in the app, which takes its dose logs with it. You can also delete any health entry you logged yourself — a symptom, a mood entry, a dose or any other kind — on its own, in either app, and correct most kinds, some of them only on the web; the section on your rights describes where, and what a deletion does not reach. On the web you can also clear all of one kind at once from most tracker screens, and delete a single health goal or health alert, or all of them, from the screen that lists it; a reading a device sent still has no per-entry delete. Separately, on the web, the device privacy screen under Health revokes your device connections and erases the readings synced from them, together with the cycle records and the breathing and meditation sessions kept beside them. It no longer erases the sleep-journal entries, health goals or body measurements you wrote yourself: it used to, and it should not have. Erasing everything means deleting your account: that is scheduled thirty days ahead, and your payment records survive it with the link to you removed. Scheduling it signs you out at once, so there is nothing in the app to press to stop it. What stops it is the link we email you when you schedule it, used together with your account password — or, if your account has no password, a short code we email you instead — any time inside those thirty days. If that email never reaches you, you can ask for a fresh link from the page the first one points at, and if none arrives, write to privacy@cravora.com and we will stop the deletion by hand. Grievance redressal and nomination come through privacy@cravora.com.

We process your data on the consent you give when you register and when you switch on individual features. Those two are not the same in practice. You cannot create an account without accepting this policy and the terms, and there is no control anywhere in the app that withdraws that acceptance afterwards. Withdrawing it means writing to privacy@cravora.com, which we handle by hand, or deleting your account.

The feature consents are not all the same. Health Insights, under Privacy in your settings on the web, and anonymised research sharing, on the device data privacy screen under Health on the web and in settings in the mobile app, are real switches: switching one on is recorded, and switching it back off is the withdrawal and is recorded too. Crash reporting is a real switch too, under Privacy in your settings on the web, but it starts on, and turning it off is recorded the same way. Sharing your health data with the clinicians you have connected sits on that same Privacy tab and is on until you suspend it, and both suspending it and lifting the suspension are recorded. Health analytics, personalised recommendations and the partner-sharing box beside them are asked once at sign-up and have no switch afterwards, so you withdraw those in your consent log rather than by moving a switch back; nothing in the product is gated on those three; the one place personalised recommendations is read is the privacy score we show you, so withdrawing one changes our record of your decision rather than what we do. Two of the things on that Privacy tab decide how your use of the app is measured: your cookie choice, where analytics, marketing and functional all start off, and the Save Search History switch, which starts on and decides whether the searches you run in the benefits area are recorded against your account and passed to our analytics provider, and whether your browser keeps its own lists of recent searches, which turning it off also clears. Your settings also hold a consent log, which lists every consent record we hold for you, with a revoke button on each one still in force that is yours to withdraw. Three are not. Essential is the basis on which we run the service rather than a consent, so ending it means deleting your account; Functional and Analytics are cookie categories, and that answer is held per browser rather than per account. The log says so on each of those instead of accepting the click, and, where a control exists, links you to it. A record written by an earlier version of the app is refused there too, and the log says so without a link: nothing now reads it, so there is no control left to send you to and nothing left to withdraw. Revoking in the log is no longer a different act from moving the switch. Revoking Health Insights stops the analysis, revoking clinician sharing suspends every connected clinician's access, revoking anonymised research takes you out of the research population and turns that switch off with it, and revoking crash reporting stops the reporting in the browser you are using rather than waiting for your next sign-in.

Marketing is the one we have to be exact about. The choice you make at onboarding is recorded, and revoking it in the consent log is recorded too. The Product updates and Health tips switches in your notification settings write a preference and no consent record, so a withdrawal made there appears neither in your consent history nor in your export. Newsletter and Promotional offers are the same until you turn the last one of the pair off, which goes in your consent history and your export — as a withdrawal where your marketing consent was in force, as a refusal where it was not in force and we hold no marketing record for you, and not at all where it was not in force and we hold one already; turning email off on that screen is not recorded as one, because it silences the channel and leaves both marketing switches where they were. What those four switches stop is also narrower than their names suggest: we check them only for a message that declares which of the four classes it belongs to, and today the only message that declares one is our welcome mail, which declares Newsletter or Promotional offers according to the form you signed up on. Revoking marketing in the consent log now turns Promotional and Newsletter off for you as well, so the record and those switches finally say the same thing. There are two further ways to stop that mail without writing to us. Every non-urgent email we send carries an unsubscribe link in the message header, which is what your mail app's own Unsubscribe button uses, and our newsletter welcome mail carries a visible one in its footer as well. Pressing that button stops all our non-urgent email to that address; so does opening either link and pressing the confirm button on the page it opens. The other way is turning email off in your notification settings, which stops the same mail. If you have nothing left to click, write to privacy@cravora.com and we will take you off by hand.

The AI coach is the other exception: no consent record is captured for it at all, and stopping means not using the feature, except that your health score is given to it only while Health Insights is on.

Several things we do rest on preventing serious harm rather than on your consent, and no switch turns any of them off. Every message you send the coach is scanned for crisis signals before anything else is done with it, and if one matches, our own trained reviewers read what you wrote, in full, next to your name and your email address. A positive self-harm answer on a PHQ-9 questionnaire reaches the same reviewers the same way. So does a blood-sugar reading above 250 or below 70 mg per dL posted to our health endpoints by an app signed in to your account: it opens a record for those same reviewers holding the reading and its units, beside your name and your email address, and it needs no message from you at all. Text messaging is not switched on yet, so none of the texts described next is sent today. Once it is, where a coach message is assessed as critical, or a reading crosses those thresholds, we will also send a text message, through our SMS provider, to the emergency contacts saved on your account; we text those same contacts again after about fifteen minutes and every contact on your account after about thirty, unless the alert has been resolved by then. A heart rate above 120 or below 50 beats per minute, reaching us through one of those endpoints, texts those same contacts once off that number alone, with no follow-up and no record for our reviewers. We do that to prevent serious harm and to respond to a medical emergency, not on your consent, so it is not something you can withdraw while you use the coach, that questionnaire, or an app that sends us those readings.

The Act requires us to publish contact details for someone who can answer your questions about how we process your data; it requires a named Data Protection Officer in India only of fiduciaries the government designates as significant. We have not appointed a named officer, and we would rather tell you that than print a title nobody answers. Until an officer is appointed, send anything you would send to a Grievance Officer to privacy@cravora.com, and we will handle it under the same timelines. You can also complain to the Data Protection Board of India, and the Act asks you to raise the grievance with us first.

Cross-border transfer is covered above and applies to you. Nothing in Cravora keeps Indian data inside India: there is a single primary database serving every region, whatever a regional storage location shown elsewhere in the app may suggest.

You must be at least 13 to have a Cravora account. Below that age the account is refused outright at sign-up. If we are told that we are holding data about a child under 13, we delete it. Be aware that this is a manual process today: we have not built anything that finds such an account on its own, so it depends on somebody telling us.

One thing does not follow from that. A child having no account of their own does not mean we hold nothing about them, because an adult account holder can record a child, and nothing in the product refuses a young date of birth. In the family step of onboarding you can add a family member whose relationship is child or grandchild, and we store the name you give, the relationship, the date of birth, the age we work out from it, the gender if you pick one, and any health conditions you list for them. In the family section you can add a dependant, and we store their name, their relationship to you, their date of birth, the age we work out from it, and any benefit claim you make on their behalf. The child gets no account and no login of their own.

Removing those records is uneven, and we would rather say so. Both kinds hang off your account and are deleted when your account is deleted. The delete-family control in your family settings removes the onboarding family records, all of them together, and revokes the health-data access you granted to your family members; access that other people granted to you is not affected, because ending your family is not authority over somebody else’s decision. It does not touch a dependant added in the family section, and there is no control anywhere in the product that removes a dependant. Until there is, write to privacy@cravora.com and we will remove one by hand. Building that control is what closes this, and we will say so here when it lands.

Above 13, you need a parent or guardian's verified consent until you turn 18, or until a higher age if your country sets its digital-consent minimum above 18. We always apply whichever of the two is higher, so no country's rule can lower the bar for you.

The account itself is created before anyone has consented to anything. When a 13 to 17 year old submits the sign-up form we store, at that moment, their email address, their name, their phone number if they gave one, their date of birth, their country, and their password as a hash. The account cannot be signed into until a guardian approves. If no guardian ever approves, nothing removes it: the approval link stops working, but the account and what we already hold stay where they are, and because the account cannot be signed into, the person it belongs to cannot start a deletion themselves. Write to privacy@cravora.com and we will remove it by hand.

The consent flow works like this. To open the account you must give us a parent or guardian's email address, and it has to be different from the account holder's own. We ask for their name as well. Both are stored on the consent record, and we email that address a single-use verification link through our email provider. The link expires after 72 hours. We store only a hash of it and never the link itself, so it cannot be recovered from our database or reused once it has been followed. The consent record sits under the minor's account. It has no expiry of its own, nothing sweeps it, and there is no screen through which a guardian can reach it, so the guardian's name and address stay with us until the minor's account is deleted.

The record also carries a one-year expiry date, and we should be straight about what that does. We check that date at one moment only: when the account is first switched on, where an expired consent will not activate it. After that nothing checks it again. Nobody is asked to consent a second time, and the account keeps working once the year has passed.

A parent or guardian can review the minor's data, ask us to delete it, and withdraw consent at any time by writing to privacy@cravora.com. All three are done by a person, by hand, from that mailbox. There is no button that withdraws consent, and there is nothing in the code that closes or suspends an account when consent is withdrawn: a withdrawal takes effect because somebody acts on your email, not because the software does. There is no screen that shows a guardian the minor's data either. What the family section shows a guardian is limited to what the minor has chosen to share with them, and it never includes coach conversations.

We do not use a minor's data for advertising: the product runs no advertising pixel and no ad-network tracker. The one caveat set out in the section on cookies — that the app does not set Google's advertising signals either way — applies to a minor exactly as it applies to anyone else. We should not claim more than that. We do not collect less from a minor than from an adult. A 13 to 17 year old's account holds the same categories as anyone else's, including the coach conversations we send to our AI provider with no de-identification, and the safety records our staff read. There is no minor-specific collection limit in the code today.

We will update this policy as the product changes. The date shown at the top always tells you which version is currently in force, and that is the version your acceptance is recorded against. This page is the authoritative text. An older, automatically generated summary of our privacy practices is still reachable at one of our API endpoints; it is being retired, and where the two differ this page is the correct one.

On the web, when the in-force version for your country is newer than the one you last accepted, the app stops you and asks you to read and accept the new version before you carry on using Cravora. That check is per-jurisdiction, so a revision that only affects one region only re-prompts the people in it.

Our mobile apps do not re-prompt yet, and we do not email you about a revision either. If you use only the mobile app, nothing in the product will tell you that a new version is in force. The date at the top of this page is the way to check. Building the mobile re-prompt is what closes that, and we will say so here when it lands.

We keep a record of which version you accepted and when. That record is part of how we demonstrate your consent, and it is one of the things we keep for a period after you withdraw it.

For anything about privacy or your data, write to privacy@cravora.com. That address reaches the people who actually process these requests, and it is the right one for access, correction, deletion, withdrawing consent, and complaints.

We publish other addresses too, and you should use whichever suits you. For questions about the Terms of Service, or anything else, write to support@cravora.com, the general contact address on our contact page. For media enquiries, press@cravora.com. Anything sent to those about your privacy or your data will be passed to the same people.

That contact page lists no telephone number and no postal address: we do not offer support by telephone, and the placeholder number and street address it used to show have been removed. The page also carries a message form, and that one does work. What you type into it, meaning your name, your email address, an optional phone number, a subject, and up to 5,000 characters of free text with whatever health detail you choose to put in it, goes out through our email provider and arrives in our support inbox, where our staff read it. We do not store it against your account, so it will not be in your data export.

There is a third route, and it works differently from an email. Signed in, you can open a support ticket in the app. A ticket is a record we keep in our database: the subject, up to 5,000 characters you write, the email address and phone number you give us for a reply, and the browser and platform your request came from, which we record from the request itself even when you leave the "Include diagnostic logs" box unticked. Once the subject and the message are more than a few characters long, what you have typed is sent to our own servers while you are still typing, to suggest a category and to check it against your own tickets from the last week, so text you type and then delete has already reached us. Two of the categories you can choose are Data & Privacy and Health Tracking, so a request about your data can arrive this way; it reaches the same people. The ticket is assigned automatically to a support agent where one is free, and our administrators and moderators can read every ticket, not only the ones assigned to them. Support tickets are one of the things your export does not include.

We would rather name the roles that do not exist yet than list titles you cannot reach. Cravora has not appointed a Data Protection Officer, an EU Article 27 representative, a UK representative, or an India Grievance Officer. Where the law makes one of them mandatory for us, we will appoint them and publish their details here. Until then privacy@cravora.com is the single privacy channel, and everything sent to it is handled under the same legal timelines that would apply to those roles.

Outside India and Australia you never have to come through us first. You can complain directly to your own data protection authority: your national supervisory authority in the European Economic Area, the Information Commissioner's Office in the United Kingdom, or your state Attorney General in the United States. India and Australia are the exceptions. In India the Act asks you to raise the grievance with us first, and the Data Protection Board of India is the step after that. In Australia the authority is the Office of the Australian Information Commissioner (oaic.gov.au), and it normally expects you to complain to us first and to give us 30 days to respond before it takes up your complaint.