Privacy Policy

1. Who we are and what this policy covers

Paweł Milewski Software Development (the Operator, “we”, “us”, “our”) provides glumea (the App), a mobile application for diabetes self-management, and glumea.com (the Website). This policy explains what data we collect, why, where it is stored, who can access it, how long it is kept, what deletion removes, and the rights and controls you have.

It is also the notice we owe you under European data protection law: the information required by Articles 13 and 14 of the General Data Protection Regulation (Regulation (EU) 2016/679), which we call the GDPR from here on, covering both the data you give us yourself and the data that reaches us from somewhere else.

This policy covers:

The App: the glumea mobile app for iOS and Android.
The Website: the glumea.com website, including the pages that host these legal documents.

The Website collects almost nothing, and it has its own section below.

The Operator is the data controller responsible for your personal data:

Controller: Paweł Milewski Software Development
Company registration number: NIP PL6751782526 — sole proprietorship entered in CEIDG, the Polish Central Registration and Information on Business
Postal address: ul. Franciszka Bohomolca 3 lok. 7, 31-416 Kraków, Poland
Email: [email protected]
Country of establishment: Poland

If applicable:

EU representative: not applicable — we are established in the European Union
UK representative: not appointed
Data protection officer: not appointed; data-protection questions go to [email protected]

“Data controller” means the party that decides how and why your personal data is processed, as defined by the GDPR.

Two other documents apply alongside this policy, and you should read them together with it:

our Terms of Service, which govern your use of the App and the Website, and
our Medical Disclaimer, which sets out the medical limits of what the App does.

If you are a Washington resident, a fourth document applies to you specifically: our Consumer Health Data Privacy Policy, which Washington law requires us to publish separately. If you are in Nevada, the equivalent is our Nevada Consumer Health Data Privacy Notice.

2. Summary

A short version of what follows. Each point names the section that sets it out in full, and that section governs.

Who we are. Paweł Milewski Software Development decides how and why your data is processed. Sections 1 and 21.
What we collect. Your email address and password; the profile you enter at onboarding; the diary you keep, glucose, food, insulin, other medication, weight, medications and reminders; sign-in tokens and server connection records. Records from Apple Health or Health Connect if you connect them, and subscription information if you subscribe. Section 3.
Health data. The diary, diabetes type, treatment method and therapy settings are special-category data under Article 9 GDPR. Cloud sync has a separate confirmation for the diary. Current onboarding does not collect a separate explicit consent before storing the health profile and therapy settings. Sections 3.3 and 4.
Where it is. Some of your data is on our servers from the moment you create an account: your account details, your profile including your diabetes type and treatment, and your therapy settings. Your diary is not: it is written first to an encrypted database on your phone, the App works offline, and it reaches our servers only if you turn Cloud sync on, a glumea+ feature, off until you turn it on, and a choice held on your account rather than on the phone. Section 10 has the full table.
Who receives it. Our EU hosting provider; an email provider if email delivery is enabled; PostHog and Sentry under the current telemetry defaults; the store if you subscribe; and RevenueCat whether or not you subscribe. We do not sell your data, and the App carries no advertising. Sections 5, 7, 8 and 9.
Your choices. The App exposes analytics and error-reporting switches, but current builds store both as enabled by default and do not reliably stop an already initialized SDK on sign-out. In the App you can turn sync off, delete the server copy of your diary, delete your account, and use the implemented exports. Sections 5 and 13.
Your rights. Access, rectification, erasure, restriction, portability, objection, withdrawal of consent, and a complaint to a data protection authority; in the United States, the rights your state’s law gives you. The controls currently available are in the App. [email protected] is the general data-protection contact, but it is not currently connected to an automated rights-request workflow. Sections 13, 14 and 17.
What deletion misses. Deleting your account is immediate and permanent in our production database, but it does not reach subscription notification records, RevenueCat’s subscriber record, a PostHog analytics profile, provider logs or existing backups. Section 12 states what persists and for how long.

3. Data we collect

Most of what is listed here is provided by you directly. Two categories are not: readings you import from Apple Health or Health Connect, and subscription information that reaches us from Apple, Google and RevenueCat. Both are described below.

3.1 Account data

Email address and password. Your password is hashed on our servers with bcrypt, is never stored in plaintext, and is never saved on your device. Your email address is also carried inside the sign-in token the App uses.
One-time codes for email verification, password reset, password change and email change. A code expires 10 minutes after it is issued, and five wrong attempts invalidate it.

3.2 Profile data

Collected during onboarding:

First and last name (stored as a nickname), age, gender (optional), and height.
Diabetes type (Type 1, Type 2, gestational, or other), treatment methods (insulin, tablets, injectables, diet), and insulin delivery method.

Your diabetes type, your treatment methods and your insulin delivery method are health data, a “special category” of personal data under Article 9 of the GDPR, even though this policy groups them under “profile”. The legal bases section below sets out the condition we rely on for them.

3.3 Health data you log (special category data)

The following is health data, a “special category” of personal data under Article 9 of the GDPR. We hold it on our servers only under your explicit consent. The legal bases section below sets out how that consent is given, and which of these reach our servers only when cloud sync is on:

