Data processing agreement

This data processing agreement ("DPA") is part of the tuix terms of service ("terms") between the customer ("you") and Maciej Wciślik Trąbka Świata, ul. Stryjeńskich 15a lok. 60, 02-791 Warszawa, Poland, registered in CEIDG (the Polish Central Register and Information on Economic Activity), REGON 140261166, VAT/NIP PL9590959380 ("tuix", "we", "us"). It applies whenever we process personal data for you as part of the service, and it is meant to meet Article 28 of the GDPR (Regulation (EU) 2016/679). You accept it when you accept the terms.

1. Definitions

Words such as controller, processor, personal data, processing, data subject and personal data breach have the meanings given in the GDPR. In addition:

• Customer personal data: personal data in customer data (as the terms define it) that we process for you.
• Subprocessor: another processor we engage to process customer personal data.

2. Roles

• You are the controller of customer personal data, and we are your processor.
• If you process the data for your own client, for example as an agency that runs an app for a client, you are a processor and we are your subprocessor. You confirm that your client has authorised you to use us on the terms of this DPA. You pass your client's instructions to us, and you pass on to your client the information this DPA gives you.
• We are a controller, not a processor, for the account, billing and security data that our privacy policy describes. This DPA does not cover that data.

3. What we process

Annex 1 describes the subject matter and duration of the processing, its nature and purpose, the types of personal data and the categories of data subjects.

4. Your instructions

• We process customer personal data only on your documented instructions, including for any transfer to a third country, unless EU or Member State law requires otherwise. In that case we tell you before processing, unless that law forbids it.
• Your instructions are the terms, this DPA, and what you and your team do in tuix: your project settings (capture, masking, network patterns, retention, environments and sign-in), the integrations and AI apps you connect, the people you invite and the deletions you make. Further instructions must be in writing and within the scope of the service. If they need work outside it, we agree any charge with you first.
• We tell you at once if we believe an instruction infringes the GDPR or other EU or Member State data protection law. We may then decline to follow it until you confirm or change it.

5. Your obligations

You are responsible for:

• the lawfulness of the processing, including a legal basis for what the widget captures in your app;
• informing data subjects. Annex 4 has suggested wording;
• setting up the service so it captures no more than you need: masking with data-tuix-mask, capture settings, network allow and deny lists, retention, and signed identity;
• not sending special categories of personal data (art. 9 GDPR) or data about criminal convictions (art. 10 GDPR) unless you have a legal basis and have taken suitable measures;
• the integrations you connect, such as Slack and AI apps. Data you send through them leaves our processing, and their providers are not our subprocessors.

6. Confidentiality

We give access to customer personal data only to people who need it to provide, support or secure the service, and who are bound to confidentiality by contract or by law. Our operator console shows workspace metadata only, never reports, screenshots, logs or the identities of app people, except reports you send us yourself with the tuix button on the tuix.app dashboard.

7. Security

We implement the technical and organisational measures in Annex 2, as Article 32 of the GDPR requires. We may change them over time, but never in a way that lowers the protection of customer personal data.

8. Subprocessors

• General authorisation. You authorise us to use the subprocessors listed in Annex 3 and at tuix.app/subprocessors.
• Changes. Before we add or replace a subprocessor, we update the list and email the workspace owners at least 30 days ahead. We say who the subprocessor is, where it processes data and what it does.
• Objections. You may object during that period, on reasonable data protection grounds, by writing to support@tuix.app. We will discuss it with you in good faith. If we cannot resolve it, you may end the agreement before the change takes effect, and we refund the unused part of your prepaid period.
• Same duties. We bind each subprocessor by contract to data protection obligations that protect customer personal data at least as well as this DPA, including sufficient guarantees of appropriate technical and organisational measures. We remain liable to you for our subprocessors' performance of those obligations.
• Not our subprocessors. Services you choose to connect, such as Slack, AI apps through our MCP server, and Shopify, are your integrations. GitHub, where we build our code, holds no customer personal data.

9. Where data is processed

We and our subprocessors process customer personal data in the European Economic Area. We will not transfer it outside the EEA without your prior written instruction and the safeguards that Chapter V of the GDPR requires. Integrations you connect may transfer data outside the EEA; that is your decision and responsibility.

