Audit Logs and Audit Trail Checklist for AI, ERP and Internal Audit

An audit log is a time-stamped record of what happened in a system: who acted, what changed, when it happened, where it happened and, where available, which workflow or approval supported it. For internal audit, an audit trail is useful only when it can be tied back to a business process, source population, control test, exception and reviewer conclusion.

The search term sounds technical, but the audit question is simple: can the company prove that the transaction, approval, master-data change, AI output or report extract was created and reviewed in the way management says it was?

Quick audit trail checklist

Area	Internal audit test
Log coverage	Confirm which ERP, payroll, bank, SaaS, workflow and AI tools generate audit logs
User identity	Check whether logs show named users, service accounts, roles and privileged users
Transaction history	Verify creation, modification, approval, posting, reversal and deletion events
Master-data changes	Review vendor, customer, employee, GL, tax, bank and item-master changes
AI activity	Capture prompts, files, model/tool version, output, human review and override
Completeness	Reconcile log population to source transactions, user list or report extract
Integrity	Check whether logs can be edited, deleted, disabled or overwritten by admins
Retention	Confirm retention period, archival process, legal hold and backup availability
Monitoring	Check alerts, exception rules, reviewer sign-off and incident escalation
Evidence link	Tie log exceptions to RCM controls, workpapers, observations and action tracking

An audit log by itself is not evidence. It becomes audit evidence when the auditor proves the log is complete, reliable, relevant to the control being tested and retained with the workpaper conclusion.

Why audit logs matter more now

Internal audit teams increasingly rely on ERP reports, SaaS workflows, bank portals, dashboards, bots, AI assistants and automated exception rules. That creates two risks.

First, the report may be correct but unsupported. A dashboard showing duplicate payments is useful, but the file still needs the source population, rule logic, extraction date, exception list and reviewer conclusion.

Second, the system may have changed after the fact. A vendor bank account can be edited, an approval can be bypassed, a user can be deactivated, an AI tool can produce a draft answer, or a report definition can change. Without logs, the auditor sees only the final state.

NIST's log-management guidance treats log management as an enterprise process: generate, transmit, store, access, dispose and use logs for investigation, operations and compliance. NIST's 2023 draft revision also emphasises planning log improvements across the organisation, not only inside one system. That is a useful lens for internal audit because ERP, payroll, treasury, CRM and AI logs often sit in separate systems.

For AI systems, NIST's AI Risk Management Framework adds another layer: risks should be governed, mapped, measured and managed through the AI lifecycle, with ongoing monitoring and periodic review. OWASP's 2025 web risk list also keeps security logging and alerting failures as a core risk, and its GenAI guidance highlights the need to manage risks from prompts, sensitive information, supply chain, excessive agency and overreliance. All of these require usable logs.

What internal audit should log

1. ERP and finance transaction logs

For P2P, O2C, R2R, cash-bank, inventory, fixed assets and treasury reviews, internal audit should identify the logs behind:

• Transaction creation and posting
• Approval route and approver
• Edit history and reversal history
• Manual journal entry creation and approval
• Invoice, GRN, dispatch, receipt and payment status changes
• Bank account and payment file activity
• Report extraction parameters
• Period close and reopen activity

The control test should not stop at "approval exists". It should ask whether the approval existed before posting, whether the approver had authority and whether the audit trail shows later changes.

2. Master-data audit trails

Master-data changes are high-risk because they affect many transactions after a single edit. Internal audit should review:

• Vendor master creation and bank changes
• Customer credit-limit changes
• Employee master and bank-account changes
• GL code, cost centre and Schedule III mapping changes
• Item master, price list and tax-code changes
• User role and workflow-approval changes

Useful fields include old value, new value, maker, checker, timestamp, reason, ticket reference and effective date. If the system stores only the latest value, internal audit should treat that as a control-design weakness for high-risk masters.

3. AI and automation logs

AI logs need more than a generic timestamp. For an AI assistant, analytics bot or workflow agent, capture:

• User, role and business process
• Prompt or instruction, subject to privacy rules
• Uploaded file name, data class and source system
• Model, tool, agent or workflow version
• Retrieval source or knowledge base used
• Output generated
• Human review, edit, approval or rejection
• Action taken by the AI tool, if any
• Override, exception and incident history

If AI output enters a workpaper, management report, control test or external communication, the file should show who reviewed it and what source evidence supports the conclusion.

Audit log review procedures

