GV-3.2: Accountability for AI risk is established
Designate accountable roles for AI risk management decisions.
Last reviewed October 2026
Why GV-3.2 evidence is hard
Somebody has to own the decision when a critical finding is accepted rather than fixed. That naming happens in your governance structure, not in a scan. What the platform records is the consequence of the decision: who moved a finding into the accepted-risk register, when, and under which account, in an append-only log. Accountability is evidenced by the roster; adherence to it, partly by the trail.
How Penaxtra maps to GV-3.2
NIST AI 600-1 asks what you measured and what you did about it. The GV-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.
GV-3.2 capabilities
Findings tagged with the NIST AI 600-1 GV-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
GV-3.2 control coverage
Findings for GV-3.2 carry the NIST AI 600-1 GV-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 GV-3.2 (Accountability for AI risk is established)?
Designate accountable roles for AI risk management decisions. It is a NIST AI 600-1 control; Penaxtra assesses it at high severity.
How does Penaxtra test for GV-3.2?
NIST AI 600-1 asks what you measured and what you did about it. The GV-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 GV-3.2 help with an audit?
Each finding is tagged with the NIST AI 600-1 GV-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.