Federal Government BI on Apache Superset: An IRAP-Aligned Pattern

Table of Contents

1. Why IRAP Matters for Federal BI
2. Understanding IRAP and ISM Alignment
3. Apache Superset as a Federal-Grade BI Platform
4. D23.io Infrastructure and Tenancy Patterns
5. IRAP PROTECTED Controls Implementation
6. Shared-Services Tenancy Architecture
7. Security Audit Readiness and Compliance
8. Real-World Deployment: A 6-Week Pattern
9. Common Pitfalls and Remediation
10. Next Steps and Governance

---

Why IRAP Matters for Federal BI

Australian federal government agencies operate under strict information security obligations. The Australian Cyber Security Centre (ACSC) mandates that all ICT systems processing government data meet the Information Security Manual (ISM) baseline controls. For business intelligence platforms, this is non-negotiable: dashboards, data pipelines, and query engines must be deployed, configured, and audited in ways that satisfy both the letter and spirit of IRAP (Information Security Registered Assessors Program) assessment.

Traditional commercial BI vendors—Tableau, Power BI, Qlik—come with licensing costs that scale with user count and often require cloud tenancy models that don’t align with Australian data residency or shared-services procurement frameworks. Apache Superset, by contrast, is open-source, self-hosted, and infinitely customisable. When deployed on D23.io (the Australian government’s secure cloud platform), Superset becomes a PROTECTED-grade BI engine that agencies can own, audit, and govern end-to-end.

The pattern we outline here is not theoretical. It reflects real engagements where PADISO has architected and deployed Superset-based BI for federal teams, passing IRAP assessments and delivering operational dashboards in 6–8 weeks. The outcome: agencies retain data sovereignty, reduce licensing sprawl, and build BI capabilities that are audit-ready from day one.

Understanding IRAP and ISM Alignment

What Is IRAP?

IRAP is the Australian government’s formal assessment framework for ICT systems that will process PROTECTED or OFFICIAL: Sensitive data. An IRAP assessment evaluates whether a system’s design, deployment, and operations comply with the ISM—a comprehensive set of security controls published by the ACSC.

The ISM covers 14 control families: information security governance, personnel security, physical security, communications security, cryptography, ICT security, system development and acquisition, cryptographic key management, system and communications protection, information and data security, ICT security incident management, business continuity management, supplier management, and security assessment and accreditation.

For a BI platform like Apache Superset, the most relevant controls cluster around:

• Access control: Multi-factor authentication (MFA), role-based access control (RBAC), and audit logging of user actions.
• Data protection: Encryption in transit and at rest, data classification, and secure disposal.
• Network security: Network segmentation, firewall rules, and intrusion detection.
• Incident response: Logging, alerting, and forensic capability.
• Supplier management: If using third-party cloud or SaaS, ensuring vendors are IRAP-assessed themselves.

When you deploy Superset on D23.io, you inherit D23.io’s IRAP assessment and baseline controls. However, you must then layer application-level controls—authentication, authorisation, encryption keys, audit logs—to achieve end-to-end compliance.

ISM vs. IRAP: The Distinction

The ISM is the standard; IRAP is the assessment methodology. An IRAP assessor (an accredited, independent security professional) evaluates your system against ISM controls and produces a report. If the system passes, it receives an IRAP certificate at OFFICIAL, OFFICIAL: Sensitive, or PROTECTED level, depending on the data classification.

For federal BI, PROTECTED is the typical target. PROTECTED data includes information that, if disclosed, could cause serious injury to individuals or organisations. Most agency operational dashboards—budget data, personnel metrics, contract pipelines—fall into this category.

D23.io as the Hosting Foundation

D23.io is the Australian government’s dedicated, secure cloud platform. It is itself IRAP-assessed at PROTECTED level and complies with ISM requirements for data residency, network isolation, and physical security. By hosting Superset on D23.io, you inherit these baseline controls and avoid the overhead of building your own secure infrastructure.

