AU-10: Non-repudiation

AU-10 (Non-repudiation) requires you to produce irrefutable, auditor-ready proof that a specific person, or a system process acting for them, performed defined security-relevant actions. Operationalize it by selecting in-scope actions, binding identities to those actions with strong authentication and tamper-evident logs/signatures, and retaining evidence that survives disputes. ¹

Key takeaways:

• Define the “actions” that must be non-repudiable, then map each to a system-of-record that can prove who did what and when.
• Make audit data tamper-evident: strong identity binding, protected logs, time integrity, and controlled key/signing material.
• Treat evidence as a product: consistent event schemas, retention, replayability, and a testable dispute workflow.

Non-repudiation is a very specific audit and security outcome: if someone later denies they approved a payment, changed a firewall rule, promoted code, or disabled logging, you can prove the action occurred and tie it back to an identity with defensible evidence. AU-10 asks for “irrefutable evidence” that an individual (or process acting on behalf of an individual) performed defined actions. ¹

For a Compliance Officer, CCO, or GRC lead, the fastest path is to stop treating AU-10 as a vague “logging” requirement. It is a targeted control design problem: (1) choose which actions matter, (2) decide what “irrefutable” means in your environment, (3) implement technical controls that bind identity to action and protect the record, and (4) retain an evidence bundle that an auditor can validate without reverse-engineering your stack.

This page gives requirement-level implementation guidance you can assign to Security Engineering, IAM, and platform teams, with clear evidence expectations and common audit questions. It also includes a practical execution plan and the minimum artifacts you should keep ready for audits and customer diligence.

Regulatory text

Requirement (AU-10: Non-repudiation): “Provide irrefutable evidence that an individual (or process acting on behalf of an individual) has performed [actions].” ¹

Operator interpretation: you must be able to prove, after the fact, that specific high-risk actions were performed, and that the action can be attributed to a specific authenticated identity (human or service). The evidence must be strong enough to withstand internal disputes, audits, and investigations. ²

What this means in practice

• You define the set of “actions” that require non-repudiation (don’t leave the bracketed “[actions]” ambiguous).
• You implement mechanisms that bind identity to each action (authentication strength, authorization checks, and accountable session context).
• You protect the action record against tampering (write protections, integrity checks, signing, or other tamper-evident methods).
• You retain and can produce the evidence package on request. ¹

Plain-English requirement

AU-10 means: if a person (or their automated process) does something that matters, you can prove it was them. “Prove” here is not a screenshot in a ticket. It is a chain of evidence: identity, authentication, authorization, the event record, time context, and integrity protections that make later edits detectable.

Typical “actions” that should be in scope

Start with actions that create financial, security, safety, privacy, or availability impact:

• Privileged access and admin actions (role grants, group membership changes, break-glass usage)
• Security control changes (logging disabled, retention reduced, EDR agent removed)
• Production change approvals and deployments
• Key management actions (key creation, rotation, export, signing key access)
• Data access to regulated datasets (bulk export, privileged query, customer record changes)

Your final scope should match your system boundary and risk assessment, but you must explicitly document it so auditors can test it.

Who AU-10 applies to

Entity scope

AU-10 commonly applies to:

• Federal information systems and environments mapped to NIST SP 800-53.
• Contractor systems handling federal data, including third parties supporting federal missions. ¹

Operational scope (where the control “lives”)

You need AU-10 wherever actions can be disputed:

• Identity providers (IdP), privileged access management, directory services
• CI/CD and change management systems
• Cloud control planes and key management systems
• Ticketing/approval workflows that trigger production-impacting changes
• Central logging/SIEM and log archive storage

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

Step 1: Define the AU-10 control card (owner, scope, triggers)

Write a one-page control card your teams can run:

• Objective: prove performance of in-scope actions with irrefutable evidence
• Owner: named role (e.g., Head of IAM or Security Operations)
• In-scope systems: IdP, PAM, cloud control plane, CI/CD, logging platform
• In-scope actions: enumerated list (by event type or system capability)
• Trigger events: new system onboarding, new privileged workflow, incident/investigation request, quarterly control health check
• Exceptions: emergency access workflow, legacy systems, third-party managed systems, with compensating controls and timelines

