Data processing agreement

1.1. The controller uses Nordtally to measure visits to its websites. For the personal data in those measurements, the customer is the controller and Nordtally is the processor. Annex 1 describes the processing.

1.2. For account data about the customer’s own users (names, email addresses, sign-in data), Nordtally is a controller, and its privacy policy applies instead of this DPA.

1.3. Terms such as “personal data”, “processing”, “personal data breach” and “sub-processor” have the meaning they have in the GDPR.

2.1. Nordtally processes personal data only on the controller’s documented instructions, including with regard to transfers to third countries, unless EU or member state law requires otherwise. In that case Nordtally informs the controller of that legal requirement before processing, unless the law prohibits it.

2.2. The controller’s instructions are this DPA, the terms of service and the settings the controller chooses for each site, such as the compliance mode, retention period, Global Privacy Control and Do Not Track settings, query-parameter allow-list and excluded IP ranges and paths.

2.3. Nordtally immediately informs the controller if, in its opinion, an instruction infringes the GDPR or other data protection law.

2.4. Nordtally does not use the personal data for its own purposes. It does not sell or share it, does not combine it with other data, does not use it across customers and does not use it for advertising, profiling or benchmarking.

Nordtally ensures that everyone authorised to process the personal data is bound by confidentiality, by contract or by law, and has access only as far as their work requires.

4.1. Nordtally implements the technical and organisational measures in Annex 2, which are designed to ensure a level of security appropriate to the risk, as required by Article 32 GDPR.

4.2. Nordtally may change the measures as technology and risks develop, but never in a way that lowers the overall level of protection.

5.1. The controller gives Nordtally general authorisation to engage sub-processors. The sub-processors in use when this DPA was last updated are listed in Annex 3 and on the sub-processor page.

5.2. Nordtally informs the controller at least [30] days before adding or replacing a sub-processor, by email to the workspace owners and on the sub-processor page. The controller may object on reasonable data protection grounds within that period. If the parties cannot resolve the objection, the controller may end the agreement before the change takes effect.

5.3. Nordtally imposes data protection obligations on each sub-processor by contract that are no less protective than this DPA, in particular sufficient guarantees for appropriate technical and organisational measures. Nordtally remains fully liable to the controller for its sub-processors.

6.1. Personal data collected from visitors to the controller’s websites is stored and processed only in the EU. Nordtally does not transfer it outside the EU/EEA.

6.2. Nordtally will not move this data to another location, or transfer it to a third country, without the controller’s prior written instruction and a valid transfer mechanism under Chapter V GDPR.

7.1. Taking into account the nature of the processing, Nordtally assists the controller with appropriate technical and organisational measures to respond to requests from data subjects exercising their rights under Chapter III GDPR.

7.2. The service is designed so that data about a visitor cannot be linked back to them: strict mode stores no identifier, and the daily visitor hash cannot be recomputed after its salt is deleted at midnight UTC. In most cases neither party can therefore identify a data subject’s data (Article 11 GDPR). In consented mode, data can be located with the ID in the visitor’s consent cookie, and Nordtally will help the controller do so on request.

7.3. If Nordtally receives a request directly from a data subject, it forwards it to the controller without undue delay and does not respond itself unless the controller instructs it to.

Taking into account the nature of the processing and the information available to it, Nordtally assists the controller in meeting its obligations under Articles 32 to 36 GDPR: security, notification of personal data breaches, data protection impact assessments and prior consultation. The compliance centre provides the generated privacy text, an Article 30 record entry and a CNIL self-assessment for each site.

9.1. Nordtally notifies the controller without undue delay, and no later than [48] hours after becoming aware of a personal data breach that affects the controller’s data.

9.2. The notification describes, as far as known, the nature of the breach, the categories and approximate number of data subjects and records concerned, the likely consequences and the measures taken or proposed. Information that is not yet available is provided as soon as it is.

9.3. Nordtally documents every breach and takes the steps needed to contain it and limit its effects.

10.1. Event data is kept for the retention period the controller sets for each site, between 1 and 25 months, and is then deleted by a scheduled job. Deletion is physical, not a hidden flag.

10.2. When the controller deletes a site or workspace, or the agreement ends, Nordtally deletes the related personal data within [30] days, unless EU or member state law requires it to be kept. The site’s consent key is destroyed at the same time. Encrypted backups containing the data are overwritten within [backup retention period].

10.3. Before deletion the controller can export its statistics as CSV or through the Stats API. Exports contain aggregates only.

