Your analytics platform is part of your attack surface

Analytics platforms are built to help organizations understand what their users are doing. Increasingly, they do much more than that: they connect behavioral data with customer context, power personalization, inform automated decisions, and provide intelligence to teams and AI systems.

To do this well, analytics needs access to valuable data. That makes analytics more than a measurement layer. It makes analytics part of your security perimeter.

A recent zero-day vulnerability affecting Metabase is a useful reminder of what that means in practice. The lesson is not that analytics platforms should be kept away from useful data, nor that any particular deployment model can eliminate security threats. The bigger question is: If your analytics platform were compromised tomorrow, what could an attacker access — and where would that access take them?

‍What the recent Metabase incident showed

In August 2026, Metabase disclosed that attackers had exploited a previously unknown vulnerability in its platform. According to Metabase, the attack allowed a threat actor to create an authenticated administrator session. From there, the attacker could browse accessible data and create an API key that enabled bulk table downloads.

The impact quickly became visible beyond Metabase itself. Australian ticket resale platform Tixel later notified users that email addresses and mobile phone numbers may have been accessed through the incident. Tixel said its website and account systems themselves had not been breached, and that passwords, payment information and purchase histories were not involved. That distinction matters. The organization's core product did not necessarily need to be compromised for customer information to become exposed. The analytics layer had become part of the path to data.

Analytics needs access. The question is how that access is designed.

When teams choose an analytics platform, most of the evaluation naturally focuses on questions such as:

• Can it answer the questions our teams have?
• Can it combine enough context to produce meaningful insights?
• Can it handle our scale?
• Can it power personalization and AI use cases?
• Can it integrate with the rest of our stack?

Those are exactly the questions organizations should be asking. Modern analytics becomes more valuable when it has enough context to understand customers deeply. An intelligence layer that knows nothing about your users, products or business can only take you so far. The security objective therefore cannot simply be: Give analytics less data. A better objective is: Give analytics the data and context it needs — within an architecture you control. That leads to a different set of security questions:

• Where does the analytics platform run?
• Does customer data have to leave our controlled environment to become useful?
• Which systems can the analytics layer access, and under what permissions?
• Who else becomes part of that trust relationship?
• If the analytics layer itself were compromised, what controls would contain the blast radius?

The issue is not access alone. It is uncontrolled access, unnecessary data movement, and trust boundaries you cannot govern.

Think about the blast radius — and the trust boundary

Imagine two ways of building an analytics and intelligence layer. In one, customer and behavioral data continually moves outside the organization's environment into external analytics systems. As more use cases are added, more datasets, integrations, vendors and subprocessors may become part of the path between raw data and useful intelligence. In another, analytics operates inside infrastructure controlled by the organization. It can still work with rich first-party behavioral data, connect that context with other relevant systems, and provide intelligence across the business — but the organization maintains control over where the data lives and how access is governed.Both architectures still need security.

Both can theoretically contain software vulnerabilities. The important difference is the trust boundary. When analytics becomes deeply embedded in your organization, the question is not simply how much data it knows. The questions are: Where does that knowledge live? Who controls it? And how many external boundaries does the data have to cross before it becomes intelligence?‍

Bring analytics to your data — not your data to another analytics silo

There is an important distinction between reducing the value of analytics and reducing unnecessary exposure. Organizations should absolutely practice data minimization where appropriate. Sensitive fields that have no analytical purpose do not need to be collected simply because they can be. But sophisticated analytics often benefits from rich context. Product behavior. Customer attributes. Experiment data. Feedback. Journey history. Operational context. Eventually, this same context can support personalization, automation and AI. The opportunity is therefore not to make the intelligence layer deliberately ignorant. It is to make it powerful without giving up control of the underlying data. That means designing analytics so it can exist as part of the organization's own data environment rather than requiring the organization to continuously export valuable customer context into another external data estate.

Reduce the attack surface without reducing the intelligence

Organizations cannot eliminate their attack surface entirely. But they can make deliberate choices about where trust exists and how data moves. For analytics, that means several things.

