What’s New in Security and Compliance on the Databricks Data and AI platform

Summary

• Private connectivity: Databricks enables end-to-end private connectivity from users to the platform and to data sources, preventing unauthorized access.
• Data protection: Platform capabilities prevent data exfiltration and restrict access to only authorized workspaces, ensuring data remains isolated.
• Compliance standards: Databricks offers multiple compliance standards and certifications across AWS, Azure, and Google Cloud for regulated environments.

What’s New in Security and Compliance on the Databricks Data and AI platform

Talk by Filippo Seracini, Staff Product Manager, Databricks ; Suresh Thiru, Senior Director, Product Management, Databricks
In this video, we’ll walk through the latest advancements in platform security and compliance on Databricks — from networking updates to encryption, serverless security and new compliance certifications across AWS, Azure and Google Cloud. We’ll also share our roadmap and best practices for how to securely configure workloads on Databricks SQL Serverless, Unity Catalog, Mosaic AI and more — at scale. If you're building on Databricks and want to stay ahead of evolving risk and regulatory demands, this video is your guide.
Here’s more to explore:
Unified and open governance for data and AI: https://www.databricks.com/product/unity-catalog
See all the product announcements from Data + AI Summit: https://www.databricks.com/events/dataaisummit-2025-announcements

Chapters

• 0:00 Introduction and overview
• 5:13 Trusted platform access
• 15:11 Context-based ingress demo
• 17:50 Preventing data exfiltration
• 24:12 Data protection and encryption
• 30:28 Restricting data access
• 31:22 Compliance and security profiles
• 32:49 Compliance roadmap and expansion
• 36:41 Enhanced security and additions
• 41:51 Conclusion and call to action

FAQs

How does Databricks prevent data exfiltration?

Databricks blocks unauthorized outbound connections and restricts workspace access to prevent data exfiltration. This video explains platform-native security capabilities.

What compliance certifications does Databricks support?

Databricks provides compliance standards across AWS, Azure, and Google Cloud for industries requiring regulatory adherence on the Databricks Data and AI platform.

How can we prevent unauthorized access across our data and AI environment?

This video covers security and compliance features across the Databricks Data and AI platform including network security, identity controls, and data encryption. The platform provides defense-in-depth with multiple layers of access control. Unity Catalog enforces consistent governance across data and AI assets.

What is an agent control plane?

This video explains the agent control plane as part of the Databricks Data and AI platform security architecture. It provides centralized governance for agent access to data and tools. The control plane ensures only authorized agents can execute and access only permitted resources.

end-to-end platform security across data, governance, and AI?

This video presents the Databricks Data and AI platform holistic security approach covering data encryption, network isolation, fine-grained access control, and audit logging. Security spans all layers from infrastructure through governance to application. The platform helps organizations meet compliance requirements across multiple frameworks.

Full transcript

0:00 Introduction and overview

Good morning everyone. I lead the platform PM team. I'm joined with Philippo in my team and he leads all of compliance and GV clouds. Once again, thanks for joining us. You might have seen this slide many times by now. We'll be discussing a few roadmap items that are subject to change after the session. Please do take the survey and provide your feedback. If you have any enhancement requirements or challenges that you face with networking and security, please do share the details and also reach out to us in conversations with many of you and other customers. one important needs come up consistently.
How do we as customers adopt geni and serverless that handle sensitive data like PII, PHI or HR records while staying compliant and minimizing exposure risk. You want the power of genai and serverless but with the confidence that your data, users and workspaces remain isolated, encrypted and auditable. In this session, we'll talk about how the platform enables exactly that. By the end of the session, you will have a clear understanding of how the platform provides end-to-end private connectivity from users and apps to the databicks platform and from the databris platform to any data source.
Second, how the platform prevents data exfiltration by blocking outbound connections to unauthorized destinations. And third, restricts data access to only authorized workspaces. So other workspaces cannot access your data. And finally, datab bricks offers many compliance standards and we'll go over how you can enable them with a single toggle. Now you might wonder why did these foundational capabilities matter? Because to unlock the power of AI and serverless potential, you need a platform that is not only powerful but also secure and easy to adopt.
And we'll talk about, you know, platform native capabilities to secure your environment. If you're not familiar with the datab bricks architecture, the platform decouples with a control plane and a data plane. The control plane is where we are handling things like authentication, authorization, logging, monitoring, cluster management, job scheduleuler and many other functions. In the data plane is where your data is being processed like running SQL queries, jobs, notebooks, data bricks apps, machine learn machine learning workloads and many more.
In the classic data plane, compute runs in your cloud account. In the case of serverless, we manage compute and makes it much more efficient. Now we'll talk about how you can leverage these capabilities to get the most out of the platform and protect your environment. These are the four steps that you need to take in order to leverage the platform native security and compliance capabilities. First ensure trusted access by validating users and applications access the datab bricks platform from authorized locations with the strong uh strong authentication.
Second, prevent data exfiltration. As I mentioned earlier, you take you configured the platform capabilities to block outbound connections to unauthorized destination whether that is cloud storage or any external system. And third restricts data access to only your workspaces. If you have multiple workspaces, you may want to provide data access to only specific workspace. We'll show you how you can make that happen. And finally, enable compliance.
We support so many compliance standards and you can enable them with a single toggle in order to meet all of your compliance requirements. Taken together, all of these capabilities help you to create a guardrail so that you can run fast and stay secure. Let's go over each step with the corresponding capabilities that we offer in the platform. We'll start off with ensure trusted access platform. The datab bricks platform prevents unauthorized access with capabilities like multiffactor passwordless IPL contextbased access control and private link.

