Embedded analytics requirements checklist

A practical checklist for choosing and building embedded analytics with open-source platforms, covering who sees the dashboards, how tenant data is isolated, licensing for distribution and how to verify each requirement.

On this page

How to use this embedded analytics requirements checklist

If your team must put dashboards in front of staff, customers or partners, the first decision is not which tool to install. It is what the tool must do for each audience. Before you choose Apache Superset, Metabase or a commercial embedding product, write down who sees the dashboards, how each viewer's data is isolated, how they sign in, and under what license you may distribute the software. This checklist turns those questions into requirements you can test against a shortlist.

The checklist is organized into five groups: functional, security, integration, operational and compliance requirements. Each requirement carries a verification step, such as a test login with a second tenant's account, a query log review, a restore test on a spare cluster or a license read-through by counsel. A requirement without a verification step is a wish, so treat it that way during evaluation. Where a plan tier determines whether a feature exists at all, as with SSO and row-level permissions in some Metabase plans, confirm the tier in writing before you score the tool.

DeployOpen plans, implements, integrates and hardens self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks, and it runs security testing against the result. It prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations, so use this checklist to decide what evidence to collect, not to claim that an assessment has been passed.

Functional requirements for embedded analytics dashboards

This table lists the functional requirements an embedded analytics platform must meet, why each one matters and how to verify it before you commit. Use the verification column to build a proof of concept with a real dashboard and a tenant-specific data set. The main takeaway: several controls that matter most for customer-facing dashboards sit in paid Metabase tiers, so test them on the edition you plan to run.

RequirementWhy it mattersHow to verify
Audience and user typesStaff, customers and partners need different permissions, branding and login paths. Mixing them in one workspace is a common source of data exposure.List each audience, its login method and what it may see. Confirm the platform supports separate user types or embedding identities for each.
Dashboard authoring and self-serviceInternal analysts may need to build questions without developer help, while external viewers should only see published content.Ask a business user to build a chart on a test data set. Confirm that external viewers cannot edit or browse other dashboards.
Filters and drill-downFilters that a user can change may expose rows they are not entitled to. Drill-down can bypass aggregates if it reaches raw records.Test each filter and drill path with a restricted account. Confirm that drill-down respects the same row limits as the parent dashboard.
Tenant isolation and row-level securityRow-level and column-level permissions are what keep one customer's data out of another customer's view.Run the same dashboard under two tenant identities and compare results. Confirm row and column permissions are available on your Metabase tier, since they are listed only in Pro and Enterprise.
Single sign-on and guest tokensCustomer portals usually need the portal's identity to drive dashboard access. Guest tokens and SSO configurations differ in how they pass that identity.Confirm the login flow with a test identity provider. For Metabase, check that JWT, OIDC or SAML are on your plan, since they require Pro or Enterprise.
Theming and white-labelingCustomers may expect dashboards to match the product's brand. Branding changes can also be restricted by license terms.Apply the target brand to a sample dashboard and review it with marketing. Check the license terms before removing any vendor branding.
Embedding modesIframe, SDK and full-app embedding differ in control over layout, navigation and session handling.Build one dashboard in each mode you plan to use. Confirm session expiry and access revocation behave as your security team expects.
Data sources and query performanceHeavy queries against production databases slow the product and can expose operational data to dashboard users.Run the slowest planned dashboard against a production-sized copy. Confirm whether a separate analytics database or replica is part of the design.
Usage analytics and auditCustomers and internal reviewers may ask who viewed which data and when. Usage data also informs capacity planning.Request a sample audit log export. For Metabase, confirm usage analytics and auditing are included in your plan, as they are listed only for Pro and Enterprise.

Security requirements that decide tenant isolation

In embedded analytics, most cross-customer data exposure happens at the boundary between the product's identity, the embedding token and the database account. The cards below cover the controls that must hold at that boundary and the test that proves each one.

Row-level security at the data layer

Tenant filters must be enforced by the database or the BI platform's permission model, not only by a filter added to the dashboard URL. Ask the implementation partner where the filter lives for each dataset and whether a user can remove it through the interface or the API. Test it by logging in as tenant A and attempting to query tenant B's identifiers through every chart, filter, download and export path.

Signed embedding and guest tokens

