AU-10(3): Chain of Custody

AU-10(3) requires you to preserve the identity (credentials) of every reviewer and releaser as part of the chain-of-custody record for information that is reviewed or released. Operationally, that means your logging, workflow, and evidence retention must prove “who approved what, when, under what authority,” and keep that linkage intact from creation through release. ¹

Key takeaways:

• Treat reviewer/releaser credentials as chain-of-custody data that must stay attached to the record, not as “nice-to-have” workflow metadata. ¹
• Implement enforced approvals (not email) and immutable audit trails that bind content/version, decision, timestamp, and identity. ¹
• Keep evidence that an assessor can replay: request → review → approval/release → distribution, with reviewer/releaser credentials preserved. ¹

AU-10(3): Chain of Custody sits in the audit and accountability family, but it is really a release-governance requirement. If your organization publishes, shares, exports, posts, transmits, or otherwise “releases” information, you need a defensible chain-of-custody record that retains the credentials of the people who reviewed and released that information. ¹

This requirement becomes concrete in high-friction workflows: security exception approvals, system authorization artifacts, customer data extracts, vulnerability reports, incident communications, public statements, regulatory submissions, and any distribution of controlled information to a third party. In those workflows, assessors commonly ask a simple question: “Show me who approved this release and prove the approval wasn’t altered later.” AU-10(3) is your answer, but only if you build it into the tooling and evidence model, not just a policy statement. ¹

The goal of this page is to help a Compliance Officer, CCO, or GRC lead operationalize the au-10(3): chain of custody requirement quickly: define scope, select a control pattern, implement workflow and logging, and retain artifacts that survive audits and incident response. ²

Regulatory text

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

Operator meaning

• You must keep the reviewer’s or releaser’s credentials (the identity attributes your organization relies on to authenticate and authorize that person) inside the chain-of-custody record for the information item being reviewed or released. ¹
• “Within the chain of custody” means the credentials are persistently linked to the specific information, version, and approval event, so you can later prove which credentialed identity performed the action. ¹

Plain-English interpretation (what AU-10(3) is really asking)

AU-10(3) expects a durable, reviewable trail that ties together:

1. the information (and its version),
2. the review/release decision, and
3. the credentialed identity of the reviewer or releaser. ¹

If you cannot show “this exact artifact was released by this credentialed person through an approved process,” your chain of custody is incomplete for AU-10(3), even if you have some logs somewhere. ¹

Who it applies to (entity and operational context)

Entities

• Federal information systems implementing NIST SP 800-53 controls. ²
• Contractor systems handling federal data, where 800-53 controls are flowed down contractually or required for an authorization boundary. ²

Operational contexts (where you scope it)

Scope AU-10(3) to “information that is reviewed or released” where identity and release authority matter, such as:

• Security-relevant releases: incident notifications, vulnerability disclosures, advisory postings.
• Data releases: exports, extracts, reports, or transfers to a third party.
• Authorization and compliance artifacts: SSPs, POA&Ms, assessment reports, ATO packages, boundary diagrams shared outside the team.
• Policy/communications releases: statements that represent the organization and require approvals.

A practical scoping method: start with systems and workflows where a mistaken or unauthorized release would create confidentiality, integrity, or non-repudiation risk, then expand. ¹

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

Step 1: Define “reviewer/releaser credentials” for your environment

Decide what counts as “credentials” in your chain-of-custody evidence:

• Unique user identity (human or service account)
• Authentication source (IdP) and immutable identifier (subject ID), not just display name
• Role/entitlement at time of approval (where feasible)
• MFA status and method (if your logs capture it)

Your goal is assessor-friendly identity evidence that maps back to a controlled authentication system. ¹

Step 2: Identify “release events” and force them into a controlled workflow

List the release pathways for in-scope information:

• Ticketing/workflow tools (change management, exceptions, approvals)
• Document management systems
• CI/CD or code review systems (for releases of configuration/code artifacts)
• Data platforms (exports, shares)
• Email/manual transfers (high risk)

Then choose a rule: no release without an auditable approval record. For manual pathways, your compensating control is to route approval through a system that logs approver identity and the exact object released. ¹

Step 3: Bind identity + object + decision + time into a tamper-resistant record

For each in-scope release:

• Assign a unique artifact ID and version/hash (or immutable revision reference).
• Record the review/release decision (approved/rejected, conditions).
• Record timestamp in a consistent time source.
• Record reviewer/releaser credentials (immutable user ID, not free text). ¹

If your workflow tool stores the approval separately from the artifact, build a linkage field (artifact ID in the ticket, ticket ID in the artifact metadata) and make it mandatory. ¹

Step 4: Enforce separation of duties where it matters (policy decision)

AU-10(3) does not, by itself, require separation of duties, but in practice you should define when the reviewer and releaser can be the same person and when they cannot. Put it in a procedure and make your tooling enforce it for high-risk releases.

Step 5: Centralize logging and make it retrievable for audits

Make sure you can produce the chain-of-custody trail on demand:

• Central log collection (SIEM or log archive)
• Correlation keys (artifact ID, ticket ID, document revision)
• Searchable fields for reviewer/releaser identity
• Access controls to protect the integrity of the audit trail

Assessors rarely accept “we could find it if we had time.” You need repeatable retrieval. ¹

Step 6: Operationalize with ownership, cadence, and evidence mapping

Assign a control owner and write an implementation procedure that states:

• In-scope information types and release events
• Approved systems of record for review/release
• Required fields (artifact ID/version, approver credential)
• Evidence to retain and where it lives
• Periodic self-test steps

Daydream-style execution (done well) starts by mapping AU-10(3) to a named owner, a short operating procedure, and recurring evidence artifacts that your team can produce without heroics. ¹

Required evidence and artifacts to retain

Keep evidence that proves the credentialed identity stayed in the chain of custody for the released information. Typical artifacts include:

Evidence item	What it proves for AU-10(3)	Good enough looks like
Approval/work item record (ticket/workflow)	Named reviewer/releaser credential and decision	Immutable user ID, timestamp, decision, artifact reference 1
Artifact metadata (document revision history, repository tag, release record)	Exact object/version that was reviewed or released	Revision ID/hash tied to the approval record 1
Audit logs from approval system	Credentials captured by the system of record	Authenticated identity and event log entries 1
Identity records (IdP directory export or access review output)	Credentials map to a real authorized identity	Role/entitlement evidence supporting authority to approve 1
Distribution/release logs (where applicable)	The release occurred after approval and via approved channel	Share/export event correlated to approval 1

Retention period is not specified in the provided AU-10(3) excerpt; set it based on your program requirements and document it. ¹

Common exam/audit questions and hangups

Questions you should be ready for

• “Pick a released artifact. Show the full chain of custody, including the reviewer/releaser credentials.” ¹
• “How do you know the approval relates to this exact version?” ¹
• “Where are credentials stored, and how do you prevent edits to approver identity fields?” ¹
• “If someone approves in a chat or email, how is that captured in the chain of custody?” ¹
• “Can an admin change the approval record after the fact? How would you detect it?” ¹

Hangups that stall assessments

• Approvals exist, but the approver is stored as a free-text name.
• The artifact changed after approval, and versioning is unclear.
• Logs exist, but correlation keys between systems were never designed.

Frequent implementation mistakes (and how to avoid them)

1. Relying on screenshots as the chain of custody
   Fix: treat screenshots as supporting evidence only. Your primary evidence should be system records and logs that preserve credentialed identity. ¹

2. Approvals in email with no identity binding
   Fix: require review/release through a workflow tool that authenticates users and stores immutable user identifiers. ¹

3. No version binding between approval and content
   Fix: enforce artifact IDs and revision references (hash, commit, doc revision) inside the approval record. ¹

