What breaks when FAIR calculations live outside the system of record?

Why This Matters for Security Teams

When FAIR calculations sit outside the system of record, the organisation may still have a number, but it no longer has a defensible risk record. That matters because FAIR outputs are only as reliable as the assumptions, inputs, and control mappings behind them. If those elements live in spreadsheets, emails, or disconnected notebooks, change management becomes informal and auditability weakens. This is especially problematic when the calculation is used to justify treatment plans, budget priorities, or residual risk acceptance.

Security teams often underestimate how quickly an out-of-band model becomes stale. A control improvement, threat shift, or asset change can invalidate prior loss estimates without anyone noticing. The result is not just operational inefficiency, but governance drift: risk decisions continue to reference a calculation that no longer reflects the environment. NIST’s control guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it reinforces the need for managed records, accountability, and consistent control operation.

In practice, many security teams encounter the problem only after an audit, a board challenge, or a major incident forces them to reconstruct how a prior FAIR figure was produced.

How It Works in Practice

The core issue is lineage. FAIR works best when the inputs, assumptions, version history, and output are tied to the same governed record as the asset, control, or risk scenario being assessed. When calculations live elsewhere, teams have to manually reconcile what changed and when. That creates version drift, introduces transcription errors, and makes it harder to compare one assessment with another over time.

In operational terms, a system of record should preserve at least the following:

• scenario definition and scope
• asset or process owner
• assumptions for frequency and magnitude estimates
• control status and treatment decisions
• review dates, approvals, and recalculation history

This is where governance and data quality intersect. If FAIR outputs feed GRC reporting, threat prioritisation, or investment decisions, the calculation needs to be reproducible. The CIS Critical Security Controls are useful as an operational reference because they emphasise asset inventory, secure configuration, and control verification, all of which influence the quality of upstream risk inputs. The same logic applies to NIST Cybersecurity Framework 2.0, which expects risk management to be embedded into ongoing governance rather than treated as a one-time exercise.

Practically, mature teams either integrate FAIR into the risk register or maintain strong bidirectional links between the register and the model store. The goal is not just convenience. It is to ensure that any change in exposure, control effectiveness, or threat assumption can trigger a review of the prior result. These controls tend to break down in fast-moving environments with multiple spreadsheet owners and no enforced review workflow because there is no single authoritative place to detect when a prior estimate has become obsolete.

Common Variations and Edge Cases

Tighter governance around FAIR calculations often increases admin overhead, requiring organisations to balance reproducibility against analyst speed. That tradeoff is real, especially in teams that use FAIR for early-stage scenario exploration as well as formal risk reporting. Current guidance suggests that not every draft estimate needs full workflow rigor, but anything used for treatment approval, executive reporting, or audit evidence should be version-controlled and traceable.

There is no universal standard for exactly how much provenance is enough. Some organisations store calculations directly in the GRC platform, while others use a controlled repository with immutable links from the system of record. The right approach depends on how often scenarios change, how many analysts contribute, and whether the output needs to survive regulatory scrutiny. Where the FAIR model informs third-party risk, cloud security, or resilience planning, the need for traceability grows because downstream decisions can depend on the same assumptions for months.

The edge cases are usually integration-driven. If the system of record cannot store formulas, assumptions, and approval history, then the organisation needs a governed external store with clear identifiers and change logging. If neither exists, then the risk process becomes dependent on tribal knowledge. That is acceptable for informal analysis, but it is weak for evidence-based governance. The practical compromise is to treat the FAIR artefact as part of the controlled risk record, not as a detached analytical appendix.

Related resources from NHI Mgmt Group

• What breaks when model evidence is kept outside the artifact system?
• What breaks when candidate verification is kept outside the ATS or HR system?
• What breaks when organisations copy legacy access into a new ERP system?
• What breaks when AI identities are handled outside IAM?