How Apache Superset supports HIPAA access control and audit controls
A covered entity or business associate putting ePHI behind Superset dashboards needs to show that only authorized workforce members can reach that data and that their activity is recorded. Superset can support two technical standards, 45 CFR 164.312(a)(1) access control and 164.312(b) audit controls, but it cannot carry the rest of the Security Rule. Risk analysis, workforce security, policies, physical safeguards and business associate contracts under 164.314 remain organizational work. Within the technical scope, the configuration choices are concrete: login through your identity provider so each person has a unique identifier, roles that limit which datasets and charts a user can open, row level security by facility or role, session timeouts for automatic logoff, and retention of the action logs your team reviews. Confirm each of these against the Superset version you run, since authentication and logging options differ between releases.
DeployOpen prepares the configuration, the documented settings and the evidence package for these controls. It does not certify your organization, and it does not issue an attestation or audit report. HIPAA has no certification: HHS states that no Security Rule standard requires certifying compliance and that HHS does not recognize private certifications. Where a third party is involved, such as a HITRUST assessment that some customers request, that work is performed by the assessor, not by DeployOpen. The HHS OCR HIPAA Audit Program page describes how the regulator reviews compliance, and it is the right reference for what an examiner will ask to see.
Before scoping any build, decide which dashboards and datasets contain ePHI, who needs them, and what your risk analysis says about each. Then ask the project to confirm the Superset version, the metadata database, the identity provider and whether the Superset API and export features are enabled for those datasets. Those answers determine which controls can be configured in Superset and which must be handled by the database, the network or your procedures. Also confirm that the business associate agreements under 164.314 cover the hosting platform, database and any support staff who can reach the system.
Mapping HIPAA technical safeguards to Superset configuration
This table maps the HIPAA access control and audit standards to the Superset capability that supports each one, the configuration involved, and what stays open for your own assessment. Read each row as a question an assessor will ask, with the Superset answer on the right and the decision you still own in the last column. Superset supplies mechanisms, but the rule leaves the policies, logoff time and review procedures to your organization.
| Requirement | Superset configuration | What remains open |
|---|---|---|
| 164.312(a)(1) access control | Limit dashboards, datasets and databases through Superset roles and row level security, so only granted users can reach ePHI | You define which workforce roles may see which patient data and document the basis under 164.308(a)(4) |
| Unique user identification (required) | Set login through your identity provider with OAuth2, LDAP or a custom OAuth2 server, so each person has an individual account and no shared logins | Confirm that local accounts are disabled for workforce users and that shared service accounts are documented and restricted |
| Emergency access procedure (required) | Keep a break-glass administrator path that is documented, tested and separate from routine admin roles | Superset does not define this for you; write the procedure and decide how access is granted and logged during an outage |
| Automatic logoff, 164.312(a)(2)(iii) (addressable) | Configure session lifetime and inactivity settings in Superset and the identity provider, then confirm they apply to browser and API sessions | The rule does not set a time limit; set it through your own assessment and document the decision if you choose an alternative |
| Access authorization, 164.308(a)(4) | Map identity provider groups to Superset roles with AUTH_ROLES_MAPPING and review role membership on a schedule | Who approves access, how often reviews run and how removals are triggered are policy decisions for your organization |
| 164.312(b) audit controls | Use Superset logs for dashboard views, queries and permission changes, and forward them to your central log store | Confirm which events Superset records in your version, define what is reviewed, by whom and how often, and set retention |
| Metadata database and secret handling | Run the metadata database on PostgreSQL or MySQL rather than SQLite, and set a SECRET_KEY that you rotate with PREVIOUS_SECRET_KEY | Confirm encryption of the metadata database and backups under your own risk analysis, since the rule lists encryption as a separate addressable specification |
Which audit evidence Superset produces and how to keep it
An auditor testing 164.312(b) will ask what Superset recorded, who can read it, and how long it was kept. The cards below cover the artifacts to export, where they live, and the review cycle that makes them count as activity review rather than stored files.
Role and permission exports
Export the role list and the permissions attached to each role on a fixed schedule, using the Superset admin interface or the metadata database under read-only access. Compare each export with the role design approved for ePHI datasets. Record who approved each change, since a role that grants dataset access to a new group is the first thing an auditor will look for. Keep the export dated so it can be matched to log entries from the same period.
IdP group to role mappings
Keep the AUTH_ROLES_MAPPING configuration and the matching group definitions in the identity provider under version control. Each mapping shows which directory group grants which Superset role, which is the basis for showing unique, authorized access. Retain the commit history and review approvals alongside it. When a group is renamed in the IdP, the mapping must change in the same window or access will silently drift.
User lists and account lifecycle records
Export the Superset user list with status, last login and assigned roles. Compare it against the workforce roster from HR and the IdP to find active accounts for people who have left or changed roles. Local accounts created outside the IdP should appear as exceptions with a documented reason. Keep each export so you can show when a user was added, changed or deactivated.
Action and event logs
Superset records user activity such as queries, dashboard views and permission changes in the metadata database or in a log sink you configure. Confirm which events your deployment captures, where they are written and how long the database or sink keeps them before you rely on them as evidence. Ship logs off the application host to a store the Superset administrators cannot edit, and test that a sample login and query appear there.
Configuration baselines
Keep a dated copy of superset_config.py and the container or Helm values that produced the running system. Include the session timeout settings that support automatic logoff under 164.312(a)(2)(iii), the authentication settings, and the export and database connection options. Each baseline should show the approved values and the person who signed them off, so a change between two dates can be explained.
SECRET_KEY rotation records
Record each rotation of SECRET_KEY, including the date, the approver, the previous key's retirement, and the use of PREVIOUS_SECRET_KEY during the transition. Store the record in the secrets manager and keep only key identifiers in the change log, never the key value. Rotation is a control event, so an auditor may ask whether sessions were invalidated as expected.
How Superset logins, roles and RLS fit together
A Superset user reaches ePHI through four layers in sequence: identity provider login, role assignment, row level security and the metadata database that stores all of it. For the 164.312(a)(1) access control, the first layer is what makes a user unique. Flask-AppBuilder, the framework Superset is built on, can delegate sign-in to an OAuth2 provider, an OIDC-style provider or LDAP, so the workforce member authenticates with the organization's own directory rather than a local Superset password. Confirm with your identity team which protocol your IdP exposes and whether the login session enforces multi-factor authentication there, since Superset itself does not decide that.
Groups from that identity provider are then translated into Superset roles through AUTH_ROLES_MAPPING in the configuration file. This is the point where a clinician's group membership becomes a set of dataset and dashboard permissions. Row level security filters sit on top of those roles and restrict which rows a query returns, for example by facility or care team. A useful check before go-live is to log in as one test user per role and confirm that the mapped role and the RLS clause together return only the expected records. Treat the mapping and the RLS rules as one access design and review them together. (Illustrative: a user in a group for Facility A should see zero rows from Facility B.)
The metadata database holds users, roles, dashboards, datasets and RLS definitions, so its security is part of the access control. The architecture documentation says production deployments should use PostgreSQL or MySQL, not the SQLite default used by quickstart or PyPI installs, and the configuration documentation lists the supported versions. The optional caching layer and Celery workers are needed for alerts, reports, async queries and thumbnails, and they hold query results and scheduled delivery, so they fall inside the ePHI boundary too. Ask whether any scheduled report can deliver rows outside the RLS filter that applies to the recipient, and document the answer in the risk analysis.
Configuration sequence for HIPAA-aligned access and logging
This sequence turns Superset into a system where each ePHI dataset has a named owner, every person signs in with a unique account, access follows documented roles and facility scope, sessions end on inactivity, and activity is logged and reviewed. Each step ends with an artifact an auditor or security lead can inspect.
Scope ePHI datasets and collect risk analysis inputs
Start by listing every Superset database connection, dataset, chart and dashboard that touches ePHI, and record which tables hold patient identifiers, clinical data or billing data. Ask the security officer to confirm these inputs feed the entity's risk analysis under 164.308, because the access and logging decisions below depend on them. Assign a data owner to each dataset. Done means a signed inventory that names the owner, the source database, the workforce groups that need the data and any business associate that hosts the source. Confirm the scope with your compliance lead before any role work starts.
Enforce IdP-only login with unique accounts
Configure Superset to authenticate through your identity provider using OAuth2 or LDAP, as described in the Superset configuration documentation, and disable local password logins for workforce users. Keep one local break-glass administrator account under documented control to meet the emergency access procedure under 164.312(a)(2)(ii). Confirm that no shared accounts exist by comparing the Superset user list against the IdP directory. Done means every active user maps to one IdP identity and the break-glass account is recorded, sealed and tested.
Map identity provider groups to Superset roles
Use AUTH_ROLES_MAPPING to translate IdP groups into Superset roles that match the job functions identified in step one. Keep administrative roles in a separate, smaller group and avoid granting broad built-in roles to clinical users. Have the data owner approve each mapping in writing. Test with a few sample accounts from each group to confirm they see only their assigned datasets. Done means a role matrix that lists each group, its Superset roles, its datasets and its approver, plus test results for each group.
Design row-level security by facility or role
Define row-level security filters on ePHI datasets so users see only the facility, department or patient population their role requires. Write each filter as a short, reviewed predicate tied to a group attribute, and keep the filter logic in version control. Test each filter with accounts from different facilities to confirm that no rows leak across boundaries, including through saved charts and exports. Done means a filter register with each predicate, its owner, its test case and the date it was last verified.
Set session timeout and logoff behavior
Set session lifetime and inactivity behavior in the Superset configuration so that idle sessions end after a period your entity sets through its risk analysis. The rule does not fix a number, so record the chosen value and its rationale. Apply the same setting to the reverse proxy and the IdP session where applicable, so the shortest timeout governs. Test by leaving a session idle in a staging browser and confirming that the next request requires sign-in. Done means a documented timeout value and a test record showing forced logoff.
Enable action logging and set log retention
Turn on Superset's event and action logging, then send logs to a central store that your security team controls, so that record of who viewed, exported or changed ePHI content is kept outside the Superset host. Set a retention period that your policy and any state or contractual obligations require, and confirm it with your compliance lead. Verify by performing a test view, a test export and a test role change, then finding each event in the central store with the user identity and timestamp. Done means a log source, a retention setting and three verified test events.
Document activity review procedures
Write the activity review and audit policy and the standard operating procedure that tells a named reviewer what to examine, how often, and how to escalate anomalies, following the key activities in NIST SP 800-66 Rev. 2 for this standard. List the events to review, such as failed logins, exports, role changes and access to restricted datasets. Record each review with reviewer, date and findings. Done means an approved SOP and a first completed review record that an auditor can trace back to the logs from the previous step.
Test in staging and follow upgrade guidance before production
Build the complete configuration in a staging environment that mirrors production, then run the access and logging tests from the previous steps. Before any Superset version change, back up the metadata database, run the documented upgrade commands, and check UPDATING.md for breaking changes, as the Superset upgrade documentation directs. Re-run the role, RLS, timeout and log tests after each upgrade. Done means a signed test report, a change record and a rollback plan that the security owner approves before production changes go live.
What Superset does not cover under the HIPAA Security Rule
Superset can enforce identity, row-level access and activity records for analytics, but the Security Rule asks for much more than one application. The cards below mark the obligations that remain with your organization, your business associates and your governance program.
Risk analysis and risk management
The Security Rule expects an accurate and thorough assessment of risks to ePHI before controls are chosen, and an ongoing process to reduce them. Superset's settings do not produce that analysis. Your team should list every Superset component that touches ePHI, including the metadata database, cache, Celery workers, exports, scheduled reports and the warehouse connections, and rate each one. NIST SP 800-66 Rev. 2 offers sample questions for this work.
Workforce security policies and training
Access rights under 164.308(a)(4) decide who may use Superset, and those decisions come from written policies, not from the tool. Your policies should define who approves a role, how joiners, movers and leavers are handled in the identity provider, and how access reviews are documented. Training should cover exporting data, sharing dashboard links and handling unexpected results. Confirm that your HR and access request processes feed the IdP that Superset relies on.
Emergency access procedure
164.312(a)(2)(ii) is a required implementation specification, so you need a documented way to reach ePHI in Superset during an outage or emergency. Single sign-on can fail, and a break-glass local administrator account must be controlled, monitored and tested. Decide who holds that account, where its credentials are stored and how its use is logged and reviewed. Verify that the procedure works against your actual IdP and metadata database setup before you need it.
Encryption decisions
Encryption is an addressable specification under 164.312(a)(2)(iv), so you must assess it, implement it or document an equivalent measure. Superset does not decide this for you. Confirm TLS on the browser path, encrypted connections from Superset to the metadata database and warehouses, and encryption at rest for the metadata database, cache and any stored exports. Record the reasoning for each choice, because an auditor will ask how the assessment was made.
Business associate agreements
If a vendor, hosting provider or consultant can access ePHI in your Superset environment, 164.314(a)(2)(i) requires a business associate contract. It must require Security Rule compliance, flow the same terms to subcontractors that handle ePHI, and require reporting of security incidents. Confirm that agreements exist with every party that can reach the database, the hosting platform or the support channel. Read the contract text with counsel, because a DeployOpen engagement does not replace these agreements.
Physical and facility safeguards
The physical standards in 164.310 cover facility access, workstation use and device handling, and Superset depends on them. Servers, backup media, hypervisor consoles and the laptops used to view dashboards all sit outside the application. Your data center or cloud provider controls, screen locking on shared workstations and disposal of old media need their own procedures and evidence. Document where each Superset component runs and who can physically reach it.
No HIPAA certification and a pending rule
No Security Rule standard requires certification, and HHS does not recognize private certifications, which do not prevent a later violation finding. Be cautious with any vendor or partner that claims HIPAA certification for Superset. HHS proposed a major Security Rule revision in 90 FR 898 on January 6, 2025. As of October 2026 no final rule has been published, and the Unified Agenda projects final action for July 2027, so confirm current requirements before each review.
Questions buyers ask about Superset and HIPAA
What drives the cost of configuring Superset for HIPAA access control?
The cost depends on how many data sources, facilities and roles need separate treatment, how many identity provider groups must map to Superset roles, and how much of the audit trail must be proven rather than assumed. The main components are discovery of which ePHI datasets exist, identity provider work with your IdP team, Superset role and row level security design, logging and retention setup, and a test pass that shows the controls behave as written. Most of this is one-time work. Recurring costs include role reviews, Superset upgrades and any retainer for ongoing support. Ask any provider for a written scope that lists each of these components, who performs each one, and which items are excluded, such as database-side permissions or the wider HIPAA program.
How long does it take to configure Superset access controls for ePHI?
Duration depends on the number of datasets, the state of your identity provider groups, and whether your facility and role model is already written down. Teams with clean groups and documented roles move faster than teams that must first decide who should see which patients. Ask for a timeline tied to a written scope with clear milestones, and check whether it includes staging validation and a review of the audit logs. Your own IdP and data teams will set the pace more than the Superset configuration itself, so agree their availability before the timeline is final.
What does the work need from our identity provider and data teams?
The work needs your identity team to confirm which directory or IdP is the source of truth, to provide test accounts, and to agree which groups or claims map to Superset roles. Your data team needs to identify the ePHI datasets, the database accounts Superset uses, the facility or role attributes that should drive row level security, and the owners who approve access. Both teams should also confirm how joiners, movers and leavers are handled, since Superset login must be removed when the IdP account is disabled. Without these inputs, role mapping and row level security cannot be tested against real access decisions.
Can our own team configure Superset for HIPAA without a partner?
Yes, if your team has engineers who can run Superset, configure an OAuth2 or LDAP login, manage Flask-AppBuilder roles and test row level security. Many organizations split the work: internal staff own the identity provider and data access decisions, while a partner handles the Superset build, test evidence and documentation. The questions to answer honestly are whether you have time to build the test plan, whether someone will keep the configuration current through Superset upgrades, and whether you can produce evidence an auditor will accept. Your legal or compliance team should also decide how the work fits into your Security Rule risk analysis.
What is the OCR audit exposure if Superset access is not controlled?
The HHS Office for Civil Rights enforces the Security Rule through complaints, compliance reviews and audits, and its 2024 to 2025 audits review 50 covered entities and business associates on provisions most relevant to hacking and ransomware. For penalties assessed on or after January 28, 2026, the inflation-adjusted civil money penalty under 45 CFR 102.3 (91 FR 3666) ranges from $145 per violation with no knowledge to $2,190,294 per violation for uncorrected willful neglect, with a calendar-year cap of $2,190,294. Exposure depends on the facts of each case, including how you responded to discovered problems. Ask counsel to review your specific obligations rather than relying on these figures alone.
Does a HITRUST assessment replace HIPAA compliance work on Superset?
No. HITRUST is a private framework and assessment, and HHS states that it does not endorse or recognize private certifications, and that they do not prevent HHS from later finding a violation. There is also no HIPAA certification that covers the Security Rule as a whole. A HITRUST assessment may use evidence about Superset access controls, but it tests against its own control specifications, and the assessment does not cover every Security Rule obligation, such as your risk analysis, workforce sanctions or business associate contracts. Your Superset evidence still needs to show how access under 164.312(a)(1) and audit activity under 164.312(b) work in practice. Ask any assessor which requirements they test and which they leave to you.
Which Superset settings do engineers check first for audit logging?
Engineers should start by confirming that every user signs in through the identity provider with a unique account, that local login is disabled or restricted to a break-glass path, and that the session lifetime is set to a value your risk analysis supports. Next, verify which actions are logged, where the metadata database records them, who can read those records, and how long they are kept. Check that row level security filters apply to every chart, dataset and dashboard that touches ePHI, including embedded or exported content. Finally, test a sample of access decisions and confirm that the logs show who viewed what, since a logging setting alone does not prove that activity was recorded and reviewed.
Deciding whether to configure Superset for ePHI in-house
The first decision is whether your own team has the skills to configure Superset for ePHI and evidence it. The work spans three areas: the identity provider that issues unique logins, the metadata and analytics databases that hold dashboard definitions and query access, and the security policy that decides which facilities and roles may see which rows. A team that can already run an OIDC or SAML integration, grant least-privilege database accounts, and write a role matrix tied to 164.308(a)(4) access authorization may be able to do this internally. If any of those three areas is thin, a partner can cover the gap, and the gap is usually the identity or database work rather than Superset itself.
Before building, confirm the questions that only your counsel and assessor can answer. Ask counsel whether the analytics environment falls within your covered entity or business associate scope and whether a business associate contract under 45 CFR 164.314(a)(2)(i) is needed for any hosting or support vendor that can reach ePHI. Ask your assessor which addressable specifications, such as automatic logoff under 164.312(a)(2)(iii), they expect to see implemented or documented with an equivalent measure. Confirm with your own environment how the identity provider, metadata database and warehouse are hosted, because that determines where log and session evidence lives.
Whichever route you choose, the implementation work is fixed-scope and agreed in writing before it starts. A written scope should name the roles, datasets, RLS rules, log destinations and test evidence to be delivered, and it should say who maintains each control after handover. Ask any partner to state those deliverables in the quote, and ask whether ongoing support and upgrades are a separate retainer, since Superset upgrades recur and each one can change security-relevant settings.
How DeployOpen scopes and delivers HIPAA-aligned Superset configuration
DeployOpen plans, builds and documents Apache Superset for HIPAA access control and audit controls inside your own infrastructure. Each engagement starts from a written scope that ties identity, role design, row level security and logging to the Security Rule provisions your team needs to evidence. Superset is open source under the Apache License 2.0, so the configuration and evidence stay in your environment.
How we scope
- Inventory the datasets, facilities and roles that hold or reach ePHI in your Superset environment.
- Map each access and audit decision to 164.312(a)(1) and 164.312(b), plus the related workforce access rules in 164.308(a)(4).
- Agree deliverables, exclusions and timelines in writing before work starts, since most engagements are fixed-scope.
How we build
- Configure SSO through your identity provider so each workforce member has a unique login, with group-to-role mapping.
- Design row level security by facility or role and test it with named accounts before any production dashboard is shared.
- Set session timeout, action logging and export restrictions, and document the values chosen and why for each addressable specification.
How we hand over
- Provide configuration records, role and RLS matrices, and a test log showing which accounts could and could not reach ePHI.
- Write standard operating procedures for access reviews, log review and emergency access, following the activities in NIST SP 800-66 Rev. 2.
- Walk your security and operations staff through the runbooks so they can administer roles and review logs without us.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover.
- Plan upgrades with a metadata database backup, a staging test and a review of breaking changes in each release's notes.
- Prepare the systems, controls and evidence for your assessors. DeployOpen does not issue audit reports, attestations or certifications.
