Self-hosted web analytics for GDPR and ePrivacy consent

The record of processing is a written entry the controller keeps under the GDPR, describing the purpose of the analytics, the categories of data collected, the recipients, the retention period and the security measures. For a self-hosted Matomo, Plausible or Umami deployment, the entry should name the analytics server, its hosting location and the tracked data fields, such as page URL, referrer and truncated IP address. Your team writes the entry, but the platform configuration supplies the facts it describes. Confirm each field against the live tracking script and the database schema, not only the design document, because plugins and tag managers often add fields later.

Auditors expect a documented lawful basis for each analytics purpose, plus consent records wherever consent is the basis. Where a regulator accepts a consent exemption for privacy-focused measurement, the assessment should show that the configuration stays within the exempt purposes, collects only anonymous statistics and excludes marketing measurement. The Matomo FAQ on the ePrivacy Directive notes that features such as User ID, heatmaps or session recordings remove that exemption, so the assessment must list which features are switched off. If a consent banner is used, the consent management tool produces the timestamped records. Confirm the position with your supervisory authority or counsel for each country where you operate.

Auditors want a retention setting that is written down, applied in the platform and provable from an export. Retention in self-hosted analytics is usually a configuration value for raw data plus a separate rule for aggregated reports, so both must be recorded. Export the current settings from the admin interface or configuration files, keep the export with a date and the change history, and run a test that confirms older raw records are removed. For Plausible Community Edition, the data store is ClickHouse, so retention checks run against that store. Ask your implementation partner to document which setting controls which data, and to show the deletion job logs.

A data protection impact assessment is required under the GDPR only where processing is likely to result in a high risk to individuals, so the first step is a documented screening decision. The screening should cover the data categories, the tracking scope, any profiling, the use of third-party scripts and whether the analytics is combined with other datasets. A privacy-focused setup with truncated IP addresses, no cookies and no cross-site identifiers usually produces a lower-risk screening result, but that result must be reasoned and signed by the controller, not assumed. Your data protection officer owns the decision. The DPIA itself, if needed, is written by the controller with technical input from the platform team.

A transfer assessment is needed for any external service that receives personal data from visitors, even when the analytics server itself is self-hosted in the EU. Typical examples include a content delivery network that serves the tracking script, a font or video plugin, or an import connector that calls an outside API. For each one, record the processor, the data sent, the country of processing and the transfer mechanism relied on under Chapter V of the GDPR. Where the data goes to the United States, the EU-US Data Privacy Framework decision is one mechanism to check. The evidence is a list of external requests from the live site, matched to the contracts and assessments for each.

Access review logs show who holds administrator and viewer rights to the analytics server and dashboards, when those rights were last confirmed, and what changed. Keep a current user list with roles, a review record signed by a named owner, and logs of logins, role changes and data exports from the platform. Matomo and Plausible each record different audit detail, and some of it depends on your reverse proxy, database and operating system logs, so confirm the exact events each product and layer records. Central logging and single sign-on, where supported by the edition you run, make the review faster. Ask your partner to define the review frequency in the written scope.

Patch records are dated entries showing which release was installed, when a security advisory was published, and when your team applied it. For Plausible Community Edition, the project states that security fixes reach you only when the operator applies the release, so the patch log is central to the evidence. A recent example is the v3.2.1 security release published on May 15, 2026. Keep the release notes, the change ticket, the deployment log and a post-update check for each update. Also record the Matomo, database and operating system versions, since Matomo 6.0.0 has its own PHP and database minimums that differ from 5.x. Confirm the support window for your chosen release line before you plan updates.

A breach response runbook sets out how your team detects, assesses and reports an incident involving the analytics server. Under the GDPR, the controller must assess a personal data breach and, where required, notify the supervisory authority and affected individuals within the time limits in Articles 33 and 34. The runbook should name the owners, the alerts that trigger it, the steps to isolate the server and preserve logs, and the contacts at the data protection office. For an analytics stack, it should also cover the tracking script, which an attacker could modify to collect more data than intended. Test the runbook with a tabletop exercise and keep the record of that test, since auditors ask for proof of practice, not only a document.