Blood glucose readings, with optional context tags (meal timing, physiology, activity, medication and technology, plus tags you write yourself) and free-text notes.
Food entries: carbohydrates, plus optional protein, fat, calories, and a name you type.
Insulin doses: the number of units, linked to the insulin medication you configured, bolus, basal or premixed.
Injectable medication doses (for example GLP-1 agonists).
Pill and tablet intake counts.
Body weight entries, each with the time you recorded it.
Your medication catalogs: insulin, pill, and injectable medications you configure, including drug names (for example Fiasp, Lantus, Metformin, Ozempic) and pharmacokinetic parameters (onset, peak, duration), and the reminder times you set for them.
Treatment settings you configure: your glucose target range (default 3.9–10.0 mmol/L), insulin-to-carb ratio (ICR), and insulin sensitivity factor (ISF). The App never uses any of them to calculate or recommend a dose. Your insulin-to-carb ratio is stored for your reference and nothing else reads it. Your target range is stored and is also what draws the in-range band of Time in Range, sets the inner edges of the Good / Fair / Critical label, and decides when the hypo-risk wording changes. Your insulin sensitivity factor is used to work out the hypo-risk wording and the approximate lowering range shown beside active insulin. The Medical Disclaimer describes all of it.
Values the App derives on your device from what you log: estimated active insulin (an estimate for awareness only: it does not recommend or calculate a dose), the hypo-risk wording and the approximate lowering range shown beside it, trends, average glucose and its spread, Time in Range, the estimated A1C (GMI), the suggested time for your next reading, and the Good / Fair / Critical label on your latest reading. The Medical Disclaimer sets out what each of these is and is not.

Several of these fields are free text, glucose notes, tags you write yourself, food names, custom medication names, the name of a custom reminder slot. Whatever you type there is stored, and synced if sync is on, exactly as you typed it.

3.4 Data we receive from other sources

Apple Health and Health Connect. If you connect them, the App reads blood glucose, body weight and dietary carbohydrate records from the health platform on your phone. This is read-only: the App never writes anything back. On iOS it asks the system only for read access and declares no reason for writing, which is what a write would require; on Android it holds only read permissions for the three record types. Records that originally came from a meter, a CGM or another app therefore reach glumea through the health platform. Imported entries are stored on your device as ordinary entries, tagged with the platform they came from and the record’s identifier. Whether an imported entry is also copied to our servers depends on whether Cloud sync is on, in exactly the same way as an entry you typed in yourself. The connection is off until you turn it on, and you can disconnect it or switch off individual data types at any time in Settings → Integrations.
Apple, Google and RevenueCat. If you subscribe to glumea+, information about that subscription reaches us from the store and from RevenueCat. See the glumea+ section below for exactly what.

3.5 Technical data

Authentication tokens, stored in your device’s secure storage so you stay signed in. Your session on our servers is a record holding a session id, your user id, and its expiry.
When cloud sync is on, our servers process the data you sync together with the bookkeeping needed to run the sync service, such as sync timestamps.
When the App communicates with our servers, the servers receive standard connection information such as your IP address, the path requested and the time, used for security and to operate the service.
While analytics or diagnostics is enabled, each SDK sends the data described in section 5. Current builds enable both stored settings by default.

3.6 Data that stays on your device and data that does not

Some things never reach our servers at all: notification settings, glucose-check reminder times, Quiet hours, sick-day mode, lock-screen detail choice, local notification state, health-platform connection state, app preferences, telemetry preferences and sync bookkeeping. One qualification: while analytics is enabled, language, theme and unit settings are sent to PostHog as profile attributes. Nothing else in this list leaves the device through our backend.

Your medication schedules are the exception: they belong to the diary, so they are copied to our servers when Cloud sync is on, a medication reminder has to survive a new phone.

The cloud-sync switch itself is not device-only either. Your answer to it is held on your account on our servers, so that it follows you to a new phone and survives signing out; section 10 sets out what that means in practice.

Files you create yourself, a .glumea backup archive, or a CSV or PDF glucose report, are written on your device and handed to whichever app you choose to share or save them with. Where they go after that is outside our control, and a CSV or PDF report is not encrypted.

4. Why we process your data and our legal bases

Under the GDPR, each use needs an Article 6 basis and special-category data also needs an Article 9 condition. The intended bases are listed below. The current telemetry defaults and missing profile-consent step do not provide the affirmative consent those processing activities require.

Providing your account and the App: creating and securing your account, authentication, email verification, password reset, operating cloud sync, providing glumea+ if you subscribe, and keeping a record of the subscription notifications the store and RevenueCat send us so we can tell whether glumea+ is active and sort out a billing problem: performance of a contract, Article 6(1)(b) GDPR.
Holding health data on our servers: the intended bases are Article 6(1)(b) for the service and explicit consent under Article 9(2)(a) for the health data. The diary is copied to our servers only after the separate Cloud sync confirmation. Current onboarding stores profile and therapy settings on the account without a separate explicit-consent step. Acceptance of a contract is not automatically explicit consent for special-category processing, so the current onboarding flow does not provide that Article 9 condition. Deleting the account is the only implemented way to remove those profile and therapy fields from the production database.
Product analytics: the intended basis is consent under Article 6(1)(a), explicit consent under Article 9(2)(a) for health inferences, and consent under Article 5(3) of the ePrivacy Directive for SDK storage. The current enabled-by-default setting does not provide that affirmative consent.
Diagnostics and crash reports: the intended basis is consent under Article 6(1)(a), explicit consent under Article 9(2)(a) because use of a diabetes app is health-revealing, and Article 5(3) ePrivacy consent for SDK storage. The current enabled-by-default setting does not provide that affirmative consent.
Keeping the service secure and preventing abuse: rate limiting on our API, and investigating suspected misuse: our legitimate interests, Article 6(1)(f) GDPR. The specific interest is protecting your account and other people’s accounts from unauthorized access, and keeping the service available. We rely on this only where our interests are not overridden by your rights.
Meeting a legal obligation: where the law of Poland requires us to keep or to disclose particular records, we do so on the basis of Article 6(1)(c) GDPR. We do not rely on this basis for the health data you log. We do not take your payment and we never receive your payment details, so the payment and billing records for your purchase are held by the store rather than by us.

