Data processing agreement

1. Parties and scope

This agreement is between the customer who accepts the terms of service (the controller) and the provider of Highseat (the processor):

• Legal name: Piotr Kulpiński
• Address: Al. Pokoju 83A/12, 31-564 Kraków, Poland
• Tax number (NIP): 8661673036 (EU VAT number PL8661673036)
• Registry entry: Central Register and Information on Economic Activity (CEIDG), REGON 260591531
• Email, for privacy and anything else: support@highseat.com

It applies to the personal data the processor handles for the customer when it collects and reports on traffic to the customer's sites. It is part of the terms of service and is accepted with them, by creating an account or using the service. No signature is needed. Where this agreement and the terms differ on personal data, this agreement wins.

Account data about the customer's own staff, such as their names and email addresses, is not covered here. The processor is the controller of that data, as the privacy policy explains.

2. Subject, duration, nature and purpose

Subject: the collection, storage and analysis of visits and events on the customer's sites, and reports on them.

Duration: for as long as the customer's workspace runs, then until its sites are deleted. After a trial or plan ends unpaid, collection continues for 14 days as part of the service, and the data is deleted on day 60:

Nature: receiving events from the tracker, the customer's own servers and the customer's payment providers; deriving the device, location and visitor id from each request; storing, aggregating, exporting and deleting the result.

Purpose: to give the customer analytics about their own sites. The processor does not use the data for its own purposes, does not sell it, and does not combine it with data from other customers.

3. Types of data and data subjects

Data subjects: the visitors of the customer's sites, and, where the customer calls identify(), the customer's own signed-in users.

Each event stores:

• The page: its host and path, its title, and only the query parameters the site owner chose to keep. Every other query parameter and the URL fragment are dropped.
• Where the visit came from: the referring page without its query string, UTM tags and ad click ids (such as gclid or fbclid).
• The device, read from the user agent on arrival: browser, operating system, device type, brand and model, with their versions. Also the screen and window size and the browser language.
• The location, looked up from the IP address on arrival in a database on our own server: country, region, city and that city's approximate coordinates.
• A visitor id: a SHA-256 hash of the site, the IP address, the user agent and a random salt that changes every day. A session id built from it.
• How long the page stayed in view and how far it was scrolled.
• Custom events and the properties the site sends with them, and revenue: an amount, a currency and a hashed checkout id.
• A user id, only when the site calls identify(). It is stored exactly as the site sends it.

The processor reads but never stores:

• The IP address. It is read once to look up the location and to build the visitor id, then dropped.
• The user agent. It is read once to work out the device and to build the visitor id, then dropped.
• Cookies. The tracker sets none, and the request to collect events carries none.

The tracker keeps in the visitor's browser:

• A random id for the browser tab, in session storage under highseat_aid. It lets a sale made in that tab be credited to the visit. The browser deletes it when the tab closes, and the server stores only its hash.
• The user id from identify(), in local storage under highseat_uid, only on sites that call it. It is removed when the site calls identify(null), and after 13 months.

When a customer connects a payment provider, the processor also receives that provider's sale and refund records: the amount, the currency, an order id and the hashed checkout id. It stores no name, email address or card detail from them.

The service is not meant for special categories of data (GDPR Art. 9). The customer must not send them, and must not put a direct identifier such as an email address into identify(), an event property or a URL.

4. The controller's instructions

The processor processes the data only on the customer's documented instructions. These are this agreement, the terms, and the customer's choices in the dashboard and the API: which sites to track, which query parameters to keep, what to exclude, what to import and what to delete.

The customer instructs the processor to delete each site and its events on day 60 after the workspace lapses. This is a standing instruction, given now, and the deletion notice email repeats it.

If the processor believes an instruction breaks the GDPR or another data protection law, it tells the customer at once. If EU or member state law requires processing the customer did not instruct, the processor tells the customer first, unless that law forbids it.

5. Confidentiality

Everyone the processor allows to access the data is bound to keep it confidential, by contract or by law. Only the people the processor names for it can reach the production systems, and only as far as running the service needs.

6. Security

The processor keeps the technical and organisational measures in the annex in place, and reviews them as the service and the risks change (GDPR Art. 32). It may improve them, but never lower the overall level of protection.

7. Sub-processors

The customer gives general authorisation for the processor to use sub-processors. The current list, with each one's purpose and location, is on the sub-processors page.

The processor tells the customer before it adds or replaces a sub-processor, by email to the workspace owners and on that page, at least 14 days before the change takes effect. The customer may object on reasonable data protection grounds within that time. If the parties cannot resolve it, the customer may end the agreement and gets a refund of any prepaid fees for the unused period.

When a sub-processor fails, suffers a security incident, or has to be replaced to keep the service secure or running, the processor may engage the replacement at once. It then tells the customer as soon as possible, and within 72 hours of the switch. The customer keeps the same right to object and the same remedy: ending the agreement with a refund of any prepaid fees for the unused period.

This notice covers additions and replacements on the sub-processor list only. The services the processor uses for its own account and billing data, listed separately on the same page, change without notice, through an update to the privacy policy.

The processor puts each sub-processor under data protection duties at least as strict as this agreement, and stays liable to the customer for how each one performs them.

8. Transfers outside the EEA

Events and account data are stored in Finland, in the EU. Some sub-processors are based in, or reach the data from, a country outside the European Economic Area.

Each such transfer relies on the sub-processor's certification under the EU-U.S. Data Privacy Framework: Cloudflare and Better Stack are both certified. Where the framework does not apply, the transfer relies on the Standard Contractual Clauses adopted by the European Commission in Decision (EU) 2021/914, Module 3 (processor to processor), in that sub-processor's data processing agreement. The clauses are incorporated by reference and are not copied here.