D23.io’s shared-services model allows multiple agencies to co-tenant the same cloud fabric while maintaining logical and cryptographic isolation. This is critical for cost efficiency and procurement simplicity in the federal context.

Apache Superset as a Federal-Grade BI Platform

Why Superset Over Commercial Alternatives?

Apache Superset is an open-source, modern data exploration and visualisation platform. It runs on Python and JavaScript, integrates with any SQL database, and offers a no-code dashboard builder for business users. For federal agencies, Superset offers three strategic advantages:

1. Data sovereignty: Code and data remain entirely within Australian infrastructure. No cloud vendor lock-in, no overseas data transfer.
2. Cost control: No per-user licensing. A single Superset instance serves 10 users or 1,000 users at the same operational cost.
3. Auditability: You control every line of code, every configuration, and every audit log. There are no black-box SaaS algorithms or hidden data flows.

Compare this to Tableau or Power BI, where licensing scales with users and data residency can be opaque. For a large federal agency with thousands of potential BI consumers, Superset’s economics are transformative.

Core Superset Capabilities for Government BI

Superset provides:

• Multi-database support: Connect to PostgreSQL, MySQL, Oracle, Snowflake, Databricks, and dozens of other SQL backends.
• SQL Lab: A SQL editor for analysts to write and execute queries, with result caching and download capability.
• Dashboards: Drag-and-drop dashboard composition with filters, cross-filtering, and drill-down.
• Alerts and reports: Automated email reports, Slack notifications, and threshold-based alerting.
• Row-level security (RLS): Restrict dashboard rows and query results based on user roles or attributes.
• Semantic layer: Define metrics, dimensions, and calculated fields once, reuse across all dashboards.

For government, the semantic layer is particularly powerful. It allows a central data governance team to define “revenue,” “headcount,” or “budget variance” once, and every analyst in the agency sees the same definition. This eliminates spreadsheet chaos and audit risk.

Integration with Agentic AI

One emerging pattern is integrating Superset with agentic AI systems. As outlined in PADISO’s guide on agentic AI and Apache Superset, you can wire Claude or similar LLMs to query Superset programmatically, allowing non-technical users to ask natural-language questions and receive dashboard insights automatically. For government, this democratises data access without requiring SQL training.

However, agentic AI in PROTECTED environments requires careful governance. Our production horror stories guide details real failures—runaway loops, prompt injection, hallucinated tools—and remediation patterns that apply equally to government deployments.

D23.io Infrastructure and Tenancy Patterns

D23.io Architecture Basics

D23.io is a containerised, multi-tenant cloud platform running on Australian infrastructure. It provides compute (Kubernetes), storage (object and block), networking, and identity services, all pre-hardened to ISM standards.

When you deploy Superset on D23.io, you provision:

• Kubernetes cluster: A managed Kubernetes service where Superset pods run.
• Persistent storage: For Superset’s metadata database (typically PostgreSQL) and user-uploaded files.
• Secrets management: A secure vault for database credentials, API keys, and encryption keys.
• Network policies: Ingress/egress rules controlling traffic to and from Superset.
• Identity federation: Integration with Australian government’s identity provider (typically Active Directory or Entra ID).

Shared-Services Tenancy Model

D23.io uses a “shared-services” model where multiple agencies can run workloads on the same physical infrastructure, but with strong logical isolation. This is achieved through:

• Kubernetes namespaces: Each agency gets one or more namespaces, preventing pods from one agency accessing another’s.
• Network policies: Firewall rules at the network layer restrict traffic between namespaces.
• RBAC (Role-Based Access Control): Kubernetes RBAC ensures only authorised service accounts can interact with a given namespace.
• Encryption at rest: All persistent data is encrypted with agency-specific keys, preventing cross-agency data leakage even if storage is physically shared.
• Audit logging: All API calls to D23.io are logged and immutable, enabling forensic investigation.

For a federal agency deploying Superset, this model means:

• Low upfront infrastructure cost (you pay only for compute and storage used, not for dedicated hardware).
• No operational burden of managing physical servers or network switches.
• Strong assurance that your data and configurations are isolated from other agencies.
• Transparent audit trail for compliance investigations.

Network Segmentation and Ingress

Superset instances on D23.io are typically fronted by a reverse proxy (e.g., Nginx) that enforces TLS termination, request logging, and rate limiting. The proxy sits in a DMZ network segment, while Superset’s backend and database sit in a more restricted segment.

Ingress to Superset is controlled via:

• IP whitelisting: Only traffic from agency networks (or a VPN gateway) is allowed.
• VPN or private link: For remote users, a site-to-site VPN or private cloud link ensures encrypted, authenticated access.
• MFA at the proxy layer: Optionally, enforce MFA (via TOTP or FIDO2) before traffic reaches Superset.

This layered approach ensures that even if a Superset vulnerability is discovered, the attack surface is minimised by network controls.

IRAP PROTECTED Controls Implementation

Authentication and Authorisation

Superset’s native authentication is database-backed (username/password stored in Superset’s metadata DB). For IRAP, this is insufficient. Instead, you must:

1. Disable local authentication: Remove Superset’s built-in login form.
2. Integrate with government identity provider: Use SAML 2.0 or OpenID Connect to federate authentication to the agency’s Active Directory or Entra ID.
3. Enforce MFA: Require multi-factor authentication (TOTP, SMS, or hardware token) for all users.
4. Implement RBAC: Map government AD groups to Superset roles (Admin, Editor, Viewer) so access is provisioned and de-provisioned automatically.

When an agency employee logs in, the flow is:

1. User navigates to Superset.
2. Superset redirects to the government’s SAML identity provider.
3. User authenticates with username, password, and MFA.
4. Identity provider returns a signed SAML assertion with the user’s groups.
5. Superset parses the assertion, creates or updates the user, and assigns roles based on groups.
6. User is logged in and can access dashboards and data based on their role.

This is an IRAP-standard pattern, used across government agencies for all applications. Superset’s SAML/OIDC support makes this straightforward.

Row-Level Security (RLS)

Row-level security ensures that a user can only see data they are authorised to view. In Superset, RLS is implemented via the semantic layer: you define a “base clause” for each dataset that filters rows based on the logged-in user’s attributes.

For example, a “Budget” dataset might have a base clause:

WHERE department_id IN (SELECT department_id FROM user_departments WHERE user_id = '{user_id}')

When a user queries the Budget dataset, Superset automatically appends this clause, ensuring they see only budgets for their department. This is transparent to the user—they see a normal dashboard, unaware of the filtering.

RLS is critical for IRAP compliance because it prevents data leakage. Even if a user gains unauthorised access to the Superset database, they cannot read rows outside their scope.

Encryption in Transit and at Rest

• In transit: All traffic between client and Superset is encrypted with TLS 1.2 or higher. Certificates are issued by a trusted CA (e.g., DigiCert) and pinned in the reverse proxy.
• At rest: Superset’s metadata database (PostgreSQL) is encrypted using D23.io’s encrypted block storage. Database backups are also encrypted. For data warehouses (e.g., Snowflake, Databricks), encryption is delegated to the warehouse provider, but Superset’s connection credentials are encrypted in Superset’s secrets vault.

Audit Logging and Monitoring

Superset logs all user actions: dashboard views, query executions, dataset modifications, user creation/deletion. These logs are written to a central logging system (e.g., ELK, Splunk, or D23.io’s native logging service) and retained for at least 12 months.

Key audit events include:

• User login/logout (timestamp, user ID, source IP, MFA method).
• Dashboard view (user, dashboard name, timestamp).
• Query execution (user, SQL, dataset, timestamp, execution time, rows returned).
• Configuration changes (admin actions, who changed what, when).
• Data export (user, dataset, number of rows, timestamp).

An IRAP assessor will review these logs to verify that:

1. All user actions are recorded.
2. Logs are immutable (cannot be deleted or modified after creation).
3. Logs are retained for the required period.
4. Log access is restricted to authorised personnel.
5. Alerts are configured for suspicious activities (e.g., bulk data export, failed login attempts).

Incident Response and Forensics

Superset’s audit logs enable rapid incident response. If a user is suspected of unauthorised data access, you can:

1. Query audit logs to identify all queries executed by that user.
2. Review the SQL and data returned to assess what was accessed.
3. Check the user’s login history to identify if the account was compromised.
4. Cross-reference with network logs to identify the source IP.
5. Initiate a security incident response process if needed.

For IRAP, you must document your incident response procedures and demonstrate that you can execute them. Superset’s logging infrastructure supports this.

Shared-Services Tenancy Architecture

Multi-Agency Deployment Patterns

When multiple agencies deploy Superset on D23.io, the architecture typically follows one of two patterns:

Pattern 1: Dedicated Superset Instance per Agency

Each agency runs its own Superset instance in its own Kubernetes namespace. This is the simplest model:

• Pros: Complete isolation, no shared code or configuration, easy to audit.
• Cons: Operational overhead (each agency must patch, upgrade, and maintain Superset independently).

Pattern 2: Shared Superset Instance with Logical Isolation

All agencies run a single Superset instance, but with strong logical isolation:

• Pros: Centralised operations, shared security patches, economies of scale.
• Cons: More complex configuration, higher risk if isolation is misconfigured.

Pattern 2 requires careful implementation:

1. Separate databases per agency: Each agency’s metadata and data warehouses are in separate database instances or schemas, encrypted with agency-specific keys.
2. RBAC and RLS: Superset’s RBAC ensures users from Agency A cannot see Agency B’s roles or dashboards. RLS ensures they cannot see Agency B’s data.
3. Audit logging with agency tagging: Every log entry includes the agency ID, enabling post-hoc audit separation.
4. Secrets segregation: Each agency’s database credentials are encrypted and stored separately, inaccessible to other agencies’ administrators.

PADISO has implemented both patterns for federal clients. Pattern 1 is typical for large agencies (APS 200+), while Pattern 2 suits smaller agencies or shared-services arrangements.

Data Warehouse Integration

Superset itself is not a data warehouse; it is a query engine and visualisation layer. For federal agencies, the data warehouse is typically:

• Snowflake (hosted on AWS in the ap-southeast-2 region with ISM-aligned controls).
• Databricks (similarly configured).
• On-premises Oracle or PostgreSQL (connected via secure VPN).
• Government data lake (e.g., a Hadoop cluster or Delta Lake on D23.io).

Superset connects to the warehouse via a database driver (JDBC, ODBC, or Python DB-API), executing queries and returning results. For IRAP compliance:

1. Credentials are never logged: Database passwords are encrypted and stored in Superset’s secrets vault, never appearing in logs or UI.
2. Connections are encrypted: TLS is enforced for all database connections.
3. Query auditing is comprehensive: Every query is logged, including the SQL, user, timestamp, and result set size.
4. Rate limiting is enforced: Prevent resource exhaustion attacks by limiting query frequency and result set size.

Semantic Layer as Governance

The semantic layer is where data governance happens. Instead of allowing analysts to write arbitrary SQL, you define a curated set of datasets, metrics, and dimensions. Analysts build dashboards using these pre-defined objects, ensuring:

• Consistency: Everyone uses the same definition of “revenue” or “headcount”.
• Security: Only authorised metrics and dimensions are exposed (others are hidden).
• Auditability: You know which datasets are in use and who is using them.
• Performance: Metrics are pre-calculated and cached, reducing query load on the warehouse.

For example, a “Sales” dataset might expose:

• Dimensions: Region, Product, Customer Segment, Date.
• Metrics: Revenue (sum of sales), Order Count, Average Order Value.
• Calculated Fields: Revenue Growth (YoY %), Margin (Revenue - Cost).