This aligns with the operational best practice of turning requirements into executable runbooks. ¹

Step 2: Map each action to an authoritative system-of-record

For each action, document:

• Where the action occurs (system)
• Where the action is recorded (log/event stream)
• How identity is captured (principal, user ID, service account, workload identity)
• How the record is protected (immutability, signatures, access controls)
• How long it is retained and where

A simple table is enough for first pass:

Action	System	Record source	Identity binding	Integrity/tamper evidence	Evidence location
Add admin role	IdP	Admin audit log	MFA + admin session	Write-once archive + restricted access	SIEM + archive bucket

Step 3: Tighten identity binding (the “who” in who-did-what)

Non-repudiation fails when identity is weak or shared. Require:

• Unique accounts (no shared admins; no shared service credentials)
• Strong authentication for privileged actions (MFA where applicable; controlled break-glass)
• Clear attribution for automation (workload identity, signed tokens, service-to-service auth)
• Session context captured in logs (source IP/device, session ID, request ID)

If you can’t tie the action to a stable identity, “irrefutable” becomes hard to defend.

Step 4: Make audit records tamper-evident and survivable

Auditors will look for whether a privileged user could alter the very evidence used to judge them. Implement:

• Centralized collection into a protected logging platform
• Restricted admin access to logs and log pipelines (separation of duties where feasible)
• Immutable or write-once storage for log archives (or equivalent tamper-evident controls)
• Time integrity controls (consistent time sync, reliable timestamps)
• Integrity validation where feasible (hashing/signing log batches; controlled signing keys)

You don’t need to over-engineer, but you do need a defensible story: “Here is how we detect or prevent log manipulation.”

Step 5: Define the minimum evidence bundle (what you will hand an auditor)

For each execution cycle (and for each incident request), define a consistent evidence bundle:

• The scoped list of non-repudiable actions (approved baseline)
• Sample events showing identity + action + timestamp + target object
• Proof of log protection (configuration snapshots, access control lists, immutability settings)
• Proof of retention (policy + storage location + retrieval test)
• Exception register (approved exceptions, compensating controls, expiry dates)

This is explicitly aligned to the recommended practice of defining a minimum evidence bundle. ¹

Step 6: Test the dispute workflow (prove you can actually produce “irrefutable” evidence)

Run a tabletop that mimics a real dispute:

• Pick an in-scope action (e.g., privileged role grant).
• Retrieve the full chain: approval (if required), authentication evidence, audit event, and archive copy.
• Verify integrity controls: show the event exists in primary logs and the immutable archive; confirm only authorized roles can access/alter pipelines.
• Document gaps and remediation tickets.

Step 7: Run recurring control health checks

Non-repudiation degrades quietly when systems change. Add a lightweight recurring check:

• Confirm log sources are still reporting for in-scope systems
• Confirm retention and immutability settings remain enabled
• Confirm privileged access to logging remains constrained
• Confirm new workflows (new CI/CD, new cloud accounts, new third party tooling) are added to scope

Track findings to closure with due dates and validated remediation evidence. ¹

Required evidence and artifacts to retain

Keep these ready in a single “AU-10 evidence” folder (GRC tool, secure repository, or Daydream control workspace):

1. AU-10 control card (owner, scope, cadence, exceptions)
2. Action-to-evidence mapping table (system, event types, retention, integrity controls)
3. Logging architecture diagram (sources → collector → SIEM → archive)
4. Configuration exports/screenshots for:
   • IdP admin audit logging enabled
   • Cloud audit logging enabled ¹
   • CI/CD audit logs enabled
   • Log archive immutability/write protections
5. Access control evidence:
   • Who can administer logging, who can delete/alter logs, and how access is approved
6. Sample log extracts (redacted as needed) showing identity binding for each key action type
7. Retention policy and retrieval test records (proof you can pull historical events)
8. Exception register and compensating controls
9. Control health check results and remediation tracking

Common exam/audit questions and hangups

Expect these questions, and prepare short, testable answers:

