Data Handling Policy & Procedures — Individual Users

Last updated: 20 September 2026 · Version: 1.0 (draft — pending legal review)

This document sets out how Levantra ("we", "the Platform") handles the personal data of individual users in practice: what we collect, the technical and organizational measures we apply, our sub-processors, our retention schedule, and our procedures for data-subject requests and security incidents. It is the operational companion to our /en/pages/privacy, written for readers who want the procedural detail behind that policy — prospective enterprise or clinic partners conducting due diligence, auditors, and our own staff.

1. Purpose and scope

This policy implements the principles of Article 5 GDPR (lawfulness, fairness, transparency, purpose limitation, data minimization, accuracy, storage limitation, integrity and confidentiality, and accountability) in the specific context of an AI-assisted skincare platform that processes special-category biometric and health-related data. It applies to every system and person that touches individual users' personal data on our behalf: our own engineering and support staff, and the sub-processors listed in §6.

2. Roles and responsibilities

Data controller: Levantra determines the purposes and means of processing individual users' personal data.
Data Protection Officer: [Legal review note: appoint and name a DPO here if required under Article 37 GDPR given your processing volume and the special-category data involved, or record the basis on which one is not required.]
Processors: the sub-processors listed in §6, each bound by a data processing agreement limiting their use of the data to our instructions.
A linked clinic acts as an independent data controller for the clinical notes and treatment decisions it records about its own client relationship with a user, once that user has consented to share their profile with that clinic. The Platform is a processor for the purpose of hosting that relationship. [Legal review note: this controller/processor allocation should be reflected in a data processing agreement between the Platform and each clinic — see /en/pages/data-handling/clinics-vendors.]

3. Data inventory

Category	Examples	Source	Special category?
Identity & account	Name, email, phone, password hash, date of birth, gender, locale	User-provided	No
Location	Country, city, street address, coordinates	User-provided / device, with permission	No
Skin-health questionnaire	Skin type, concerns, allergies, medications, pregnancy status, diagnosed conditions	User-provided	Yes — health data
Skin-analysis photographs	Face photograph	User-captured/uploaded	Yes — biometric/health data
Skin-analysis scores	Per-concern numeric scores 0–100	Derived by AI processing of the photograph	Yes — derived from special category data
Orders	Products, quantities, price, shipping address, status	User action	No
Payment outcome	Authorization/capture/refund status and a gateway reference	Payment processor	No (card data itself is never received by us)
Communications	AI chat messages, specialist messages, clinic messages, attached images	User-provided	Potentially, if health-related content is written into a message
Consent records	What was granted/withdrawn, when, in relation to what	System-generated	No, but records processing of the above
Device & technical	IP address, device type, push token	Automatic	No

4. Data minimization and purpose limitation in practice

A face photograph is used only to compute the requested analysis and is never attached to any purpose beyond that analysis and, where the user opts in, sharing it with a clinic they have consented to share with.
The AI assistant receives only the current message's attachment, not the full image history of a conversation — older images are not resent to the AI provider on every turn.
Recommendations exclude, rather than merely flag, any product or ingredient ruled out by a declared pregnancy, allergy, or oral retinoid therapy — this is a data-minimization control on the output side: unsuitable options are removed from the candidate set before any further step (rule engine or AI) can select them.
A clinic sees only the parts of a client's profile the client has actively consented to share with that specific clinic — consent is per-clinic, not a single global toggle, and a client linked to two clinics can share different information with each.

5. Security measures

Encryption in transit: all traffic between clients (web, mobile) and our servers, and between our servers and every sub-processor, uses TLS.
Encryption at rest: database and file storage are encrypted at rest by our hosting sub-processor.
Signed, time-limited access to photographs: no skin-analysis photograph is ever given a public or permanent URL. Every read is through a cryptographically signed link with a short expiry (typically minutes), generated fresh per request.
Authentication: passwords are hashed (never stored in plain text); optional two-factor authentication is available; session tokens are short-lived and refreshable, with the ability to revoke all other active sessions on password change.
Authorization: every access to personal data is checked in application code against the caller's identity and role before the request is served — an object identifier alone (such as a record ID in a URL) is never treated as sufficient authorization on its own.
Row-level access control at the database layer is enabled as a second, independent line of defense beneath the application layer.
Audit logging: every access a clinic staff member makes to a client's clinical data is logged with the actor, the action, and the time.
Least privilege: clinic staff permissions are role-based, and a role that does not include clinical-notes access cannot read clinical notes regardless of other permissions it holds.
Vendor and clinic account separation: a person's customer account and any staff account they hold at a clinic are kept as separate identities, so one login cannot silently gain both a customer's personal history and a clinic's access to other clients' records.

6. Sub-processors

