Data Processing Agreement

Processor: S.C. CloudX Digital Agency, Str. Principală nr. 358, Sângeru, județul Prahova, România, trade register no. J29/1572/2016, tax ID RO36481851, operating the PageView.ro service. Contact for data protection matters: [email protected].

Controller: the customer — the organisation that installs the tracker on its websites and holds the PageView.ro account. You determine the purposes and means of the measurement; we process only on your behalf.

This agreement applies automatically to every account. It does not replace the Article 26 arrangements you may need with any other party, and it does not cover the account data of your own staff who sign in to the dashboard — for that data we are the controller, and the Privacy Policy applies.

Data subjects

• Visitors and readers of the controller's websites.
• Authors and editors named in the controller's own article metadata, to the extent those names are personal data.

Personal data

• We process personal data only on the controller's documented instructions. This agreement, the Terms of Service, the settings you choose in the dashboard and the requests you make through the product together constitute those instructions.
• We do not process reader data for our own purposes, do not sell it, do not enrich it with third-party datasets, do not use it for advertising, and do not use it to train machine-learning models.
• If we believe an instruction infringes the GDPR or other Union or Member State data-protection law, we will tell you before carrying it out.
• Where a legal obligation requires us to process beyond your instructions, we will inform you before processing unless that law prohibits it on important grounds of public interest.
• Everyone we authorise to process personal data is bound by confidentiality and is granted access on a need-to-know basis.

• Establish and document a legal basis for the measurement, and publish your own privacy notice describing it. Our Privacy Policy describes our processing; it does not discharge your duty to inform your readers.
• Obtain valid consent under Article 5(3) ePrivacy before enabling the optional first-party identity, and do not enable it until you have.
• Do not send us direct identifiers or special-category data through editorial metadata, URL paths or page titles.
• Keep the account, invitation links and the private API key secure, and manage user roles so only the right people can read the data.
• Respond to data-subject requests concerning reader data — you are the controller. We assist as described in section 9.

The controller grants a general authorisation for the sub-processors listed below. Each is bound by a written contract imposing data-protection obligations no less protective than those in this agreement, and we remain fully liable for their performance.

There is no email provider, CRM, advertising network, session-replay tool or third-party analytics service anywhere in the reader-data path.

Changes: we will publish any intended addition or replacement of a sub-processor on this page, with the “last updated” date changed, at least 14 days before it takes effect. Because we operate no email infrastructure, the change is also surfaced in the dashboard; we will not claim to have emailed you. Within those 14 days you may object on reasonable data-protection grounds, in writing to the contact address in section 1. If we cannot resolve the objection, you may terminate the affected part of the service and require deletion under section 11.

The measures below are what the system actually does today. They are described here so they can be audited against reality, not aspiration.

Pseudonymisation and data minimisation

• The visitor identifier is pseudonymised at the moment of collection: a keyed hash of user agent, IP address and site domain under a salt that rotates daily and is deleted after two days.
• The raw IP address and raw user-agent string are never written to storage; they exist only in memory during request handling.
• Location resolution stops at the country code. Query-string parameters other than utm_* are discarded. Identifiers are scoped per site, so no cross-site profile can be constructed.

Confidentiality and integrity

• All traffic runs over HTTPS.
• Each site key is bound to an allow-list of domains; requests from other origins are rejected and rate limits apply per site and per IP address.
• Access to a site's data requires an explicit membership record with a role (viewer or admin). The platform-administration surface is separated from customer workspaces, and privileged features are gated individually.
• Dashboard passwords are stored hashed; administrator-issued temporary passwords must be replaced by the user at first sign-in.
• The internal service key never leaves the server, and per-site read API keys can be rotated or revoked by a site administrator at any time.
• Outbound webhooks are HTTPS-only, cryptographically signed, and blocked from resolving to loopback, private or link-local addresses.
• Access logs on the tracker host are kept disabled or IP-anonymised as a standing operational rule.
• Administrative actions in the platform console are recorded in an audit log.

Availability and resilience

• Backups run to EU-region object storage, and restores are drilled quarterly into a scratch environment rather than assumed to work. Backups and database volumes are encrypted at rest.
• The ingest degrades under load in a defined order — heartbeats before pageviews — rather than failing unpredictably, and its saturation counters are monitored and alerted on.
• The platform runs on a single server by design and is therefore not highly available. This is disclosed rather than hidden; see section 5 of the Terms of Service.

Erasure capability