‍1) Keep control of the environment.Know where analytics is running, where its underlying data is stored, and which organization controls the infrastructure.

‍2) Control access, rather than avoiding access.A useful intelligence layer may legitimately need rich context. What matters is that access is governed through appropriate identities, permissions and roles rather than being unnecessarily broad or externally available.

‍3) Minimize unnecessary data movement.Every copy of customer data creates another environment that has to be secured and governed. Ask whether data needs to leave your infrastructure to generate the insight you need.

‍4) Be deliberate about integrations.Analytics should be able to connect to the systems required to produce useful intelligence. Those connections should be intentional, permissioned and understood as part of the security architecture.

‍5) Know your external trust relationships.Infrastructure providers, analytics vendors, subprocessors and integrations can all extend the security perimeter. Organizations should understand which parties have access to which parts of the environment.

‍6) Design for containment.No vendor can credibly promise that a zero-day vulnerability will never occur. Architecture should therefore consider not only prevention, but what happens after a component is compromised.

Where first-party analytics changes the equation

This is where Countly's approach becomes important. Countly is designed around first-party behavioral data. Organizations can collect and enrich product and customer data from digital touchpoints and use it for analytics, segmentation, engagement and increasingly intelligent experiences. But that intelligence does not necessarily have to live in another vendor-controlled data silo.

Countly Enterprise can run within infrastructure controlled by the customer, giving organizations control over where their analytics data is stored and how the environment connects to the rest of their technology stack. That creates a different model:
Your data.
Your infrastructure.
Your analytics and intelligence layer.

Instead of choosing between powerful analytics and control of the underlying data, organizations can bring the analytics layer closer to where their data already lives.

That becomes even more important as analytics evolves beyond dashboards. Behavioral intelligence is increasingly becoming context for AI assistants, agents, personalization models and automated customer journeys. The question will no longer simply be whether your dashboard provider can see your data. It will be whether your organization's intelligence layer can use rich customer context without that context having to leave the environment you control. That is a much bigger architectural decision.

Self-hosting is about control, not invulnerability

None of this means that software running inside your own environment cannot be compromised. The Metabase incident demonstrated precisely the opposite: self-hosted software, particularly publicly accessible deployments, can also be affected by vulnerabilities. Self-hosting does not remove the need for patching, monitoring, secure configuration, network controls and good security operations.

Control is not the same as immunity. What it gives an organization is the ability to decide where the system runs, where its data is stored, how it connects to other systems and what security controls surround it. That distinction matters.

The goal is not to build an analytics platform that has access to nothing. The goal is to build an intelligence layer with the right access, inside the right boundary, under the organization's control.

Five questions to ask about your analytics architecture today

If recent incidents have prompted you to review your analytics architecture, start here:

1. Where does our analytics and customer intelligence layer actually run?
2. What customer data leaves our controlled environment in order to be analyzed?
3. Which databases, warehouses and internal systems can our analytics layer access — and under what permissions?
4. Which vendors, subprocessors or other third parties have access to our analytics data or infrastructure?
5. If an analytics administrator or service were compromised today, what could it reach — and what would contain the blast radius?

These questions do not ask you to make analytics less useful. They ask you to make its place in your architecture explicit.

Analytics belongs inside your security perimeter

Analytics is becoming fundamental infrastructure for digital businesses. It informs product decisions, customer experiences, experimentation, personalization, engagement and increasingly AI. That evolution means analytics will likely need more context, not less.

The next generation of analytics should therefore not force organizations to choose between intelligence and control. It should let them build richer understanding of their customers while keeping that intelligence inside a security and data boundary they define. Your analytics platform is part of your attack surface. Make it part of your architecture accordingly.‍

Put intelligence where your data lives

Countly gives organizations a first-party analytics and intelligence layer that can run within their own infrastructure or private environment — allowing teams to collect, analyze and act on rich customer context while maintaining control over where that data lives and who can access it.

‍Keep the intelligence. Keep control of the data. →