Skip to main content

Legal

Data processing addendum

The processor terms that apply when Lupee handles data on behalf of your organisation, including the subprocessor list.

Draft, not yet reviewed by a lawyer

This document was written by the product team and has not been through legal review. It is published here so you can read what is intended, not as a binding agreement. The reviewed version replaces it before the product takes its first payment, and the effective date will say so.

Lupee Data Processing Addendum

Version: 13 November 2026

1. The parties and how this fits together

1.1 This Data Processing Addendum ("DPA") is between:

  • the Customer, the entity that has agreed to the Lupee Terms of Service,

acting as controller (or as processor for its own customer, in which case it acts as controller towards us as a matter of contract); and

  • ILLUSNT LLC, 1209 Mountain Road Pl NE, Ste R, Albuquerque, NM 87110, USA, registered in the State of New Mexico, USA,

acting as processor ("we", "us").

1.2 This DPA is incorporated into the Terms of Service at https://lupee.app/terms and applies whenever we process Customer Personal Data on the Customer's behalf. A Customer that needs a signed copy may request one at [OWNER TO CONFIRM: legal mailbox, proposed legal@lupee.app]. If there is a conflict between this DPA and the Terms, this DPA controls on the subject of data protection.

1.3 This DPA does not apply to data for which we are the controller in our own right, listed in section 5 of the Privacy Policy. That data is governed by the Privacy Policy.

2. Definitions

"Data Protection Law" means, as applicable: Regulation (EU) 2016/679 (GDPR); the UK GDPR and Data Protection Act 2018; the Swiss Federal Act on Data Protection; the California Consumer Privacy Act as amended by the CPRA; and any other privacy or data protection law that applies to the processing.

"Customer Personal Data" means personal data contained in Message Data and in the Commitments derived from it, and any other personal data we process on the Customer's behalf under the Terms.

"Message Data", "Commitment", "Connected Channel", "Workspace" and "Service" have the meanings given in the Terms of Service.

"Sub-processor" means a third party engaged by us to process Customer Personal Data.

"SCCs" means the Standard Contractual Clauses in Commission Implementing Decision (EU) 2021/914 of 4 June 2021.

"UK Addendum" means the International Data Transfer Addendum to the SCCs issued by the UK Information Commissioner under section 119A of the Data Protection Act 2018, version B1.0.

"Personal Data Breach", "processing", "controller", "processor", "data subject" and "supervisory authority" have the meanings given in the GDPR.

3. Roles and scope

3.1 The Customer is the controller and we are the processor of Customer Personal Data. Where the Customer is itself a processor, we are a sub-processor and the Customer warrants that it has the controller's authority to appoint us on these terms.

3.2 The subject matter, duration, nature, purpose, categories of data and categories of data subject are set out in Annex 1.

3.3 Each party complies with the Data Protection Law that applies to it. The Customer is responsible for the lawfulness of the personal data it puts into the Service, for having a lawful basis for the processing it instructs, and for giving any notice and obtaining any consent that is required from the people whose messages are ingested, including people who are not Lupee users.

3.4 The Customer confirms that it has the right to enable each Connected Channel and to have the messages in it processed. We rely on that confirmation.

3.5 Channels the Customer must not enable. The Customer will not enable a Connected Channel whose ordinary subject matter is data falling within Article 9 GDPR or Article 10 GDPR. That means, in particular, channels used for health or occupational health matters, HR case work, disciplinary or grievance process, whistleblowing, trade union business, legal advice, or criminal allegations and convictions. The Service is not designed for that data, no Article 9 condition covers processing it here, and the per-channel opt-in exists so that these channels can be kept out. Free-text chat can of course contain anything, and this clause is about what a channel is for rather than about a stray sentence in a channel that is for something else.

3.6 Employment monitoring. Where the Customer is an employer and enables a Connected Channel in which its workers post, the Customer warrants that it has complied with the law of each country whose workers are affected, including any requirement that is procedural and must be completed before deployment. Without limiting that warranty, the Customer is on notice that:

  • France requires individual prior information of employees under Article