Procedure	Evidence to retain
Map critical logs	System inventory, process-cycle map, control dependency and log owner
Test log generation	Sample transactions and confirm each action appears in the log
Test log completeness	Reconcile log count to transactions, report extracts, users or API events
Test privileged access	Admin users, service accounts, log-disable rights and emergency access
Test edit/delete protection	Configuration screenshots, vendor documentation and attempted-change evidence
Review exceptions	Failed logins, override approvals, master changes, deleted/reversed transactions
Review AI use	AI inventory, prompt/output records, model changes, human review and incidents
Check retention	Retention policy, archive evidence, backup coverage and legal-hold process
Link to RCM	RCM rows, control tests, issue rating, observation and management action

The best audit-log workpaper is not a dump of thousands of events. It is a clear conclusion: which logs were relied on, how completeness and integrity were checked, what exceptions were found, and what those exceptions mean for the control.

Tamper-evident audit trail controls

Tamper-evident does not always mean blockchain or complex cryptography. In most internal audit files, the first question is whether management can change, delete, suppress or regenerate the log without leaving a second trail.

Internal audit should check:

• Whether logs are append-only, or whether edits/deletions create a separate event
• Whether administrators can disable logging without independent approval
• Whether privileged-user activity is logged outside the same system they administer
• Whether log files are backed up or exported to protected storage
• Whether hash totals, file versions or immutable storage controls protect retained exports
• Whether monitoring alerts are reviewed by someone outside the activity owner
• Whether restored, archived or migrated logs remain readable during the audit-file retention period

For high-risk systems, ask for evidence rather than accepting a system description. Useful evidence includes configuration screenshots, vendor documentation, audit-trail setting history, SIEM/export logs, backup proof, log-retention policy and a sample of events traced from transaction to log entry.

Common audit trail red flags

• Logs can be disabled by the same admin whose actions are logged
• Deletions are not recorded
• Log exports can be overwritten without version history or hash evidence
• Master-data logs show changed values but not old values
• Service accounts post or approve transactions without owner mapping
• Report extracts do not retain parameters or extraction timestamp
• AI output is retained, but prompt, source file and human review are missing
• Workflow approvals are overwritten when a transaction is edited
• Logs are retained for less time than internal audit workpapers
• Monitoring alerts exist but have no reviewer sign-off
• Log exceptions are reviewed by IT only, with no process-owner conclusion

Where audit logs fit in internal audit

Audit logs should feed three internal-audit workflows.

First, they support source-data readiness. Before relying on analytics or sampling, the team should confirm that the source report and event log reconcile to the population being tested.

Second, they support continuous monitoring. Repeated issues such as duplicate payments, stale BRS items, high-risk journal entries, leaver access or vendor-bank changes can become recurring monitoring rules.

Third, they support observation quality. A strong observation can say not just that an exception exists, but when it happened, who performed it, what control failed, how long it remained open and whether it was repeated.

Audit logs FAQ

What is the difference between an audit log and an audit trail?

An audit log is the system-generated event record. An audit trail is the broader chain of evidence showing how a transaction, approval, change, report or AI output moved from origin to review and conclusion.

What should an audit log contain?

At minimum, an audit log should contain user identity, action, timestamp, system, object affected, old value, new value, status, source IP/device where relevant and workflow reference. For AI tools, also capture model/tool version, input, output and human review.

Are audit logs enough as audit evidence?

No. Internal audit must test whether the logs are complete, reliable, protected from tampering and relevant to the control objective. A log dump without reconciliation, exception review and conclusion is weak evidence.

How long should audit logs be retained?

Retention should align with legal, regulatory, contractual and audit-file requirements. For critical finance, payroll, treasury, compliance and AI systems, internal audit should check whether retention is long enough to support investigation, assurance and repeat-finding analysis.

How should internal audit review AI audit logs?

Start with the AI use-case inventory. For each high-risk use case, check input data, prompt or instruction, model/tool version, output, human review, override, action taken and incident history. Then tie the review back to the RCM and workpaper conclusion.

Related CORAA resources

• Internal Audit Source Data Readiness
• ITGC Internal Audit Checklist
• Internal Audit Continuous Monitoring Rules
• Internal Audit Monitoring Rules Builder
• SA 230 Audit Documentation Working Papers
• AI Vendor Due Diligence Checklist

Sources

• NIST SP 800-92, Guide to Computer Security Log Management
• NIST SP 800-92 Rev. 1 Initial Public Draft, Cybersecurity Log Management Planning Guide
• NIST AI Risk Management Framework
• NIST AI RMF Core
• OWASP Top 10:2025, A09 Security Logging and Alerting Failures
• OWASP GenAI Security Project, LLM and GenAI risks