Data catalog for healthcare

Why a data catalog for healthcare starts with knowing where PHI sits

For most healthcare organizations, the first job of a data catalog is to show where protected health information sits before anyone decides what to do with it. Clinical data lives in the EHR, claims in billing systems, results in the laboratory information system and copies in analytics stores, and research extracts are cut from all of them. OpenMetadata or DataHub, self-hosted in the organization's own infrastructure, is the usual fit for classifying PHI, assigning owners and tracing lineage from source tables to the extracts that leave the clinical environment. Both are Apache-2.0 licensed, so the decision turns on operating model, connector coverage and the team that will run the platform rather than on license cost. HIPAA does not certify anything. HHS states that no Security Rule standard requires an entity to certify compliance, and a private certification does not prevent HHS from later finding a violation. The catalog therefore produces evidence: a dated inventory of tagged sensitive columns, named owners, approved access requests and lineage showing which research or analytics copies derive from which source. Under 45 CFR 164.308 and 164.312, that evidence supports risk analysis and access controls, and the Office for Civil Rights reviews such records through complaints, compliance reviews and audits. Confirm with your privacy and security leads which of your systems are covered entities or business associate systems, because that determines which records the catalog must reach. HITRUST assessments and GDPR obligations are separate tracks that use the same inventory. A HITRUST r2 or i1 assessment is performed by an external assessor, and the GDPR context, including the 3 September 2026 CNIL decision against a French hospital under Articles 32 and 34, turns on access control matching the care team's need to know. Ask a partner to show how the catalog's tags feed access requests so that a research user can see that an extract is pseudonymized or identified, who approved it and which source it came from.

Which HIPAA and GDPR requirements shape the catalog build

This table maps each supplied HIPAA, GDPR and EU requirement to what it means for how a healthcare catalog is designed and populated. Read each row as a design input: the requirement on the left, the catalog feature it points to in the middle, and the point where teams most often fall short on the right. The main takeaway is that ownership, classification and access request workflows matter more to an assessor than the catalog product choice itself.

Requirement	What it means for the catalog	Where teams usually fall short
Security Rule scope for ePHI (45 CFR 164.302)	The rule covers all electronic PHI that covered entities and business associates create, receive, maintain or transmit, so the catalog must reach clinical, claims and research extracts, not only the warehouse.	Catalogs are scoped to the analytics warehouse, leaving source systems and exported files outside the inventory.
Unique user identification (164.312, required)	Catalog access must trace to a named person, so SSO-backed accounts and no shared service logins for steward or reviewer actions.	Shared analyst accounts or service tokens used for interactive browsing and edits.
Automatic logoff (164.312, addressable)	Session timeouts for catalog users who can view sample data or sensitive column profiles. Document the decision if the setting is not used.	Sample values and profiling output stay visible in long-lived browser sessions.
Encryption (164.312, addressable)	Encrypt catalog database, search index and connector credentials. Record the encryption method chosen and the reason for it.	Connector passwords stored in plain configuration and search indexes left unencrypted at rest.
Business associate flow-down (164.314(a)(2)(i))	Where a vendor or partner handles ePHI through the catalog, contracts must require Security Rule compliance and incident reporting. Track each external party as an owner or data source in the catalog.	Third-party connectors and implementation contractors not recorded as business associates.
Ownership per dataset (GDPR Article 5(2) accountability, supporting Articles 30 and 32)	Every ePHI-bearing table, file and extract needs a named business owner and technical steward so access decisions have an accountable approver.	Ownership is assigned to the platform team by default, so no one approves access to clinical datasets.
Classification tags for sensitive columns	Tag identifiers, diagnosis codes, dates of service and other sensitive fields so access rules and lineage reviews can filter on them. Map tags to confidentiality labels.	Tags applied only to column names, missing free-text fields and coded values in claims files.
Access request workflow (GDPR Articles 32 and 34)	Route requests for sensitive datasets through an approval step that checks the requester's role and need to know before access is granted. Keep the approval history in the catalog.	Access is granted by a broad group membership, so the need-to-know check described in the CNIL case does not happen.
Lineage into research and analytics extracts	Lineage from source systems through transformation to extracts lets reviewers show where ePHI was copied and who received it.	Extracts created by hand or by notebooks are not captured, leaving copies outside the lineage graph.
NIS2 Annex I health sector coverage	Healthcare providers and certain medical product manufacturers are high-criticality entities under NIS2. Confirm with counsel whether the organization falls in scope, since this affects inventory and incident evidence.	Organizations assume HIPAA scope covers NIS2 obligations, or the reverse, without checking each regime's applicability.
Security Rule revision (proposed, not final)	HHS proposed a major revision on 6 January 2025. No final rule had been published as of October 2026, and the Unified Agenda projects final action for July 2027. Design to the current rule and track the revision.	Teams build controls to proposed text as if it were binding, or ignore the proposal and miss likely new inventory expectations.

