When your data lives inside Databricks, access control is not a single switch—it’s a web of permissions, groups, and workspace-level configurations. The core of Data Access and Deletion Support starts with knowing exactly who can see and change what. Without that map, your compliance promises are just words.
Understand the Layers of Access Control
Databricks provides multiple layers:
- Workspace Access: Controls who enters a workspace at all.
- Cluster Permissions: Decides who can run jobs or connect to compute.
- Table and View Permissions: Managed through Unity Catalog or legacy table ACLs, these define read and write rights.
- Data Masks and Row-Level Security: Enforce fine-grained control for sensitive data subsets.
To support deletion requests properly, you need to link these layers. A deletion operation that runs on the wrong cluster, or under the wrong identity, risks missing records or violating retention rules.
Map Identities Across Clouds
Databricks integrates with IAM systems from AWS, Azure, and GCP. But roles and groups in one cloud may not match cleanly to another. Track the service principals, human users, and automated jobs. Align them so that when you revoke access, you revoke it everywhere. During deletion, run operations under a clear, traceable identity.
Design a Repeatable Deletion Workflow
Deletion is not only dropping rows. You need to: