Governance trace
Governance work produces a web of relationships. A control covers a framework requirement. A risk is mitigated by that control. Evidence supports the control. A finding contradicts a piece of evidence. An assessment evaluated all of them.
Governance trace is the in-product layer that makes those relationships first-class: queryable, visible on each record, and walkable as a graph. Catalog lineage is the related provenance layer that records where a local record came from when it was imported or installed from an upstream catalog.
Together, these two answer the questions auditors and internal reviewers ask most:
- “What touches this control?”
- “What does this finding affect?”
- “Where did this assessment template come from, and is it still current?”
- “If we change this evidence, which downstream records care?”
What lives in this section
| Page | What it covers |
|---|---|
| Trace graph | Neutral trace links between records, the graph panel, depth and direction controls, and how trace differs from a hard foreign key. |
| Catalog lineage | Where local records came from when they were imported from a catalog, lineage status (active, superseded, detached), and the package-installation record above individual templates. |
How trace relates to the rest of governance
Trace is not a separate module you have to populate. The work happens in the governance modules themselves: when you link an assessment finding to the control it contradicts, that link is also a trace edge. When you attach evidence to a control, that’s a trace edge. When an automation creates a finding from a monitoring event, that’s a trace edge.
The trace section of the docs is about how to read and use that graph, not about how to populate it. You’ll find dedicated pages for each governing object under Modules.
How lineage relates to governance content
Some records start as local from day one (an internal control your compliance team wrote). Others arrive from an upstream catalog (a framework registered from an industry catalog pack, an assessment template imported from a published package, a controls library installed across the organization).
Lineage gives those imported records a back-reference: the upstream catalog provider, the source template version, the install date, who accepted it. As upstream catalogs change, lineage tells you when your local record is on an older version and whether you’ve intentionally detached it.
Catalog lineage is read-mostly for end users. You see it on a record’s detail page; you don’t usually create lineage entries by hand. They’re written when something is installed or imported.
When to reach for this section
- An auditor asks “what’s the evidence trail for this finding?” Use Trace graph.
- A reviewer asks “is this assessment template still aligned with the source catalog?” Use Catalog lineage.
- You’re planning to retire a control and want to see what depends on it. Use Trace graph.
- You’re deciding whether to accept an updated version of an imported package. Use Catalog lineage.
Related
- Modules, where the records themselves live.
- Governance overview, the big picture this fits into.
- Audit log, for the time-ordered record of who did what.