Technical and Organizational Measures (TOM)

1. Scope and Purpose

This document describes the technical and organizational measures (TOM) that MousePlayer implements to ensure a level of security appropriate to the risk, in accordance with Art. 32 GDPR. It applies to all processing of End-User data carried out on behalf of a Controller (Customer).

Operator of the service: LW IT Solutions Company Lukas Wójcik, al. Tadeusza Kościuszki 80/82 lok. 301, 90-437 Łódź, Poland · NIP PL7252266190.

2. Confidentiality – Access Control

2.1 Physical access

The service runs on hardware owned and operated by us, located in Łódź, Poland. No third-party data centre, cloud or hosting provider is involved in the operation itself. The servers are operated in-house, in closed premises within Poland. Access is held solely by the controller. The room is locked by key and under video surveillance; no other persons — including landlords or cleaning services — have access (statement of the controller, 17 Aug 2026). The precise address is deliberately not stated here.

2.2 System access

• Access to the application requires an individual user account with a password; passwords are stored as salted hashes, never in plain text.
• Administrative interfaces are separated from the customer-facing application and are accessible only to super administrators; the authorisation is checked on the server.
• State-changing requests of the signed-in web interface are protected by CSRF tokens; programming interfaces authenticate with their own keys.
• Server administration takes place via SSH with key-based authentication.
• Sign-in can optionally be protected by a second factor (time-based one-time codes per RFC 6238). The secret is stored encrypted and recovery codes only as hashes; a code that has already been used is not accepted a second time, and repeated failed attempts temporarily lock the account's second factor.
• Every sign-in is tracked individually (login_sessions). The account holder sees the list in the settings and can revoke individual sign-ins or all others; revocation also ends a running session and a stored remember-me token. A password change ends all other sign-ins. If an account signs in from an unknown device (fingerprint from browser, operating system, device type and the /24 or /48 network range of the IP address), the holder receives an e-mail.

2.3 Data access (authorization)

• A role model (owner, admin, viewer) governs what a user may see and do within a workspace. Deletion and sharing are restricted to owner and admin; the restriction is enforced on the server, not merely in the interface.
• Every query for session data is bound to the workspace of the requesting account. A recording of another customer cannot be addressed even with a known identifier.
• Share links (see 4.3) are the only way to reach a recording without an account. They are created deliberately by an authorized user, can be revoked, and can carry an expiry date.

2.4 Separation

• Customer data is separated logically by workspace and project (channel). Every read and write path carries this restriction.
• Development and production run in separate installations with separate databases.

3. Pseudonymization and Data Minimization

• No processing before consent. The tracking script performs no identification, no storage, no cookie and no network connection until a consent signal is present. Absence of a signal is treated as refusal, not as permission.
• Global Privacy Control. A GPC signal from the browser is honoured worldwide and overrides any other signal.
• Pseudonymous identifiers. Visitors are distinguished by randomly generated tokens. No names, e-mail addresses or telephone numbers are collected by the Service itself.
• IP addresses. The full IP address of a visitor is used in the working memory of the recording server to establish the connection, to determine country, city and network provider, and to defend against abuse; it is written to the database only in truncated form (for IPv4 a.b.c.xxx), and the dashboard never displays a full visitor IP address. Exceptions: to detect connection floods, an address is counted in Redis for ten seconds; if it triggers the automatic block, it is held in full for up to 24 h as a block entry in Redis (mp_autoban:), and this Redis instance writes to disk via AOF. Accesses through share links are logged with the full IP address (share_views) and are deleted with the link.
• URL redaction. The values of parameters that commonly carry personal data or access credentials (for example ?email=, ?token=, ?code=) are removed before storage – in the query string as well as after the #, where sign-in services place access credentials (for example #access_token=). Single-page application routes and in-page anchors are kept.
• Form input – three levels, strictest by default. Full masking (the default) replaces every character of every entry before it leaves the browser. Selective masking keeps names, addresses, e-mail, telephone, payment fields and free-text areas fully masked and replaces only digits elsewhere, so search terms stay usable. No masking records input as typed. The two weaker levels are not self-service: each requires our written approval for that specific property, recorded with time and grantor. Enforcement is server-side – a project whose stored level exceeds its approval is capped at the approval before the value ever reaches the browser, so setting the field directly achieves nothing.
• The floor no approval lifts. Fields recognised as passwords or payment data stay fully masked on every level. Recognition reads the field's name, id, type and autocomplete attribute and covers English, German and Polish terms. None of this reaches content the website itself renders into the page; regions marked data-mp-mask are excluded from the recording entirely.
• Exclusion list. The Controller can exclude entire paths (for example checkout or account pages) from recording. The exclusion is enforced on the server and also applies when a single-page application navigates into an excluded path without opening a new connection.

