Metabase usage analytics for audit logging and access reviews

The Usage analytics collection in Metabase is the activity record an auditor is most likely to ask about. It tracks dashboard and question views, queries, downloads, and administrative actions such as changing settings or inviting people. For a SOC 2 or ISO/IEC 27001 review, these entries are the evidence that access to analytics content is used and changed under control. Treat the collection as part of the logging design for your Metabase instance, alongside your identity provider and application database, and not only as a dashboard for usage trends.

By default, only administrators can view the Usage analytics collection. That setting has direct consequences for segregation of duties under CC6.3, which expects access to be granted, changed and removed by people with defined roles and reviewed on a regular basis. In many small Metabase teams, the administrators who grant access, change settings and invite users are the same people who would read the log of those actions. If that is your situation, an administrator reviewing their own changes does not give you independent review. Decide before the audit period who holds administrator rights, how many people hold them, and who reviews activity tied to each administrator's changes.

The same decision determines who prepares audit extracts. If an administrator pulls the activity records, the extract is produced by a person whose own actions appear in it, so the reviewer needs a way to confirm that the extract is complete and unaltered. Record who exported the data, when, the date range and any filters applied, and keep that record with the extract. For an open source installation, the gap is larger. Metabase documents that the Open Source Edition and the Cloud Starter plan do not collect Activity and View data, and that after an upgrade to Pro or Enterprise, logs start only from the upgrade date. Records for the earlier period cannot be rebuilt from this collection.

Before you rely on this collection as evidence, confirm the details that Metabase's documentation does not settle for your version: how long entries are retained, whether they can be exported and in what format, whether a non-administrator account can be given read access without administrator rights, and whether entries can be forwarded to your log platform. ISO/IEC 27001 control A.8.15 asks that logs be produced, stored, protected and analyzed, so an export that cannot be analyzed outside Metabase may need a separate collection step. Ask Metabase for written answers, and test an export on a staging instance before the audit window opens.

The Open Source Edition does not collect Activity and View data, so a self-hosted open source instance cannot produce the usage analytics record that a paid edition provides. Metabase's usage analytics collection covers dashboard and question views, queries, downloads and administrative actions such as changing settings or inviting people, and by default only admins can see it. On Open Source, that record is absent from the start. Upgrading to Pro or Enterprise starts these logs, but only from the upgrade date. Nothing is backfilled for the period before the upgrade, so your logging design has to assume two evidence sources for two time windows.

Consider an audit period that includes an upgrade. Usage analytics will show Metabase activity only for the portion of the period after the upgrade. An auditor testing whether access was reviewed and whether use was logged across the whole period will expect evidence covering the earlier portion as well. If the upgrade falls in the middle of the observation window, the first part of that window has no Metabase activity records inside Metabase itself. Plan for this gap in advance, document how you handled it, and agree the approach with your auditor before the period closes.

The period before the upgrade therefore needs evidence from other sources. Confirm which logs your deployment produces: the Metabase application log, the logs of the application database (PostgreSQL or MySQL if you have moved off the embedded H2 database), and the reverse proxy in front of Metabase. Each one records requests, authentication attempts or database activity at a different level of detail, so check what each actually captures before relying on it. Ask your team whether these logs are enabled, how long they are retained, and whether they are forwarded to a central store that covers the full audit period.

Decide where those logs will be stored and who can change or delete them. A log store that Metabase administrators can edit weakens the evidence, particularly for the access review under CC6.3, which depends on records of who had access and when it changed. A.8.15 asks that logs be produced, stored, protected and analyzed, so write down the retention period, who can reach the store, how integrity is maintained and how the logs are reviewed. Record the upgrade date in your own change records so an auditor can see exactly where the Metabase usage analytics record begins.

The first question an assessor asks is which report type applies, because that decides how much activity evidence they need. A SOC 2 Type 1 report describes the system and the suitability of control design as of a single date. A Type 2 report adds an opinion on operating effectiveness over a period, so the assessor must see that access reviews and log checks happened throughout the window, including the months between the start and end dates. For a Metabase install, that means dated exports of who viewed dashboards, who ran queries, and who changed settings or invited people, collected on a schedule for the whole period. Usage analytics is available only on the Pro and Enterprise plans. On the Open Source Edition and the Cloud Starter plan, Metabase does not collect Activity and View data at all, and after an upgrade to Pro or Enterprise those logs start only from the upgrade date.

The 2017 Trust Services Criteria place logical access in common criteria CC6, and CC6.3 asks the organization to grant, change and remove access to protected assets based on roles, responsibilities or system design, with least privilege and segregation of duties in mind. The points of focus under CC6.3 cover creating or modifying access, removing it, using role-based access structures, and reviewing access roles and rules. Treat these points as design aids that help you build and test the control. The criteria are the requirement the assessor tests against, and the points of focus show how to design for it. Not every point of focus has to be addressed, so document which ones your Metabase access review design covers, such as group membership reviews and admin role checks, and record the reason for any that do not apply to your environment.

ISO/IEC 27001 uses a different model. Annex A lists the controls you implement, and control A.8.15 Logging asks that logs of activities, exceptions, faults and other relevant events are produced, stored, protected and analyzed. The assessment itself is performed by an accredited certification body, because ISO does not certify organizations. The body operates to ISO/IEC 17021-1 and ISO/IEC 27006-1, and the certificate it issues can be checked in the IAF CertSearch database. A certification cycle lasts three years, and the body must carry out at least one audit in every calendar year, either surveillance or recertification. Logging and access review evidence therefore has to be ready for each annual visit, not only the first. Also confirm that your certificate references the 2022 edition of the standard, because certifications to the 2013 edition were required to expire or be withdrawn by 31 October 2025.

DeployOpen prepares the system, controls and evidence for these assessments, but it does not issue SOC 2 reports, ISO certificates or any other attestation. The service auditor or certification body reaches those conclusions. Before work starts, agree in writing with your auditor which framework version, which assessment period and which evidence formats they will accept. For SOC 2, management also provides written representations to the service auditor under AT-C section 205, so the owner of each access review must be able to stand behind the exported records. Ask the auditor early whether scheduled Metabase exports combined with your own change tickets are sufficient, and whether the assessment period includes an upgrade date that would split the activity record.