Can Apache Superset meet PCI DSS need-to-know access requirements?
The core question for most payment teams is whether analysts can work with payment data in Superset while PAN stays out of reach of anyone without a business need. Superset can support that goal through role design, dataset-level restrictions, row-level security (RLS) and audit logging, which map to the controls PCI DSS Requirements 7.2, 3.4 and 10.2 ask you to demonstrate. The software does not decide compliance, though. A Qualified Security Assessor (QSA) or a Self-Assessment Questionnaire (SAQ) with an Attestation of Compliance does that, based on your environment as a whole. Treat Superset as one component you configure and evidence, not as a control that makes you compliant on its own.
Several boundaries sit outside the Superset configuration and need their own decisions. The database that holds cardholder data, its privileges and its own logging are not covered by Superset roles, so a Superset user restricted to a masked view can still reach raw tables if the warehouse account allows it. Network segmentation decides which systems count as in the cardholder data environment and whether Superset itself falls inside that scope. Your choice of the defined approach or the customized approach for each requirement is also yours to justify, and a customized approach needs a documented targeted risk analysis and evidence that the stated objective is met. Confirm each of these with your QSA or assessor before you finalize the design.
Before building anything, confirm three things in writing: which PCI DSS version and assessment type applies to you, which Superset components will touch cardholder data (including the metadata database, caching and any SQL Lab usage), and who owns the review of Superset accounts and their privileges. Check the supported metadata database versions and the current release notes against your own standards, and confirm with the Superset project which features your chosen release provides. The outcome of this scoping work determines how much of the design in the following sections is needed and how much evidence your assessor will expect.
How Superset capabilities map to PCI DSS 7.2, 3.4 and 10.2
This table maps each PCI DSS requirement that governs Superset access to the Superset capability that supports it, the configuration it needs and the step your own process must complete. Read each row as a split: Superset enforces what it can, while approvals, account reviews and log retention stay with your team. The main takeaway is that Superset supports need-to-know access but does not satisfy these requirements on its own.
| Requirement | Superset capability | Configuration needed | Where your process must act |
|---|---|---|---|
| 7.2.1 to 7.2.3: access control model, least privilege and approval | Roles and permissions control which datasets, charts and dashboards each user can open | Define roles by job function, map IdP groups with AUTH_ROLES_MAPPING, avoid shared admin accounts | Your team defines the access model and approves each role and its privileges |
| 7.2.4: review of all user accounts and privileges every six months | Superset lists users and roles, and access follows IdP group membership when SSO is used | Remove access through the IdP so role membership is the single source of truth | Run the six-monthly review, include vendor accounts, act on findings and record management sign-off |
| 7.2.5.1: review of application and system account access | Database connections and worker processes run under accounts configured in Superset | Give each database connection a read-only account scoped to masked views or the cardholder schema | Set the review frequency in your targeted risk analysis under Requirement 12.3.1 |
| 3.4.1: PAN masked wherever it is displayed | Superset displays what the database returns, so masking must happen in the data layer | Publish a masked dataset that returns only the BIN and last four digits to general roles | Confirm the masking design with your assessor, since masking is not truncation (PCI SSC FAQ 1146) |
| 3.4.2: technical controls against copying or moving PAN through remote access | Chart and dataset exports (CSV, Excel, clipboard) can move displayed data out of Superset | Restrict export permissions to authorized roles and confirm export behavior in your Superset version | Assess remote-access and endpoint controls, since Superset settings alone do not meet this requirement |
| 10.2.1 to 10.2.1.7: audit logs for user access, admin actions and permission changes | Superset and database query logs can record user activity, but the events each version writes must be confirmed | Forward Superset and database logs to a central store with restricted read access | Define log retention, review cadence, alerting and evidence of admin and permission change logging |
Evidence Superset produces for a PCI DSS assessor
A QSA or internal assessor will sample artifacts that show who could reach cardholder data in Superset, who reviewed that access, and what was logged. Superset generates raw material for these, but the customer must generate, export, retain and protect the records, because Superset does not produce an attestation.
Role and permission exports
Export the roles, permissions and dataset grants from Superset on a schedule and keep dated copies. An assessor will compare them against the access model for Requirement 7.2 and test whether any role can reach datasets that expose full PAN. Confirm the export method for your Superset version with your team, since the admin interface and API differ across releases. Record who ran each export and where it was stored.
Access review records
Requirement 7.2.4 expects every account and privilege, including vendor and third-party accounts, to be reviewed at least every six months, with inappropriate access fixed and management acknowledging the results. Keep a signed review record per cycle that lists each Superset user, role, and the reviewer's decision. Attach the role export used for that review so the evidence can be traced to the state of the system at the time.
Audit log extracts
Retain extracts from the web server, the metadata database and any proxy or identity provider that show individual access to datasets, administrator actions, changes to credentials and invalid access attempts, as described under Requirement 10.2.1. Superset's own event logs cover only part of this, so confirm which events reach your central log store. Test that a sampled event can be found, explained and tied to a named user.
Configuration baselines
Keep the approved configuration for the Superset instance under version control, including the settings for authentication, the secret key handling, the database connections and the export and feature flags. An assessor will ask for the baseline and for proof that production matches it. Store changes as reviewed commits so each change has an author, a reviewer and a date.
Masking and display design records
Document which datasets and charts show masked PAN, which show only the permitted digits, and which roles are authorized to see more, as Requirement 3.4.1 requires. Include the query or view definitions used for masking and the justification for each role with a legitimate business need. Explain in the record how this masking differs from truncation, because the two are handled differently under the standard.
Evidence custody and retention
Decide who owns each artifact, where it is stored, how it is protected from edits, and how long it is kept before your assessor and payment brands ask for it. Restrict write access to the evidence store, separate it from the Superset administrators, and confirm the retention period with your QSA or acquirer rather than assuming one. Remember that the assessment itself is documented on PCI SSC templates, so the evidence supports the report but does not replace it.
Designing roles so only job functions see cardholder data
Most analysts in a Superset deployment should never query a dataset that contains a full primary account number. The practical pattern is to build a masked dataset that exposes only the fields analysts need, such as transaction counts, amounts, merchant category and a truncated card reference, and then grant the analyst role access to that dataset alone. Superset controls this through three layers that work together. Flask-AppBuilder roles define which screens and actions a user can perform. Dataset permissions decide which tables or virtual datasets a role can query. Row-level security (RLS) filters the rows a role sees within a dataset that it can already reach.
- Masked datasets as the default: Expose a virtual dataset that masks or omits PAN before any analyst role is granted access, and keep the base table reachable only by roles that have a documented need.
- Role inheritance kept narrow: Start from a custom role that copies the minimum permissions of the built-in Alpha or Gamma roles, rather than granting broad database-wide access.
- Row-level security by segment: Add RLS filters for merchant, region or product line where analysts should see only their portfolio.
- No direct SQL Lab access to raw tables: Restrict SQL Lab permissions for analyst roles, since free-form queries can reach columns that a chart never displays.
- Named owners for each dataset: Record which team approves access to each masked dataset so that access reviews under Requirement 7.2.4 have a clear decision-maker.
Confirm in your environment which masking method your data team will use, and test that a user in the analyst role cannot reach the base table through SQL Lab, chart exports or the API.
Fraud, chargeback and card operations staff sometimes have a legitimate need to see more than a masked value, for example to investigate a disputed transaction. Requirement 3.4.1 allows unmasked display only for personnel with a legitimate business need, so the design goal is to give this group a separate, documented role and dataset rather than widening the analyst role. In Superset this usually means a dedicated role that can reach a restricted dataset with the fields investigators require, combined with RLS that limits each investigator to the cases or queues they are assigned. Because the ability to see more data is the sensitive part, the role should be the smallest one that does the job, and its membership should be tied to a recorded approval.
- Separate role, separate dataset: Create a distinct role and a restricted dataset for investigators instead of adding permissions to the analyst role.
- Documented need as a condition of membership: Require a written approval that names the business reason, and link that approval to the group that the identity provider maps to the role.
- RLS tied to case ownership: Filter rows by queue, region or assigned case where your data model allows it, so an investigator sees only the transactions in scope.
- Export and download restrictions: Remove CSV and Excel export rights from this role unless the process requires them, and document where exported data is stored.
- Time-bound membership where possible: Remove membership when an investigation or a team change ends, and check that the removal happens in the identity provider as well as in Superset.
Confirm with your fraud and card operations leads which fields they truly need unmasked, and confirm with your QSA how the approval evidence will be retained for Requirement 7.2.4 reviews.
Administrators can change who sees what, so their privileges need the strictest design. An administrator who can edit roles, datasets and RLS rules can, in effect, grant themselves access to cardholder data. Superset administrators also manage the metadata database, the secret key and the database connections, which hold credentials for the warehouse. Requirement 7.2 expects privileges to be assigned by job function, approved and reviewed, and the administrator group is the first place a reviewer will look. The design therefore separates platform administration from data access. Platform administrators manage the application, while a data governance function approves dataset and RLS changes that affect cardholder data.
- Separate platform and data administration: Keep the Admin role limited to platform work, and assign dataset and RLS changes to a governance role that a second person approves.
- Named, individual accounts: Map administrators through the identity provider to individual identities, with no shared login.
- Privileged role membership reviewed on a schedule: Include admin and governance roles in the account review under Requirement 7.2.4, and record the outcome.
- Database connection credentials scoped to read-only: Use a warehouse account whose privileges match the masked datasets, so that a Superset compromise does not expose more data than the dataset layer does.
- Changes logged and traceable: Confirm that role, dataset and RLS changes appear in logs that feed the controls under Requirement 10.2.
Confirm the exact permissions in your Superset version against the current documentation, because the set of permissions that allow role and dataset editing can change between releases.
Role assignments should follow the identity provider, not manual edits inside Superset. Superset supports LDAP and OAuth2 providers, and its configuration maps group membership from those sources to Superset roles with AUTH_ROLES_MAPPING. When a person changes job function, the identity provider group changes, and the next login updates the role. This keeps the approval record in one place and makes the review of user accounts and privileges easier to perform. The mapping is only as strong as the group structure behind it, so the groups should match the job functions defined in the role design, and the mapping should be tested before anyone relies on it for cardholder data.
- One group per job function: Create groups such as analyst, card-operations-investigator and platform-admin, and avoid nesting that grants a broad group to a narrow function.
- Explicit mapping review: Keep the AUTH_ROLES_MAPPING entries in version-controlled configuration so that every change to a group-to-role link is reviewed.
- Default role without data access: Make sure that a user who authenticates but belongs to no mapped group receives a role with no access to cardholder datasets.
- Removal through the identity provider: Disable or remove users in the identity provider, and verify that Superset no longer grants access after the next login or session expiry.
- Test with real group membership in staging: Log in with test accounts from each group and confirm the datasets, charts and RLS results match the design.
Confirm which identity provider your organization uses and how its groups are populated, and confirm the mapping behavior for your Superset version and authentication method with the current configuration documentation.
Where masking in Superset ends and truncation begins
Masking hides PAN when it is displayed, and it does not change the PAN that is stored. PCI SSC FAQ 1146 separates masking from truncation: masking hides digits at the point of display, while truncation permanently removes digits from the stored PAN. Requirement 3.4.1 is a display control, so it is met by making sure only personnel with a legitimate business need see more than the BIN and last four digits. Truncation is a storage decision that sits in the database and data pipeline, not in Superset. FAQ 1492 covers how these methods apply to 8-digit BINs, which is worth reading before you agree on masking rules with your QSA.
A masked dataset in Superset is a view over the source, so the full PAN still exists in the source database, in any query Superset runs against it, and in the metadata database if a user saves that SQL. Masking also does not automatically cover CSV exports, chart data downloads, dashboard thumbnails, async query results or cached results held by the caching layer, which the architecture documentation says alerts, reports and async queries rely on. Each of these paths can carry a column that the on-screen chart hides. Confirm in your Superset version how each of these outputs treats sensitive columns, and test them with a restricted test role before any production dataset is exposed.
Plan the masking layer and the storage decision as separate work items. Ask your QSA whether truncation at the source, a masked view in the database, or a Superset-level restriction is the control you can evidence for Requirement 3.4.1, and where Requirement 3.4.2 applies if users can copy results through remote access. Record which export, caching and async paths are disabled for PAN-bearing datasets, and note the result for your Requirement 7.2 role reviews, so the masking claim matches what the platform actually does.
Configuration sequence for a PCI DSS scoped Superset
This sequence takes Superset from scoping to a working, reviewable configuration in which each user sees only the cardholder data their job function needs. Each step ends with an output the assessor can inspect, from the signed scope note to the access review record.
Confirm cardholder data scope with the assessor
Before any build work, the team agrees with its Qualified Security Assessor or internal assessor which Superset components fall inside the cardholder data environment. The scope covers the web application, the metadata database, any caching layer and Celery workers, and every analytics connection that can reach stored PAN. The output is a signed scope note listing these systems and their accounts. That note sets the boundary for the masking, logging and access review work in the steps that follow.
Deploy on a supported metadata database
The platform team installs Superset on PostgreSQL or MySQL in the versions the configuration documentation lists as supported: PostgreSQL 10 to 17 or MySQL 5.7 and 8.x. The SQLite default and the Docker Compose PostgreSQL container are not suitable for production. Generate a unique SECRET_KEY before first start and store it in your secrets manager, so PREVIOUS_SECRET_KEY can support later rotation. The output is a staging instance that starts with the custom key and a tested backup of the metadata database.
Enforce single sign-on and map groups to roles
The identity team connects Superset login to your identity provider through OAuth2 or LDAP. The platform team then maps directory groups to Superset roles using AUTH_ROLES_MAPPING. Name each group after a documented job function so that role membership matches a need-to-know decision under Requirement 7.2.1. Confirm in your version whether local password logins can be turned off for workforce users. The output is a test matrix showing that each test account receives only the roles its group grants, and that an account with no group has no data access.
Build masked datasets and job-function roles
The data team creates datasets in the warehouse or as governed database views that expose PAN only in the form Requirement 3.4.1 allows, such as the BIN and last four digits, or not at all. Masking hides digits at display time, while truncation permanently removes them from stored data, so analytics that need the full value stay on the source side. Grant each role access to these datasets, not to raw cardholder tables. The output is a dataset inventory mapped to roles, plus a test query from a restricted account that shows no full PAN.
Apply row-level security rules
The data owner defines row-level security filters for each role or business unit, so each user sees only the rows that function needs. The team tests every rule with a test account for each role and checks that the query Superset generates includes the filter. Filters should be reviewed whenever a dataset or role changes. The output is a signed test record for each filter, which an assessor can match against the role design from the earlier steps.
Restrict exports and downloads
The platform team reviews which roles can export chart data, download results or use SQL Lab, then removes those permissions from every role that does not need them. SQL Lab access should be limited to a small, named group of approved users. Where a role keeps export rights, the team assesses how Requirement 3.4.2 applies to copying PAN through remote access. Confirm the exact permission names in the role editor of your version. The output is a permission export listing who can export, download or query, and the approval for each entry.
Enable audit logs and forward them
The operations team turns on Superset event logging and sends the logs, along with those from the metadata database and identity provider, to central storage outside the Superset host. The log set should cover individual access to cardholder data, administrator actions, access to the logs themselves, invalid access attempts, credential changes and the creation or deletion of system-level objects, as Requirements 10.2.1.1 to 10.2.1.7 describe. Confirm which events each version records and close any gaps. The output is a sample set of test actions that appears in the central store.
Schedule access reviews at the defined frequency
The security team sets the review frequency for application and system accounts from the targeted risk analysis under Requirement 12.3.1, as Requirement 7.2.5.1 requires. Every user account and privilege, including vendor accounts, is reviewed at least once every six months under Requirement 7.2.4. Each review compares the Superset role export with the identity provider group list, removes inappropriate access and records management's acknowledgment. The output is a signed review record for each cycle, kept with the scope note from the first step.
What Superset does not cover for PCI DSS
Superset can enforce roles, row level security and masked datasets, but it does not decide what is in scope or prove that controls work. The cards below cover the gaps that sit with your team or a partner, and they connect because each one determines whether the Superset controls actually protect the cardholder data environment.
Scope determination
Superset does not decide which systems store, process or transmit cardholder data. Before you rely on role design, map every dataset, database connection, cache, worker and export path that could carry PAN, and confirm which components could affect the security of the cardholder data environment. A Superset instance that touches a cardholder dataset is in scope even if its dashboards look harmless.
Network segmentation
Superset's web application, metadata database, Redis cache and Celery workers all need network paths to the warehouse. Superset cannot isolate them for you. Confirm with your network team which segments hold the Superset components, which firewall rules allow connections to the analytics database, and whether workers that send alerts or reports can reach systems outside the cardholder data environment.
Database-level PAN controls
Masked datasets and RLS hide values in Superset, but the warehouse account behind each database connection can still read raw PAN. Restrict that account at the database layer, grant it only the columns and schemas each dataset needs, and confirm that the connection string stored in Superset uses a read-only role. Treat any SQL Lab access as a direct database session.
Remote-access copy controls
Requirement 3.4.2 expects technical controls that prevent copying or relocating PAN through remote-access technologies, except for explicitly authorized personnel. Superset's export and download features are only one path. Remote desktop, screen sharing, clipboard sync and browser developer tools also move data, so confirm the controls your endpoints and remote-access tools provide.
Log retention and review
Superset can record user activity in its event and audit logs, but the standard also expects logs to be retained and reviewed. Decide where logs are shipped, how long they are kept, who reviews them, and how a reviewer confirms that logging has not been stopped. Confirm the retention period with your assessor and check the log fields Superset emits against the events listed under Requirement 10.2.1.
Vendor and partner account reviews
Requirement 7.2.4 covers all user accounts and privileges, including third-party and vendor accounts, reviewed at least once every six months. Superset roles assigned to a partner, contractor or support engineer must appear in that review. Keep a named list of external accounts and their roles, and confirm that management acknowledges each review.
No certification or paid edition
Apache Superset is licensed under Apache-2.0 and has no paid edition, so patching, hardening, upgrades and support sit with your team or a partner. No Superset release is a PCI DSS certification. Assessment is done by a Qualified Security Assessor or through a Self-Assessment Questionnaire with an Attestation of Compliance, and you should ask your assessor which evidence they will accept for each control.
Questions buyers ask before outsourcing PCI DSS access work on Superset
What drives the cost of PCI DSS access work on Superset?
The scope of the cardholder data environment and the number of roles, datasets and databases in it drive the cost most. A quote follows from a written scope, so DeployOpen does not publish a price list. Cost components include discovery of which datasets hold PAN, role and dataset design, masked dataset build, row level security, logging configuration, testing and evidence packaging. Ask the partner to separate one-time build work from recurring items such as periodic access reviews, Superset upgrades and retained testing. Ask for each deliverable, the environments covered and the acceptance criteria in writing before work starts.
How long does it take to go from scope to audit evidence?
Duration depends on how many databases feed Superset, how well the existing roles are documented and how quickly the client can approve role designs. No supplied timeline applies to this topic, so ask the partner for a phased schedule tied to the written scope. Build work can run in staging first, then production, and evidence such as role exports and log samples needs a review period before an assessor sees it. Requirement 7.2.4 asks for a review of all user accounts at least once every six months, so the first review cycle should be scheduled before the engagement ends.
What does our team need to provide before the work starts?
The partner will need a list of databases and schemas that Superset can reach, the current data flow that places PAN into those datasets and the people who approve access by job function. Your team should also provide the identity provider or directory that will map groups to Superset roles, a named owner for access approvals and read access to your PCI DSS scope documentation. Expect to supply staging infrastructure that mirrors production. Confirm with your assessor which evidence format they accept, since the Attestation of Compliance is issued by a Qualified Security Assessor or through a Self-Assessment Questionnaire, not by DeployOpen.
Can our internal platform team do this work alone?
Often yes, if the team has Superset administration experience, database privilege knowledge and time for a formal review. The work includes role design, masked datasets, RLS rules, logging and testing, which need engineers who can read SQL and understand cardholder data flows. Consider the skills gap, the time needed for staging tests and the need for an independent check of the design. Confirm the vendor's current capabilities for your database engine, since the Superset documentation lists tested metadata database versions and not every warehouse behavior. Many teams split the work: internal staff own operations and reviews, while a partner builds and documents the controls.
Does running Superset make us PCI DSS compliant?
No. Superset is an open-source analytics application under the Apache License 2.0, and PCI DSS compliance applies to your whole cardholder data environment, including people, processes and other systems. Superset can support requirements such as 7.2 access by job function, 3.4.1 PAN masking when displayed and 10.2.1 audit logging, but the configuration only supports those controls. Your entity's validation is documented in a Report on Compliance or a Self-Assessment Questionnaire with an Attestation of Compliance, and the payment brands decide which entities must validate. Ask any partner to show how each control maps to evidence you can give your assessor.
How does the current PCI DSS version change the work?
PCI DSS v4.0.1 is the only active version, published on 11 June 2024, after v4.0 retired on 31 December 2024 according to the PCI SSC blog. The future-dated v4.x requirements, including 7.2.4, 7.2.5.1 and 3.4.2, became mandatory on 31 March 2025, so the design must meet them rather than treat them as best practice. The PCI SSC announced a request for comments on v4.0.1 running from 3 June to 20 July 2026, and as of October 2026 it had announced no release date for a new version. Ask your partner to track that announcement and to confirm which approach, defined or customized, applies to each requirement.
Which parts of the work should we ask about first?
Start with the access model, because role design decides most other controls. Ask how each Superset role maps to a job function, who approves privileges and how the review of user and application accounts will be scheduled. Then ask how PAN is masked in datasets and which technical controls stop copying or relocation through remote access, covering Requirement 3.4.2. Finally, confirm which events are logged under Requirement 10.2.1 and where those logs are stored and reviewed. A good quote lists these items as separate deliverables with owners and acceptance tests.
How DeployOpen scopes and documents Superset access controls
DeployOpen plans, builds and documents Apache Superset access controls inside infrastructure you control, so role design, masked datasets and audit logging can be explained to a QSA against the requirements they test. We work from a written scope, and we prepare systems and evidence for assessment without issuing any attestation or certification.
How we scope
- Inventory which datasets, schemas and columns hold PAN and which roles currently reach them.
- Agree in writing which Superset roles, RLS rules and masked datasets are in the engagement.
- Confirm with your QSA which requirements, approach (defined or customized) and evidence they expect.
- Record the metadata database, SECRET_KEY handling and authentication source as scope items.
How we build
- Design job-function roles and map identity provider groups to them through AUTH_ROLES_MAPPING.
- Build masked datasets and RLS filters, then test them with named test accounts for each role.
- Restrict export and download permissions and verify that PAN cannot be copied through them.
- Configure audit logging for user access, administrator actions and permission changes, then test that events are recorded.
How we hand over
- Deliver a role matrix, dataset masking map and RLS rule register that match the built configuration.
- Provide a logging specification showing which Superset events are captured and where they are retained.
- Document the access review procedure for Requirement 7.2.4, including how role exports are produced and acknowledged.
- Train your administrators on changes, upgrade steps and the evidence to keep for each control.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover.
- Re-test role and masking changes when Superset is upgraded, following your staging-first process.
- Update evidence packs when the access model changes or when your QSA asks for new samples.
- Confirm with your assessor and the PCI SSC materials which version and approach apply to your environment.