L1222-4 of the Code du travail, and information and consultation of the social and economic committee before the introduction of technology capable of monitoring employee activity, under Article L2312-38;

  • Germany gives the works council a co-determination right under section

87(1) no. 6 BetrVG over technical devices suitable for monitoring the conduct or performance of employees. Suitability is assessed objectively, so the right arises whether or not monitoring is intended, and a works agreement is required before deployment;

  • Italy restricts remote monitoring of workers under Article 4 of law

300/1970, which generally requires either an agreement with the union representatives or an authorisation from the labour inspectorate, and requires that workers be given adequate information about how the tool works before any data may be used for employment purposes;

  • the United Kingdom Information Commissioner's guidance on monitoring

workers applies to productivity tools and requires a lawful basis, transparency to workers, and an impact assessment where the monitoring is systematic;

  • other countries have comparable works council, union or employee

representative requirements, and this list is not exhaustive.

We will provide reasonable assistance with those steps, including a description of what the Service reads and what it produces, but we cannot take them for the Customer and we do not verify that they have been taken.

3.7 The Customer will not use the Service to make a decision about a person by automated means. Extraction produces a suggestion for a person to review. If the Customer builds a process in which an output of the Service determines, or substantially determines without meaningful human involvement, an outcome concerning an individual's pay, promotion, discipline, redundancy, contract renewal, engagement or selection, that is the Customer's processing under Article 22 GDPR and the Customer is responsible for its lawfulness, for the safeguards Article 22(3) requires, and for the transparency the individual is owed.

3.8 Platform terms bind the Customer as well as us. The platforms the Customer connects impose their own limits on how their data may be held and used, independently of Data Protection Law. Those limits can be shorter than the retention window the Customer selects, and where they are, the platform's limit applies to data from that platform. In particular, Slack permits only limited and temporary storage of another organisation's data and prohibits persistent copies, archives, indexes and long-term data stores; Discord restricts retention of message content to what is necessary; and both prohibit the use of message content to train a large language model. We will apply the platform's limit where it is shorter, and we will tell the Customer which of its sources are capped and at what.

4. Our obligations as processor

We will:

4.1 Process only on instructions. Process Customer Personal Data only on the Customer's documented instructions, including for transfers to a third country, unless required otherwise by law that applies to us, in which case we will tell the Customer before processing unless that law forbids it on important grounds of public interest. The Terms, this DPA, and the Customer's use of the Service's settings, including which channels it enables and what retention window it sets, are the documented instructions.

4.2 Tell the Customer if, in our opinion, an instruction infringes Data Protection Law. We may suspend the affected processing while the point is resolved.

4.3 Confidentiality. Ensure that everyone we authorise to process Customer Personal Data is bound by an appropriate duty of confidentiality and is trained on their obligations.

4.4 Security. Implement and maintain the technical and organisational measures in Annex 2, taking into account the state of the art, the cost of implementation, and the risk to data subjects.

4.5 Sub-processors. Engage sub-processors only under section 6.

4.6 Data subject requests. Assist the Customer under section 7.

4.7 Breach. Notify and assist under section 8.

4.8 Assessments. Provide reasonable assistance with data protection impact assessments and prior consultations under Articles 35 and 36 GDPR, taking into account the nature of the processing and the information available to us. We have carried out our own assessment of the processing described in Annex 1, and we make it available to the Customer on request under a confidentiality undertaking. It sets out the categories of data subject, the lawful bases we consider available to a controller in the Customer's position, the risks we have identified, the measures that address them, and the residual risks that remain. It is a starting point for the Customer's own assessment and it is not a substitute for it: the Customer knows its channels, its people and its purposes, and we do not.

4.9 Deletion or return. At the Customer's choice, delete or return all Customer Personal Data at the end of the Service, and delete existing copies, unless law requires storage. Our default is deletion, on the timetable in section 11.

4.10 Demonstrate compliance. Make available the information reasonably necessary to demonstrate compliance with this DPA, and allow audits under section 9.