11.1. Nordtally makes available to the controller the information needed to demonstrate compliance with Article 28 GDPR, including this DPA, its annexes and the documentation in the compliance centre.

11.2. Nordtally allows for and contributes to audits, including inspections, by the controller or an auditor it mandates. The controller gives at least [30] days’ notice, the auditor is bound by confidentiality, and audits take place during business hours without disrupting the service or exposing other customers’ data. Unless an audit follows a breach or an order from a supervisory authority, each party bears its own costs and audits take place at most once a year.

12.1. This DPA applies for as long as Nordtally processes personal data on the controller’s behalf.

12.2. If this DPA conflicts with the terms of service, this DPA prevails for the processing of personal data.

12.3. Liability under this DPA follows the terms of service, except where the GDPR provides otherwise. The DPA is governed by the same law as the terms of service.

Data minimisation in the collection pipeline

• Each request is processed in memory by a single service. The component that writes data only accepts a structure that has no field for an IP address or user-agent string.
• IP addresses are never written to any database, log, trace, metric, error report, queue or backup. Country is looked up from an in-memory database and is the most precise location kept.
• User-agent strings are parsed into browser and operating system family with major version, and device type. The raw string is never stored.
• Page addresses lose their fragment and every query parameter except utm_*, ref, source and parameters the controller allow-lists. Email addresses, long numbers, ID-like and token-like strings are redacted, and addresses are truncated to 2,048 characters. Referrers are reduced to host and path; internal referrers are dropped.
• Custom properties are limited to 30 keys and 2,000 characters per value, and email-like values are rejected.
• Requests marked with Global Privacy Control are dropped before anything is recorded; this is configurable per site and on by default. Do Not Track can be honoured per site in the same way.
• In strict and anonymous mode the tracker never reads or writes cookies or browser storage and uses no fingerprinting surfaces such as canvas, WebGL, fonts, audio, screen size, plugins or hardware details.

Pseudonymisation and keys

• Visitor hashes are keyed BLAKE2b hashes of the site, IP address and user-agent with a daily salt of 32 random bytes. Salts rotate at 00:00 UTC; old salts are deleted and the table is vacuumed.
• In consented mode the hash input is the random ID from the consent cookie, keyed with a per-site consent key that is destroyed when the site is deleted.
• Salts and consent keys are never logged or exported. They are kept in database tables that are not written to the write-ahead log or replicated, the database runs without WAL archiving or point-in-time recovery, snapshots of the database server are disabled, and backups are logical dumps that exclude these tables.
• Hashes always include the site, so they cannot be linked across sites.

Access control and separation

• Each customer workspace is separated in the application. Every dashboard, API and export query is scoped to a site the user has been checked for access to, and analytics queries run with a read-only database user. Tests cover cross-tenant access attempts.
• Roles (owner, admin, analyst, viewer, client viewer) limit what each member can see and do. Two-factor authentication is available for all accounts, and no sign-in method bypasses it.
• Account sessions store no IP address or full user-agent string. Passwords, shared-link tokens and API keys are stored only as hashes. Sign-in attempts and shared-link passwords are rate limited.
• Visitor and visit identifiers are never shown in the dashboard and never included in exports, the Stats API or shared dashboards.
• Production access is limited to [named roles]. Deployments go through an automated pipeline with manual approval for production.

Logging and monitoring

• Web server access logs are filtered to remove client IP addresses, ports and all request headers. The collection service’s logger has no fields for IP addresses or user-agents.
• Errors are tracked on a self-hosted service on our own EU servers, with personal data scrubbed.
• An automated canary test sends events with a unique IP address and user-agent, then searches every database, log and database dump for them; the build fails if either is found. Another test proves that salts rotate and old salts are gone.

Availability, backups and deletion

• Servers run in Hetzner’s data centres in the EU. Physical and environmental security is provided by Hetzner under its own data processing agreement.
• Backups are encrypted logical dumps stored in Hetzner Object Storage in the same region.
• If the database is unavailable, events are queued on local disk in their already-sanitised form, with a size limit and an alert.
• Retention and site deletions remove data physically and wait for completion.

Transport and organisation

• Traffic between browsers or customer servers and Nordtally is encrypted with HTTPS.
• Changes that touch collection, storage or logging are reviewed against a written list of privacy invariants, which change only by recorded decision.
• Security incidents are handled under a documented procedure, including notification under section 9. [Confirm the incident procedure is written down before launch.]

As of 2026-11-03:

Only Hetzner processes event data. The current list is always on the sub-processor page.