4. Integrity – Transfer and Input Control

4.1 Transport

• Connections from the internet are TLS-encrypted; TLS terminates in nginx on the server. Unencrypted requests on port 80 are redirected to HTTPS. The tracking script connects over WSS by default (/mp_wss/). If the WebSocket never comes up, it falls back to an HTTP tunnel over HTTPS (/mp_wst) that passes through the same server-side checks; very large page snapshots are uploaded over HTTPS with a signed, time-limited token (/mp_dom), and failed WebSocket connections are counted by a measuring endpoint without any visitor identifier (/mp_wsfail). Behind nginx, the WebSocket server listens only on the server's loopback interface, without TLS.
• Within our own local network at the same site, connections to the database (MariaDB) and the cache (Redis) are unencrypted; transport encryption of these connections is not configured. Both are access-restricted and reachable only from our own local network (no port forwarding); the application's Redis instance listens on the loopback interface only.
• Certificates are renewed automatically. An expired certificate of the application would be noticed by the one-minute check from a second machine (see section 5), which queries over HTTPS with certificate verification; there is no separate monitoring of certificate lifetime.

4.2 Input control

• Administrative actions are recorded in an audit log with account, time and action.
• Every change of consent state is written as its own record, together with its source (explicit API, Consent Mode, TCF, CMP adapter, GPC), so that the state at the time of recording remains verifiable.

4.3 Onward transfer

• The tracking script transmits exclusively to MousePlayer's own infrastructure. No third party is contacted during normal recording.
• Optional interfaces (webhooks, BigQuery, customer relationship, e-mail marketing and ticketing systems, spreadsheets and object storage, conversion interfaces of advertising networks) are configured by the Controller; they run into systems the Controller chooses, are inactive unless the Controller enables them, and transmit individual items; only the BigQuery export can, on the Enterprise plan and on request, also include the raw events of the recording (mouse_events). Where the Controller switches on a bridge to a tool it has itself embedded on its page (such as chat, error tracking or web analytics), the script hands individual items such as the link to the recording to that tool in the browser; the tool's own script transmits them to its provider. The recipients are not sub-processors of MousePlayer.
• Generated texts are phrased by a language model on our own machines with a graphics card, in the same local network and at the same site as the server. They fetch the calculated findings over HTTPS, every request signed with its own secret; the recording itself never reaches them, and nothing goes to an external AI service – not even while such a machine is down for maintenance: the jobs then wait, and the interface shows the calculated version.
• Share links transfer data only to whoever holds the link. The Controller decides whether to create one.

5. Availability and Resilience

