SAC security across S/4HANA and Datasphere: free authorization matrix template (.xlsx)

Security in a SAP Analytics Cloud landscape rarely breaks in one place. A story looks fine for the admin who built it, then a planner in another business unit sees the wrong numbers — or none at all. The cause is usually that data security lives in three different places depending on where the data sits: SAC itself, S/4HANA, or SAP Datasphere. This guide explains each layer and gives you a free Excel matrix to design and test all of them in one file.

Two questions, two layers

Every access decision answers two separate questions:

• What can this user do? Open stories, create models, enter plan data, administer the tenant. That's functional security: SAC roles (and the license each role consumes), Datasphere roles, S/4HANA business roles.
• Which data can this user see or change? Company code 1000 but not 2000, Business unit 1 but not Business unit 2, the Forecast version but not Budget. That's data security — and where it's enforced depends on the model type.

In SAC, a role consumes one license type, and a user's consumption comes from the roles they're assigned directly or through teams. Standard roles such as BI Admin, BI Content Creator and BI Viewer are a starting point; most projects build custom roles around business needs.

Where data security is enforced

1. Import and planning models: SAC Data Access Control

When data is stored in SAC, you restrict it in the model. Enable Data Access Control on a dimension in the model preferences, then grant Read or Write on members to users or teams. Things that catch people out:

• Permissions on a hierarchy node are inherited by its children — grant at the right level.
• It applies to transaction data; master data (member lists) isn't hidden.
• The Version dimension adds a Delete permission and defaults to no access — grant it explicitly or planners see empty versions.
• A user with no assignment on a DAC-enabled dimension sees nothing.
• Users with Full Data Access (e.g. BI Admin) and the model owner see everything. That's why "it works for me" proves nothing.

For planning models built on our templates (for example the Version dimension guide), the Business unit and Version dimensions are the usual candidates.

2. Live connections to S/4HANA: authorizations stay in the source

With a live connection, SAC doesn't store the data, so it can't filter it. S/4HANA evaluates the authorizations of the logged-in user — role restrictions, CDS access controls (DCL) on the views you consume. Two consequences:

• The user must reach S/4HANA as themselves: plan SSO / principal propagation with your identity setup before you design stories.
• When a user sees no data, the answer is usually on the backend (authorization trace, missing role), not in SAC.

Not sure whether a model should be live or import? Our Live vs Import decision tool and Live-Ready checker cover that choice.

3. SAP Datasphere: Data Access Controls on views

In Datasphere, row-level security is done with Data Access Controls, created by space administrators and applied by modelers to views. SAP documents four types: Single Values, Operator and Values, Hierarchy and Hierarchy with Directory, each driven by a permissions entity that maps user IDs to allowed values. SAP's guidance is to secure data as early as possible, apply one targeted control on a combined view rather than many, and avoid more than 5,000 permission records per user in Operator and Values controls. Business users who only consume Datasphere data through SAC typically get the DW Consumer role, which doesn't log in to Datasphere itself.

How to use the matrix

1. Personas — one row per group with the same access: license, SAC roles and team, Datasphere role and spaces, S/4HANA role, SSO need. A formula flags any SAC team with no data-access rule as Missing.
2. SAC Roles — standard vs custom, license consumed, Full Data Access yes/no.
3. SAC Data Access — model, dimension, member or node, team, Read/Write/Delete.
4. Datasphere DAC — space, protected view, DAC type, criteria and permissions entity; a check flags Operator and Values controls above 5,000 records per user.
5. S4 Live Auth — live source, restriction field (e.g. company code), authorization object or DCL, SSO status, test user.
6. Access Tests — expected vs actual per test user; Pass/Fail is calculated and rolls up to a pass rate on the README dashboard.

Yellow cells are inputs; the blue italic row is an example to overwrite.

Test with real test users — every quarter

Design isn't proof. Create at least one test user per persona (never test as an admin) and run the Access Tests tab before go-live and after each quarterly release. QRC4 2026 lands on 14–15 November: our QRC4 Impact Check builds the rest of your test plan in 30 seconds.

Common pitfalls

• Testing as the model owner or a BI Admin — both bypass Data Access Control.
• Forgetting Version security, so planners can't see or write the Forecast.
• Restricting in SAC what is actually a live model — the restriction belongs in S/4HANA.
• One Datasphere DAC per source view instead of one on the consumption view.
• Assigning roles user by user instead of through teams, which makes license consumption hard to read.

Sources (October 2026): SAP Learning — Managing security and administration in SAP Analytics Cloud (roles, licenses, Data Access Control, Version security); SAP Datasphere documentation — Standard Roles Delivered with SAP Datasphere, Securing Data with Data Access Controls, Create a Data Access Control; Nextlytics — authorization concept for SAP Analytics Cloud; Mindset Consulting — SAC security troubleshooting guide. Built from public documentation, not tested in a tenant. Role names and license mapping vary by tenant and contract — verify in yours. Independent project, not affiliated with SAP SE. SAP, SAP Analytics Cloud, SAP S/4HANA and SAP Datasphere are trademarks of SAP SE.