9. Helping with data subject requests

The processor helps the customer answer requests from data subjects under GDPR Articles 15 to 22. Most of this help is built into the service:

• Access and portability: owners and admins can export every event of a site as a CSV file, in every state of the workspace.
• Erasure: on a site's Data settings, owners and admins can erase everything recorded for one user id, with the rest of that user's visits.
• Anonymous visitors: their id changes every day and cannot be traced back to an IP address once the day's salt is deleted. So no one, the customer or the processor, can find one anonymous visitor's events. Such a request can be answered by saying so.

If a data subject writes to the processor about a customer's site, the processor forwards the request to the customer and does not answer it alone.

The processor also helps the customer, as far as it reasonably can, with security, breach notices, data protection impact assessments and prior consultation (GDPR Arts. 32 to 36).

10. Personal data breaches

The processor tells the customer without undue delay after it becomes aware of a personal data breach affecting the customer's data, and no later than 48 hours after. The notice goes to the workspace owners by email.

The notice says what happened, which data and roughly how many data subjects are affected, the likely consequences, and what the processor has done and will do. Facts not known yet follow as soon as they are.

11. Deletion and return at the end

Before the end, the customer can export every event of each site, free, for as long as the site exists. An export file stays available for 7 days, then it is deleted.

At the end, the processor deletes the data. That happens when the customer deletes a site, a workspace or an account, or on day 60 after the workspace lapses, on the customer's standing instruction. The ways to delete:

• One identified user: on a site's Data settings, an owner or admin can erase every event recorded for one user id, with the rest of each of that user's visits.
• Imported history: an import can be deleted on its own, and the site's sessions are rebuilt without it.
• A site: deleting a site deletes every event and session it recorded. The delete runs a second time once no late event can still arrive.
• A workspace: deleting a workspace deletes its sites, their events and its subscription.
• An account: deleting an account deletes the person's profile, sign-in methods, sessions and memberships, and every workspace nobody else belongs to. An account that is the only owner of a shared workspace must hand that workspace over first.

Deleted events disappear from every report at once. They leave the database disk within hours, through a job that runs every hour. Daily backups keep events for up to 60 days and account data for up to 14 days, so a deletion is complete everywhere within 60 days.

Events are kept while the workspace runs, until the customer deletes them, deletes the site or the workspace, or the workspace lapses and its sites are deleted on day 60. Highseat sets no shorter period of its own.

The workspace record, its members and its invoices stay after its sites are deleted, because the law requires invoices to be kept. They hold no visitor data.

12. Information and audits

The processor gives the customer the information needed to show that it meets GDPR Article 28. It answers reasonable written questions, and shares summaries of its sub-processors' audit reports where they allow it.

If that is not enough, the customer, or an auditor bound to confidentiality, may audit the processor once a year, with at least 30 days' notice, during business hours and at the customer's own cost. An audit must not disturb the service or expose another customer's data.

13. Liability, law and changes

The limits of liability in the terms of service apply to this agreement, except where GDPR Article 82 does not allow it.

Governing law: Polish law. Courts: the common court with jurisdiction over the provider's place of business in Kraków.

The processor may update this agreement to follow the law or the service. It emails the workspace owners before a change that lowers the customer's protection takes effect, and such a change never applies without that notice.

Questions about this agreement: support@highseat.com.

14. Annex: technical and organisational measures

Data minimisation

• No raw IP address or user agent is ever stored. Both are read once and dropped.
• The salt behind each visitor id is 32 random bytes, made on the first event of each day and stored only in our Postgres database. The same visitor gets a new id every day, so ids cannot be linked across days.
• Each salt is deleted about three and a half days after its day begins, once no late event can still need it. A job checks every hour. After that, nobody, Highseat included, can work out which IP address an id came from. The daily database backups keep a deleted salt for up to 14 more days.
• The tracker sets no cookies and turns itself off for a browser that sends Global Privacy Control.
• Page URLs are stored without their fragment and without any query parameter the customer has not chosen to keep. Referrers and link targets are stored without their query string.
• The id that links a sale to a visit is hashed before it is stored.

Where the data lives

• Events and account data sit on one dedicated server at Hetzner in Helsinki, Finland. The databases are reachable only from the app's internal network, never from the internet.
• Both databases are backed up off site every day, to Cloudflare R2 in Western Europe. Backups of events are kept for up to 60 days, backups of account data for up to 14 days.
• Cloudflare encrypts every object in R2 at rest, including the backups.

Access

• Every connection to the app and to ingest uses HTTPS.
• Members have one of three roles: owner, admin or viewer. Only owners and admins can export, erase or delete. A share link shows only the reports it was made for.
• Passwords are stored as hashes. API keys and site secrets are stored only as SHA-256 hashes, so a database copy cannot be used to sign in or report.
• Secrets for connected payment providers are encrypted with AES-256-GCM under keys kept outside the database, and the keys can be rotated.
• Sign-in, share links and ingest are rate limited. Each sign-in session can be seen and ended by its owner.
• Only people the processor names for it can reach the production server and its deploy panel.
• The server accepts sign-in by SSH key only, with passwords switched off. The deploy panel reaches the server over a private, encrypted network.
• The deploy panel is not open to the internet. Reaching it takes a separate sign-in through Cloudflare Access before the panel's own login.

Monitoring and resilience

• Errors and request traces go to Better Stack with secret tokens removed from every URL first.
• Alerts fire when ingest fails or starts losing events.
• Event inserts are deduplicated, so a retried request is stored once.
• Deletes are applied twice for a deleted site, and deleted rows are removed from disk by an hourly job.