Data Processing Agreement

You are the controller of the personal data recorded on your websites and apps and of the data about your team. We are your processor. If you are yourself a processor acting for someone else, we are your sub-processor, and you are responsible for passing on your controller’s instructions and for having the authority to agree to this DPA.

Your instructions are this DPA, the Terms, and the settings you choose in the product — masking, consent mode, retention, what you send with identify and custom events, who you invite. We will tell you if we believe an instruction breaks data protection law.

We process personal data to provide AnyReplay: recording sessions on the sites where you install our recorder, storing them, replaying and translating them for your team, and running your account. This DPA lasts as long as we process personal data for you, and its deletion clauses outlive the Terms until that data is gone.

Collection, storage, organisation, retrieval, display, translation and deletion of session recordings and related account data, and, on paid plans, summaries and analyses of those recordings written by Argus, our AI assistant, for the sole purpose of letting your team understand how people use your product. We do not sell your data, use it to train models, or combine it with other customers’ data.

Data subjects:

• Visitors and end users of the websites and apps where you install the recorder.
• Members of your team who use the dashboard.

Personal data:

• Interaction events: clicks, scrolling, mouse movement, focus and typing.
• The values visitors type into forms — on a website and in a mobile app alike — and the values already in those forms: a name, an email address, a phone number, a postal address, a message, an order reference, unless you switch masking on. Passwords, payment card fields, one-time codes and values shaped like a card number are masked in every configuration and are never recorded; see section 5.
• Page addresses visited, and the page or screen structure and text as rendered, with masked content replaced before it leaves the browser or the phone.
• Device and browser information: browser, operating system, device type, screen size and browser language, derived in the recording endpoint. The raw user-agent string is not stored.
• A random visitor identifier generated in the browser.
• Approximate location: country, city, region and time zone, as our network provider resolves them from the address of a session’s first request. Recorded once, at the start of the session, and never updated. No postcode and no coordinates.
• Identifiers you choose to send with identify() — for example your own user id or an email address — and the properties you attach to custom events.
• For your team: name, email address, language, role, sign-in records, and audit-log entries of actions taken in the dashboard (which include the IP address and browser of sign-in events).

IP addresses of visitors are not stored. The recording endpoint uses the address a request came from only in memory, to apply rate limits, and does not write it to the database or the recording. Our content-delivery network (Cloudflare) necessarily sees it in transit and resolves it to an approximate place; what reaches us, and what we store on the session, is that result — country, city, region and time zone — and never the address itself. See the sub-processor list.

You must not use AnyReplay to collect special categories of personal data (health, religion, sexual orientation, biometric data and the like) or criminal-offence data.

Configuring masking is your obligation, not ours, because what the recorder records depends on how you configure it. Form field values are masked by default. If you turn that off with maskAllInputs: false, or if any page or screen where you install the recorder has other text that could carry special-category data, or any other data you are not entitled to store in a recording, you must mask it before you install: maskAllTyping: true for rich-text editors as well as fields, or the ar-mask class for individual elements. Elements marked ar-block are not recorded at all. The same options exist in our React Native SDK, where the marker is a testID containing ar-mask instead of a class. This applies to ordinary contact details as much as to anything else: with maskAllInputs: false, an email address or a telephone number typed into a form is recorded unless you mask it.

Payment card data is the one category we enforce for you: a password, a one-time code, a card number, a security code, an expiry date, a cardholder name, an IBAN or a routing number is masked on the visitor’s device in every configuration, as is any value shaped like a card number, and no setting records them. That is a floor, not a guarantee that your checkout is out of scope: a card number your own code renders as page text, or one typed into a rich-text field, is ordinary page text and it is for you to mask it. In a mobile app the floor can only read what the app tells the operating system — a secure field, or one whose content type, autofill hint, keyboard type, accessibility label, placeholder or test identifier names a credential or a payment instrument — so a text field carrying no such hint is recorded, and labelling it is your responsibility. Sending such data through identify() or custom-event properties, which are stored as you send them, is likewise your decision and your responsibility.

• Process personal data only on your documented instructions, unless the law requires otherwise — in which case we will tell you first unless the law forbids it.
• Keep it confidential, and make sure everyone authorised to process it is bound by confidentiality.
• Apply the security measures in Annex II.
• Use sub-processors only as described in section 8.
• Help you meet your obligations to data subjects, on security, breach notification, impact assessments and prior consultation, taking into account what we can reasonably know.
• Delete or return the data at the end of the service, as in section 11.
• Make available the information needed to show we comply, and allow audits, as in section 12.

Only people who need access to operate the service or to help you when you ask can reach customer data, and each of them is under a written or statutory duty of confidentiality. We access an organisation’s recordings only to operate the service, to investigate a problem you report, or where the law requires it.