5. AI processing: a specific instruction

5.1 The Customer instructs us to transmit Message Data to Anthropic, PBC, as a sub-processor, so that a large language model can extract Commitments. This is essential to the Service and cannot be disabled while the Service is in use for a Connected Channel. Disabling a channel stops it for that channel.

5.2 We apply an automated redaction pass to Message Data before transmission to the model provider, targeting patterns that resemble credentials, tokens, payment card numbers and direct identifiers such as email addresses and telephone numbers. The Customer acknowledges that this is a best-effort filter and not a guarantee, and remains responsible for what its users put into Connected Channels.

5.3 Under our agreement with the model provider, Customer Personal Data submitted through the commercial API is not used to train the provider's models. The provider may retain inputs and outputs for a limited period for trust and safety and legal compliance purposes. The current period and terms are stated in the subprocessor list at https://lupee.app/subprocessors.

5.4 We do not use Customer Personal Data to train or fine-tune any model. We use the Customer's confirmations and rejections of extracted Commitments to rank, score and filter results for that Customer's own workspace only, and never to train a model on the underlying message content.

5.4a That commitment is also a requirement of the platforms the Customer connects, which is why it is drafted as an absolute rather than as a policy we could change. Discord's Developer Policy prohibits the use of message content obtained through its APIs to train machine learning or AI models, including large language models, without Discord's express written permission. Slack's API terms state that API Data may not be used to train a large language model. Transmitting text to a model so that it can extract commitments from one batch of messages is inference and is permitted; training and fine-tuning are not. This obligation survives any change to our own product plans, and it applies to our sub-processors on the same terms.

5.5 Extraction output is probabilistic and can be wrong. The Customer remains responsible for any decision it takes on the basis of that output. This processing does not involve automated decision-making producing legal or similarly significant effects within the meaning of Article 22 GDPR, because every extracted Commitment is presented for human review before it has any effect.

6. Sub-processors

6.1 General authorisation. The Customer gives a general authorisation for us to engage sub-processors. The current list is in Annex 3 and is maintained at https://lupee.app/subprocessors.

6.2 Flow-down. We impose data protection obligations on each sub-processor that are no less protective than those in this DPA, and we remain fully liable to the Customer for a sub-processor's performance.

6.3 Notice and objection. We will give at least 30 days' notice before adding or replacing a sub-processor. The Customer can subscribe to notice at https://lupee.app/subprocessors. Within 30 days of notice the Customer may object on reasonable data protection grounds, in writing to [OWNER TO CONFIRM: privacy contact mailbox, proposed privacy@lupee.app]. We will work in good faith to find an alternative. If we cannot, the Customer may terminate the affected part of the Service, or the Service as a whole where the sub-processor is essential to it, and receive a refund of prepaid fees for the unused period. That is the Customer's sole remedy.

6.4 Emergency replacement. If a sub-processor must be replaced urgently for security, legal or continuity reasons, we may do so immediately and will notify the Customer as soon as we can.

7. Data subject requests

7.1 The Service gives the Customer self-service tools to access, export, correct and delete Customer Personal Data, including whole-workspace deletion and account deletion. Disabling a Connected Channel stops further ingestion from it and is not itself a deletion: Message Data already stored from that channel is removed on the ordinary retention window.

7.2 If a data subject contacts us directly about Customer Personal Data, we will not respond substantively other than to acknowledge and redirect, and we will pass the request to the Customer without undue delay, unless the Customer has instructed us otherwise or law requires otherwise.

7.3 Where the self-service tools are not enough, we will give the Customer reasonable assistance, taking into account the nature of the processing. We may charge for assistance that goes materially beyond what is reasonable, at rates notified in advance.

8. Personal data breach

8.1 We will notify the Customer without undue delay, and in any event within 72 hours, after becoming aware of a Personal Data Breach affecting Customer Personal Data.

8.2 The notice will describe, to the extent known: the nature of the breach, the categories and approximate number of data subjects and records concerned, the likely consequences, the measures taken or proposed, and a contact point. Where we cannot provide all of it at once, we will provide it in phases without further undue delay.

