For GRC teams

The evidence mapping problem

Every GRC practitioner knows this pain: you have evidence (policies, procedures, audit findings, screenshots, technical configs) scattered across wikis, SharePoint, OneNote, and email. You have frameworks (NIST, CIS, MITRE, CRI, FFIEC) in massive spreadsheets. And you need to prove to auditors that specific evidence satisfies specific controls.

Status last verified: 2026-08-28 — verified in real Obsidian against the ATT&CK release-drift report and selected housekeeping re-baseline flow.

This is evidence mapping — the core work of compliance — and the tools are broken. Understanding who owns what in the ontology ecosystem helps explain why.

Built for GRC first; works for any structured framework or taxonomy. Every example on this page is compliance, and the one-click imports that ship today are all compliance sources. Nothing in the note format is compliance-specific, though, and that works in your favor: the non-GRC structures your team already maintains — vendor questionnaires, internal control taxonomies, asset and service hierarchies, skills matrices — go through the same guided import, so they can live in the same vault and link to the same evidence instead of a separate tool. Why the core stays domain-neutral.

Two worlds that don’t talk to each other

Framework world (structured)	Evidence world (unstructured)
NIST 800-53: 1000+ controls in a spreadsheet	Your MFA policy lives in SharePoint
CIS v8: 153 safeguards in an Excel tab	Your firewall configs are in a wiki
CRI Profile: Diagnostic statements across 8 sheets	Your audit findings are in email threads
ATT&CK: 200+ techniques in a matrix	Your detection rules are in SIEM configs

The gap between these worlds is where compliance teams spend most of their time — manually searching, cross-referencing, and documenting connections in yet another spreadsheet.

Why spreadsheets fail at evidence mapping

• No bidirectional linking — you can write “AC-2 → MFA Policy” in a cell, but the MFA Policy document doesn’t know it’s been mapped. Update the evidence and the mapping is instantly stale. This is the referential integrity gap that file-based systems face.
• No metadata about the mapping itself — Is this evidence sufficient? Who reviewed it? When was it last validated? What type of evidence is it? Spreadsheets can’t answer these. Crosswalker solves this with typed links and edge metadata.
• No cross-framework traceability — when an auditor asks “show me the CRI diagnostic statement, the CSF subcategory it maps to, the 800-53 control, AND the evidence” — that’s a manual detective hunt across 4+ spreadsheets. Framework crosswalks make this one click.
• No query capability — you can’t ask a spreadsheet “which controls have zero evidence?” without formulas that break when rows shift. Obsidian Bases solves this natively.
• Sync is impossible — frameworks update, evidence moves, people leave. The mapping sheet becomes a graveyard of stale references. This is the ontology evolution problem — and it’s never fully solved, only managed.

The multi-framework regulatory pressure

Financial institutions using CRI Profile must simultaneously demonstrate compliance with NIST CSF, FFIEC CAT, CISA CPG, and sometimes NYDFS and SEC requirements. Each regulator uses different terminology for overlapping requirements. Without systematic crosswalking, teams map the same evidence to the same concept in 5 different spreadsheets.

This isn’t just inefficiency — it’s a compliance risk. Inconsistent mappings across frameworks signal to auditors that the organization doesn’t truly understand its control environment.

What Crosswalker does differently

Crosswalker eliminates the gap between frameworks and evidence by putting everything in one place — your Obsidian vault — where frameworks, evidence, policies, and notes are all interlinked and queryable.

Import frameworks as navigable knowledge

Your Vault
├── Ontologies/                   ← default output folder (change it in settings)
│   ├── NIST-800-53/
│   │   ├── Access Control/
│   │   │   ├── AC-1.md          ← full control text, metadata, crosswalk links
│   │   │   └── AC-2.md          ← linked to CIS 5.2, CIS 6.3, PR.AC-07
│   │   └── ...
│   ├── CIS-Controls-v8/
│   └── MITRE-ATT&CK/
├── Evidence/
│   ├── MFA-Policy.md            ← links directly to AC-2, CIS 6.3, PR.AC-07
│   ├── Firewall-Audit-Q1.md     ← links to SC-7, CIS 4.4, DE.CM-01
│   └── Pen-Test-Report.md       ← links to CA-8, ATT&CK techniques
└── Reports/
    └── Compliance-Dashboard.md   ← live queries across everything