Each embedded view should carry a server-signed token that names the tenant, the dashboard and the allowed parameters, with a short expiry. Confirm which signing method and key length the chosen platform uses and who holds the signing key. Test it by altering the tenant parameter in a valid token, replaying an expired token and requesting a dashboard the token does not name.

SSO with group-to-role mapping

For staff portals, the platform should sign users in through the organization's identity provider over OIDC, SAML or OAuth2, and map groups to roles automatically. Superset maps LDAP or OAuth groups to roles through AUTH_ROLES_MAPPING. Metabase limits JWT, OIDC, SAML and SCIM to its Pro and Enterprise plans, so confirm the plan before design. Test it by removing a user from a group and checking that access ends at the next login.

Secret and key rotation

Superset refuses to start without a user-specified SECRET_KEY, and it supports rotation through PREVIOUS_SECRET_KEY. Store that key, database credentials and signing keys in a managed secret store, not in configuration files in the repository. Test rotation in staging: confirm sessions and stored credentials still work during the overlap window and that the old key is removed afterward.

Least-privilege database accounts

The BI platform should query the analytics store through a read-only account scoped to the required schemas, never through an administrator or the production transactional database. ClickHouse supports access control and external authenticators such as LDAP and JWT, which helps keep each service account narrow. Test it by running write and DDL statements from the BI connection and confirming they are rejected.

Audit of who viewed what

Isolation needs evidence. Record which user or tenant opened which dashboard, which filters applied and which queries ran, and keep those records outside the BI application's own database where possible. Usage analytics and auditing are part of Metabase's Pro and Enterprise plans, so confirm that tier before committing. Test it by opening a restricted dashboard as one tenant and checking that the log shows the tenant, the dashboard and the filter values.

What license terms mean when you ship dashboards to customers

The license question decides whether you can ship dashboards to customers at all, so settle it before you choose a tool. Apache Superset is licensed under Apache-2.0 and has no paid edition, which means the code itself carries no commercial license fee. Metabase works differently: its open source edition is licensed under the AGPL outside its enterprise directory, while its commercial editions use the Metabase Commercial Software License. Those two licenses create different obligations, and the difference matters most when you modify the software, distribute it to customers or partners, or run it as a service for third parties.

Distribution, modification and hosting for third parties can each trigger different obligations. Ask counsel to map three things in writing: whether you distribute copies of the software or only give customers access to a hosted page, whether you modify the source code of the open source edition, and whether your product is a separate application that calls the tool through its interface or embeds code from it. The answers can change the terms that apply to your own product code. Ask the vendor to confirm the license text that covers the exact version and edition you plan to deploy, and check whether any feature you need sits in a file marked as enterprise code under different terms.

Treat the license review as a gating deliverable with a named owner, not a footnote in the build plan. Record the decision, the edition, the version, and any restrictions in the architecture file, and repeat the review when you upgrade to a new major release or add a feature from a paid tier. This page does not provide legal advice. It is a list of what to confirm with your counsel and your software vendor, and an implementation partner can document the deployed configuration so that the review is based on what is actually running.

Which identity and embedding method fits each audience

Staff usually sign in to the BI platform directly, so the identity source is the organization's corporate directory or identity provider. That source must supply a stable user identifier, group membership that reflects the person's job and an active or deprovisioned status that the platform can act on. Superset is built on Flask-AppBuilder and supports OAuth2 providers such as Google and Azure, custom OAuth2 servers using the code flow and LDAP. It maps LDAP or OAuth groups to roles with AUTH_ROLES_MAPPING, so role design happens in the identity system and not by hand in each dashboard. Metabase open source and Starter support Google sign-in and LDAP, while JWT, OIDC, SAML and SCIM provisioning require Pro or Enterprise, according to Metabase's documentation.

  • Group-to-role mapping: Define which directory groups become Superset roles or Metabase groups, and test each mapping with one account per role.
  • Deprovisioning: Confirm that a disabled account stops working at the BI layer, and check whether the platform caches sessions or tokens.
  • Licensing gap: If you need OIDC or SAML in Metabase, price the Pro or Enterprise plan before design starts.
  • Admin access: Keep platform administrators in a separate group with MFA enforced at the identity provider.

Before approving the design, ask the implementation partner to demonstrate a role change and a termination in staging and show the resulting access.