• “What are the ‘actions’ in scope for AU-10, and why those?” Auditors want an explicit list tied to risk.
• “Show me evidence that Alice approved/deployed/changed X.” They will pick a transaction and trace it.
• “Can an administrator tamper with the logs?” They will examine permissions and storage immutability.
• “How do you handle service accounts and automation?” They will test whether actions are attributable to a workload identity, not a shared secret.
• “What happens during emergency access?” They will check whether break-glass actions are logged and reviewed.

Hangup pattern: teams provide “we log things” statements, but cannot demonstrate retrieval, integrity controls, and identity binding for a specific action.

Frequent implementation mistakes (and how to avoid them)

1. Leaving “[actions]” undefined. Fix: publish an action inventory and link it to systems and event types.
2. Shared admin accounts or generic service accounts. Fix: unique identities, tightly controlled automation identities, and explicit ownership.
3. Logs stored where the same admins can delete them. Fix: separate duties where possible; at minimum, immutable archive and monitored deletion attempts.
4. No retention/retrieval proof. Fix: periodic retrieval test and archived sample package.
5. Relying on tickets as the evidence. Fix: tickets can support intent/approval, but AU-10 hinges on system audit records of the actual action.
6. No operational cadence. Fix: recurring control health checks with tracked remediation. ¹

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for AU-10, so you should treat this control as an audit-driven requirement that becomes critical during incidents, disputes, and investigations. ¹

Operational risk is straightforward: without non-repudiation, you may be unable to attribute security-relevant actions, which slows incident response, weakens accountability, and complicates legal and contractual disputes with third parties or internal operators.

Practical 30/60/90-day execution plan

Use phases instead of fixed-day promises; actual timing depends on system sprawl and logging maturity.

Immediate (stabilize scope and ownership)

• Assign AU-10 owner and publish the control card (scope, actions, systems, exceptions).
• Identify “top dispute actions” (privileged access changes, logging changes, key management actions) and confirm each has an audit source.
• Stand up the evidence bundle template and central retention location (where auditors can be granted read access).

Near-term (close technical gaps)

• Remediate shared identities and unclear automation attribution for in-scope actions.
• Centralize audit logs for all in-scope systems into a protected logging pipeline.
• Implement tamper-evident storage or equivalent integrity controls for log archives.
• Document access controls and review who can administer logging and archives.

Ongoing (prove operation)

• Run the first dispute workflow test and keep the results as evidence.
• Establish recurring control health checks and remediation tracking.
• Add AU-10 checks to onboarding for new systems and new third party integrations.

Where Daydream fits: Daydream is a practical place to store the AU-10 control card, maintain the action-to-evidence mapping, and standardize the evidence bundle so audits don’t become a scavenger hunt across IAM, SIEM, and cloud teams.

Frequently Asked Questions

What counts as “irrefutable evidence” for AU-10?

Evidence is “irrefutable” when you can tie an action to a unique identity and show the audit record is protected against undetected change. In practice that means strong identity binding plus tamper-evident logs you can retrieve and validate. ¹

Do tickets and approvals satisfy AU-10 by themselves?

No. Tickets help show approval intent, but AU-10 focuses on proof that the action occurred and who performed it. Keep both when approvals exist, but treat system audit logs as the primary record. ¹

How should we handle non-repudiation for automation and service accounts?

Attribute automation to a controlled workload identity with clear ownership and limited permissions, and ensure actions are logged with that identity. Avoid shared secrets that multiple engineers can use without accountability.

What if our logging admins can also delete logs?

Document the risk, then reduce it with access restrictions, immutable archives, and monitoring for log pipeline changes and deletion attempts. Auditors typically focus on whether tampering would be detectable and whether you can still produce historical records.

How do we scope the “[actions]” without boiling the ocean?

Start with privileged actions and changes to security controls, then expand to business-critical transactions where disputes are plausible. Publish the list, map each action to evidence, and iterate as systems change.

What evidence should we hand an auditor for a single sampled event?

Provide the event record showing actor, action, target, and timestamp; show the authentication context if available; show where the log is stored and how it is protected; and show that an archived, immutable copy exists for the retention period.

Footnotes

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

2. NIST SP 800-53 Rev. 5