Embedded analytics for manufacturers and connected products

Access evidence comes from the access layer, not the dashboard tool alone. Superset's authentication setup (Flask-AppBuilder with OAuth2 or LDAP and AUTH_ROLES_MAPPING) determines who logs in and with which role, and the metadata database records dashboard and query activity that you can export. ClickHouse's own logs and its access control definitions (users, roles and row policies) show which account queried which table. Combine these into a log that maps each viewer to a tenant identifier and a timestamp. Confirm with your security team which log retention and export mechanisms apply in your environment, because the exact fields depend on your deployment and configuration.

Keep a repeatable test suite that logs in as a user from each tenant and attempts to read every other tenant's rows through dashboards, charts, SQL Lab and direct API calls. Store the test inputs, expected results, actual results and the commit or configuration version tested. Auditors look for negative tests, not just a demonstration that a tenant sees its own data. Run the suite after every Superset upgrade and every change to role mapping or dataset definitions. DeployOpen can plan and implement security testing, including application and API testing, but the evidence must be retained by your team and reviewed by your assessor.

Keep backup job records and restore test records as separate artifacts. ClickHouse BACKUP and RESTORE can write full and incremental backups of tables, partitions or databases to local disk, S3-compatible storage or Azure Blob Storage. The backup documentation notes that replication does not protect against human error or corruption, so backups are a separate control. The documentation also warns that a backup never test-restored will probably not restore when needed. Record the backup identifier, storage location, date, the restore target (ideally a spare cluster), the row counts or checksums compared, and who signed off. Run restore tests on a schedule and keep the results for assessors.

Each upgrade should leave a change record built from the upgrade procedure itself. The Superset documentation calls for a metadata database backup, running superset db upgrade and superset init, testing in staging first, and reviewing UPDATING.md for breaking changes between versions. Keep the target version, the reviewed breaking changes, the staging test results, the backup reference, the approver, and the rollback plan. Pair this with ClickHouse change records, since the ClickHouse production guidance recommends a pre-production environment with representative data and reading the changelog before upgrading. Confirm which ClickHouse release line your change board has approved, because supported versions change over time.

Map each document to the control area it supports rather than writing one generic policy. For the IEC 62443 series, ANSI/ISA-62443-2-1-2024 addresses the security program requirements for asset owners, ANSI/ISA-62443-3-2-2020 covers risk assessment for system design, and ISA-62443-3-3-2013 sets system security requirements and security levels. Your analytics platform is typically a system within the wider IACS and IT estate, so the zone and conduit model and security levels need to be stated explicitly. For NIS2, Article 23(4) requires an early warning within 24 hours, an incident notification within 72 hours and a final report within one month for significant incidents, so your runbooks and logs need to support those timelines. Confirm with counsel whether your organization is an in-scope entity, since the manufacturing sector classification covers several NACE divisions.

No. DeployOpen plans, implements, hardens and documents the platform and prepares the systems, controls and evidence that an assessment will examine. Audit reports, attestations and certifications are issued only by independent auditors and certification bodies. In practice, DeployOpen can help assemble the access logs, RLS test records, backup and restore records, change records and the mapping to IEC 62443 and NIS2 obligations described above, and can run security testing as a separate engagement. Your assessor will decide what evidence is sufficient. Ask any partner to state this boundary in the written scope.

Possibly, and the timing matters. Regulation (EU) 2024/2847 applies to products with digital elements from 11 December 2027, but manufacturers' Article 14 obligations to report actively exploited vulnerabilities and severe incidents have applied since 11 September 2026 (Article 71(2)). If your connected product or its portal is in scope, you need a documented process for vulnerability handling and incident reporting that covers the analytics components, including Superset and ClickHouse versions in use. Fines under Article 64 reach EUR 15 million or 2.5% of worldwide annual turnover, whichever is higher, for breaches of certain obligations. Confirm applicability with your legal and product compliance team, since scope depends on the product and its classification.

Yes, many teams can produce these records with internal staff if they assign owners and schedule the work. The recurring items are access log exports, monthly or per-release RLS test runs, quarterly restore tests, and change records for every upgrade. The one-time items are the initial test suite, the document mapping and the runbooks. A partner typically adds value in building the automation, running independent security testing, and writing the mapping against the standards. Most DeployOpen engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts, and ongoing support can be provided through a retainer. Ask any provider to itemize which evidence they will build and which your team must operate.