We do not make decisions about you that produce legal effects or similarly significant effects on you based solely on automated processing, and we do not profile you for such decisions. There is no automated decision-making in glumea within the meaning of Article 22 GDPR. The estimates the App shows, active insulin, trends, Time in Range, are arithmetic performed on your device on the data you entered, presented for your awareness only. They do not recommend or calculate any insulin or medication dose, and they are not medical advice.

Is providing data a requirement? You are not required by law to provide data. An email address and password are required for an account. The profile and therapy fields requested during onboarding are stored on the account, subject to the consent limitation described above. Logging entries, connecting Apple Health or Health Connect, and cloud sync are optional. Analytics and diagnostics have user-facing switches, but enabled-by-default settings do not constitute affirmative consent.

5. Analytics and diagnostics

The App includes two third-party SDKs for these purposes: one for product analytics and one for crash and error reports. This section sets out what each one is and what it receives.

The two settings are independent and can be changed in Settings → Data & privacy → Privacy & diagnostics. Current builds store both as enabled by default. Signing out clears stored preferences but does not reliably close an SDK that was already initialized in the running process. Consequently, the present implementation is not an affirmative opt-in flow and cannot support the consent claims that an EU, UK, Washington or Nevada launch would require.

5.1 Product analytics: PostHog

We use PostHog (EU Cloud, eu.i.posthog.com) to understand how the App is used so we can improve it.

What PostHog can receive while analytics is enabled:

Your glumea account identifier: the internal UUID for your account. Not your email, not your name. Once you are signed in, events are tied to that identifier, so those events are not anonymous. The events that can happen before you sign in, or after you sign out, first launch, app launches, sign-up and the verification of an emailed code, carry a pseudonymous device identifier instead, and that identifier is regenerated when the App resets the SDK.
A fixed list of event names, about 28 of them, covering things like the app being opened, signing up, completing onboarding, saving an entry, importing from Apple Health, granting or refusing a notification permission, generating an export, opening the paywall, and the outcome of a purchase or restore.
A small number of properties, each from a closed list or a bounded count: which kind of entry was saved (glucose, food, insulin, pill, injectable, weight), how many rows an import produced, whether an entry was logged in the moment or backdated, whether an export was CSV or PDF, which onboarding step was completed, and similar. No property anywhere in the system accepts free text.
The screen you are on, as a route template like /settings/privacy. Digits are refused, so a record identifier cannot travel inside one.
A handful of profile attributes: your language, your theme, your glucose, weight and carbohydrate units, and whether you are on glumea+.
What the PostHog SDK adds by itself, outside our control: device model, operating system and version, app version, SDK version, timezone, locale, network type and a session identifier. PostHog also receives the IP address your request comes from, as any web service does.

What PostHog cannot receive: a glucose value, an insulin dose, a medication name, a note, a food name, an email address, or any other free text. The filter that ensures this is fail-closed, an event that is not on the list is dropped whole, a property that is not declared is stripped, and a declared property whose value does not match its expected shape is stripped too. There is no “any string” property in the system. There is no session replay, no screen recording, no surveys, no autocapture of taps, and no push token.

The events still carry a health inference. An insulin-entry event indicates insulin use even though the dose is not sent. A low- or high-glucose recheck-reminder event indicates that a reading crossed a threshold shortly before it. This requires an affirmative explicit-consent gate before production processing where the law requires one; the current default does not provide that gate.

The analytics SDK stores its own identifier on your device, along with a queue of events waiting to be sent. Two limitations follow from the way the SDK works. Withdrawing records one last event of its own, that you opted out. And that event, together with anything already collected while you consented, is delivered afterwards on the SDK’s own schedule rather than at the moment you withdraw. Nothing new is collected after that.

5.2 Diagnostics and crash reports: Sentry

We use Sentry (European Union region) to find out when the App crashes or errors, so we can fix it.

Every content-bearing part of a report the App builds is rebuilt from scratch before it is sent, from a list of fields that are allowed rather than a list of fields to remove. A dozen or so remaining top-level fields are cleared by name instead, so a field newly added by a future version of the SDK would not be caught by that clearing until we add it. What survives that rebuild is:

The exception type, and a computed label in place of the original error message.
The stack trace, with filenames reduced to their basename and, in release builds, symbol names obfuscated, they are made readable only on Sentry’s side using the mapping we upload at build time.
Device family, model, architecture, whether it is a simulator, and orientation.
Operating system name, version and build; app name, version and build; the Dart runtime version.
Debug image identifiers, needed to make native crashes readable.
The shape of the breadcrumb trail, the category, type, level and timestamp of recent events, but never their content.
Two labels: which area of the App failed, and whether it happened in the foreground or in the background notification engine.
The release, build number, environment and a randomly generated event id.

What is removed outright: the error message, any request data, any user object, the server name, the transaction name, thread lists, module lists, local variable values, source-code context, absolute paths, the device’s unique id and name, the install-scoped app hash, breadcrumb messages and data, screenshots, view hierarchies and any attachment. Screenshots, view hierarchy capture, session replay, performance tracing, logging and request bodies are all switched off. The App attaches no user identifier to a Sentry event: no account id, no email address, no device id.

Two limits on the above:

Native crashes, app-not-responding events and iOS watchdog terminations may reach Sentry without passing through that rebuild, because they are produced by the operating system’s crash handler rather than by the App’s own code. So is the periodic “app session started / ended” signal Sentry uses for release health. We cannot inspect those on the device and we do not know every field the platform SDK puts into one. We set no identifier that would connect one of them to you.
Sentry receives the IP address the report is sent from.

If diagnostics is disabled before SDK initialization, Sentry is not started. Turning the switch off closes the reporters reached by that control, but signing out does not reliably disable an already initialized SDK in the running process. The current lifecycle therefore cannot be described as immediate withdrawal in every state.

6. glumea+ and subscription data

glumea+ is a subscription, sold only as an in-app purchase through the Apple App Store and Google Play. There is no other way to buy it, no web checkout and no card form anywhere in the App.