Integration requirements with data sources and identity systems

An embedded dashboard is only as trustworthy as the links behind it: the analytics database, the metadata store, the identity provider, the host product and the pipeline that loads the warehouse. Each link needs an owner, an authentication method and a test that runs under production-like load before any customer or partner sees a chart.

Analytics database and its authenticators

The analytics database (for example ClickHouse) is where row-level filtering must hold, so confirm which external authenticators it will use: LDAP, Kerberos, SSL X.509 certificates, an HTTP authenticator or JWT. Ask the BI platform service account to connect with the least privileges needed and verify that a session scoped to one tenant cannot read another tenant's tables. Under load, measure whether dashboard queries slow down ingestion or other workloads on the same cluster.

Metadata database for the BI platform

The BI application stores dashboards, users, permissions and cached state in its own metadata database. For Apache Superset, that database must be PostgreSQL or MySQL, not the SQLite default used by quickstart and PyPI installs. Confirm the supported versions, backup schedule and restore test before go-live, and check that the metadata database can handle concurrent embedded sessions without becoming the bottleneck.

Identity provider and group mapping

Staff and partner logins usually come from an existing directory or identity provider over OAuth2, OIDC, SAML or LDAP. Confirm which protocol each BI feature needs on the chosen edition, since some SSO options may sit behind a paid plan. Map identity groups to BI roles and tenant attributes in writing, and test that a user removed from a group loses access to the affected dashboards on the next session.

Host product or portal embedding

The product, customer portal or intranet that displays the dashboard must pass the user's identity or a signed guest token to the BI platform. Decide where signing keys live, how long tokens last and who can rotate them. Test the embed from the host application with a second tenant's account to confirm the filter cannot be changed in the browser, and check that the host page does not expose the analytics database credentials.

Pipeline that feeds the warehouse

Dashboards are only as current as the pipeline behind them. Identify each source system, the orchestrator that schedules loads (for example Airflow or Dagster), the ingestion tool and the target tables. Set freshness targets with the business owner, then run the pipeline at expected peak volume and confirm that failed loads trigger alerts and that dashboards show the data timestamp rather than silently serving stale figures.

Failover, backup and restore tests

Replication keeps a second copy of the analytics data, but it does not protect against human error or corruption. Confirm that backups of the analytics database and the BI metadata database run on a schedule and are restored on a spare environment at least periodically. Record the restore time and check that dashboards, permissions and embed keys come back consistently with the data they describe.

Operational requirements and how to verify them

This table lists the operational requirements an embedded analytics stack must meet after launch, how to verify each one, and the evidence to keep. Read each row as a question to put to your team or implementation partner before go-live. The main takeaway is that version support, tested restores and worker components are easy to leave out of a demo but hard to recover from in production.

RequirementVerification stepEvidence to keep
Supported upgrade path for the BI platformConfirm the Metabase version is LTS or inside its support window (LTS supported for 14 months, non-LTS about 2 months) and read the release notes before each upgradeVersion support dates, dated upgrade plan, staging test results
Superset upgrade procedureBack up the metadata database, run superset db upgrade and superset init in staging, then check UPDATING.md for breaking changesSigned-off staging runbook, backup record, UPDATING.md review notes
Metabase application database backupBack up the application database before every upgrade and confirm the backup restores to a separate instanceBackup logs, restore test report, PostgreSQL or MySQL version record
Analytics store version and supportCheck the ClickHouse version against the security policy list of supported releases and plan upgrades from the changelogSupported-version register, changelog review, pre-production test results
Tested restore for the analytics storeRun BACKUP and RESTORE to local disk, S3-compatible or Azure Blob storage, then restore to a spare cluster on a scheduleBackup schedule, restore test logs, time-to-restore measurements
Caching and worker componentsConfirm that Redis, Celery workers and beat are deployed and healthy for alerts, reports, async queries and thumbnailsArchitecture diagram, worker health checks, alert delivery test records
High availability and Keeper quorumDeploy at least three ClickHouse Keeper nodes on dedicated hosts (about 4 GB RAM each) and test failover of one replicaTopology document, failover test results, replica resync log
Monitoring and alertingMonitor the application, workers, databases and replication lag, and test that alerts reach an on-call ownerDashboard screenshots, alert rules, on-call escalation records