Which open source catalog fits a healthcare estate

A healthcare catalog has to cover clinical, claims and research data at once, with sensitive columns tagged and owners named. The options below differ mainly in how they capture lineage and classification, how much they assume about the stack around them, and who maintains them. Each card names one decision to make and one thing to confirm before committing.

OpenMetadata as the default candidate

OpenMetadata is Apache-2.0 licensed and lists more than 130 connectors for warehouses, BI tools, pipelines and ML platforms. It covers table, column, dashboard, pipeline and metric lineage through OpenLineage events, and it includes classifications, glossaries, domains and data quality tests that a PHI tagging program depends on. Confirm which EHR, claims and warehouse connectors are maintained for your exact vendor versions, because connector coverage varies by source system and release.

Column-level lineage into research extracts

For HIPAA and GDPR records, the question is whether a de-identified research extract can be traced back to the clinical or claims columns it was built from. OpenMetadata captures column lineage when its ingestion and OpenLineage integrations see the transformations, so warehouse SQL and dbt models are usually the reliable path. Confirm with your data engineering team which transformations run outside those tools, since manual spreadsheets and ad hoc notebooks will break the chain.

DataHub as the alternative

DataHub is Apache-2.0 licensed, and the open source project is at v1.7.0.1 as of September 3, 2026. It is a reasonable comparison when your team already runs Kafka-centric pipelines or prefers its metadata model and event-driven ingestion. Ask any partner to demonstrate PHI classification and ownership workflows on your own sample data in both products before choosing, because feature gaps tend to appear in access request handling rather than in connectors.

Maintenance and commercial support

OpenMetadata is maintained by Collate, which also offers commercial enterprise capabilities and premium support. Open source licensing does not include a support contract, an upgrade path or a hardened deployment, so the reader should ask who owns patches, how breaking changes in major releases are tested against their environment, and which parts of the roadmap sit behind a paid tier. Those answers shape the operating cost more than the license does.

Access requests and identity integration

A healthcare catalog is only useful if access requests route to the right data steward and care or research approver, and if the catalog's own access controls match the EHR's need-to-know rules. Confirm how the chosen platform authenticates users through your identity provider, how roles are mapped to stewards, and whether access request workflows can be audited. Keep the catalog's admin accounts separate from day-to-day stewardship roles.

Pipelines that feed research and analytics

Research and analytics extracts often pass through Apache Airflow or Dagster pipelines before they reach a warehouse or BI tool. Airflow is Apache-2.0 and Airflow 3.3.2 was published on September 17, 2026, while Dagster is Apache-2.0 with 1.13.26 published on October 9, 2026. Confirm that the pipeline metadata reaches the catalog, including task names, run history and dataset outputs, so lineage does not stop at the orchestrator boundary.

CKAN for published portals only

CKAN is a data portal platform built for publishing datasets to the public or to partner agencies, not for tracing PHI through clinical and claims systems. It fits when the goal is an open or shared dataset catalog with DCAT-style metadata. For internal healthcare governance, a portal alone will not provide column-level lineage or sensitive data tagging, so confirm that the requirement is internal governance before choosing it.

How deployment choices change the compliance boundary

Running OpenMetadata in your own data center keeps the catalog, its database and its search index inside facilities and networks your organization already controls. The HIPAA Security Rule applies to the electronic protected health information your workforce and systems handle, and a self-hosted catalog keeps the metadata that describes that data under the same administrative and technical safeguards as the source systems. The published bare metal prerequisites are Java 21, PostgreSQL 15 or later, and Elasticsearch 9.x or OpenSearch 3.x. The minimum server is 2 vCPUs, 4 GB RAM and 20 GB storage, and the database and search services each need at least 2 vCPUs, 2 GB RAM and 30 GB storage.