The total cost is the sum of infrastructure, software licensing, configuration and documentation work, and recurring operations. Software is often free: Matomo On-Premise Community is listed as free forever, and Plausible Community Edition is AGPLv3 licensed. The larger lines are servers, the staff time to install and tune the platform, and the legal and security review that decides which features are switched on. Each feature you add, such as heatmaps or session recording, adds licensing cost and can also remove a consent exemption, which raises the work. Ask any quote to split one-time setup from recurring upkeep, and to list which features are in scope.

Yes, a capable internal team can install and run either platform, but the work is wider than the software install. The team needs skills in Linux server administration, database operations, backups, patching and TLS, plus enough privacy knowledge to set IP anonymization, retention and consent settings correctly. Plausible's self-hosted page notes that Community Edition operators manage installation, upgrades, capacity, uptime, backups and security themselves, and that security fixes arrive only when the operator applies a release. Teams with thin platform capacity often bring in a partner for the initial build and documentation, then keep upkeep in house. Decide this on the staffing you can sustain for years, not only the first month.

Duration depends on the platform, the number of sites, the features in scope and how much evidence the organization needs to keep. Installation itself is usually the shortest step. The longer work is deciding the lawful basis, writing the configuration record for IP handling, retention and cookie behavior, testing that tags fire only as designed, and writing the runbook for upgrades and incidents. No fixed timeline is given here because it varies widely by environment. Ask any partner to state effort and duration in the written scope, with the deliverables named, before work starts.

Legal and privacy teams decide the lawful basis for analytics, whether a consent banner is still needed, and how the configuration fits the organization's records of processing. Security teams review hosting location, access control, encryption, logging, vulnerability patching and the security of processing duties in Article 32 of the GDPR. Both groups should sign off on the same written configuration, because a change such as enabling User ID or a session replay plugin can alter the analysis. The GDPR is enforced by national supervisory authorities, and their guidance differs by country, so legal review should check the authority in each market where you operate.

Using a hosted service does not remove your obligations as controller. It changes who operates the system and where the data sits, so the contract, transfer documentation and processor terms must be reviewed. Matomo states that Matomo Cloud data is stored in Frankfurt, Germany, and that Cloud plans start at 29 per month excluding tax for tiers from 50,000 to 10 million hits. Plausible's homepage describes its service as made and hosted in the EU, using no cookies. Verify the processor agreement, subprocessors and data location in writing with the vendor. Self-hosting keeps the data in your own infrastructure, but then you carry the operational duties yourself.

Historical data can be imported, but the result is aggregated, so it will not match raw visit data. Matomo's Google Analytics Importer is free under GPL v3 or later and imports aggregated report data only, so the Visitor Log, Ecommerce Log, Custom Reports and Segmentation do not work for imported reports, and some reports such as Funnels are not imported. Plausible's documentation says it imports historical GA4 stats as daily aggregates up to the first native Plausible visitor, supports up to 5 GA properties per site, cannot import ecommerce revenue, and approximates unique visitors by summing daily uniques. Before importing, decide whether old data is needed at all, since keeping it extends retention and needs its own justification.

Start by confirming the request, then search the analytics platform for any identifiable records, which may be limited if you have set IP anonymization and avoid storing user identifiers. Aggregated, anonymous statistics usually contain no personal data to return, so the response should explain that clearly and cite the configuration. Where identifiable data exists, such as a User ID or a session record, export or delete it within the deadlines set in the GDPR and document the action. Make sure the team knows where each platform's data lives, including backups, which can complicate erasure. Test this process before a real request arrives, and confirm the exact steps with your privacy team and implementation partner.

Test the features that most affect compliance before the site goes live. Confirm that the tracking script loads only where intended, that no identifiers are sent when consent is declined where a banner applies, and that IP addresses are truncated or anonymized as configured. Check retention periods by inspecting the stored data and the backup schedule. Verify that heatmaps, session recording and User ID are disabled unless the legal review approved them. Keep the test results as evidence. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors and certification bodies issue any audit report or certification.