No payment details reach us. Apple or Google takes the payment. We never see your card number, your bank details, or your billing address. Cancellation and refunds are handled through your store account, the Terms of Service explain where.
RevenueCat is the service we use to know whether your subscription is active. The App tells RevenueCat one thing about you: your glumea account identifier, used as the subscription’s user id. Our servers also ask RevenueCat whether that identifier has an active subscription, including when you have never subscribed, because that is how we learn that you have not. We set no email address, no display name, no phone number, no push token, and we do not ask it to collect device advertising identifiers. RevenueCat’s own SDK also collects some device and network information for the operation of the RevenueCat service, described in its own privacy notice. We do not configure that collection and we do not receive what it produces.
What the App keeps locally is a single true/false value: whether glumea+ is active. No price, no product id, no expiry date, no transaction id is stored on your device by the App. That value is set to false when you sign out, so the next account on the device starts with no subscription and has to be checked against the store on its own.
What our servers store. RevenueCat sends our backend a notification when something changes about a subscription, a purchase, a renewal, a cancellation, a billing issue. We record each of those notifications as received: the event id and type, the environment, your glumea account identifier, and the complete message RevenueCat sent, stored exactly as it arrived rather than field by field. That message typically includes the product identifier, price, currency, store, country and the purchase and expiry dates. Because we store it whole, it can also carry whatever subscriber attributes RevenueCat holds for you, an email address among them: even though our App sets none of its own. We never rewrite the message; a repeated delivery of the same event updates only our count of how many times it arrived.
While analytics is enabled, the funnel events described above go to PostHog, together with a profile attribute recording whether glumea+ is active. No price, product identifier or store identifier is sent to analytics.

Two consequences follow. The webhook log carries your glumea account identifier, but it has no database relationship to your account row, so deleting your account does not take it with it. A scheduled job removes each webhook record 90 days after it arrives. RevenueCat keeps its own subscriber record under the same identifier, and deleting your glumea account does not remove it. Section 12 describes both limits.

7. What we do not do

None of the following happens in glumea:

No advertising, of any kind. No advertising SDK, no attribution SDK, no advertising identifier. The App cannot show the iOS “Ask App not to Track” prompt, because it does not carry the entry that would allow it, and it declares no ad-attribution networks.
No sale of your data. We do not sell or rent personal data, and we do not sell health data. We do not share it for cross-context behavioral advertising.
No use of your health data for advertising, marketing, or building a profile of you for anyone else.
No location data. No access to your contacts, camera, microphone, photos or calendar, the App requests none of those permissions on either platform.
No Firebase in the App: no Firebase Analytics, no Crashlytics, no Firebase Cloud Messaging. (Firebase Hosting does serve the Website, including this page, that is a different Google service and it is named below.)
No push notifications, and no device push token. Reminders are scheduled and displayed by your own device; there is no server-to-device channel at all.
No screenshots, no screen recording, no session replay, no view-hierarchy capture, from either of the two SDKs described above.
Beyond PostHog and Sentry, no other analytics, telemetry or tracking SDK is in the App. The only components that open a network connection are the App’s own connection to our servers, PostHog, Sentry and RevenueCat.

8. Who receives your data

We share data with the service providers below to operate glumea. Their roles, their own privacy notices and the contractual terms applicable to our use of each service govern that processing. RevenueCat’s SDK also collects device and network information by itself. We do not configure that collection and do not receive its output, so the description of it comes from RevenueCat’s privacy notice rather than from our systems.

Google (Google Cloud Run and Google Cloud SQL, region europe-west1), hosts our backend and the database holding everything you sync, including your health data. Google Secret Manager holds our server credentials, and Google Cloud Logging holds our server request logs.
Google (Firebase Hosting), serves glumea.com and these legal documents.
Sentry (European Union region), receives the diagnostic reports described above while diagnostics is enabled under the current setting behavior.
PostHog (EU Cloud), receives the analytics events described above while analytics is enabled under the current setting behavior.
RevenueCat (the United States), receives your glumea account identifier and your subscription state, whether or not you subscribe: checking that you are not a subscriber uses the same identifier as confirming that you are. As noted above, its SDK additionally collects device and network information that we do not configure and do not receive; RevenueCat’s own privacy notice describes it.
Zoho ZeptoMail: if production email delivery is enabled, this provider receives the destination email address and the verification or password-reset message needed to deliver it. No email provider receives those messages while delivery is disabled.

Apple and Google are not our processors. They operate the stores through which glumea+ is sold, they take the payment, and they are independent controllers for the purchase data they hold about you. What they collect is governed by their own privacy policies, not by this one.

Beyond that, we disclose personal data only if the law requires it, for example a binding order from a court or authority, or at your direction.

If Paweł Milewski Software Development is ever involved in a merger, acquisition, or sale of assets, your data would remain protected by this policy, and we would notify you before your data becomes subject to a different privacy policy.

9. International transfers

Where each recipient processes your data:

Your account, profile and synced health data are stored in the EU: Google Cloud, europe-west1 (Belgium). Storage location is not the whole answer. Google can reach that data from outside the EEA, for support and to operate the platform, and that is a transfer in its own right. It relies on the Standard Contractual Clauses in Google’s Cloud Data Processing Addendum.
Analytics go to PostHog’s EU Cloud, which stores them in the EU. Where PostHog can reach them from outside the European Economic Area, the transfer relies on the Standard Contractual Clauses in PostHog’s data processing agreement.
Diagnostics go to Sentry in its European Union region. Where that is outside the European Economic Area, the transfer relies on the Standard Contractual Clauses in Sentry’s data processing addendum.
The Website is served by Firebase Hosting from Google’s content delivery network, so a request for a page may be served from, and logged at, a location outside the European Economic Area. Where that happens, the transfer relies on the Standard Contractual Clauses in Google’s Cloud Data Processing Addendum.
Subscription state goes to RevenueCat in the United States. Where that is outside the European Economic Area, the transfer relies on the Standard Contractual Clauses in RevenueCat’s data processing addendum.
If production email delivery is enabled, verification and password-reset emails are delivered by Zoho ZeptoMail, which processes the destination email address at the European Union — Zoho Corporation B.V., Zoho’s EU data centres in the Netherlands and Ireland. Where that is outside the European Economic Area, the applicable transfer mechanism is the Standard Contractual Clauses in Zoho’s data processing addendum.
Apple and Google process purchase data under their own arrangements, as independent controllers.