Hardware scope: Size the server, database and search nodes for your ingestion volume, not only the documented minimums.
Access paths: Confirm that connector credentials for clinical and claims sources are stored in your secrets management, not in configuration files.
Backups: Include the metadata database and search index in the same backup and restore schedule as other regulated systems.
Staffing: Name who patches Java, PostgreSQL and the search service, since your team carries that work directly.
Physical controls: Your facility safeguards under the physical standards apply to the hardware that holds catalog data.

Confirm which of these components sit in your existing covered-entity boundary and which, if any, your IT team already runs for other systems.

Integration points that carry PHI metadata

A healthcare catalog is only as trustworthy as the feeds that populate it. The six integration points below determine what the catalog can see, how sensitive fields are tagged, and what evidence it can later produce for HIPAA and GDPR reviews.

EHR and claims connectors

Connectors read schemas, table and column names, and sampled values from the EHR, the claims warehouse and the systems that feed them. This is where patient identifiers, diagnosis codes and member IDs first appear in the catalog, so the connector scope decides what gets classified. Confirm with the vendor which connectors are native for your EHR and claims stores, whether sampling can be turned off or limited per source, and how credentials are held. Ask whether connectors run inside your network so schema metadata never crosses a boundary you have not approved.

Pipeline lineage through OpenLineage

OpenLineage events emitted by orchestrators such as Airflow or Dagster let the catalog show how a clinical table becomes a claims extract, a de-identified dataset or a research cohort. Without this, lineage stops at the warehouse and the trail into research is lost. Confirm which pipeline tools in your estate emit OpenLineage events, how column-level lineage behaves through SQL transformations, and where lineage gaps will be documented for auditors. Lineage that is incomplete should be labeled as incomplete, not presented as full coverage.

SSO for steward and analyst access

Stewards, privacy staff and analysts reach the catalog through single sign-on, so group membership can map to who may see sensitive classifications and sample data. Access to PHI metadata should follow the same need-to-know rules that govern the source systems. Confirm how group claims map to catalog roles, whether sample previews can be hidden from broad read roles, and how deprovisioning is handled when a clinician or analyst changes teams. Ask for the audit trail of role changes as part of the handover.

Research extract workflow

Requests for de-identified or limited datasets for research pass through an approval step before a pipeline produces the extract. Recording that request, its approver, the source tables and the resulting dataset in the catalog creates the link between a research use and the PHI behind it. Confirm whether your workflow tool can hold the approval and write ownership and lineage back to the catalog, and whether the approval record can be exported for an institutional review board or privacy office.

Audit logging of catalog activity

The catalog records who searched for, viewed, edited or exported metadata about sensitive assets. Those logs matter because the HIPAA Security Rule expects audit controls and activity review, and because a catalog that exposes PHI column names is itself a system holding ePHI-related information. Confirm which events are logged, where logs are stored, how long they are retained, and whether they can be forwarded to your existing security information tooling. Ask how log integrity is protected.

Data quality and profiling jobs

Profiling and quality tests run against the sources and write row counts, null rates, value distributions and freshness results back to the catalog. Profiling reads real patient values, so job scope, sampling limits and the storage location of profile results need explicit decisions. Confirm which profiler settings default to sampling, whether sampled values are stored or only aggregated statistics, which service accounts run the jobs, and how failed checks are routed to the data owner.

How to tag sensitive columns and assign owners without slowing clinical teams

Start with auto-classification in a scoped pilot, not across the whole estate. In OpenMetadata, classification can be driven by column name rules and by entity recognition on sampled values. Name rules are fast and transparent, but they miss values stored under neutral names such as notes or ref_code. Sampling catches those values but produces more false positives, for example nine-digit numbers that are internal case IDs rather than member identifiers. Run both methods on a few clinical and claims tables that the privacy and clinical informatics leads already understand, then compare the hits against a manually labeled sample. Tune the confidence threshold until the false positive rate is low enough that stewards review a manageable queue. Confirm the current classification and recognizer options in the OpenMetadata documentation for your release before you write the rules, because the 2.0 line changed several defaults, including sampling.