5:13 Trusted platform access

Starting with multiffactor authentication um passwordless authentication the platform natively supports multiffactor password authentication and deep integration with your identity provider. The most secure option to access datab bricks platform is using single sign on with unified login. If you're not familiar with the unified logging, we introduced that feature recently to streamline the SSO configuration across all your workspaces in a given account.
So once you configure the SSO at that account level, that configuration is applied across all workspaces. It also enables collaboration using Genie or AIBI dashboards to all your users and minimizes and you know reduces all the frictions with login. You can also ensure access to the platform during SSO outages because we provide emergency access. for some reason you have not implemented SSO or if SSO is not in place the next best option to access the platform is through datab bricks managed multiffactor authentication we strongly recommend you to enable MFA for protecting all your users and data if you're not familiar with MFA it's a multiffactor authentication it requires more than you know one factor you know the first factor is password then you need another factor like security key or OTP um as the second factor.
We talked about login strong authentication and the next step is ensuring access coming from authorized locations and the way you can do that is with IPAL. Today we support IPAL and now we are introducing contextbased ingress which is takes it to the next level. Now you not only filter access based on IP address but also based on identity. So the combination of IP address and identity gives you precise control of who can access from where and to what APIs within the platform.
And finally you can keep the traffic all private using private link and we do support front-end private link between user and apps to the uh between user and apps and the datab bricks platform. The platform is also flexible to support any connections over the internet using your corporate IP addresses. So the platform has the flexibility to support both private and connection over the internet and you can decide which one to choose.
Most enterprises go with private link. Now I talked about the ingress control. Let me explain some of the use cases that we see and how it is applicable for you. A few years ago you know we just started with the notebooks data engineering products. Now if you look at data bricks we support so many products and continue to support more and more products you know data bricks apps that we uh made it generally available model serving endpoints vector search and many more are going to come.
So in a single workspace you have multiple products. Next your data bricks enment also grows with other external services. Basically you are in you're exposing the data bricks platform as part of the integration with external services like Salesforce and other platform. Now how do you restrict access in this scenario? Most enterprises provide access to the datab bricks platform for all their users from their corporate network and that's why you know you see natted IP which is a IP range that you get from service providers and that's how you access the platform and you access all the workspaces which means all the endpoints for all the users.
Now if a credential is stolen that credential cannot be accessed uh using that credential one cannot access the databicks platform from the internet right and that's what helps you with the IPO filtering then the next question is you want to integrate with the Salesforce right for example you want to integrate Salesforce with model serving endpoint in the datab bricks platform and if If you think about Salesforce, they provide fixed IP egress, which means that fixed egress IPs shared across all tenants.
If your credential is compromised for some reason, any Salesforce tenant can access your workspace, right? How do we prevent that? Right? The second scenario is SAS BI tools like PowerBI, right? which does not have fixed egress IPs and they provide dynamic IPs. In this case, you can you not you cannot even use IPLE. If you have to provide access from PowerBI to the datab bricks platform, you pretty much open access from anywhere.
Right? IPL is not applicable at all. Now your requirement is ensuring PowerBI access only SQL endpoint and nothing else. Right? through this access path. You don't want to expose notebooks, queries, jobs, model serving endpoints, right? You want to restrict PowerBI talking to SQL endpoints only. So, how do you do that? Right? And that's where the contextbased ingress comes into play. And finally, you have admins, right?
If you are admins, you want to make sure that you provide access to admin APIs from highly trusted networks, right? uh from corporate VPN or dedicated subnet right all of these use cases or requirements is what we heard from many of you now that's why we are introducing contextbased ingress control which is currently in private preview on all three clouds with contextbased ingress control you can accomplish whatever I described in the previous slide all the use cases that I mentioned so let me walk you through the details So if you look at the diagram you have source which means you know users or applications accessing the data bricks platform and then we talked about the datab bricks platform has got multiple endpoints right multiple products model serving endpoints apps SQL admin APIs right and many more now you want to create an ingress rule and provide access only to what is absolutely needed so that you can implement the principle of least privilege by default.
So the way the ingress control works is sort by three components source based filtering first. So you define the source the source could be IP address range identity or the combination of the two. If you define the rule combining IP address ranges and identities, both conditions have to be met in order for the platform to grant access. And the next step is to define what that source can access. And here with the targeted API scope you can specific you can specify exactly what is the API endpoint that source can access.
Okay. So now you have who from where can access what right? So you have this complete rules you can define with contextbased ingress. We also support multi-ruule policies. What does that mean? You can create complex ingress allow and deny list or rules within a single policy. For example, you may want to provide access to the datab bricks platform from certain IP address IP address range. For other endpoints, you may need both IP address range ranges and identity.
Right? So that is the kind of policy you can define with context basing risk control. This feature is currently in private preview. Uh if you any of you are interested, please reach out to us. We can enable it for you so that you can play with it and give us feedback on how we can continue to improve. If it doesn't satisfy any of your requirements, please do let us know. So this is demo time. Let me show you how you know the contextbased ingress actually works.

