Open formats: records that can leave the building
Most of the twenty-seven sources are prose: principles and steps that each organisation translates into its own fields, differently. Four publish a format a program can check. This page explains what that means for a risk professional, and then offers the files.
What a schema is, in plain words
A schema is the list of fields a record must have, with the type of each (a date, a number, one of a fixed set of values) and the rules they obey. When two organisations adopt the same idea, each designs its own table, and the two cannot be joined without a mapping that someone writes, maintains and gets wrong. When they adopt the same format, there is nothing to map: a record can leave the organisation, to a supervisor, an insurer, a parent or an auditor, and arrive meaning the same thing. A validator is a program that checks a record against the schema and says whether it conforms, so the check is run by software rather than argued in a meeting.
The files below are written in JSON, a plain-text format for structured data that any program can read: a record is a list of named fields and their values. Despite the name, it has nothing to do with programming in JavaScript; it is simply the common language for exchanging data between systems, the way PDF is for documents.
The four formats the framework adopts
| Object | Published by | What the framework does |
|---|---|---|
| Risk (register row and detail record) | NIST IR 8286 Rev. 1 [9]: eleven fields for the row, thirty-four for the detail record, as JSON schemas | Adopts the schema whole (component C6.1) and adds its own fields as extensions, so a row stays valid under the base schema |
| Event (loss event, near miss, incident) | FSB Format for Incident Reporting Exchange, FIRE [27]: eighty-seven items in four sections | One incident record for cyber, operational and third-party events (C5.4) |
| Hazard | UNDRR/ISC Hazard Information Profiles [24]: 281 hazards with persistent identifiers | A controlled vocabulary every identification exercise consults (C2.5) |
| Software component | CISA SBOM minimum elements [15] | The component beneath the supplier, with the rule that gaps are declared as gaps (C2.7) |
The five the framework proposes
No open schema exists for an objective, a control, a scenario, an indicator or an assurance activity: the things an organisation does about risk rather than what happens to it. The framework publishes draft schemas for the five, shaped like the four that exist, with the attributes of Table 19.1 of the book. They stay proposals until someone other than the author has used them in a running register; if you have, tell us.
A worked example, read field by field
This is the payments risk of chapters 17 and 18 of the book, PAY-014, as a register row with the framework's extensions. The first block is the published NIST row: identifier, the validated statement as description, category, likelihood, impact, exposure, response, cost, owner and status. The crmf block carries what the framework adds: the statement broken into its four parts, the taxonomy node, the tier, the consequence against each objective, the precision of the likelihood, the three snapshots of exposure (inherent, expected, measured), the actual cost of the response, the named decider, the Action Priority band, and the versions the row was scored under.
{
"id": "PAY-014",
"description": "Given that beneficiary details for high-value payments are verified by a telephone callback performed from memory under cutoff pressure, there is a possibility that a payment is released to a fraudulent or mistaken beneficiary, affecting the corporate payments service, with an unrecoverable loss and a late payment for the client.",
"category": "Process execution › manual verification",
"likelihood": 3,
"impact": 4,
"exposure": 12,
"response_type": "mitigate",
"response_cost": 420000,
"response_description": "Selection report SR-2026-07: beneficiary verification block and automated matching.",
"owner": "Head of payment operations",
"status": "in progress",
"crmf": {
"validated_statement": {
"condition": "beneficiary details for high-value payments are verified by a telephone callback performed from memory under cutoff pressure",
"departure": "a payment is released to a fraudulent or mistaken beneficiary",
"asset": "the corporate payments service",
"consequence": "an unrecoverable loss and a late payment for the client"
},
"taxonomy_node": "process execution / manual verification",
"process": "corporate payments",
"tier": "process",
"consequence_per_objective": [
{
"objective_id": "OBJ-PAY-ACCURACY",
"consequence": 4
},
{
"objective_id": "OBJ-PAY-TIMELINESS",
"consequence": 2
},
{
"objective_id": "OBJ-CLIENT-TRUST",
"consequence": 3
}
],
"likelihood_precision": "estimated from two internal events and one peer case",
"scale_version": "bank-scale-2026.1",
"exposure": {
"inherent": 1800000,
"expected": 300000,
"measured": 150000
},
"response_cost_actual": 510000,
"decider": "Head of payment operations",
"opportunity": false,
"action_priority": "H",
"scored_under": {
"criteria_version": "2026.1",
"catalog_version": "1.0"
}
}
}The files
| File | What it is |
|---|---|
| register-row-extensions.schema.json current | The framework's extension fields to the NIST register row |
| objective.schema.json proposal | Objective: tier, appetite position, tolerance, aggregated likelihood of being missed |
| control.schema.json proposal | Control: hierarchy level, mode, human dependence, decay, measured effectiveness, designer and assurer |
| scenario.schema.json proposal | Scenario: the triplet with uncertainty, variant, technique, versioned inputs |
| indicator.schema.json proposal | Indicator: leading or lagging, threshold, breach record, data lineage |
| assurance-activity.schema.json proposal | Assurance activity: line, provider, reliance, twelve-month safeguard, opinion |
| PAY-014.json | The worked example above |
Schemas are released under CC0 1.0 so that nothing stands between an implementer and the file. Every record carries the schema version it validates against and the catalog version it was scored under.