Tagged: GRC
Governance, Risk, Compliance concepts and workflows
Pages with this tag
Framework landscape
1Overview of common compliance frameworks and their data structures.
UI lexicon
2The canonical mapping from internal/KB vocabulary to what the plugin actually says on screen — and the rules that keep it that way.
Vision
3Crosswalker's product identity, operating model, machine-actionability, implementation horizon, and design principles.
Challenge 39: Is there a unified-model spine — and is it CRI?
4Stress-test the assumption that the unified risk/audit/GRC model has a single spine and that the spine is the CRI Profile. Evaluate spine candidates (CRI, SCF/STRM, NIST CSF 2.0, NIST 800-53, ISO 27001/27002, synthetic/derived) against coverage, sector-neutrality, mapping availability, license, and durability — and seriously consider hub-and-spoke, peer-mesh, and no-designated-spine alternatives. Foundational input to the unified-model shape and to ingestion sequencing.
Challenge 40: Control, risk, or obligation as the backbone entity?
5Decide what the unified model's nodes actually are — does everything hang off controls, risks, or obligations? Stress-test the implicit control-centric assumption against a risk-centric and an obligation-centric model, and determine whether the backbone is a single entity type or a small fixed set with typed edges. Feeds the unified-model shape and the Tier 1 schema.
Challenge 41: Is internal audit a spine element or a lens? (and what to name the model)
6Determine whether internal audit is a first-class structural element of the unified model or a consumer/lens over it — and let the model's name fall out of that decision. Weigh 'Unified Risk and Audit Model' against 'Unified Assurance Model', 'Unified GRC Model', and others. Naming follows structure, not the reverse.
Institutional ontology landscape — planning
7Planning the documentation of how institutions create, maintain, map, regulate, and consume ontologies — the human side of ontology evolution.
Institutional landscape decisions
8Decisions on how to document the institutional ontology landscape — layout, structure, tech approach, and scope.
Ontological foundations of the Unified Control Assurance and Risk Model
9A key foundations log defining the core categories of the security/GRC/risk/audit problem domains and how they relate — the five 'kinds of being' (objective, risk, obligation, control, audit/finding) as the foundation, structured around the three useful practitioner perspectives that name the model: Control (GRC-operational), Assurance (audit), and Risk (risk management). Covers the prudential-vs-deontic split, why obligation is broader than compliance (governance vs regulatory vs contractual source), why risk is the ontologically strangest category, and why control earns the center. Name chosen: Unified Control Assurance and Risk Model; remaining calls flagged open.
Use-case test — the GRC corpus end-to-end through Crosswalker
10A living end-to-end map of taking the downloaded GRC / audit / compliance framework corpus all the way through Crosswalker — ingest, parse, structure into Tier 1 concepts, crosswalk, and query into the unified ontology. The point is to see the whole pipeline at once, surface every applicable construct the tool already has, find the snags (most of the corpus is prose PDF), and decide what's worth building on top — toward the shareable community ecosystem. Disconnected pieces are fine for now; this is where they get connected.
The Unified Risk Model in practice — every question is a recipe
11The bridge from data morphology to the Unified Risk Model: one typed graph, three lenses (Control / Assurance / Risk), and a catalog of the real GRC questions each answers — every one decomposed into the same small set of moves (shape → transform → reshape → draw). Visualization-oriented (tool-agnostic). The opening of an end-to-end journey through Crosswalker on the GRC corpus.
The evidence closeout — a report that can say "nothing" and mean it
12Implements Challenge 45 §4.3. Withdraws the Bases evidence-gap view, which filtered a property no recipe emitted and therefore reported total non-coverage regardless of the vault. Moves the gap query to the SQL index, where a LEFT JOIN can report an absent relationship. Fixes the junction contract: subject is the control, object is the evidence, predicate is exactly has_evidence, matched by stable identity rather than wikilink text. Registers the evidence recipe. Corrects the GRC guide and the metadata-ecosystem page, both of which taught backlink counting. Adds tier2 to the recipe schema output targets.