Concept card

Data Access Controls (DAC)

As of 2026-07-24T14:00:00Z

Edited by Cédric-Olivier Mâry, sole editor and publication director — 27 years in the SAP ecosystem. How these pages are produced, and where automation is used.

What is Data Access Controls (DAC)?

One DAC rule at Catalog scope governs every consumer at once — SAC, Joule, Delta Sharing, OData, JDBC — replacing the three or four separate row-security policies a generic warehouse stack would need.

Data Access Controls, DAC, are SAP Datasphere's catalog-level security mechanism for restricting which rows and which columns a given user is allowed to see. The defining property is not the predicate logic itself — row-level security exists in every mature database — but where the rule lives: a DAC rule is attached once, at the catalog object, and every consumer reading through that object inherits the same restriction automatically. SAC stories, Joule agents, Delta Sharing partners, OData clients, JDBC connections — one rule, enforced identically everywhere, with no separate policy to maintain per tool.

Why this matters more than it sounds

In a generic warehouse-plus-BI-tool-plus-API-gateway stack, achieving the same row-level guarantee typically means writing the filter logic three or four times over: once in the warehouse's native row-security feature, once in the transformation layer, once in the BI tool's own security model, and once again in whatever service exposes the data externally. Each duplicate is a place the logic can drift out of sync — someone updates the BI-tool rule after a reorganisation and forgets the warehouse-side rule, and for a stretch of time a user sees data they should not. DAC collapses that surface to one place. This is the argument analytics leads make to a skeptical governance or security team: fewer places for a security gap to hide, and one location to demonstrate compliance from during an audit.

How it works

Why it matters

A single predicate applied at the lowest exposed view layer reaches every downstream consumer, eliminating policy drift across BI tool, warehouse, and API gateway.
The region/geography filter pattern doubles as the GDPR compliance mechanism — one rule serves both sales reporting and regulatory obligation.
DAC rules are named, versioned, code-reviewable catalog objects — security policy becomes an auditable artifact instead of tribal config scattered across tools.

Key points

Catalog-level row + column security; one rule reaches SAC + Joule + Delta Share + OData + JDBC.
Predicate references session attributes ($$session_user) and target object columns.
Bind at the lowest exposed view — never just on the Analytic Model.
Five canonical patterns: region · cost-centre · segment · time-window · PII column-mask.
Authorization mapping table owned by HR/IAM, refreshed hourly, wired to IdP claims.
Push-down preserved: query-rewrite adds WHERE clause, HANA executes as standard plan.
DAC vs SAC roles: DAC = row scope (cross-tool); SAC roles = object access only.
Overhead 3-5 ms per rule per query; above ~10 stacked rules, consolidate via composite mapping.
Data Access Controls (DAC) is mastered only when it changes a named buyer decision.
Start with the semantic contract and control model before demonstrating the tool.

Terms used on this page

DAC (Data Access Control): Catalog-level row/column security rule applied at query-rewrite time.
DAC predicate: SQL boolean expression that decides if a row passes the security filter for the calling user.
Session attribute: Per-user value resolved from IdP claims, group memberships, or lookup tables. Referenced as $$session_user.X.
Authorization mapping table: Customer-managed table mapping USER_ID to allowed scopes (region, cost-centre, segment). Joined by DAC predicates.
Column masking: DAC variant that returns a fixed string (e.g. '***MASKED***') instead of the real column value when the rule fires.
Cross-tool reach: DAC's defining property — a rule on a catalog object applies to every consumer that reads the object, not just to one BI tool.
Query-rewrite: Datasphere optimizer phase where the user's SQL is wrapped in additional WHERE / SELECT clauses to enforce DAC. Push-down preserved.
ABAC: Attribute-Based Access Control — preview feature, tag-driven policy inheritance from the Catalog hierarchy. H2 2026 GA target.

Sources

Full card available to members. What the full card adds: the full decision framework · the SAP vs Snowflake / Databricks / Fabric comparison · the common pitfalls and their fix · the cheat sheet · the architecture schemas · the code blocks · the facts worth quoting.

Open in the app →