Derived relations: what it means for data governance teams

TL;DR: Derived relations let users define custom multi-hop paths in Collibra's knowledge graph so indirect asset connections, lineage, and policy context surface directly on an asset page, according to Collibra. The governance shift is from static lineage viewing to operational context discovery, which matters whenever security, compliance, or AI oversight depends on relationships that are not one hop away.

NHIMG editorial — based on content published by Collibra: Connecting the dots on how derived relations unlock complex connections in your knowledge graph

By the numbers:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
• Only 5.7% of organisations have full visibility into their service accounts.

Questions worth separating out

Q: How should teams use multi-hop relationships in a knowledge graph for governance decisions?

A: Use multi-hop relationships to surface the dependencies that matter for lineage, policy scope, and accountability, not just to make diagrams richer.

Q: Why do indirect relationships matter in data governance and access governance?

A: Indirect relationships often carry the real control impact because policies, ownership, and downstream dependencies are rarely one hop away.

Q: What should teams check before publishing derived relationships in a knowledge graph?

A: Check that the path has clear business meaning, a named owner, and a stable interpretation in both directions.

Practitioner guidance

• Define governance-critical multi-hop paths explicitly Map the indirect relationships that drive policy scope, ownership, lineage, and downstream impact, then create derived relation types for those paths instead of relying on ad hoc navigation.
• Assign relation semantics with business meaning Review head asset type, tail asset type, role, and co-role with the governance owner before publishing the path so the relation reads correctly in both directions.
• Add derived relations to the asset types used in review workflows Place the widget on the objects that reviewers, analysts, and approvers actually inspect, so the indirect dependency appears where decisions are made.

What's in the full article

Collibra's full post covers the implementation detail this analysis intentionally leaves for the source:

• The exact path-definition workflow for creating a derived relation type in platform settings.
• How head asset type, tail asset type, role, and co-role are configured in practice.
• What the derived relation widget does when an asset page loads and queries the graph.
• Examples of derived relation use cases for lineage and policy traceability on specific asset types.

👉 Read Collibra's post on derived relations for knowledge graph context →

Derived relations: what it means for data governance teams?

Explore further

View Full Forum →  |  NHI Foundation Course →