Requests from authorities outside the EU. If a court or authority of a country outside the EU asks us for customer data, we do not hand over personal data unless an international agreement between that country and the EU or Poland, such as a mutual legal assistance treaty, requires it (art. 48 GDPR) and Chapter V of the GDPR allows the transfer. For other customer data, we follow art. 32 of the EU Data Act (Regulation (EU) 2023/2854). Before we hand over anything, we tell you, unless the request serves law enforcement purposes and telling you is forbidden for as long as needed to keep that purpose effective, and we give only the minimum the request allows.

10. Helping you with people's requests

Taking into account the nature of the processing, we help you answer requests from people exercising their rights under Chapter III of the GDPR. Mostly, you do this with tools in the service:

• Access and portability. Your team sees reports, comments, screenshots and logs in the dashboard. Reports can also be read through our read-only API and the MCP server.
• Erasure. A project admin can delete a person from your app in Project settings. The person's widget access ends at once. About 11 minutes later we delete their reports, screenshots, logs, comments, notifications and other activity. Where other people's comments mention them, the mention becomes "@Deleted user". Reports by other people stay.
• Rectification. Your app updates a person's name and email address each time it identifies them to the widget.
• Retention. Screenshots and logs are deleted automatically after each project's retention period.

If a person contacts us directly about customer personal data, we pass the request to you without undue delay. We do not answer it ourselves unless you ask us to.

If you need help beyond the tools, for example to restrict processing of one person's data or to get a copy in a particular format, we provide reasonable help. It is free unless requests are manifestly unfounded or excessive.

11. Helping with security, breaches and assessments

Taking into account the nature of the processing and the information available to us, we help you meet your obligations under Articles 32 to 36 of the GDPR: security, breach notification, data protection impact assessments and prior consultation with a supervisory authority. For an assessment, we give you this DPA, our documentation and answers to reasonable questions.

12. Personal data breaches

• We notify you without undue delay, and in any case within 48 hours, after becoming aware of a personal data breach affecting customer personal data.
• We send the notice by email to the workspace owners. It includes what we know at the time: the nature of the breach, the categories and approximate number of people and records concerned, the likely consequences, the measures taken or proposed, and a contact for more information. We send more information as we learn it.
• We take reasonable steps to contain the breach and reduce its effects, and we keep a record of it.
• You decide whether to notify the supervisory authority and the people affected. We do not notify them for you unless you ask us to or the law requires it.
• Notifying you is not an admission of fault.

13. Retention, deletion and return

During the agreement:

• Screenshots and console and network logs are deleted automatically after each project's retention period. A project admin sets it, up to the plan's maximum: 14 days on Free (developer), 180 days on Solo, 365 days on Team and 730 days on Agency. New projects start at 180 days, or less if the plan allows less.
• Uploads never attached to a report are deleted after 24 hours.
• Report text, comments, statuses and the identities your app sent stay until you delete the person concerned, or until the agreement ends.
• When a workspace lapses because a trial or paid period ended unpaid, nothing is deleted while it is lapsed. If it stays lapsed for 90 days, we may end the agreement, after emailing the owners at least 30 days before it ends (section 9 of the terms). Customer personal data is then deleted as described under "At the end of the agreement" below.

At the end of the agreement:

• For 30 days, an owner can ask us for a copy of the customer personal data in a machine-readable format (JSON, with the screenshot files). If you ask us to delete sooner, we do.
• Within 30 days after the end, we delete customer personal data from our live systems: the database and file storage.
• Copies in our database backups are overwritten within a further 15 days. Traces and logs expire 30 days after they were written.
• If we ever restore a backup, we delete again the data that had been deleted after the backup was taken.
• We keep customer personal data longer only where EU or Member State law requires it.
• On request, we confirm the deletion in writing.
• If you switch to another provider under section 19 of the terms (the EU Data Act), the periods there apply instead: we delete after the transition and retrieval periods end.

14. Information and audits

