OpenMetadata for GDPR records of processing

The working method starts by marking where personal data sits, then assigning accountability for it, then tracing where it travels. In OpenMetadata, the first step uses classifications and glossary terms applied to tables and columns that hold personal data, such as customer names, contact details, national identifiers or account numbers. Your data governance lead should agree a short tagging vocabulary before anyone tags anything, so that a column holding an email address and a column holding a phone number are recorded consistently and can be filtered together when the record of processing is compiled.

Ownership comes second. Each asset in a domain needs a named owner who can answer for the processing purpose behind it, not only for its technical health. The domain owner should confirm which team collects the data, which team uses it, and who approves changes to the classification. Without a named owner, tags tend to drift and the Article 30 entries built from them lose their accountability trail. Assign owners at the table level first, then check that column-level tags sit under an owner who recognizes the data.

Column-level lineage then shows the route the data takes from source systems through transformations to downstream dashboards, pipelines and exports. This is the part of the method that answers recipients and transfers questions. A marketing export that carries an email column is a recipient of personal data even if no one has recorded it as one. Lineage shows that export as a downstream node, and the owner of that export becomes a candidate entry in the recipients field. Lineage also shows whether the flow crosses a boundary into a third country, which you will need to confirm against the hosting locations of each downstream tool, since OpenMetadata records the lineage edge but not the physical location of the recipient.

Be precise about what detection will and will not do. Confirm with the vendor documentation for your chosen release which tagging and detection options it provides, whether profiling can flag candidate personal data, and whether those flags need human review before they become classifications. Also confirm how sampling affects coverage. If profiling samples rows, a column that holds personal data in only a small share of records may not be flagged. Plan a manual review of high-risk tables and of any column whose name or lineage suggests personal data, and record which assets were reviewed by hand.

Treat the output of this method as a map to verify, not a finished inventory. Before the record of processing is signed off, have each owner confirm the tagged columns in their domain, check the lineage edges that leave the domain, and log any gaps, such as a spreadsheet export that never reached the catalog. The gaps list is itself useful evidence that the team looked, and it tells the privacy function where manual interviews or code reviews are still needed.

The catalog can show where personal data sits, who owns the asset and how data moves between systems, but several parts of the Article 30(1) record are decisions and statements that no metadata connector can capture. Plan these as entries in a register or governance process owned by the privacy function, and link each one to the catalog by asset identifier. The main items are the controller's contact details, the purposes and lawful basis for each processing activity, the decision on whether a recipient contract is in place, the transfer mechanism for any third-country transfer, the retention and erasure decisions, and the general narrative of Article 32 security measures.

Purposes and lawful basis are the hardest to derive from a catalog. A table or pipeline can be tagged as containing personal data, but the reason it exists and the legal basis relied on are judgments made by the controller. Ask the business owner of each processing activity to state the purpose in their own words, then record the lawful basis and the categories of data subjects in the register. Confirm with your counsel whether any activity relies on legitimate interests, since that reliance requires a documented balancing assessment that must sit beside the record.

Recipient contracts and transfer mechanisms need the same treatment. OpenMetadata can show that a dashboard or external export consumes a dataset, but it cannot tell you whether a data processing agreement with that recipient is signed, which version applies, or whether a transfer to a third country relies on an adequacy decision, standard contractual clauses or another safeguard. Chapter V of the GDPR governs these transfers. For transfers to the United States, confirm whether the recipient is certified under the EU-US Data Privacy Framework, as set out in Commission Implementing Decision (EU) 2023/1795, and record the check date and the source you used.

Retention and erasure decisions also belong in the register. Catalog tags can show that a table holds personal data and where its owner has set a retention note, but the time limit and the rationale for it must be set by the controller and reviewed regularly. Article 30(1) requires these limits where possible. Article 32 measures are described in narrative form, usually as a security overview that cross-references the encryption, access control, logging and backup standards in force. The catalog can link to those standards through asset identifiers, but it does not replace them.

Finally, be precise about external assurance. The GDPR requires no audit, attestation or certificate, and the record of processing is a document the controller must keep and produce to the supervisory authority on request. Article 42 certification is voluntary, is issued for at most three years by accredited bodies or supervisory authorities, and does not reduce the controller's or processor's responsibility for compliance. Do not present a catalog export, a certificate or an internal review as proof of compliance. Confirm with your legal team which evidence the supervisory authority would expect for your processing, and whether any pending changes to the GDPR, which as of October 2026 has not been amended, would affect the register's content.

The register stays accurate only if someone owns the recurring work that keeps the OpenMetadata catalog and the Article 30 record in step. Name one process owner, usually the privacy lead or data governance lead, and give that person a standing review calendar, a written checklist and a log of decisions. Without a named owner, the catalog drifts from the register within a few release cycles, and the gap usually surfaces only when a supervisory authority asks for the record.

The first recurring task is reviewing new connectors and tables against the register. Each new ingestion source, and each new schema that appears in an existing source, should be checked for personal data before it is treated as covered. Confirm that PII tags and classifications have been applied to new columns, that the owning team has been assigned, and that any new recipient or third-country destination reachable through lineage has been added to the processing entry. Ask your data team to route new connector onboarding through this review rather than leaving it to individual engineers.

The second task is re-checking classifications after schema changes. Renamed, split or merged columns can silently lose a PII tag or inherit one they should not carry. Run a periodic query against the tables tagged as personal data and compare the results with the processing activities they support. Owner assignments need the same attention. When staff move teams or leave, reassign ownership of tables, dashboards and pipelines, and check that no processing activity in the register points at a departed person. Record each reassignment so the audit trail shows who was responsible at each date.

The third task is planning OpenMetadata upgrades, and it should be scheduled rather than handled as an emergency. The 2.0 release notes list breaking changes that affect a self-hosted deployment. Embedding credentials move into an llmConfiguration block, the Databricks authentication format changes, custom ingestion images must be rebuilt for Python 3.12, and Great Expectations must be migrated to 1.3 before the upgrade. Confirm each item against your own connectors and configuration, test the upgrade in a non-production environment, and check that tags, owners and glossary links survive the move before you approve it.

Finally, record the process itself. Keep a short runbook that lists each recurring task, its frequency, its owner, its evidence and its escalation path, and review it at least once a year. The schedule should be agreed with the privacy team and the platform team before go-live, because the cost of this work is mostly staff time and recurs for as long as the catalog is in use. Ask any implementation partner to deliver the runbook and the first review cycle as part of the fixed scope, and confirm which tasks will remain with your team afterward.