Legal
Data processing addendum
Last updated: 8 August 2026
1. What this document is
This addendum is part of the agreement between M Digital Labs, trading as echoUX (“we”, “us”, the processor) and the customer named in that agreement (“you”, the controller). It is a contract term under Article 28 of the UK GDPR.
It applies whenever we process personal data on your behalf. It does not apply to your own account details, such as the email address you sign in with. For those we are the controller, and our privacy notice covers them.
Where this addendum and the terms of service disagree about the processing of personal data, this addendum wins. This addendum is governed by the law of England and Wales, the same as the terms.
2. Roles
You are the controller. You decide what feedback to send us and why.
We are your processor. We process that feedback only to run echoUX for you, and only on your instructions.
The people whose personal data is involved are usually your customers, not you and not us. We have no relationship with them and no way to identify them independently. That is the reason for section 8.
3. Your instructions
Your instructions to us are: process the feedback you send through the echoUX pipeline as configured in your account, produce discovery artefacts from it, store it for the retention period in section 6, and deliver artefacts to the destinations you have connected.
We will not process it for anything else. If we think an instruction of yours breaks data protection law, we will tell you and may pause that processing until it is sorted out.
We do not use your content to train any model. We have no model of our own. On every call to our model provider we send a routing restriction that excludes providers that store or train on prompts. This is on by default, is applied on every request, and we have verified live that every model we use routes successfully under it. It is a routing restriction our provider enforces. It is not a separate contract with each model provider.
4. What we do and do not do to the content
We store what you send, exactly as you sent it. There is no redaction, masking, anonymisation or pseudonymisation anywhere in echoUX. If a feedback item contains a person’s name, email address, phone number or account number, we store that text and include it in prompts to our model provider.
That has two consequences you should plan around:
Deciding what not to send us is your control, not ours.
Quotes taken from that text are embedded in the artefacts echoUX produces, and travel with those artefacts to the destinations you connect.
5. Confidentiality
Access to your data is limited to people who need it to run or support the service. Today that is one person, the founder. Anyone we bring in will be under a confidentiality obligation before they get access.
We do not have a customer facing audit log of internal access. We are not going to claim we can show you a record of every time your data was read, because we cannot.
6. Retention and deletion
These are the numbers implemented in the code, not intentions.
Rolling deletion of raw feedback. A job runs once a day and deletes feedback items, rejected items and pipeline checkpoints older than the retention window. It also deletes queued items that were never processed once they pass the same window, so nothing sits in a queue indefinitely.
The window defaults to 180 days. It is a per tenant setting, so we can agree a shorter one for your account, for example 30 days. If we agree one, it is recorded in your account configuration and takes effect on the next daily sweep.
Artefacts are not deleted by that sweep. Artefacts hold the quotes that ground each finding as text rather than as a reference back to the feedback item. That is deliberate, so a finding stays evidenced after the raw pool ages out. It means deleting raw feedback does not remove quotes already embedded in artefacts. If you need those gone, artefacts must be deleted, or the account closed.
Other records: sessions are deleted 90 days after expiry, one time sign in links 30 days after expiry, email records after 180 days, the error log after 180 days, delivery payloads after 7 days with failed rows after 30 days, and delivery failure records after 180 days.
On termination. You can request a data export from the app at any time, including before you cancel. Deletion is scheduled for 30 days after your subscription ends. On that date a job deletes your rows across the database, deletes the derived files we hold on disk for you, and revokes the connector connections we hold. Your tenant record is marked as deleted rather than removed, so that we keep the fact that the account existed and was purged.
Backups. We do not run an automated backup system for customer content. Beyond what our hosting provider keeps for infrastructure recovery, we take occasional manual database snapshots around maintenance work; snapshots are kept for up to 90 days and then deleted. A deletion is therefore complete in the live system on the scheduled date, and complete in every copy we hold once the last snapshot from before the deletion has expired.
7. Security
Annex II lists the measures we actually have and the ones we do not. Please read it before you sign. It is written to be useful in a security review rather than reassuring.
8. Helping you with data subject rights
If one of your customers exercises a right, you are the one who has to answer. We will help.
What we can do:
Give you a full export of your data, including raw feedback within the retention window and every artefact, in a machine readable form.
Delete specific feedback items or artefacts you identify, on your written request.
Delete your entire account and everything in it.
Answer questions about what we hold and where it went.
What we cannot do today, stated plainly:
There is no per person erasure path in echoUX. A data subject cannot invoke erasure through the product, and we have no automated way to find every record relating to one individual across raw feedback, artefacts and quotes. Deletion is by account, or by specific items you point us at.
If you need to satisfy an erasure request, tell us which feedback items and artefacts are involved and we will delete them by hand. If you cannot identify them, the only complete answer available today is deleting the account.
If your compliance position requires per subject erasure on demand, echoUX does not meet it yet. We would rather you knew before signing.
9. Personal data breaches
If we become aware of a personal data breach affecting your data, we will tell you without undue delay, and in any event within 48 hours of becoming aware.
We will tell you what happened, what data was involved as far as we can establish it, what we have done, and what we suggest you do. We will help you meet your own notification duties.
Be aware, when judging how much detail you will get: we do not have a customer facing data access audit log, and we have no third party intrusion detection. Our ability to reconstruct exactly what was accessed is limited to application and infrastructure logs.
We will not tell a regulator or a data subject about a breach on your behalf unless you ask us to or the law requires it of us directly.
10. Assisting with impact assessments
If you carry out a data protection impact assessment or a prior consultation that involves echoUX, we will give you the information we have. In practice that means this addendum, the privacy notice, the sub-processor list, and honest answers to questions. We do not have a completed standard security questionnaire, a SOC 2 report or an ISO certificate to send you.
11. Sub-processors
You give us general authorisation to use the sub-processors listed in Annex III.
If we add or replace one, we will give you at least 30 days notice by email before it starts processing your data. If you reasonably object on data protection grounds within that period, we will discuss it with you, and if we cannot resolve it you may terminate the affected part of the service and receive a refund of fees paid for the unused period.
Each sub-processor is engaged under its standard data processing terms, which incorporate the transfer mechanisms in section 12, and each is bound by terms no less protective than these so far as their own standard agreements allow.
Services you connect are not our sub-processors. When you connect Slack, Notion, Linear or your own webhook as a destination, echoUX sends artefacts, including the quotes that ground them, into a system you control and have your own relationship with. We do that on your instruction. Those services are your processors, not ours. Who can read that channel, page or issue is your decision.
12. International transfers
Some of your data leaves the United Kingdom. We are stating that clearly rather than burying it.
Our application and database are in the United Kingdom (London). Your data at rest stays there.
Our model provider, OpenRouter, routes each call on to a model provider, primarily in the United States. We do not control which country serves the call. We send a routing restriction that excludes providers who store or train on prompts. We do not send, and cannot send, a geographic constraint.
Email, payments and web traffic are handled by providers operating internationally, listed in Annex III.
We do not offer UK only or EU only processing, and we are not promising a future region change.
Transfers rely on each sub-processor’s standard data processing terms, which incorporate the UK International Data Transfer Addendum or equivalent safeguards where they apply: Stripe, DigitalOcean and Cloudflare each incorporate transfer clauses in their standard data processing agreements, and MailerSend processes in the European Union with UK transfers covered under the Data Privacy Framework. If your organisation requires a documented transfer mechanism for every recipient, ask us before you sign and we will show you exactly where each one stands.
13. Audits
We will answer reasonable written questions about our processing, and give you the documents we have, once in any twelve month period unless a breach or a regulator makes more necessary.
We do not offer on-site audits or unrestricted access to our systems. echoUX is run by one person and an on-site audit is not something we can honestly promise to support.
14. Liability
Liability under this addendum is subject to the limits in the terms of service, except where the law does not allow that.
Annex I: details of the processing
Subject matter. Reading customer feedback that the controller supplies, and producing evidence grounded discovery artefacts from it.
Duration. For as long as the account is open, plus the retention and grace periods in section 6.
Nature and purpose. Ingestion, filtering, automated analysis by large language models, storage, and delivery of the resulting artefacts to destinations the controller connects.
Types of personal data. Whatever the controller sends. In practice this is free text written by the controller’s customers, which may contain names, contact details, account or order references, location, opinions, and any other personal detail the writer chose to include. Source metadata such as a channel name, an author handle or a timestamp may also be present. No filtering, redaction or category restriction is applied by the processor.
Special category data. Not expected and not agreed. The controller must not send special category data or children’s data without prior written agreement. echoUX has no controls that detect or block it.
Categories of data subject. The controller’s customers and users, and any other person mentioned in the feedback the controller sends.
Frequency. Continuous, driven by the controller’s connected sources and uploads.
Annex II: technical and organisational measures
Written to be checked, not to reassure. Each item was verified in the code on 2026-08-04 and re-checked on 2026-08-08.
Access control
Sign in is by one time link emailed to the user. No passwords are stored. Links are stored as a hash, expire, and are single use.
Sessions are stored as a hash of the session token and can be revoked immediately. The session cookie is HTTP only and marked secure in production.
Data ingestion authenticates by hashed API tokens the customer can revoke in the product; no plaintext ingestion credential exists.
Data export archives never include connector credentials, and webhook tokens are removed from the configuration dump.
No multi factor authentication.
No customer facing log of internal data access.
Separation of customers
Every record carries a tenant identifier and a topic identifier, scoped in the application layer and enforced by database constraints and consistency triggers.
Separation is enforced in application code and schema constraints, not by database level row security.
Data in transit and at rest
Traffic between the browser and echoUX uses HTTPS, terminated in front of the application.
There is no application level encryption of stored feedback content. Protection at rest is whatever our hosting provider applies to its storage.
Deletion
A daily job deletes raw feedback past the retention window, including unprocessed queue rows.
A daily job purges cancelled accounts 30 days after the subscription ends, covering database rows, on disk derived files and connector connections.
Resilience and monitoring
Application error logging, retained 180 days.
Delivery attempts to destinations are logged, with payloads removed after 7 days.
External uptime monitoring on the public health endpoint.
No third party error tracking, no intrusion detection, no security monitoring service.
No analytics or telemetry of any kind in the application.
Assurance
No SOC 2, no ISO 27001, no independent penetration test, no bug bounty.
No formal, documented incident response plan.
Staff
One person, the founder, has production access.
Annex III: sub-processors
Sub-processor
What it does
What it receives
Location
Agreement in place
DigitalOcean
Application server, database, and (when enabled) object storage for data export archives
Everything held by the service: account data, raw feedback, artefacts
United Kingdom (London). Export archive storage is not yet in use; when enabled it will be a UK or EU region
DigitalOcean’s data processing agreement, part of its standard terms
OpenRouter
Routes prompts to large language models
The full text of your feedback, inside prompts, and the artefacts written from it
Routed on to model providers, primarily in the United States; the onward location is not under our control. A routing restriction excludes providers that store or train on prompts
OpenRouter’s standard terms and data policies
MailerSend
Sends service emails
Recipient email addresses and the content of those emails
European Union (Belgium); UK transfers under the Data Privacy Framework
MailerSend’s data processing addendum, part of its standard terms
Stripe
Payments and subscription management
Your billing contact and payment details, which you give to Stripe directly
United States and globally, per Stripe’s terms
Stripe’s data processing agreement, part of its standard services agreement
Cloudflare
Web traffic in front of the site
Web request data
Cloudflare’s global network
Cloudflare’s data processing addendum, part of its standard terms
Nango, the layer that holds the OAuth tokens for your connected tools, is self hosted on our own infrastructure: no Nango operated service receives your tokens, so it is a component of echoUX rather than a sub-processor.
Deliberately not listed, because they do not exist in the product: no analytics provider, no error tracking provider, no vector database, no embedding service, no data enrichment service.