• A full backup of the database, the application directory and – since 6 October 2026 – the recording archive is created daily at 03:00; up to 11 August 2026 it ran at 02:00.
• Local retention of backups: 7 days. The local copy is held unencrypted on an attached drive; encryption takes place when the copy is transferred off-site. The unencrypted dumps from the period before the changeover were removed there on 12 August 2026, so that the local folder now holds only the dumps made since the changeover and that retention applies to it. In addition to the local copy, the daily backup is transferred off-site – since 5 September 2026 to a Google Cloud Storage bucket in region europe-central2 (Warsaw); before that to a private Google Drive account; the copies held there were deleted on 6 September 2026, after a restore from the new destination had been verified. Retention there: daily copies for 7 days, weekly copies (Sundays) for 364 days. Both figures are a setting, not a constant in a script: the backup reads them from the same row of the configuration that this sentence quotes, so the published statement and the behaviour cannot drift apart. The copy contains the complete database. After 7 days the events of a recording are moved from the database to an archive. Since 6 October 2026 this archive is part of the daily backup; before that it was not backed up, and recordings older than 7 days had no backup copy. The archive resides on the same disk as the system; the local copy on a separate drive and the off-site copy protect against failure of that disk. Since 11 August 2026 it is encrypted on our own server before the transfer (rclone crypt); file and directory names are encrypted as well, so that the provider holds only blocks without discernible meaning. The keys are kept in two files on our own server, readable and writable only by their owner (file mode 600); the provider does not have them and cannot read the content. Decryption of such a copy has been verified. The previous, unencrypted target folder holding the complete copies from before 11 August 2026 was deleted on 12 August 2026. Since 19 August 2026 the success of the transfer is monitored automatically. The backup writes its outcome to a status file, and the watcher asks for the last successful run rather than the last run – a script that starts every night and aborts every night has a fresh timestamp and no backup. Where no successful run has occurred for longer than the configured period (36 hours by default, which permits exactly one missed daily run), a warning is sent by e-mail, at most once a day.
• Data deleted in the live system remains present in backups until the corresponding backup expires – at most 364 days after the permanent erasure; after that it is no longer contained in any backup either. This is an unavoidable consequence of having backups at all; requests for erasure carried out through the administration take the data out of processing at once (archived, hidden, no longer recorded) and erase it permanently after 30 days at the latest, without waiting where this is expressly requested; a request made on the data page /my-data is carried out without archiving, as a rule within minutes. Selective erasure inside a backup is not performed: a copy is a single sealed archive whose purpose is to be a faithful image of one point in time, and opening, altering and re-sealing it would destroy that property and the ability to show that nobody tampered with it. Backups serve no purpose other than restoring the system after a loss; they are not searched, not analysed and not disclosed. Where a backup is restored, the erasure requests recorded for end users are executed again before the system returns to service – the request record survives the erasure precisely so that it can be repeated. For a deleted customer account the position differs: its deletion deliberately leaves no record identifying it, so a restored copy would contain an account deleted after the date of that copy.
• Monitoring. A watcher process checks, at one-minute intervals, the database and event worker, the WebSocket server, the web front end, the currency of the geolocation database, the daily deletion run, the success of the backup and free disk space on the system volume and the backup volume. Each result is written to the shared state and shown in the administration area, and each failing check is reported by e-mail at most once a day – a watcher that mails every minute is switched off, and then it no longer reports the real failure either. Before 19 August 2026 only the first five of these were checked and only the deletion run raised an alert; the remainder was manual, and this document said so.
• What this monitoring cannot do, stated rather than implied: it runs on the machine it watches, so it cannot report that machine's total failure. Since 2 October 2026 a second machine at the same location checks every minute whether the application accepts recordings – database, cache, WebSocket server, background processes, queue and the tracking script – and alerts by Telegram after two failed checks in a row. It reaches the server over the local network: a failure of the internet connection, the router or DNS is not detected by it and is still noticed by a person, not by a monitor. Recovery time objective (RTO): no more than 24 hours. Restore tests: recovery from the off-site backup was tested on 5 and 6 September 2026 and on 7 October 2026 (complete restore of the data); no fixed schedule has been set.
• Overload and attacks. nginx limits requests and concurrent connections per address; an address that persistently exceeds the limit is rejected at the firewall by fail2ban for one hour. The WebSocket server automatically blocks addresses that generate connection floods for 24 h; blocks set manually by the operator are kept in the database.

6. Procedures for Regular Review

• The measures in this document are reviewed when the processing changes, and otherwise at the interval stated in section 10.
• An installation check verifies for each Customer project whether the script is embedded correctly and whether recordings are arriving with a consent record. Projects without such a record are flagged in the dashboard.
• No external penetration tests are currently commissioned and no security certifications are held. This is stated here rather than omitted: a TOM document that stays silent on the point reads as if such tests existed.
• The number of end users observed across all customers is measured daily and held against the threshold at which the assessment under Art. 37 GDPR must be repeated (100000 a month; see section 9 of the Records of Processing). That quantity is set by traffic on customer websites and not by us, so leaving it unwatched would mean the assessment silently going out of date. The annual repetition is watched by the same process.

7. Sub-processors

MousePlayer engages sub-processors only with the Controller's general written authorization under the DPA. The current list, including purpose, categories of data and place of processing, is published separately:

• List of sub-processors