Where a provider can access data from outside the EEA, including for support, that access is also a transfer and must have an appropriate safeguard under Chapter V of the GDPR. The mechanism for each recipient is named above. For users in the United Kingdom, the equivalent mechanism is the UK Addendum to the EU Standard Contractual Clauses, or the IDTA where a provider uses that form under the UK GDPR. General data-protection contact: [email protected]. No separate automated safeguard-copy request workflow is currently implemented.

10. Where your data is stored

glumea is offline-first. This section is the full answer to “what of mine is on your servers?”: everything else in this policy points here.

What	On your phone	On our servers	From when	How to remove it
Your diary, entries, medication catalogs, medication schedules	Always	Only with Cloud sync on	From the moment you turn the switch on	Turn the switch off, then delete your data; or delete your account
Your profile, name, age, height, diabetes type, treatment methods, insulin delivery	Yes	Always	From onboarding, whether or not you use sync	Delete your account
Your therapy settings, target range, insulin-to-carb ratio, insulin sensitivity factor	Yes	Always	From the moment you enter them	Delete your account
Your account, email address, hashed password, sign-in sessions	Credentials only	Always	From the moment you create the account	Delete your account
Everything in section 3.6, reminders, Quiet hours, app preferences	Yes	Never	,	Sign out, or uninstall

The rest of this section is the detail behind that table.

All data you enter is written first to a local database on your device. The App is fully usable without an internet connection.
That local database is encrypted. It is opened with a 32-byte key held in your device’s keystore, under a setting that does not migrate to another device. Consequences you should know about before you change phones: on Android we have switched cloud backup and device-to-device transfer off for the App, so no new backup copy of it is made; on iOS, a copy of the database can still end up in an iCloud backup, but it is unreadable without the key, and the key never leaves the device. Restoring that backup onto a new phone therefore does not bring your diary with it: the App finds a database it has no key for, refuses to open it rather than silently starting empty, and will not run on that phone until you reinstall it or clear its data. Moving to a new phone goes through cloud sync, or through a .glumea archive you export and import yourself.
An account of yours exists on our servers from the moment you create one. It holds your account data, your profile, including your diabetes type, treatment methods and insulin delivery method, and your therapy settings: your target range, your insulin-to-carb ratio and your insulin sensitivity factor. Those are held on our servers whether or not you use cloud sync, and the way to remove them is to delete your account.
Cloud sync is a glumea+ feature, and it is off until you turn it on. What it controls is whether your diary is copied to our servers as well: your entries, your medication catalogs and your medication schedules. Turning it on takes two steps, and you can stop at either. Without an active glumea+ subscription the App shows you the subscription screen instead of switching anything on. With one, the App then asks you to confirm, in a step of its own, that you agree to your health data, glucose readings, insulin and medication records, food and weight entries, and anything you have typed into a note, being stored on our servers. It asks that every time the switch goes on, not only the first time. That confirmation is your explicit consent under Article 9(2)(a) GDPR for the diary. You can withdraw it at any time by turning Cloud sync off, and remove what we already hold with the delete your data link in the same sheet. With sync off, everything you log stays on your device only.
When sync is on, your data is stored on our backend at api.glumea.app, which runs on Google Cloud Run with a Google Cloud SQL PostgreSQL database, in Google’s europe-west1 region (Belgium).

The switch belongs to your account, not to the phone. We hold your answer on our servers, and the App reads it back from there when you sign in and when it reconnects. So it survives signing out, and it follows you: turn sync on, sign in on another phone, and sync is on there too without being asked again. Turning it off is recorded the same way. If you turn it off while you are offline, the App keeps that answer and delivers it to our servers at the next opportunity, a withdrawal is never rolled back because a request failed. On a shared device this cuts the other way from a device-only switch: the person signing in gets their own account’s answer, not the one the last person left behind.

If glumea+ ends, backup pauses, it does not withdraw your consent and it does not delete anything. When a subscription lapses, is canceled or is refunded, the App stops copying new data to our servers and the Sync sheet reads Paused, glumea+ has ended. What is already on our servers stays there, what is on your device stays there, and your stored answer to the consent question is left as it was, so if you subscribe again, backup resumes on that stored answer without asking you a second time. If you would rather it did not, turn the switch off: turning it off, and the delete your data link beside it, both stay available whether or not a subscription is live. Ending a subscription never takes away your ability to withdraw consent or to have the server copy erased.

Sync can also stop without you touching that switch. Your sign-in session can expire, and when it does we do not sign you out and we delete nothing: the App keeps every entry on your device, parks the backup, and waits. The Sync sheet then reads Paused and tells you that nothing is being synced until you log in again, and the Summary screen carries a banner about the expired session. Everything you log meanwhile stays on the device and reaches our servers only once you have signed in again. If you are relying on the server copy to survive a lost phone, that banner is the thing to act on.

The copy on our servers is protected by transport encryption, by Google’s storage encryption, and by our access controls. It is not end-to-end encrypted, and we can read it. glumea is not a zero-knowledge service. The only artefact in the whole system that we cannot open is a .glumea archive, because that is encrypted with a password only you know.