Every framework control is a note you can open, read, and link to. No more hunting through spreadsheet rows.

Map evidence with structured metadata

This is the breakthrough. When you link evidence to a control, you can attach metadata about the relationship itself — as a small evidence-link note whose properties describe the relationship:

# Evidence Links/AC-2--has_evidence--MFA-Policy.md
---
kind: junction-note
subject: "[[AC-2]]"
subject_curie: nist-800-53:AC-2
predicate: has_evidence
object: "[[MFA-Policy]]"
status: approved
coverage: full
reviewer: Alice
review_date: 2026-03-15
---

You do not have to write this by hand. Run Crosswalker: Evidence: link evidence to a control from the command palette, or from an open control note to have that control pre-selected. It asks for the control and the evidence, fills in the rest, and the note it creates says whether the link counts yet.

If you do write one by hand, three details carry weight, and getting them wrong is the difference between a coverage report that works and one that silently reports nothing:

• Direction. subject is the control; object is the evidence. Read it aloud: “AC-2 has evidence: the MFA policy.” Writing it the other way round produces links that look fine and count for nothing.
• predicate: has_evidence. This exact value is what coverage counts. Other relationships between notes are perfectly legitimate, but they are not a claim that evidence satisfies a control, so they do not appear in coverage.
• status: approved. Proposed and in-review links are not yet evidence. Only approved links count.

subject_curie is the control’s stable identifier. Fill it in wherever your spreadsheet has it: links are matched by that identifier rather than by note name, so renaming AC-2.md later does not quietly detach its evidence.

A second link from the same policy to IA-5 can carry coverage: partial and a gap note. Because every relationship is a note with plain properties, “show me all controls where evidence is partial and needs remediation” is one Bases filter — not a spreadsheet treasure hunt.

Crosswalk between frameworks automatically

Import NIST 800-53 and CIS Controls, and Crosswalker generates the WikiLinks between corresponding controls. The crosswalk lives in your vault as navigable, queryable connections — not a separate mapping spreadsheet.

When an auditor asks “trace from CRI diagnostic statement through CSF to 800-53 to your evidence” — you follow the links. Each hop is one click.

Query your compliance posture

Two different tools answer two different kinds of question, and it is worth knowing which is which.

Obsidian Bases answers questions about links that exist:

• “Show all controls where evidence is insufficient” — filter by metadata
• “What evidence was last validated more than 90 days ago?” — date filter
• “Which evidence links are still awaiting approval?” — filter by status

Crosswalker’s coverage report answers questions about links that are missing:

• “Which controls have no evidence?”
• “What share of each family is covered?”

That split is not a limitation anyone chose; it is what the two tools can each honestly do. A Bases view filters the notes in your vault. A control with no evidence has no evidence note to filter, so there is nothing for a view to show — the control simply does not appear, and an empty result looks identical to a clean bill of health. Counting backlinks does not rescue it either, because hierarchy links, index links, and framework crosswalks are all backlinks, so nearly every control looks covered.

Crosswalker therefore computes coverage from its own index, which can tell the difference between “no evidence” and “no row”. Run Crosswalker: Evidence: create coverage report from the command palette. It writes a note listing the controls with no valid evidence, the partially covered ones, and any evidence links it had to set aside and why: wrong direction, unapproved status, expired review, or a control that changed after approval. A low score sends you to the data rather than to a panic.

Changed controls appear in three review queues, in this order: wording, scope, then housekeeping. Each heading gives its count, and every changed link appears once. Wording and scope changes need human re-review. For housekeeping-only source changes, select the rows you mean to acknowledge and run Crosswalker: Maintenance: record selected housekeeping changes as baseline. Crosswalker asks for confirmation and updates only those recorded fingerprints; it does not change approval status, reviewer, or review date. A link with no recorded baseline still counts and is named separately, because missing history is not proof that the control stayed unchanged.