What compliance evidence an embedded analytics platform can produce

An embedded analytics platform produces evidence in five places: authentication and access logs, role and group mappings, tenant filters on datasets, change records for dashboards and configuration, and restore test results. Each one can support a control in an assessment such as SOC 2 or an ISO/IEC 27001 review, because each shows who could see what, who changed it and whether data could be recovered. Before the build starts, decide which of these records your auditor will ask for, and confirm that the chosen product writes them to storage you control and can retain for the period your assessment covers. For Apache Superset and Metabase, that means checking where the application database lives, since the metadata and audit tables sit there. Metabase documents that its usage analytics and auditing features are limited to its Pro and Enterprise plans, so confirm that before you rely on them as evidence.

Role mappings and tenant filters need the most careful evidence. Ask the team to export the mapping from identity groups to Superset roles or Metabase groups, store that export with a date, and keep a record of each change. Show that row-level security rules, such as the filters that scope a customer to their own rows, are versioned and tested against a sample tenant. Restore evidence matters too: ClickHouse documentation warns that a backup never test-restored will probably not restore properly, so keep the results of periodic restore tests on a spare cluster as part of the control record. Your upgrade records matter as well, including the metadata database backup taken before each superset db upgrade or Metabase upgrade and the staging test that preceded it.

The EU AI Act record-keeping articles apply only if an analytics feature forms part of a high-risk AI system. Article 12(1) requires such systems to allow automatic event logging over their lifetime, and Article 19(1) requires providers to keep those logs for at least six months unless other law says otherwise. A dashboard that only displays aggregated operational figures is unlikely to be a high-risk AI system on its own, but a scoring or prediction feature built into it could change that. Confirm applicability with legal counsel before designing logging around these articles. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or attestations. Independent auditors and certification bodies make that determination, so plan the evidence package with your auditor from the start.

Questions that separate embedded analytics platforms in a proof of concept

How is row-level security enforced per tenant in embedded dashboards?

The strongest answer enforces tenant filters in the analytics layer and in the database, not only in the front end, so a dashboard cannot return another customer's rows even if a filter is edited. Ask the partner to show where the filter is defined, how it is bound to the signed-in identity, and what happens when a user has no matching attribute (the correct result is no rows, not all rows). Request a test script that attempts cross-tenant reads from a guest or SSO session and the logged output. In Metabase, row and column level permissions are listed on the pricing page as a Pro and Enterprise feature, so confirm the edition in the proposal. Superset's row-level filtering should be verified the same way in your own environment.

How do guest tokens or SSO embedding work in the proof of concept?

A sound answer names the embedding method, who issues the token or assertion, how long it lives, and how the product's session maps to dashboard permissions. Guest tokens are signed by your server and carry the tenant or customer attributes, while SSO embedding relies on your identity provider's groups or claims. Ask which protocol is used for each option, for example JWT or OIDC for Metabase, and confirm that the edition you plan to buy includes it, since the Metabase pricing page places JWT, OIDC and SAML in Pro or Enterprise. Request the signing key handling procedure, the expiry settings, and a demo where a revoked user loses access without a manual step in the dashboard tool.

Which embedded analytics features require a paid plan?

Start from the vendor's current pricing page and ask for the plan in writing against each feature you need. On Metabase's pricing page, SSO, row and column level permissions, multi-tenant data segregation and usage analytics and auditing are included only in the Pro and Enterprise plans, not in Open Source or Starter. Starter and Pro list their included users and per-user additions, and Enterprise is priced by quote starting at $20,000 per year. Apache Superset is an Apache-2.0 project with no paid edition, so its cost sits in infrastructure and engineering. Ask the partner to map each requirement to an edition, plan, or self-built component, and to state which items recur each year.

How is query load kept off production databases?

The right answer separates the analytics workload from transactional systems with a replica, a read-only analytics store, or a warehouse such as ClickHouse, and it caps query concurrency and timeouts. Ask how the dashboard tool's connections are pooled, which role it uses, and whether heavy dashboards refresh on a schedule against cached or precomputed tables. Superset's documentation notes that async queries, alerts, reports and thumbnails need a caching layer and Celery workers, so ask how those are sized. Request a load test that shows query latency on the production replica during peak embedded traffic, plus the configured timeout values.

