Microsoft Purview Data Governance Reviews

We have got all kinds of things to include in it. Specifically, we are looking at the data classification piece and the data protection piece that goes into it. Those are the two immediate cases. We have got ECIF partners helping us with it, and Microsoft is heavily involved. These are the two initial ones, but as we continue to expand, we are going to bring more functionality under the purview of Purview. Those are the broader use cases right now, but the idea behind it is to simplify the landscape. 

The reason why we made the decision to go with E5 and Purview is that Microsoft's technology stack has now caught up with the rest of the industry. Our preference is to keep it all in one technology stack so that it makes things simpler to connect and maintain. Previously, we had a collection of a few different applications. We want to offset that purely from the complexity, cost, and technical debt standpoint, and we are invested with Microsoft. We like their technologies, and that is why we found the match. We ran the assessments, and there are still some things that are not quite there. We are hoping by the time our program gets to implement them, they are going to be ready. They are going to fulfill our requirements.

Purview delivers data protection across multi-cloud and multi-platform environments, including AWS and GCP, which is extremely important. We are primarily a Microsoft Azure house. We have taken that leap with them. We are a strategic framework partner, and we are proud of it. We are proud of the relationship, and we are growing within that framework. The footprint eventually has to mature to a multi-cloud capability. Anything that we do in the multi-cloud framework, if it cannot be addressed with the existing data protection toolset, it would be, at a minimum, frustrating. In the worst case, it would be a significant rebuild of our landscape. We would be taking a step back in time because of the fragmentation that we are doing today.

It is extremely important that Purview was built taking into account critical regulations from around the world. There are different PII regulations, and there are specific regulations that are applicable to the utility business. Different countries have different data residency requirements. Can Purview help with that? That is a little bit of a long shot when it comes to expectations, but all of those pieces would help us because otherwise, we would have to build it from the ground. That was an expectation that I shared with the Microsoft team, and they brought specialists to the table, but from an automation standpoint, we are still pretty far away from that preferred goal.

We use Purview for data loss protection, but it is too early to assess Purview data loss protection for remediating policy violations. We are very hopeful about how we are going to set this up because it all depends on how you set up the policies. There is a lot of learning. We are going to set up the initial typesets, and then we are going to build on them as we go along, but I believe that everything that we need is there.

Purview has not affected the visibility we have into our estate because we have not quite reached that design aspect. We have not gone to that level of detail because we are still tinkering with a few other third-party products for visibility across our estate. It is an insightful question, but we have not quite thought it through.

Purview has not yet saved us money and time. It has cost us money to subscribe, so it has not saved us. There is a business case behind it where we do believe there is an offset of the third-party products, but the execution is going to determine how much of that projection we can actually meet. That is one piece of it. From a time standpoint, it is a productivity play. As we get more conversant with the platform or as our folks get more conversant with the platform, I believe this is going to become a lot easier for us to work with than some of our other products. Time will tell, but I believe this can get us there. Currently, we are in that early phase of understanding it, getting the structure built around it, and scaling our skillsets up, and then we can start talking about how we squeeze this and get better from productivity and other standpoints.

Purview can connect to iOS, Mac, and Android devices, and data in other SaaS apps. Its connectivity to Android devices is not so important to us, but with all other devices, it is important. One of our biggest problems with Microsoft solutions is their closed-ended ecosystem approach not just with InfoSec solutions but also with some of the connectivity capabilities. It is very inspiring to hear them talk about fabric across the ecosystem boundaries. We hope to see more and more of that because if we are going to include what we have from Microsoft as our primary solution, it should replace the capabilities that are brought by other ecosystem-agnostic solutions.

It is pretty early, but the decision to go with this investment was largely driven by the simplification of our information security technology management stack. That is the primary objective. Once you simplify and you have a connected structure, it allows for faster adoption there. It also gives us additional capabilities as we go on using the technology that we are familiar with, and we do not have to depend on outside parties to come in and tell us how to do certain things. Obviously, as new features are rolled out, it is good to know and hear from Microsoft. In some cases, they are very helpful in getting them implemented. 

We have had a lot of issues since we moved to Unified Support. There have been work gaps there, and we believe they fixed them, but we need to make sure that they are going to be sustainable. It is to be seen.

