Where your data sits, and who can reach it.
Every procurement review arrives at the same two questions, and most vendor pages answer neither clearly. Your tables and files stay in cloud storage you own, in the region you choose. Databricks runs a control plane — the interface, the scheduling, the metadata — and the work itself runs in a compute plane that sits either inside your own cloud account or in a Databricks-managed account in the same region, depending on a choice you make. That choice decides which controls are yours to configure and which are Databricks’ to attest, which is why it deserves more than a default.
Two planes, and one decision that follows from them.
If you take one diagram from this section, take this one. Almost every security question about Databricks resolves into “which plane is that in?”
Serverless or classic: an honest trade.
Databricks recommends serverless wherever it is available, and for most workloads that is right. But the recommendation is not universal, and a risk review that has not had this conversation has not been done.
You want the platform to carry the operational burden
- Load is bursty and idle time is where your money currently goes.
- You do not want to patch, size or capacity-plan compute.
- Egress controls and customer-managed keys satisfy your requirements.
- You want features — AI functions among them — that need it.
A requirement names the account the compute runs in
- A regulator, a contract or an internal policy requires compute inside your own account.
- You need network controls that only exist in your own VPC.
- You have instance-level requirements — specific hardware, specific images.
- An existing approved pattern already covers it and re-approval is costly.
The mistake we see is choosing classic out of caution, inheriting all of its operational work, and then not configuring the controls that were the reason for choosing it. If you take classic, take it deliberately and configure it. If the requirement cannot be stated in a sentence, it is probably not a requirement.
Named features, and what each is for.
These are the controls Databricks names. Each has prerequisites and a tier, and we size them against your actual obligations rather than switching on everything that sounds reassuring — because every control you enable is also a thing that can break a deployment at an awkward moment.
| Control | What it addresses | The question it answers |
|---|---|---|
| Customer-Managed Keys | Encryption using keys held in your own key management service rather than the platform’s. | “Can we revoke access to our own data unilaterally?” |
| Multi-Key Encryption | More than one key in play, so different data can be encrypted under different keys. | “Can one tenant’s or one entity’s data be cryptographically separated?” |
| Private Link | Private network connectivity, so traffic does not traverse the public internet. | “Is any of this reachable from, or reaching out to, the open internet?” |
| Serverless Egress Controls | Constraining where serverless workloads are permitted to send traffic. | “Could a notebook post our data to an arbitrary external host?” |
| Enhanced Security and Compliance | The hardened configuration profile used for regulated workloads. | “Is this workspace configured for the standard we are bound by?” |
| Unified Security for Data and AI | One control point over both data and AI assets, through Unity Catalog and the gateway. | “Who decides what an agent is allowed to read?” |
| Employee access control | Whether Databricks staff can access your workspace at all — a setting you control. | “Can the vendor see our data?” This is the one auditors ask most sharply. |
On compliance, be precise about wording. Databricks is attested to ISO 27001, ISO 27017, ISO 27018 and SOC 2 Type II, and offers PCI-DSS, HIPAA and FedRAMP compliance. An offering is a configuration and a tier, not a default — a regulated workload is a procurement item. The plain-language security commitment sits in the Security Addendum of the customer agreement, and that is the document to read rather than the marketing page.
Unusually specific, which is itself a signal.
Most platform vendors answer “how do you secure yourselves?” with a page of adjectives. Databricks publishes numbers, and the specificity is worth noting in a vendor assessment — not because the numbers are impressive in themselves, but because an organisation willing to publish a count is usually one that keeps the count.
Alongside those: static and dynamic analysis before code reaches production, severity-zero issues prioritised above everything else, a public bug bounty through HackerOne, an immutable infrastructure model in both planes, multi-factor authentication and single sign-on for production access, least-privilege controls with separation of duties, security design reviews for high-impact features, peer code review, and multi-person approval for deployments.
Lakewatch, and what it tells you
In March 2026 Databricks launched its own security monitoring product: Lakewatch, an open, agentic SIEM built as a security lakehouse rather than a tool you pay to copy your logs into. Triage uses agents built on Agent Bricks, Genie handles multi-step investigation, and an assistant writes, tests and deploys detections. Databricks claims petabyte-scale detection at up to 80% lower total cost of ownership, names Adobe and Dropbox among early customers, and uses Anthropic’s Claude models inside it.
It is in private preview, so treat it as a direction rather than a plan. What it does tell you is that Databricks runs its own security operations on this architecture — which is a more meaningful endorsement than a certificate.
What is available near Sri Lanka, and the caveat that matters.
We work from Colombo, so this question comes up on every engagement, and the answer has two parts: which regions exist, and which features have reached them. The second part is the one that changes architectures.
Mumbai and Singapore
Asia Pacific (Mumbai) and Asia Pacific (Singapore) both appear with serverless support on Databricks’ regional availability tables, alongside Tokyo and Seoul. The AI and machine learning table shows both as supported, with a note that Asia-region traffic may be processed within regions in Japan, South Korea or Singapore.
asia-south1 and asia-southeast1
Mumbai maps to asia-south1 and Singapore to asia-southeast1 on the Google Cloud region list, with support for the core feature columns. Some features — certain Lakeflow connectors among them — have narrower availability.
Maintained separately
Azure Databricks keeps its own region list, and we have not been able to confirm its Asia-region feature coverage from the pages we checked. For an Azure-first organisation this is a question to resolve against the current Azure Databricks documentation before design, not after.
Region support and feature support are different questions
A region appearing on the list does not mean every service in it is available. Individual features reach regions at different times, and the one that bites hardest is usually a Lakeflow connector or an AI service that is not there yet. That is not a timeline problem — it changes the architecture, because the fallback is a different ingestion method or a different region for one workload.
We check the current region and feature tables for the specific services a design depends on, and we write down what we checked and when. A note that said “supported” eight months ago is not evidence.
One more consideration for organisations in Sri Lanka and the region: data residency requirements are set by your sector and your contracts, not by the platform. The region choice is the easy half. Knowing whether your own obligations permit Mumbai or Singapore, and what your customers were told, is the half worth getting advice on.
Where these controls get applied.
Architecture decides what is possible. These decide what actually happens.
Unity Catalog
Tables, files, models, agents and dashboards in one permission model, with column-level lineage, attribute-based policies and a gateway that governs what AI is allowed to touch.
Read it →Sharing and collaborationOpenSharing
An open protocol for handing live tables, models and files to another company on another platform, with clean rooms for the work neither side may see, and a marketplace.
Read it →The billPricing and Cost
How consumption pricing works, what a DBU is, which products bill separately, and the handful of settings that decide whether your platform costs double what it should.
Read it →Where this leads next.
© 2026 Mawkish Technologies. This guide, its diagrams and illustrations are protected by copyright. You’re welcome to learn from it and to quote it with credit and a link. Reproducing it, by hand or through AI, and publishing it as your own is not allowed. Read our copyright notice
What risk and procurement ask.
Where does our data physically sit?
Your tables and files stay in your own cloud storage, in the region you pick. Databricks runs a multi-tenant control plane — the interface, job orchestration, metadata — and the work itself runs in a compute plane. With classic compute that plane is inside your cloud account; with serverless it runs in a Databricks-managed account in the same region.
That distinction drives most security conversations, because it decides which network controls are yours to configure and which are Databricks' to attest.
Which certifications does Databricks hold?
It publishes attestations for ISO 27001, ISO 27017, ISO 27018 and SOC 2 Type II, and offerings for PCI-DSS, HIPAA and FedRAMP compliance. A plain-language security commitment sits in the Security Addendum of the customer agreement.
An offering is not the same as a default. A compliance-bound workload needs the right tier and the right configuration, and that is a procurement item, not a tick box.
Can we hold our own encryption keys?
Customer-managed keys and multi-key encryption are both named features. Private Link and serverless egress controls cover the network side, letting you keep traffic off the public internet and constrain where serverless workloads may reach.
Each of these has prerequisites and a tier. We size them against your actual obligations rather than switching on everything that sounds reassuring.
How does Databricks look after its own platform?
It publishes an unusual amount of detail: daily authenticated vulnerability scans, static and dynamic analysis before code reaches production, roughly 8 to 10 external and 15 to 20 internal penetration tests a year, a public bug bounty through HackerOne, an immutable infrastructure model where systems are replaced rather than patched, multi-factor authentication and single sign-on for production access, multi-person approval for deployments, and the ability for a customer to control whether Databricks staff can access their workspace at all.
It also runs its own platform as its security monitoring system, processing more than 9TB a day. Make of that what you like, but it is a meaningful signal.
What is Lakewatch?
Databricks' own security product, launched in March 2026 as an open, agentic SIEM in private preview. The pitch is a security lakehouse rather than a tool that charges you to copy logs into it: petabyte-scale detection and investigation on the same architecture, with triage agents built on Agent Bricks, Genie for multi-step investigation, and an assistant that writes, tests and deploys detections. Databricks claims up to 80% lower total cost of ownership and names Adobe and Dropbox among early customers. Anthropic's Claude models are used inside it.
It is in private preview. Treat it as a direction, not a plan.
Send us your security questionnaire.
We will work through it against what Databricks actually publishes, mark what is attested, what is an offering requiring configuration, and what we could not verify — and give you back a design with the controls chosen to match your obligations rather than everything switched on for comfort.
- Serverless or classic, decided on a stated requirement
- Controls matched to obligations, not to anxiety
- Region and feature availability checked and dated
- The Security Addendum read, not the marketing page
- What we could not verify, said plainly
Databricks, Lakehouse, Lakeflow, Lakebase, Unity Catalog, Genie, Agent Bricks, OpenSharing, Delta Sharing and Lakewatch are trademarks of Databricks, Inc. Apache, Apache Spark, Apache Iceberg and Spark are trademarks of the Apache Software Foundation. Delta Lake and MLflow are projects of the Linux Foundation. SAP, SAP Business Data Cloud and SAP Datasphere are trademarks of SAP SE. PostgreSQL is a trademark of the PostgreSQL Community Association. All other names belong to their owners. Mawkish Technologies is not affiliated with, endorsed by or a reseller for Databricks, Inc. Everything described here is taken from material Databricks publishes; product names, availability and prices change, so check the current documentation before you commit to anything. Screens shown are our own illustrations with sample data, not screenshots.
The Urihaven Map is our shorthand for looking after the details nobody sees in Databricks Security and Architecture.