How do AGPL obligations apply to our product if we embed Metabase?

The answer depends on how you distribute and modify the software, so ask for a written opinion from your counsel, and ask the partner what it has seen in comparable setups. Metabase ships its open source edition under the AGPL and its commercial editions under the Metabase Commercial Software License, so confirm which license covers each component you deploy. Ask whether your team plans to modify Metabase source, whether the modified version is offered to users over a network, and whether any enterprise directory code is included. Apache Superset is Apache-2.0 with no paid edition, which changes the obligation profile. DeployOpen does not give legal advice, so treat the partner's technical notes as input to your counsel's review.

How is dashboard usage audited, and who can see what?

A credible answer lists the events captured (logins, embedded views, query text, export actions, and the identity or tenant behind each one) and where they are stored and for how long. Ask whether usage analytics and auditing is available in your chosen edition, since Metabase limits it to Pro and Enterprise. If you operate under the EU AI Act, note that Article 12 concerns automatic event logging for high-risk AI systems, and Article 19 requires providers to keep those logs for at least six months, so confirm whether that applies to any AI features in the product. Request a sample audit export and a retention setting that you can change without vendor help.

Can our own team run and upgrade the platform after the proof of concept?

Yes if your team owns the runbooks, and the proof of concept should show that before you commit. Upgrades need a backup of the application database, a staging test, and a read of the release notes; for Superset, the documentation says to back up the metadata database, run the upgrade steps, and check UPDATING.md for breaking changes. Metabase applies application database migrations automatically, and its docs recommend a single node during major upgrades and upgrading release by release from versions older than 40. Ask a partner to document these steps, support the first upgrade, and state whether ongoing support is a fixed-scope project or a retainer.

How much does embedded analytics cost to implement, and what does it need from us?

What drives the cost of embedded analytics?

The largest drivers are the licensing tier, the number of users who see dashboards, the infrastructure, the analytics database and the embedding and security work. Apache Superset is licensed under Apache-2.0 and has no paid edition, so its software cost is zero, while the rest of the bill comes from servers, the database and labor. Metabase is different: its Open Source edition is free, but SSO, row and column level permissions, multi-tenant data segregation and usage analytics are included only in its Pro and Enterprise plans, according to its pricing page. Ask every vendor which features in your design sit behind a paid tier.

What does Metabase Pro cost compared with Starter?

According to the Metabase pricing page, Pro is $575 per month, or $517.50 per month billed yearly, with the first 10 users included, and additional users cost $12 per month. Starter is $100 per month, or $90 per month billed yearly, with the first 5 users included, and additional users cost $6 per month. Enterprise is priced by quote starting at $20,000 per year. These are list prices from the vendor's page at the time of publication, so confirm current figures directly with Metabase before you budget.

Can our own team build and run embedded analytics in-house?

Many teams can, provided they have engineers who know the platform's architecture, identity integration and data modeling. Superset, for example, has four components to operate: the application, a metadata database, an optional caching layer and optional Celery workers, and the caching and worker components are needed for alerts, async queries and thumbnails. Operating it also means backups, upgrades and security patching on a recurring schedule. Assess whether you have that skill set on staff for the long term, not only for the first launch.

How long does an embedded analytics rollout take?

Duration depends on the number of data sources, how many dashboards must be migrated or rebuilt, the complexity of row-level security, the identity provider integration and the number of review cycles your security team requires. Metabase's upgrade guidance, for instance, expects staged upgrades and a database backup before each change, which adds time to any rollout that touches production. Ask a partner for a timeline tied to a written scope, with milestones for staging, security review and go-live. Do not accept an estimate that is not based on that scope.

What does our team need to provide for an embedded analytics project?

Plan to supply three kinds of input. Identity owners must define how users map to roles or groups, which can be done through OAuth or LDAP group mapping such as Superset's AUTH_ROLES_MAPPING. Data owners must confirm which tables, columns and tenant keys drive row-level filters and which datasets may be exposed. Security reviewers must approve the authentication design, token lifetimes, secret handling and logging, and the review should start early because it often sets the schedule.

What should we ask for in a written quote for embedded analytics?

