What Evidence Shows Approval Authority Is Operating?

Define the control objective and evidence chain

Write the control objective in observable terms: governed actions occur only after a current, authorized decision for the exact object and scope; qualified conditions and expiries are enforced; rejected, changed, or expired requests cannot proceed. Name the accountable control owner and the period being tested.

Build a four-link evidence chain for every sampled event:

NIST’s AI RMF Core says roles, responsibilities, lines of communication, leadership responsibility, and human-AI oversight should be documented. This supports the design expectation, but documentation does not by itself demonstrate operation. Evidence must connect a dated rule to actual decisions and actions.

• Request: stable request ID, decision type, object version or hash, scope, requester, date, and required evidence.
• Authority: current authority-matrix row, role assignment, threshold, delegation record, conflicts, and expiry at decision time.
• Decision: approver identity, timestamp, evidence reviewed, rationale, conditions, residual issues, and decision status.
• Enforcement: release, access, configuration, transaction, or workflow record showing that execution matched the decision.

Sources: [1]

Test the population before sampling

Obtain the complete population of governed requests and independently reconcile it to execution records. Include approvals, rejections, withdrawals, exceptions, expired requests, emergency decisions, and actions that occurred without a visible request. Reconcile counts and unique identifiers across the request system, decision log, identity or role register, deployment or transaction system, and exception register.

Investigate unmatched items before selecting a sample. If the decision log contains 47 records but the execution system shows 51 governed changes, sampling only the 47 logged decisions would hide the most important failure. Preserve the extraction time, query, filters, fields, row count, source owner, and hash for each population file.

Select every high-consequence, emergency, delegated, conditional, changed, and threshold-adjacent event. Add a representative sample across decision types, approvers, systems, and time periods. Define the sample rule before seeing the results and keep the full exception population.

Examine, interview, and test each event

The current NIST SP 800-53A Revision 5 provides customizable control-assessment procedures and frames assessment methods around examination, interviews, and tests. Its federal security and privacy context must be tailored; using its methods does not make this review a federal assessment or certification.

Examine the authority record and decision packet. Confirm that the approver held the named role on the decision date, the amount, data class, geography, use case, duration, and risk level were within scope, and any delegate had an active delegation. Compare the packet’s object version with the executed version. Interview the approver and operator where records are ambiguous, but do not let recollection replace missing evidence. Test workflow behavior using controlled cases: absent approver, expired delegation, changed object, breached threshold, conflicting specialist advice, and expired condition.

Classify exceptions by link: missing request, invalid authority, incomplete decision, or enforcement mismatch. Also record root-cause hypotheses, affected population, immediate containment, owner, due date, and retest evidence. One passed workflow test cannot compensate for an unreconciled population.

Sources: [2]

Worked operating-evidence test

Suppose a synthetic organization requires approval before an AI assistant can access a new data class. The quarter’s request system contains 31 decisions: 22 approvals, four conditional approvals, three rejections, and two withdrawals. The connector platform records 33 new data-class configurations.

Reconciliation finds two configurations without request IDs. One is a test tenant correctly covered by a standing low-risk authorization but missing the required cross-reference. The other enabled confidential support notes under an approval limited to public knowledge articles. It is an enforcement mismatch and a scope breach, not a paperwork observation.

Risk-based testing covers all four conditional approvals, the standing authorization, three threshold-adjacent decisions, and six routine approvals. One conditional approval required deletion after 30 days, but the storage record shows deletion on day 38. Another request was approved by a delegate two days after the delegation expired. The latter configuration was never enabled because the workflow rejected it, showing that enforcement worked even though the decision record was invalid.

The reviewer cannot conclude that approval authority operated without exception. The disposition is qualified: the workflow blocked an expired delegate, but population reconciliation exposed one out-of-scope configuration and one late condition. The control owner disables the configuration, opens an incident review, adds request-ID validation to the connector workflow, and schedules a complete-population retest after remediation.

Conclude, remediate, and retest

Use clear dispositions. Pass means the reconciled population and performed tests support the stated control objective for the period, subject to recorded limits. Qualified means exceptions are bounded and the conclusion names their effect. Fail means missing population evidence, invalid authority, material scope mismatch, or unenforced conditions prevent reliance. Not assessable means evidence is too incomplete to conclude.

The evidence bundle should contain the control objective, owner, approved authority matrix, role history, delegation register, source manifests, reconciled population, sample rationale, tested event records, interview notes where used, workflow-test results, exception log, containment, remediation, approval of the conclusion, and dated retest. Bind records to stable IDs and hashes where feasible. Track repeat exceptions across periods because a closed ticket does not prove the underlying cause was removed.

The NIST RMF authorize step describes a senior official making a risk-based authorization decision from an authorization package and recording terms and conditions. Use it as an evidence-packet reference, not as a claim that ordinary organizational approvals are authorizations to operate.

Two Prune can simulate an approval-evidence review and observe how a participant reconciles records, checks authority, tests conditions, uses AI support, and communicates exceptions. That assessment evidence concerns observed performance in the simulation. It is not a security audit, legal opinion, control attestation, compliance determination, or automated employment decision.

Sources: [3]