8.3 We will take reasonable steps to contain and remediate, and will give the Customer reasonable assistance with the Customer's own obligations under Articles 33 and 34 GDPR.

8.4 Our notification is not an admission of fault or liability.

8.5 The Customer must not make a public statement that identifies us in relation to a breach without first consulting us, unless it is legally required to and there is no time to consult.

9. Audit

9.1 On reasonable written request, and no more than once in any 12 month period unless a supervisory authority requires more or a Personal Data Breach has occurred, we will provide the Customer with:

  • our current security documentation, including the measures in Annex 2
  • the results of our most recent penetration test, in summary form
  • written responses to a reasonable security questionnaire

9.2 If that is not sufficient to demonstrate compliance, the Customer may, at its own cost, conduct or mandate an audit. The audit must be: on at least 30 days' notice; during business hours; subject to confidentiality; limited to systems and records relevant to the processing; and conducted so as not to disrupt our operations or the confidentiality of other customers' data. The Customer will not have physical access to any data centre, because we do not operate one; those are operated by our infrastructure sub-processors under their own certifications.

9.3 Where the SCCs apply, the audit rights in Clause 8.9 apply and this section describes how they are exercised in practice.

10. International transfers

10.1 The Customer authorises us to transfer Customer Personal Data internationally as necessary to provide the Service, including to the United States. The subprocessor list states the location of each sub-processor.

10.2 SCC module reference. Where we transfer Customer Personal Data from the EEA to a country without an adequacy decision, the SCCs apply and are incorporated into this DPA by reference, on the following basis:

  • Module Two (controller to processor) applies where the Customer is a

controller and we are its processor. This is the default module for this DPA.

  • Module Three (processor to processor) applies where the Customer is itself

a processor acting for a third-party controller and we are its sub-processor.

  • Modules One and Four do not apply, because we do not act as controller for

Customer Personal Data and the Customer does not act as our processor.

  • The Customer is the "data exporter" and we are the "data importer".
  • Clause 7 (docking clause) is included.
  • Clause 9: Option 2, general written authorisation, with the 30 day notice

period in section 6.3.

  • Clause 11(a): the optional independent dispute resolution body language

is not included.

  • Clause 17: Option 1, governed by the law of the EEA member state stated in

Annex 1. If none is stated, the law of Ireland.

  • Clause 18(b): the courts of that member state.
  • Annex I.A is completed by Annex 1 of this DPA. Annex I.B is completed

by Annex 1 of this DPA. Annex I.C (competent supervisory authority) is completed by Annex 1. Annex II is completed by Annex 2 of this DPA. Annex III (list of sub-processors) is completed by Annex 3.

10.3 UK transfers. The UK Addendum applies to transfers subject to the UK GDPR. Tables 1 to 3 are completed by the corresponding parts of this DPA and its Annexes. In Table 4, neither party may end the Addendum as set out in Section 19 of it.

10.4 Swiss transfers. For transfers subject to the Swiss FADP, references in the SCCs to the GDPR are read as references to the FADP, the competent authority is the Federal Data Protection and Information Commissioner, and "member state" is read so as not to deprive data subjects in Switzerland of the right to sue in their place of habitual residence.

10.5 Conflict. If the SCCs conflict with this DPA, the SCCs prevail for transfers they cover.

10.6 Transfer impact. We have carried out a transfer impact assessment and will make a summary available on request. We will tell the Customer if we become unable to comply with the SCCs.

11. Deletion and return

11.1 Raw Message Data is deleted according to the retention window the Customer sets, with a default of 30 days.

11.2 On termination of the Service, or on the Customer's written request, we delete Customer Personal Data from live systems within 30 days and from backups within a further 90 days as backups age out.

11.3 Before deletion the Customer may export its data using the Service's export function, or ask us for an export at [OWNER TO CONFIRM: legal mailbox, proposed legal@lupee.app] within 30 days of termination.