• We make available the information needed to show that we meet Article 28 of the GDPR: this DPA, Annex 2, the subprocessor list, and written answers to reasonable security questionnaires, up to once a year.
• If that is not enough, or a supervisory authority requires it, you may audit us yourself or through an independent auditor who is bound to confidentiality and is not our competitor. Give us 30 days' notice. Audits take place during business hours, at most once every 12 months unless they follow a personal data breach or a supervisory authority asks for them, and they do not give access to other customers' data. Each party bears its own costs.
• We tell you if a supervisory authority contacts us about customer personal data, unless the law forbids it.
• We keep a record of the processing we carry out for our customers, as Article 30(2) of the GDPR requires, and make it available to the supervisory authority on request.

15. Liability

Liability under this DPA is subject to the limits in the terms (section 17). These limits do not affect either party's liability to data subjects under Article 82 of the GDPR.

16. Term and precedence

This DPA applies for as long as we process customer personal data for you, including after the agreement ends and until the data is deleted. If it conflicts with the terms, this DPA prevails on personal data. It is governed by the same law, and disputes go to the same court, as under the terms (section 21).

Annex 1: Details of the processing

Subject matter. Providing tuix, a feedback tool: people using your app report problems at the element where they happen, and your team triages, discusses, fixes and verifies them.

Duration. For the term of the agreement, and after it until deletion under section 13.

Nature of the processing. Collection through the widget; storage; organisation; display in the dashboard, and in the widget to people with access; sending in emails to the people involved and to integrations you connect; deletion by the retention and erasure tools.

Purpose. To let your app people report and discuss problems with their context, to let your team triage, fix and verify them, and to provide the other features you turn on.

Categories of data subjects:

• App people: users of your app whom your app identifies to the widget, for example your staff, your clients' staff, testers or end users.
• Your team members and invited people, as they appear in reports, comments, mentions, assignments and history.
• Anyone whose personal data appears in a capture: on a captured screen, in console or network entries, or in report text, for example your app's own customers.

Types of personal data:

• Identity sent by your app: the user ID in your app, name, email address (optional; marked as verified when your app signs it), avatar URL and any traits your app sends; when the person was first and last seen.
• Reports and discussion: report text, type and severity, comments and mentions, statuses, assignments, and fix and verification history.
• Page and element: page URL, route, page title, and the reported element's position, text and accessible name, with the locators used to find it again.
• Screenshot: an image of the page when the report was made. Elements your app marks with data-tuix-mask are replaced by a grey box. The person sees the screenshot and can remove it before sending.
• Console entries, if enabled: up to 50 recent errors and warnings, each cut at 500 characters.
• Network entries, if enabled: only requests that failed (status 400 or above, or no response): method, URL without query string or credentials, status and duration. Request and response bodies and headers are never read.
• Browser details: viewport, pixel ratio, user agent and client hints, language, time zone, online status, your app's release label, and any custom context your app passes (up to 4 KB).
• Technical data: IP addresses, used for rate limits and stored only as a short-lived digest; widget sessions; and widget measurements (load time, error categories, and how pins found their elements).
• Emails sent for you: reply, mention and status notifications to app people and team members.

Special categories. Not intended. You keep them out of reports (section 5).

Retention. As section 13 describes.

Location. The EEA: Frankfurt, Germany for servers, database and file storage; Amsterdam, the Netherlands, with backups in Germany, for email.

Annex 2: Technical and organisational measures

Separation between customers

• Each workspace is a separate tenant. Every read and write is checked against the workspace and project, and widget access also against the app's origin and environment. Database foreign keys tie records to their workspace and project.
• Automated tests try cross-workspace access, forged widget sessions and claims on other customers' files, and require them to fail.
• Team members reach a project only through a membership in it. Console and network logs are visible only to the report's author and to project admins.

Sign-in and access

• Team members sign in with single-use email links that expire after 15 minutes. Sign-in links, session tokens, API tokens and AI-app tokens are stored only as hashes.
• Sign-in requests are rate limited per address and per network address, and the answer is the same whether or not an address has an account.
• The session cookie is encrypted, inaccessible to page scripts, sent only over HTTPS, and marked SameSite=Lax. Confirmation pages cannot be framed or cached and send no referrer.
• Your app's server signs widget identities with a project key that never reaches the browser, and signatures are required by default. The widget API accepts requests only from the origins you list. Widget sessions last at most 12 hours.
• AI-app access is read-only unless a project admin allows changes, and screenshot and diagnostic access can be switched off per connection. Reporter email addresses are never returned, and email addresses in page titles, element text and app context are removed. Every read and change through AI access is logged.
• Slack messages carry no screenshots, logs, report bodies or reporter identities.