Sub-processor	Role	Data involved	Location (at time of writing)
Anthropic	AI vision analysis and chat assistant	Skin-analysis photographs (per-analysis); chat messages; most recent chat attachment	United States
Stripe	Payment processing, vendor payouts, subscription billing	Order/subscription amounts, payment outcome, vendor payout allocation — not full card numbers	United States (processes globally)
Supabase	Database hosting, private object storage	All categories in §3, as stored data	European Union — Stockholm, Sweden (eu-north-1)
Railway	Application (backend) hosting	All categories in §3, in transit/processing	[confirm region]
Vercel	Website hosting	Account session tokens (client-side), page content	[confirm region]
SendGrid (Twilio)	Transactional email delivery	Recipient email address, message content (account, order, and clinic-alert emails)	United States
Telegram	Optional clinic alert channel	Alert content a clinic has opted to receive this way — not full client records	[Telegram's own infrastructure]

[Legal review note: this table must be kept current as sub-processors change, and a mechanism for notifying users of a new or replaced sub-processor should be defined — commonly, an update to this document with a summary in the privacy policy's change log.]

7. International transfer mechanisms

Where a sub-processor in §6 is located outside the EEA, transfers rely on Standard Contractual Clauses, an applicable adequacy decision, or another lawful transfer mechanism. [Legal review note: confirm and document the specific mechanism per sub-processor, and keep signed SCCs (or equivalent) on file.]

8. Retention schedule

Data	Retention period	Deletion mechanism
Skin-analysis photograph	Per the user's own retention setting (immediately / 1 week / 1 month / 3 months)	Automated daily sweep; "immediately" is applied right after scoring
Skin-analysis scores	Account lifetime, or until the user deletes the analysis	User action, or account deletion
Account/profile data	Account lifetime	On deletion request: anonymized (see §9) rather than hard-deleted, to preserve records we have an independent legal basis to keep
Refresh/session tokens	Revoked immediately on password change, sign-out, or account deletion	Automatic
Orders and invoices	Per applicable tax/accounting retention law	Not deleted on account deletion; this is a legal record, not a service record
Consent and consent-log records	Retained as an audit trail, including after account deletion	Not deleted; this is itself the compliance record
Location snapshots, device tokens, notification preferences	Account lifetime	Deleted on account-deletion request

9. Data-subject request procedure

Access / export: available as a self-service export feature in the user's own account, returning profile, consents, skin analyses, routines, orders, reviews, and wishlist data in a structured format. A request received by any other channel (for example, email) is fulfilled manually within the statutory time limit.
Rectification: most fields are directly editable by the user; a request to correct a field that is not self-service is handled manually.
Erasure: available as a self-service account-deletion request, and is never refused for a user's own request, consistent with the right to erasure. On deletion: the account is anonymized (name, email, phone, and credentials removed); biometric photographs and their scores are deleted; any pending request the user had open with a clinic is closed out, and the clinic's own record of it is preserved as the clinic's business record; any active clinic link is ended; any active subscription is cancelled outright with the payment processor, so billing does not continue against an account that can no longer sign in to stop it; and records we have an independent legal basis to retain (orders/invoices for tax purposes, consent logs as an audit trail) are kept, consistent with §8.
An administrator-initiated removal of an account (as opposed to the user's own request) is handled differently and more conservatively: it is refused, by name, while the account still has a live paid subscription, a pending request at a clinic, or an active clinic link — an administrator suspends (blocks) the account instead in that case. This distinction exists because the user's own erasure request is a right that must always be honored, while administrative tidying is not, and must not be used to sever a relationship the user has not asked to end.
Every request, however received, is logged and tracked to completion within the statutory time limit (one month under the GDPR, extendable by two further months for complex requests, with notice given to the requester).

10. Security incident / breach notification procedure

[Legal review note: this section is a procedural skeleton and must be completed with real named roles, a specific notification template, and confirmed timelines before publication.]

Detection & containment. Any suspected incident is escalated immediately to the operator (contact@dermaid.se), who contains the exposure (e.g., rotating a leaked credential, disabling a compromised account, patching a vulnerability).
Assessment. Determine what data and how many individuals are affected, and whether the incident is likely to result in a risk to the rights and freedoms of the individuals concerned.
Regulator notification. Where required, notify the relevant supervisory authority (for Sweden, IMY) within 72 hours of becoming aware of the breach, per Article 33 GDPR.
Individual notification. Where the breach is likely to result in a high risk to affected individuals, notify them directly and without undue delay, per Article 34 GDPR, describing the nature of the breach, likely consequences, and measures taken.
Record-keeping. Document every breach, regardless of whether notification was required, including facts, effects, and remedial action taken (Article 33(5)).
Post-incident review. Identify and implement measures to prevent recurrence.

11. Consent management

Each consent type (biometric analysis, marketing, clinic data-sharing per clinic, AI-chat profile access, age self-declaration, and acceptance of terms/medical disclaimer) is recorded as an individual, timestamped grant, separate from general acceptance of terms.
Withdrawal is available directly in account settings for every consent type except the mandatory registration-time acknowledgments (terms of service, medical disclaimer), which are conditions of using the Service rather than optional processing.
An immutable log mirrors every grant and withdrawal, kept as the audit trail described in §8.

12. Staff access and training

[Legal review / operational note: complete with your actual policy once staff are hired — for example: access to production personal data is limited to staff whose role requires it; all staff with such access complete data-protection training before being granted it and refresher training annually; access is reviewed periodically and revoked immediately on role change or departure.]

13. Sub-processor due diligence

Before engaging a new sub-processor with access to personal data, we assess its security posture and data-protection commitments, and put a data processing agreement in place before any live data is shared with it. §6 is updated as part of that process.

14. Review cadence

This policy is reviewed at least annually, and additionally whenever we introduce a new category of personal data, a new sub-processor, or a new region of operation.

This document is a draft prepared for legal review and has not yet been finalized by counsel.