11. How long we keep your data

We keep your data for the periods below.

Account data, profile and therapy settings: kept on our servers for as long as your account exists.
Health entries and medication catalogs you have synced: kept for as long as your account exists, or until you delete the server copy or delete your account. Deleting a single entry works differently: it goes from the device you deleted it on, and from that device only. The copy on our servers stays, so the entry can come back on a reinstall, on a new phone, or after you sign out and sign in again. Only delete your data or deleting your account removes those rows from our servers.
Tombstones for entries you deleted: where a deletion of a single entry does reach our servers, the row is kept as a marker that still carries its value, its tags and its notes, so that the deletion can travel to your other devices. We have no job that prunes them, so they stay for as long as your account exists. Using delete your data, or deleting your account, removes them.
Sign-in sessions: an access token lasts 15 minutes. The session record on our servers expires after 90 days without use. Signing out revokes it immediately, so it can never be used again, but the row itself is removed by an hourly job once that 90-day window has run out. Deleting your account removes it at once.
One-time codes: expire 10 minutes after they are issued, and an hourly job marks expired ones unusable. We do not purge the records themselves: they stay until you delete your account, which removes them with everything else.
Server backups: 7 days. Data deleted from the live database persists in backups until they roll over.
Server request logs, which include IP addresses: 30 days.
Analytics events at PostHog: 12 months.
Diagnostic reports at Sentry: 90 days.
Subscription notification records: 90 days from the moment each message reaches us, after which a scheduled job deletes it. The job counts age and nothing else: it does not keep a row back for an open billing dispute, and deleting your account does not remove one any sooner.
Data stored only on your device: stays there until you delete it, sign out, delete your account, or uninstall the App. It is under your control.

12. Deletion: what happens and where

Before you start. Two things matter more than anything below, and they are both in the Terms of Service: cancel your glumea+ subscription in the store first, because deleting your glumea account does not stop the charges (section 13.1 there), and export first, because once your rows are gone we cannot build an export for you (section 13.3 there).

Three different controls, three different results. They are easy to confuse, so:

Control	Where it is	What it removes	What it keeps	What can undo it
Deleting a single entry	Wherever you logged it	That entry, on that device only	The server copy, which can bring it back	A reinstall, a new phone, or signing out and back in
delete your data	The Sync sheet, opened from the cloud button on Summary or History, not Settings	The server copy of your entries, medication catalogs and schedules	Your account, your profile, your therapy settings, and everything on your phone	Turning sync back on re-uploads from your phone
Delete account	Settings → Account details	Your whole account on our servers, and the App’s data on this device	Nothing of yours, subject to the destinations below	Nothing

delete your data needs a live sign-in and Cloud sync switched off first; the three notes at the end of this section explain why.

Deleting your account in the App is an immediate, permanent deletion from our production database. It does not reach everywhere. This is what happens at each destination.

Our production database: deleting your account performs a hard delete of your user record, at the moment you confirm it. Everything attached to it is removed with it by database cascade: your profile, your therapy settings, every synced glucose, food, weight, insulin, pill and injectable entry, your medication catalogs and schedules, your sessions, and your pending verification and reset codes. There is no soft-delete flag and no recovery.
Subscription notification records: each row holds your glumea account identifier and the full message RevenueCat sent. It is not linked to your account row, so the automatic cascade does not reach it. A scheduled job deletes each row 90 days after it arrived, whether or not you have deleted your account. The current flow does not support earlier removal through [email protected].
RevenueCat: RevenueCat holds its own subscriber record under the same account identifier, and deleting your account in the App does not reach it. No deletion request is currently sent to RevenueCat through [email protected].
PostHog: an analytics profile held under your account identifier is not removed by the database cascade, and deleting your account in the App does not reach it. No profile-deletion request is currently sent to PostHog through [email protected]. Pre-sign-in events use a pseudonymous device identifier instead of the account identifier.
Server backups: a copy of what was deleted persists in our hosting provider’s automated database backups until those backups roll over: 7 days, and in no case longer than six months after authentication where that statutory limit applies. Individual records are not edited inside a backup. A disaster-recovery restore can therefore temporarily reintroduce rows that were deleted from production.
Server logs: deleting your account does not retrospectively erase server request logs, which are kept for 30 days.
Sentry: the App attaches no account identifier, email address or user record to a diagnostic report. There is therefore no supported way to locate or delete an individual user’s reports. Reports produced by the operating system’s crash handler do not pass through the App’s filter, and we do not know every field the platform SDK adds. Reports expire under Sentry’s retention: 90 days. Article 11(2) GDPR addresses data for which the controller genuinely cannot identify the data subject.
Apple and Google: your purchase and subscription records belong to the store, not to us. Deleting your glumea account does not cancel a subscription and does not delete anything at Apple or Google. Cancel in your store account settings; their records are governed by their policies and by tax law.
Your own device: deleting the account, signing out or switching accounts wipes the local database, session credentials and stored preferences from that device. Clearing a telemetry preference does not reliably disable an SDK already initialized in the running process. A first-install flag and the database-encryption key can survive the wipe, but neither contains diary data. An iCloud device backup can contain an unreadable encrypted database copy; Android backup is disabled for the App.
Copies you made yourself: a .glumea archive, a CSV, a PDF report, anything you shared or saved elsewhere: these are yours and are outside our reach. Delete them where you put them.

To summarise the timing: deletion from our production database happens when you confirm it in the App. The current deletion flow does not pass the request to destinations outside the database cascade. In our hosting provider’s automated database backups, a copy persists until those backups roll over, 7 days.

The automatic cascade does not reach server request logs, Sentry reports, subscription notification records, RevenueCat’s subscriber record or a PostHog analytics profile. Server logs and Sentry reports expire under their configured retention periods. Subscription notification records expire after 90 days. Account deletion does not remove the RevenueCat record or PostHog profile.