Next, map PHI tags to confidentiality labels that your information security policy already uses, and keep that mapping in writing. A tag such as a direct identifier should map to the restricted label, while a quasi-identifier such as a date of service may map to a lower label that still requires an access request. The catalog records these as classifications and labels. It does not decide whether a field is PHI under the HIPAA Security Rule or whether a dataset is a limited data set. Those determinations belong to the privacy officer and counsel, and the catalog should show their decision as an owner-approved attribute. Every clinical or claims dataset needs one named data owner, accountable for who may access it, and one steward, who maintains its definitions and reviews classifications. Assign owners by business function, such as the claims adjudication lead or the registry manager, and avoid assigning all tables to the data platform team.

Review should be tiered so clinical teams are not reviewing every column. Stewards confirm auto-tags on new or changed datasets, and owners approve only high-sensitivity tags and any access grant. Configure access requests so they route to the owner recorded on the dataset, with the steward copied, and set a service level for responses that the owners agree to in advance. Track how many requests stall, because stalled requests are the usual reason clinical teams work around the catalog. Plan for the case where a dataset has no owner: block its PHI-tagged columns from being shared until one is named. Ask any implementation partner to show how the ownership and request workflow is configured in OpenMetadata, which roles can edit classifications, and how changes are logged for later review.

How a healthcare catalog rollout runs in phases

The sequence moves from defining which systems hold ePHI to a catalog that the organization's own team can run, upgrade and extend. Each phase closes with a written output so scope, ownership and evidence are settled before the next phase starts.

Scope in-scope systems and the ePHI boundary
The engagement starts by listing the clinical, claims, billing, research and analytics systems that create, receive, maintain or transmit electronic protected health information, and by agreeing which of them sit inside the catalog's boundary. DeployOpen works with the privacy office, security team and system owners to record the systems, the data flows between them, and the business associates that handle ePHI. The step closes with a signed scope document and a boundary diagram that the organization approves. Done means every in-scope system has a named owner and a stated reason for inclusion.
Deploy the catalog in the organization's infrastructure
The platform is installed in the organization's own cloud accounts, data center or private network, using the deployment model agreed in scope. Typical components include the catalog application, its metadata database and its search service, each with network segmentation, encryption, backups and identity integration configured to the organization's standards. DeployOpen documents the build and runtime prerequisites, including the Java and database versions named in the OpenMetadata bare metal documentation, and records the configuration. The step is complete when the environment passes a health check and an access review confirms that only approved roles can sign in.
Set up connectors and lineage capture
Connectors are configured for the in-scope clinical, claims and analytics sources, along with the pipelines and extract jobs that move PHI into research and analytics environments. Lineage is captured at table, column and pipeline level where the source tooling supports it, and gaps are logged as known limitations rather than hidden. Service accounts are created with read-only, least-privilege access and their credentials are stored in the organization's secrets management system. The step closes when a sample lineage path, such as a clinical table through a transformation job into a research extract, can be traced end to end and reviewed by the data owner.
Classify PHI and assign owners
Sensitive columns are identified through a combination of naming rules and sample-based detection, then reviewed by data stewards who confirm or correct each tag. Classifications are mapped to the organization's confidentiality labels, and every dataset receives a named business owner and a technical custodian. Reviewers record how false positives were handled and who approved the tuning, so the classification can be explained later. The step is complete when every in-scope dataset carries an owner, a classification and a review date, and the privacy office has signed off on the PHI tag set.
Build the access request workflow
A request workflow is configured so that staff ask for access to a dataset through the catalog, the owner approves or rejects it, and the decision is recorded with its reason and date. Approvals are tied to the need-to-know principle that the organization sets for each classification, and any role change or revocation is logged. DeployOpen tests the workflow with representative requests, including a denied request and an expired grant, and confirms that the audit trail captures each step. The step closes when the privacy and security teams have walked through the test cases and accepted the recorded evidence.
Hand over with an upgrade and operations plan
The handover package includes architecture and configuration documentation, runbooks for connector maintenance and backups, a list of owners and their responsibilities, and a training session for the platform and stewardship teams. The upgrade plan is written before go-live, because OpenMetadata 2.0 introduced breaking changes, including moving embedding credentials into an llmConfiguration block, a new Databricks auth format, rebuilding custom ingestion images for Python 3.12 and migrating Great Expectations to 1.3 before upgrading. Each upgrade is tested in a non-production copy first, and the team confirms the release notes for every version it adopts. The step closes when the organization's own staff have run a backup restore and a test upgrade, and both results are recorded.

