Would your audit logs prove who did it?
Answer 17 questions on tamper evidence, storage, time, identity and separation of duties. Get an integrity and non-repudiation score, the gaps ranked by impact, and the NIST and PCI DSS controls each one maps to.
How your audit logs work today
Start from a typical setup, then set each answer to match yours. The score updates as you go.
Tamper evidence (3)Can anyone change a log without it showing?
Maps to AU-9(3), AU-10, PCI 10.3.4
Maps to AU-9(3), AU-10(2), RFC 5848
Maps to PCI 10.3.4, AU-9
Storage and retention (3)Where logs live and for how long
Maps to AU-9(1), AU-9(6), PCI 10.3.3
Maps to AU-9(2), AU-4, PCI 10.3.3
Maps to AU-11, PCI 10.5.1
Time (3)Can you prove when something happened?
Maps to AU-8, SC-45, PCI 10.6.1-10.6.3
Maps to AU-8, AU-3
Maps to AU-10, RFC 3161
Identity binding (4)Can you prove who did it?
Maps to AU-3, AU-10(1), IA-2, PCI 10.2
Maps to IA-2(1), AU-10
Maps to AU-10, AU-10(2), SI-7
Maps to AU-3, PCI 10.2.2
Separation and operations (4)Who can touch the logs, and do you notice failures?
Maps to AC-5, AU-9(4), AU-9(5)
Maps to AU-5, PCI 10.7
Maps to AU-6, AU-9, PCI 10.4.1
Maps to AU-10(3), AU-9
Integrity and non-repudiation score
An administrator, or an attacker with admin access, could alter or delete the record of what they did. Logs like these support investigations but are weak evidence that a specific person acted.
A weighted checklist built on NIST SP 800-53 and PCI DSS references. Weights are our judgement; this is not an audit opinion.
Gaps, largest first
Are log records hash-chained or sealed so a deleted or edited record is detectable?
CriticalNow: No
Target: Hash chain verified on a schedule, anchored externally (e.g. RFC 3161 time-stamp)Fix: Turn on the platform's log-file integrity validation (for example signed digest files for cloud audit trails), or hash-chain records at ingestion; verify the chain on a schedule and alert on breaks. Anchor periodic digests with an RFC 3161 time-stamp.
Controls: AU-9(3), AU-10, PCI 10.3.4 · Source: SP 800-53 Rev. 5, PCI DSS v4.0.1, RFC 3161
Are the people who administer systems separate from the people who can change or delete their logs?
CriticalNow: Same admins control both
Target: Separated, dual authorisation required to change retention or deleteFix: Give log-store administration to a small group outside the system admins, and require two people to change retention or delete.
Controls: AC-5, AU-9(4), AU-9(5) · Source: SP 800-53 Rev. 5
Are logs stored on write-once (WORM) or immutable storage?
HighNow: Soft-delete or versioning only
Target: Immutable in compliance mode / legal hold, no one can shorten retentionFix: Use object lock or immutable blob policies in compliance mode for the retention period. Governance mode protects against accidents but not a compromised admin.
Controls: AU-9(1), AU-9(6), PCI 10.3.3 · Source: SP 800-53 Rev. 5, PCI DSS v4.0.1
Does every logged action carry a unique individual identity (no shared or generic accounts)?
HighNow: Mostly individual, some shared
Target: Individual everywhere, including break-glass with per-use attributionFix: Remove shared accounts; where one must exist (break-glass), check it out per use so each use maps to a named person. Propagate the end-user identity through service calls.
Controls: AU-3, AU-10(1), IA-2, PCI 10.2 · Source: SP 800-53 Rev. 5, PCI DSS v4.0.1
Are all systems synchronised to authoritative time sources?
HighNow: Most systems, default pools
Target: All systems, designated sources, drift monitored and time settings change-controlledFix: Point every system at designated time servers that use authoritative sources, alert on drift, and restrict who can change time settings (and log it).
Controls: AU-8, SC-45, PCI 10.6.1-10.6.3 · Source: SP 800-53 Rev. 5, PCI DSS v4.0.1, SP 800-92
Are log records or batches digitally signed by the producing system?
MediumNow: Signed in transit only (TLS)
Target: Signed at source with keys in an HSM or KMSFix: TLS protects transit only. Sign at the source or collector (signed syslog, or signed digests) with keys held in a KMS or HSM that log administrators cannot export.
Controls: AU-9(3), AU-10(2), RFC 5848 · Source: SP 800-53 Rev. 5, RFC 5848
How long are audit logs retained?
MediumNow: 90 days to under 12 months
Target: Defined per log type from legal, regulatory and investigation needs, at least 12 monthsFix: Set retention per log type from your legal and regulatory needs; PCI DSS requires at least 12 months with three immediately available. Intrusions are often found months after they start.
Controls: AU-11, PCI 10.5.1 · Source: SP 800-53 Rev. 5, PCI DSS v4.0.1
Are high-value transactions (approvals, payments, contract acceptance) digitally signed by the user?
MediumNow: Re-authentication before approval
Target: User-bound digital signature (private key under the user's sole control)Fix: For actions someone may later deny, have the user sign the transaction content with a key only they control (smart card, passkey-backed signing, qualified signature), and store the signature with the record.
Controls: AU-10, AU-10(2), SI-7 · Source: SP 800-53 Rev. 5
9 more in the report.
Assessment report
Preview
AUDIT-LOG INTEGRITY AND NON-REPUDIATION ASSESSMENT Score: 36/100 (Weak) An administrator, or an attacker with admin access, could alter or delete the record of what they did. Logs like these support investigations but are weak evidence that a specific person acted. BY AREA Tamper evidence: 23% Storage and retention: 44% Time: 42% Identity binding: 44% Separation and operations: 25% GAPS, LARGEST FIRST 1. [Critical] Are log records hash-chained or sealed so a deleted or edited record is detectable? Now: No Target: Hash chain verified on a schedule, anchored externally (e.g. RFC 3161 time-stamp) Fix: Turn on the platform's log-file integrity validation (for example signed digest files for cloud audit trails), or hash-chain records at ingestion; verify the chain on a schedule and alert on breaks. Anchor periodic digests with an RFC 3161 time-stamp. Controls: AU-9(3), AU-10, PCI 10.3.4 2. [Critical] Are the people who administer systems separate from the people who can change or delete their logs? Now: Same admins control both Target: Separated, dual authorisation required to change retention or delete Fix: Give log-store administration to a small group outside the system admins, and require two people to change retention or delete. Controls: AC-5, AU-9(4), AU-9(5) 3. [High] Are logs stored on write-once (WORM) or immutable storage? Now: Soft-delete or versioning only Target: Immutable in compliance mode / legal hold, no one can shorten retention Fix: Use object lock or immutable blob policies in compliance mode for the retention period. Governance mode protects against accidents but not a compromised admin. Controls: AU-9(1), AU-9(6), PCI 10.3.3 4. [High] Does every logged action carry a unique individual identity (no shared or generic accounts)? Now: Mostly individual, some shared Target: Individual everywhere, including break-glass with per-use attribution Fix: Remove shared accounts; where one must exist (break-glass), check it out per use so each use maps to a named person. Propagate the end-user identity through service calls. Controls: AU-3, AU-10(1), IA-2, PCI 10.2 5. [High] Are all systems synchronised to authoritative time sources? Now: Most systems, default pools Target: All systems, designated sources, drift monitored and time settings change-controlled Fix: Point every system at designated time servers that use authoritative sources, alert on drift, and restrict who can change time settings (and log it). Controls: AU-8, SC-45, PCI 10.6.1-10.6.3 6. [Medium] Are log records or batches digitally signed by the producing system? Now: Signed in transit only (TLS) Target: Signed at source with keys in an HSM or KMS Fix: TLS protects transit only. Sign at the source or collector (signed syslog, or signed digests) with keys held in a KMS or HSM that log administrators cannot export. Controls: AU-9(3), AU-10(2), RFC 5848 7. [Medium] How long are audit logs retained? Now: 90 days to under 12 months Target: Defined per log type from legal, regulatory and investigation needs, at least 12 months Fix: Set retention per log type from your legal and regulatory needs; PCI DSS requires at least 12 months with three immediately available. Intrusions are often found months after they start. Controls: AU-11, PCI 10.5.1 8. [Medium] Are high-value transactions (approvals, payments, contract acceptance) digitally signed by the user? Now: Re-authentication before approval Target: User-bound digital signature (private key under the user's sole control) Fix: For actions someone may later deny, have the user sign the transaction content with a key only they control (smart card, passkey-backed signing, qualified signature), and store the signature with the record. Controls: AU-10, AU-10(2), SI-7 9. [Medium] Do you get alerted when logging stops or a source goes quiet? Now: For some critical systems Target: For all critical sources, with an owner and response time Fix: Alert on logging failures and on sources that stop sending. Disabling logging is a classic attacker step. Controls: AU-5, PCI 10.7 10. [Medium] Can you export logs as evidence with a documented chain of custody? Now: No process Target: Documented export with hashes, who exported, when, and storage Fix: Write a short evidence procedure: export, hash, record who and when, store read-only, and record each hand-over. Controls: AU-10(3), AU-9 11. [Medium] Is there change detection or file-integrity monitoring on stored logs? Now: Partial Target: Yes, alerts reviewed Fix: Monitor log stores for modification and deletion and send the alerts somewhere the log administrators cannot silence. Controls: PCI 10.3.4, AU-9 12. [Medium] Is the identity behind logged admin actions strongly authenticated? Now: MFA for some admin access Target: Phishing-resistant MFA for all admin access Fix: An identity in a log is only as strong as the login that created it. Require phishing-resistant MFA for all privileged access. Controls: IA-2(1), AU-10 13. [Medium] Do audit records capture who, what, when, where, outcome and the object affected? Now: Most fields, inconsistent across systems Target: All fields, one schema across systems Fix: Standardise one event schema: user, action, timestamp, source, success or failure, affected resource. Controls: AU-3, PCI 10.2.2 14. [Medium] Are logs reviewed, and is access to the logs themselves logged? Now: Reviewed after incidents only Target: Automated review daily; access to logs is logged and reviewed Fix: Review security events daily (automated), and log every read, export and configuration change of the log store itself. Controls: AU-6, AU-9, PCI 10.4.1 15. [Medium] Are logs copied promptly to a system separate from the one that produced them? Now: Forwarded in near real time to a central store in the same account Target: Forwarded in near real time to a separate account or tenant with separate admins Fix: Forward in near real time to a dedicated log account or tenant. An attacker who owns the host, or the production account, should not own the copy. Controls: AU-9(2), AU-4, PCI 10.3.3 16. [Medium] Do timestamps use a consistent format with time zone (ideally UTC) and enough precision? Now: Consistent but local time Target: UTC or explicit offset, ISO 8601, millisecond precision Fix: Record UTC (or an explicit offset) in ISO 8601 with at least millisecond precision so events correlate across systems. Controls: AU-8, AU-3 17. [Medium] For high-value records (approvals, signatures, payments), is a trusted time-stamp applied? Now: Server clock only Target: Trusted time-stamp authority (RFC 3161) or equivalent Fix: For records you may need to prove in a dispute, obtain an RFC 3161 time-stamp over the record hash from a time-stamp authority. Controls: AU-10, RFC 3161 ALL ANSWERS - Are log records hash-chained or sealed so a deleted or edited record is detectable? -> No - Are log records or batches digitally signed by the producing system? -> Signed in transit only (TLS) - Is there change detection or file-integrity monitoring on stored logs? -> Partial - Are logs stored on write-once (WORM) or immutable storage? -> Soft-delete or versioning only - Are logs copied promptly to a system separate from the one that produced them? -> Forwarded in near real time to a central store in the same account - How long are audit logs retained? -> 90 days to under 12 months - Are all systems synchronised to authoritative time sources? -> Most systems, default pools - Do timestamps use a consistent format with time zone (ideally UTC) and enough precision? -> Consistent but local time - For high-value records (approvals, signatures, payments), is a trusted time-stamp applied? -> Server clock only - Does every logged action carry a unique individual identity (no shared or generic accounts)? -> Mostly individual, some shared - Is the identity behind logged admin actions strongly authenticated? -> MFA for some admin access - Are high-value transactions (approvals, payments, contract acceptance) digitally signed by the user? -> Re-authentication before approval - Do audit records capture who, what, when, where, outcome and the object affected? -> Most fields, inconsistent across systems - Are the people who administer systems separate from the people who can change or delete their logs? -> Same admins control both - Do you get alerted when logging stops or a source goes quiet? -> For some critical systems - Are logs reviewed, and is access to the logs themselves logged? -> Reviewed after incidents only - Can you export logs as evidence with a documented chain of custody? -> No process Control references: NIST SP 800-53 Rev. 5 (AU, AC-5, IA, SC-45, SI-7), NIST SP 800-92, PCI DSS v4.0.1 Req. 10. Weights are PlayCISO judgement; this is not an audit opinion.
Loading…
TL;DRThe short answer
5 points
- Non-repudiation means someone cannot credibly deny an action they took. NIST SP 800-53 control AU-10 asks for irrefutable evidence that an individual or process performed a defined action.
- Logs only provide it if four things hold: records are tamper-evident, held where the actor cannot change them, stamped with trustworthy time, and tied to one authenticated person.
- The most common break is not technology but separation of duties: the same administrators run the systems and can delete their logs.
- Shared accounts break non-repudiation at the root. A log can show that something happened, but not who did it.
- For actions people later dispute (approvals, payments, contract acceptance), a user-bound digital signature is stronger than any log line.
What each question checks, and the controls behind it
For the concept itself, read What is non-repudiation?
Tamper evidence
Storage and retention
Time
Identity binding
Separation and operations
How the score works
Each question has a weight from 2 to 5: PlayCISO's judgement of how much it decides whether your logs would hold up as evidence. Separation of duties, immutable storage, tamper evidence and individual identities carry the most. Each answer earns none, part or all of its weight; the score is the total as a share of the maximum. A gap is Critical when a weight-5 item is at its weakest setting.
Control references come from NIST SP 800-53 Rev. 5 and PCI DSS v4.0.1. The weights are not NIST's or the PCI SSC's, and the result is not an audit opinion.
Frequently asked questions
What is non-repudiation in cyber security?
Non-repudiation is the assurance that someone cannot successfully deny having performed an action, such as sending a message, approving a payment or changing a configuration. It is provided by digital signatures with keys under the user's sole control, and by audit logs that are tamper-evident, time-synchronised and bound to individual identities. NIST SP 800-53 covers it in control AU-10.
What does NIST AU-10 require?
AU-10 (Non-repudiation) in NIST SP 800-53 Rev. 5 requires the system to provide irrefutable evidence that an individual, or a process acting for an individual, performed actions the organisation defines. Its enhancements cover associating identities with information, validating the binding of the producer's identity, chain of custody, and validating reviewer identity.
What is the difference between AU-9 and AU-10?
AU-9 (Protection of Audit Information) protects the logs themselves from unauthorised access, change and deletion, with options such as write-once media, separate storage, cryptographic protection and limiting access to a subset of privileged users. AU-10 is about what the evidence proves: that a specific identity performed a specific action. You need AU-9 for AU-10 to mean anything.
Is TLS enough to make logs tamper-proof?
No. TLS protects logs in transit between systems. Once stored, a record can still be edited or deleted by anyone with write access. Tamper evidence at rest needs hash chaining or signed digests, immutable (WORM) storage, and a store run by people other than the system administrators.
How long should audit logs be kept?
It depends on your legal and regulatory obligations; NIST AU-11 leaves the period to the organisation. PCI DSS v4.0.1 requirement 10.5.1 sets at least 12 months, with the most recent three months immediately available for analysis.
Why does time synchronisation matter for non-repudiation?
If clocks disagree, you cannot reliably order events across systems or show when an action happened. NIST AU-8 and SC-45 and PCI DSS 10.6 require time stamps from synchronised, authoritative sources, with time settings protected from change.
Sources
- NIST: SP 800-53 Rev. 5, Security and Privacy Controls (AU family) (Rev. 5, update 1, Dec 2020). AU-9 Protection of Audit Information (enhancements include write-once media, storage on separate systems, cryptographic protection, access by a subset of privileged users, dual authorisation, read-only access). AU-10 Non-repudiation: provide irrefutable evidence that an individual or process performed defined actions (enhancements: association of identities, validating the binding of producer identity, chain of custody, validating reviewer identity). AU-8 Time Stamps; AU-11 Audit Record Retention; AU-3 Content of Audit Records; AU-5 Response to Audit Logging Process Failures; AU-6 review; AC-5 Separation of Duties; SC-45 System Time Synchronization.
- NIST: SP 800-92, Guide to Computer Security Log Management (Sep 2006). Logs must be protected for confidentiality and integrity in storage and transit, kept for a defined retention period, and time-synchronised so events can be correlated; it recommends centralised log management infrastructure.
- NIST: SP 800-92 Rev. 1 (initial public draft), Cybersecurity Log Management Planning Guide (Oct 2023 (draft)). A draft update that reframes log management as a planning exercise in "plays"; still a draft, so the 2006 guide remains the final publication.
- PCI Security Standards Council: PCI DSS v4.0.1, Requirement 10 (Jun 2024). 10.2: log user actions and admin actions with user identity, event type, date/time, success or failure, origin and affected resource. 10.3: protect logs from unauthorised modification, back them up promptly to a central server or media that is difficult to alter, and use file-integrity monitoring or change detection on them. 10.5.1: keep audit logs at least 12 months, the most recent three months immediately available. 10.6: synchronise clocks with time-synchronisation technology and protect time settings. 10.7: detect and respond to failures of critical security control systems, including audit logging.
- ASD's ACSC, CISA, FBI, NSA and international partners: Best practices for event logging and threat detection (21 Aug 2024). A multinational baseline for event logging: an enterprise logging policy, centralised collection and correlation, secure storage and event-log integrity, timestamp consistency, and detection strategy.
- IETF: RFC 3161, Time-Stamp Protocol (TSP) (Aug 2001). A trusted time-stamp authority signs a hash of data with the time, proving the data existed at that time without revealing it; used to anchor log hash chains and signed records.
- IETF: RFC 5848, Signed Syslog Messages (May 2010). Defines signature blocks for syslog that give origin authentication, message integrity, replay resistance, message sequencing and detection of missing messages.
Educational, not legal advice. Whether a record is admissible as evidence depends on the jurisdiction and the case.
More security tools
The tools people use most on PlayCISO.
Catch injected instructions hiding in content your AI agent should only read.
Score your readiness against the first international standard for AI security threats.
Critical CVEs across 21 major vendors, month by month — and what the 2026 surge means.
Build an ordered ruleset, replay labelled packets and catch shadowed and any-to-any rules.
Self-assess all six Functions, from Govern to Recover, and see your weakest one.
Search 172 threat actors across Microsoft, CrowdStrike, Mandiant and community names.