In terms of features, our technical team would be able to speak about the areas of improvement better. In terms of additional features, that would again require a conversation with the technical team as we are thinking about what pieces and parts are missing. We have a feature set that we have shared with Microsoft, and that gets into a lot of detail. We did the analysis. We believe that we are on the road map for some of those feature sets.

Purview is a relatively newer offering. We upgraded to E5, and we are just starting to do the implementation. It has been about four months.

Stability-wise, it is there. The product is enterprise-grade, so definitely, there are no doubts in our mind about that. Its functionality and capability will keep improving as we go along. We are confident in the stability aspect.

Scalability should be fine. At least for our footprint, it should be fine. We are a 7,000-employee company, so it is not a huge footprint. If we are talking about mega giants, such as Saudi Aramco, or Procter and Gamble, that would be a different question.

We have had a lot of issues since we moved to Unified Support. It has largely been because of the amount of traffic that they have under Unified Support, and it almost feels like their back office is not necessarily trained very well to handle those kinds of calls. Instead of a high-tech solution offering, it is just something that people in the back office can hand off from one shift to another, so their transition points are not correct.

It is hard to find the right people at Microsoft to support the technologies that we have from them, but the account team has made a lot of effort. They have put a lot of effort and brought it to their attention. Kudos to them for trying to fix the problem, but it is still early to say if we are on what we call emergency support, or if this is a level of sustainable performance that they can bring, which is going to keep us happy. 

We were using other options. We had technology gaps. We had a fragmentation of visibility and things, but we were not able to get a full estate view of it. Those were all supposed to solve cancer and world hunger, but they did not, so we did not go into Purview with that mindset. However, what we are hoping for is that there would be incremental improvements that would get us enough visibility of real estate and help us solve the problems of the past.

I was not involved in its deployment. Our technical team handles that.

It is too early for that, but we are hopeful. We hope to see a landing point by the end of this year, and then start to ramp up on the value prop by the middle of next year.

The interesting part is how they are bundling the version into the E5 stack. If it was not for that inclusion, this would have been a difficult conversation for us, so kudos to Microsoft on that. Separating it out may become a problem for customer retention. It is definitely a good move on Microsoft's part to include it as part of any existing or any system upgrades for customers that were on E3. Is the cost good or bad? Any cost that is incurred is really about the value. Do we want to put a price on a breach? I hope not. That is where the cost comes in. The value comes in right there.

You get what you pay for most of the time, and that is just the reality in life. You can go out and buy six cheap items that do not work well together or you can invest with Microsoft in their stack, which allows us to keep everything working, as we would expect it to work, seamlessly and with as little ongoing investment. We have a very large partnership with Microsoft, and so from a cost standpoint, we are paying for it. We never like to pay for things, but we have to. We believe we are in a pretty fair spot with Microsoft on that.

The evaluation landed on the maturity scale that Microsoft had shown. We went through almost a year-long evaluation with them of our landscape, and during that stage, they went from multiple small snippets of PoCs, etcetera, to win the business and convince us more to say, "This is why we need to move there." It was a competitive analysis, but it was more time-based and maturity-based rather than Microsoft versus the rest of the world. Our intent was to move to Microsoft, but the question for us was—Was Microsoft ready?

To those evaluating this solution, I would advise making sure you go through a proper set of PoCs and give it adequate time. We gave it almost a year, and we still felt it was not enough time. Have a very clear definition of what your requirements, use cases, and expectations are, and truthfully check the boxes for yourself. It is not a comparison between Microsoft and other products. They all do the same thing differently. It is really a bottom-line comparison of whether it gets the job done and what is more important for you. Is the technology stack consolidation important, or having the best of the best for each of those capabilities is important? That is a differentiator for most companies. They have to get real clear in their heads.

I have not heard too many complaints. Given where we are, conservatively, I would rate Microsoft Purview a good solid six out of ten. It is not negative feedback, but it is just too early to say that it is going to check all the boxes for us. However, our initial impressions are great. As with every implementation, once the initial phase is over, we get into some of the details. We find gaps and some very positive things, but at the same time, we do not want to say it is going to work. There is a lot of learning that has to happen. How many gaps are going to remain still needs to be seen once we address the implementation across our landscape.

We are using Microsoft Purview for Azure Information Protection and DLP to create automatic labeling and policies for sensitive labels. We are also using Insider Risk Management, Communication Compliance, and Records Management for our client.

