How Apache Superset supports GDPR data protection by design
An analytics team that wants Superset dashboards over personal data needs to show how Article 25 and Article 32 of the GDPR are met. Superset configuration can help with data minimization through the datasets you publish (only the columns and rows a purpose needs), access restriction through Superset roles, row level security and export settings, and logging of who viewed or exported what. It cannot decide the lawful basis for processing, set retention periods, authorize transfers to third countries or make your processing compliant on its own. Those remain controller decisions, supported by your legal, privacy and hosting teams. DeployOpen plans and implements the Superset side of this work and prepares the configuration records and evidence you need. It does not issue audit reports, attestations or certifications. Independent auditors and certification bodies do that work, and the GDPR itself requires no certificate.
The design choice that carries the most weight is what Superset is allowed to see. Article 25(2) asks that only personal data necessary for each specific purpose be processed and that data not be made accessible to an indefinite number of people. In practice, this means building datasets over curated database views that omit direct identifiers, pseudonymizing where the analysis allows it, and granting each analyst role access only to the datasets its purpose requires. Row level security then narrows which rows a role can read within a shared dataset. Before rollout, confirm with your privacy team which fields are necessary for each dashboard, and test that each role sees only what that purpose needs, using accounts that represent real analysts rather than administrators.
Article 25 also requires that the chosen measures be reviewed regularly, and Article 32 requires security appropriate to the risk. For Superset, this means keeping a written record of dataset definitions, role mappings, RLS rules and export permissions, and reviewing them when dashboards or data sources change. Confirm with your identity team that logins go through your identity provider so that access removal follows the employee lifecycle, and confirm which Superset actions are written to logs and how long those logs are kept in your environment. The GDPR's own text and the EDPB Guidelines 4/2019 on Article 25 are the natural next reads for the privacy team, since they define the principles this configuration has to serve.
Mapping GDPR Articles 25 and 32 to Superset capabilities and configuration
This table maps each GDPR Article 25 and 32 requirement to the Superset capability that supports it and the configuration you need to set. Read each row as a design question: what the regulation asks, which Superset feature can help, and what you must configure and confirm in your own version's documentation. The main takeaway is that Superset supports these obligations only when datasets, roles and export settings are designed together, because a role model alone does not limit what personal data a dataset exposes.
| Requirement | Superset capability | Configuration needed |
|---|---|---|
| Article 25(1): data minimization and pseudonymisation | Dataset definitions control which columns and derived fields charts can reach | Build curated datasets that omit direct identifiers, expose pseudonymous keys where possible, and document the purpose of each dataset |
| Article 25(2): only necessary data by default | Dataset access, dashboard sharing and default chart settings determine what users see on opening | Default new dashboards to private, limit personal fields to datasets that need them, and confirm sharing defaults in your version's docs |
| Article 32(1): security appropriate to the risk | Roles and permissions, SSO login, metadata database and secret key protect the platform | Use an SSO-only login, PostgreSQL or MySQL as the metadata database, a user-set SECRET_KEY, and a documented role review cycle |
| Article 32(2): risks of unauthorised disclosure and access | Row level security filters rows per user or role, and export permissions govern CSV and data downloads | Define RLS rules per tenant, region or role, restrict export and download permissions to named roles, and test RLS as each role before release |
| Article 32(3): certification as an element | Superset does not hold or issue certification; it produces configuration and logs you can present as evidence | Ask an accredited certification body or auditor which evidence they expect, and confirm any approved mechanism applies to your processing |
Which records show auditors and supervisors how the measures work
Article 25 and Article 32 require measures that work in practice, so the proof is a set of records kept over time. The cards below cover the configuration, access, logging and review records that show how Superset limits personal data and protects it, and how each one is kept and checked.
Role and permission exports
Export the roles, their permissions and their assigned users from the Superset metadata database on a fixed schedule and store each export under change control. Compare each export with the previous one to see who gained or lost access to datasets containing personal data. Ask the reviewer to sign off on any role that can open raw tables or export data, because those roles carry the largest disclosure risk. Keep the dated exports for as long as your retention policy requires.
Dataset and RLS rule inventories
Maintain a current inventory of every dataset that touches personal data, with its source table, the columns exposed, and the row level security rules applied to it. The inventory shows whether a dataset was built to carry only the fields each purpose needs, which is the data minimization test under Article 25(2). Review it whenever a new dataset is published, and record who approved each rule and when it was last tested against a sample user.
Configuration under change control
Keep the superset_config.py file, the deployment manifests and the secret handling process in version control, with every change reviewed and approved. The records should show that SECRET_KEY is set to a user-specified value, that authentication settings such as AUTH_ROLES_MAPPING match the approved identity provider configuration, and that any key rotation followed the PREVIOUS_SECRET_KEY procedure. Confirm that the stored history matches what runs in production.
Access and action logs
Collect login events, permission changes and dataset or chart activity from the metadata database or your log sink, and forward them to storage that administrators cannot edit. These logs let you answer who viewed or exported a dataset, when, and under which role. Confirm with your own environment which events your deployment records by default and which need extra configuration, since the set of logged actions should be checked rather than assumed.
Periodic review records
Record each periodic review of access, datasets and configuration as a dated document with the reviewer, the scope, the findings and the actions taken. Reviews show that the protections are checked regularly, which the EDPB guidelines expect for measures that must stay effective over time. Keep the review cadence in your own policy, and attach the exports and inventories used in each review so the reviewer's conclusions can be traced.
No certificate required
The GDPR requires no audit report, attestation or certificate, so these records are evidence you produce for supervisors and your own accountability, not a document you file to a regulator. Article 42 certification is voluntary and does not reduce your responsibility. Independent auditors or certification bodies can test the records if you choose to commission them, but the obligation rests on the controller to show that the measures were designed, applied and reviewed.
Designing datasets so personal data is not in reach by default
Decide which columns and tables reach Superset at all before anyone builds a chart. Article 25(2) of the GDPR requires that, by default, only personal data necessary for each specific purpose is processed, and that covers the amount collected, the extent of processing, the storage period and accessibility. In Superset, the practical control point is the dataset. Build virtual datasets with SQL that select only the fields a given dashboard needs, and use aggregated or pseudonymised views for analysis where individual identities add nothing. Keep direct identifiers such as names, email addresses and national identifiers out of the datasets that most users can open, and where a join key is required, use a pseudonymised identifier that the analytics team cannot reverse without a separate, controlled lookup. Article 25(1) names pseudonymisation explicitly as an example of such a measure.
Treat this design as a record you must keep current. EDPB Guidelines 4/2019 on Article 25 state that the obligation applies to all controllers regardless of size, covers systems that existed before the GDPR, and requires regular review of whether the chosen measures remain effective. A Superset instance that was connected to a warehouse years ago, with datasets created by early users, is therefore in scope. Inventory every dataset, its source tables and its columns, and confirm each one against a documented purpose. Schedule the review in your change process so that new columns added upstream do not appear in Superset automatically.
Purpose and retention are not decisions Superset can make for you. Before finalising any dataset, agree with your DPO and the data owners what each dataset is for, which personal data that purpose needs, and how long the source data may be kept in the analytics database. Confirm with the DPO whether retention rules apply to the warehouse tables Superset queries, because a dashboard cannot be more limited than the data beneath it. Record the agreed purpose against each dataset so that the decision is traceable when an auditor or supervisory authority asks why a column is present. DeployOpen can help map these decisions to dataset definitions, but the purpose and the lawful basis remain the controller's to set.
Configuring Superset for Article 25 and Article 32 in sequence
This sequence turns Superset from a default install into a deployment where personal data is limited to what each purpose needs, access is limited by identity and row, exports are controlled, and activity can be reviewed. Each step produces a record that the controller can show when it explains its measures under Article 25 and Article 32.
Confirm purposes and build the data inventory
Before any Superset object is created, the controller and the data owners list each analytics purpose, the personal data each purpose needs, the source tables that hold it, and who should see the results. Legal or privacy staff sign off on the list, and the data owners confirm the fields they can release. The output is a dataset register that names a purpose and a lawful reason for every personal data field exposed in Superset. Fields without a stated purpose stay out of the first build.
Deploy with a production metadata database
The platform team installs Superset with PostgreSQL or MySQL as the metadata database, using a version within the ranges the configuration documentation lists (PostgreSQL 10 to 17, MySQL 5.7 or 8.x). SQLite and the Docker Compose PostgreSQL container are not suitable for production, according to the architecture documentation. The team also confirms which optional caching and worker components are needed, since alerts, reports and async queries depend on them. Done means the instance starts against the production database, the backup job covers it, and the database sits inside the controlled network segment.
Set a user-specified secret key
The platform engineer generates a unique SECRET_KEY and stores it in the organization's secrets manager, not in a source file or image. Superset requires this value to start, which prevents the instance from running on an insecure default. The team records the rotation procedure using PREVIOUS_SECRET_KEY so that a future rotation does not log users out or break stored credentials unexpectedly. The check is that the key is absent from the repository, the image and the logs, and that rotation has been rehearsed in staging.
Connect the identity provider and map groups to roles
The identity administrator connects Superset login to the organization's identity provider using OAuth2 or LDAP, as supported by Flask-AppBuilder. Local accounts are disabled for ordinary users so that each person signs in with a unique identity. AUTH_ROLES_MAPPING then links directory groups to Superset roles, and the team keeps only the roles needed for each purpose. The output is a test sign-in for one user in each group, showing the expected role and no additional permissions, and a removed test account that can no longer sign in.
Define row level security and dataset rules
The data owners and Superset administrators configure RLS filters so that each role sees only the rows its purpose requires, such as one region, business unit or case set. Datasets are built from curated views that exclude direct identifiers not needed for the purpose, and pseudonymized or aggregated fields are used where the analysis allows it. Each RLS rule and dataset is recorded with its owner and purpose. The check is that test users in each role see only their permitted rows and that a dataset without an approved purpose is not visible to any non-admin role.
Restrict export and download permissions
The Superset administrator removes the export, download and CSV permissions from the general roles and grants them only to named roles that have a documented need. Access to raw SQL Lab queries is limited in the same way, because a user who can run arbitrary queries can extract data that RLS was meant to hide. The output is a permission matrix that lists which roles can view, export, run SQL and change datasets, reviewed by the data owner. The test is that a standard analyst account cannot export a restricted chart.
Enable logging and test in staging
The platform team turns on application and audit logging, routes the logs to the central log platform, and confirms that sign-ins, permission changes, exports and dataset changes are recorded with user identity and time. The full set of measures is then tested in a staging copy that mirrors production roles, RLS rules and data subsets, including an upgrade rehearsal from the upgrade documentation. The output is a signed test record listing each case, its result and the fix applied. Production launches only after the records show that each control works as designed.
Schedule periodic reviews of the measures
Article 25 requires the effectiveness of measures to be reviewed regularly, so the controller sets a review calendar covering the purpose register, group-to-role mappings, RLS rules, export permissions and log samples. Each review is recorded with the reviewer, the changes made and any new purpose that required a new dataset. Upgrades and secret key rotations trigger an extra review. The sequence is complete when the calendar has an owner for each review and the first review has been carried out and documented.
What Superset does not decide or cover for GDPR
Superset enforces the access and logging controls you configure, but it cannot decide why data is processed or how long it lives. The cards below cover the decisions and adjacent controls that stay with your organization as controller, and that an auditor or supervisory authority will still ask you to evidence.
Lawful basis and purpose limitation
Superset does not record why a dataset exists or whether the processing has a lawful basis. Each dataset, chart and dashboard that touches personal data needs a documented purpose, a named owner and a lawful basis agreed with your data protection officer before it is published. Review this list when a new business question is added to an existing dashboard, because a purpose that was clear at build time can drift.
Retention and deletion of source data
Superset queries your warehouse and stores its own metadata, query history and cached results, but it does not decide how long source records are kept. Set retention rules in the warehouse, confirm that Superset caches and async query results expire on a schedule you control, and check that deleted source rows do not persist in exports, scheduled report attachments or dashboard thumbnails.
Data subject request handling
Access, rectification, erasure and restriction requests under the GDPR are answered by your organization, not by a BI tool. Map which datasets, saved charts, exports and scheduled reports hold a given individual's data, so a request can be traced across the warehouse and Superset. Confirm the process for removing that person's rows from cached and exported material, and document how the request was closed.
Breach notification under Articles 33 and 34
Superset logs can help establish what was viewed or exported during an incident, but the decision to notify the supervisory authority and affected individuals sits with the controller and its incident response process. Confirm that audit logs are retained long enough to scope a breach, are forwarded to a system your security team monitors, and that someone is named to assess timelines against Article 33 and Article 34.
Transfer assessments under Chapter V
Where Superset is hosted, backed up or supported remotely from outside the EEA, the arrangement may be a restricted transfer. EDPB Guidelines 05/2021 treat remote access from a third country, even only displaying data on a screen for support, as a transfer, and storage in a cloud outside the EEA as well. Assess hosting locations, support access paths and any third-country legal exposure of your providers before go-live, and record the outcome.
Security of the warehouse and network
Superset's row-level rules only filter what it asks for. The warehouse credentials, network paths, database privileges and encryption in transit and at rest are configured outside Superset, and a weak warehouse can expose personal data regardless of dashboard design. Review the database account Superset uses, the network segment it runs in, and the Article 32 risk assessment that covers both, because the controller remains responsible for the whole chain.
Where hosting choices change the GDPR analysis
Self-hosting inside your own infrastructure does not remove transfer questions. Running Superset in your cloud account or data center keeps the platform under your control, but the GDPR transfer rules follow where personal data is accessed and stored, not only where the software is installed. EDPB Guidelines 05/2021 state that remote access from a third country, even only displaying data on a screen for support or administration, is a transfer, and so is storage in a cloud outside the EEA. A Superset instance hosted in an EU region can therefore still trigger Chapter V if a vendor engineer in another country opens a dashboard to troubleshoot a chart, or if backups of the metadata database are replicated abroad.
The practical question is who can reach the data and from where. Map each path that exposes personal data: the Superset web interface, the metadata database that holds users and permissions, the query engine behind each dataset, the worker and cache layers that hold query results and report attachments, and the backup copies of all of them. For each path, record the operator, their location, and whether support access is granted through a remote session, a jump host or a shared administrator account. Where a processor or its parent is subject to third-country law, the EDPB guidance says controllers should assess that exposure before engaging the processor. The Schrems II judgment (Case C-311/18, 16 July 2020) and the US CLOUD Act provision at 18 U.S.C. 2713 are the reasons this assessment cannot be skipped: the first invalidated the Privacy Shield decision, and the second requires providers to preserve or disclose data in their control regardless of where it is located.
Confirm your own hosting and support access model with counsel before you finalize the Article 25 and Article 32 design, since the answer depends on your contracts, your provider's ownership and your data locations. Ask counsel whether any support path, log export or backup location creates a transfer, and which transfer mechanism applies. Ask your implementation partner to document every administrative and remote access route into the Superset environment so that the record matches what counsel reviews.
How much work and what it costs to configure Superset for GDPR
What drives the effort of configuring Superset for GDPR?
The main drivers are the number of datasets that touch personal data, how complex the row level security rules are, how much identity provider work is needed, and how far the log pipeline has to go. Each dataset needs a review of its columns, a decision on whether personal data is needed for its purpose, and often a masked or aggregated version. RLS effort grows with each role and each rule that depends on region, business unit or customer. Identity work grows when group mapping, deprovisioning and multi-factor settings live in an external directory. Log work grows when export and query events must be retained and shipped to a system your team already reviews. Ask for a count of datasets and roles before any quote.
Can our internal team configure Superset for GDPR without a partner?
Often yes, if the team has Superset administration experience, someone who understands the processing purpose, and time to test changes in staging. The harder parts are usually not the settings themselves but the decisions behind them: which columns are necessary for each purpose, who may export data, and what evidence proves the controls work. Teams without a Superset administrator or without a documented data inventory tend to take longer and may need a partner for the design and testing phases. A partner can be used for a fixed scope, while your team keeps ownership of the decisions and the running system.
How long does a GDPR configuration project take?
Duration depends on scope rather than on a standard period, and no reliable figure can be given until the dataset count, role model, identity provider and logging design are known. A small deployment with a handful of datasets and one identity provider is very different from a multi-tenant instance with dozens of RLS rules and a SIEM integration. Plan time for the data review with the DPO and data owners, for staging tests of RLS and export settings, and for an upgrade plan if the version will change. Ask any provider to split the timeline by phase and to name which phases depend on client decisions.
What do the DPO, data owners and IT need to provide?
The DPO needs to confirm the processing purposes, the lawful basis recorded for each purpose, retention expectations and any restrictions on who may see personal data. Data owners need to say which datasets they own, which columns are needed for their reports, and which users should see which rows. IT needs to provide the staging and production environments, identity provider access for group mapping, database accounts with the least privilege needed, and a place where Superset logs are retained. Agree on who approves changes to RLS rules and export permissions, because those approvals become part of the evidence.
How is a fixed-scope quote built for this work?
A fixed-scope quote follows from a written scope that lists the datasets, roles, RLS rules, identity integrations, export controls and logging items to be configured, along with the deliverables and the acceptance tests for each. The quote covers the planning, build, testing and handover work described in that scope. Anything not in the written scope, such as a new data source or an additional identity provider, is priced separately through a change to that scope. Ask for the assumptions list, the client responsibilities, and the conditions that would change the price or timeline.
What costs recur after the initial configuration?
The one-time costs are the design, build and testing work. Recurring costs include reviewing new datasets and roles, re-running access reviews, applying Superset upgrades, and checking logs and exports on a schedule. Upgrades matter in particular because each version can change behavior, so the team should test RLS and export settings after every change. Ongoing support and continuous testing can be covered by a retainer. Ask any provider to separate one-time and recurring items in the quote so you can budget for both.
Will the work result in a GDPR certificate?
No. The GDPR requires no audit, attestation or certificate, and Article 42 certification is voluntary and issued by accredited certification bodies or supervisory authorities. DeployOpen prepares systems, controls and evidence, but does not issue audit reports, attestations or certifications. Even an approved certification would not reduce your responsibility as controller or processor for compliance. Your data protection authority and, where relevant, an independent assessor determine how your measures are judged.
Keeping the measures effective after go-live
Article 25 measures are not finished at go-live. EDPB Guidelines 4/2019 require controllers to review regularly whether the chosen measures and safeguards remain effective, and that obligation covers systems that were already in place before the GDPR. For Superset, this means a scheduled review of dataset column exposure, RLS rules, the export permissions held by each role, and the logging settings that support your Article 32 evidence. Assign an owner for that review and record each result, so the review itself becomes part of the accountability trail.
Upgrades are where protective settings most often drift. Follow the documented sequence: back up the metadata database, run superset db upgrade and superset init, test in staging first, and check UPDATING.md for breaking changes between versions before you touch production. Confirm that the upgrade does not reset role assignments, RLS filters or export restrictions, because a changed default can silently widen access. Keep the Kubernetes Operator in mind as well: its documentation describes it as alpha with a v1alpha1 API whose schemas may change between releases, so pin versions and treat operator upgrades as higher-risk change control than the application itself.
Rotate the SECRET_KEY on a planned schedule using PREVIOUS_SECRET_KEY so existing sessions and encrypted values stay readable during the transition, and record each rotation in your change log. Pair this with recurring access reviews: export the role and user assignments from Superset, compare them with the identity provider's group membership, and remove leavers and role changes that no longer match a job function. Ask your team to confirm how often these reviews run, who approves them, and where the evidence is stored, since those answers determine whether the measures stay effective.
How DeployOpen scopes and delivers GDPR-aligned Superset configuration
DeployOpen plans, implements and documents Apache Superset inside infrastructure you control, so data minimization, row level security, export limits and access logs are configured and tested against your own processing purposes. Engagements start from a written scope that names the datasets, roles, and evidence in play before any configuration begins.
How we scope
- We map the Superset datasets, dashboards and roles that touch personal data, and record the processing purpose for each.
- We agree in writing which fields to remove, pseudonymize or aggregate, and which RLS rules and export limits apply.
- We confirm the data protection evidence you need, such as configuration records and access logs, before any build work starts.
How we build
- We deploy Superset on your infrastructure with PostgreSQL or MySQL as the metadata database and a user-specified SECRET_KEY.
- We configure SSO through your identity provider, map groups to Superset roles, and test RLS rules with real access scenarios.
- We set export restrictions, alert and report recipients, and logging, then test each control against the scoped requirements.
How we hand over
- You receive a written record of the datasets, roles, RLS rules and export settings, with the reasoning behind each choice.
- You receive test results showing which access paths were checked and what each check showed, for your own review.
- You receive a runbook for reviewing role membership, RLS rules and logs on a schedule you set.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, sized to the scope agreed in writing.
- We plan Superset upgrades with a metadata database backup, staging tests and a review of breaking changes before each release.
- We re-test access controls after changes to datasets, roles or identity provider groups, so the record stays current with the system.