Cost follows four drivers: the number of customer tenants, the volume and retention of machine and sensor data, the isolation model you choose, and how much OT integration the work requires. Each tenant adds dashboards, row-level security rules and access testing. Time-series volume sets the size of the ClickHouse cluster, its backup storage and the replication design. A shared-table model with row-level security costs less to build than separate databases per customer, but it needs stronger testing to prove that one customer never sees another's data. OT integration adds connectors, change control and plant-side review. Ask any implementation partner for a quote that itemizes these four drivers and states which parts are one-time and which recur, such as hosting, backups, patching and retainer support.

The first dashboard depends on how quickly the data owners confirm the data model, how many machine signals feed it, and whether the customer portal's identity system is ready for single sign-on or guest tokens. A narrow first release, such as one equipment family and one set of sensor metrics for a pilot group of customers, moves faster than a full fleet rollout. Work runs under a written, fixed-scope agreement, so the timeline is set in that document rather than estimated here. Ask the partner which milestones the schedule depends on, which of them sit with your team, and what happens if plant access or data-owner approvals arrive late.

The manufacturer must supply four things: named data owners who can approve the metrics and retention rules, a documented path to the machine and sensor data, a decision on how plant networks connect to the analytics platform, and the identity provider that customers will use. Data owners settle which signals are customer-visible and which are internal. OT access needs an agreed method, such as a read-only export or a one-way data path, and the security team must approve it. The identity provider must support OAuth2 or LDAP so that Superset or Metabase can map groups to roles. Confirm these inputs with your plant engineering, OT security and customer identity teams before signing a scope.

A team with Linux, Kubernetes or VM operations, PostgreSQL administration, ClickHouse experience and identity integration skills can run the platform, but the workload is specialized. The Superset architecture includes a metadata database, an optional caching layer and optional Celery workers, and alerts, async queries and thumbnails depend on the caching and worker components. ClickHouse needs at least three ClickHouse Keeper nodes in production, and backups must be restored and tested on spare clusters. Before deciding, list the people who would own upgrades, backups, row-level security changes and on-call response, and check whether they can cover those tasks during a plant incident.

Upgrades follow a documented sequence that someone must own. For Superset, the upgrade documentation says to back up the metadata database, run superset db upgrade and superset init, test in staging first, and read UPDATING.md for breaking changes. ClickHouse stable releases ship roughly monthly, LTS releases ship twice a year and are supported for a year, and its security policy lists supported versions, so choosing a release line is a governance decision. Ask the partner how staging mirrors production, how rollback works, and whether upgrades, patching and testing are included in a retainer. Retainers cover ongoing support, upgrades and continuous testing, and their terms belong in the written scope.

The initial implementation is usually a fixed-scope project with agreed deliverables. Ongoing work, such as platform upgrades, monitoring, backup verification, security testing and changes to dashboards or tenants, is often handled through a retainer. Ask what the retainer covers, how change requests are priced, how response expectations are written, and what happens when a customer tenant is added. Confirm whether the retainer includes restore tests and staging upgrades. DeployOpen does not publish a price list, so request a written quote that separates one-time work from recurring support.

Yes. Any path between plant systems and an analytics platform should be reviewed against the ISA/IEC 62443 series, which organizes requirements into general, policies and procedures, system and component groups. ANSI/ISA-62443-3-2-2020 covers security risk assessment for system design, which fits the connection design, and ANSI/ISA-62443-2-1-2024 covers program requirements for asset owners. NIST SP 800-82 Rev. 3 covers OT security and states that performance, reliability and safety requirements matter. Keep customer dashboards on a separate tier from operational control systems, and have OT engineers approve any read path. Ask your partner which of these standards their assessment covers and how findings are documented.

Several regulations may apply, depending on where your products are sold and which sectors you serve. NIS2 Annex II lists manufacturing as a critical sector, including electronic, electrical, machinery and transport equipment, and in-scope entities face incident reporting deadlines in Article 23(4). The Cyber Resilience Act, Regulation (EU) 2024/2847, applies to products with digital elements from 11 December 2027, while manufacturers' Article 14 reporting obligations have applied since 11 September 2026. The Machinery Regulation applies from 14 January 2027. DeployOpen prepares systems, controls and evidence for compliance assessments but does not issue audit reports or certifications. Ask your legal and compliance team to confirm which obligations apply to your products.