Microsoft Purview provides data protection across multi-cloud and multi-platform environments, which is essential. Some of our clients require these measures because their systems must be secure and their data must be protected from loss for auditing purposes. Therefore, the client is requesting that we enable all of these features for the system.

It is important that Microsoft Purview was built taking into account critical regulations from around the world.

The data loss protection helps remediate policy violations.

Data loss protection helps educate users on how to handle sensitive data.

It improved our visibility into our environment.

Microsoft Purview helps us show our compliance in real time.

Microsoft Purview helps reduce our time to action against threats. It takes some time for the initial configuration, but it detects as soon as the configuration is enabled.

Microsoft Purview integrations with non-Microsoft products have room for improvement.

The technical support has room for improvement.

I have been using Microsoft Purview for four months.

Microsoft Purview is generally stable, but some of our clients occasionally experience accessibility issues when connecting to the cloud.

Microsoft Purview is scalable.

From a technical support standpoint, I have raised many tickets to date. Within this format, I have raised more than fifteen tickets for various purposes. I feel that few technical team members have a good understanding of the problems we are trying to explain. The rest of them waste our time. Typically, they say they will get back to us after two or three days, but then they come back to the same place they left off. Only a few technical team members are knowledgeable about Microsoft Purview. We still have tickets that are open to this date.

Neutral

The price is reasonable because most of our clients already have an E3 license, which makes implementation easy. For other clients who do not have an E3 license, the cost is higher because they must purchase the package.

I would rate Microsoft Purview seven out of ten.

Maintenance is done by the vendor.

I recommend Microsoft Purview for organizations with an existing E3 license, rather than spending money on a third-party DLP.

We use it for the text of emails. We use it to keep track of groups as well. We also use it to go through the mailbox of a former employee to retrieve the mailbox for a new employee. We use it for e-discovery and content search in emails across our organization.

We use it internally for just a few use cases. I know there are a lot of connections between it and other Microsoft applications and multiple clouds, but we don't have those use cases currently.

We carry out implementations for customers on these particular solutions. For example, if we're selling a Microsoft 365 solution to them, we use it to secure their data, especially their emails through backup, and SharePoint.

It has improved our ability to retain data and retrieve the data that we need at a future date.

We are also able to see how sensitive data flows across the organization, so it has been very helpful in telling us where that data is originally from and where it is being sent to. We have the ability to track it and control and restrict it from going outside our organization. We've benefited from that a lot.

Purview also enables us to show compliance in real time. We can see what the requirements are and then we can apply them across the organization. That has been very helpful.

It has also helped us to stay updated and make sure that we are not out of compliance. It keeps us updated with any new policies that are required for organizations like ours. That's of great value to us.

Another advantage is that it has definitely reduced the time-to-action on insider threats, although we don't measure that at the moment. But from experience, we can tell how much it is saving us in investigations, compared to before we had the solution.

The most valuable feature is the information protection, the way we're able to retain emails.

Another aspect that is very important is that Purview has been built to take critical regulations from around the world into account. It gives us trust that all of the compliance requirements are being met and that we just have to take care of our data. We don't have to worry about whether the regulations are being met around the infrastructure and we can just focus on our data. It's very important to us to have that level of trust in our systems.

Also, Purview's data loss protection for remediating policy violations is very good. It gives you the opportunity to know your data and apply policies around it. If those policies are flouted, you can always track what's happening. You have options such as alerting the person who is committing that action, or you can take automatic action by blocking, for example, an email that is being sent externally. It's very useful.

I've been using it since as far back as when it was Security and Compliance Center, before there was a separation between compliance and security. That happened around 2019, so I've been using it since 2019.

The stability is great. Like every SaaS application, there are infrastructure issues, maybe once a year. Overall, it's good.

The scalability is also great.

The service level agreement is excellent and the support follow-up is also great. They have good knowledge.

Positive

In terms of ROI, my bosses take care of that calculation, but I know we are getting benefit and value from Purview.

The categorization within the licensing could be improved. There are a lot of solutions within Microsoft Purview. If the licensing could be a bit clearer and the solutions could be better categorized according to function and across multiple environments, that would be excellent. The licensing is very confusing.

The pricing, for the solutions and value being provided, is fair. But that ties back to what I said about the licensing. There are a lot of standalone solutions you can get, and there are different licensing options for them. Depending on what you need, you can have a cost-effective solution; you can figure out your cost and benefit. It's affordable.