• Erasure of one person and erasure of a whole site are both implemented as first-class operations, not manual database surgery.
• The site-wide erasure capability ships disarmed at platform level and must be explicitly armed by an operator, and the dashboard requires a typed confirmation of the site's name.

• We will notify the controller without undue delay after becoming aware of a personal data breach affecting the controller's data, in writing to the contact on record.
• The initial notification will describe 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. Where the full picture is not yet available, we will send what we have rather than wait, and follow up in phases.
• We will assist the controller with its own obligations under Articles 33 and 34, including notification to the supervisory authority and, where required, to data subjects.
• We will not notify the supervisory authority or data subjects on the controller's behalf unless the controller instructs us to in writing.
• We keep a record of breaches affecting controller data and make it available on request.

• If a data subject contacts us directly about data we process for a controller, we will not respond on the merits; we will forward the request to the controller without undue delay.
• Taking into account the nature of the processing, we assist the controller with appropriate technical and organisational measures in fulfilling requests under Articles 15 to 22 — in particular through the per-person erasure operation and CSV/API export.
• We assist with data protection impact assessments and prior consultation under Articles 35 and 36, by supplying the information about our processing that is available to us.
• Article 11 limit. In the default cookieless mode we hold no additional information enabling identification of a data subject, and we are not obliged to acquire any merely to comply. We will say so plainly rather than request further personal data to build a link that does not exist.

• We make available to the controller all information necessary to demonstrate compliance with Article 28 and allow for and contribute to audits, including inspections, conducted by the controller or an auditor it mandates.
• In practice, the first port of call is documentation: this agreement, the Privacy Policy, the published architecture and operational notes, and written answers to a security questionnaire.
• Where documentation is not sufficient, the controller may audit once in any twelve-month period on 30 days' written notice, during business hours, without unreasonable disruption to the service, and subject to confidentiality. More frequent audits may take place where a supervisory authority requires it or after a confirmed breach affecting the controller's data.
• An auditor must not be a competitor of ours, and access will be scoped so that other controllers' data and the security of the platform are never compromised.
• Each party bears its own audit costs, unless the audit reveals material non-compliance on our side, in which case we bear the reasonable cost of the audit and of remediation.

• On termination of the service, and at the controller's choice, we delete or return all personal data processed on the controller's behalf, and delete existing copies unless Union or Member State law requires storage.
• Return is by CSV export and the read API, both available for as long as the account is active.
• Deletion is performed as a site-wide erasure covering the raw events, all three aggregation tables, the bot-hit table, the aggregator-hit table and the visitor profiles.
• Where no instruction is given, the retention periods in the Privacy Policy apply and the data expires automatically: raw events after 90 days, minute-level totals after 13 months, hourly rollups after 25 months, visitor profiles after 18 months of inactivity.
• Backups are not edited surgically. Data present in a backup disappears when that backup expires, within 90 days, and backups are never used to restore individual deleted records.
• Account and site metadata in the operational database — the site record, memberships, configuration — is not analytics data and may be retained where we have a legal or accounting reason; it is deleted on request where no such reason exists.

All processing of controller data takes place within the European Union. The servers, the analytical database, the operational database, the dashboard and the backups are hosted in Germany. There is no transfer of personal data to a third country, and therefore no need for Standard Contractual Clauses, an adequacy decision or supplementary measures under Chapter V of the GDPR for this processing.

Two points of detail, so the claim survives scrutiny. The country-lookup database is supplied by a United States company and downloaded onto our EU servers; the lookup itself is local and no personal data is transmitted to the supplier. The tracker host is fronted by a CDN with a global edge network, so a beacon may be terminated at an edge node geographically close to the reader before reaching our servers, while storage remains exclusively in Germany.

If we ever intend to process controller data outside the European Union, we will notify the controller in advance under the sub-processor procedure in section 6 and put an appropriate Chapter V transfer mechanism in place first.

In case of conflict between this agreement and the Terms of Service on any question of personal-data processing, this agreement prevails. In all other respects the Terms of Service continue to apply, including the limitations of liability set out there, except where the GDPR provides otherwise — nothing in this agreement limits either party's statutory liability under Article 82 towards data subjects or supervisory authorities.

This agreement is governed by Romanian law, with the courts identified in the Terms of Service.

This agreement takes effect for every account without a signature. If your organisation requires a countersigned copy, or requires its own template to be used, write to [email protected] and we will sign or review it. We would rather negotiate a document your data protection officer is comfortable with than hand you a page you cannot change.