15:11 Context-based ingress demo

In this case, let's assume that you as a customer has two requirements. First, provide access to the data bricks platform from corporate network only for all users and identities including service principles. Second, provide access to SQL endpoint only from SASBI for all users or group of users. Let's assume that's your requirements and then we can go through the demo. anyway I I can explain. Uh so you go to the network policy from the cloud resources and you define the ingress rule.
As you can see we talked about the sourcebased filtering. You provide your network source which could be your corporate IP address range and then you uh select in this case we selected all workspaces all workspace UI API right because users are coming from the corporate network and you're trusting them then I'm creating a second row in this case I selected all users but you can also select a group again you provide the network source what you want and where it comes from where these users are coming from and then you define the destination filter.
In this case, we are giving access to these users only to the SQL endpoint and nothing else. Through this access path, those users cannot access any other endpoints. They can't access model serving. They can't access data bricks apps or admin APIs. So now once you define these rules you want to apply these rules on selected or all workspaces. So again you go to the workspace you click the network policy and then you select the rules that you defined it's done.
You can apply these rules across many workspaces. In this example I have applied these rules in two workspaces dev and stage. So now we have covered ensured trusted access which basically validating users and applications accessing the platform with the strong authentication access control and ensuring that traffic goes over the private link. Next I'm going to cover about prevent data excfiltration. how you can control outbound action, outbound connections.

17:50 Preventing data exfiltration