4. Shared accounts performing releases
   Fix: prohibit shared credentials for review/release actions or treat them as a formal exception with compensating monitoring, then plan removal. ¹

5. Evidence scattered across teams
   Fix: define a single “system of record” per workflow and write down where the authoritative chain-of-custody data lives. Daydream can help by turning that into an assessor-ready evidence map with recurring collection tasks. ¹

Risk implications (why auditors care)

AU-10(3) supports non-repudiation and accountability for information release. Without preserved reviewer/releaser credentials, you may be unable to:

• attribute a release to an authorized person,
• prove approval occurred before release,
• investigate data loss or unauthorized disclosure with confidence. ¹

That gap becomes acute during incident response, litigation hold, and regulatory inquiries, because the question shifts from “do you have a policy” to “prove who approved this release.” ¹

Practical 30/60/90-day execution plan

No fixed timelines are specified in the requirement text, so treat these as operational phases, not compliance deadlines. ¹

First 30 days (baseline and control design)

• Name a control owner and write a one-page AU-10(3) procedure: scope, systems of record, mandatory fields, and evidence locations. ¹
• Inventory in-scope release workflows and classify them by risk (data releases, external publications, security communications).
• Select one workflow system per release type and document it as authoritative.
• Define the credential attributes you will retain (immutable user ID, role/entitlement reference).

Days 31–60 (implementation and evidence wiring)

• Configure approval workflows to require authenticated approvals and to capture reviewer/releaser identity from the IdP directory field, not user-entered text. ¹
• Add artifact version binding (revision ID/hash/commit) and make it required in approval steps.
• Implement log forwarding for approval events and release events; add correlation keys.
• Run a tabletop audit: pick sample releases and verify you can reconstruct chain of custody end-to-end.

Days 61–90 (operational hardening and audit readiness)

• Close manual paths (email approvals) or implement compensating controls that still preserve credentials in the chain of custody. ¹
• Add periodic self-tests: a reviewer pulls a random release and produces the evidence package.
• Formalize exceptions: define who can approve exceptions and how exception approvals themselves are recorded with credentials.
• Build an assessor packet template in Daydream (or your GRC) that links procedure, samples, and log queries to the au-10(3): chain of custody requirement. ¹

Frequently Asked Questions

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

Use the identity attributes your organization relies on to authenticate the reviewer/releaser, ideally an immutable user identifier from your IdP directory plus evidence of the associated account. The requirement is to maintain those credentials within the chain-of-custody record for reviewed or released information. ¹

Do we need cryptographic signing to meet AU-10(3)?

The provided AU-10(3) text requires maintaining reviewer/releaser credentials in the chain of custody, but it does not mandate a specific technical method such as digital signatures. If you can’t make your audit trail tamper-resistant through platform controls, signing can be a strong design choice. ¹

How do we handle approvals that happen in Slack or email?

Treat chat/email as non-authoritative and require the decision to be recorded in the approved workflow system where the approver identity is authenticated and preserved. If you must accept email in an exception case, capture the approver credential and bind it to the artifact and version in the chain-of-custody record. ¹

Are service accounts allowed to be “releasers”?

They can be, but you must still preserve the service account credential identity within the chain of custody and be able to tie that identity back to controlled authorization and ownership. Many programs restrict service accounts from approvals and reserve them for automated release actions with a preceding human approval. ¹

What is the minimum evidence an auditor will accept?

Expect to produce a chain that links a specific artifact version to an approval record containing the reviewer/releaser credential, supported by system logs that show the event. If you can’t correlate “who” to “what version,” you should treat it as a finding risk. ¹

How does this map into our GRC tooling without creating busywork?

Keep the procedure short and automate evidence collection from the workflow and identity systems you already run. Daydream is a natural fit when you want AU-10(3) mapped to a clear owner, an implementation procedure, and recurring evidence artifacts that can be produced on demand. ¹

Footnotes

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

2. NIST SP 800-53 Rev. 5