Scope and operating boundary
This page explains the relevant product boundary, provider dependency and customer responsibility in plain language.
Data requests
Data requests, written around the service you actually use.
Provide a verified identity-check and request path for access, correction, export or deletion without collecting unnecessary sensitive details.
Current limitation
It does not invent a legal entity, jurisdiction, provider list, retention period or right that has not been confirmed.
Decision this page supports
You can understand the practical boundary and identify the facts that belong in an agreed service document.
Current published text
The text that applies today is published in English in the Rellooma app.
Working legal draft · English canonical
Draft clauses for owner and counsel review
This English text is a non-operative review draft. It is not an effective policy, executed agreement or legal advice. Facts and clauses marked as open must be verified before publication.
DRAFT — NOT EFFECTIVE. No customer agreement or legal commitment is created by this page.
Request types & secure route
Identity verification
Rights & secure requests
Status & response handling
Operator & contact identity
Secure requests
The published route must reach a monitored privacy contact. Verify the requester's authority proportionately and do not request passwords, session cookies, MFA codes or complete private conversation histories as identity proof.
Request handling
The operational workflow should record scope, verification, responsible team, applicable response timing, permitted extensions or exceptions, and completion evidence. No mailbox or response SLA is treated as active until tested.
Complaints
A final notice should state the competent regulator and complaint route applicable to the confirmed controller and data subject. Counsel must verify jurisdiction and wording.