We are still exploring whether Purview can help reduce the number of solutions that we have interacting with each other. There are a lot of solutions within Microsoft Purview, but we still have some data that is on-prem and we are still looking at how we can expand and connect to those areas. It's something that is in progress.

In terms of maintenance, it's a SaaS solution, so the applications are automatically updated. There's almost zero maintenance. We do have to take care of configuration and updating preferences. I am able to handle that myself.

My advice is to develop a clear use case and a roadmap, perhaps from a consultant if you don't have the time, or spend some time doing research on it, because there are a lot of great solutions within Microsoft Purview. You need to have a strategy for the way you combine the solutions together.

We use it for the creation of enterprise PSA, as well as for our enterprise data catalog and data governance.

This is a type of pilot project or proof of concept. Our organization wants to see how it works, how complex the maintenance side will be, and how effective and efficient it will be.

It enables us to show compliance in real-time. However, because it is a pilot project for us, we are not showing the information to other parties yet.

It has definitely helped us reduce our time to action on insider threats. Finding proper data is always challenging in a big organization and this is a really positive aspect of Purview.

The first thing that we were particularly interested in is data lineage. It makes it pretty easy to connect and scan data sources, and do any kind of additional steps like Synapse or SSIS processing.

Overall, I would laud its ease of use, intuitive interface, and easy navigation. It's a very user-friendly product that is easy to work with.

In addition, we considered the issue of multi-cloud and multi-platform environments when we were trying to identify the best tools that would serve all the requirements of our organization. Currently, we are not directly pulling data from AWS. We are working with Azure. But we have the potential in the future to consider such options. This feature is very valuable because we are planning to establish automated data-pulling from AWS.

And the solution's data connector platform for the ingestion of data from non-Microsoft data sources is very easy to use. I investigated what data sources it can work with. It's certainly easy to work with all Microsoft data sources like SQL Server, Synapse, and data lakes, but it also has great functionality working with Oracle. And of particular interest to us is the ability to pull data from Excel, CVS files, and other types of flat files.

Another particularly nice feature is its integration with other services. This is one of the biggest advantages of the solution. For example, if you need to store a key for database access, it's easy to integrate with key vault services.

And a feature that is very important to us is the fact that Purview was built taking into account critical regulations from around the world. Before we started working with Purview, we put great effort into evaluating its capabilities and functionality. We created a comparative matrix with other tools and this was one of the factors we included. We considered it a big positive for Purview.

The scanning of data sources can be scheduled to execute automatically. That is the only automation we are using within the solution.

One area for improvement is the detection of data types. This is really important. It has some of that functionality, but I consider it very limited. Maybe they can add some custom programming, or machine learning could be particularly useful for the detection of the nature of the data.

If it could tell us, for example, when a given type of data is a social security number, that would be helpful. Currently, we need to open it and determine what the format is. We would like to know if a given type of data is PII data.

I have been using Microsoft Purview for almost two years.

I found some defects, through my interaction with the solution, in the reporting system. Purview has its own reporting and I found a function that apparently is not working. There are some bugs in that section, but other than that, everything looks okay. It works well.

We haven't experimented with scaling it, but my perception is that it's very scalable.

We haven't had to contact Microsoft's tech support.

We didn't have a previous solution.

The setup was pretty straightforward. It took us about one week, but a lot of the dependencies are not directly related to Purview. We had to obtain a password and user and that takes some time.

Microsoft takes care of patching, so I haven't seen any need for maintenance by us. It's on the cloud and they take care of it. We don't need to worry about that part at all and that is one of the big advantages of a cloud system.

We did everything in-house. I had architecture and administrative support, but I did the actual work with Azure alone.

I'm handling the proof of concept work. No other organizations have access to it. We don't want people to start using something that is not really complete yet.

Because this is a proof of concept, we haven't seen direct cost savings, but we see it having a positive impact on development work, particularly for BI folks who are interested in self-service and building reports for themselves. This is a very good exploration tool.

Microsoft Purview is the best option I have encountered when it comes to price. Maybe some of my information is outdated, but Microsoft offered it so that you could use it almost without paying. This was a really nice aspect. 

I don't know how Microsoft's pricing stands today, but for us, it was very cheap and effective. We are still paying some money but it's not significant. 

They should look to keep the pricing moderate in the future.

We compared Purview with other solutions, but not on a practical level. We only compared it with the information we were able to find on the internet, including the documentation and the functionality, but we did not install or do anything with the other solutions.

