AU-10(3): Chain of Custody

AU-10(3) requires you to keep verifiable reviewer or releaser credentials embedded in your information release chain of custody, so you can prove exactly who reviewed or approved a disclosure and under what authority. Operationalize it by instrumenting workflows (ticketing, CI/CD, eDiscovery, data export) to capture approver identity, role, and decision records, then retaining that evidence with the released content’s audit trail.

Key takeaways:

• Capture “who approved/reviewed this release” as tamper-evident, queryable evidence tied to each release event.
• Enforce role-based approval rules and separation of duties for high-risk releases, then record exceptions.
• Retain an evidence bundle (request, content hash, approvals, identity attributes, timestamps, distribution list) mapped to your retention schedule.

AU-10(3): Chain of Custody is a narrow requirement with a high operational payoff: it forces you to treat “review and release” as a controlled, auditable event, not an informal act performed over email or chat. The control enhancement sits in the Audit and Accountability family and is usually tested when a system generates outputs that leave a security boundary: log exports, incident reports, data extracts, regulatory filings, legal productions, customer data portability responses, vulnerability disclosures, and even public statements pulled from internal systems.

For a Compliance Officer, CCO, or GRC lead, the fastest path is to pick the release paths that matter, define what “reviewer or releaser credentials” mean in your environment, and hardwire those identity attributes into the workflow tools your teams already use. You are aiming for two outcomes: (1) only authorized people can approve a release, and (2) you can prove, later, who approved it and why, with evidence that stands up to audit scrutiny.

This page translates AU-10(3) into an operator runbook: applicability, step-by-step implementation, required artifacts, audit traps, and a practical execution plan that fits real teams and real tooling.

Regulatory text

Requirement (AU-10(3)): “Maintain reviewer or releaser credentials within the established chain of custody for information reviewed or released.” ¹

What the operator must do

You must ensure that every time information is reviewed for release or approved for release, the chain-of-custody record includes the credentials/identity attributes of the person(s) who performed that review or approval. In practice, “credentials” means you can tie the action to an authenticated identity (human or approved service identity), their role/authorization, and the approval decision record, and you can retrieve that evidence later.

This is not a generic “have audit logs” requirement. It is specifically about release governance: the reviewer/releaser’s identity has to be part of the chain-of-custody for the released information, not scattered across inboxes, chat threads, or unstructured notes. ²

Plain-English interpretation (requirement-level)

If your system or organization outputs information, you need a defensible answer to:

• Who reviewed it?
• Who approved releasing it?
• Were they authorized at the time?
• What exactly was released (version/content fingerprint)?
• Where is the record showing that linkage?

“Within the established chain of custody” means the credentials must be captured in the same auditable workflow that defines the custody trail for the information. A screenshot of a Slack message approving an export is weak evidence because it is not reliably tied to the content released, is hard to retain under recordkeeping controls, and is easy to spoof or lose.

Who it applies to (entity and operational context)

AU-10(3) is commonly applied in:

• Federal information systems and contractor systems handling federal data where NIST SP 800-53 is in scope. ³
• Teams with controlled release paths such as Security Operations (for incident reporting), Legal (for productions), Privacy (for DSAR/data portability), Engineering (for deployment artifacts and release notes tied to system behavior), and Compliance (for attestations and regulator responses).

Operationally, it applies wherever you have:

• Outbound disclosures: data extracts, reports, regulated submissions, third-party transfers, customer deliveries.
• High-impact internal releases: privileged audit logs to analysts, vulnerability details to engineering, forensics images to third parties.
• Automated release pipelines: CI/CD and publishing systems that push artifacts externally.

What you actually need to do (step-by-step)

Step 1: Define “release events” and put them in scope

Build a short list of release event types that matter. Use a table like this:

Release event type	Example	Primary system of record	Risk notes
Data export	CSV extract of customer records	Ticketing + data platform logs	High privacy/regulatory impact
Incident reporting	Incident summary sent to customer/regulator	IR platform + GRC	Needs defensible approvals
Legal production	eDiscovery export	Legal hold/eDiscovery tool	Chain-of-custody expectations
Log disclosure	Export SIEM logs to third party	SIEM + ticketing	Sensitive security telemetry
Software artifact release	Container/image pushed to registry	CI/CD + artifact repo	Supply chain integrity

