Which SOX access requirements Superset can support for financial reporting dashboards
If Superset dashboards feed figures that go into financial reporting, those dashboards can fall in scope for SOX IT general controls over access, and the answer depends on whether the figures support a control over financial reporting. Superset can support the access side of that work: user provisioning and removal through your identity provider, mapping of groups to Superset roles, restriction of admin privileges, and logs of who opened or changed what. It cannot decide scope, design your control matrix, or prove operating effectiveness on its own. Under SEC Release 33-8810, management evaluates the IT general controls needed for the proper and consistent operation of controls that address financial reporting risks, and it does not need to evaluate controls that only affect operational efficiency. Start by listing which dashboards, datasets and databases feed those figures, then work back to the controls that depend on them.
The configuration decisions that matter most are where login is handled and who can administer the platform. Confirm that authentication goes through your identity provider, that accounts are created and disabled there, and that the AUTH_ROLES_MAPPING setting maps only the groups your access model defines to Superset roles. Keep Admin and other privileged roles to a short, named list, and record who holds them. Check the Superset configuration documentation for the authentication and role options that your version supports, since the exact behavior of group sync and local fallback logins should be confirmed in a test environment before an auditor asks. Decide where Superset's own event and audit records are stored and how long they are retained, because a removal or role change is only evidence if the record exists.
DeployOpen prepares systems, controls and evidence for compliance assessments. It does not issue audit reports, attestations or certifications, and it does not act as your external auditor. Management owns the control design, the periodic access reviews and the conclusion on ICFR, and the external auditor tests operating effectiveness under PCAOB AS 2201 by combining inquiry, observation, inspection and re-performance. Your team should ask for a written scope that names the in-scope dashboards, roles and log sources, and that states which evidence the implementation will produce. Before the first review cycle, run a test provisioning, a removal and a role change, and keep the outputs so the review population can be reconstructed.
Mapping SOX ITGC access requirements to Superset configuration
This table maps each SOX-relevant access requirement to the Superset capability that supports it, the configuration to set, and the process the company must still own. Read it as a split of responsibility: Superset enforces and records access, while the company decides who should hold it, reviews it and proves it operated over the period.
| Requirement | Superset capability | Configuration to set | What remains the customer's process |
|---|---|---|---|
| SEC Release 33-8810: access to programs and data as an ITGC area | Superset authenticates users through Flask-AppBuilder, with login delegated to an OAuth2 provider or LDAP directory and roles held in the metadata database | Set AUTH_TYPE to an OAuth or LDAP mode, disable local password logins for workforce users, and confirm no shared accounts exist in the metadata database | Defining which dashboards and datasets support financial reporting, documenting them as in scope, and retaining the list for the auditor |
| AS 2110 B4: unauthorized access to data and excessive privileges breaking segregation of duties | Roles and permissions in Superset control which datasets, charts and dashboards each user can open, and admin roles grant broader rights | Use AUTH_ROLES_MAPPING so IdP groups drive roles, restrict Admin to a named minimal group, and separate report authors from approvers | Designing the segregation matrix, confirming no one both builds and approves a financial metric, and resolving conflicts found in review |
| AS 2201 paragraph 44: authority and competence of the person performing the control | Role assignments record who holds which access, so the reviewer and the reviewed user can be identified from exports | Assign access reviews to a named owner in the IdP group, and export role and user lists from the metadata database for each review | Confirming reviewers have the business knowledge and authority to approve access, and documenting their appointment |
| AS 2201 paragraph B33: access controls as part of the IT control environment | Authentication, role mapping and user records form the access control layer that determines how long an auditor can rely on automated controls | Set SECRET_KEY explicitly, restrict database and dashboard permissions by role, and keep the Superset configuration under change control | Maintaining the change records, approvals and environment separation that show the access layer did not change unexpectedly |
| AS 2201 paragraph 47: reliance on effective ITGCs for automated controls | Superset applies row level and dataset permissions consistently on every query when roles are configured correctly | Test row level security and dataset access for each role before go-live, and retest after role or mapping changes | Testing operating effectiveness across the period, which may require inquiry, observation, inspection and re-performance |
| COSO 2013 Principle 11: general control activities over technology | Superset provides configuration points for authentication, roles and logging that management can document as control activities | Document each Superset access setting as a control with an owner, frequency and evidence source | Writing the control narrative, assigning owners, and monitoring whether the controls run as designed each period |
| Joiner, mover and leaver removal through the IdP | Superset accepts users from the IdP on login, so removing a user in the IdP blocks new sign-ins to Superset | Enable user attribute sync on login and confirm disabled IdP accounts cannot reach Superset, and test removal timing | Defining the provisioning trigger, timing for removals and who checks that terminated staff lost access |
Configuring Superset access for SOX ITGC review
This sequence sets up Superset so that access to financial reporting dashboards is granted through the identity provider, limited to named roles, and changed only under control, which gives management and the external auditor a consistent population to test. It starts with scoping and ends with change control over role mappings.
Scope the in-scope dashboards and datasets
Finance, controllership and IT leads list every dashboard, chart, dataset and database connection that feeds a financial reporting control, and record which of them an auditor would rely on. Map each one to the process it supports and to the owner who approves access. Keep this list as the controlled population for every later step. The step is done when the owner has signed off the list and each in-scope asset has a named business owner.
Configure SSO-only login through the identity provider
The identity administrator connects Superset to the organization's identity provider using the OAuth2 or LDAP settings documented for Superset and Flask-AppBuilder, so that every workforce user signs in with corporate credentials. Confirm that the provider enforces its own multi-factor policy for these users. The step is done when a test user can sign in through the provider and the login page offers no path that bypasses it.
Map identity provider groups to Superset roles
Using AUTH_ROLES_MAPPING, the Superset administrator maps each identity provider group to a documented Superset role, and writes the mapping as a versioned configuration file that is reviewed before release. Only groups that correspond to an approved business role should appear in the mapping. The step is done when a test account in each group receives exactly the expected roles and no others.
Remove local password logins for workforce users
The Superset administrator disables or removes local database accounts for workforce users and confirms that no account can sign in with a stored password. Any remaining local account is documented with its owner and reason, and it is reviewed on the same cycle as privileged access. The step is done when an export of the user table shows no active workforce account with a local password and the exceptions list is approved.
Restrict the Admin role to named privileged accounts
The security lead limits the Admin role to a short list of named individuals who need it for administration, and assigns everyone else analytical roles. Because AS 2110 names IT personnel holding privileges beyond their duties as a segregation of duties risk, the list should separate dashboard authors from people who can change access. The step is done when the Admin list is approved, each privileged account is linked to a named person, and no shared administrator account remains.
Set SECRET_KEY and plan its rotation
The platform engineer sets SECRET_KEY in the deployment configuration, which Superset requires before it starts, and stores it in the organization's secrets manager rather than in source control. For rotation, the engineer uses PREVIOUS_SECRET_KEY as documented, records the rotation date and approver, and tests the procedure in staging first. The step is done when the key is stored outside the repository, a rotation runbook exists, and a staging rotation has been completed and logged.
Confirm a supported production metadata database
The platform engineer confirms that the metadata database runs on PostgreSQL or MySQL in a supported version listed in the configuration documentation, with backups that the auditor can see. The SQLite default used by Quickstart and PyPI installs is not recommended for production, and the Docker Compose PostgreSQL container is also not recommended for production. The step is done when the version, backup schedule and restore test result are documented.
Establish change control for roles and mappings
The Superset owner and the IT general controls lead agree a written change process in which every change to role definitions, group mappings, Admin membership or configuration is requested, approved by someone other than the requester, and logged with its evidence. Access reviews later compare current state against this approved record. The step is done when the process is written, the first approved change is traceable from request to deployment, and the auditor has been shown the procedure.
Evidence Superset produces for an auditor testing access
An auditor testing operating effectiveness will inquire, observe, inspect and re-perform, so the evidence has to exist before the test starts. The cards below cover what comes from the identity provider, what comes from Superset's metadata database, and what comes from change records, along with how to retain and sample each set.
IdP provisioning and removal records
Superset sign-in should go through the identity provider, so the provisioning and deprovisioning history of each Superset account lives in the IdP's own logs and tickets. Auditors inspect those records, not Superset alone, to confirm that a joiner was approved and a leaver was removed on time. Ask the IdP team which events are logged, how long they are kept, and whether a removal in the directory flows through to Superset sign-in. Sample leavers from HR termination lists and trace each one to a removal event.
Exported user and role lists
Run a dated export of users, their active flags, last login and assigned roles from the metadata database, using a read-only account. This list is the population for the periodic access review, so it must be complete and reproducible. Record the query, the database name and the export time alongside the file. Re-running the same query later should return the same population, which is what re-performance depends on.
Role-to-group mapping configuration
Where Superset maps IdP or directory groups to roles through AUTH_ROLES_MAPPING, the mapping file is the documented rule for who receives which role. Version it in source control and store the approved revision with the change record. An auditor can then compare the mapping against the approved access model and check that each financial reporting dashboard role traces to a named business owner.
Admin role membership lists
Privileged access is tested by listing every account holding Admin or other high-privilege roles, then checking each one against an approved list. Keep a dated membership report for each review period and note any account that holds an admin role outside its job function. Segregation of duties matters here: the people who build financial dashboards should not also approve their own access changes, so compare this list with the approvers recorded in the access ticket system.
Permission and role change logs
Some deployments capture events for role and permission edits in the application or in a central log pipeline, but the scope of what is logged depends on the version and configuration. Confirm with the vendor documentation and your own log pipeline which events are recorded, where they are stored and how long they persist. If a change is not logged, the access review must compensate, for example by comparing consecutive exports. Auditors will ask how completeness of the log was verified.
Upgrade change tickets
Each Superset upgrade can change authentication behavior, roles or permissions, so it needs its own change record. Attach the upgrade guide steps performed, the metadata database backup reference, staging test results and the post-upgrade role export. Review the release notes for breaking changes before approval. A dated ticket with that evidence shows the change was controlled and that access settings were rechecked after it.
Running a periodic Superset access review that an auditor can re-perform
A periodic access review is only useful to a SOX auditor if someone else could repeat it and reach the same result. Under PCAOB AS 2201 (paragraph 44), the auditor checks whether a control operates as designed and whether the person performing it has the necessary authority and competence. For Superset, that means the review should name the owner of each in-scope dashboard, the dataset and database connections behind it, and the roles that grant access to them. Each dashboard owner confirms the population of users and roles that should see it. The reviewer should be someone with authority over that data who is not also the person who administers the accounts, so that the review does not check the administrator's own work. Management decides how often the review runs, and that frequency and the reviewer roster should be written into the control description before the first cycle.
The reviewer then compares three sources: a current export of users and their roles from Superset, the membership of the identity provider groups that map to those roles, and the HR status of each person. Superset's user and role lists can be exported through the admin interface or the API, and the export should be saved with its date and the name of the person who produced it. Accounts that are active in Superset but absent from the IdP group, or belong to someone who has left or changed jobs, are exceptions. Each exception needs a recorded decision, a revocation request, and a completion date. Track revocations to closure in your ticketing system and keep the evidence that the role was removed or the account was disabled. Sign and date the completed review for each dashboard owner. Ask your auditor which sample sizes and evidence formats they expect before the first run.
Public dashboards and embedded access fall outside the ordinary role review, because a viewer may see content without holding a Superset user account at all. Build a separate inventory of every dashboard flagged as public, every guest token issuing path used by an embedded application, and the owner of each. Review that inventory on the same cycle as the role review, and confirm that each entry still needs to be visible to the audience it reaches. Check the Superset configuration for the settings that control public access and guest tokens, and confirm their current values against your documented design, since the exact settings depend on your Superset version. Auditors will ask how this inventory is kept complete, so record how new public or embedded content gets added to it.
What Superset does not cover for SOX ITGCs
Superset gives you access controls and logs for dashboards, but the scoping decisions, the management evaluation and several control areas sit outside the application. The cards below name the boundaries your SOX program has to document and test in other systems.
Scoping which dashboards matter
Superset does not know which dashboards feed a financial statement line, a reconciliation or a disclosure. Management decides that, usually by mapping each dashboard and dataset to the processes it supports. Record the scoping decision in your ICFR documentation and tie each in-scope dashboard to its owner, its datasets and the roles allowed to view or edit it. Superset will enforce whatever you configure, but it will not tell you what to configure.
Management's ICFR evaluation
Superset produces role exports and logs, but it does not perform the management evaluation required under Rule 13a-15(c) or issue an audit opinion. Management must assess the controls, document its conclusions and retain evidence each fiscal year. External auditors test those controls under PCAOB AS 2201 using inquiry, observation, inspection and re-performance. Plan who runs each test and where the evidence is stored before the auditor asks.
Change control and computer operations
Program change control and computer operations are separate ITGC areas that Superset does not cover. Changes to Superset's configuration, container images and Python packages travel through your deployment pipeline, while the host, the database and backup jobs have their own change records. Auditors will ask for approvals and testing for each. Confirm where those records live and that a Superset configuration change cannot reach production without them.
Joiner, mover and leaver processes
Superset only reflects the identities it receives. The HR events that trigger a new hire, a transfer or a termination, and the IdP workflows that act on them, sit outside Superset. Check that disabling an account at the IdP blocks Superset sign-in, that group changes flow into role mappings, and that the timing of removal meets your own policy. Local Superset accounts that bypass the IdP need their own removal process.
Alpha deployment tooling
The Apache Superset Kubernetes Operator is in alpha with a v1alpha1 API, and its custom resource schemas may change between releases. If it manages your production Superset, a schema change can alter the deployed configuration without a clear diff in your review. Treat the operator as a change-controlled dependency, pin its version, test upgrades in staging and keep the rendered configuration as evidence.
Warehouse privileges and query-level access
Superset connects to databases with credentials that determine what it can read, and row level security or dataset restrictions only limit what Superset displays. Direct database access, service accounts and privileges granted in the warehouse can bypass Superset entirely. Review the database role behind each connection, confirm it cannot write to financial tables, and include those grants in the same access review as Superset roles.
Questions finance and IT teams ask about Superset and SOX access
Are all Superset dashboards in scope for SOX IT general controls?
No. Scope depends on the financial reporting role of the output, not on the tool that displays it. A dashboard that feeds a figure into the financial statements, a key reconciliation or a management review control is usually in scope, because the access and change controls over the data it shows can affect whether that control operates as designed. An exploratory dashboard that no control relies on generally is not. Management decides this with the external auditor, so start by listing every dashboard, its data sources and the control, if any, it supports. The SEC guidance on IT general controls asks management to evaluate only the controls needed for other financial reporting controls to operate consistently.
How long does SOX access work on Superset take, and what drives it?
No general duration applies, because the effort depends on the facts of each environment. The main drivers are the number of in-scope dashboards and their data sources, the maturity of your identity provider and its group structure, how many roles Superset needs after review, and how long you must retain evidence. Work is faster when provisioning already flows from HR through the identity provider and when dashboard owners are named. Ask any partner to show the written scope, the list of assumptions and the milestones before agreeing to a timeline, and confirm the scope with your auditor before build starts.
What cost components should a quote for this work cover?
A quote for this work should break the cost into five components:
- Scoping: inventory of in-scope dashboards, data sources and control owners, agreed with your audit team.
- Configuration: SSO-only login, group-to-role mapping and admin role restrictions in Superset.
- Evidence design: the role export, access review and change log formats your auditor will test.
- Testing: reperformance of provisioning, removal and review steps before the auditor arrives.
- Handover: runbooks and training for the team that keeps the controls running.
Ask which parts are one-time and which recur, and whether the quote assumes your staff provide IdP and HR data access. Fixed-scope work is agreed in writing before it starts.
Can our internal team implement SOX access controls for Superset?
Yes, if your team has two things. The first is working skill in your identity provider and in Superset administration, including Flask-AppBuilder role design and group mapping. The second is independence: the people who configure access should not be the same people who review it or approve their own admin access, because that overlap undermines the segregation of duties the control is meant to show. Many organizations keep configuration in-house and bring in outside testing to check it. Assess your team against the scope list before deciding, and document who performs each step and who reviews it.
What does the work need from our staff?
The work depends on four groups of people. Identity provider administrators must grant configuration access and confirm how user and group changes flow from HR. HR data owners must confirm joiner, mover and leaver events and who is authorized to approve access. Dashboard owners must confirm which dashboards support financial reporting, who needs each role and what their data should be limited to. An auditor liaison should agree the evidence format and sampling approach early, so configuration is not rebuilt late. Ask for these commitments, with named people and dates, in the written scope.
Can DeployOpen certify that our Superset access controls comply with SOX?
No. DeployOpen configures systems, prepares controls and evidence, and tests them, but it does not issue audit reports, attestations or certifications. Management is responsible for its annual assessment of internal control over financial reporting, and for accelerated and large accelerated filers that are not emerging growth companies, an independent auditor attests to that assessment under Section 404. Your auditor decides whether the controls are effective. Use DeployOpen's work as preparation and ask your auditor to confirm which evidence they will test.
What recurring work follows go-live for Superset access controls?
Several controls recur after go-live. Joiner, mover and leaver changes must flow through the identity provider and be checked against the approved role model. Periodic access reviews must be performed by someone independent of the administrators, with the review retained as evidence. Changes to admin roles, role mappings and dashboard permissions should be logged and reviewed. Superset upgrades need a backup of the metadata database, staging tests and a check of UPDATING.md for breaking changes, and each upgrade can affect role and authentication behavior. Plan who owns each recurring step and budget for it as an operating cost, whether it is done in-house or under a retainer.
Keeping Superset upgrades inside change control
Treat every Superset upgrade as a change under management control, because a new version can alter how roles, permissions and row level security behave. A version change that quietly shifts what a financial reporting role can see is exactly the kind of unauthorized or improper change an auditor will ask about. Record each upgrade as a change ticket with its approval, the target version, the test results and the post-change access review. Back up the metadata database first, since that database holds the users, roles and permission assignments the access review depends on. Then run superset db upgrade and superset init in that order, as the upgrade documentation describes.
Before any production change, read the breaking change notes in UPDATING.md for every version between your current release and the target, and apply them to your own role design. Run the full upgrade in staging against a copy of the production metadata database, not an empty one. Once staging is up, repeat the access review from your control design on the staging result: confirm that each user's roles, dataset access and RLS filters still match the approved list, and that admin roles have not gained members. Keep the before and after exports with the change ticket. If you need release dates for planning, confirm them against the Apache Superset releases on GitHub page, which lists 7.0.0rc2 as a pre-release dated October 16, 2026. Do not schedule a production upgrade to a pre-release version for a controlled environment.
How DeployOpen scopes and delivers SOX access controls for Superset
DeployOpen plans, implements and documents Apache Superset inside your own infrastructure, with the access controls that support financial reporting dashboards designed up front. Engagements are fixed-scope, so the in-scope dashboards, identity integration, role design and evidence outputs are agreed in writing before work starts.
How we scope
- Inventory which Superset dashboards and datasets feed financial reporting controls, and which only affect operations.
- Document the identity provider, group sources and owners that will govern Superset access.
- Agree in writing which admin roles, provisioning paths and review cycles are covered and which are excluded.
How we build
- Configure SSO through your identity provider and map groups to Superset roles so access follows directory membership.
- Restrict admin roles to named, approved accounts and test that privileged changes are logged and attributable.
- Test provisioning, removal and role changes against your written control design, including re-performance of sample cases.
How we hand over
- Deliver a written access control design, role matrix and runbook for user provisioning, removal and periodic review.
- Provide documented test scripts, sample evidence exports and a walkthrough so your team can re-run the checks.
- Record configuration as code where practical so changes to roles and authentication can be reviewed and traced.
How we support
- Offer ongoing support, upgrade planning and continuous testing as a retainer, scoped in a separate written agreement.
- Plan Superset upgrades in staging with metadata database backups and review of breaking changes before production.
- Confirm with your auditors which evidence they will accept, since DeployOpen prepares controls and evidence but does not issue audit opinions.
Sources and further reading
- Commission Guidance Regarding Management's Report on Internal Control Over Financial Reporting, Release 33-8810 ↗
- PCAOB Auditing Standard No. 5 (now AS 2201) as filed with the SEC, Release 34-55876 ↗
- PCAOB risk assessment standards, including Auditing Standard No. 12 (now AS 2110), as filed with the SEC, Release 34-62919 ↗
- Apache Superset docs: Configuring Superset ↗
- Apache Superset docs: Upgrading Superset ↗