You give us general written authorisation to use the sub-processors listed on our sub-processor page (Annex III). Each is bound by a written contract with data-protection obligations no weaker than this DPA’s, and we remain responsible to you for their performance.

We will announce any new sub-processor at least 30 days before it starts processing your data, on that page and its RSS feed and by email to your organisation’s owners. You may object on reasonable data-protection grounds within that period by writing to [email protected]. We will try in good faith to resolve the objection; if we cannot, you may terminate the affected service and we will refund any prepaid fees for the unused period.

Requests from your visitors or users go to you, as controller. If one reaches us, we will pass it to you without responding ourselves, unless you ask us to. The dashboard lets you act on requests directly:

• Delete a single session, which removes the recording at once; section 11 says what then happens to the copy in storage.
• Erasure requests by user id, email or visitor id, which find and delete every matching recording across your projects.
• Delete a team member’s account, and close the whole organisation.

Where these are not enough, we will help you on request.

We will notify you without undue delay, and in any case within 48 hours, after becoming aware of a personal-data breach affecting your data. We will send it to your organisation’s owners and include what we know about the nature of the breach, the data and people affected, the likely consequences, and what we are doing about it — adding detail as we learn it. Notifying you is not an admission of fault.

During the service, recordings are deleted automatically when they pass the retention period set for your organisation, and at once when you delete them or when an erasure request matches them.

At the end of the service an owner closes the organisation from the dashboard. Closure takes effect after a 30-day grace period, during which it can be cancelled and you can export what you need; after that we delete the organisation’s recordings, projects, memberships and account data.

Copies do not disappear everywhere at the same instant. Whenever we delete a recording, a copy still held on our own server goes with it, while a copy in object storage is hidden by the storage provider immediately and its bytes removed seven days later: “deleted” therefore means gone within 7 days rather than in the same instant. The window is deliberate — it is what would let a deletion nobody intended, whether a bug of ours or a stolen key, be undone while it still can be — and nothing is read back from it in the ordinary running of the service. Backups are encrypted on our own server before they leave it and age out within 30 days; while recordings are stored on our server rather than in object storage they are included in them, so a deleted recording can survive in an encrypted backup for that long. Nobody restores from a backup except to recover the service after a failure.

One record outlives the organisation deliberately: the billing events behind its payments, which we keep for accounting with the organisation’s identifier removed from them. They hold what the payment provider sent us about a charge, which can include the buyer’s name and email address.

We will answer reasonable written questions about our processing and send you the information you need to show compliance, including this DPA’s annexes and our security overview. If that is not enough, you (or an independent auditor bound by confidentiality) may audit our compliance once a year, with at least 30 days’ notice, during business hours, at your cost, and in a way that does not expose other customers’ data. More often is possible after a breach or when a supervisory authority requires it.

Our servers are in Germany. Some sub-processors are based, or may process data, outside the European Economic Area; the sub-processor page says where each one is and what safeguard applies. Where personal data is transferred outside the EEA to a country without an adequacy decision, the EU Standard Contractual Clauses (Commission Decision (EU) 2021/914) apply and are incorporated into this DPA by reference: Module Two (controller to processor) where you are a controller, and Module Three (processor to processor) where you are a processor. For those clauses, the annexes of this DPA are their annexes, option 2 of clause 9 (general authorisation) applies with the notice period in section 8, clause 13 supervision follows your establishment, and clauses 17 and 18 name the law and courts of Germany.

For transfers subject to UK data-protection law, the International Data Transfer Addendum issued by the UK Information Commissioner applies alongside those clauses, with the information in this DPA completing its tables. For Switzerland, references to the GDPR include the Swiss Federal Act on Data Protection.

Each party’s liability under this DPA is subject to the limitations in the Terms of Service, except where the law does not allow it to be limited.

If documents conflict: the Standard Contractual Clauses (where they apply) prevail over this DPA, and this DPA prevails over the Terms and anything else you and we have agreed about personal data.

• Data exporter: the customer, as identified at acceptance (company name and address recorded in the dashboard). Role: controller, or processor on behalf of its own customer.
• Data importer: AnyReplay, contact [email protected]. Role: processor or sub-processor.
• Data subjects, categories of data and special categories: section 4 and section 5. The categories include the contents of form fields — on websites and in mobile apps, and including email addresses and telephone numbers typed into ordinary fields — to the extent the customer has not configured masking, and never include passwords, one-time codes or payment card data.
• Frequency: continuous, while the recorder is installed and the account is open.
• Nature and purpose: section 3.
• Retention: the retention period set for the organisation — 14 days for a new one, and at most what its plan allows (14 days on the free plan, 365 on the largest); account data for as long as the account exists; then as in section 11.
• Sub-processor transfers: as listed in Annex III, for the purposes stated there.
• Competent supervisory authority: the one competent for the data exporter.