Your goal is not to model every email attachment. Start with the release paths that are repeatable, material, and auditable.

Step 2: Define “reviewer or releaser credentials” for your environment

Minimum set to record per reviewer/releaser action:

• Authenticated identity (user ID tied to SSO/IdP)
• Name (display name) and unique identifier
• Role/group at time of approval (or reference to RBAC policy)
• Approval decision (approved/rejected) and any required rationale
• Timestamp and workflow record ID

Where possible, store the IdP immutable identifier (for example, the directory object ID) so name changes do not break traceability.

Step 3: Establish (or document) the chain-of-custody workflow

Pick the workflow that constitutes “chain of custody” for each release type:

• Ticketing workflow (ServiceNow/Jira) for requests and approvals
• eDiscovery/legal platform for productions
• CI/CD pipeline approvals for artifact releases
• GRC workflow for formal submissions

Then document the lifecycle states and required approvers per state (draft → reviewed → approved → released). Keep it short and enforceable.

Step 4: Enforce authorization checks at the point of release

Design approvals so the system blocks release unless:

• The approver is in an authorized group/role for that release type
• Required separation-of-duties is met for higher-risk releases (example: requestor cannot be final approver)
• Exceptions require explicit documentation and a secondary approver

Don’t rely on policy alone. Put a technical or workflow gate in the tool that executes the release.

Step 5: Bind the approval record to the exact content released

This is where teams fail audits. You need to tie approvals to what was released, not just that something was released.

Practical approaches:

• Store a content hash (or immutable artifact ID/version) in the ticket or release record.
• For database extracts, store the query identifier, dataset name, export job ID, and output file checksum.
• For documents, store the document management version ID and a PDF hash at the time of release.

Step 6: Centralize retention and retrieval (evidence must be findable)

Define where the evidence lives:

• The system of record for the workflow (ticketing, eDiscovery, CI/CD) retains the approval metadata.
• A compliance evidence repository retains snapshots/exports needed for audits, with access controls and retention rules.

If your auditors ask “show me three examples,” you should be able to retrieve them quickly by searching release type, date range, and approver.

Step 7: Run control health checks

Operate AU-10(3) like a control, not a project:

• Sample releases periodically.
• Verify that each sampled release has: request, approver credentials, content binding, timestamps, and distribution/destination details.
• Track exceptions to closure with corrective actions.

A lightweight way to run this is a recurring control test with documented results and remediation tracking.

Required evidence and artifacts to retain

Build a minimum evidence bundle per release event:

1. Release request record (ticket/case ID, requestor, business justification)
2. Approval workflow record (approver credentials, role, decision, timestamps)
3. Content identifier (hash/version/artifact ID/export job ID)
4. Release execution evidence (system log entry, pipeline run ID, transmission record)
5. Recipient/destination (distribution list, endpoint, third party name, method)
6. Exception record (if bypassed, who authorized the bypass and why)
7. Retention location and retention rule reference (where stored, how long retained)

Store these artifacts so they are tamper-evident and access-controlled. The chain-of-custody story collapses if many people can edit or delete approval history.

Common exam/audit questions and hangups

Auditors and assessors tend to focus on these points:

• “Show me the chain of custody for a specific release.” They will pick a real event and expect you to walk from request → review → approval → release → recipients.
• “How do you know the approver was authorized at the time?” Expect questions about role membership history and how approvals are gated.
• “Where are the credentials stored?” “In email” is rarely acceptable; they want it in the workflow record. ¹
• “How do you prevent tampering?” They will ask who can edit approvals, delete tickets, or alter artifacts.
• “What about automated releases?” You must show controlled service identities and approvals where required.

Frequent implementation mistakes and how to avoid them

Mistake 1: Treating “credentials” as a typed name in a comment

Fix: Require approvals via authenticated workflow actions (approval button, electronic signature, gated pipeline step) tied to SSO identity.

Mistake 2: Approvals exist, but they aren’t tied to the exact released content

Fix: Add a required “content ID” field (hash/version/export job ID) and make release execution populate it automatically where possible.