So far we discussed what can enter to the datab bricks platform. Obviously the other side of the equation is about what can leave the platform, right? And you want to have precise control over where your data can go. So before I go into the details, we see two scenarios in which data can be exfiltrated whether accidentally or maliciously, right? So let me walk you through the two scenarios. you have a compromised workload and that compromised workload can reach cloud unapproved cloud storage um either accidentally or maliciously.
Right? This might involve interactive users or automated workloads pulling in and executing untrusted internet hosted libraries. That's one way the you know compromised workload can reach unauthorized storage destination. The second scenario is the risk of your workspace accessing another workspace which may have path to internet. Basically you're take you know let's say your workspace you completely blocked internet access but the second workspace has got full internet access.
If you allow your workspace to talk to the workspace API of the second interface which has got the internet access, one can exfiltrate the data through the second interface, second workspace through the workspace APIs. So obviously you want to prevent crossworkspace interactions. So let me walk you through what are the capabilities that we are providing in the platform to prevent data excfiltration for both use cases that I mentioned.
The platform supports two capabilities. Unity catalog with external locations. Basically your admin can govern access to cloud storage in a central and policy in a centralized policy. So with that policy once they define where your workloads or users can access cloud storage data cannot be exfiltr exfiltrated through unapproved storage path. Even if users try to access private storage bucket or any other unapproved storage destination, UC will block that.
You see and serverless secrets control will block that automatically. That way you're reducing data excfiltration. The second feature that we introduced for serverless environment is serverless egress control. With serverless egress control, you can control where your data can lead. Pretty much, you know, blocking all outbound connections and allowing only to sanction resources and nothing else. And that's what serverless egress control supports which was in private preview yesterday.
We made it generally available on AWS and Azure. If you have been using serless egress control and you have some feedback, please reach out to us. Love to learn more about uh any additional requirements you may have. So in this example in this diagram I'm showing you you know all of these products can access sanctions storage but not to the personal storage and that can be done through UC governed storage bath with external locations and also with egress control.
Once you define the UC external locations, those locations are automatically included in the servers serverless egress control rules. So how does this server serverless egress control work? Basically in a single policy you're covering the hardbound connections for three surface areas. First as I mentioned UC locations you define the location external locations in UC and those locations are automatically included in serverless egress control.
On top of that you can enumerate other storage path. For instance, you may want your workload to access um private repo or specific public repo and those paths that you want to include in the serverless egress control rules. Second, you may want your your enrollment access Salesforce or other external systems. You have to include specific internet domains in the egress rules. That's how data bricks platform can allow you to access external systems.
And finally, we talked about crossworkspace interaction. By default, serverless egress controls blocks all crossworkspace interactions. If you have any use case that require crossworkspace interaction, please let us know. Um the main reason we are blocking by default is to prevent as I mentioned earlier workspace A is talking to workspace E and excfiltrate data through workspace B assuming that workspace B has got full internet access or access to unsanctioned uh storage destination.

24:12 Data protection and encryption

So if you haven't played with the serverless egress control policy, let me walk you through. It's a single policy that you define at the account level and then apply across workspaces. For instance, you know, you can create a default policy. The default policy is basically blocking all internet access for all new workspaces. And then you can say okay I want to allow access to specific storage path or storage destination or external system.
Then you select restricted access to specific destination. Then you list out allowing allowed domains as well as storage destination. Again you do not have to specifically add UC external location in egress control. We automatically take all those UC external locations and include them in the serverless egress control to simplify the management. Okay, so I talked about serverless egress control. What are the use cases?
Let me quickly walk through some of the use cases you can achieve with serverless egress control. First, you can start off with the zero internet access. No one gets access other than your users and workload access cloud storage paths which are defined in UC external locations. That's it. Right? Many customers do that. Then you may have a requirement to access specific private repo in a VPC or VNET. Then you open up access only to those private repo.
Then third, you may want to connect to external system. That's when you open up access to specific domain right Salesforce domain or any other domains that you want to have access. So you can achieve all these use cases with serless egress control. Basically with ingress control and egress control you are creating a parameter with full control at the edge helping you enforce the principle of lease privilege by default.
So let me quickly go through another scenario. Right? We talked about the parimeter boundary that you can establish. What if if your administrator storage administrator can access data directly right now exposing your data to infrastructure administrators and how do you prevent this right from happening? This is why we introduced multi key protection. So you can own your encryption and protect against insider threads.
So in this example what I'm showing is all data in the datab bricks platform is encrypted at trust by default with your key customer managed key. You own encryption root encryption key root not us. Your key pretty much protects everything in the datab bricks platform. Your data set code uh models everything that you own in the data bricks platform using your key. Then what we have done we created a key per catalog using the combination of customer manage key and data bricks manage key.
On top of that we also have key per object model table key volume key and that is encrypted with the catalog key and then finally we create ephemeral file key per data file and then encrypt that with the object key. File key is heal and stored in memory on trusted compute not persisted to disk right. So that way if you ever have to revoke access to the data bricks platform you own the key and you can revoke it. No data bricks process or insider data bricks internal users or anyone can access your data.
We are supporting this capability for default storage. What we what I mean by that is datab bricks managed storage. Um and if you want us to extend to your own storage to protect against insider threats, please let us know. We have been thinking about how we can extend this capability for bring your own storage or customer managed storage. Okay, how does this help you? As I mentioned, this provides defense in depth, right?
Um using multi key protection basically all access to your data must come through the front door right nobody can access your data directly right even if they access data any data right they can't get anything out of it right because it's all encrypted and the way this works is a user must have access to workspace right without that they can't even you know login on top of that we talked about strong authentication and access control.
That means users have to come from authorized location before they can access the workspace and log to the workspace. Second, your workspace must have access to the catalog. If you have not bind uh if you are not binding the catalog to the workspace, that workspace cannot access your data. Second user third user must have authorization to access schema tables right and finally the code must run on the trusted network and also only the trusted code has access to the encryption right so if you have bring your own code that code cannot even uh uh decrypt the data so all the encryption key is made available only to the trusted code right and that's how we protect end to end and even if your storage administrator got direct access to the cloud storage they can't decrypt the data okay so I have to go fast um restrict data access basically you know how do you give access only to authorized workspaces you can achieve this with uh two ways one using private link or stable identifier basically Datab bricks exposes workspace IP address stable IP address that you can configure in the cloud storage firewall or endpoint policies right if you're using AWS second you can establish a private connectivity from the production workspace to each resource cloud resource right and that way your dev workspace cannot access your production data and only your production workspace can access that data either through the stable identifier or through private link.