Deletion is permanent. Deleted data cannot be recovered, so if you may need your records later, for your healthcare team, for instance, get a copy first using the export options described under your rights.

Account deletion currently requires the signed-in App. Deleting your glumea account explains that route and its limits.

Three more things about the narrower delete your data control, which removes the server copy of your entries, your medication catalogs and your medication schedules but keeps your account, your profile, your therapy settings and everything on your device:

It needs a live sign-in. If your session has expired, the state section 10 describes, where the sheet reads Paused: the link tells you to sign in again and does nothing until you do. Signing in again is enough; nothing is lost meanwhile.
It requires Cloud sync to be off first. If you switch sync back on afterwards, the entries still on your device are queued and uploaded again, the deletion on the server is undone by your own device.
It does not propagate to your other devices. They keep their local copies and are not notified.

13. Your controls in the App

You do not need to email us to control your data. The App gives you these built-in controls:

Delete account: in Settings → Account details, with type-to-confirm. Performs the server-side hard delete described above and wipes the App’s local database, session credentials and preferences from that device. The database cascade does not reach subscription notification records, RevenueCat or a PostHog analytics profile; section 12 states what persists.
delete your data: the link inside the Sync sheet, which opens from the cloud button at the top of the Summary or History screen rather than from Settings. Hard-deletes the server copy of your entries, your medication catalogs and your medication schedules, while keeping your account and the data on your device. It reaches no further than that: your profile and your therapy settings stay on our servers until you delete your account. Read the three notes just above.
Cloud sync: the switch in that same sheet, and a glumea+ feature. Turn it off at any time to stop new data reaching our servers, which is also how you withdraw your consent to us storing it; turning it off never needs an active subscription. Data already synced stays on our servers until you use delete your data or Delete account. Your answer to this switch is held on your account, so it survives signing out and follows you to a new phone.
Usage analytics and Error reporting: two independent switches in Settings → Data & privacy → Privacy & diagnostics. Current builds store both as enabled by default. Turning one off updates the preference, but queued data can still be delivered and sign-out does not reliably close an SDK already initialized in the running process.
Apple Health / Health Connect: connect, disconnect, or switch off individual data types in Settings → Integrations. You can also revoke the permission in the health platform itself.
Show details on lock screen: off unless you turn it on. Reminder notifications show generic text until you do.
Sign out: wipes the App’s local database, your session credentials and your preferences from the device, your analytics and diagnostics choices included. Nothing you logged and no choice you made is kept back; the deletion section names the two technical values that survive.
Export: a password-protected .glumea archive of your entries, medications, profile, therapy targets and reminders, from Settings → Data & privacy → Data import & export. The CSV and PDF glucose reports are a separate thing, produced from the glucose screen’s own export sheet; the archive and the CSV are free, and the PDF report is a glumea+ feature.

[email protected] is the general data-protection contact. It is not currently connected to an off-app deletion, export or rights-request workflow. The controls listed above require the App and, where stated, an active sign-in.

14. Your rights

Under the GDPR you have the right to:

Access your personal data and get a copy of it.
Rectify inaccurate or incomplete data. You can edit entries and medications where you logged them, your profile in Settings → Account details, and therapy settings where you set them. No separate off-app correction workflow is currently implemented.
Erase your data (“right to be forgotten”). The deletion section above tells you exactly what erasure reaches and what it does not.
Restrict processing in certain situations.
Data portability: receive the data you provided in a structured, commonly used, machine-readable format where the law provides that right. The in-app CSV glucose export is machine-readable and unencrypted. The .glumea archive contains entries, medications, profile, therapy targets and reminders, but it is encrypted with a password only you know and can be imported only into the glumea account that created it. No additional custom export is currently available through [email protected].
Object to processing based on our legitimate interests.
Withdraw consent at any time. Withdrawal does not affect processing that was lawful before withdrawal. For synced diary data, turn Cloud sync off and use delete your data, or delete your account. For analytics and diagnostics, use the two switches in Settings → Data & privacy → Privacy & diagnostics. There is no profile-only or therapy-settings-only removal control, and no such workflow is currently available through [email protected]. Deleting the account is the only implemented way to remove those fields from our production database.
Complain to a supervisory authority. Our lead supervisory authority is the President of the Personal Data Protection Office (Prezes Urzędu Ochrony Danych Osobowych), ul. Stawki 2, 00-193 Warsaw, Poland. You can also complain to the data protection authority in the EU member state where you live, where you work, or where you believe an infringement occurred. If you are in the United Kingdom, you can complain to the Information Commissioner’s Office (ICO), Wycliffe House, Water Lane, Wilmslow, Cheshire SK9 5AF.

Use the in-app controls described in section 13 where they cover the requested action. [email protected] is a general contact address, not an implemented off-app identity-verification or rights-request workflow. This limitation does not reduce any statutory right, response period or request-channel requirement.

If a controller does not act on a GDPR request, Article 12 requires it to explain the reason within one month and to identify the available complaint and judicial-remedy routes. Those routes remain available whether or not you contact the controller again.

Identity verification. The implemented controls rely on the user’s authenticated App session. No email one-time-code or alternative manual identity-verification workflow is currently implemented for off-app requests. This does not reduce any verification or response duty imposed by applicable law.

15. How we protect your data