Mistake 3: Release happens outside the chain-of-custody system

Teams approve in Jira, then someone sends the file via email with no logged linkage. Fix: Require the release mechanism to reference the ticket/case ID, or route the release through an integrated tool (secure file transfer portal, eDiscovery export function, governed data export service).

Mistake 4: No exception handling

Emergency releases happen, and nobody records why controls were bypassed. Fix: Define an emergency path with required approver credentials and retrospective review.

Mistake 5: Evidence exists but is not retrievable

Evidence spread across tools with inconsistent naming breaks audits. Fix: Standardize naming conventions and maintain an evidence index (even a simple register) that points to where evidence is stored.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for AU-10(3), so you should treat this as a control that is typically evaluated through assessments, audits, and customer due diligence, rather than a control that has a predictable, control-specific enforcement playbook in public records.

Risk-wise, AU-10(3) failures usually surface as:

• Inability to prove that disclosures were authorized
• Disputes over who approved a release
• Weak incident response defensibility
• Increased legal/regulatory exposure during investigations because record integrity is unclear

A practical 30/60/90-day execution plan

First 30 days: Get to a defensible baseline

• Appoint an owner for each release event type (Security, Legal, Privacy, Engineering).
• Define your “reviewer/releaser credentials” schema (identity, role, timestamp, decision).
• Inventory top release workflows and pick the system of record per workflow.
• Create a control card/runbook: trigger events, steps, exception rules, and evidence bundle.

Days 31–60: Instrument workflows and start capturing evidence

• Configure approval steps in ticketing/CI/CD/eDiscovery so approvals capture authenticated identity and are non-editable (or tightly restricted).
• Add content-binding fields (artifact ID, export job ID, hash) and make them required.
• Establish an evidence repository and a retrieval procedure (who can pull what, how fast, and from where).
• Pilot sampling: pull a small set of real releases and test whether you can reconstruct custody end-to-end.

Days 61–90: Operationalize control testing and close gaps

• Formalize periodic control health checks with documented results and tracked remediation.
• Harden access controls: limit who can modify/close tickets, delete artifacts, or change approvals.
• Create an exception review cadence with named approvers and documented outcomes.
• Prepare an “audit-ready” packet with multiple example release chains and a one-page narrative of how the control works.

Where Daydream fits (earned, practical)

If you struggle to keep the control card, evidence bundle definition, sampling results, and remediation tracking consistent across multiple release paths, Daydream can act as the control system of record for AU-10(3) operations: a single place to document the runbook, define the minimum evidence bundle, schedule control health checks, and track issues to validated closure.

Frequently Asked Questions

What counts as “reviewer or releaser credentials” for AU-10(3)?

Use authenticated identity attributes that reliably map to a person or approved service account, plus the role/authorization context and the approval action record. The record should live in the workflow chain of custody, not in informal communications. ¹

Do we need cryptographic hashes for every released item?

AU-10(3) does not explicitly mandate hashes, but you must bind the approval to the specific content released. Hashes, immutable version IDs, or export job IDs are practical ways to create that binding.

How do we handle approvals given in email or chat?

Treat email/chat as a request intake channel, then require the actual approval to occur in the system of record (ticketing, eDiscovery, CI/CD) where the approver’s authenticated credentials are captured and retained.

Does AU-10(3) apply to automated releases from CI/CD pipelines?

Yes, if the pipeline releases information or artifacts, you need an auditable chain that includes who authorized the release and the identity of the account that performed it. Use gated approvals and controlled service identities tied to the pipeline run.

What if the same person must request and approve in a small team?

Document the constraint and implement compensating controls: second-person review for high-risk releases when available, manager attestation, or retrospective review with documented approver credentials and rationale.

How much retention is required for AU-10(3) evidence?

NIST 800-53 does not set a universal retention duration in AU-10(3). Align retention to your organizational recordkeeping requirements, contract obligations, and system audit log retention, and ensure you can retrieve evidence for sampled periods during assessments. ³

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON

2. NIST SP 800-53 Rev. 5; Source: NIST SP 800-53 Rev. 5 DOI

3. NIST SP 800-53 Rev. 5