Data Protection

1. Our position, stated plainly

KareGO stores medical records. That is among the most sensitive categories of personal data that exists, and the consequences of handling it badly are not abstract: a leaked HIV status, a psychiatric history seen by an employer, a pregnancy disclosed before someone chose to.

We treat this as the central engineering and commercial constraint of the business, not as a compliance chore. The practical expression of that:

• Health data is stored in the United States.
• Health content in the app is end-to-end encrypted, so KareGO staff cannot read your medical records from our servers.
• Our AI runs on our own servers. Your records are never sent to an external AI provider.
• We have no advertising business, so we have no commercial reason to profile you and no revenue that depends on it.
• We use a deliberately small number of external providers, because every one of them is a reduction in the control we can promise you.

2. Who is responsible

Data protection at KareGO is owned by named individuals who are accountable for it. It is not delegated to a mailbox or a form.

3. The principles we work to

GDPR sets out principles that are easy to recite and harder to apply. Here is what each one means concretely inside KareGO.

Lawfulness, fairness and transparency. Every processing activity has a documented legal basis. For health data that basis is your explicit consent. We do not rely on "legitimate interests" to justify anything involving your medical records.

Purpose limitation. Your data is used to run KareGO for you. It is not used for research, product analytics on health content, or any secondary advertising purpose.

Data minimisation. Every field in your health profile is optional. The app functions with almost nothing filled in. We ask for information because it makes the product useful to you, never because it is useful to us.

Accuracy. You can edit or delete anything in your profile at any time. Our AI-assisted profile completion never overwrites data you entered yourself — it only proposes values for empty fields, and you approve them.

Storage limitation. We hold your data until you delete it. When you delete, it goes. Section 6 sets out the full schedule.

Integrity and confidentiality. Encryption in transit and at rest, restricted and logged access, audited consent. Section 7.

Accountability. We maintain records of processing activities under Article 30, we document our decisions, and we publish this page.

4. Every company that touches your data

This is our complete sub-processor register. There is nothing omitted.

Notably absent: no analytics platform tracking your behaviour in the app, no advertising SDK, no marketing automation platform, no data enrichment service, no external AI provider.

4.1 How we choose providers

Before a provider touches user data we require a data processing agreement under Article 28, appropriate transfer safeguards where personal data moves internationally, and a documented security posture. We assess whether the function can reasonably be done without the provider seeing personal data at all.

The default answer to "should we add another vendor?" is no.

4.2 When this list changes

If we add or replace a sub-processor, we update this page. Where the change affects how health data is handled, we notify registered users by email in advance, not afterwards.

5. Data leaving Europe

Other non-health operational data is also handled by providers in the United States — email addresses at Resend, subscription identifiers at RevenueCat, crash diagnostics at Firebase. Transfers of personal data from the UK or EEA to the United States are made under the European Commission's Standard Contractual Clauses, together with the UK International Data Transfer Addendum for UK users, where those instruments apply.

We are aware that Standard Contractual Clauses are an imperfect instrument and that US surveillance law is a real consideration rather than a formality. That is why health content is end-to-end encrypted, why we keep the provider list small, and why our engineering direction is to reduce exposure further, not to grow it.

6. How long we keep things

We run a 7-day backup window deliberately. Longer windows are more convenient for us and worse for you: they mean deleted medical data lingers for months. Seven days is enough to recover from a genuine failure and short enough that deletion means deletion.

7. Technical and organisational measures

Article 32 requires security appropriate to the risk. Given what we hold, we treat the risk as high.

Technical

• TLS/HTTPS encryption for all communication between the app and our servers
• Encryption at rest for the database and for all backups
• Signed JWT access tokens with limited lifetimes
• Passwords stored only as cryptographic hashes — we never see your password
• Granular device permissions (camera, microphone, photo library, location, health data, notifications) requested individually and revocable by you at any time
• Server-side audit logging of consent actions and access events
• Backups held in the same United States region as the primary data

Organisational

• Production access limited to a small number of named personnel with a specific operational need
• Multi-factor authentication required for all administrative access
• Access to production systems is logged and reviewable
• Binding confidentiality obligations for everyone with access
• Data processing agreements with every provider in section 4
• Documented internal procedure for handling rights requests and security incidents

7.1 The limit we will not hide

The KareGO app is end-to-end encrypted. Your health content is encrypted so that KareGO staff cannot read your medical records from our servers. Encryption at rest and in transit sits on top of that. Residual risks — unlocked devices, shared Medical ID links, exports — are set out on our Security page.