Our own staff

• Operators have separate accounts, sign in with an emailed link and a code from an authenticator app, and their sessions last 12 hours.
• The operator console shows workspace metadata only.
• When you send us a report from the tuix dashboard, it may contain personal data shown on that page, including data of your app's people. We use it only to answer that report, on your instruction; it is visible to the tuix team and to the people of your workspace who use the tuix button, kept for 30 days for screenshots and logs, and deleted with your workspace.
• Every change an operator makes is written to an audit log in the same transaction as the change.
• Access to production systems is limited to tuix's owner, Maciej Wciślik. Anyone else is bound to confidentiality before getting access.

Files

• Screenshots and attachments are kept in private storage under random keys scoped to the project.
• Read links are signed and valid for 5 minutes; upload links for 10 minutes.

Encryption

• All traffic to tuix uses HTTPS. Plain HTTP is redirected, and browsers are told to use HTTPS only (HSTS).
• The application connects to the database over TLS and checks the server's certificate and hostname.
• Stored Slack webhooks, Shopify access tokens and pending invitations are encrypted with the application's secret key.
• The database, the server's disk and file storage are encrypted at rest with AES-256 by our hosting provider, with keys the provider manages.

Less data from the widget

• The widget runs in a closed Shadow DOM. It never reads your app's cookies or browser storage, or request and response bodies. Screenshots show what is on the screen unless you mask it.
• Capture of screenshots, console and network entries can each be turned off per project. Masking and network allow and deny lists limit what is captured.
• Before sending, the person sees the screenshot (and can remove it) and how many console and network entries will be attached.
• Text people write is shown as text, never as HTML, in the widget and the dashboard.

Deletion

• A retention job runs every hour. It deletes each file before its database record and retries failures, so nothing is left behind.
• Erasure of a person runs as a background job that retries after failures and resumes where it stopped. The person stays locked out until it finishes.

Servers and operations

• Servers, database and file storage are in Frankfurt, Germany.
• The application runs as an unprivileged user behind a TLS proxy. The firewall admits only SSH and web traffic. Configuration files with secrets are readable only by the administrator account. Operating system security updates install automatically.
• The database runs on a private network with public access turned off.
• We deploy only builds made by our CI from a successful run on a known commit. A deploy that fails its health check rolls back automatically.
• Widget files are versioned and never changed once published, and pinned installs can check them with integrity (SRI) hashes.

Monitoring

• Traces and logs go to our own server in the EU. Secrets are removed before anything is stored; database query values and visitors' IP addresses are not recorded. They are kept for 30 days, and the credential that sends them cannot read them.

Backups and recovery

• The managed database keeps point-in-time backups for 15 days.

Annex 3: Subprocessors

The current list is at tuix.app/subprocessors and forms part of this DPA. On the effective date it is:

Annex 4: Suggested wording for your privacy notice

This annex is not part of the agreement. Adapt it to your app, your legal basis and your settings.

Feedback tool. We use tuix, a feedback tool provided by Maciej Wciślik Trąbka Świata (Poland), to collect reports about problems in [your app]. When you send a report, tuix records what you write, a screenshot of the page you are on (some fields are hidden), the element you pointed at, recent error messages from your browser's console, the addresses of requests that failed (never their content), and technical details such as your browser, screen size, language and time zone. It also receives your name [and email address] from [your app], so we know who reported and can tell you about replies.

Other signed-in users of [your app] in the same environment can see reports and their screenshots. Console and network details are visible only to you and our administrators. tuix processes this data for us, in the EU, under a data processing agreement. We keep screenshots and technical details for [number] days, and report text until [your rule]. The widget keeps your preferences in your browser's storage.

We do this based on our legitimate interest in finding and fixing problems in [your app] (Article 6(1)(f) GDPR) [or your legal basis].