For a large enterprise, it's very important to have tools like this. It's especially useful for IT people who are dealing with data science or who need to find or investigate data or find out what data an organization has. It's also useful for those who maintain a central data warehouse and for people who want self-servicing business intelligence.

At this point, Purview has not reduced the number of solutions we interact with. In the future, we will consider that option. At this point, it operates as a standalone for us, because it is a pilot project in our organization.

Microsoft Purview is not yet a leader in data cataloging or data governance, but I'm pretty sure it will be, given how the tools are evolving and the functionality it already has. At the same time, I'm certainly looking for some of its functionality to improve, including easier integration with Microsoft Power BI.

The main use case is DLP, for alerts and insider risk management.

It is very important for our organization because ours is a very data-heavy organization. We process a lot of data on a daily basis, and we need to check where the data is coming from, how it is being classified, where it is being sent, and whether it is being used by the intended user. We need all the security controls.

We have clarity and visibility at a granular level. We can check data at rest or in transit—where data is coming from and where it is going—on-premises as well as in cloud solutions. That's how it is helpful.

The attack surface has been reduced significantly. Earlier, we didn't have any visibility into it.Now, we review every log to know where data is coming from and where it is going, as well as who is handling it. And all our employees also know that if they are doing anything mischievous, someone is watching them.

In terms of time saved, we write a policy, get an alert, and work on it. It has reduced a lot of human intervention while checking all the logs. It gives us the log source that we can check directly.

The best part is that I can create classifications per my requirements. I use it to classify multiple platforms like AWS, GCP, Azure, and different file sharing systems.

I also like the auto-labeling and the encryption of data when it is being sent out of the organization.

We also need complete coverage for every device that is connecting in our environment, so it's important that Purview can connect to iOS, Mac, and Android devices.

We just started using Purview DLP for macOS endpoints. We deployed it and
we are fine-tuning the policies. The macOS support is a very important factor because most of the teams handle data. We need to check whether they are sending any source code and how they are handling the data. We need to know whether they are using a key management system to handle secrets.

The fact that Purview was built to account for regulations around the world is important for us. It has to keep updated regarding all regulations because our users are across the globe. If we don't know the regulation data, retention policies, and other policies regarding the data, we may not be in compliance with those policies, and our company will have to pay a hefty fine.

I have been using Microsoft Purview for about two years.

It is a stable product. The stability is an eight out of 10.

Support should be improved in the form of good documentation and video lessons where a person can check things out. There is a community, but it takes a lot of time if we want to get an answer to a question. There should be an easy-to-reach place where, if you're stuck, the support system is there.

Neutral

The deployment was straightforward. We got help from Microsoft support's FastTrack. They helped us deploy it.

As for maintenance, we have to update the policies.

Overall, the only problem is the support system, which is a bit costly. But the product is good.

Our process for potential policy violations is to first check whether something is a true positive or a false positive; we check the document that is being sent. We then check it from our team's side, the responder's side, and then we check it with the compliance team. We look at the policies that have been violated and also check the business use case where something is being sent outside the organization. It's a manual effort for one of our teams.

As for educating users on how to best handle sensitive data, that is done by our compliance team. They do awareness training for our end users and send them awareness emails as well as monthly connections where they give them awareness information about how to handle sensitive data.

We are only using Purview for DLP on the incident-response side and for data protection. So I'm not sure whether it has reduced the number of solutions in the stack we are using, but it is very useful for us.

And although I'm not involved with the compliance side, we can check the compliance dashboard to deal with compliance-related issues. We have a dedicated team that checks it.

The primary purpose is to catalog all the different data sources. The idea is to get insight into what is available and, more importantly, to document and better understand the data quickly and easily. You're not doing any manual work, you're just scanning sources, which means you can automate it. It automates the majority of the documenting process.

The most important benefit is its data documentation and the data catalog. It saves a lot of time compared to doing those things manually. Normally, when you want to describe your sources and get an overview of what is available, it takes a lot of time for data engineers and other people in the company to document the data. That whole issue is eliminated by using Purview.

Also, the fact that you can easily view your metadata helps with data exploration. A lot of the time, there are so many sources at a company that at some point, most people don't even know what is available anymore. A really key feature is that not just one person but lots of people can access it for the same price, to do data exploration. They can all see what is available and decide what they want to see in a company report, for example.