Analysts can filter and group by these dimensions and metrics, but cannot access raw tables or write custom SQL (unless they have the Analyst role, which requires additional approval).

Security Audit Readiness and Compliance

Pre-Assessment Checklist

Before engaging an IRAP assessor, conduct an internal security assessment. Key areas:

1. Access control: Are all users authenticated via MFA? Are roles correctly assigned? Are inactive accounts disabled?
2. Data protection: Is sensitive data encrypted at rest and in transit? Are backups encrypted and tested?
3. Audit logging: Are all user actions logged? Are logs immutable and retained? Are log access controls in place?
4. Network security: Is Superset isolated from untrusted networks? Are firewall rules documented? Is network segmentation enforced?
5. Patch management: Are Superset, dependencies, and OS patches current? Is a patch management process documented?
6. Incident response: Is there a documented process for responding to security incidents? Have you tested it?
7. Supplier management: If using third-party services (e.g., Snowflake), are they IRAP-assessed? Are contracts in place?
8. Backup and recovery: Are backups tested regularly? Is the recovery time objective (RTO) documented and achievable?
9. Change management: Is there a formal change control process? Are all changes logged and approved?
10. Security awareness: Have all staff received security training? Is there a process for onboarding new staff?

As detailed in PADISO’s AI automation for government services guide, federal deployments require particular rigour around change management and audit trails, as these are often scrutinised by oversight bodies.

Common IRAP Assessment Findings

IRAP assessors typically identify a few recurring gaps in Superset deployments:

1. Weak authentication: Local username/password instead of federated identity. Remediation: Implement SAML/OIDC federation.
2. Missing MFA: Users can log in with password alone. Remediation: Enforce MFA at the identity provider or proxy layer.
3. Insufficient audit logging: Query logs don’t capture the full SQL or result set size. Remediation: Enable Superset’s extended audit logging and centralise logs.
4. No RLS: All users can see all data. Remediation: Implement RLS via the semantic layer.
5. Unencrypted backups: Database backups are stored in plain text. Remediation: Enable encryption for all backups.
6. Missing incident response plan: No documented process for handling security breaches. Remediation: Write and test an incident response plan.

Addressing these findings typically requires 2–4 weeks of remediation work before a re-assessment.

Real-World Assessment Timeline

A typical IRAP assessment for a Superset deployment follows this timeline:

• Week 1–2: Assessor conducts interviews with your team, reviews documentation, and performs a desktop audit.
• Week 3–4: Assessor conducts technical testing (login, access control, encryption, logging).
• Week 5: Assessor reviews findings with your team and identifies remediation items.
• Week 6–8: Your team remediates findings.
• Week 9: Assessor conducts a re-assessment to verify remediation.
• Week 10: Assessor issues the IRAP report and certificate.

Total timeline: 10 weeks. If findings are minor, the timeline can be compressed. If findings are major (e.g., fundamental architectural issues), timeline extends.

Real-World Deployment: A 6-Week Pattern

The Engagement Structure

PADISO has deployed Superset for federal agencies multiple times, typically in a 6–8 week fixed-fee engagement. The pattern is:

Week 1–2: Discovery and Design

• Interviews with stakeholders to understand data sources, user personas, and compliance requirements.
• Architecture design: D23.io infrastructure, Superset configuration, semantic layer structure.
• Procurement of D23.io resources (compute, storage, network).
• Setup of development, staging, and production environments.

Week 3–4: Implementation

• Deploy Superset on D23.io Kubernetes cluster.
• Configure SAML/OIDC federation with agency identity provider.
• Implement MFA at the proxy layer.
• Build the semantic layer: datasets, metrics, dimensions, calculated fields.
• Set up audit logging and centralised log aggregation.
• Implement RLS for sensitive data.

Week 5–6: Dashboards and Training

