# Data subject rights **Summary:** How Unless handles personal data under the GDPR, the roles of controller and processor, and how data subjects exercise their rights to access, rectification, erasure, restriction, and portability through our platform. **In short:** One place to understand how we process personal data under the GDPR and how your end users exercise their rights. **Last updated:** 2026-06-18 This page brings together how Unless handles personal data under the GDPR. It is written for the compliance officers of our customers, so you can see in one place who is responsible for what, how we process personal data, and how your end users exercise their rights. It summarizes commitments set out in our data processing addendum and points to the detailed pages where relevant. This page is not legal advice. Every deployment is different, so review our data processing addendum and consult your own legal team. ## Controller and processor roles Under the GDPR, our customer is the controller and Unless is the processor. The customer decides why and how personal data is processed, and Unless processes it on the customer's documented instructions to deliver the service. The main agreement, the data processing addendum, and any order form together form those instructions. This split matters for accountability. The customer is responsible for having a lawful basis for the personal data it brings into the platform and for informing its own end users. Unless is responsible for processing that data securely, only for the agreed purpose, and for supporting the customer in meeting its own obligations. Privacy at Unless is overseen by our Data Protection Officer, who can be reached at dpo@unless.com. ## What personal data we process By default the personal data we process is minimal. The AI does not need identifiable end-user data to work. Richer personal data is only processed when a customer imports it or an end user provides it during a conversation. Unless processes two kinds of personal data, and the difference matters. The first is technical request data that every browser sends with every request: an IP address (with the last octet stripped before storage, so 1.2.3.4 becomes 1.2.3.0), browser and device information, page views, and rough geographic location. This passes through our system whenever the platform is used, but by default we do not store it or tie it to a person. It only gets stored and linked if a controller deliberately builds audiences with a lifetime longer than a single session and triggers our consent API. Neither is on by default, so it cannot happen by accident. The second is input, meaning data that is actively submitted. That is either an end user or agent typing into the assistant, or controller data that the controller sends us through our browser API or a back-end integration. All input is screened for PII on our back-end. Anything found is masked or deleted before it is stored or passed to a model. ## Privacy by design The platform is built to be sensitive to end-user privacy through a few core choices. We do not collect unnecessary data, only what the service needs. We aggregate and anonymize wherever possible, which reduces the chance of identifying an individual end user. Personal data is either kept out of the AI models entirely or tokenized through our Privacy Vault, so raw identifiers never reach the models. For the full picture of where each data type lives, see the data and locations page. ## Lawful basis and consent The lawful basis sits with the customer as controller. We provide the technical means to support common bases: - For anonymous end users, tracking features stay off until consent is given through the Consent API. - For logged-in users, the Identify API can be used under a legitimate interest basis. Without an opt-in, tracking features simply do nothing for that user, and the experience stays cookieless. The end-user tracking page explains the consent options and the specific cookies in detail. ## Data subject rights Data subjects exercise their rights through the customer as controller, using standard GDPR and data subject access request channels. Unless supports these requests technically rather than bypassing the controller. The controller initiates each request from our dashboards, and there is a human in the loop on our side to verify before anything changes. - Right of access (Article 15) and rectification (Article 16): the controller performs these from the dashboard. Tokens generated for personal data are orphaned if the underlying value changes, which prevents token hijacking. - Right to erasure (Article 17) and restriction (Article 18): the controller requests these from the dashboard. Tokens are orphaned if the underlying value is deleted. - Right to data portability (Article 20): handled through the same flow. The system exports the relevant personal data in a structured, commonly used, machine-readable format such as JSON or CSV, so it can be moved to another controller or returned to the data subject. - Right to object (Article 21) and rights related to automated decision-making (Article 22): supported through the controls described above and the human oversight built into the platform. If we receive a request directly from a data subject, we forward it to the controller without undue delay, and in any event within five business days, and we do not respond ourselves unless instructed to or required by law. Standard assistance with these requests is included in the service. We may charge a reasonable fee only for assistance that is substantially disproportionate to the nature of the service. ## Data retention and deletion We retain personal data only for as long as we provide the service to the customer, and our retention times are no longer than 365 days. After the agreement ends, we delete or return the personal data in our possession, except where we are required by law to keep some of it, in which case we prevent any further processing. Backups are kept on a shorter cycle: continuous database backups are retained for thirty-five days, encrypted in transit and at rest. ## Breach notification If we become aware of a personal data breach, we notify the customer without undue delay, and in any case within 48 hours, so the customer can meet its own notification obligations under Article 33 of the GDPR. The notification includes the information the customer reasonably needs, to the extent known at the time, and we supplement it as more becomes available. We use reasonable efforts to help the customer mitigate the effects of a breach. ## Sub-processors Certain sub-processors are needed to run the service. The customer gives general consent to engage them, on the condition that each is bound by obligations at least as strict as ours. When we add or change a sub-processor, we inform the customer in advance, and the customer has 20 business days to object on reasonable grounds. The current sub-processors that may handle user or end-user data are Amazon Web Services, Microsoft Azure, and Google Cloud Platform, all in the EU. A separate set is used strictly for our dashboard and administration rather than the platform itself. The sub-processors page holds the full, current list. Large language models used by the platform run within the environments of these cloud sub-processors. We do not transmit customer data directly to separate model vendors, so customer data stays inside the cloud sub-processor boundary. ## International transfers All platform personal data is hosted within the EU. Where a sub-processor would involve a transfer outside the EEA to a country without an adequacy decision, we put in place an appropriate transfer mechanism under Chapter V of the GDPR. The default is the 2021 Standard Contractual Clauses, with the UK International Data Transfer Addendum applied where UK personal data is involved. Before any such transfer, we run a transfer impact assessment and add supplementary measures where needed. We make the assessment available to the customer on reasonable request, and we suspend a transfer if the chosen mechanism stops providing a valid basis. ## Assistance with DPIAs and authority consultations We provide reasonable assistance to the customer with Data Protection Impact Assessments under Article 35, with prior consultations with supervisory authorities under Article 36, and with any inquiry or investigation from a supervisory authority relating to the processing under our agreement. This assistance takes into account the nature of the processing and the information available to us. For your own DPIA, see the DPIA considerations page. ## Audit rights The customer may audit our compliance with the data processing addendum up to once a year, or more often where its own legislation requires. Audits are arranged on reasonable notice with an agreed scope. Where the relevant scope is already covered by an ISO, ISAE, or similar assurance report from a qualified third-party auditor within the prior 12 months, and there are no known material changes, the customer may rely on those findings instead of running a fresh audit. ## Related pages - [Data and locations](/en/legal/resources/data-and-locations/), for where each data type is stored and the data residency model. - [End user tracking](/en/legal/resources/cookies-and-tracking-for-end-users/), for cookies, the Consent and Identify APIs, and consent guidance. - [DPIA considerations](/en/legal/resources/dpia/), for running your own impact assessment. - [EU AI Act compliance](/en/legal/resources/eu-ai-act-compliance/), for the provider and deployer roles around the AI system. - [Security overview](/en/legal/resources/security-overview/), for our technical and organizational security measures.