The report also states when the index behind it was last rebuilt, and warns you if that rebuild was incomplete. It is regenerated from scratch each run, so keep your own notes elsewhere.

A dashboard is a plain .base file you drop in your vault. Save this as Reports/Evidence-Links.base and Obsidian renders live views over your approved evidence links:

filters:
  and:
    - 'kind == "junction-note"'
    - 'predicate == "has_evidence"'

properties:
  subject:
    displayName: "Control"
  object:
    displayName: "Evidence"
  coverage:
    displayName: "Coverage"
  review_date:
    displayName: "Last reviewed"

views:
  - type: table
    name: "Approved evidence"
    filters:
      and:
        - 'status == "approved"'
    order:
      - subject
      - object
      - coverage
      - review_date
    summaries:
      subject: Count

  - type: table
    name: "Partial coverage — needs remediation"
    filters:
      and:
        - 'status == "approved"'
        - 'coverage == "partial"'
    order:
      - subject
      - object
      - notes

  - type: table
    name: "Evidence going stale"
    filters:
      and:
        - 'review_date < (today() - "90d")'
    order:
      - review_date
      - subject
      - object

  - type: table
    name: "Awaiting approval"
    filters:
      and:
        - 'status != "approved"'
    order:
      - subject
      - object
      - status

Change a filter, get a different report. No formulas to re-drag, no rows to keep in sync.

Every view above is a report on evidence you have. For the gap list — the controls with nothing attached — run the coverage report, which counts controls rather than filtering notes.

Own your data

Every control, every mapping, every piece of evidence metadata is a plain markdown file in a folder on your disk. No vendor database. No API dependency. Version control with git. Move between tools freely. Your compliance knowledge base is yours.

Owning the files does not override the framework publisher’s terms. Importing for internal use, redistributing the source, and sharing generated notes can be different acts. Check the per-framework licence posture before a vault containing imported framework content leaves your organization.

Handle framework updates without panic

When NIST publishes CSF 3.0, re-import alongside 2.0. Your evidence links to 2.0 controls stay intact. Migrate at your own pace using the version-tagged folder approach. No more “framework update breaks everything” emergencies.

Supported frameworks

Crosswalker imports any structured data from CSV, XLSX, or JSON. These sources ship with one-click recognized import:

Framework	What you get
NIST CSF 2.0	Subcategories in function/category structure (three layout variants, including the CPRT export)
NIST SP 800-53 Rev 5	Controls and enhancements as notes
CIS Controls v8	Controls and safeguards, two layout variants
MITRE ATT&CK	Techniques with tactic metadata
MITRE Fight Fraud Framework (F3)	Fraud techniques for financial services, with tactic metadata (a technique under several tactics lists them all)
CRI Profile v2.2	Diagnostic statements
SCF 2026	Controls from the Secure Controls Framework workbook
OLIR-style crosswalk files	Framework-to-framework mapping rows as typed crosswalk notes

Not on the list? If it’s in a CSV, XLSX, or JSON export, Crosswalker imports it through the same guided mapping — it just doesn’t get the one-click head start. (The companion Python CLI in the repo additionally batch-imports MITRE D3FEND and ENGAGE.) See framework data sources for technical details.

Getting started

1. Install Crosswalker
2. Import your first framework
3. Start creating evidence notes and linking them to controls
4. Build compliance dashboards with Obsidian Bases
5. When audit time comes, your evidence trail is already built

---

Resources

• The problem — the hierarchy vs. graph tension at the heart of this
• Link metadata system — how edge metadata works
• Framework standards & tools — comprehensive reference
• Framework data sources — publisher files, licence posture, bundled recipes, and silent-failure gotchas
• Ecosystem — where Crosswalker fits in the GRC landscape