Data Product governance in SAP BDC: access on request
What Data Product governance in SAP Business Data Cloud (wave 2026.20) changes: access requests, data stewards, access agreements and how to prepare.
Table of contents
Wave 2026.20 of SAP Business Data Cloud, which SAP planned to roll out on 23 September 2026, brings Data Product governance. Access to a Data Product is no longer something granted quietly behind the scenes: it becomes a request that someone reviews and that gets recorded. If your BI team shares Data Products with other departments or platforms, this matters more than it looks.
What it is
According to SAP, the new capability adds a structured, auditable process for controlling who can access which Data Product. The building blocks are:
- Access requests: anyone who wants to consume a Data Product asks for it, and the request is tracked, reviewed and stored.
- A central Governance area: where data stewards review incoming requests and approve or reject them.
- Terms and conditions that can be defined at domain level and at Data Product level.
- Automatic approval, meant to give low-friction access in development and test environments.
- Access agreements: on approval, BDC turns the request into an agreement that records who asked for access, why, the target environment, the approved endpoints and the expiry date.
The key detail: even when approval is automatic, the agreement is still created. You can remove friction without losing traceability.
Why a BI team should care
In BW we were used to security meaning analysis authorizations and roles: technical, fine-grained and, almost always, handled by the BI team itself one ticket at a time. With Data Products the problem changes scale. The same product can end up being consumed from Datasphere, from a third-party platform or from another tenant. The question is no longer just “can this user see this company code?” but “who is using this product, for what, and until when?”.
That is where a request-based model adds value:
- Auditing without spreadsheets: the reason and the target environment are stored with the approval.
- Expiry: access has an end date, something that almost never gets reviewed when permissions are granted by hand.
- Clear accountability: the domain’s data steward approves, not the technical admin who “happened to have the rights”.
How I would prepare it on a project
The tool is the easy part. What makes it work is the groundwork. This is the checklist I would close before switching it on:
| Decision | Question to answer | My recommendation |
|---|---|---|
| Domains | Which business domains do we have and who owns each one? | Few, aligned with the business (Finance, Sales, Operations) |
| Data stewards | Who approves in each domain, and who covers for them? | A business person with a deputy, not only IT |
| Terms and conditions | What use is allowed? Is there personal data? | Short text at domain level; exceptions on the Data Product |
| Automatic approval | In which environments is access approved without review? | Development and test only, never production |
| Expiry | How long does access last by default? | Short periods with explicit renewal |
| Periodic review | Who reviews the active agreements? | Quarterly review per domain |
Two more tips:
- Start with a pilot domain. Pick one with few consumers and an engaged steward. You will quickly see whether approval times are acceptable.
- Agree an approval SLA. If a request takes two weeks, people will look for shortcuts (extracts, copies in a sandbox) and governance stays on paper.
What it does not solve (and what I would ask SAP)
Access governance decides who can consume a Data Product. It does not replace row-level security or data quality. In a group with several legal entities, having approved access to a product does not mean someone should see every entity it contains.
Before designing the final model, these are the questions I would take to SAP or the partner:
- How does this governance work alongside the row-level permissions we already have in Datasphere?
- What exactly happens when an agreement expires, for each type of consumer?
- Can agreements be exported for internal audit or for the data protection officer?
- Does it apply the same way to SAP’s standard Data Products and to the ones we build ourselves?
I do not yet have verified answers to these questions, which is exactly why they are worth asking before promising anything to audit.
My recommendation
If you are already sharing Data Products, do not wait for an incident to put access in order. Name owners and stewards per domain, write short terms and conditions, limit automatic approval to development and test, and start with a pilot. The configuration is the easy bit; agreeing who approves takes weeks, so start there.