AU-10: Non-repudiation

To meet the au-10: non-repudiation requirement, you must generate and protect audit evidence that can credibly prove a specific person (or delegated process) performed a specific action, and that the record has not been altered. In practice, this means strong identity binding, tamper-evident logging, and controlled key/signature practices for high-risk events. ¹

Key takeaways:

• Focus AU-10 on actions with legal, financial, or safety impact (admin changes, approvals, data exports), not every log event.
• Non-repudiation is a system design outcome: identity proof + event integrity + retention/verification procedures.
• Auditors look for repeatable evidence: event schemas, key management, log immutability, and verification workflows mapped to an owner.

AU-10 is easy to misunderstand because many teams treat it as “turn logging on.” Logging supports accountability, but AU-10 asks for something narrower and tougher: irrefutable evidence that a particular individual (or a process acting on their behalf) performed a particular action. That “irrefutable” bar drives design decisions about identity binding (who did it), event integrity (was the record changed), and proof (can you validate it later without hand-waving).

For a Compliance Officer, CCO, or GRC lead, operationalizing AU-10 starts with scoping. You do not need cryptographic signatures on every debug line. You do need a defensible non-repudiation pattern for the actions that matter: privileged access use, configuration changes, approval workflows, data release/export, and actions that trigger regulatory reporting or customer impact. Then you need an evidence package an assessor can follow: written procedures, technical settings, sample records, and an explanation of how the organization verifies authenticity over time.

This page gives requirement-level implementation guidance you can hand to Security Engineering, IAM, and platform owners and then collect durable audit artifacts.

Regulatory text

Requirement (AU-10): “Provide irrefutable evidence that an individual (or process acting on behalf of an individual) has performed {{ insert: param, au-10_odp }}.” ¹

What the operator must do

You must:

1. Define the set of actions/events that require non-repudiation (the organization-defined parameter in the control).
2. Design logging and authorization so those events are attributable to a unique identity (human or service principal), including delegated actions.
3. Protect the integrity of the records so you can show they were not modified (tamper-evidence/immutability controls and access restrictions).
4. Retain and be able to verify the evidence on demand, using documented procedures and repeatable queries/reports.

This is an “evidence quality” control. A pile of logs that can be edited, are missing identity context, or cannot be verified later will fail the intent even if the system is “logging.”

Plain-English interpretation (what AU-10 really means)

AU-10 requires that you can credibly answer, with durable proof:

• Who performed the action (a uniquely identified person, or a process clearly mapped to a person or approved role).
• What action occurred (clear event type, object, and outcome).
• When and where it occurred (time and system context).
• That the record is authentic (you can demonstrate it was captured by the system of record and hasn’t been altered).

Non-repudiation is usually implemented through a combination of:

• Strong authentication and authorization (identity binding),
• Centralized, access-controlled audit logging (collection),
• Tamper-evident storage (integrity),
• And documented verification steps (proof workflow).

Who it applies to (entity and operational context)

AU-10 is most relevant for:

• Federal information systems and contractor systems handling federal data operating with NIST SP 800-53 controls in scope. ¹
• GRC programs where you must prove administrative and business-critical actions for investigations, incident response, disputes, or change control.

Operationally, it applies wherever a person can take a meaningful action in:

• IAM (role grants, privilege escalation, MFA resets),
• Cloud and infrastructure (security group changes, key creation, logging disablement),
• Application administration (feature flags, pricing/entitlements, approval overrides),
• Data platforms (exports, sharing, deletion, schema changes),
• CI/CD (production deployments, pipeline bypasses).

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

Step 1: Define the AU-10 event scope (“ODP” list)

Create a short, explicit list of non-repudiation events. Keep it defensible and tied to risk. Typical categories:

• Privileged actions (admin console access, break-glass use)
• Security control changes (logging off, key rotation policy changes)
• Access governance (role grants, group membership changes)
• Data egress (bulk export, sharing outside boundary)
• High-impact business actions (approvals, payments, critical workflow sign-offs)

Artifact: AU-10 scope statement (1–2 pages) with event taxonomy and rationale. Map each event type to a system owner.

Step 2: Bind each event to a unique identity (human and service)

For each scoped event type, confirm you can capture:

• User ID (immutable unique identifier; avoid display names as primary key)
• Authentication context (SSO subject, MFA status where available)
• Session/request context (source IP, device ID where available, request ID)
• Delegation context for “process acting on behalf of an individual” (who initiated, what was delegated, what authorization allowed it)

Where service accounts act, require:

• Service principal identity
• Ownership (team), purpose, and approval record
• Where feasible, a link to the human change/approval that triggered the action (ticket ID, pipeline run ID)

Artifact: Identity-to-event mapping table (event → fields captured → authoritative system).

Step 3: Make audit records tamper-evident and access-controlled

Non-repudiation fails if admins can edit logs without trace. Implement:

• Centralized log collection to a system with strict access controls
• Separation of duties: production admins should not be able to alter audit trails without detection
• Integrity controls such as append-only/WORM-like storage patterns, immutability features, or cryptographic integrity validation where feasible
• Alerts on audit pipeline health: dropped events, collector stoppage, log source disabled

Artifact: Logging architecture diagram + access control list for the log platform (who can read, who can manage retention, who can delete).

Step 4: Establish a verification procedure (how you prove “irrefutable”)

Write a short runbook that an investigator or auditor can follow:

• How to retrieve AU-10 evidence for a specific event (query patterns, report templates)
• How to validate it is complete (cross-check with secondary sources like IdP logs or cloud control plane logs)
• How to validate integrity (immutability settings, hash verification if used, access logs showing no alteration)
• How to handle time synchronization issues (at minimum, document time sources used across systems)

Artifact: AU-10 verification runbook with screenshots or saved queries.

Step 5: Operationalize monitoring and periodic checks

Add recurring checks:

• Confirm scoped event sources are still emitting required fields
• Review privileged access to the logging platform
• Sample a few AU-10 events and walk the verification procedure end-to-end
• Track exceptions (legacy systems that cannot provide needed fields) with compensating controls and a remediation plan

Artifact: Quarterly (or your chosen cadence) AU-10 control test record with samples.

Step 6: Assign ownership and package evidence for assessment

AU-10 is often “owned by everyone,” which means owned by no one. Assign:

• Control owner (GRC or Security Assurance)
• Technical owners per system (IAM, cloud platform, SIEM/log platform)
• Evidence owners (who exports reports, who approves exceptions)

Tools like Daydream fit naturally here because AU-10 tends to sprawl across teams. Use Daydream to map AU-10 to a named control owner, an implementation procedure, and a recurring evidence set so your audit package is repeatable instead of rebuilt each assessment cycle.

Required evidence and artifacts to retain

Keep artifacts that prove both design and operation:

1. AU-10 scope definition (the ODP list of event types) ¹
2. Data dictionary / event schema for each scoped event (required identity and context fields)
3. Architecture diagram showing log sources → collectors → storage → access paths
4. Configuration evidence (screenshots/exports) showing:
   • Log sources enabled for scoped systems
   • Immutability/retention settings
   • Access control settings for log platform
5. Key management/signing design if you use signatures/hashes for integrity (documented approach and key custody)
6. Sample evidence packets for several AU-10 events (sanitized):
   • The initiating identity record (IdP/auth logs)
   • The action record (application/cloud audit event)
   • Correlation identifiers linking them (request ID, session ID, ticket ID)
7. Runbook + test results showing you can retrieve and validate authenticity

Common exam/audit questions and hangups

Expect questions like:

• “What events did you designate as requiring non-repudiation, and why?” ¹
• “Show me an example of a privileged change and prove who performed it.”
• “Who can delete or alter audit logs? Show approvals and technical restrictions.”
• “How do you handle automated processes acting on behalf of an individual?”
• “What happens if logging is disabled or the pipeline fails?”

Hangups that trigger findings:

