Which ISO 27001 access controls Apache Superset helps evidence
Apache Superset can support the technical side of A.8.3 Information access restriction, A.5.15 Access control and A.8.11 Data masking, but it cannot satisfy them on its own. Superset enforces what you configure: who can log in, which roles they hold, which datasets and dashboards those roles reach, and which rows a user sees through row level security. The control design, the topic-specific access control policy that sets those rules, and the decision about which information must be restricted or masked remain with your organization. DeployOpen plans, configures and documents the platform and prepares the system settings and evidence an assessor will ask for. DeployOpen does not issue audit reports or certifications. Only an accredited certification body can certify your ISMS.
Annex A of ISO/IEC 27001:2022 contains 93 controls in four themes, taken from ISO/IEC 27002:2022. A.5.15 sits in the organizational theme (clause 5), and A.8.3 and A.8.11 sit in the technological theme (clause 8). A.8.11 is one of the 11 controls new in the 2022 edition, so organizations that certified under the 2013 edition may not have a direct predecessor for it. Map each control to the Superset feature that supports it, and record which parts of the evidence come from your identity provider, your database and your own procedures. The crosswalk between SP 800-53 Rev. 5 and ISO/IEC 27001:2022 relates A.8.3 to access enforcement, but NIST notes that mapped controls are not always equivalent, so confirm the mapping with your auditor before relying on it.
Before you start, confirm three things with your certification body and your policy owner: which information is in scope for the Superset deployment, which roles must be separated, and how long access reviews must be retained as records. Those answers decide the role design, the RLS rules and the masking approach. Ask your certification body which evidence format they accept for role exports and access logs, because a screenshot of the Superset interface is rarely enough on its own.
Mapping A.8.3, A.5.15 and A.8.11 to Superset capabilities
This table maps three Annex A controls to the Superset features that can support them, the configuration each one depends on and the evidence an assessor is likely to ask for. Read each row as a starting design point, then confirm the exact role and row level security behavior in the Superset version you run, because the controls ask for outcomes your own policy defines. The main takeaway is that Superset supports these controls through roles, dataset access and RLS, but the access rules themselves must come from your access control policy.
| Requirement | Superset capability | Configuration needed | Evidence |
|---|---|---|---|
| A.8.3 Information access restriction: access to information is restricted in line with the topic-specific access control policy | Role-based permissions on dashboards, charts and datasets, plus row level security filters applied to queries | Define roles that match your policy, grant dataset and dashboard access per role, attach RLS rules to sensitive datasets, and confirm how RLS applies to admin and owner roles in your version | Role and permission export, RLS rule inventory, dashboard ownership list, and a test log showing a restricted user cannot see out-of-scope rows |
| A.5.15 Access control: rules for physical and logical access are established and implemented from business and security requirements | Authentication through an external identity provider with group-to-role mapping, so access follows the identity lifecycle | Use SSO or LDAP login only, map IdP groups to Superset roles with AUTH_ROLES_MAPPING, disable local account creation where your policy requires it, and document who approves role changes | IdP group to role mapping configuration, joiner and leaver records from the directory, and periodic role review sign-offs |
| A.8.11 Data masking: masking used in line with the access control policy and applicable legislation | Masked datasets built from SQL views or restricted columns, combined with RLS so users see only permitted records | Mask or omit personal and sensitive fields at the database view layer, avoid exposing raw tables to Superset roles, and have legal or privacy owners confirm which fields must be masked | Dataset inventory showing which fields are exposed, view definitions, data protection sign-off, and query samples from a restricted role |
| Crosswalk reference for A.8.3: NIST SP 800-53 AC-3 and AC-24 | Access enforcement and access decisions mapped to the same outcome as A.8.3 | Treat the NIST crosswalk as a pointer for assessor discussion, not a substitute for your own mapping, since NIST notes that mapped controls are not always equivalent | Your own control mapping document that cites the crosswalk and explains any gaps |
| Logging of access decisions for auditors | Audit and event logging of dashboard views and permission changes, depending on what your version records | Confirm which events Superset logs, forward them to your central log store, and set retention to match your policy | Log samples showing dashboard access and permission changes, plus retention settings |
How login and group mapping restrict access in Superset
Who can log in to Superset is the first access restriction an auditor will test for A.5.15. Superset is built on Flask-AppBuilder and can authenticate users through OAuth2 providers such as Google and Azure, through a custom OAuth2 server using the code flow, or through LDAP. Its AUTH_ROLES_MAPPING setting maps LDAP or OAuth groups to Superset roles, so the group a person holds in your identity provider decides which datasets, dashboards and actions they receive. Confirm the exact configuration keys, provider settings and mapping syntax against the Superset version you run, since these have changed across releases and the Superset configuration documentation is the reference for your version.
Local accounts deserve a deliberate decision. Every local account in the metadata database is an identity that sits outside your joiner, mover and leaver process, so auditors will ask whether local login is disabled for workforce users or limited to a documented break-glass account. Two platform settings support that evidence. The SECRET_KEY must be set explicitly before Superset starts, and it protects session and signed data, so its ownership, storage and rotation procedure (using PREVIOUS_SECRET_KEY) belong in your access control documentation. The metadata database also holds users, roles and permissions, so use PostgreSQL or MySQL in production, not the SQLite default, and confirm the supported versions listed in the configuration documentation before you commit to one.
Once group membership drives access, the identity provider becomes the source of truth for A.5.15. Provisioning and removal of a person's group membership in the IdP then determines whether they can reach a dashboard, so your evidence should show that a leaver's group is removed promptly and that the matching Superset role no longer applies at next login. Decide with your auditor how often you will review the group-to-role mapping and who approves changes to AUTH_ROLES_MAPPING. Test this with a named account in staging before the audit period begins, and record the result alongside the role export.
Configuring roles, row level security and masking by access model
Superset controls what each user can open, edit and export through roles built on Flask-AppBuilder permissions. The configuration decision is to start from the smallest set of roles that matches each job, then grant extra permissions only where a documented need exists. Keep the Admin role to a short, named list of platform owners, because that role can change nearly everything in the instance. Decide explicitly who may create or edit datasets, since dataset definitions control which tables and columns exist for every chart built on them. If this is skipped, broad default roles or widely held dataset edit rights let analysts reach tables outside their policy, and the access review later has no clear baseline to compare against.
- Least privilege roles: Define one role per job function, such as viewer, analyst and dashboard owner, and grant only the view, query and export permissions that function needs.
- Small admin population: Limit Admin membership to named platform staff, and record who holds it and why.
- Dataset edit rights: Restrict dataset creation and editing to a data owner group, so analysts cannot quietly expose new tables.
- Role mapping from the IdP: Where groups come from an identity provider, map them to Superset roles in one place so removals in the directory flow through.
- Role export for review: Plan a recurring export of roles and member lists to support access reviews.
Confirm the exact permission names, default roles and the export and dataset edit options in the Superset documentation for the version you run, since these change between releases.
Row level security (RLS) adds a SQL filter that Superset applies to every query on a dataset, so the same dashboard shows different rows to users in different business units or regions. The configuration decision is which attribute drives the filter, where that attribute comes from, and which roles bypass or are subject to the rule. The filter should reference a value the user cannot edit, such as a group or a mapped attribute from the identity provider, not a free-text input. If RLS is skipped or applied to only some datasets, a user can reach rows outside their unit through a chart or a saved query on an unfiltered dataset.
- Filter attribute source: Base filters on a trusted attribute, such as region or business unit from the directory, rather than on user-entered values.
- Coverage across datasets: Apply the rule to every dataset that exposes the protected table, including datasets built on joins and virtual datasets.
- Role scope: Decide which roles the filter applies to and document any exception for administrators or data owners.
- Test with a non-admin user: Log in as a standard user in each business unit and confirm charts, tables and exports show only permitted rows. Admin accounts bypass or see different results, so they cannot prove the rule works.
- Retest after changes: Repeat the test after dataset, role or database changes, and keep the results as evidence.
Confirm in the documentation for your version how RLS rules are defined, which roles they apply to, and whether caching or async queries respect them.
Masking in Superset is usually achieved by what a dataset exposes, not by a display setting. A curated dataset lists only the columns the access policy allows, often with sensitive values transformed in the SQL definition, and charts are built on that dataset rather than on the raw table. The configuration decision is which columns to expose, which to hash, truncate or omit, and whether the warehouse role used by Superset can read the raw table at all. Superset must not be the only control, because a user who can run SQL Lab against a broad database login may read columns the dataset hides. If the warehouse role is not limited to the same scope, the masking can be bypassed.
- Column allowlist: List the columns each dataset exposes against the policy, and exclude everything else by default.
- Transformed sensitive fields: Replace identifiers with masked or truncated expressions in the dataset definition where the policy requires partial display.
- Warehouse role scope: Create a database login for Superset that can read only the curated views or schemas, matching the dataset allowlist.
- SQL Lab restrictions: Limit which users may run ad hoc SQL against each database connection, since SQL Lab can reach any table the login can read.
- Mapping to the policy: Keep a table that links each dataset column to the access topic-specific policy so auditors can trace the masking decision.
Confirm with your data owners and the Superset documentation for your version how database connections, SQL Lab permissions and dataset-level SQL are controlled, and test the warehouse login directly to verify its reach.
Configuration sequence for an access restriction evidence set
This sequence turns an access policy into a Superset configuration that can be tested, recorded and reviewed. Each step produces a artifact an auditor can inspect, from the identity mapping and role design to the baseline export and the review schedule. Follow the order so that access decisions are made before the controls that enforce them are built.
Confirm the access control policy and owners
Before any Superset setting changes, the organization confirms its topic-specific access control policy and names an owner for each data classification, dashboard group and Superset admin role. The policy defines who may see which information and who approves exceptions. Owners sign off a short written register that lists each dataset, its classification and its approver. This register is the reference every later step is checked against, so it is done when every dataset in scope has a named owner and a recorded approval path.
Choose the identity provider and map groups
Decide which identity provider will authenticate Superset users, such as an OAuth2 provider or LDAP directory, so that each person has a unique login that the organization already manages. Then map provider groups to Superset roles using the AUTH_ROLES_MAPPING setting in the configuration. Confirm with the identity team which group changes the provider will record, since role assignment will follow those groups. The step is complete when a test login from each group receives only the expected roles.
Set the secret key and metadata database
Set a user-specified SECRET_KEY, which Superset requires to start, and store it in your secrets management system rather than in a file in the repository. Point Superset at a production metadata database, PostgreSQL or MySQL, using a version listed as supported in the configuration documentation, and avoid the SQLite default. Record the key rotation procedure, including PREVIOUS_SECRET_KEY, so rotation does not lock users out. The step is done when Superset starts against the production metadata database and the key is stored and documented.
Define roles and row-level security from classification
Translate the classification register into Superset roles and row-level security (RLS) rules. Give each role the minimum dataset, dashboard and chart permissions its job requires, and write RLS filters that limit rows by region, business unit or other attribute the policy names. Keep admin roles separate from analyst roles. The output is a written role matrix that lists each role, its permissions and its RLS filters, which the owners approve before deployment.
Create curated and masked datasets
Where the classification calls for it, build curated datasets that exclude or transform sensitive columns, and expose those datasets to the roles that need them instead of raw tables. Apply masking in the query layer or the source view so that the value is not available to unauthorized roles, and document how each masked field is produced. Relate this to the data masking control A.8.11 in the policy. The step is complete when test users can query only the curated datasets for masked fields and the masking logic is recorded alongside the dataset register.
Restrict database connections to warehouse roles
Create dedicated database users in each analytics database with read privileges limited to the curated schemas, and configure each Superset database connection to use only that user. Superset roles then govern what users see in the interface, while the database role limits what the connection can read regardless of Superset settings. Confirm that no shared administrative credential is used for dashboards. The step is done when a query issued through a restricted connection to an out-of-scope table fails at the database.
Test access with named accounts in staging
Run the access test in a staging instance built from the same configuration. Use named test accounts for each role, including at least one account that should be denied, and check the dataset list, dashboard visibility, RLS results and export actions against the role matrix. Record each expected and actual result, and retest after any change. The step is complete when every test case matches the matrix and the signed results are stored with the change record.
Capture the baseline and schedule reviews
Export the role and permission configuration, the RLS rules, the AUTH_ROLES_MAPPING setting and the test results, and store them as the baseline for production. Set a periodic access review in which owners compare current users and role assignments against the register, and file the export and sign-off as evidence. For upgrades, follow the documented steps: back up the metadata database, run superset db upgrade and superset init, test in staging first, and check UPDATING.md for breaking changes so that access controls are not changed silently. The baseline is done when the review calendar exists and the first review has been completed and filed.
Evidence auditors sample for access restriction and how to keep it
An auditor testing A.8.3 information access restriction will sample evidence that shows who could reach which data in Superset, why, and whether that changed over time. The cards below cover the artifacts that connect identity, roles, row level security, datasets, reviews and configuration into one traceable record.
IdP group to role mapping export
Export the mapping between your identity provider groups and Superset roles, including any AUTH_ROLES_MAPPING entries from the Superset configuration. The auditor tests whether a person's access follows from their group membership and whether no one holds roles through a local account outside that path. Store a dated copy in your evidence repository and compare it against the directory group list each quarter. Confirm which mapping fields your Superset version writes to its logs before promising a complete history to an auditor.
Role and permission export with dates
Keep a dated export of every role, its permissions and the users assigned to it. The auditor samples a role and checks that its permissions match the access policy approved for that job function. Compare each export with the previous one so changes to dashboard, dataset and SQL Lab permissions are visible. Record who ran the export and where it is stored, because an undated or unattributed list is weak evidence.
RLS rule definitions and named user tests
Store each row level security rule with its target datasets, the roles it applies to and its owner. Add test results that show named users in different roles seeing only their permitted rows, with the test date and Superset version. The auditor tests whether restrictions are enforced in data, not just documented. Re-run the same tests after any change to a rule, role or dataset, and keep the before and after results.
Dataset and masking inventory
Maintain an inventory of every dataset exposed in Superset, its source database, the sensitive columns it contains and any masking applied through a view, virtual dataset or upstream control. Map each entry to the A.8.11 data masking requirement and to the access policy that governs it. The auditor uses this inventory to confirm that sensitive fields are not exposed to roles that do not need them. Review it whenever a new dataset is published.
Access review records with approvals and removals
Record each periodic access review with the reviewer, the population reviewed, the decisions made and the approval date. Include evidence that removals were carried out in Superset and in the identity provider, including users who left or changed roles. Auditors commonly sample leavers and movers, so confirm the review covers both. Set the review cadence in your own policy, then keep the signed records alongside the exports they relied on.
Configuration baseline and change records
Keep a baseline of the production superset_config.py settings, with the SECRET_KEY rotation history, including any use of PREVIOUS_SECRET_KEY during rotation. Pair it with change records for each upgrade, citing the backup taken and the staging test results, as described in the upgrade documentation. Illustrative example: a ticket that links a version change, a database backup and an access export taken before and after the upgrade. Auditors use these records to confirm that controls were not silently weakened.
What the auditor tests and what DeployOpen does not do
ISO does not certify organizations. Accredited certification bodies do, and they operate to ISO/IEC 17021-1:2015 together with ISO/IEC 27006-1:2024, which IAF MD 29:2024 required them to apply to all clients by 31 March 2026. A certification cycle runs three years, with at least one audit, either surveillance or recertification, in every calendar year. Organizations that held certificates to the 2013 edition had to expire or be withdrawn by 31 October 2025, so the relevant assessment today is against the 2022 edition and its 93 Annex A controls. Confirm with your certification body which edition and transition terms apply to your certificate and when your next audit falls.
The auditor does not test whether Superset is configured in a particular way. The auditor samples evidence against your own access control policy and against the attributes of A.8.3, A.5.15 and A.8.11 as they apply to your organization. A role export, a list of row level security rules, a record of an access review or a log of a permission change is useful only if it traces back to a rule you wrote and approved. Before the audit, ask which datasets, dashboards and roles the auditor will sample, and check that each one has an owner, a documented business need and a dated review record.
DeployOpen plans, configures and documents the Superset side of these controls, and prepares the records that show they operate. DeployOpen does not issue audit reports, attestations or certifications, does not decide whether your controls conform, and does not act as your certification body. Those decisions belong to an accredited certification body. If you need a readiness view, ask for it as preparation work with a written scope, and confirm with your certification body how it will treat evidence prepared by an outside party.
What Superset does not cover for ISO 27001 access restriction
Superset can enforce access inside the analytics layer, but several controls that auditors test for A.8.3, A.5.15 and A.8.11 sit in other systems or in the organization's own management processes. The cards below mark where those responsibilities sit so the control design does not assume Superset covers them.
Access control policy and risk decisions
The topic-specific access control policy that A.8.3 refers to is the organization's document. Superset does not decide who should see which dataset, which risks are accepted, or how sensitive a dashboard is. Confirm that the policy names owners for each dashboard and dataset, and that the role model in Superset is traceable back to that policy.
Joiner, leaver and MFA enforcement
Provisioning, removal and multi-factor authentication happen in the identity provider that Superset trusts, not in Superset itself. A user removed from the directory can still hold a local Superset account if local login remains enabled. Check that account removal is driven by the IdP and that local accounts are reviewed on a schedule.
Warehouse grants and masking
Row level security and roles in Superset filter queries that Superset sends, but the database itself must enforce its own grants and masking for A.8.11. Anyone who connects to the warehouse directly, or who holds a database user with broad privileges, bypasses the Superset model. Confirm database-side grants, masked columns and service account scope before relying on dashboard filters.
ISMS scope and statement of applicability
The ISMS scope, the statement of applicability, the risk treatment decisions and management review are records the organization produces. Superset does not generate them, and an auditor will not accept a dashboard screenshot in their place. Map each Superset control to an applicability decision and an owner, and record why any Annex A control is excluded.
Audit and event log coverage
Whether Superset records permission changes, dashboard access, export events and login activity depends on the version in use and on how logs are shipped. Do not assume a given event type is logged. Confirm the logging behavior for your release, test that a role change produces a record, and check that logs leave the Superset host before an auditor requests them.
Operator maturity for control design
The Apache Superset Kubernetes Operator is in alpha with a v1alpha1 API whose custom resource schemas may change between releases. Do not make it the only basis of an access control design. Where a control depends on deployment configuration, document the configuration outside the Operator resources and set a plan for schema changes at each upgrade.
Questions buyers ask before scoping ISO 27001 access work in Superset
How much effort does mapping A.8.3, A.5.15 and A.8.11 to Superset take?
Effort depends on the scope you agree in writing, not on a standard figure. The main drivers are the number of data domains, the number of datasets and dashboards that expose them, how many row level security rules you need, how complex your identity provider's group structure is, and how many warehouse grants must be reviewed and aligned with Superset roles. A single domain with one identity provider group and a few RLS rules is a small exercise. Several domains with nested directory groups, masked columns and separate warehouse service accounts is a much larger one. Ask any partner to break the estimate down by these drivers before you agree a scope.
What do we need to provide for ISO 27001 access work in Superset?
The work needs decisions and access from several people in your organization. Policy owners must confirm the topic-specific access control policy that A.8.3 and A.5.15 refer to, since the Superset role model should follow it. Data owners must classify datasets and approve who may see which rows. Identity provider administrators must supply group structures and test logins. Warehouse administrators must provide read-only service accounts and confirm grants. Finally, you should provide test accounts that represent each role, so access can be verified in staging before anything reaches production.
Can our internal team map these controls to Superset without a partner?
Yes, if the team has working knowledge of Apache Superset administration, the warehouse you connect to, and the ISO/IEC 27001 control set, and if it has time to run staging tests. The hard parts are rarely the configuration screens. They are reconciling the access policy with the actual warehouse grants, proving that RLS filters hold for every role, and keeping evidence in a form an auditor can sample. A partner is useful when those skills are missing or when the team lacks the capacity to document and test the work alongside daily operations.
How long does ISO 27001 access restriction work in Superset take?
Duration is driven by scope, so no fixed figure applies. The same drivers that shape effort also set the timeline: the number of data domains, identity provider changes, RLS complexity, the number of warehouse connections, and how quickly your data and policy owners can make decisions. Timelines also depend on how many staging test cycles you need and whether changes must pass your change advisory process. Ask for a timeline in the written scope that lists the dependencies on your side, such as IdP access and owner sign-off.
Does configuring Superset alone get us ISO 27001 certified?
No. Configuring Superset supports the technical part of an information security management system, but it does not certify anything. ISO does not certify organizations, and accredited certification bodies decide whether your management system meets ISO/IEC 27001:2022. Those bodies assess the whole ISMS, including risk assessment, the Statement of Applicability, policies, training, supplier management and internal audit. DeployOpen prepares systems, controls and evidence for assessment, but does not issue audit reports, attestations or certifications. Confirm the certification body's requirements early in the project.
What does ISO 27001 access work in Superset cost?
Most engagements are fixed-scope, and DeployOpen does not publish a price list. A quote follows from a written scope that lists the data domains, identity provider integration, RLS rules, warehouse grant review, test plan, evidence pack and handover. Costs are mostly one-time, covering design, configuration, testing and documentation. Recurring costs appear when you add a retainer for role reviews, upgrades or ongoing testing, and when your own team carries access reviews over time. When requesting a quote, ask which deliverables are included, what you must provide, how changes after sign-off are handled, and which items are optional.
Where does ISO 27001 data masking fit in a Superset rollout?
A.8.11 data masking applies when dashboards show personal or otherwise sensitive data that a role should not see in full. In Superset, this usually means choosing whether to mask at the warehouse view, in the dataset definition, or through row and column restrictions tied to roles. The choice depends on what your data owners and applicable legislation require. Confirm with your policy owners which fields need masking, then test that exports, chart tooltips and SQL Lab results follow the same rules, since these are common gaps.
How DeployOpen scopes and delivers access restriction evidence for Superset
DeployOpen plans, implements and documents self-hosted Apache Superset inside your own infrastructure, mapping roles, row level security, dashboard access and masking to the controls your ISMS owner will test. We do not issue audit reports or certifications; we prepare the system, the configuration and the evidence that your certification body reviews.
How we scope
- Engagements are fixed-scope, with the Superset deployment, identity sources and datasets agreed in writing before work starts.
- The written scope lists which dashboards, datasets and roles fall under your access restriction policy and A.5.15 and A.8.3 review.
- We confirm which data needs masking under A.8.11 and which business owners approve each access rule.
How we build
- We configure Superset roles and permissions against a documented matrix tied to your access control policy.
- Row level security rules are written, reviewed by data owners and tested with named test accounts for each intended audience.
- Dashboard sharing, export settings and masked datasets are tested for unintended access paths before sign-off.
How we hand over
- You receive the role matrix, RLS rule register, configuration records and test results as documents your auditor can sample.
- Access review procedures are documented so your team can export role assignments and repeat checks on a schedule you set.
- We walk your administrators through change control for roles, RLS rules and dataset masking, including the upgrade steps in UPDATING.md.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped in writing separately from the build.
- Retainers can cover re-running access tests after Superset upgrades, identity provider changes or new dataset onboarding.
- Before any certification assessment, confirm with your certification body which evidence they expect and whether it matches our deliverables.