• Build 5–10 core dashboards based on stakeholder requirements.
• Set up alerts and automated reports.
• Conduct user training (dashboard navigation, filtering, exporting).
• Conduct admin training (user management, dashboard governance, troubleshooting).
• Documentation: architecture guide, runbook, FAQ.

Week 7–8: Hardening and Handover

• Security hardening: firewall rules, network policies, secrets rotation.
• Backup and disaster recovery testing.
• Performance tuning and load testing.
• Handover to agency operations team.
• Support for initial issues and optimisations.

As detailed in PADISO’s D23.io consulting engagement guide, a typical $50K engagement covers this scope: architecture, SSO, semantic layer, 5–10 dashboards, and training delivered in 6 weeks.

Staffing and Roles

A typical engagement involves:

• Solution Architect (PADISO): Leads design, oversees implementation, interfaces with stakeholders.
• Superset Engineer (PADISO): Implements Superset, configures infrastructure, builds semantic layer.
• Data Engineer (PADISO): Designs data pipelines, optimises warehouse queries, builds metrics.
• Agency Data Owner: Provides business requirements, validates dashboards, ensures data accuracy.
• Agency IT/Security: Approves infrastructure, manages identity provider integration, reviews audit logs.
• Agency End Users: Participate in training, provide feedback on dashboards.

Deliverables

At the end of the engagement, the agency receives:

1. Superset instance (production-ready, IRAP audit-hardened).
2. Semantic layer (datasets, metrics, dimensions, RLS rules).
3. Dashboard suite (5–10 core dashboards covering key business metrics).
4. Audit and logging infrastructure (centralised logs, alerts, retention policy).
5. Architecture documentation (infrastructure diagram, security controls, operational procedures).
6. Runbook (how to provision users, create dashboards, troubleshoot issues).
7. Training materials (user guide, admin guide, video walkthroughs).
8. Handover support (4 weeks of on-call support for issues and optimisations).

Common Pitfalls and Remediation

Pitfall 1: Underestimating Semantic Layer Complexity

Problem: Teams assume they can build a semantic layer in a few days. In reality, defining metrics and dimensions requires stakeholder alignment, data lineage mapping, and performance tuning.

Remediation: Allocate 2–3 weeks for semantic layer design. Start with a core set of metrics (5–10), validate with stakeholders, then expand iteratively.

Pitfall 2: Insufficient RLS Planning

Problem: RLS rules are implemented ad-hoc, leading to data leakage or overly permissive access.

Remediation: Map user roles to data access requirements upfront. Define RLS rules in a matrix (user role vs. dataset dimension). Test RLS rules with sample data before production.

Pitfall 3: Inadequate Audit Logging

Problem: Superset logs are verbose but not actionable. Assessors cannot easily verify who accessed what data when.

Remediation: Centralise logs in a SIEM (e.g., Splunk). Create dashboards for audit events. Define alerting rules (e.g., alert on bulk exports or failed logins).

Pitfall 4: Overlooking Performance Tuning

Problem: Dashboards load slowly, frustrating users and causing support tickets.

Remediation: Profile queries early. Use Superset’s caching layer. Pre-aggregate metrics in the warehouse. Test dashboards with realistic data volumes and user load.

Pitfall 5: Poor Change Management

Problem: Dashboards are modified without approval, breaking downstream reports or exposing sensitive data.

Remediation: Implement a dashboard governance process: changes require approval from a data steward. Version-control dashboard definitions. Maintain a change log.

Pitfall 6: Inadequate Disaster Recovery

Problem: A database failure or misconfiguration results in data loss or extended downtime.

Remediation: Implement automated daily backups. Test recovery procedures monthly. Document RTO and RPO. Set up a standby Superset instance for failover.

For deeper insights into production failures and remediation, PADISO’s agentic AI production horror stories document real failures and patterns that apply to any complex system, including federal BI platforms.

Next Steps and Governance

Establishing a Data Governance Board

Once Superset is in production, establish a governance board to oversee:

• Dashboard approvals: New dashboards and significant modifications require approval.
• Data access: User provisioning and role assignments are reviewed quarterly.
• Metric definitions: Changes to core metrics are documented and communicated.
• Performance: Query performance and system uptime are monitored and reported.
• Security: Audit logs are reviewed monthly, and security incidents are investigated.

The board typically includes representatives from:

• Data governance (chair).
• IT/Security.
• Key business units (finance, operations, HR).
• Data engineering.

Continuous Improvement

Superset deployments should evolve over time:

• Month 1–3: Focus on stability and user adoption. Gather feedback.
• Month 4–6: Expand the dashboard suite based on user requests. Optimise performance.
• Month 6–12: Integrate new data sources. Introduce advanced features (alerts, reports, custom plugins).
• Year 2+: Evaluate agentic AI integration (natural-language queries). Explore federated learning for privacy-preserving analytics.

As outlined in PADISO’s agentic AI and Superset integration guide, integrating LLMs with Superset can democratise data access, but requires careful governance around prompt injection and hallucination risks.

Staying Current with IRAP and ISM

The ISM is updated periodically, and IRAP assessors’ expectations evolve. To maintain compliance:

• Annual security review: Engage an external assessor to review your Superset deployment against the latest ISM controls.
• Patch management: Apply Superset and dependency updates within 30 days of release.
• Training: Ensure staff receive annual security awareness training.
• Incident tracking: Maintain a log of security incidents and remediation actions.

Building Internal Capability

Initially, PADISO may be your delivery partner, but the goal is to build internal capability so your agency can evolve Superset independently. This involves:

• Training your team: Hands-on workshops on Superset administration, semantic layer design, and troubleshooting.
• Documentation: Comprehensive runbooks and architecture guides.
• Mentoring: Pairing your engineers with PADISO’s team during the engagement.
• Transition planning: A formal handover process where PADISO gradually reduces involvement and your team increases ownership.

This transition typically takes 3–6 months. By month 6, your team should be able to:

• Provision new users and manage roles.
• Create and modify dashboards.
• Troubleshoot common issues.
• Apply Superset updates.
• Review audit logs and respond to incidents.

Exploring Advanced Patterns

Once the baseline Superset deployment is stable, consider:

• Federated analytics: Multiple agencies sharing a single Superset instance with strong logical isolation, reducing operational overhead.
• Agentic BI: Integrating Claude or similar LLMs to allow natural-language queries, as discussed in PADISO’s agentic AI guide.
• Custom plugins: Building agency-specific visualisations or data connectors.
• Embedded analytics: Embedding Superset dashboards in agency portals or citizen-facing applications.
• Real-time streaming: Integrating Apache Kafka or similar for real-time data ingestion and dashboard updates.

These advanced patterns are typically explored in year 2 and beyond, once the baseline is stable and the team has developed expertise.

Conclusion: IRAP-Aligned BI as a Competitive Advantage

Apache Superset on D23.io is not just a cost-saving measure; it is a strategic capability for federal agencies. By deploying open-source, self-hosted BI on Australian government infrastructure, agencies achieve:

• Data sovereignty: Data remains under your control, encrypted with your keys, audited by your team.
• Cost efficiency: No per-user licensing, no vendor lock-in, no overseas data transfer fees.
• Audit readiness: IRAP-aligned controls built in from day one, reducing assessment overhead.
• Operational independence: Your team owns and evolves the platform, not a vendor.

The 6–8 week pattern outlined here has been validated across multiple federal deployments. By week 8, agencies have a production-ready, audit-hardened BI platform serving hundreds of users and supporting critical decision-making.

The next step is to engage a partner—like PADISO—who understands both federal compliance requirements and the technical depth of Superset. Together, you can architect a BI platform that is secure, scalable, and distinctly Australian.

For more information on how PADISO can support your federal BI transformation, visit PADISO’s website or contact the team directly. We specialise in federal-grade infrastructure, IRAP-aligned deployments, and building data capabilities that stand up to scrutiny.