11.4 We may keep Customer Personal Data where law requires it, for as long as that law requires, and subject to the protections in this DPA.

12. CCPA terms

Where the CCPA applies, we act as a "service provider". We will not sell or share Customer Personal Data, will not retain, use or disclose it for any purpose other than performing the Service and the business purposes stated in this DPA and the Terms, will not use it outside our direct business relationship with the Customer, and will not combine it with personal information from another source except as the CCPA permits for a service provider. We certify that we understand and will comply with these restrictions.

13. Governing law and forum

Except where the SCCs specify otherwise, this DPA is governed by the law that governs the Terms of Service, and disputes are resolved as the Terms provide.

14. Liability

Each party's liability under this DPA is subject to the limitations and exclusions in the Terms of Service, except where Data Protection Law does not permit that. Nothing in this DPA limits a data subject's rights under the SCCs or under Data Protection Law.

15. Contact

Data protection contact: [OWNER TO CONFIRM: privacy contact mailbox, proposed privacy@lupee.app] Security contact: [OWNER TO CONFIRM: security mailbox, proposed security@lupee.app] Legal notices: [OWNER TO CONFIRM: legal mailbox, proposed legal@lupee.app] EU representative: [OWNER TO CONFIRM: EU Article 27 representative] UK representative: [OWNER TO CONFIRM: UK Article 27 representative]


Annex 1: Description of the processing

This Annex completes Annex I of the SCCs.

A. List of parties

Data exporter / controller

  • Name: the Customer, as identified in its Lupee account and billing record
  • Address: as in the Customer's billing record
  • Contact: the account owner's email address, or the privacy contact the

Customer has set in Settings

  • Activities relevant to the transfer: using Lupee to track commitments

extracted from the Customer's chat channels

  • Role: controller (Module Two), or processor (Module Three)
  • Signature and date: by accepting the Terms of Service, or by signing the

executed copy

Data importer / processor

  • Name: ILLUSNT LLC
  • Address: 1209 Mountain Road Pl NE, Ste R, Albuquerque, NM 87110, USA
  • Contact: [OWNER TO CONFIRM: privacy contact mailbox, proposed privacy@lupee.app]
  • Activities relevant to the transfer: providing the Lupee service, which

ingests messages from Connected Channels, transmits them to a model provider for extraction, stores extracted commitments, and sends reminders

  • Role: processor (Module Two), or sub-processor (Module Three)
  • Signature and date: by making the Service available, or by signing the

executed copy

B. Description of the transfer

Categories of data subjects

  • The Customer's users of Lupee, including administrators and team members
  • Any person who posts a message in a Connected Channel, whether or not they

use Lupee

  • Any person named or described in such a message
  • Any person named as the owner or the recipient of an extracted Commitment

Categories of personal data

  • Identity and contact: name, display name, email address, avatar, platform user

identifier, identity provider

  • Account and configuration: plan, entitlement, language, timezone, settings,

retention window, list of enabled channels

  • Message content: the full text of messages posted in Connected Channels while

they are enabled

  • Message metadata: sender identifier and display name, channel and thread

identifier, timestamps, a permalink where the platform provides one, reply and edit structure

  • Derived data: extracted commitments, the owner and recipient of each, due

date, confidence, state, source reference, and the Customer's confirmations, rejections, edits and completions

  • Device and delivery: device model, operating system, app version, push

notification token

  • Diagnostics: error and crash records, which may incidentally contain fragments

of the above

Sensitive data

Not requested and not required by the Service. Because the data set is free-text chat, sensitive data may nevertheless be present if the Customer's users write it, and in practice it will be: people mention illness, bereavement, religion, union activity and legal trouble in the same message as the thing they are apologising for being late with. No filter can catch that, and none is claimed.

The Customer decides which channels to enable and is responsible for that choice, and clause 3.5 prohibits enabling channels whose ordinary subject matter is Article 9 or Article 10 data.

Applied restrictions:

  • per-channel opt-in, with every channel off until the Customer switches it on;
  • the party filter, which keeps a message only where the Customer's linked team