The beauty of Purview is that it's all about a central location where everyone goes. I wouldn't recommend creating multiple Purview instances, although you might have one for production and non-production. But, ideally, you would just have one Purview for your entire organization and then provide access to multiple people to make use of it.

On the documenting side, in particular, it saves a lot of time, and time is money, especially when you are dealing with people entering data and information into Excel. That can be replaced by Purview and that saves a lot of time. Purview also gives you information that you can act upon. Instead of finding out too late, you can act earlier, and save money in that sense.

What I like the most about Purview is the fact that you can really easily connect to data sources and retrieve the metadata in a batch manner. Instead of having to manually write down which tables and columns exist and then describe them, you can do that process in one go, by simply connecting to a source. That's a huge time-saver and a great benefit of Purview.

The solution takes into account critical data compliance regulations from around the world and that is one of the most important aspects of Purview. New laws are being enforced for data compliance and a lot of companies have a great interest in this feature of Purview. I think Microsoft is going to be focusing on that for the next couple of years to help organizations improve on data compliance.

In terms of reducing time-to-action, if you set up a clever rule that gets applied to your scan—it would just take some time to create that rule—in theory, whenever you are scanning your data you could identify something that is going on and act upon it. But I haven't seen that in practice yet.

The fact that Purview delivers data protection across multiple platforms, including AWS and GCP, is really important, but I feel the tool can mature further in that area. You can set up rules and scan your data and then you can figure out whether your data is secure and compliant, but feel that Microsoft could improve on this and add more features to the tool. I think they will do so over time. The solution has only been generally available since last year, so it's still quite early in terms of maturity. The multiple platforms feature is very important and there is potential there.

A bit of a downside is that although you can explore the data, that creates a great interest in data lineage or the data flow. How does it go from a source to a platform to a Power BI report, for example? It is possible, to some extent, to see that with Purview, but the lineage feature requires some manual work on the development side or more work from Microsoft to improve on it.

The data lineage is effective and useful when you are using all Microsoft products, but as soon as there's any complexity or you have a different tool in between, like Databricks for data transformations in your platform, for example, the lineage isn't going to be added in Purview because there is no connection to it. On the lineage side, a lot more can be done, but there is a lot of potential.

An additional feature I would like to see is in the following scenario. Suppose you have your sources scanned and you have all the tables listed in Purview. Right now, to update and label them, or to group them, would take a lot of time because you have to manually click on the assets and the tables that you have. But given that a database can have hundreds of tables, it would be helpful if you could update the assets in batch and, possibly, multi-select them. That would be a nice addition.

I have been involved with Microsoft Purview from the private preview stage, which was about two or three years. At that stage, it was only being shared with certain companies and nothing could be shared externally. In that phase, I got to share what I learned from the tool with Microsoft.

I haven't used it all the time since then, but more recently, I got to work with it for a few months so I got to see the latest update and changes that were made.

It is quite stable in terms of the scans running and not failing. It's not going to be slow or not function when you do an action inside of Purview. The stability is great.

It's really scalable, just like most things in Azure. You can add to it but it gets more expensive. You can add as many sources as you want, and the scanning of sources goes quite quickly, even for really big databases. The reason is that you're not copying any actual data, you're only getting the metadata, meaning a description of the tables and the schema, et cetera.

I haven't had to use Microsoft's technical support for Purview.

From my experience with other Microsoft Azure tools, the support is not bad, but it might take some time. Once you get someone working on it, an issue always gets resolved, but it can take a bit of time to get the right person involved to help you out.

For documenting data I have used Excel. I've seen huge Excel files with lots of data descriptions, and they took a lot of time to create. 

Also, on the data quality side of things, I have used an Azure data platform: an SQL database and a Power BI report. For example, if you're scanning data and you apply a rule to check if a column is empty so that you can classify it as "empty column," that would be a data quality rule. Instead of using Purview, I have used Azure.

It's very straightforward. There are not that many fields to fill in initially. Connecting sources, the first step, didn't take a long time. You really quickly get to see things, especially when it comes to Azure sources. It's all integrated so you can connect really easily. You just need to have authentication rights assigned. So connecting is quite fast.

The deployment is all-cloud. It's all Azure, which makes it really easy to deploy the tool really quickly. And if you have other data in the cloud, you can really easily connect to it.

