MS-2.3: AI system performance is evaluated regularly
Continuous evaluation against benchmarks + drift detection.
Last reviewed October 2026
Why MS-2.3 evidence is hard
Regularly is the operative word, and it is the part a platform can hold up. Scans run on a schedule, and each run writes one row per probe attempted, carrying the verdict, the tier that decided it, latency, and a digest of the response. The 1,682 templates mapped to it make this the broadest entry in the NIST set. Benchmark accuracy and drift against your own targets are measured with your own tooling.
How Penaxtra maps to MS-2.3
NIST AI 600-1 asks what you measured and what you did about it. The MS-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.
MS-2.3 capabilities
Findings tagged with the NIST AI 600-1 MS-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
MS-2.3 control coverage
Findings for MS-2.3 carry the NIST AI 600-1 MS-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 MS-2.3 (AI system performance is evaluated regularly)?
Continuous evaluation against benchmarks + drift detection. It is a NIST AI 600-1 control; Penaxtra assesses it at high severity.
How does Penaxtra test for MS-2.3?
NIST AI 600-1 asks what you measured and what you did about it. The MS-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 MS-2.3 help with an audit?
Each finding is tagged with the NIST AI 600-1 MS-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.