• Logs show only shared accounts or generic “admin”
• No correlation between approval and action (especially in CI/CD)
• Audit store admins can purge/edit without independent detection
• Evidence retrieval is manual tribal knowledge, not a runbook

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails AU-10	Fix
Treating AU-10 as “SIEM exists”	SIEM presence doesn’t prove identity binding or integrity	Define AU-10 event scope and required fields; test retrieval
Shared/admin accounts for sensitive actions	You cannot attribute actions to an individual	Enforce unique admin identities and privileged access workflows
Missing “on behalf of” attribution for automation	Actions appear to be performed by a bot with no human chain	Record ticket/pipeline run/approver ID and correlate in logs
Log platform has broad admin access	An insider can tamper with records	Restrict delete permissions, separate duties, and monitor admin actions
No periodic verification	Evidence quality drifts after changes	Add recurring sampling and pipeline health checks

Enforcement context and risk implications

No public enforcement cases were provided in the supplied source catalog for this requirement, so this page does not cite specific actions tied to AU-10.

Risk implications still matter operationally: weak non-repudiation increases the chance you cannot resolve disputes (who approved, who changed, who exported), cannot support incident investigations, and cannot demonstrate control operation under assessment. For federal and federal-adjacent environments, AU-10 gaps often cascade into findings across auditing, incident response, and access control because those controls rely on trustworthy event data. ²

Practical execution plan (30/60/90)

You asked for speed. Use this plan as a checklist; adjust scope to your system boundary and assessment timeline.

First 30 days (scope + minimum viable proof)

• Name the AU-10 control owner and technical owners.
• Publish the AU-10 event scope list (ODP) and get system owner sign-off. ¹
• For top systems (IdP, cloud control plane, production app admin), confirm required identity fields are present.
• Document current log storage immutability/retention and who has delete rights.
• Produce one end-to-end evidence packet for one high-risk event.

Days 31–60 (integrity + repeatability)

• Close the biggest “who did it” gaps (shared accounts, missing SSO subject mapping).
• Tighten access to the log platform; document separation-of-duties decisions.
• Implement alerts for log stoppage and audit-source disablement.
• Write the AU-10 verification runbook and store saved queries/reports.
• Run an internal “mini-audit” using your runbook and capture results.

Days 61–90 (scale + sustain)

• Expand AU-10 coverage to remaining scoped systems and event types.
• Add correlation across systems (IdP ↔ cloud/app ↔ ticketing/CI).
• Establish the recurring evidence calendar and sampling procedure.
• Track exceptions with compensating controls and target remediation dates.
• If you use Daydream, centralize the owner assignment, procedures, and evidence requests so AU-10 stays audit-ready.

Frequently Asked Questions

Do we need digital signatures on every audit log to satisfy AU-10?

No. AU-10 requires “irrefutable evidence” for the events you define in scope, which can be met through strong identity binding plus tamper-evident storage and controlled access. Use cryptographic signing where it materially improves integrity for your highest-risk actions. ¹

What does “process acting on behalf of an individual” mean in practice?

It covers automation triggered or approved by a person, such as CI/CD deployments or scheduled jobs initiated through a change record. Your evidence should show both the service principal that executed the action and the human identity tied to the trigger or approval.

If our admins can access the SIEM, does that automatically break non-repudiation?

Not automatically, but broad delete/alter permissions without detection is a common audit failure point. Restrict destructive actions, log SIEM admin activity, and document how you detect and respond to tampering attempts.

How do we scope AU-10 without boiling the ocean?

Start with privileged actions, security control changes, and data egress, then add business-critical approvals. Write the scope down as your AU-10 ODP list and get sign-off so auditors see intentional boundaries. ¹

What evidence does an auditor usually ask for first?

They ask for one real example: “Show me who changed X and prove it.” Have a prepared evidence packet that includes the action log, the authentication record, and integrity/retention proof from the logging platform.

Can third parties be in scope for AU-10?

Yes, if third parties administer systems in your boundary or operate hosted components that generate audit trails you rely on. Contractual terms should require access logging, identity attribution, and timely access to audit evidence consistent with your AU-10 scope.

Footnotes

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

2. NIST SP 800-53 Rev. 5