Ask for a fixed scope that lists each platform component, each data source, each embedding pattern and each identity integration. Request the one-time costs (design, build, testing, documentation, handover) separately from recurring costs (hosting, database, licenses or plan fees, upgrades and support), and ask which plan tier each feature requires. Also request assumptions about user counts, staging environments, backup and restore testing, and what happens to work outside the scope. Compare quotes on that basis rather than on a single total.

Which recurring costs continue after launch?

Recurring costs typically include hosting, the analytics and metadata databases, backup storage, paid plan fees if you choose a commercial tier, and staff time for upgrades and patching. ClickHouse, when used as the analytics database, has its own release cadence and support windows, with stable releases roughly monthly and LTS releases supported for a year, according to its production guidance, so the upgrade effort is recurring. Budget for these lines explicitly, and ask a partner whether they offer ongoing support as a separate retainer.

How DeployOpen scopes and delivers an embedded analytics implementation

The sequence moves from a written scope of audiences, tenants and data to a tested proof of concept, then a hardened build inside your own infrastructure with the evidence and documentation your reviewers need. Most engagements are fixed-scope, and every step closes with a written output you can check.

  1. Agree the written scope

    DeployOpen works with your product, security and data leads to record who sees dashboards (staff, customers, partners), the tenant model, the identity provider that will issue sessions or guest tokens, the source databases and the expected query patterns. The scope also names the Superset or Metabase edition being considered and the license questions that affect distribution. The step is done when deliverables, exclusions, responsibilities and timelines are agreed in writing and signed before any build work starts. Most engagements are fixed-scope, and there is no published price list, so the quote follows directly from this document.

  2. Map tenants, identity and data sources

    Next, the team turns the scope into a design: how each tenant maps to row-level filters or data segregation, how groups from your identity system map to roles, and where analytics queries will run relative to production databases. For Metabase, this step confirms which identity features the chosen plan includes. For Superset, it confirms the OAuth2 or LDAP group mapping approach. The output is a design document with a row-level security matrix, an entitlement map and a data flow diagram, reviewed by your security team before the proof of concept starts.

  3. Build a proof of concept with representative data

    DeployOpen deploys a non-production instance inside your infrastructure and loads representative tenant data, ideally a copy or sample that reflects real cardinality and skew. The proof of concept tests whether row-level isolation holds for each audience, whether embedded sessions behave correctly for a sample of tenants, and how dashboards perform under expected concurrency. Your team should test cross-tenant access attempts. The step closes with a written test report listing what passed, what failed, and what changes the design needs.

  4. Implement and harden in your infrastructure

    DeployOpen builds the production environment in your own cloud accounts, data centers or air-gapped network. Work includes the metadata database (PostgreSQL or MySQL for Superset and Metabase in production), secret management, SSO or guest token configuration, theming, the query path to the analytics store, and hardening against the platform's security guidance. Changes are made through version-controlled configuration where possible. The step is complete when the environment passes the test cases from the proof of concept and a staged configuration matches the production build.

  5. Prepare documentation and compliance evidence

    DeployOpen documents the architecture, tenant isolation design, access control configuration, backup and restore procedures, and the upgrade runbook covering the database backup and version-specific steps. It also assembles evidence that a compliance assessor or internal reviewer would request, such as access configuration exports, test results and change records. DeployOpen prepares this evidence but does not issue audit reports or certifications; your auditors or certification bodies do. The step closes when your team signs off on the documentation pack.

  6. Hand over and operate with your team

    Handover covers an operating session for your administrators and engineers on user and group management, tenant onboarding, dashboard publishing, log review and restore testing. For backup, the documentation for ClickHouse and other stores notes that a backup never test-restored will probably not restore when needed, so the handover includes a scheduled restore test on a spare environment. The step is done when your team has run one restore and one upgrade rehearsal in staging, with the results recorded.

  7. Continue with optional retainer support

    After handover, you can choose a retainer for ongoing support, version upgrades, security testing of the embedding surface and periodic restore tests. Upgrade work follows the vendor's documented process, including backing up the metadata database, testing in staging and checking breaking-change notes first. Retainer scope, response expectations and fees are set in a separate written agreement, so confirm service levels in writing before signing. The step ends when the retainer's agreed deliverables are met each cycle.

Talk to our team.

Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.

  • 30-minute call: free, with no obligation.
  • NDA on request: we can sign before you share details.
  • Clear next steps: a scope and plan after the call.