30:28 Restricting data access

So with that I'm going to give it to uh Philippo so that he can cover compliance and then if we have time we can walk you through the demo. Okay. All right folks. So we are six minutes to the end. So I was supposed to give this presentation at 12. So buckle up because they're going to speed up a little bit. Um so let's talk about compliance. So, SARS has walked you through how to secure your network, how to secure your workspace, your data bricks data and so on and so forth.

31:22 Compliance and security profiles

So, a lot of you may also have to deal with an additional step which is compliance. So, if you are processing regulated data, think of Fedra, PCI, HEIPA, you name it. So, let's see how um what we do to help you also on this side. So data bricks we are trying to make the data bricks uh sorry the uh compliance experience as simple as possible for you and with compliance experience I mean really how you set up your data bricks environment to support your compliance needs.
So for that let me get your focus on the one of the features here which is the most relevant is the compliant security profile. The compliant security profile is a security baseline that you apply to your workloads to your workspaces and basically brings you a lot of the um security features that are necessary to meet the applicable compliance controls. Think of like data and transit encryption, data rest encryption, FIPS encryption if you are under one of the FIPS standards and so on and so forth.
And hold on clicking access. So and enabling the complian secure profile is is as simple as flipping a toggle. You go on the account console under security and compliance. You can do this either at the workspace level. So on individual workspaces or you can set think of like a default policy so that all the new workspaces going to do this and you just have to flip a toggle. You select applicable compliance standard or standards that you need and we apply in the back everything that needs to be done all the applicable controls that needs to be applied.

32:49 Compliance roadmap and expansion

Okay. One caveat here. Don't over select because we are blocking features that are not compliant. So if you select all of them, you're going to get the most restrictive set. So only select what what you need because we are actively blocking features that have not gone through compliance certifications yet. Okay. So this is the most important slide. Uh so focus on this one. What are we doing this year for the compliance space?
So we're bringing serverless everywhere. with everywhere means all clouds AWS, Azure, Google Cloud, AWS GC cloud on all regions for all standards. We're doing the same also for model serving and all the mosaic AI features and then we're bringing the uh enhanced security and compliance add-on which is the uh add-on under which the compliant security profile is is made available. we're bringing to all clouds specifically the one that was the big missing one was Google cloud and lastly but not least we are bringing more and more compliance standards across all clouds so let me walk you through all these steps so for those of you have been with us on the serverless journey and the complian journey you know the uh has been a little tedious so we initially only had starting back in 2023 we had serverless for only a couple of our compliance standards on only two region globally.
So that if you were for example in Europe or in Asia outside of uh in Asia any Asia region you were out of luck. You could not use serverless because we did not have serverless support for compliance those region. Moving to 2024 we brought uh serverless to Azure as well with HIPPA in all regions. Uh we brought it to GCP for heap in all regions and we expanded more region on AWS but we are still not there. I mean we are still not done. uh this this year 2025 we expanded serverless DBR DBR stands for basically general compute jobs notebooks and delta life table all serverless so we brought it the heap of support for those on on GCP and I get the attention on the red box that's what we're going to f focus on this year we're bringing basically serverless SQL and serverless DBR on Azure for all standards on all region AWS of cloud We are about to launch the private preview of SQL serverless ons cloud.
It should open up in the next couple of weeks and then we're going to bring the rest of the serverless DBR in the next uh couple of months. And in AWS all region, all standards by Q4 remember our Q4 give or take I mean our Q4 goes from November to January uh 2026. Now going in the calendar year 2026, we're also going to bring serverless SQL and DBR for PCI in all region on GCP which is part of one of the announcement we do today.
I'm spoiled the bean a little bit for a few slide later. This month we should get we are waiting any day at this point to get the PCI certification for GCP classic architecture. So once we have that, we're going to expand the certification also for serverless and that's why you're seeing uh 2026 as a timeline because we just need to get the product certified going to model serving and openi a lot I know there is a lot of uh people in this room I I recognize a few faces they're waiting for these especially on the go cloud side uh but starting from Azure and AWS in Q2 so now Q2 for us ends in July We're bringing model 7 AI gateway for all standards and all region on AWS and Azure commercial.

