Unified risk model (for risk & GRC teams)

Note

Audience: risk, GRC/ISRM, internal-audit, and compliance teams. This is a recommended implementation of Crosswalker for a specific domain — not a universal Crosswalker concept (Crosswalker is a general ontology-lifecycle-management system; this is one applied use). Per-role entry points: internal audit · GRC / ISRM (operational compliance) · regulatory compliance.

Tip

The unifying answer to “which tool should each team use?” is not a single product — it’s a shared data model. Whatever tools internal-audit, GRC/ISRM, and compliance pick, if they all expose the same core entities with real relationships, the teams stay relatable instead of running three disconnected databases (or three spreadsheets pretending not to be). This page describes that model. Crosswalker is one way to implement it; so are the related tools.

Caution

Two senses of “compliance” — keep them distinct. Obligation-centric (regulatory) compliance — tracking laws + reg changes (Reg E/Z, BSA/AML, UDAAP) — is a different job from control-centric (operational) compliance — maintaining a control library + framework crosswalks. Crosswalker is a control-centric tool. In the table below, the “Compliance” column is the regulatory team’s control-mapping touchpoints — their obligation-tracking system itself lives elsewhere. See control-centric vs obligation-centric compliance and for regulatory compliance.

The problem this solves

In a regulated org, internal audit, GRC/ISRM, compliance, and third-party risk each own slices of the same reality — the same controls, frameworks, assets, vendors, processes, findings, and evidence — but their tools model that reality differently (or not relationally at all). The result is duplicated control libraries, crosswalks maintained in ad-hoc spreadsheets, and a reg change that nobody can trace to the controls it affects.

A unified risk model (sometimes “unified operational risk model” / URO) fixes this by defining one set of shared entities + relationships that every team operates on through its own front-end — IA in an audit engine, compliance in a reg-CMS, ISRM in a control spine — over the same underlying objects.

CRI Profile as the spine

For a financial institution, CRI Profile is the authority-of-record for the GRC/InfoSec team. Every other framework crosswalks to it (NIST CSF 2.0, 800-53, ISO 27001, FFIEC, NCUA) via a standards-based method (OLIR or STRM) so the relationships are auditable and survive framework version changes.

The two load-bearing joints are the control and the crosswalk: a single control hangs off one or more CRI diagnostic statements, and because CRI is crosswalked to the other frameworks, that one control plus its evidence automatically answers them too — assess once, comply many.

Note

CRI-at-center is the FI default. The same model works with any top-of-house authority — swap CRI for whichever framework your domain treats as canonical (e.g. a biomedical ontology, a library taxonomy). The structure is general; the spine is a choice.

The shared entities

Per-team role on each shared entity — Owns = system-of-record · Uses = active (creates/updates) · Reads = consumer/reference · – = minimal. Entity definitions follow the table.

Shared entity	Internal Audit	Compliance	GRC / ISRM
Authority / Framework	Reads	Uses	Owns
Requirement / Diagnostic Statement	Reads	Uses	Owns
Control (reference + applied)	Uses (tests)	Uses (relies on)	Owns
Risk / Risk Scenario	Uses (planning)	Reads	Owns (ERM co-owns)
Asset	Reads	Reads	Owns (with IT)
Vendor / Third Party	Reads	Reads	Uses (security review; TPRM owns)
Business Function / Process (BIA)	Reads	Reads	Uses (BCP/business owns)
Assessment (risk / audit / vendor)	Owns (audit)	Uses (compliance)	Owns (risk)
Finding / Issue	Owns (audit)	Uses	Uses
Evidence	Uses	Uses	Owns (collect once)
Incident	Reads	Reads	Owns (with SecOps)

Entity definitions + CRI tie:

• Authority / Framework — CRI Profile + crosswalked CSF 2.0 / 800-53 / ISO 27001 / FFIEC / NCUA. The spine: CRI is top-of-house; all others map to it.
• Requirement / Diagnostic Statement — testable line items under each authority. CRI diagnostic statements are the canonical cyber requirement set.
• Control — reusable control library vs. its real implementations. One control satisfies many CRI statements + crosswalked requirements — the “assess once, comply many” joint.
• Risk / Risk Scenario — threat × impact to an asset/process. Risks tag the CRI function/category they threaten.
• Asset — data, systems, facilities you protect. Scoping: defines where CRI controls apply.
• Vendor / Third Party — external entities + their services. Vendor controls assessed vs. CRI-derived requirements.
• Business Function / Process (BIA) — critical processes + tolerances (RTO/RPO). Criticality drives control rigor (CRI Govern/Identify).
• Assessment — a point-in-time evaluation (risk / audit / vendor). Measures adherence to CRI requirements/tiers.
• Finding / Issue — a gap and its remediation. Maps back to the CRI requirement/control that failed.
• Evidence — proof a control operates. Proves CRI controls; reused across every crosswalked framework.
• Incident — a realized event. Maps to CRI Respond/Recover; feeds risk updates.

How it operates

• Internal Audit doesn’t get a separate control universe — its tests point at the shared control objects and write back to the shared finding register.
• Compliance keeps its own obligation-tracking system, but maps each regulatory obligation down to the same controls, so a reg change surfaces exactly which controls and evidence are affected. (This is obligation-centric compliance connecting to the control-centric spine.)
• GRC/ISRM owns the spine (authorities, requirements, controls) and the evidence — collected once, reused everywhere.
• Nobody owns everything; each team Owns the entities it’s accountable for and Reads the rest — which is what keeps it relatable.

How this relates to formal governance models

The unified risk model is a data / ontology model — what the shared objects are and how they relate. That’s a different (and complementary) axis from the accountability models that say who is responsible for what. The unified model is the substrate those governance models run on:

Model	What it governs	Relationship to the unified risk model
IIA Three Lines Model (formerly “Three Lines of Defense”)	Accountability: 1st line = operational management (owns/manages risk); 2nd line = risk + compliance oversight; 3rd line = internal audit (independent assurance)	The unified model gives all three lines one shared set of entities to act on — 1st line operates controls, 2nd line oversees them, 3rd line audits them, all pointing at the same control + finding objects instead of separate databases. Note: the Three Lines is about who, not what data — it does not map to the control-vs-obligation tooling distinction.
COSO ERM / COSO Internal Control	Enterprise risk + control framework principles	The risk, control, and assessment entities here are the objects a COSO program populates.
NIST RMF (SP 800-37)	The lifecycle: categorize → select → implement → assess → authorize → monitor	The model’s controls, assessments, evidence, and findings are the RMF lifecycle’s working set; CRI/CSF/800-53 are the catalogs it draws from.

Note

Don’t confuse the IIA Three Lines Model (a formal accountability structure: 1st/2nd/3rd line) with the informal control-centric vs obligation-centric tooling distinction. They’re orthogonal — one is about who’s responsible, the other about what a tool’s atomic unit is.

Where Crosswalker fits

Crosswalker implements the control + crosswalk core of this model as plain-text notes: concept notes (controls / requirements / framework items), junction notes (the crosswalk edges with typed STRM relationships), and queries/views (coverage matrices, gap analyses) over them. It is not a full GRC platform — it’s the relatable backbone the model needs, owned by you in markdown. The teams’ other functions (reg-CMS, audit workpapers, TPRM questionnaires) live in related tools that connect at the shared control.

How to evaluate whether any tool fits this model (the test to apply to every candidate):

1. Do risks, controls, requirements, assets, vendors, processes, findings, evidence exist as first-class related objects — not free-text fields?
2. Can one control map to two frameworks simultaneously with evidence reuse?
3. Does it import/export OSCAL and/or use OLIR/STRM crosswalk semantics?
4. Can a control relate to many risks/assets/authorities (many-to-many)?

Tools that force a rigid audit-only or vendor-only schema fight the model; tools with a configurable, relationship-rich core align with it.

Related

• Related tooling (GRC, audit, compliance, risk) — the tools each team uses + where Crosswalker fits
• What makes Crosswalker unique — the plain-text-ownership differentiator
• Hierarchy primitives · Query primitives — how the model is emitted + queried
• Institutional landscape — who creates/maintains/mandates the authorities the spine points at
• Terminology — concept note, junction note, crosswalk edge, evidence link
• Registry: CRI · OLIR · STRM · OSCAL · SSSOM
• Framework corpus + tooling checkpoint — the working doc for building a real corpus toward this model