We could omit this. Many companies structure their language so you never notice. We state it because you are entitled to know the actual shape of the protection you are relying on, and because a limitation you were told about is very different from one you discover.

Access is restricted to investigating a fault you have reported or responding to a security incident. It is logged. It is never for analysis, curiosity or commercial purposes.

8. Data protection by design

Article 25 requires privacy to be built in rather than added on. Concretely, in KareGO:

• No account is required to see value. Our public tools work without signing up and without retaining what you upload.
• Every profile field is optional. The product does not withhold function to extract data.
• AI never overwrites your data. Automated profile completion proposes values for empty fields only; you approve them.
• Apple Health is read-only. We read the vitals you permit and never write back to your health record.
• Notification content is minimal by default. Reminders do not display diagnoses or results on a lock screen.
• Document ownership is checked. We compare the patient name on uploads against your profile to reduce the risk of another person's records entering your account.
• The Medical ID share link is revocable and under your control.
• Deletion is one step, and it is real. No retention flows, no confirmation mazes, no "are you sure you want to lose everything" dark patterns. This is a written commitment, not a current implementation detail.

9. Data Protection Impact Assessments

Processing health data at scale, with AI, requires a Data Protection Impact Assessment under Article 35 — a written analysis of what could go wrong and what we have done about it.

We complete a DPIA for the core KareGO service before processing begins, and we complete a new or updated one before launching any feature that materially changes how health data is processed. A feature does not ship until that assessment is done.

Our DPIAs examine, at minimum: the categories of data involved, the necessity and proportionality of the processing, risks to users including unauthorised access, inaccurate AI output and unintended disclosure, the mitigations applied, and the residual risk. Where residual risk remains high, we consult the relevant supervisory authority before proceeding.

10. Exercising your rights

Your rights are set out in the Privacy Policy. This is how a request is actually handled.

How to ask. Email privacy@karego.ai, or use the controls in the app. No form, no template, no specific wording. "Delete everything" is a valid request.

Identity. We may need to confirm you are who you say you are, because releasing a medical history to the wrong person is the worst thing we could do. We ask for the minimum necessary — usually confirmation from your registered email address.

Timing. We respond within one month. If a request is genuinely complex we may extend by up to two further months, and we will tell you within the first month, with reasons. In practice most requests are handled in days.

Cost. Free. Always.

Refusal. If we cannot fulfil a request we will explain why in plain language, tell you what we can do instead, and tell you how to complain.

Export. You can export your data in a structured, machine-readable format at any time, whether or not you have a paid subscription.

11. If there is a data breach

We plan for this on the assumption that it will happen, because that is the only responsible assumption.

Our procedure

1. 1Contain — isolate the affected systems and stop ongoing exposure.
2. 2Assess — establish what data was involved, how many people, and what the actual risk to them is.
3. 3Notify the regulator within 72 hours of becoming aware, where the breach is likely to result in a risk to people's rights and freedoms.
4. 4Notify you directly and without undue delay where the risk to you is high.
5. 5Remediate and publish — fix the cause, and account publicly for what happened.

What we will tell you: what happened, when, what data was involved, what the realistic risk is, what we have done, and what you should do. In plain language, promptly, without minimising it and without waiting until we have a comfortable narrative.

To report a suspected vulnerability or breach: security@karego.ai. We will not pursue legal action against researchers who act in good faith and give us reasonable time to fix an issue.

12. Commitments that do not change

These are permanent. They are not subject to revision as our commercial circumstances change, and any future owner of KareGO is bound by them.

• We will never sell or share your health data with advertisers, data brokers, insurers or employers.
• We will never show you advertising or use your health data to target you.
• We will never make deletion difficult or use retention dark patterns.
• We will never hold your medical records behind a paywall. If your subscription ends, you keep access to your data and can export or delete it at no cost.
• We will never make a material change to how we use your data without telling you first and, where required, asking again for your consent.

13. Complaints

If you are unhappy with how we handle your data, tell us at privacy@karego.ai. We would rather hear it from you than read it somewhere else.

You also have the right to complain directly to a data protection supervisory authority, without contacting us first:

• In the EU: the authority in the country where you live or work, or where you believe the problem occurred. The list is published by the European Data Protection Board at edpb.europa.eu.
• In the UK: the Information Commissioner's Office, ico.org.uk.

14. Contact

Data protection and rights requests: privacy@karego.ai

Security and vulnerability reports: security@karego.ai

General support: support@karego.ai