Evidence the catalog can produce for HIPAA and GDPR reviews

This table maps the evidence a self-hosted catalog can produce to the component that generates it, so reviewers can see where each artifact comes from. Read it as a list of inputs to an assessment, not as proof of compliance. Auditors and HHS decide whether the evidence is sufficient, and DeployOpen prepares the evidence without issuing attestations.

Evidence	Produced by	What the reviewer checks
Classification inventory export	OpenMetadata or DataHub classification and tagging of PHI columns	Whether sensitive columns across clinical and claims sources are tagged, with the tagging method and date recorded
Owner assignments	Catalog ownership fields and domain assignments per dataset	Whether each dataset holding ePHI has a named, accountable owner who approves access
Lineage graph from source to research extract	Table and column lineage, with OpenLineage events from pipelines	Whether a research or analytics extract can be traced back to the clinical or claims source it came from
Access request records	Catalog access request workflow and its audit trail	Who asked for ePHI, who approved it, and whether the approval matched the stated need to know
Configuration records	Versioned deployment config, SSO and role settings kept in your repository	Whether authentication, role mappings and logging were set as documented and changed under control
Audit logs of catalog activity	Platform logs shipped to your SIEM or log store	Whether administrative and metadata changes are recorded with user identity and timestamp
Business associate and data processing terms	Your contracts, not the catalog (confirm with counsel)	Whether vendors and integrators touching ePHI are covered by the agreements the rules require
AI system event logs (only if extracts feed AI)	Logging at the AI system, referenced from catalog lineage	Whether logs are retained as EU AI Act Articles 12 and 19 require, which depends on the system's risk classification

What to ask an implementation partner before signing

Start with the connectors, because every later question depends on them. Ask which EHR and claims sources the partner will connect, whether each connector runs inside your network, which service account and read scope it uses, and whether the partner will connect to production or to a de-identified copy first. Ask how the partner will prove that no PHI leaves your environment through the ingestion path, and how it will handle connector credentials in the ingestion configuration so that secrets are not stored in plain text in pipeline definitions. Ask for the list of tables and fields in scope to be written into the statement of work, not left to discovery.

Next, ask how lineage and governance will be built and who will sign off on them. Ask how table, column and pipeline lineage will be captured from the extract jobs that feed research and analytics, whether through OpenLineage events or through parsing of job code, and what the partner will do where a manual step breaks the chain. Ask how owners and the business glossary will be bootstrapped with clinical and claims staff: who runs the workshops, how many domains are covered in the first phase, and how PHI tags will be mapped to the entries in your records of processing and to the HIPAA safeguards your privacy and security officers own. Ask who approves a tag change.

Finally, ask about the contract and the upgrade path. Request written answers on how business associate terms apply to the partner and to any subcontractor that can reach ePHI or ingestion credentials, as 45 CFR 164.314(a)(2)(i) requires for business associate contracts, and how incidents will be reported to you. Ask how OpenMetadata upgrades are tested against a staging copy of your connectors, lineage and classification rules, given that the 2.0 release notes list breaking changes. Ask for a written scope, a deliverables list, acceptance criteria for each phase and the named roles on both sides before any work begins.

Questions healthcare teams ask before hiring outside help

What drives the cost of a healthcare data catalog project?

Cost follows scope: how many source systems need connectors, how deep lineage must go, how much metadata curation is needed, and where the platform is hosted. The main cost components are the infrastructure that runs the catalog, the connector and lineage setup, the time clinical and privacy staff spend confirming owners and definitions, and ongoing operations. OpenMetadata is released under the Apache License 2.0, so there is no license fee for the software itself, but its bare metal prerequisites (Java 21, a supported PostgreSQL or MySQL database and Elasticsearch 9.x or OpenSearch 3.x) are paid infrastructure. A quote should itemize connectors, lineage depth, classification rules, training, hosting and support as separate lines, with the one-time and recurring items labeled.

How long does a healthcare data catalog implementation take?

The duration depends on the number of systems in scope, how many of them are clinical versus claims, and how quickly owners can be named. DeployOpen does not publish a fixed timeline. Each engagement is fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ask a prospective partner to break the timeline into phases: environment setup, first connectors, PHI classification review, lineage for one research or analytics extract, and handover. Phases that depend on clinical or privacy decisions often take longer than technical setup, so ask how those reviews are scheduled.