36:41 Enhanced security and additions

We're also starting to bring model serving some of the feature model serving to AWS cloud in Q3 and we plan to complete this in Q4. So by January next year we plan to be done with all the model serving features. Following that we're also going to have vector search you I mean I'm not going to read all of these but just uh mind map Q2 for us ends in July. Q3 ends in October. Q4 ends in in January. Okay. So that you know when it's coming but basically what you're seeing here more and more momentum momentum building you get old serverless you get the model serving you get vector search and once we have these few components and this is really what I would like you to take away.
So serverless especially DTS SQL model serving and vector search are sort of the building blocks of all the other uh genai or mosaici features. So this year we have been really working hard to build these building blocks on all this environment on all region for all standards. So we expect and you can expect that once we have all the other we have this building block done all the other geni feature will start to roll down much faster and so we expect to speed up the delivery of them.
Okay let's go to the third step and enhance security and compliance on available to all customers. So it was a little bit of a whack-a-ole kind of game with the because for example on AWS commercial we only had it available for commit customer those that will sign a contract all the PGO customer were not allowed to process any regulated data we are removing the block in the next couple of weeks and we're also changing and I'm sure for the our AWS customer this is good news we are changing the pricing model of ESC we are going to workspace level upcharge instead of contract level upcharge so they're you only going to pay the upcharge for the enhanced security compliance on for those first phases where you actually use the features.
Um it also means again that you don't need to update your order form. If you even if you're a uh commit customer, you don't need to update your order form. You can just start using it whenever you want. We are building we are building actually as of yesterday we published a blog. We announced a public preview of the ESC add-on on uh GCP. is going to be available or it's already available for HEIPA as soon as we get PCI report back again.
It should happen any day this month. We're also going to extend it to offer PCI and then um AWS cloud we are basically going to make available not just enhance the C add-on but the entire WS cloud available for PGO customer via marketplace. Azure in this case is the wins the cake because they have done already all the work. So it's available for commit, it's available for PGO, it already has the new pricing model. So no big news there because we already done all the work there.
And now let's go to the more compliance offering. So AWS we recently uh announced a few new standard like the can proctor B and we are bringing few more standard this year. We are working on two standard for our German customers C5 and TAX. We're working on a new standard for our Japanese customers with ISMAP WS Golf Cloud. We a couple of months ago we got the IL5 Fedramp at Fedrum high sorry Fedramp high uh ATO and the Fed DoD IL5 ATO and so with that we are com we are done for now on AWS of plant term certification we we have a fairly strong portfolio there on Azure we are bringing a lot of new standards uh again uh CFI and TSAX and Fedram high we plan to expand our availability to Fedrum high to more customers towards the end of the year early next year.
Google cloud uh we are doing a lot of work there as you can see because we only had EHIPA we are about to launch PCI we are bringing C5 IRA IRA for Australian government UK cyber central plus uh ECCCC for the uh Kingdom of Saudi Arabia. So a lot of momentum building also on the compliance side for GCP. And lastly, one announcement I want to do uh is we actually just launched also the enterprise tier on GCP. And why is this related?
Because the enterprise tier you get all the security features that Sash talked about it. They're going to be available on the enterprise tier. And the enhanced security compliance add-on is also going to be available on the enterprise tier. So um a lot of the feature coming up uh public preview soon or already in public review. So that's another big point. And to wrap it up today, you sort of we walk you through how to harden your data bricks environment, how to ensure that you have the right trusted access, that you prevent data exfiltration, that you restrict a data access, and how you deal with compliance in the context of data bricks and how you support your compliance journey by applying all the uh necessary controls to your environment.

41:51 Conclusion and call to action

And with this uh call to action if you wanna uh obviously there is the survey to do uh a lot of more things you can learn about our security our trust center our compliance offering security offering you name it and I think at this point if you have any question we are happy to take them.

Learn more about the Databricks Data and AI platform.