Institutional landscape

Every ontology evolution problem has a human side. Frameworks don’t update themselves — institutions create them, other institutions map between them, regulators mandate them, and your team consumes them. Understanding these actors and their relationships is essential for making architectural decisions about how Crosswalker handles the ontology lifecycle.

---

The entities

Seven types of actors participate in the ontology ecosystem. Each has different incentives, timelines, and capabilities.

Standard bodies

Create and publish frameworks

NIST, ISO, MITRE, W3C, OASIS

Industry groups

Create domain-specific frameworks

CRI, FS-ISAC, OWASP, PCI SSC, HITRUST

Regulators

Mandate which frameworks to use

SEC, FFIEC, NYDFS, EU NIS2, HIPAA/HHS

Mapping organizations

Create and maintain crosswalks between frameworks

NIST OLIR, SCF, Center for Threat-Informed Defense

GRC vendors

Implement frameworks in software

ServiceNow, Archer, Drata, Vanta, CISO Assistant

Your organization

Adopts frameworks, maps evidence, proves compliance

GRC team, security team, IT, engineering

Auditors

Verify framework adoption and evidence

Big 4, internal audit, examiners, assessors

Terminology note: These entity types are defined in the terminology page. In other domains: standard bodies = standards development organizations (SDOs), industry groups = trade associations, mapping organizations = ontology alignment services. Mapping organizations that maintain mappings from many frameworks to a single canonical intermediate (like SCF with its ~1,300 controls, UCF’s ~10,000 Common Controls, or the DESM project) are also known as synthetic spine or hub-and-spoke mapping services — an architectural pattern where N frameworks each map once to a central pivot instead of authoring O(N²) direct pairwise crosswalks. Whether Crosswalker should adopt, inherit, or reject a synthetic spine architecture is the subject of Challenge 06 and the 04-10 foundation synthesis.

Interactive entity map

Drag nodes to explore relationships. Hover to highlight connections.

---

The relationships

These entities interact through six relationship types. Each creates a different kind of dependency — and a different kind of staleness risk.

Relationship	From → To	What it means	Staleness risk
Publishes	Standard body → Framework	Creates and versions the ontology	Low (they control the schedule)
Mandates	Regulator → Framework adoption	”You must comply with this”	High (mandate may reference specific version)
Maps/crosswalks	Mapping org → Framework↔Framework	”These controls correspond”	Very high (neither framework owner controls this)
Implements	GRC vendor → Framework-in-software	”Our tool supports this framework”	Medium (vendor may lag behind updates)
Adopts	Your org → Framework	”We comply with this”	Medium (your evidence links to a snapshot)
Verifies	Auditor → Your compliance evidence	”Prove it”	Low (point-in-time assessment)

The dependency chain

Every compliance assertion follows this chain — and any link can break:

Standard body

publishes

→

Framework

mandated by

→

Regulator

requires

→

Your org

maps evidence via

→

Crosswalk

verified by

→

Auditor

When NIST updates 800-53, the “publishes” link changes. But the “crosswalk” link (maintained by OLIR or SCF) may NOT update. And the “mandates” link (from your regulator) may still reference the OLD version. Your evidence links break not because YOU did anything wrong, but because the chain upstream shifted.

---

The artifacts

Each entity type produces and consumes different artifacts:

Artifact	Produced by	Consumed by	Format	Evolution pattern
Framework	Standard body, Industry group	Everyone	Excel, CSV, PDF, OSCAL, STIX	Varies by publisher
Crosswalk	Mapping org, Standard body	Your org, GRC vendors	Excel, SSSOM, JSON	Often stale
Regulation	Regulator	Your org, Auditors	Legal text, PDF	Infrequent but binding
Evidence	Your org	Auditors	Policies, configs, screenshots, logs	Continuous
Assessment	Auditor	Your org, Regulator	Report, PDF, OSCAL	Point-in-time
Config	GRC vendor, Community	Your org	JSON, YAML, proprietary	Vendor-dependent

Crosswalker operates on frameworks (importing), crosswalks (linking), and evidence (the user’s notes). The other artifacts are context that informs handling strategy.

---

Real-world scenarios

Scenario 1: Financial institution

Bank adopting CRI Profile

Board / FS-ISACmandates →CRI Profile v2.0maps to →NIST CSF 2.0maps to →FFIEC CAT

The bank must prove compliance across ALL THREE simultaneously. Each has different examiners. Evidence for one control must trace through crosswalks to satisfy all three frameworks. When CRI updates, the CSF crosswalk may not update at the same time.

Scenario 2: Tech company

SaaS company with multiple compliance needs

Customersrequire →SOC 2+ →ISO 27001implemented via →CIS Controls

Different customers require different certifications. The company maps operational controls (CIS) to audit frameworks (SOC 2, ISO). Crosswalks between these are community-maintained — no single authority owns them.

Scenario 3: Government contractor

Defense contractor meeting CMMC

DoD / DFARSmandates →NIST 800-171derived from →NIST 800-53implemented via →DISA STIGs

The mandate flows from regulation (DFARS) through control frameworks (800-171, 800-53) to technical implementation (STIGs). Each layer has different maintainers and update cycles. STIG updates happen independently of 800-53 updates.

The pattern across scenarios

Every scenario shares the same structure:

1. A mandate (regulatory, contractual, or internal) requires framework adoption
2. The framework crosswalks to other frameworks the org also uses
3. Evidence must trace through crosswalks to satisfy multiple requirements
4. Each link in the chain has a different maintainer with a different update cycle
5. When any link updates, downstream links may break without notification

This is what Crosswalker’s Maintain phase addresses — tracking which links are stale and which evidence needs re-validation.

---

Analogies in other domains

The same institutional patterns exist beyond cybersecurity:

Domain	Standard body	Framework	Mapping org	Regulator
Cyber/GRC	NIST, MITRE	CSF, ATT&CK, 800-53	OLIR, SCF	SEC, FFIEC
Healthcare	WHO, AMA	ICD-10, SNOMED CT	UMLS	HHS, FDA
Financial	FASB, IASB	GAAP, IFRS, XBRL	None (direct regulation)	SEC, PCAOB
Scientific	Gene Ontology Consortium	Gene Ontology	OBO Foundry	None (peer review)
Web/Data	W3C, IETF	RDF, SKOS, Schema.org	LOV, BioPortal	None

The EvolutionPattern taxonomy is designed to work across all these domains — not just cybersecurity.

---

What this means for Crosswalker

The institutional landscape determines:

1. What EvolutionPattern fields matter — crosswalk_maintenance captures who maintains mappings; release_cadence captures how often the publisher updates
2. What metadata to track — which entity published the framework, when, and who maintains the crosswalks you’re using
3. What staleness detection to build — different entity types fail differently (publishers update on their schedule; mapping orgs may go silent)
4. What the community registry should capture — not just framework configs, but institutional context (who publishes, who maps, who mandates)

---

Resources

• Ontology evolution — the three-layer problem with actors model
• Framework versioning — how each framework handles updates
• Ontology lifecycle — the full lifecycle model
• For GRC teams — the evidence mapping problem
• Framework standards & tools — links to all frameworks and tools
• Terminology — entity type definitions