How much time do clinical and privacy staff need to give?

Clinical informatics, privacy and data owners need to confirm what each sensitive column means, who is accountable for each dataset, and which extracts may contain PHI. Technical teams can tag columns from name rules and sample data, but a person with clinical or privacy authority should review the results before they drive access decisions. Ask the partner to name the reviewers for each dataset, estimate how many review sessions the scope requires, and state what the review produces: approved classifications, a glossary of clinical terms and a log of decisions that auditors can read later.

Can our internal team run a healthcare data catalog without outside help?

Yes, many teams run open-source catalogs in-house, and the question is capacity and skills rather than permission. Running OpenMetadata well requires people who can operate the database and search services, manage upgrades (OpenMetadata 2.0 includes breaking changes, including embedding credential changes and a Python 3.12 requirement for ingestion images), write and maintain connectors, and steward metadata. Outside help is most often used for the first build, the initial classification design, and the upgrade runbook. Assess your team against those tasks, and ask a partner to split the work into what you keep and what they deliver.

Is there a HIPAA certification for a data catalog or the organization running it?

No. The HHS Office for Civil Rights states that no Security Rule standard requires an entity to certify compliance, and that private certifications do not prevent HHS from later finding a violation. HHS enforces the rule through complaints, compliance reviews and audits. A catalog can support HIPAA evidence, such as a record of which systems hold ePHI, who owns them and how access requests are handled, but it does not make an organization compliant on its own. Any claim of HIPAA certification from a vendor or partner should be treated with caution. If a third-party assurance report is wanted, ask which framework it would use, such as HITRUST CSF, and who would issue it.

What is one-time work and what recurs after go-live?

One-time work includes the initial deployment, connector configuration, the first classification and ownership pass, glossary bootstrap, and the design of access request workflows. Recurring work includes hosting and database costs, search index capacity, connector maintenance when source systems change, upgrades (OpenMetadata 2.0.0 was released on August 24, 2026, followed by maintenance releases 2.0.1 to 2.0.5), steward review of new datasets, and periodic checks that classifications still match the data. Ask for these as separate line items, and ask whether support and upgrades are covered by a retainer or billed per request.

Does a healthcare data catalog cover GDPR as well as HIPAA?

It can support both, but the obligations differ. HIPAA applies to covered entities and business associates for ePHI, while GDPR applies to personal data of people in the EU and EEA, including health data. A single catalog can tag personal and PHI columns, record which systems and extracts use them, and show who owns each one. Ask the partner how the classification scheme maps to each regime, and whether business associate contract obligations, such as flow-down to subcontractors under 45 CFR 164.314, are tracked in the catalog or in a separate register.

How DeployOpen scopes and supports a healthcare data catalog

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For a healthcare data catalog, that means the metadata, classification evidence and access workflows stay in the organization's cloud accounts, data centers or air-gapped networks, scoped in writing before work starts.

How we scope

Written scope listing which clinical, claims and research sources are connected to the catalog and which are excluded
Agreed list of PHI and personal data categories to tag, with owners named for each system and dataset
Decisions on lineage depth into research and analytics extracts, documented before connector work begins
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts

How we build

Deploys OpenMetadata or DataHub in the client's environment, with database and search services configured for production
Configures connectors, classification rules and glossary terms for sensitive columns, then tests tagging accuracy on sample data
Integrates SSO and access request workflows so ownership and approvals are recorded in the catalog
Runs security testing of the catalog deployment and its integrations before handover

How we hand over

Documents architecture, data flows, connector configuration, classification logic and upgrade procedures
Delivers evidence packs mapping catalog controls to HIPAA Security Rule safeguards and GDPR records requirements
Trains data owners, stewards and privacy staff on reviewing tags, lineage and access requests
Backup and recovery steps are written down and tested with the client's operations team

How we support

Ongoing support, upgrades and continuous testing are available as a retainer, covering OpenMetadata or DataHub version changes
Reviews new source systems and extracts for personal data before they are added to the catalog
Confirm with your auditors and compliance team that catalog evidence meets their expectations, since DeployOpen prepares evidence but does not issue attestations