The second part that takes a bit longer is defining the data, just like you would normally describe your tables and your columns and all your data definitions in Excel. In Purview, that also takes a bit of time. You have to find the way to describe it most easily. You can use the rules while scanning your data and automatically label or classify the data. But creating those rules takes a bit of time: How are you going to scan the data and what rules do you apply?

Getting the resources going just takes a day or two. But to connect to them and make things functionally available takes more time.

It's a one-man job. Even for connecting to resources, all you need is an admin who can grant you all the rights that you need for those sources and you can really easily scan them. The part where you need more people is on the business side because you need to describe, understand, and classify your data. That takes a lot more people because one person might know something about the customer database and a different person might know something about the finance database.

There is an investment of time involved, but once you set up those rules and you have the sources to scan, it automatically checks your data. It takes time to set it all up, but over a longer period of time, you will actually save time and see a return on investment. How fast that happens depends on your organization and how many data sources you have, as well as on how many people are using Purview and how efficiently.

You pay a minimum amount every month for the data map. You scan your sources and the metadata gets saved and then you pay for what is stored, which makes sense. However because there is a minimum amount, in the beginning, you might pay for more than you are using. That's something that some of my clients didn't like. That's why I say it's quite pricey; you're always paying a certain amount.

It would be nice if it went to entirely pay-per-use. For example, on Azure, when you have storage accounts, you pay for exactly how much you store. That would be nice to see in Purview as well. And while it's pay-per-use, you pay for features as well. For example, you pay for the cataloging part, including describing your data and adding labels and classifications. I would like to see a standard price and exact pay-per-use. 

I understand, in practice, that might not happen, but the pricing may be a bit overwhelming for some clients. They will say, "Hey, I'm already paying this much and now something else comes with another cost? Why is that?" It raises questions.

I'm working at a company that is a Microsoft partner, so it's all Microsoft-first.

We did do a quick analysis for a few other companies and there is some competition out there, but the other solutions are quite expensive. They are enterprise tools that are a bit more mature but the license costs $100,000 for some of them. Purview is pay-per-use and a lot of companies are interested in that. It's still quite expensive compared to most Azure components, but compared to the alternatives it costs less. That may be because it's not that advanced yet.

My advice is to involve people from the business side who can describe data and describe business terms. That's what is most important. Otherwise, it's just going to stay a technical implementation and it won't be used, which would be a huge waste. From the start, involve the people with a mandate who can actually start using it in the future.

Regarding its data connector platform for ingestion from non-Microsoft data sources, there are so many sources in the world that they have a ways to go there, but I do feel, especially in the last year, that the solution has grown a lot in that area. All the big, and most-used data sources, like Amazon, SAP, and many other sources, have been added, which is a great step. But if you work with sources that are more unique, the kind that are not used by many other companies, those are not available and you would have to write code in Purview for them. You can use the API that is available and you could insert metadata and lineage information into Purview, but that is a manual process. You would have to develop that for specific sources.

Purview's natively integrated compliance across Azure, Dynamics 365, and Office 365 is also quite important, but I haven't worked on that myself.

In my experience, Purview hasn't come far enough yet to help us reduce the number of solutions that interact with each other. We use Purview right next to all the other tools, which is okay. It takes a lot of time for a company to adapt to using Purview. You can scan data quite easily and figure out how to apply rules and classify and document your data, but you still need people to adapt and make use of it. I haven't really seen that last part very much in practice yet. It takes a bit of change management to get people to make use of it properly. As a result, it hasn't replaced tools yet for me.

Purview doesn't enable you to show compliance in real-time, but you can schedule how often you scan your sources. When the sources are scanned and added to Purview, they become visible and you can see if you're compliant or not, but that's not real-time. You can schedule scans daily, for example, but then you have daily data sets rather than real-time data.

Overall, the potential for this solution is really large. Data management is extremely important and Microsoft is investing very heavily in Purview. Right now, it's not quite there yet.

Our client was looking to do data governance and we decided to implement Microsoft Purview for them. The client did not have very specific requirements, because they had no idea what to do with data governance and they wanted someone who could kick-start things. We implemented the basic functionalities for them.

Our client was impressed because they now understand how much sensitive data they hold. They now know they have to assign someone who can work as a data steward, someone who will manage and protect the sensitive data to make sure that no one else can access it.

It has also helped our client save time when compared with doing data governance manually. It could be up to 80 percent faster because, if we had to do it manually, it would take a lot of time to create a script to scan all of the data in the data repository. With Purview, we can configure the connectors and just hit the button and it will do the rest.