is a party to it: they wrote it, it mentions one of them, it replies to one of them, it sits in a thread one of them has posted in, or it is a direct message involving one of them. The filter applies unconditionally to historical messages read when a channel is first enabled. On the live message stream it is a deployment setting, and where it is not enforcing, messages the Customer is not a party to are stored and are removed on the ordinary retention window. We state that plainly rather than describe the filter as universal;

  • automated redaction of credential-like and direct-identifier patterns before

transmission to the model provider and before the search index is built;

  • short default retention for raw text, enforced by a nightly sweep;
  • no ingestion of attachments, images, audio, video or file contents;
  • encryption in transit and at rest, restricted and logged engineer access.

Frequency of the transfer

Continuous, event-driven. Messages are transferred as they are posted in Connected Channels, and in batched extraction windows.

Nature of the processing

Collection, recording, organisation, structuring, storage, retrieval, consultation, use through automated analysis by a large language model, transmission to sub-processors, erasure and destruction.

Purpose of the processing

To identify commitments, requests, questions and deadlines in the Customer's chat channels; to present them for review; to remind the Customer and its users about them; to post replies into source threads where the Customer has enabled that; and to provide, secure, support and improve the Service.

Retention period

  • Raw message text: the window set by the Customer, default 30 days, subject to

the platform ceiling in clause 3.8 where that is shorter

  • Message metadata: sender identifier and display name, channel, thread,

timestamp, and a permalink where the platform provides one, survive the text purge and are kept for the life of the row. The purge nulls the text, not the record that a message existed

  • Message metadata linked to a live Commitment: for the life of that Commitment
  • Commitments: until deleted by the Customer, or 12 months after account

closure. A Commitment's title and detail are written in the words of the source message and therefore outlive it

  • Backups: held for at least 35 days and aged out within 90
  • Otherwise as set out in section 9 of the Privacy Policy

Transfers to sub-processors

See Annex 3. Subject matter, nature, and duration of each sub-processor's processing are stated there.

C. Competent supervisory authority

The supervisory authority of the EEA member state in which the Customer is established. Where the Customer is not established in the EEA but is subject to the GDPR under Article 3(2), the supervisory authority of the member state where the Customer's Article 27 representative is established.

To complete before publishing: state the default authority you will name where the Customer does not specify one.


Annex 2: Technical and organisational measures

This Annex completes Annex II of the SCCs. Everything in the table below is a contractual commitment. Before publishing, delete any line that is not true on the day of signature and move it to the "planned" table underneath.

A. Measures in place

AreaMeasure
Encryption in transitTLS 1.2 or higher for all connections between clients, our services, and every sub-processor. HSTS on web endpoints. No plaintext transport.
Encryption at restDatabase, object storage and backups encrypted at rest using the provider-managed encryption of our hosting sub-processors (AES-256 or equivalent).
Field-level protectionThird-party access tokens and refresh tokens are encrypted with an application-managed key before being written to the database, so a database compromise alone does not yield working platform credentials.
Pseudonymisation and minimisationOnly channels the Customer explicitly enables are ingested. Attachments, images and files are not ingested. Automated redaction of credential-like, card-like and direct-identifier patterns runs before any transmission to the model provider. Raw message text is deleted on a short default window.
Access control, usersAuthentication by email one-time code, Sign in with Apple, or Google. Short-lived access tokens (15 minutes) with rotating refresh tokens held in the platform secure store. Sessions can be revoked.
Access control, staffProduction access is limited to named engineers on a least-privilege basis, requires multi-factor authentication, and is reviewed at least quarterly. There is no shared administrator account.
Access loggingAdministrative and production database access is logged, and logs are retained for review.
Secret managementSecrets and API keys are held in the hosting platform's secret store and injected as environment variables at runtime. Secrets are never committed to source control. Automated secret scanning runs on the repository.
Network securityApplication services are not directly reachable except through the published API endpoints. Database and queue services are reachable only from the application network. A managed WAF and DDoS protection sit in front of public endpoints.
Tenant separationLogical separation by tenant identifier, enforced in the data access layer, with automated tests covering cross-tenant access.
BackupsAutomated encrypted backups with point-in-time recovery on the managed database. A backup object is held for at least 35 days and expires at 90. Restore procedure documented.
Availability and resilienceManaged, multi-instance hosting with automated restart and health checks. Queue-based ingestion so that a downstream outage delays rather than loses work.
Change managementAll code changes go through version control and review. Automated tests, type checking and dependency vulnerability scanning run in continuous integration before deployment.
Vulnerability managementAutomated dependency scanning with a defined patching window by severity. A published vulnerability reporting address with stated response targets, at https://lupee.app/security.
Incident responseA documented incident response procedure with defined roles, a severity scale, and a notification path to affected customers.
Logging hygieneApplication logs are configured to exclude message content and credentials. Crash reporting is configured to scrub known sensitive fields.
PersonnelEveryone with access is bound by written confidentiality obligations and receives data protection and security guidance on joining and annually.
Sub-processor governanceEach sub-processor is assessed before engagement, is bound by a data processing agreement with terms no less protective than this DPA, and is listed publicly.
DeletionDocumented deletion routines for whole-workspace and full-account deletion, on the timetable in section 11. Disabling a channel stops further ingestion and is not a deletion routine.
Physical securityWe operate no data centre. Physical security is provided by our infrastructure sub-processors, who maintain their own certifications.

