Why self-hosted web analytics for government websites is a different build
An agency running dozens of department sites needs analytics that keeps visitor data inside government control, and that holds up under accessibility deadlines. Self-hosted analytics on Matomo, Plausible or Umami keeps visitor data inside the agency's own boundary, so no page tag sends browsing records to an ad-funded platform. The platform choice then depends on how many sites you run and how much reporting depth your teams need. Matomo fits multi-site rollups, because it supports many sites under one installation and offers the reporting depth that department owners usually ask for. Plausible fits smaller footprints with fewer features: its Community Edition omits several capabilities that Plausible Cloud offers, including the Sites API and single sign-on, so confirm each required feature against the edition you plan to run.
Two external factors shape that choice more than feature lists do. First, the ADA Title II rule requires state and local government web content to meet WCAG 2.1 Level AA, and the interim final rule published April 20, 2026 sets compliance dates of April 26, 2027 for entities serving 50,000 or more people and April 26, 2028 for smaller entities and special districts. Your analytics dashboards are part of the public experience that staff use to manage content, so ask whether the reporting interface itself must meet those criteria and who will test it. Second, licensing differs. Matomo's repository is GPLv3, Plausible Community Edition is AGPLv3 with community-only support, and both carry obligations that legal counsel should review before modifications or hosting for other departments. Confirm these terms against the current license files before you commit.
Start by writing down which departments need their own dashboards, which need only rolled-up totals, and who may see raw visitor logs. Those answers decide whether a single multi-site installation or separate instances fit your governance model, and they set the sizing and operations work that follows. Plan the accessibility review and the license review as part of the decision, not as a later step.
Which government rules shape the analytics build
This table maps each government rule to what it asks of the analytics hosting, access control, logging and dashboards. Read it as a starting point for conversations with your legal and security teams, since applicability depends on your jurisdiction, agency type and whether criminal justice data could reach the platform. The main takeaway is that the rule that most often changes the build is accessibility of the public-facing dashboards, followed by hosting boundary decisions.
| Rule or control reference | What it asks for | What it means for the analytics build |
|---|---|---|
| ADA Title II web rule (WCAG 2.1 AA) | State and local government web content must meet WCAG 2.1 Level AA, including content supplied through contracts. Compliance dates are April 26, 2027 for entities serving 50,000 or more people and April 26, 2028 for smaller entities and special districts. | Internal analytics dashboards that publish public reports are web content. Confirm with counsel whether staff-only dashboards are covered, and test dashboard charts, tables and exports against WCAG 2.1 AA before the dates. |
| NIST SP 800-53 Rev. 5 baselines | Low, moderate and high baselines select 149, 287 and 370 controls and enhancements respectively, as defined in SP 800-53B. Many agencies adopt these as their control reference. | Pick a baseline with your security office before design. It sets expectations for access control, audit logging, configuration management and backups for the analytics server, and it becomes the control map an assessor will use. |
| FISMA and Inspector General review | Under FISMA, Inspectors General independently assess agency system security and report to OMB. | Expect the analytics platform to be in scope of agency system inventories if it is a federal system. Keep system documentation, access reviews and change records ready for an IG sample. |
| FedRAMP scope | FedRAMP covers cloud products and services that handle federal information on behalf of an agency. Systems used only for one agency's own operations on cloud infrastructure, not offered as a shared service, are generally out of scope. | A self-hosted analytics server in the agency's own cloud account is usually a single-agency system. A vendor-hosted SaaS analytics tool is a different case and may need FedRAMP status. Confirm the classification in writing. |
| CJIS Security Policy v6.1 encryption | For criminal justice information, v6.1 requires FIPS 140-3 validated modules or FIPS 197 AES with at least 256-bit keys in transit and at rest outside physically secure locations, plus vulnerability scanning at least monthly. | Applies only if criminal justice data could enter analytics, for example through query strings on police or court service pages. Keep such pages out of tracking and confirm encryption and scanning evidence if they are not excluded. |
| Hosting location and data residency | Public bodies often require data to stay within a defined national or government boundary, and some rules add specific residency expectations. | Host the analytics server and its database inside the approved boundary, and check that CDNs, script hosts and update channels do not move visitor data outside it. |
| Records retention | Records laws and agency schedules set how long analytics data must be kept or deleted. | Confirm whether aggregate reports count as records. Configure retention and deletion in the platform to match the schedule and document the setting. |
Where government analytics can be hosted
Running Matomo, Plausible or Umami in an agency-owned data center keeps visitor data on premises under the same controls the agency already applies to its other systems. The agency holds the hardware, the network paths and the physical access records, so residency is the easiest to prove. The cost is that the agency carries every operating task itself, including patching, capacity, backups and monitoring, and those tasks need staff who know the stack.
- Residency: Data stays in agency facilities, and backups must be placed in locations the agency also controls.
- Operations: The agency's own platform or security team runs the servers, databases and web tier.
- Plausible specifics: Community Edition requires Docker, Docker Compose and a CPU with SSE 4.2 or NEON support for ClickHouse, with at least 2 GB of RAM.
- Matomo sizing: Matomo's requirements FAQ sizes a single server at 4 CPUs, 8 GB of RAM and 250 GB of SSD for up to 1 million pageviews a month.
- Documentation: Keep a system description, data flow diagram, backup location record and patch log that an auditor can trace.
Confirm with your security team whether the data center sits inside the boundary your authorization already covers, and whether it needs its own assessment.
A government cloud tenancy is an account or subscription that the agency or its contracted cloud provider controls, placed inside the government boundary and often covered by an existing authorization. It gives elastic capacity and managed infrastructure while keeping residency within approved regions. Responsibility is shared: the cloud provider runs the physical layer, and the agency or its implementation partner runs the analytics application and its configuration.
- Residency: Data stays in regions the agency names in its contract and configuration, and the agency must verify that replicas and backups follow the same rule.
- Operations: The agency or its partner manages the analytics application, databases and updates, while the provider manages the platform layer.
- Authorization: Check whether the tenancy's existing authorization covers an analytics workload added to it, and whether the provider's service is in scope for the relevant control baseline.
- Shared responsibility: Record which controls the provider inherits and which the agency must implement itself.
- Documentation: Keep the responsibility matrix, region and backup configuration, and the change record for each analytics release.
Ask the provider for its current authorization package and confirm in writing which regions the analytics data can reach.
A hosted vendor region means the analytics product runs on the vendor's infrastructure, and the agency buys a subscription. Operations are lighter, but the agency depends on where the vendor stores data and who at the vendor can access it. Matomo Cloud, for example, stores data in Frankfurt, Germany, and that location may not satisfy a sovereignty requirement for a public body. The agency must decide this with counsel before any procurement step, not after a pilot.
- Residency: The data location is set by the vendor's offering. Confirm the storage region, backup region and support access locations in writing.
- Operations: The vendor runs the platform, upgrades and capacity, and the agency manages accounts, configuration and data requests.
- Access: Ask who at the vendor can view raw visitor data, under which conditions, and how access is logged.
- Exit: Confirm how data and configuration can be exported and what happens to copies after termination.
- Documentation: Keep the vendor's data processing terms, sub-processor list, transfer assessment where relevant, and the decision record from counsel.
Set the sovereignty test before you compare prices, because a region that fails the test removes the option regardless of cost.
Which open-source analytics platform fits a government estate
Government web estates differ in department count, traffic, and identity requirements, and those differences decide the platform. The cards below compare the three options most often shortlisted for self-hosted analytics, with the checks each one needs before a department commits to it.
Matomo as the default for rollups
Matomo is licensed under GPLv3 and its latest stable release, 5.14.1, was published on October 4, 2026, with 6.0.0 in beta. It runs on PHP with MySQL 8.0 or MariaDB 10.6 or newer for version 6.0.0, and its FAQ sizes a single server for up to 1 million pageviews a month, with separate app and database servers recommended for up to 10 million. Its multi-site reporting suits department rollups. Confirm the Google Analytics importer limits before promising historical continuity, because it imports aggregated reports only and omits the Visitor Log and Segmentation.
Plausible Community Edition for lighter estates
Plausible Community Edition is licensed under AGPLv3 and runs on Docker Compose with ClickHouse, which needs a CPU with SSE 4.2 or NEON and at least 2 GB of RAM. Its v3.2.1 security release was published on May 15, 2026. The Community Edition lacks single sign-on and the Sites API, and the operator applies every security patch. It suits a single department or a small estate where SSO is not required.
Missing SSO as a common blocker
Many government identity standards expect analytics administrators to sign in through the agency's central identity provider with enforced multi-factor authentication. Plausible Community Edition does not include single sign-on, so access control falls back to local accounts that must be reviewed, disabled and logged by hand. Treat SSO as a go or no-go requirement and check it against the agency's identity architecture before shortlisting Plausible.
Umami as a lightweight option
Umami is a lightweight, self-hosted analytics option that a team may consider for a single small public site where the reporting needs are basic. Its feature set, identity options, multi-site handling and upgrade cadence should be checked against the agency's requirements rather than assumed from its general profile. Confirm its licence terms, supported database and hosting requirements in writing with the vendor or in a test deployment before selecting it.
Patching responsibility in self-hosting
Plausible Community Edition receives security fixes only when the operator applies the release, and the operator also handles installation, upgrades, capacity, uptime and backups. Matomo on-premise places the same operating duties on the agency or its partner. Agencies should write down who applies patches, how quickly, and who tests the upgrade, and should confirm that the chosen platform's maintenance model fits the agency's change control process.
Matomo's Premium plugins and consent
Matomo's Heatmap and Session Recording plugin is a paid premium plugin sold per number of users under the InnoCraft EULA, not under the GPL. Adding heatmaps or session recordings can also remove the consent exemption that France's CNIL recognizes for some audience measurement. Government sites should keep these features out of the default configuration and confirm the licence and consent position with legal counsel before enabling them.
How to roll up traffic across departments without merging data
The first design decision is whether the agency runs one Matomo instance with a separate site per department, or one instance per department. This choice sets who can see what, how totals are produced and what the audit trail looks like, so make it before any tags are deployed. A single instance with one site per department lets a central analytics team hold cross-department reporting and manage users, roles and plugins once. Its weakness is that a broad administrator role can read every site, so the agency must keep super-user accounts few and documented, and must confirm in its own environment which Matomo roles and site-level permissions meet its separation requirements. Separate instances isolate each department's database and access, which suits departments with distinct legal bases or security authorities, but every instance then needs its own patching, backups and sizing, and cross-department rollups must be assembled outside the tool.
Whichever model is chosen, the consolidation layer should carry aggregates, not visitor-level records. Ask each department to export daily or monthly summary figures for agreed metrics (visits, pageviews, bounce rate, top sections) into the central reporting store, rather than granting cross-site raw log access. Matomo's own API and reporting can serve these figures, but the agency should confirm which exports and API tokens are permitted under its policy and who issues them. Establish a written shared standard covering metric definitions, time zones, bot filtering, the naming of sites and the tag convention, for example a fixed pattern for department, service and content type in custom dimensions. Keep the convention in version-controlled documentation, and check any change to it against the audit log, since a renamed dimension silently breaks year-on-year comparisons.
Finally, record the rollup logic as part of the evidence trail. For each consolidated figure, the agency should be able to show which site IDs feed it, which definitions were in force on that date, and who changed the mapping. Review the mapping table at each department onboarding and whenever a department reorganizes, which happens often in public bodies. Plan for records retention on both sides: the department's raw data and the central aggregate may follow different schedules, so agree these with the records officer before the first export runs. Confirm with your legal and records teams how long the aggregate and the site-level logs must be kept, and whether a department that leaves the rollup must have its history transferred or archived.
How an agency rollout moves from scope to operated service
The sequence takes an agency from an agreed list of what is measured and excluded to a hosted analytics service that departments use and that operations staff can patch, back up and restore. Each step closes with a named output that the next step depends on.
Define scope and classify the data
The agency's privacy, records and web governance leads agree which sites and page types are in scope, which events and fields are collected, and which are excluded, such as form inputs, search queries containing personal details, and authenticated service pages. DeployOpen works through the list with them and records the classification of each data element. Done means a signed scope document and a data inventory that names every collected field, its purpose, and its retention owner.
Design hosting and identity inside the boundary
The team selects the hosting location, network paths and server roles inside the agency's approved environment, then designs how administrators and departmental users sign in through the agency's existing identity provider. Encryption, logging, and access reviews are specified against the control baseline the agency already uses. Done means an architecture decision record, an access model with roles per department, and a list of any external dependency that needs an approved exception.
Pilot on one department site
The platform is installed in a non-production environment and connected to one department's site, using the chosen Matomo, Plausible or Umami configuration. The pilot tests tag firing, exclusion rules, and dashboards with a keyboard-only and screen-reader pass, because the ADA Title II rule requires state and local government web content to meet WCAG 2.1 Level AA. Done means a test report listing defects, their fixes, and the accessibility findings accepted or remediated by the agency.
Onboard departments with a tagging standard
Each remaining department receives a written tagging standard covering naming of sites and goals, required and forbidden parameters, consent treatment where a banner applies, and the rules for rolling up totals across departments. DeployOpen configures the sites and rollup views, and the department owners verify their tracking on staging before go-live. Done means each department signs off on its tag inventory and the central team holds a register of sites, owners and tags.
Configure records retention and export
The agency's records schedule is translated into retention settings for raw and aggregated data, along with deletion jobs, backup retention, and an export procedure for transfers to the records team or to an archive. The team confirms with the records officer which report formats and metadata the archive accepts. Done means a retention matrix that the records officer approves and a tested export run whose output is checked against the source.
Hand over operations with patch and backup routines
DeployOpen documents the runbooks for patching, backup and restore, capacity checks, and monitoring, then runs a restore test with the agency's operations staff. The agency decides who receives security notices, who approves upgrades, and how a restore is requested. Done means a handover pack, a completed restore test, and a named operations owner who has accepted the runbooks.
Integration points that government analytics must respect
Each integration point is a place where visitor data could leave the agency boundary, or where a control can be enforced. Map every connection before the analytics server is built, and confirm which ones carry page data, identifiers or logs.
Agency identity provider for staff
Staff who view dashboards should sign in through the agency's own identity provider, not local accounts that drift out of sync. Map group membership to roles so that departmental users see only their own sites, and remove access when staff move or leave. Confirm whether the identity provider itself sits inside the boundary, and whether its logs are retained under the same rules as analytics data. Confirm the single sign-on path before go-live.
Reverse proxy and TLS termination
The reverse proxy is the first component that sees visitor requests to the collection endpoint, so its configuration defines what is recorded. Decide where TLS terminates, which headers are forwarded, and whether client IP addresses are logged at the proxy as well as in the analytics application. Agencies should check that the certificate authority and certificate chain are approved internally and that no third-party proxy or edge service sits in front of the endpoint without a documented decision.
Database and backup storage in the boundary
Pageview records, aggregated reports and backups all hold visitor data, so each store needs the same location commitment as the application. Confirm where the database runs, where snapshots and off-site copies are written, and who holds the encryption keys. Backups are often overlooked: a copy kept in a commercial cloud region or a vendor's storage can move data outside the boundary even when the live server does not. Request the storage map from the platform partner in writing.
Tag management and CDN scripts
Tag managers, CDN-hosted script files and third-party embeds are the most common leakage points on government sites. A tag container can load a script from a foreign domain, and a CDN can log every request before the analytics server sees it. Inventory every script on each page, serve the analytics script from the agency's own domain where possible, and treat any external request as a potential transfer to review. Note that a single tag added by a content team can undo the boundary design.
Historical import from Google Analytics or Search Console
Importing history from Google Analytics or Search Console can preserve year-on-year comparisons, but the import itself sends data to a third party and depends on the agency's policy. Confirm whether the agency permits that transfer before any connection is made, and record the approval. Matomo's importer only brings in aggregated reports, and Plausible's import brings in daily aggregates, so the imported history will not match raw data. Treat the import as a permitted exception, not a default setup step.
Logging to the agency SIEM
Security logs from the analytics server, reverse proxy and administrator sessions should feed the agency's security information and event management system. Agree which events are forwarded, such as admin logins, configuration changes and failed access attempts, and make sure the forwarding itself stays inside the boundary. Avoid forwarding raw visitor data into the SIEM, since that would copy personal data into a second system with its own retention. Ask the partner to show the log schema before forwarding is enabled.
What auditors and inspectors ask to see from the analytics platform
This table maps each thing an assessor or inspector typically asks for to the analytics platform component that produces it, the evidence to request, and where teams usually fall short. Read it as a checklist to build before the first review, not as a list of findings. DeployOpen prepares this evidence, but auditors and inspectors make any conclusion about whether it is sufficient.
| Evidence area | What the assessor expects to see | Where teams usually fall short |
|---|---|---|
| Data location and boundary | A diagram showing where the analytics servers, databases, backups and CDN or proxy components run, and confirmation that visitor data stays inside the government boundary | Tracking scripts or fonts still load from third-party hosts, and backups or log shipping leave the boundary without being documented |
| Admin and report role access reviews | Dated lists of who holds administrator, report-only and API roles across all departmental sites, with approval and removal records | Shared admin accounts, stale accounts from departed staff, and no review cycle for multi-site rollup users |
| Audit logs of configuration changes | Logs showing changes to tracking settings, IP handling, consent options, site definitions and user permissions, kept under the agency's log retention policy | Logs are enabled but not retained long enough, not forwarded to a central log store, or cannot show who changed a tracking setting |
| Retention settings and deletion records | The configured retention period for raw visit data and aggregated reports, plus records showing scheduled or manual deletion ran | Retention is set to a default value nobody approved, and deletion jobs are never verified or recorded |
| Accessibility test results for dashboards | Test results for the admin and public report dashboards against WCAG 2.1 AA, with defects logged and tracked to closure | Only the public website is tested, while internal dashboards used by staff and departments are left out of scope |
| Patch records for the platform version | Record of the installed platform version, the release dates of applied updates, and the process for applying security releases | Community editions receive security fixes only when operators apply them, so unpatched instances can sit behind schedule |
| Vulnerability scan evidence | Scan reports for the analytics server and its dependencies, with findings triaged, remediated or formally accepted | Scans run once at deployment and not again, or findings are closed without a recorded owner or justification |
Questions agencies ask before commissioning a self-hosted analytics build
How long does a government self-hosted analytics rollout take?
The duration depends on scope and on how quickly the agency can supply its inputs, so no fixed timeline applies to every department. The main drivers are the number of sites to be measured, whether historical data must be migrated, how many approval gates the agency's security and change processes contain, and whether the hosting environment already exists inside the government boundary. A single-site Matomo or Plausible deployment on an existing approved server moves much faster than a multi-department rollup that needs identity integration, separate roles per department and a documented retention schedule. DeployOpen agrees the timeline in writing as part of a fixed-scope engagement, so ask for the milestones, the approvals each one depends on and the agency-side dependencies that could move them.
Can our team run self-hosted analytics without an implementation partner?
Yes, a capable internal team can run Matomo or Plausible Community Edition, but the work does not end at installation. The team needs skills in the web server, database, PHP or Docker stack, backups, patching and monitoring, plus someone who owns the tracking configuration and the access model. Agencies that lack these skills in-house, or that cannot absorb on-call duty for an analytics server, often bring in a partner for the initial build and then decide whether to keep a support retainer. Assess the skills honestly against the operating tasks listed in the platform documentation, and write down who patches, who restores from backup and who answers a data subject or records request.
What does a self-hosted government analytics platform cost beyond the licence?
Matomo On-Premise Community is free to download under the GPL, and Matomo's pricing page lists it as free forever with unlimited users and hits. The licence is therefore not the main cost. The recurring and one-time costs are the server or cloud capacity inside the agency's boundary, database and backup storage, the implementation and configuration work, the internal staff time to operate and approve changes, and any paid add-ons such as the Heatmap and Session Recording plugin, which is sold under a separate EULA. Capacity needs grow with monthly pageviews, and Matomo's requirements FAQ gives sizing guidance for one million and ten million pageviews a month. Ask any vendor or partner for a quote that separates infrastructure, one-time implementation, support and staff effort.
Does Matomo Cloud meet data residency requirements for a government site?
Matomo Cloud may not meet residency rules for every government body, because its hosted data is stored in Frankfurt, Germany, and that location may fall outside the boundary your legal or policy team has defined. Whether it is acceptable depends on the jurisdiction, the classification of the data, any contractual terms and how the agency reads its own mandates. Self-hosting Matomo On-Premise keeps the server, database and backups under the agency's own control, which is why most public bodies with strict residency requirements evaluate that option. Confirm the requirement with your data protection officer and legal counsel before comparing options, and ask Matomo for its current hosting and contract terms.
How do security updates work for Plausible Community Edition?
Plausible Community Edition receives security fixes only when the operator applies a release, so the agency owns the patch cadence. Plausible's self-hosted page says the Community Edition is a long-term release published twice per year and is community supported only, while Plausible Cloud ships updates multiple times per week. A recent example is the security release v3.2.1, published on May 15, 2026, after v3.2.0 on January 26, 2026. The practical question is whether your change process can apply a security release within the time your risk policy requires. Plausible's self-hosted page also notes that the operator manages upgrades, capacity, uptime, backups and security. Agree the patch procedure and the owner before go-live.
Can analytics dashboards meet WCAG 2.1 AA for public service sites?
The analytics dashboards are internal tools, but the accessibility question still matters because staff with disabilities must be able to use them and because the ADA Title II rule covers state and local government web content. The rule, which is set out in 28 CFR 35.200, requires WCAG 2.1 Level A and AA from 26 April 2027 for entities serving 50,000 or more people and from 26 April 2028 for smaller entities and special districts. Whether a given dashboard meets WCAG 2.1 AA depends on the platform version, theme, custom reports and any plugins, so it should be tested rather than assumed. Ask for an accessibility test of the dashboards you will actually use, and record the results as evidence.
What must the agency supply before a self-hosted analytics build starts?
The agency must supply decisions and access that no implementer can make on its behalf. The main inputs are the hosting environment inside the government boundary with capacity, network rules and backup targets, the identity provider and role model for each department, a named data owner for each site, the retention schedule that applies to analytics records, and the list of sites and tracking requirements. Agencies also need a named approver for the change process and a security contact for patching. Missing inputs are the most common cause of schedule slippage, so confirm each item in writing before the fixed scope is signed.
Which federal control baseline should a government analytics system map to?
The control set depends on the jurisdiction and on whether the analytics data counts as federal information or is used by a federal program. NIST SP 800-53 Rev. 5 is the federal control catalog, and SP 800-53B defines low, moderate and high baselines that select 149, 287 and 370 controls and enhancements respectively. Under FISMA, agencies must assess their systems, and FedRAMP scope applies to cloud services that handle federal information for an agency. Analytics that runs on infrastructure used only by one agency is usually handled through that agency's own authorization process. Ask your authorizing official which baseline applies, and map the analytics system to the controls in writing.
What to ask an implementation partner before signing
Start with the boundary. Ask the partner to draw the analytics server, database, backups, log storage and any CDN or tag-manager hop on one diagram, and to say which of those sit inside the government boundary and which cross it. Ask whether the Matomo tracking script and any assets are served from your own domain, and how they prove that no visitor IP address, page URL or query string reaches a third party. Ask who operates the hosting environment, where administrative access terminates, and whether the design has been reviewed against the control families in NIST SP 800-53 Rev. 5 that your authorization process uses. Request the data flow document in writing before the scope is signed, and confirm that the partner will update it after each change.
Ask how the partner will document data flows and configuration for auditors and how they will test accessibility. Request a sample evidence pack that lists configuration exports, retention settings, role assignments, change records and backup test results, and confirm who keeps it current after handover. For dashboards, ask which WCAG 2.1 Level AA checks they run on the reports your staff and the public will use, which assistive technologies they test with, and how they handle third-party report plugins that fail those checks. Ask how retention is configured, whether raw data deletion and aggregated report retention can be set separately, and how records are exported in a form your records team accepts. Confirm the upgrade path: ask how they will move from Matomo 5.x to 6.0.0, which currently is in beta, and what regression testing, rollback and plugin compatibility checks come first.
Finally, settle support and credentials. Ask which tasks are fixed scope and which sit under a retainer, such as patching, incident response, capacity changes and report changes, and get the boundary between them in writing. Ask who holds the root, database and Matomo super-user credentials at handover, whether those credentials are stored in your own vault, and how access is revoked when staff or the partner change. Ask for a list of all accounts created during the engagement and a written statement that no partner account remains without your approval.
How DeployOpen scopes and supports government analytics
The sequence below takes a public body from an undefined analytics need to a documented, hardened and supported self-hosted platform inside its own infrastructure. Each step ends with a written output the agency can check before the next one starts.
Define the measurement scope and sites
DeployOpen works with the agency's digital team to list the sites, departments and domains in scope, the questions each team needs answered, and which pages or portals must never be tracked. Requirements on public service sites, authenticated areas and third-party embeds are recorded separately so that exclusions are explicit. The output is a written scope document that both parties sign before any design work begins, and it becomes the basis for the fixed-scope quote.
Confirm hosting boundary and governing obligations
Together with the agency's security and legal teams, DeployOpen confirms where the analytics servers will run, which accounts or data centers fall inside the government boundary, and which control baselines or assessment regimes apply. The agency confirms which frameworks govern its systems, since NIST SP 800-53 baselines, FedRAMP scope and accessibility rules each reach different parts of the stack. The output is a boundary and obligations note that names what must be confirmed with the agency's own assessors.
Select platform and edition against requirements
DeployOpen compares Matomo, Plausible and Umami against the agreed requirements, including licence obligations, feature needs such as ecommerce or campaign reporting, and whether the agency needs single sign-on or an API. Each candidate is checked against the current release and support terms published by its maintainer, and the agency is told which capabilities must be confirmed directly with the vendor. The output is a written platform recommendation with the trade-offs recorded.
Build, harden and integrate the platform
DeployOpen installs the chosen platform inside the agreed environment, configures collection to match the scope, and applies hardening to the web server, database, administrative access and logging. It connects the analytics instance to the agency's identity provider and multi-site structure where required, and it sets retention and IP handling as documented. The output is a working environment with a configuration record that lists each setting, the reason for it, and the person who approved it.
Test accessibility and collection behavior
DeployOpen checks that the analytics dashboards and any embedded reporting are operable by keyboard and screen reader, and that the tracking code does not break the accessibility of the public sites it sits on. It also verifies that excluded pages send no data and that the agency's rollup views reflect the intended sites. The output is a test record listing each check, the result and any open defect, which the agency can share with its accessibility auditors.
Document controls and prepare assessment evidence
DeployOpen writes the operating documentation: architecture, access model, backup and restore procedures, patch routine, incident contacts and data flow diagrams. It collects configuration exports, access reviews and test records into an evidence set mapped to the controls the agency has named. The output is an evidence pack for the agency's internal reviewers and independent assessors. DeployOpen does not issue audit reports, attestations or certifications, and the agency should confirm with its assessor which evidence they require.
Hand over and support through retainer
DeployOpen runs a handover session with the agency's operators and records the runbooks, escalation path and training completed. Ongoing work such as release upgrades, security patching, capacity reviews and periodic testing is offered under a separate retainer agreed in writing. The output is a signed handover record and, where the agency chooses, a retainer scope that states response expectations and what is excluded.