• Encryption in transit: every connection to AnyReplay uses TLS — between browsers and Cloudflare, and between Cloudflare and our servers with a Cloudflare origin certificate.
• Encryption at rest: recordings in object storage are encrypted by the storage provider (SSE-B2), and database backups are encrypted with AES-256 on our server before they are uploaded. Data on the server’s own disks — the database, and recordings not yet moved to object storage — is not disk-encrypted; it is protected by the data centre’s physical security and by access controls.
• Data minimisation: masking happens in the visitor’s browser, or on their phone, before anything is sent — a masked value is replaced with asterisks of the same length and the original characters never leave the device. Passwords, payment card fields, one-time codes and values shaped like a card number are masked in every configuration; other form values are masked by default, and the customer can choose to record them or to mask further elements, a choice we enforce on the device. Visitor IP addresses are not stored, only the approximate country and city our network provider resolves them to, and not the postcode it also offers; error reports sent to our monitoring provider have bodies, cookies, IP addresses and user details removed.
• AI processing: translation and Argus send session content to the language-model sub-processor listed in Annex III only when a reviewer asks for a translation or when Argus summarises or analyses a recording. What is sent never includes typed values, and Argus removes email addresses and long digit runs from the text it sends. An owner or admin can turn both off for the organisation, and from that moment nothing more is sent.
• Sandboxed replay: recordings replay in an iframe sandboxed without script execution, and recorded scripts are rebuilt as inert elements, so a recording cannot run code in the dashboard.
• Access control: every organisation is isolated from every other; within one, role-based permissions (owner, admin, moderator, member, viewer) decide who can view, delete, export or erase.
• Authentication: passwords hashed with Argon2id, account lockout and rate limits on sign-in, optional two-step verification by emailed code, and Google sign-in.
• Audit logs: sign-ins, membership and role changes, deletions and other sensitive actions are recorded per organisation and visible to owners and admins; actions by AnyReplay staff are recorded separately.
• Backups: nightly off-site backups, encrypted with AES-256 on our own server before they are uploaded and kept for 30 days, with a weekly automatic restore test; while recordings are stored on our server rather than in object storage they are included in them. A deleted recording is hidden in object storage at once and its bytes removed 7 days later, a window kept so that a deletion nobody intended can be undone.
• Retention: automatic deletion of recordings past each organisation’s retention period.
• Monitoring: error reporting, host health checks and external uptime checks, with alerts to the operator.
• Development: every change is built, type-checked and tested automatically before it can be deployed.

The current list, with each provider’s purpose, location and transfer safeguard, and a dated log of changes, is at anyreplay.com/legal/subprocessors.

Acceptance is recorded per version. When a new version changes what we process or how, the dashboard shows that the organisation’s acceptance is for an earlier version and asks an owner or admin to accept the current one; the earlier acceptance stays on the record.

• Version 1.3 — 2026-10-12. Brings the text in line with two changes to the product. Form field values are now masked by default: section 5 and Annex II say so, and that recording what people type is a choice the customer makes with maskAllInputs: false, which then puts masking anything sensitive on the customer. Section 3 names Argus, the assistant that summarises and analyses recordings on paid plans, as part of the processing, and Annex II adds how translation and Argus use the language-model sub-processor and that an owner or admin can turn both off. Annex III is unchanged; the sub-processor list now gives OpenAI’s purpose as translation and Argus, under the notice published on 12 October 2026.
• Version 1.2 — 2026-09-20. Says what “deleted” means where the recordings are actually stored. Sections 9 and 11 and Annex II now state that a deletion removes the recording from the service at once and that the object-storage provider hides it immediately but removes the bytes seven days later — a window that exists so a deletion nobody intended, a bug or a stolen key, can be undone while it still can be. They also state that encrypted off-site backups are kept for thirty days and, while recordings are held on our own server rather than in object storage, contain them. Section 11 adds that the billing events behind an organisation’s payments are kept for accounting after it closes, with the organisation’s identifier removed. Annex I’s retention line now gives the default a new organisation actually starts with — fourteen days, the free plan’s ceiling — instead of thirty, and names the ceiling each plan allows. Annex III’s list is unchanged: translation moved from fal to OpenAI under the notice published on 19 September 2026.
• Version 1.1 — 2026-09-18. Annex I now states that recordings may contain what people type into forms on websites and in mobile apps alike: both SDKs record field values unless the customer switches masking on, and passwords, one-time codes and payment card fields are masked in every configuration. Email addresses and telephone numbers typed into ordinary fields are named as recorded data, because they are no longer part of that floor. It also adds the approximate country and city of a session. Annex II describes the masking controls accordingly, and section 5 states plainly that configuring masking for special-category, contact or payment data is the customer’s obligation — including labelling mobile text fields, which the floor can only recognise from the hints the app gives the operating system.
• Version 1.0 — 2026-09-17. First published data processing agreement.

[email protected]