B. Planned, not yet in place, not contractual

This table exists so the Customer can see the roadmap without us promising it. Nothing here is a commitment and none of it may be relied on.

AreaStatus
SOC 2 Type IINot held. Under consideration once headcount and revenue justify the audit cost.
ISO 27001Not held. Not currently planned.
Annual third-party penetration testNot yet performed. Planned before general availability of the Team plan.
Customer-managed encryption keysNot available.
EU data residency for all componentsStorage and compute regions are available from our hosting providers. Full EU residency including the model provider call is not available. See the Privacy Policy.
Formal 24/7 on-call rotationNot in place. Best-effort response outside business hours.

C. Measures for transfers

For transfers to sub-processors we rely on the measures in table A, in particular encryption in transit and at rest, minimisation of what is transmitted, contractual restrictions on onward transfer, and a transfer impact assessment for each recipient in a country without an adequacy decision. We will challenge any government access request that appears unlawful or overbroad, and will inform the Customer where we are legally able to.


Annex 3: Sub-processors

This Annex completes Annex III of the SCCs. The authoritative and current list is at https://lupee.app/subprocessors, and the full detail, including data categories per sub-processor, is in that document. The list below is correct as at 13 November 2026.

Sub-processorRoleProcessing location
Anthropic, PBCLarge language model API used to extract commitments from message textUnited States (verify)
Fly.io, Inc.Application and worker hostingCustomer-selectable region, default (verify)
Neon, Inc.Managed PostgreSQL databaseRegion as configured (verify)
Upstash, Inc.Managed Redis for the job queueRegion as configured (verify)
Cloudflare, Inc.DNS, CDN, WAF, DDoS protection, R2 object storageGlobal edge, R2 region as configured (verify)
Vercel Inc.Marketing site hostingGlobal edge, primary region (verify)
Stripe, Inc. and Stripe Payments Europe LtdPayment processing for web purchasesUnited States and Ireland (verify)
RevenueCat, Inc.Mobile subscription and entitlement infrastructureUnited States (verify)
Functional Software, Inc. dba SentryCrash and error reportingUnited States or EU, depending on the instance chosen (verify)
Grafana LabsMetrics, traces and logsRegion as configured (verify)
Apple Inc.Apple Push Notification service, Sign in with Apple, App Store purchasesUnited States
Google LLCFirebase Cloud Messaging, Google sign-in, Google Play purchasesUnited States
Expo (650 Industries, Inc.)Push notification delivery serviceUnited States (verify)
Email delivery providerTransactional email, including one-time sign-in codesTo be named before publishing

Changes to this list are notified as set out in section 6.3.