MG-3.2: Risks are tracked through to remediation
Open findings reach a documented terminal state.
Last reviewed October 2026
Why MG-3.2 evidence is hard
This is the control the finding lifecycle was rebuilt for. Every issue keeps one identity across scans. Closing it and then seeing it again reopens the same row with a reopen count and a reason, rather than minting a new one and discarding the triage. Accepted risks stay accepted and suppressed on re-observation, because silently reopening them erases the evidence of a decision. Mean time to remediate runs first-seen to close, and the count an assessor is shown is distinct issues rather than observations.
How Penaxtra maps to MG-3.2
NIST AI 600-1 asks what you measured and what you did about it. The MG-3.2 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.
MG-3.2 capabilities
Findings tagged with the NIST AI 600-1 MG-3.2 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
MG-3.2 control coverage
Findings for MG-3.2 carry the NIST AI 600-1 MG-3.2 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 MG-3.2 (Risks are tracked through to remediation)?
Open findings reach a documented terminal state. It is a NIST AI 600-1 control; Penaxtra assesses it at high severity.
How does Penaxtra test for MG-3.2?
NIST AI 600-1 asks what you measured and what you did about it. The MG-3.2 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 MG-3.2 help with an audit?
Each finding is tagged with the NIST AI 600-1 MG-3.2 identifier and exported in the PDF and JSON evidence pack, so it appears on the auditor control list with the identifier already attached.