Kindly fill up the following to try out our sandbox experience. We will get back to you at the earliest.
Microsoft Purview vs Collibra for banks, insurers and healthcare: audit log retention, lineage as evidence, access control and cost, cited to vendor documentation and primary regulation.
Updated on
Choose Collibra if the thing you have to survive is an examination of process: who approved this definition, on what date, against which policy, and can you show me the trail. Choose Microsoft Purview if the thing you have to survive is a control assessment across a Microsoft estate, and your sensitive data mostly lives in Microsoft 365, Azure SQL and Fabric rather than in a warehouse somebody else runs.
That is the honest split, and almost every comparison of these two buries it under a feature grid that treats a catalog as the product. In a bank, an insurer or a hospital the catalog is not the product. The evidence is the product. The question that decides the purchase is what you can put in front of an examiner when they ask where a number came from, who could see it, who changed it and how long you kept the proof.
One note on sourcing before the detail. Every claim below about either product was read from that vendor own documentation on 6 September 2026, and the exact pages are listed at the end. Every regulatory requirement is quoted from the primary text, not from a summary of it. Where our own internal reference disagreed with Collibra documentation, the documentation won, and the article says so.
Read the table if you read nothing else. It is written as a decision rule rather than a verdict, because the correct answer changes with where your regulated data actually sits.
| Your situation | The fit | Why |
|---|---|---|
| Regulated data sits in a warehouse and a lake, you need catalog, lineage, quality and monitoring under one subscription, and you have a small team rather than a governance office | Decube | Catalog, lineage, quality and observability are all first party, deployment is measured in weeks without a professional services engagement, and list pricing is published on the site so the business case can be written before the first vendor call. |
| You must evidence that a named person approved a named change on a named date, and you already fund a governance team to run the process | Collibra | A Collibra workflow is documented as a defined sequence of activities, tasks and decisions that automate and enforce data governance policies, and the platform keeps a full change history of who did what and when. |
| Your regulated content is Microsoft 365 and Azure, and your compliance function needs control assessments mapped to named regulations | Microsoft Purview | Compliance Manager ships more than 360 regulatory templates and splits every control into Microsoft managed, customer managed and shared. Nothing else in this comparison does that. |
| You need six years of retrievable activity evidence for HIPAA | Neither, without pricing it first | Purview Audit retains records for 180 days by default and needs a per user add on license for ten year retention that does not apply retroactively. Collibra keeps asset history in its own database, which is a different artifact from a tenant wide activity log. |
| You have a hard data residency or self hosted mandate for metadata | Resolve this before the demo | Collibra Data Lineage is documented as a cloud only product. Microsoft Purview data quality requires the Purview account and the data source to sit in the same Azure region. |
Regulators do not ask which catalog you bought. They ask four things, in four different vocabularies, and every one of them turns into a tooling requirement. Getting these written down before the demo is the single highest value hour in a governance procurement, because it converts a feature argument into a checklist.
This is the record keeping question, and it is the one that most directly describes a data catalog. Article 30(1) of the General Data Protection Regulation requires a controller to maintain a record of processing activities containing the purposes of the processing, a description of the categories of data subjects and of personal data, the categories of recipients to whom the data have been or will be disclosed, the envisaged time limits for erasure where possible, and a general description of the technical and organizational security measures. Article 30(4) settles who it is for.
The controller or the processor and, where applicable, the controller’s or the processor’s representative, shall make the record available to the supervisory authority on request. (Regulation (EU) 2016/679, Article 30(4))
A bank hears the same requirement in a different accent. BCBS 239, the Basel Committee principles for effective risk data aggregation and risk reporting published in January 2013, says at paragraph 33 that a bank should establish integrated data taxonomies and architecture across the banking group, which includes information on the characteristics of the data, and should use single identifiers or unified naming conventions for legal entities, counterparties, customers and accounts. Paragraph 37 is blunter still: as a precondition, a bank should have a dictionary of the concepts used, so that data is defined consistently across the organization. That is a business glossary written into supervisory expectation.
This is the lineage question, and in a regulated setting it is an evidence question rather than a debugging convenience. Paragraph 39 of the Basel Committee principles for effective risk data aggregation and risk reporting says supervisors expect banks to document and explain all of their risk data aggregation processes, whether automated or manual, including an explanation of the appropriateness of any manual workarounds and a description of how critical they are to accuracy. Paragraph 53 goes further and asks for something most quality tools do not produce.
Automated and manual edit and reasonableness checks, including an inventory of the validation rules that are applied to quantitative information. The inventory should include explanations of the conventions used to describe any mathematical or logical relationships that should be verified through these validations or checks. (Basel Committee on Banking Supervision, Principles for effective risk data aggregation and risk reporting, January 2013, paragraph 53(b))
An inventory of validation rules with the conventions explained is a document rather than a dashboard, and it has to be reproducible on request. The same logic runs under GDPR Article 15(1)(c) and Article 19, which entitle an individual to know the recipients of their data and require you to pass a rectification or an erasure on to each of them. If you want the underlying concepts laid out properly before you evaluate anyone, we have written up what data lineage actually is and how it is captured.
This is the access control and audit question, and HIPAA states it more plainly than any other regime in this article. 45 CFR 164.312(a)(1) requires technical policies and procedures that allow access only to those persons or software programs granted access rights, and 164.308(a)(1)(ii)(D) requires procedures to regularly review records of information system activity such as audit logs, access reports and security incident tracking reports. The standard that decides your tooling is one sentence long.
Standard: Audit controls. Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information. (45 CFR 164.312(b))
GDPR reaches the same place through Article 5(2), which makes the controller responsible for being able to demonstrate compliance with the six principles in Article 5(1), and through Article 32(1)(d), which requires a process for regularly testing, assessing and evaluating the effectiveness of the technical and organizational measures. Demonstrating anything means having a record of it.
This is the retention question and it is the one that quietly decides this comparison. HIPAA sets the clock twice. The documentation requirement is explicit.
Time limit (Required). Retain the documentation required by paragraph (b)(1) of this section for 6 years from the date of its creation or the date when it last was in effect, whichever is later. (45 CFR 164.316(b)(2)(i))
The second clock is the accounting of disclosures. 45 CFR 164.528(a)(1) gives an individual the right to receive an accounting of disclosures of protected health information made in the six years prior to the date the accounting is requested, and 164.528(b)(2) says that accounting must carry, for each disclosure, the date, the name of the recipient and where known their address, a brief description of the information disclosed, and a brief statement of the purpose. You can read the accounting of disclosures rule in full. A tool that keeps six months of activity records cannot answer that request, and no amount of catalog quality makes up for it.
Penalties are worth understanding structurally rather than numerically. 45 CFR 160.404 sets four tiers, running from a violation the covered entity did not know about and could not reasonably have known about, through reasonable cause, through willful neglect corrected within thirty days, to willful neglect not corrected. 45 CFR 160.404(a) states that the amounts are adjusted annually in line with federal inflation adjustment legislation and published at 45 CFR part 102, which is why no article should quote you a dollar figure without naming the year it was published. What matters for tooling is the tier: the difference between reasonable cause and willful neglect is very often whether you can show you were monitoring at all.
Purview is not one product. Microsoft documentation describes it as a set of solutions grouped into data security, data governance and data compliance. Data governance is Microsoft Purview Data Map and Microsoft Purview Unified Catalog. Data compliance is a different group that includes Microsoft Purview Audit, Compliance Manager, Data Lifecycle Management, eDiscovery and Records Management. Half the reason buyers talk past each other about Purview is that they are describing different halves of it.
This is the part of Purview that a regulated buyer should take seriously, and it has no equivalent anywhere else in this comparison. Microsoft documentation describes Compliance Manager as a solution that helps you automatically assess and manage compliance across a multicloud environment, and states that it provides over 360 regulatory templates for creating assessments, with the ability to build custom regulation templates. It tracks three kinds of control: Microsoft managed controls, which Microsoft implements on your behalf, your controls, which your organization implements, and shared controls. Improvement actions can be assigned to named people, and the documentation says you can store evidence, notes and status updates inside the improvement action itself.
That is a real answer to a real audit workflow, and Collibra does not ship it. If your compliance function currently tracks control evidence in a spreadsheet, Compliance Manager is a considerable upgrade. The caveat is documented on the same page: available assessments depend on your licensing agreement, so the template you need may not be in the tier you have. Check the specific regulation you are examined against before you build the business case on this.
Microsoft documentation is unusually clear here, which is to its credit, and the numbers are the ones a healthcare or financial services buyer has to reconcile against the six year clocks above. Audit Standard is enabled by default and retains records for 180 days, which Microsoft describes as being able to search for activities that occurred within the past six months. The default was 90 days before 17 October 2023 and logs generated before that date are still retained for 90 days.
Audit Premium adds retention policies and longer retention. Microsoft Entra ID, Exchange, OneDrive and SharePoint audit records are retained for one year by default, and records for all other activities are retained for 180 days unless a retention policy extends them. Ten year retention is available, and this is where the detail matters: Microsoft documentation states that a user must be assigned a ten year audit log retention add on license to retain their audit records for ten years, and that the policy is not retroactive and cannot retain audit logs generated before the policy was created. There is one more line worth reading twice. Audit records generated by non user entities, meaning service principal actions, system events and application activities, are retained for a fixed period of one year, that retention period is not configurable, and custom retention policies do not apply to them.
Read that against 45 CFR 164.316(b)(2)(i) and 164.528(a)(1) and the procurement question writes itself. If your evidence requirement is six years and your service account activity is capped at one year with no configuration option, you need a plan for exporting to somewhere else. Microsoft names the route: the Office 365 Management Activity API, which the documentation says lets organizations retain auditing data for longer periods than the default 180 days and import it into a security information and event management system. That is a sound answer. It is also a second system, a second cost and a second thing to evidence.
Data Lifecycle Management is the Purview solution that most sounds like it answers a records retention obligation, and for Microsoft 365 content it does. The documented list of locations a retention policy can be applied to is Exchange mailboxes, SharePoint classic and communication sites, OneDrive accounts, Microsoft 365 group mailboxes and sites, Skype for Business, Exchange public folders, Teams channel messages, Teams chats, Teams private channel messages, Teams call logs, Microsoft Copilot experiences, enterprise AI apps, other AI apps, and Viva Engage community and user messages.
Every entry on that list is a collaboration surface. Not one of them is a database. If your regulated records live in Snowflake, Teradata, Db2 or an on premise SQL Server, a Purview retention policy does not govern them. Data Map will scan them and Unified Catalog will govern the metadata about them, which is genuinely useful, but it is a different capability from retaining or disposing of the records themselves. Be precise about which one your auditor is asking for.
Purview markets multicloud coverage and it is real, but it is uneven, and the unevenness lands hardest on exactly the systems a bank or an insurer runs. The Data Map supported sources documentation lists, per source, whether classifications can be applied automatically, whether sensitivity labels can be applied, whether policies can be applied and whether lineage is available. Reading that table for a regulated estate is a sobering exercise.
| Source in the documented table | Automatic classification | Lineage |
|---|---|---|
| Snowflake | Yes | Yes, plus pipeline lineage where the dataset is a source or sink in Data Factory or a Synapse pipeline |
| Oracle | Yes | Yes, on the same pipeline qualified basis |
| Teradata | Yes | Yes, on the same pipeline qualified basis |
| Amazon Redshift | No | No |
| SAP HANA | No | No |
| SAP Business Warehouse | No | No |
| Db2 | No | Yes |
| Amazon S3 | Yes | Limited |
| Tableau | No | No |
| Qlik Sense | No | No |
| Salesforce | No | No |
Automatic classification is the column that matters for a privacy examination, because it is how you find where personal data actually is rather than where someone said it was. A no in that column means manual work or another tool. If your customer data warehouse is on Redshift, or your risk reporting runs through SAP Business Warehouse, or your regulated reporting surface is Tableau, Purview is not going to classify it for you, and that is a fact you can verify in Microsoft own table rather than argue about in a demo.
Data quality in Unified Catalog is more capable than its reputation. Microsoft documents out of the box rules covering six data quality dimensions, which it names as completeness, consistency, conformity, accuracy, freshness and uniqueness, along with custom rule creation, rules generated by AI, column level profiling with distribution, minimum, maximum, standard deviation, uniqueness, completeness and duplicate measures, scheduled scans, alerts to data owners and stewards, and quality scores rolled up from column to asset to data product to governance domain.
The limits are documented on the same page and they are the kind that only bite after procurement. Data quality scans run only with managed identity as the authentication option. The Purview account and the data source have to be in the same Azure region. A maximum of 200 data quality rules can be applied per data asset in a scan. Virtual network support is not yet available for Google BigQuery. Data quality services run on Apache Spark 3.5 and Delta Lake 3.2.1, which is worth knowing if you have opinions about runtime versions in a regulated change process.
On lineage, the fullest description Microsoft publishes sits on the page for the classic Data Catalog, which is worth knowing when you are reading it against the newer Unified Catalog experience. It describes capturing lineage at entity level as a graph of sources, process and targets, and at column or attribute level identifying which source attributes create or derive target attributes, with the explicit caveat that granularity can vary based on the data systems supported. Process execution status is captured to support root cause analysis. The honest summary is that Purview lineage is strongest where the pipeline is a Microsoft pipeline, which the source table above makes plain: a large share of the lineage entries are qualified by whether the dataset is used as a source or sink in Data Factory or a Synapse pipeline.
This is the part that catches finance teams out, because Purview inside a Microsoft estate feels free until it is not. Microsoft documents two consumption meters for data governance. The first counts the number of unique governed assets per day, where a governed asset is a data asset attached to a governance concept such as a data product, a critical data element, a glossary term or a quality rule. Assets collected in Data Map but not linked to a governance concept do not count. The second meter is the data governance processing unit, which Microsoft defines as a fully managed compute unit providing 60 minutes of compute time, available in Basic, Standard and Advanced performance options, consumed whenever you run data quality and health management jobs.
The consequence is that your governance bill scales with governance adoption. Every additional table somebody attaches to a data product, and every quality rule somebody schedules, moves the meter. That is a defensible model and Microsoft publishes a calculator for it, but it is a very different budgeting conversation from a seat based subscription, and it is a hard one to take to a committee that wants a number for three years. Note also that the pay as you go model requires an Azure subscription in the same tenant and an Azure resource group, and that it took effect for Purview on 6 January 2025.
Collibra is the incumbent in this comparison for a reason, and the reason is process. It is worth being specific about what that means, because governance is the word every vendor in this market uses for something different.
Collibra documentation defines a workflow as a defined sequence of activities, tasks and decisions that automate and enforce data governance policies and procedures. Users interact with it through tasks, which are specific actions assigned to one or more users, and forms, which are dialogs where a person supplies information or makes a decision, often prepopulated from the platform. Approving new data definitions or changes to existing ones is named as a use case, and the Workflow Designer is documented on the Collibra developer portal.
Automate and enforce is the operative phrase. A tagging policy tells you what should have happened. A workflow stops the change until the named approver has approved it, and leaves a record that they did. When an examiner asks how you know a critical data element definition was not changed without review, that distinction is the whole answer. Nothing else in this comparison, including Decube, is as deep on that single axis, and pretending otherwise would not survive a demo.
For all resources in the system, including communities, domains, assets, attributes, comments, user information and the meta model, Collibra stores the full history in the database, so you can consult who made each change, when the change was made and what was done. The documented history covers creating, editing and deleting resources, moving assets to a different domain, adding, editing and removing characteristics, changes to asset status, accepting or rejecting a data classification suggestion, social features such as comments, tags and ratings, workflows, and creating, editing and deleting responsibilities. Changes are logged against the affected asset, its parent domain, all parent communities and the user who made them.
That is close to what an auditor pictures when they ask for an audit trail on a governance system. Two caveats, both from Collibra own documentation. The history does not show changes to inherited responsibilities, which matters if your access model leans on inheritance rather than direct assignment. And some actions do not change the last modification date of an asset, so a report built on modification dates alone will undercount activity. Neither is a defect. Both are things to ask about in writing.
Collibra states plainly that Collibra Data Lineage is a cloud only product that maps the entire data lifecycle, and describes technical lineage as a detailed graph providing complete end to end lineage that visualizes the journey of data objects, including temporary tables and columns, in external data sources, including all source code and data transformation details. That is a strong description and it is the level of detail a model risk or a regulatory reporting team wants.
Two current facts that a proposal written even a year ago will get wrong. First, the CLI lineage harvester reached its end of life on 31 July 2026. Collibra documentation now says new versions are no longer released and recommends creating technical lineage via Edge. If you are reading a Collibra architecture diagram, a statement of work or a proof of concept plan that still assumes the harvester, the lineage path in it is out of date and the timeline attached to it probably is too.
Second, a correction to a claim that circulates widely, including in our own earlier internal notes. Collibra self hosted is not without lineage. Collibra Platform Self-Hosted documentation states that it supports many data sources and metadata sources, including JDBC data sources, ETL tools and BI tools, for which you can create a technical lineage, and the list runs to more than twenty JDBC databases plus ETL tools including Apache Airflow, AWS Glue, Azure Data Factory, dbt, Fivetran, IBM InfoSphere DataStage, Informatica and SQL Server Integration Services, and BI tools including Looker, MicroStrategy, Power BI, Qlik and Tableau. The accurate, narrower and checkable statement is the one Collibra itself makes: the Collibra Data Lineage product is cloud only.
Collibra Data Quality and Observability grew out of an acquisition and it is administered as its own component. The administration documentation includes a page for viewing and managing your Data Quality and Observability license information, including the license key, the license name, the expiration date, and whether the license is currently active or inactive. A component with its own key and its own expiration date is bought, renewed and can lapse on its own schedule. Price it separately from the catalog and governance platform, and put the renewal date in the same calendar as your examination cycle.
Neither Microsoft nor Collibra publishes list pricing for these products, so any specific total you read for either is somebody estimate. Our own comparison pages put Collibra at 3 to 9 months to deploy and up to 12 months to full value, assuming a dedicated governance team and professional services. Those are Decube figures and we are naming them as ours rather than presenting them as independent research.
What is documented rather than estimated is the shape of the work, and it points the same way. Edge has to be set up for lineage. The quality component is administered separately and licensed separately. Workflows have to be modeled by someone who can model a business process. None of that is a criticism of the product. It is the cost of a system that can enforce a process, and it is why Collibra buyers who succeed already have a governance function before they sign, rather than expecting the tool to create one.
The table lists Decube first because this is our site. Every Microsoft and Collibra cell is traceable to a documentation page in the sources list, including the rows where we are not the strongest option.
| What the auditor asks for | Decube | Microsoft Purview | Collibra |
|---|---|---|---|
| A record of what you hold and where it goes | Unified catalog with business glossary, custom attributes, and verified and deprecated tags | Data Map inventory plus Unified Catalog governance domains, data products, glossary terms and critical data elements | Mature enterprise catalog with a business glossary and a stewardship model |
| Column level lineage you can put in front of an examiner | First party, cross system, with lineage changes passing through a structured approval flow | Entity and column level, with granularity varying by source and much of it qualified by Data Factory or Synapse pipeline use | Table and column level with source code and transformation detail, but the lineage product is cloud only and the CLI harvester ended on 31 July 2026 |
| Proof that a named person approved a named change | Approval workflows on governance changes, and approval gated changes on the lineage layer itself | Improvement actions can be assigned and evidence stored inside Compliance Manager | Workflow engine that automates and enforces policy as tasks, decisions and approvals, plus a full change history of who did what and when |
| An inventory of the quality rules applied to reported numbers | 12 test types with a no code builder and custom SQL, plus dynamic thresholding | Out of the box rules across six dimensions plus custom and AI generated rules, capped at 200 rules per data asset per scan | Its own quality and observability component, licensed separately with its own key and expiry |
| Activity evidence retained for six years | Audit logs are listed in the Enterprise tier on the published pricing page | 180 days by default, one year for four Microsoft workloads on the premium tier, ten years only with a per user add on license that is not retroactive | Full change history stored in the platform database |
| Quality and monitoring included in the core subscription | Yes | No | No |
| List pricing published on the vendor site | Yes | No | No |
Regulated buyers usually discover the deployment constraints last, when they are the ones that should be resolved first. Three are documented and checkable today.
Collibra Data Lineage is a cloud only product. If your policy says metadata about regulated systems cannot leave your own infrastructure, that is a conversation to have with Collibra before the technical evaluation, not after. Collibra Platform Self-Hosted does support technical lineage for a long list of sources, so the answer is not simply no, but the boundary is real and it is written down.
Microsoft Purview data quality requires the Purview account and the data sources to be in the same Azure region, and Microsoft documentation states that the capability is supported only when accounts and data sources are in supported Purview regions. Data quality metadata and profiling summaries are stored by a Microsoft managed storage account in the same region as the data source, and a customer managed encryption key requires a separate process. For an organization operating under a regulator with a data localization rule, that is a design constraint rather than a setting.
And a practical one. Ask both vendors, in writing, which of their capabilities are generally available in your region rather than in the product tour. Purview capabilities roll out by region and Microsoft publishes a regional availability schedule for Unified Catalog. A capability that is not in your region on the day you sign is not a capability you have bought.
If you already fund a governance office and your problem is process enforcement, buy Collibra. If your regulated content lives in Microsoft 365 and your compliance team needs control assessments, buy Purview and budget the export path for your audit logs. Those are genuine answers and the rest of this section is not for you.
The shape a lot of regulated data teams are actually in is different. They own a warehouse and a lake rather than a collaboration estate. They have four or six people rather than a governance function. They need a catalog people will use, lineage they can hand to an examiner, tests that catch a bad value before it reaches a regulatory return, and monitoring that tells them when a table did not land. They need all four working together, and they cannot spend a year standing up a workflow program before any of it produces evidence.
That is the gap Decube was built for. Catalog, lineage, quality and observability are all first party on one platform, so a failed freshness check, the column it affects and the downstream report that depends on it sit in the same graph rather than in three tools passing alerts between them. Quality testing covers 12 test types with both a no code builder and custom SQL, and thresholds adjust dynamically rather than sitting at a number somebody picked in the first week. Lineage is column level and cross system, and lineage changes pass through a structured approval flow, which puts the governance control on the lineage layer itself. You can see how that is put together on the Decube data lineage page.
On the governance side the controls are the ones a regulated buyer lists: classification policies drive tagging, personal data is classified automatically, access is role based with group management, and changes pass through approval workflows. Those are set out on the Decube data governance page. Data contracts between producers and consumers are a first class feature, enforced with SQL based tests, which is the mechanism for stopping a schema change upstream from quietly breaking a regulatory report downstream.
The security posture is published rather than described in a call. The Decube security page states SOC 2 Type II certification and ISO 27001, describes the platform as GDPR compliant and HIPAA compliant, and says data is encrypted with TLS in motion and AES-256 at rest. It also makes an architectural claim worth checking against your own policy: Decube queries your sources and receives only metadata, so your data does not leave your environment, with only aggregate statistics held in anonymized storage. Deployment is offered as SaaS, single tenant or on premise, metadata location is configurable, and the page states that regular independent audits and penetration testing are carried out.
One more thing that matters more in this market than vendors usually admit. Decube is built for regulated financial services globally, and the regulators that shape our roadmap include OJK in Indonesia, APRA in Australia, MAS in Singapore and the NAIC framework for United States insurance. If you are examined by one of those, a platform that has already met the expectation is a shorter conversation than a platform that has only met the European and American ones.
The commercial difference is the one you can verify in a browser right now. Decube publishes its pricing: Starter at 175 US dollars per user per month, from 21,000 US dollars a year with a minimum of 10 users, and Growth at 225 US dollars per user per month, from 54,000 US dollars a year with a minimum of 20 users, with Enterprise quoted for larger teams and carrying unlimited data sources, private cloud deployment, and a service level agreement with audit logs. Additional monitors, additional data sources and single tenant hosting are listed as priced add ons rather than buried in a quotation. Deployment is a software as a service setup measured in weeks and does not assume a professional services engagement.
If you want the direct comparison rather than this three way view, the Collibra and Decube comparison page runs the same rows against Collibra alone. And to be straight about where we do not win: Collibra is the stronger product for enforced governance process, and this article has said so twice already because it is true.
Five questions settle this faster than another round of demos, and every one of them can be answered from documentation before you book a call.
Whichever way you go, take the four questions into the vendor call rather than a feature grid. Every claim in this article came from a page the vendor publishes or a regulation text you can read yourself, and both are still there tomorrow when the demo is over.
It depends on which auditor question you have to answer. Collibra is the stronger product for enforced governance process: its documentation defines a workflow as a defined sequence of activities, tasks and decisions that automate and enforce data governance policies, and the platform stores a full history of who made each change, when it was made and what was done. Microsoft Purview is the stronger product for control assessment across a Microsoft estate, because Compliance Manager ships more than 360 regulatory templates and splits every control into Microsoft managed, customer managed and shared. Choose Collibra when you must evidence an approval trail. Choose Purview when your regulated content is Microsoft 365 and Azure and your compliance function needs assessments.
Microsoft documents 180 days of retention for Purview Audit Standard, which was 90 days for logs generated before 17 October 2023. Audit Premium retains Microsoft Entra ID, Exchange, OneDrive and SharePoint audit records for one year by default and 180 days for everything else unless a retention policy extends it. Ten year retention requires a per user add on license, and Microsoft states the policy is not retroactive and cannot retain logs generated before it was created. Audit records generated by non user entities such as service principals, system events and application activities are retained for a fixed period of one year, which is not configurable and which custom retention policies do not apply to.
Not from the default audit configuration. 45 CFR 164.316(b)(2)(i) requires required documentation to be retained for six years from creation or from the date it was last in effect, whichever is later, and 45 CFR 164.528(a)(1) gives an individual the right to an accounting of disclosures covering the six years before the request. Purview Audit Standard retains records for 180 days and Audit Premium retains four Microsoft workloads for one year. Reaching six years means either the ten year audit log retention add on license per user, which is not retroactive, or exporting audit data through the Office 365 Management Activity API into your own retention platform. Both are valid answers and both need to be costed before purchase.
No. The documented locations a Microsoft Purview retention policy can be applied to are Exchange mailboxes, SharePoint classic and communication sites, OneDrive accounts, Microsoft 365 group mailboxes and sites, Skype for Business, Exchange public folders, Teams channel messages, chats, private channel messages and call logs, Microsoft Copilot experiences, enterprise and other AI apps, and Viva Engage messages. A warehouse such as Snowflake, Teradata or Db2 can be scanned by Microsoft Purview Data Map and governed as metadata in Unified Catalog, but that is a different capability from retaining or disposing of the records themselves.
Collibra states that Collibra Data Lineage is a cloud only product. That is narrower than the claim that self hosted Collibra has no lineage, which is not accurate: Collibra Platform Self-Hosted documentation states that it supports many data sources and metadata sources, including JDBC data sources, ETL tools and BI tools, for which you can create a technical lineage, listing more than twenty JDBC databases along with ETL tools such as Apache Airflow, AWS Glue, Azure Data Factory, dbt, Fivetran and Informatica, and BI tools including Looker, MicroStrategy, Power BI, Qlik and Tableau. If you have a self hosted mandate, put the question to Collibra in writing before the technical evaluation.
No. Collibra documentation states that the CLI lineage harvester reached its end of life on 31 July 2026, that new versions are no longer released, and that Collibra recommends creating technical lineage via Edge. If you are reviewing a Collibra proposal, architecture diagram or proof of concept plan written before that date, check whether it still assumes the harvester, because the lineage path in it is out of date and so is any timeline built on it.
Three things that map directly onto tooling. Paragraph 33 asks a bank to establish integrated data taxonomies and architecture across the banking group, including information on the characteristics of the data and single identifiers or unified naming conventions for legal entities, counterparties, customers and accounts. Paragraph 37 says that as a precondition a bank should have a dictionary of the concepts used so that data is defined consistently. Paragraph 53(b) asks for automated and manual edit and reasonableness checks including an inventory of the validation rules applied to quantitative information, with explanations of the conventions used. In practice that is a catalog, a business glossary and a documented, exportable inventory of quality rules.
The alternative worth looking at is a platform where catalog, lineage, quality and observability are all first party, so there is no second purchase and no integration between tools that each hold half the evidence. Decube is built that way: 12 quality test types with a no code builder and custom SQL, dynamic thresholding, freshness, volume and schema change monitoring, column level lineage with a structured approval flow on lineage changes, automatic classification of personal data, role based access with approval workflows, and data contracts between producers and consumers. It publishes list pricing at 175 US dollars per user per month for Starter and 225 for Growth, deploys in weeks without a professional services engagement, and its security page states SOC 2 Type II certification, ISO 27001, TLS in motion and AES-256 at rest, with SaaS, single tenant and on premise deployment options for residency requirements.
First step to AI Readiness
Table of Contents
Sneak peek from the data world.
Bring lineage, quality, governance, and AI together in one platform—so your teams and AI agents can act with confidence.
_For%20light%20backgrounds.svg)
.svg){kind=small}
.webp)