Why self-hosted web analytics in a regulated financial institution is a different build
A bank, insurer or fintech can run website analytics on its own servers and keep visitor data away from ad-funded platforms, but the build is different from a marketing site. The main design risk is account, transaction and login pages, because a page URL or event that carries a customer identifier can turn ordinary measurement into a record of financial activity. The design starts with a decision on which sections are measured at all, enforced at the tag manager and the server, and tested before go-live. Matomo is the best fit for most financial sites because the supplied facts show it is licensed under GPLv3, is free to run on premises under the Community edition, and offers the exclusion and privacy controls a regulated team needs to document. Plausible and Umami are narrower options: they suit simpler public marketing sites where the feature set is small and the team can confirm each control it needs in writing.
The second design question is third-party control. Under DORA, Regulation (EU) 2022/2554, an ICT service contract must state where services are provided and data processed, and the register of information must list every contractual arrangement for ICT services under Article 28(3). An analytics platform you run yourself still has suppliers: the hosting provider, the database and web server stack, any plugin vendor and any premium add-on. Each one belongs in the register and in the exit plan under Article 28(8). Matomo's Cloud option stores data in Frankfurt, Germany, but a Cloud contract is a third-party arrangement that needs its own review, so the reader should decide early whether the platform runs in the institution's own environment or with a provider. Confirm the licence terms of every plugin before adoption, since the Heatmap and Session Recording plugin is sold under a separate InnoCraft EULA rather than the GPL.
The third design question is access. Auditors will ask who can see visitor-level data, who can change exclusion rules and who approved the change. Plan the analytics server as a system with its own role model, administrator accounts with multi-factor authentication, logged configuration changes and separate change approval for tracking rules. Matomo Community edition is documented for PHP 8 and MySQL or MariaDB, so the team should confirm the current version against its supported stack before writing the change record. Treat these controls as evidence to prepare for internal audit and for the SEC Release 33-8810 areas of access to programs and data, not as settings that an implementation partner can declare complete.
Which obligations shape the analytics build and what each means for configuration
This table maps each obligation that commonly reaches a bank, insurer or fintech analytics deployment to what it means for the analytics server, tag exclusions and admin access. Read each row as a question to answer with your compliance, legal and vendor risk teams before the build is fixed.
| Obligation | What it means for the analytics server | What it means for tag exclusions and admin access |
|---|---|---|
| DORA Article 28(3) register of information | Record the self-hosted analytics platform and any hosting, backup or support provider as ICT arrangements in the register, with the services they support. | Document which team owns the analytics admin role and which external engineers hold access, so the register matches actual access. |
| DORA Article 28(8) exit strategy | Plan how analytics data and configuration would move to another host or be retired, and test that plan on a copy of the platform. | Keep tag definitions, exclusion rules and dashboards in version-controlled form so they can be rebuilt without vendor-specific exports. |
| DORA Article 30(2) contract terms | Confirm in writing where the server and backups are located, how changes to location are notified, and how data is returned on termination or insolvency of a provider. | Ask providers to confirm that no tag, script or plugin loads from a third party outside the approved jurisdictions on account or transaction pages. |
| PCI DSS scope test for cardholder pages | Decide whether the analytics server or its tags could affect the security of the cardholder data environment. If yes, bring it into the assessed scope. | Exclude payment, card entry and checkout confirmation pages from tags and block URL parameters that may carry card or account identifiers. |
| FTC Safeguards Rule, multi-factor authentication | Require multi-factor authentication for every account that can reach the analytics server, including vendor and support accounts, unless the Qualified Individual approves an equivalent control in writing. | Apply the same rule to admin consoles, database access and backup restore accounts, not only to dashboard users. |
| SEC Release 33-8810 access and change controls (SOX scope) | Where analytics output feeds financial reporting, treat the platform as an IT general control area covering program changes, computer operations and access to data. | Require approval and logged change records for tag and exclusion changes, and periodic review of who can edit exclusions or export data. |
| Swift Customer Security Controls Framework (where relevant) | Where the analytics server sits in the Swift-connected environment, map its hosting and administration to the applicable controls and confirm the assessment scope with your Swift assessor. | Keep analytics admin workstations and jump hosts out of the Swift operator path, and document the exception if they share infrastructure. |
Which pages and data the analytics platform must never receive
Authenticated areas, account overviews, payment flows and onboarding forms should never reach the analytics platform, and the risk is rarely the page itself. Personal or cardholder data leaks through the URL path and query string (account numbers, customer IDs, IBAN fragments or card-related tokens appended to a redirect), through page titles that echo a customer name or balance, through custom variables and dimensions set by the tag manager, and through site search fields where customers type account or card details. Each of these reaches the analytics server as ordinary data, often in a field that is retained, exported and visible to every analyst with a login. Before any tag goes live, the team should inventory every template in the banking journeys and record which URL parameters, titles, variables and form fields each one exposes.
Exclusion needs to happen in two places. In the tag manager, use blocking triggers that stop the analytics tag from firing on authenticated and transaction paths, and scrub or drop query parameters and page titles through variable rules before the hit is sent. On the server side, configure the analytics platform to discard or hash sensitive fields at ingestion and to reject hits from paths that should never be tracked, so that a misconfigured tag or a new template does not bypass the browser-side rule. For Matomo, the team should confirm which settings for excluded URL parameters, IP handling and custom dimensions are available in the edition they run, since these vary by version and installation, and document the chosen configuration in the same change record as the tag rules. Testing the exclusions is a control in its own right, and it should be repeatable. Run scripted journeys through login, balance views, transfers, card controls and account opening in a test environment, then check the analytics database and logs for any hit that contains a customer identifier, card fragment or form value. Repeat the check after every template release and tag change. Because PCI DSS scope depends on whether the analytics system could affect the cardholder data environment, confirm with your Qualified Security Assessor whether the analytics platform and tag manager sit inside or outside that scope before you finalize the design, and keep the test evidence for the assessment.
Which open-source analytics platforms fit a financial institution
Matomo is the platform with the broadest feature set among the three and the most published guidance on hosting, sizing and consent. Its source code is licensed under the GNU General Public License version 3 (GPLv3), according to the LICENSE file on its 5.x-dev branch, which governs how you may modify and redistribute it. Matomo 5.14.1, released on October 4, 2026, is the latest stable version, and Matomo 6.0.0 has been in beta since September 9, 2026. Matomo 6.0.0 needs PHP 8.1 or newer and MySQL 8.0 or newer or MariaDB 10.6 or newer, while Matomo 4.16 and 5 run on PHP 8 with MySQL 5.5 or later or MariaDB.
- Single server sizing: Matomo's requirements FAQ sizes one server with at least 4 CPUs, 8 GB of RAM and 250 GB of SSD for up to 1 million pageviews a month.
- Split server sizing: For up to 10 million pageviews a month, Matomo recommends separate app and database servers with 8 CPUs and 16 GB of RAM each.
- Matomo Cloud is a vendor contract: Matomo Cloud stores data in Frankfurt, Germany, so treat it as a third-party ICT arrangement to review under DORA, not as a self-hosted option.
- Heatmap and Session Recording is paid: This premium plugin is sold per number of users under the InnoCraft EULA rather than the GPL, with a 30-day free trial.
- Consent posture changes: Matomo's ePrivacy FAQ notes that User ID, heatmaps or session recordings remove the CNIL consent exemption, so each addition changes your risk assessment.
Confirm the Matomo version, PHP and database support, and plugin set against your own requirements before you approve a design.
Plausible is a lightweight web analytics platform that many teams evaluate when they want a narrower, simpler tool. Its self-hosted deployment and its hosted offering are separate products, so confirm which one your reference architecture actually uses. Feature availability differs between them, and some capabilities that matter to a bank, such as ecommerce revenue goals, may be documented only for the hosted service. Verify the current licence terms, supported database and storage backends, and the operating components required before you rely on them in a DORA register entry.
- Scope of the tool: Assess whether the page-level and campaign reporting you need fits the product without custom development.
- Storage and operations: Confirm which database and analytics storage components a self-hosted install requires and who operates them.
- Consent treatment: Confirm with the vendor and your data protection team whether the default configuration qualifies for any consent exemption in your jurisdictions.
- Data location: Document where every component, including any CDN or script host, processes data.
- Support evidence: Ask the vendor for documented update, security fix and backup procedures for the version you plan to deploy.
Confirm each capability in writing against your requirements before selecting Plausible for a regulated site.
Umami is a simple, privacy-oriented web analytics tool that teams often choose for a small set of public marketing or information pages. It is the most minimal of the three in scope, so the decision usually turns on what you need to exclude, not on what it can add. Its reporting depth, access control options and supported hosting patterns should be checked against your own control framework rather than assumed from its positioning. Because a financial institution must show which pages are measured and which are excluded, the tag configuration and page scope matter as much as the product itself.
- Page scope control: Confirm that you can exclude account, login, transaction and application pages from tracking, both in the tag and on the server.
- Identity and access: Confirm how administrator accounts are created, how roles are restricted, and whether single sign-on with your identity provider is supported.
- Retention settings: Verify how long raw event data is kept and whether you can set retention to match your records policy.
- Consent and identifiers: Confirm whether the default configuration sets cookies or stores identifiers, which affects consent analysis.
- Logging and evidence: Check what audit logs the platform produces for administrative changes and whether they can be exported to your security monitoring.
Confirm each capability with the maintainers and in a test environment before you put Umami on a production financial site.
How a financial institution should roll out analytics in phases
The sequence moves analytics from agreed data rules to a controlled production launch and then to retained evidence, so each phase closes with a record a risk, compliance or audit owner can check. Timing follows the written scope for each engagement, not a fixed duration.
Scope and map the data with privacy and security
Agree the business purposes for analytics, the sites and subdomains in scope, and what each tracked field would contain. Privacy, security and the business owner sign off on a data map that lists every event, identifier and page type. Done means each item has a stated purpose, a retention owner and an approver, and any page touching accounts, transactions or cardholder data is flagged for exclusion before any code is written.
Review vendor, hosting and contract terms
Confirm where the platform and its backups will run, which sub-processors or CDNs touch traffic, and how updates reach the server. Map the arrangement to the ICT register and exit planning expected under DORA, and confirm the contract states processing locations, notice of changes and data return on termination. Done means the risk function has a written decision and the register entry is updated.
Build in a non-production environment
The implementation partner installs the chosen open-source platform, database and web server in a separate environment that mirrors production controls, with no live visitor traffic. Configuration is kept in version control so each change can be reviewed and reproduced. Done means the build is documented, the baseline configuration is signed off, and the production deployment plan references that exact version.
Test exclusions against an agreed page inventory
Crawl the agreed page inventory in the test environment and confirm that account, login, transaction, payment and sensitive form pages send no tracking data. Include tag managers, embedded third-party scripts and query strings in the test. Done means every page on the inventory has a recorded pass or fail result, failures are fixed and retested, and the signed test report is stored with the change record.
Configure access and logging
Set up role-based access for administrators, analysts and auditors, connect the platform to the institution's identity provider with multi-factor authentication, and enable audit logs for administrative actions, configuration changes and data exports. Confirm that log retention and log review follow the institution's policy. Done means an access review has been completed and the logs are forwarded to the security monitoring tool.
Run a controlled go-live
Release the tracking to a limited set of low-risk public pages first, watch for unexpected data on each page type, and only then extend to the full inventory. Keep a tested rollback step ready. Done means the production deployment matches the approved configuration, the exclusion checks pass on live pages, and the go-live decision is recorded with its approver.
Collect post-go-live evidence
Schedule recurring exclusion scans, access reviews, backup restore tests and patch records, and keep them with the data map and test reports. Re-run the exclusion checks after each site release or tag change. Done means an evidence pack exists that an internal or external auditor can follow from requirement to configuration to result, with a named owner for each recurring check.
Integration points and deployment patterns for regulated analytics
A bank's analytics platform touches its identity provider, security monitoring, backup estate, hosting footprint and tag governance, so each connection needs an owner and evidence before go-live. The cards below set out what the bank must confirm with its own architecture team and its ICT third-party register.
Identity provider integration for administrators
Administrator access to the analytics server is one of the controls auditors test first, so logins should run through the bank's central identity provider rather than local accounts. Confirm that Matomo administrator roles map to groups your identity team already reviews, that multi-factor authentication is enforced at the provider, and that leavers lose access on the same cycle as other privileged systems. Check whether the vendor's supported single sign-on method works with your provider before the design is fixed.
SIEM log forwarding
Web server, application and database logs from the analytics platform should reach the bank's security information and event management system so administrator changes and failed logins appear alongside other critical systems. Confirm which log sources the platform writes, whether they can be shipped without an outbound connection to a third party, and who owns the detection rules. Log retention in the SIEM should match the bank's incident response and records policy, not the default of the analytics tool.
Backup and tested restore
Backups of the analytics database and configuration must be encrypted, stored in an approved location and restored on a schedule the bank actually tests. A backup that has never been restored is not evidence of recovery. Confirm the recovery point and recovery time the business accepts for analytics data, who performs the restore test, and where the restore results are recorded. Under DORA, the exit and data return terms in the vendor contract should also cover what happens to backups if the provider or the platform is replaced.
Hosting in an approved jurisdiction
DORA Article 30(2) requires every ICT services contract to state where services are provided and data processed, and to give advance notice of changes. For a self-hosted analytics platform, that means naming the data center, cloud region and any backup location, and confirming that support staff and remote access do not move data outside approved jurisdictions. Ask your hosting team to document the physical and logical boundary, and check whether any CDN or tag script still loads from outside it.
Tag manager governance
Most analytics data reaches the server through a tag manager, so anyone who can publish a container can add a tracker to an account or payment page. Governance means a named approver for each tag, a change log, and a review that confirms no tag fires on pages excluded from collection. Confirm who can publish, whether production and test containers are separated, and how changes are traced back to a ticket. This control also supports the bank's wider change management evidence.
Separation of app and database servers
Matomo's published sizing recommends separate application and database servers once traffic reaches the higher tiers, which also limits the blast radius of a compromise. Confirm that the database accepts connections only from the application tier, that each tier is patched and monitored separately, and that the bank's network segmentation standard covers both. The sizing figures apply to traffic volume, so confirm your expected monthly pageviews with the vendor before choosing a topology.
Evidence auditors and supervisors ask for from the analytics platform
This table lists the records a bank, insurer or fintech should be able to produce for its self-hosted analytics platform, the component or team that generates each one, and what a reviewer usually checks. Use it to plan evidence collection before an assessment, not after. DeployOpen prepares systems, controls and evidence for assessments, but does not issue audit reports or attestations; independent auditors and supervisors make those determinations.
| Evidence item | What it shows | Produced by | Where reviewers usually find gaps |
|---|---|---|---|
| DORA register entry for the analytics platform | The platform is recorded as an ICT service arrangement with its provider, hosting location and function supported | Third-party risk team, using the contract and architecture records | Platform missing from the register because it was treated as a marketing tool |
| Contract clauses on location and data return | Where analytics data is stored and processed, advance notice of changes, and data return on termination or provider insolvency | Procurement and legal, with the implementation partner's written scope | Hosting location stated only in a sales deck, or no return clause for hosted or partner-run instances |
| Documented exit strategy and transition plan | How historical data, reports and tracking code would move to another platform or back in-house | Platform owner with the implementation partner, tested as a runbook | Plan exists on paper but has never been exercised against an export |
| Excluded URL patterns with test results | Account, login, payment and transaction pages are not tracked, and the rules were checked against live pages | Analytics administrator and tester, with logs from the tag manager and collection server | Patterns defined but no dated test showing that a sample of protected pages sends no hits |
| Administrator access records | Who holds admin, export and raw data rights, when access was granted, reviewed and removed, and whether MFA applies | Identity provider logs and the platform's own user and role audit log | Shared admin accounts, stale accounts from former staff, or no quarterly review sign-off |
| Change log for tags and configuration | Each tag, rule, filter, or setting change with date, author, reason and approval | Version control or change ticketing for the tag container and platform configuration | Changes made directly in the admin interface with no approval trail |
| Retention settings and deletion evidence | Configured retention periods for raw visits and aggregated reports, and proof that older data is removed on schedule | Platform configuration export and scheduled job or database logs | Retention set in policy but raw data kept indefinitely in the database or backups |
| Backup and restore test records | Backups run on schedule, are encrypted, and a restore was tested with the result recorded | Operations team, with backup tool reports and a dated restore test | Backups exist, but no restore has ever been tested or the restored copy was never checked |
What banks and fintechs ask before hiring an implementation partner
What drives the cost of self-hosted web analytics for a bank?
The cost has four parts: the software, the hosting, the implementation and the ongoing operation. Matomo On-Premise Community is listed as free forever on the Matomo pricing page, so the licence line is often zero, but the other lines are not. Hosting depends on traffic and on whether you run one server or split application and database servers. Implementation covers tag governance, exclusion rules for account and transaction pages, data residency review and access setup. Ongoing costs include patching, backups, monitoring and staff time for reviews. Ask any partner for a quote that separates one-time work from recurring retainers, and that states which items are excluded from the fixed scope.
How long does scoping and building a compliant analytics setup take?
The duration depends on the number of sites and portals, the number of authenticated areas that must be excluded from collection, how many vendors and hosting regions are involved, and how quickly your internal reviewers respond. A single public marketing site with a clear exclusion list moves faster than a banking estate with mobile web views, multiple brands and a separate customer portal. Scoping should produce a written list of pages, events and parameters that are blocked, and a decision record for each. Fixed-scope agreements set the timeline in writing before work starts, so ask for the schedule with the named review gates.
What must our internal team provide before the partner starts?
Four internal owners are usually needed. Privacy must confirm the purposes, retention periods and whether any consent banner is still required. Security must approve hosting, administrator access, logging and the encryption standard. Network or cloud teams must provide the server location, outbound rules and backup targets. Tag owners must list every container, script and vendor tag on the site, including those added by marketing agencies. Without these inputs, the partner cannot define the exclusion rules for account and transaction pages, so ask for a written RACI before signing.
Can our compliance team run a self-hosted analytics platform alone?
A compliance team can own the policy, risk and evidence side, but it usually cannot run the platform alone. The work includes server administration, database maintenance, software upgrades, access reviews and tag configuration, which sit with platform engineering. Compliance should set the requirements, approve the exclusion list and hold the evidence. Many firms split the work: the internal team operates the platform and the partner covers the initial build, hardening, documentation and optional retainer support. Ask the partner which artifacts it prepares for assessors and which ones your team must sign.
How does a DORA vendor review affect the project schedule?
DORA requires financial entities to maintain a register of information on all contractual arrangements for ICT services, and Article 30(2) requires each ICT services contract to state where services are provided and data is processed. If the analytics provider is a third party, your vendor risk review must cover those terms, exit planning and data return before go-live. Under Article 28(8), exit strategies must be documented and tested for ICT services that support critical or important functions. Ask the partner to provide hosting locations, sub-processor details, a data return method and the documentation your register needs, so the review does not stall the build.
What happens to our analytics data when we exit the engagement?
Exit should be defined in the contract before the build starts. Ask the partner to state who holds administrator credentials after handover, how the database and configuration are exported, and in which format historical reports and raw data are returned. The exit plan should also cover backups, the deletion schedule for any copies, and removal of tags from your sites. Because DORA Article 30(2) covers data return on termination of the provider, your contract should describe it in writing. If you plan to move between Matomo editions or hosting models later, confirm which data formats and export options the platform supports.
Which access controls will auditors expect on the analytics platform?
Auditors usually look for named administrator accounts, multi-factor authentication for any individual accessing the system, role-based permissions, logged changes to tracking configuration and periodic access reviews. The FTC Safeguards Rule requires multi-factor authentication for any individual accessing an information system, unless the Qualified Individual approves an equivalent control in writing, if your entity falls under that rule. Ask the partner to show how the platform's roles map to your identity provider, how privileged access is logged, and which change records you can export for an audit trail.
What to ask an implementation partner before signing
The answers to these questions belong in the written scope, not in a sales call. Ask the partner to state, in the signed scope document, which paths are excluded from tracking (account, login, transaction, payment and statement pages), how each exclusion is implemented in the tag or server configuration, and which items are explicitly out of scope, such as the CDN, tag manager or third-party widgets. Ask who signs off on the exclusion list and how changes to it are approved after go-live. Fixed-scope work only protects you if the exclusions, deliverables and acceptance tests are written down before work starts.
Ask how the partner has handled DORA Article 30(2) contract content for ICT services, including where services are provided and data is processed, notice of changes, and data return on termination. Ask them to confirm they can supply the information your team needs for the register of information under Article 28(3) and for a documented, tested exit strategy under Article 28(8). Ask what they will hand over for the exit plan: configuration exports, data export procedures and a tested restore into a second environment. Confirm in writing who maintains each record after go-live, since the register is your obligation, not the partner's.
Ask about upgrades before you commit to a version. Matomo 6.0.0 was in beta at the time of writing and requires PHP 8.1 or newer and MySQL 8.0 or newer or MariaDB 10.6 or newer, so the move from Matomo 5 may involve database and runtime changes. Ask for a documented upgrade procedure, a staging test that re-checks the exclusion rules and consent settings, and the support terms that apply after go-live, including who patches the operating system and database. Finally, ask whether the partner tests the exclusions independently of the team that built them, and what evidence the test produces for your auditors. DeployOpen's security testing practice can be scoped this way, but confirm the exact test scope, method and deliverables in your own written agreement.
Official sources for the rules behind this page
Where can I read the text of DORA that applies to financial entities?
The authoritative text of DORA, Regulation (EU) 2022/2554, is published on EUR-Lex, the EU's official legal database. Read Article 28 for the register of information and exit strategies, Article 30 for contract terms on data location and return, and Article 2 for the list of financial entities in scope. DORA has applied since 17 January 2025 and is directly applicable in all member states, so your national supervisor will expect you to work from the Regulation itself. Confirm with your own legal or compliance team how your entity type and any national guidance apply to your analytics vendors.
- DORA on EUR-Lex
- Check how your analytics hosting provider appears in your ICT third-party register.
Which Matomo requirements should my infrastructure team check first?
Start with Matomo's requirements FAQ for On-Premise installations, which lists the supported PHP, database and web server versions for each release line. Matomo 6.0.0 needs PHP 8.1 or newer and MySQL 8.0 or newer or MariaDB 10.6 or newer, while the 5.x line runs on PHP 8 with MySQL 5.5 or later or MariaDB. The same FAQ gives sizing guidance for a single server and for separate app and database servers. Confirm the current stable and beta versions against the changelog before you pin a release, because Matomo 6.0.0 was still in beta when these facts were gathered.
- Confirm the database engine and version your security baseline permits.
- Plan sizing against your expected monthly pageviews, not today's traffic.
What does Matomo's ePrivacy guidance say about consent exemptions?
Matomo's ePrivacy FAQ explains that some national regulators, including France's CNIL, exempt certain audience measurement tools from consent when they only serve performance measurement, collect anonymous statistics and exclude marketing measurement. The same FAQ names France, Italy, the Netherlands and Spain as authorities with such exemptions and suggests following the CNIL configuration in the other three. Adding User ID, heatmaps or session recordings removes the exemption. Treat the FAQ as a vendor summary, then confirm the position with your data protection officer and the regulator in each market where you operate.
- Record which features are enabled for each country's site.
- Keep consent logs tied to the configuration in force at the time.
Which PCI DSS documents show whether my analytics setup is in scope?
The PCI Security Standards Council publishes the PCI DSS standard and its supporting documents on its standards page. The standard applies to entities that store, process or transmit cardholder data, or that could affect the security of the cardholder data environment, which includes merchants, processors, acquirers, issuers and service providers. A tracking script on a payment page can bring analytics into scope, so check every page that handles card data. The Council does not enforce compliance; your payment brands decide who must validate. Current guidance is PCI DSS v4.0.1, which replaced v4.0 at the end of 2024.
- Ask your QSA whether analytics tags on checkout or payment pages affect scope.
- Keep the standard's own wording as the reference, not summaries.
Where do I find the Swift Customer Security Programme controls for my institution?
The Swift Customer Security Programme publishes its control framework and the requirements for independent assessment and annual attestation on its own pages. The Swift Customer Security Controls Framework v2026 has 32 controls, of which 26 are mandatory and 6 are advisory. Swift users must have the controls independently assessed and attest compliance each year in the KYC-SA application. Read the controls directly from the Swift pages, because your attestation scope depends on your architecture. If your analytics platform sits near Swift-connected systems, confirm with your assessor whether it falls inside the scope of your local environment.
- Check whether any analytics component runs on the same network segment as Swift infrastructure.
- Record the control reference for each safeguard you rely on.
How should I read the Matomo Google Analytics import limits?
Matomo's FAQ on Google Analytics import limitations explains what the importer can and cannot carry over. It imports only aggregated report data, not raw visit and action data, so the Visitor Log, Ecommerce Log, Custom Reports and Segmentation do not work for imported reports. Some reports, such as Funnels, are not imported at all. For a regulated organization, this matters when auditors ask for a complete record of historical measurement. Document what was imported, what was not, and where the original data was retained under your records policy.
- Decide whether aggregated history meets your reporting needs.
- Keep the source export under your retention policy.
Where can I find the Matomo licence and edition terms before I deploy?
Matomo's LICENSE file on its GitHub repository states the GNU General Public License version 3 for the core product, and the pricing page describes the On-Premise Community edition. Some add-ons, such as the Heatmap and Session Recording plugin, are sold under a separate commercial licence with its own terms. Read the license on the branch that matches your release, and check each plugin's listing before you install it. Confirm with your procurement or legal team which terms apply to your deployment model and any support contract.
- Inventory every plugin and its license before go-live.
- Confirm whether a commercial plugin changes your consent position.
Which official source should I use to check where analytics data is hosted?
Your own contracts and architecture diagrams are the primary source for data location, because DORA Article 30(2) requires every ICT services contract to state where services are provided and data processed. Use the regulation text on EUR-Lex to confirm the contract clauses you need, and use the Matomo pages for the product requirements that affect hosting, such as the supported database and server versions. If you use a hosted Matomo service instead of your own servers, check its stated data location in the contract, not only on the marketing page. DeployOpen implements and documents self-hosted platforms inside your own cloud accounts, data centers or air-gapped networks, so the hosting location is set by your architecture.
- Map every server, backup and support connection to a named location.
- Confirm that backups and logs follow the same location rules.
How DeployOpen scopes, builds and supports analytics for regulated financial teams
DeployOpen is a Chainscore Labs company that plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, whether that is a cloud account, a data center or an air-gapped network. For a bank or fintech, that means the Matomo server, its database, the tag configuration and the exclusion rules for account and transaction pages are built in the environment your security team already governs, not in a vendor's shared tenancy. Most engagements are fixed-scope, so the scope, deliverables and timelines are agreed in writing before work starts. Before signing, confirm in the statement of work which exclusion rules, which hosting boundary, which identity provider integration and which retention settings are included, and which are left to your team.
The written deliverables should map to the evidence your assessors will ask for. DeployOpen prepares systems, controls and documentation for compliance assessments, such as the configuration baseline for the analytics server, the access model for administrators and read-only analysts, the register entry for the hosting provider and the tested procedure for restoring data. DeployOpen does not issue audit reports, attestations or certifications, and that boundary matters: your internal audit, your external auditors and the competent authority make those judgments. Security testing of the analytics deployment, including the web tracking layer and the administrative interface, can be scoped separately so that findings are documented and retested before go-live.
Operations after go-live are usually where regulated teams lose control of an analytics platform, through unapplied patches, drifting configuration and tracking tags added by marketing without review. Ongoing support, upgrades and continuous testing are available as retainers, which keep the platform on supported releases and keep the exclusion rules under change control. Ask any implementation partner, DeployOpen included, to state in writing who approves tag changes, how upgrade windows are scheduled, how backups are verified and what happens to the data and configuration at exit. Those answers feed directly into your DORA contractual and exit planning, so they belong in the proposal rather than in a later email thread.