Passwords are hashed with bcrypt, never stored in plaintext, and never stored on your device.
The local database on your device is encrypted, with a key held in the platform keystore that does not migrate to another device.
Authentication tokens are kept in your device’s secure storage, the iOS Keychain or the Android Keystore-backed store.
The App talks to our servers over HTTPS, and both platforms block cleartext connections by default, we have added no exception to that on either iOS or Android.
Our database runs inside Google Cloud, reachable only over a private Cloud SQL socket, with credentials held in Google Secret Manager.
We do not write the values you log, glucose readings, insulin doses, into our application logs. An error log line records the status code, the path, the time and the error message, which for a rejected request names the fields that failed validation. It does not contain the request body.
Reminder previews default to generic text, so a notification does not put your health data on your lock screen.
Access to the production database is limited to the people who operate the service, which means we can read it. What protects it from everyone else is access control and encryption in transit and at rest.

No system is perfectly secure. The measures above are what we do to limit how far the sensitive parts of your data are exposed.

An incident involving personal data may trigger notice to supervisory authorities or affected individuals under Articles 33 and 34 GDPR, the FTC Health Breach Notification Rule or other applicable law. Each regime has its own scope and deadline, and those statutory duties apply independently of this policy.

16. Children

glumea is not directed at children. You must be at least 16 years old to use the App. That is a condition of the service regardless of location. We do not offer a parental-authorization route. The in-app account-deletion process and the limits in section 12 apply to any account identified as belonging to a person under 16. Concerns about an underage account may be sent to [email protected].

17. Notes for users in the United States

US privacy law varies by state, and applicability depends on residence, statutory thresholds and the type of data involved. The in-app controls described in section 13 are available independently of those thresholds. Applicable statutory rights remain in force even where the current product lacks a separate request workflow.

HIPAA: glumea is a direct-to-consumer product. We do not deliver healthcare, we do not process claims, and we hold no contract with a health plan or a healthcare provider to handle data on their behalf, so we do not act in either of the roles HIPAA regulates, a “covered entity” or a “business associate”, and we do not claim HIPAA compliance. Records your own clinician holds about you are covered by HIPAA in their hands; that is separate from the copy you keep in glumea. The US rules we work to for glumea are the FTC’s health breach notification rule and the state health-privacy laws below.
California (CCPA/CPRA): applicability depends on the statutory business thresholds. The data described here can include sensitive personal information. We do not sell personal information or share it for cross-context behavioral advertising. If the CCPA applies, its access, correction, deletion, portability, opt-out and non-discrimination rules apply independently of this policy. The in-app controls remain available regardless of threshold. [email protected] is a general contact address, not an implemented off-app rights-request workflow.
Washington (My Health My Data Act): the data you log is “consumer health data”. Washington requires a separate policy for it; see the Consumer Health Data Privacy Policy. It describes the categories, sources, purposes, recipients, statutory rights and the current operational limits of the request and appeal process.
Nevada (consumer health data law, SB 370 of 2023): the data you log is “consumer health data” under Nevada law too. You have the rights to confirm whether we collect, share or sell it, to obtain a list of the third parties it has been shared with or sold to, to have it deleted, and to withdraw your consent, which Nevada treats as two separate consents, one to collection and one to sharing. Nevada’s law is enforced by the Attorney General. Our Nevada Consumer Health Data Privacy Notice sets out those rights, the deadlines that apply to them, which are shorter than Washington’s for a deletion, and the four disclosures Nevada asks for.
Requests and appeals. Applicable state law may require a written explanation, an appeal route and information about submitting a complaint to the state attorney general. No separate email appeal workflow is currently implemented at [email protected], so the current process does not provide that route where it is required. Washington requirements are described in the Consumer Health Data Privacy Policy.
Other applicable state-law rights are not limited by this policy.

18. The glumea.com website

The Website is a static site that hosts information about glumea and these legal documents. It is deliberately minimal:

No cookies.
No analytics, and no third-party-origin requests. Everything the page needs, fonts and scripts included, is served from glumea.com itself, and the site’s content security policy blocks any other origin outright. The page itself is delivered by our host, which necessarily sees the request; the last bullet in this list says who that is and what they log. The site does run a small amount of its own JavaScript: two inline snippets that apply your theme and send you to the right language, plus a few bundled files behind the navigation menu, the theme and language switchers, and the animation that reveals blocks as you scroll. None of it sends anything anywhere.
No tracking across sites, and therefore nothing for a Do Not Track or Global Privacy Control signal to switch off. The Website sets no advertising or analytics cookies, makes no third-party requests, and we do not sell or share personal information.
Browser localStorage is used only for functional preferences (your theme and language choice). These values stay in your browser and are not transmitted to us. They are set only because you chose a theme or a language, which is why no consent banner is needed for them.
The site is served by Firebase Hosting (Google). Like most web hosts, the provider may record standard server logs, IP address, request time, browser type, for security and to operate the service. We rely on legitimate interests (Article 6(1)(f) GDPR) for this, specifically keeping the site available and protecting it from abuse, and logs are kept only as long as needed for those purposes.

19. Changes to this policy

The current version is published here with its effective date. Applicable law determines whether a change requires advance notice, a renewed consent or another action. Publishing an updated policy does not itself authorize a new purpose that requires consent or another legal basis.

20. Language

This policy is published in English, Russian, Polish and Ukrainian. The English version is the legally binding one. The other three are translations, published so that you can read the policy in your own language. Where a translation and the English text differ, the English text is the one that governs.

The exception is the law itself. Where the country you live in gives the language you were addressed in a status of its own, as the consumer protection law of several countries does, that rule applies instead of this one, and nothing here takes away a right you have under it.

A translation is published when it is ready, so it can lag behind the English text after an update. If you find a place where a translation and the English text say different things, tell us at [email protected].

21. Contact us

Questions, concerns, or requests about your data:

Email: [email protected]
Post: Paweł Milewski Software Development, ul. Franciszka Bohomolca 3 lok. 7, 31-416 Kraków, Poland

Related documents: Terms of Service, Medical Disclaimer, and, for Washington residents, our Consumer Health Data Privacy Policy, or for Nevada residents our Nevada Consumer Health Data Privacy Notice.