No third party takes part in the recording itself: the tracking script transmits exclusively to MousePlayer's own infrastructure. For end-user data, one recipient exists beyond that: a daily off-site copy of the complete database and of the recording archive — including session recordings — is stored with Google (Google Cloud Storage, bucket in Warsaw). It has been held there encrypted since 11 August 2026: encryption takes place on our own server before the transfer (rclone crypt) and covers file and directory names as well; the keys are held by MousePlayer. Google does not receive them and cannot read the content, but remains a sub-processor — encryption is a technical measure, not a change of role. The previous, unencrypted target folder holding the copies from before 11 August 2026 was deleted on 12 August 2026.

8. Retention and Erasure

Retention of session recordings depends on the Customer's subscription tier:

• Free: 7 days · Small: 30 days · Business: 90 days · Enterprise: as contractually agreed, individually.
• After a downgrade, a grace period of at least 30 days applies during which the longer retention of the previous tier continues. An upgrade never shortens retention.
• The application log is erased after 60 days, the web server logs after 14 days, security logs after 72 hours.
• For sessions identified as automated access, the recording is cleared after 1 day and the session is erased after 14 days. For an account on the Free plan marked as suspected of abuse, only part of the visits is recorded, and recordings are deleted after 1 day.
• The integration delivery log is erased after 30 days. It lives in Redis rather than the database and expires there by itself; the list is additionally capped at 25 entries per project. It is therefore not part of the daily backup either.
• Erasure at the end of a retention period runs automatically and unattended; it does not need to be triggered manually.

On termination of the Customer account, all associated personal data is erased within 30 days, unless Union or Member State law requires further storage. The deletion is started by the Customer in the account settings; no request by e-mail is required. It first archives the account: access ends at once, nothing is recorded or shown any more, and for 30 days we can still restore it on request in case the deletion was a mistake. After that period it is erased permanently; when starting the deletion, the Customer can also choose permanent erasure at once. A project or a workspace that the Customer deletes is likewise archived for 30 days first and can be restored in the dashboard during that time. Three things are deliberately kept, because the law requires it or because they document a decision rather than a person: the record of acceptance of these documents, the security and change log (with the user reference removed), and support requests. By way of exception, an account on the Free plan that has gone unused for 24 months is erased permanently, without prior archiving, 30 days after a delivered notice.

Consent records are retained beyond the erasure of the recording itself. They contain no behavioural data, only the fact, time and source of the consent decision, and they exist to discharge the accountability obligation under Art. 5(2) GDPR.

9. Personal Data Breach

MousePlayer notifies the Controller without undue delay, and no later than 48 hours, after becoming aware of a personal data breach affecting the Controller's data. The notification contains the information the Controller needs in order to meet its own obligations under Art. 33 GDPR.

Reporting address for security issues: office@mouseplayer.com

10. Status and Version

• Version: 1.5 · Effective: 16 October 2026 · Next review: 19 August 2027 · replaces version 1.4 of 7 October 2026. Changed: section 2.2 names two-factor sign-in, the list of active sign-ins with revocation and the sign-in alert; section 2.3 names the roles owner, admin and viewer; section 3 names the exceptions for full IP addresses; section 4.1 describes the transport paths of the script and the unencrypted connections in the local network instead of stating that there is no unencrypted path; section 4.3 names the other interfaces; section 5 records that the recording archive has been backed up since 6 October 2026, and names the restore tests carried out and the overload limits; section 8 adds retention periods and the deletion of inactive accounts. In addition, section 2.2 states the status of SSH sign-in, and the duration of the automatic block is given as a setting. Version 1.4 replaced version 1.3 of 17 September 2026. Changed: sections 5 and 8 state that erasure first archives the data – taken out of processing at once – and erases it permanently after 30 days at the latest. Version 1.3 replaced version 1.2 of 19 August 2026. Changed: section 4.3 names the machines that run the language model for generated texts, how the findings get there, and what happens during maintenance. Version 1.2 replaced version 1.1 of 11 August 2026. Changed: section 5 states the backup retention as a setting rather than a constant, describes what happens to erasures on a restore, and records that backup success and disk space are now monitored automatically; section 6 adds the measurement of the Art. 37 threshold.
• In case of divergence between language versions, the English version prevails.