Security & Data Handling

Data moves between the GlucIQ app or gluciq.com and our backend through a single API gateway, encrypted with TLS 1.2 or later. Account and health records live in a managed Postgres backend, meal images live in managed object storage, Cloudflare hosts and fronts gluciq.com and runs its DNS, and Clerk issues the sessions the gateway validates. The Privacy Policy covers what we collect and why.

How the service is built

The app reaches our backend through a single API gateway. It never calls a backend service, a model provider, or a storage system directly. Behind the gateway sit the services that handle accounts, glucose data, nutrition analysis, recipes, and fasting. That is the whole path. We publish which processors receive personal data and what they receive, not the internal topology that sits behind them.

The processing regions for the managed backend and the object storage are kept in our sub-processor record, and writing to [email protected] with the subject Sub-processor list gets you the current version, regions included. Confirmation comes first. A wrong region is worse than a slow one.

Encryption

The app’s on-device database relies on the operating system’s file encryption alone. No application-level cipher sits on top. If you need one, the current app does not provide it.

Access control

Access is role-based and least-privilege. An engineer gets the access their function needs and nothing more. Support staff have no standing access to the production database and work from account tools and the tickets you send rather than raw table access. Administrative access requires multi-factor authentication, production access is logged, reviewed, and revoked when a role ends, and application secrets sit in a managed secret store. Secrets never touch source control.

Sub-processors

Third parties that process personal data for the product:

We add a processor only for a defined product purpose. Each one is bound by contract to protect the data it receives. Write with the subject Sub-processor list for the current list, including each processor’s region and service description. For a data processing agreement, use DPA request.

Data minimization

The meal analysis pipeline receives the photo and the context the estimate needs: diabetes type, current and target glucose, insulin parameters, and basic body data. Nothing outside that estimate goes with it. Error and log records redact email addresses, phone numbers, dates of birth, and secrets, but keep a user identifier so a support engineer can trace one report to one account without exposing contact details in the logging system. That identifier is deliberate. The app sends data to our backend only for the features you use, and never to a model provider or storage system directly.

Retention summary

Full retention rules sit in the Privacy Policy.

• Account, profile, and health records are kept while the account is active.
• When you delete the account, those records are removed from the active service. They are retained only for the legal reasons listed on Account & Data Deletion.
• A meal image is processed to produce an analysis and then deleted, and all meal images are deleted with the account. One engineering gap remains for images attached to expired or failed analysis jobs. The definitive period will be published in the Privacy Policy when that fix ships. That fix is on our launch checklist.
• Security and audit logs are kept for a limited period and then deleted.

Vulnerability handling

1. Intake. Report a vulnerability to [email protected] with the subject Security report. Name the affected component and the steps to reproduce it.
2. Triage. We assess it within five business days and tell you whether we consider it in scope.
3. Remediation. We set a fix timeline by severity and keep you posted at each stage.
4. Disclosure. We follow coordinated disclosure. Protection covers researchers who act in good faith, avoid privacy violations and service disruption, and give us a reasonable window before publishing, and we will not pursue, report, or take legal action against them. Ask for credit. We will name you in the fix note.

Incident response and breach notification

We maintain an incident process covering detection, containment, assessment, and notification. If a personal data breach creates a risk to rights and freedoms, we act within the legal deadlines.

Under the General Data Protection Regulation, a breach that requires notification goes to the competent supervisory authority within 72 hours, under Article 33. Where it is likely to result in a high risk, we notify affected users without undue delay, under Article 34. Under the United Arab Emirates Personal Data Protection Law, we notify the relevant authority and affected data subjects as that law requires.

What we do not do

We sell no personal data and run no advertising SDK, and health data never feeds advertising, marketing, or our own model training, and the app integrates with neither Apple HealthKit nor Google Health Connect today. Consent comes first if that changes. This page and the Privacy Policy change before any integration ships.

Compliance posture

Contact

Security questions, sub-processor requests, and DPA requests go to [email protected]. Data-subject requests are handled under the Privacy Policy.