MP-2.3: AI system data sources are documented
Inventory + provenance for every training, fine-tune, RAG data source.
Last reviewed October 2026
Why MP-2.3 evidence is hard
Inventory and provenance for every training, fine-tune and retrieval source is a documentation control, and the one probe attached to it does not change that. Bring the AI-BOM export: each component with its discovery source, verification status and last-verified date, in JSON or CSV. Note there is no PDF variant - the evidence pack and the AI-BOM are different exports.
How Penaxtra maps to MP-2.3
NIST AI 600-1 asks what you measured and what you did about it. The MP-2.3 identifier rides the finding into the evidence export, and the append-only audit log carries the other half: which scans ran, against which assets, on what schedule. Every finding carries the probe that was sent, a SHA-256 digest of the response it provoked, the tier that decided the verdict and its status history from first observation to close. Identity survives a re-scan: a control you closed and that comes back reopens under the same row with a reopen count, rather than arriving as a new issue.
MP-2.3 capabilities
Findings tagged with the NIST AI 600-1 MP-2.3 identifier
Penaxtra severity for this control (high)
Cross-framework identifiers attached to the same finding where controls overlap
PDF and JSON evidence export with the control identifier attached
MP-2.3 control coverage
Findings for MP-2.3 carry the NIST AI 600-1 MP-2.3 identifier along with the corresponding control identifiers in the other frameworks Penaxtra maps, so one result is reflected across each mapped framework.
Frequently asked
What is MP-2.3 (AI system data sources are documented)?
Inventory + provenance for every training, fine-tune, RAG data source. It is a NIST AI 600-1 control; Penaxtra assesses it at high severity.
How does Penaxtra test for MP-2.3?
NIST AI 600-1 asks what you measured and what you did about it. The MP-2.3 identifier rides the finding into the evidence export, and the append-only audit log carries the other half: which scans ran, against which assets, on what schedule. Every finding carries the probe that was sent, a SHA-256 digest of the response it provoked, the tier that decided the verdict and its status history from first observation to close. Identity survives a re-scan: a control you closed and that comes back reopens under the same row with a reopen count, rather than arriving as a new issue.
Does a finding for MP-2.3 help with an audit?
Each finding is tagged with the NIST AI 600-1 MP-2.3 identifier and exported in the PDF and JSON evidence pack, so it appears on the auditor control list with the identifier already attached.