Overall, Purview is quite good for helping you stay on top of compliance.

One of the best features is the classification rules, especially the scan rule sets. They are really useful, especially when we need to understand the current data the company has to ensure that all the problematic data can be put under someone's responsibility.

Also, although it is not automatic, managing the business glossary terms is valuable. If we have to work with other people who are also data governors, it's important to understand how the current data catalog is going to work with the business. We can do it manually to flag the business terms that we would like to handle.

It is also important that Purview delivers data protection across multi-cloud and multi-platform environments. Microsoft has built-in tools that can scan risky data that could be sensitive. It also provides connectors to other data platforms or clouds. These abilities are important for anyone who wants to see whether their organization has sensitive data, and how much.

In my understanding, because most of the connectors only scan databases or data lakes on multiple clouds, it is certainly not going to provide direct protection on other platforms, like iOS or macOS.

Also, Purview has no data ingestion capability. Of course, it can scan, but it won't import any data into Purview, just metadata. That is still important but it doesn't do data ingestion.

Another area for improvement is in managing the business glossary terms. If they could provide the same type of method that we use to configure the scan rule sets, that would be helpful. Currently, there is no option like this, so we have to do it manually. Automatic detection would be great.

I would also like to see third-party plug-ins. For example, there are several data quality or data management options on the market. Because Purview is not a 100 percent data governance solution, it would help if we could pick some of the good capabilities of other products. If we could plug Purview into the AI option from Ataccama, it would be enhanced immeasurably.

We implemented Microsoft Purview for a customer's company about two or three months ago.

It's stable. There were no weird glitches.

I think it's scalable, although Microsoft hasn't mentioned this explicitly. But it's a serverless solution, so it would scale. It just depends on how much data we need to scan.

We haven't had a chance to talk with Microsoft support because we haven't encountered any problematic situations.

Our client did not have a previous solution. They had no idea which one to go with. They just wished to have data governance and that's why we came up with Purview for them.

The initial deployment might seem complicated at first, but Microsoft has a guide with basic documentation on how to start and it's quite clear. Newcomers would need to understand the documentation first before they could implement this.

For example, for the resources in Azure, it might require the subscription owner to turn on some features. And in terms of the connectors, they would require an additional resource to store the data connection credentials called Key Vault. We had to implement all the resources to work along with Microsoft Purview.

It took about a week to get things up and running, but that was for the pilot solution. We did not have any very complex data to scan. We had to gather the information from the client about how much of the data they wished to scan, and when we got all the information, we started with the resources. 

We had three people involved in deploying it. One was responsible for most of the Azure connections and permissions. Another was the data governance operator who decided what to scan. The third was a data curator who made sure that all data was in the correct classifications.

It took about two weeks, after we implemented Purview, to realize the benefits of the most important features. The way that we implemented it, it was natively Microsoft-based, so there were not many other solutions to consolidate.

Compliance is not shown in real time because it might take some time to scan, but it depends on the amount of data involved. It's going to take some time to compile everything and show compliance.

Purview itself is on the cloud, but there is an on-premises database server that we need to connect with. Currently, there is no maintenance involved. It is done automatically.

The pricing is moderate. It's not too expensive, but it's not the most competitive.

In terms of additional costs, there is an option for advanced data lineage for lineage visibility with Power BI, but because our client did not have Power BI we didn't use this.

Although I haven't had a chance to work with Dynamics 365, I can see that Purview could be connected to that too, and I think it is important. And as far as I know, the classification rules built-in by Microsoft only apply to EU GDPR, as well as American and Canadian sensitive data protection. For all other regions, there are no options just yet.

If an organization wishes to do data governance that is not too advanced or sophisticated, Microsoft Purview could be the perfect fit for them, but they should, of course, do a PoC first.

We use the product to prevent the loss of personal information across Microsoft 365. 

You can set up automated dates to alert on internal data. 

I don't see any issues with the product's scalability. 

The tool's support is good and very responsive. The first and second lines of support need to improve. 

Microsoft Purview Data Loss Prevention is not cheap. 

We are heavy on the use of iOS. 

It is nice that the product delivers data protection across multiple cloud and platform environments. Azure is our primary cloud. 

We are happy with Microsoft Purview Data Loss Prevention's security and visibility. 

I rate it a five out of ten.