Skip to content

Ledger entryNo. 966191

Audit Log

Also called: Audit trail · Activity log · Security audit log

Definition
An append-only record of who did what, when and from where in a system, kept for investigations and to prove accountability to customers and regulators.

Security & identity

Mode · timeline

Work it out

Replay one morning from the audit log

7 / 7

Next dayComing upEvent 7 of 7

Investigation report

The hash chain shows no gaps or edits, so the timeline holds up for the customer and its auditors.

Seven entries from an illustrative audit trail. Scrub through them to see how actor, action and target fields let an investigator rebuild a contact export, and the response to it, minute by minute.

Event 7 of 7: Next day — Investigation report (coming up). The hash chain shows no gaps or edits, so the timeline holds up for the customer and its auditors.

What is an audit log?

An audit log (or audit trail) is a chronological, append-only record of security-relevant actions in a system. Every entry answers the same questions: who acted (a person, a system user or an API key), what they did, to which resource, when, from where (IP address, device or calling service) and whether it succeeded. Entries are written as the action happens and are never edited afterwards.

On a WhatsApp messaging platform, the events worth auditing are the ones an investigator or auditor will ask about: a teammate promoted to admin under role-based access control, a system user token or API key created, a message template edited or deleted, a broadcast sent to 50,000 contacts, a contact list exported, a webhook URL changed, an opt-out rule switched off. Meta keeps its own activity history for business portfolios, but everything that happens inside your own dashboard and services needs your own log.

An audit log is not the same thing as application logging. Application logs, ideally written with structured logging, serve engineers who debug: they are high-volume, often sampled, short-lived and full of technical detail. An audit log serves accountability: it is lower-volume, complete, retained for months or years, protected against changes and readable by compliance teams. Mixing the two usually means the audit trail gets rotated away with debug noise, or that sensitive data leaks into debug logs.

Key takeaways

  • An audit log is an append-only record of who did what, to which resource, when, from where and with what result.
  • Record security-relevant actions: role changes, token and key creation, template edits, bulk sends, contact exports and webhook changes.
  • Make it tamper-evident with write-once storage or hash chaining, and keep it apart from the systems it records.
  • Application logs help engineers debug; audit logs prove accountability and must never be sampled or dropped.
  • In India, the CERT-In Directions require ICT system logs to be kept securely for a rolling 180 days.

Why does an audit log matter?

When something goes wrong (contacts exported by a departing employee, a template quietly changed to carry a scam link, a token used from an unknown IP address), the audit log is the only way to reconstruct what happened and who was responsible, and the first record incident management teams reach for. Enterprise customers ask for it in security questionnaires, ISO/IEC 27001 and SOC 2 auditors test it, and in India the CERT-In Directions require ICT system logs to be kept for 180 days and handed over on request. Without one, every investigation becomes guesswork.

Example: A Monday-morning export, reconstructed

A Kochi insurance broker sends renewal reminders from a WhatsApp platform. One Monday, an agent account is promoted to admin, creates an API key with export rights and downloads 48,210 contacts, all within 45 minutes. An alert rule on the audit log (an export over 10,000 rows by an account promoted less than an hour earlier) pages the security lead at 09:48. She revokes the key and reverts the role, and her own actions land in the log too. The next day, the hash-chained entries let the broker show its insurer partner exactly which records left, when, through which key and from which IP address, with proof that nothing in the trail was altered.

How does an audit log work?

  1. Decide which actions are auditable

    List the actions that change access, data or money: sign-ins and failed sign-ins, role and permission changes, credential creation and revocation, template and flow edits, bulk sends, exports and deletions, configuration changes.

  2. Write a complete, structured entry

    Capture actor, action, target, a UTC timestamp from an NTP-synced clock, source IP and user agent, request ID and result, plus before and after values for changes. Mask personal data and never store secrets.

  3. Make it append-only and tamper-evident

    Write to storage that refuses updates and deletes (write-once buckets, tables with UPDATE and DELETE revoked), and chain entries by hashing each one with the previous entry's hash so any edit or gap shows.

  4. Keep it apart from what it records

    Ship entries to a separate account or service that application admins cannot modify, so an attacker who compromises the app cannot erase their tracks.

  5. Retain, review and alert

    Keep entries for your regulatory and contractual period, alert on high-risk patterns such as mass exports, new admins or tokens created at odd hours, and give compliance teams read-only search.

The figures

An audit log: key facts and limits

Core fields
Actor, action, target, time, source, result
Timestamps
UTC, from an NTP-synced clock
CERT-In log retention (India)
Rolling 180 days for ICT system logs
Integrity
Append-only storage and hash-chained entries
Never store
Passwords, tokens, OTPs or full message text
Readers
Investigators, auditors and compliance teams

In code

An audit log in code

{
"id": "aud_01J9ZK4Q6V2M8T3R5X7Y9B1C3D",
"ts": "2026-10-19T04:17:02.481Z",
"actor": { "type": "user", "id": "u_118", "role": "admin", "ip": "203.0.113.24", "via": "key_7Q2" },
"action": "contacts.export",
"target": { "type": "contact_list", "id": "cl_all_customers" },
"result": "success",
"details": { "rows": 48210, "format": "csv" },
"request_id": "req_7f3a9c",
"prev_hash": "9c1e6d…b04d",
"hash": "e57a02…11f2"
}

One entry per action: actor, action, target, time, source and result. No phone numbers, tokens or message text.

Costly mistakes

Common mistakes with an audit log

  • Logging into a database admins can edit

    If the people or the app being audited can update or delete entries, the log proves nothing. Store it in a separate account with append-only permissions.

  • Recording secrets and personal data

    Tokens, OTP codes and message text in an audit log turn it into a breach target of its own. Log identifiers and hashes, and mask phone numbers.

  • Losing the actor behind API calls

    Entries that just say "system" cannot answer who. Record the system user, API key ID or service, and the person who triggered it when known.

  • Keeping it only as long as debug logs

    Rotating audit entries after 14 days with application logs breaks investigations and CERT-In's 180-day expectation. Give the audit log its own retention policy.

Best practices for an audit log

  • Log failed and denied actions too: a run of refused exports is often the first sign of misuse.
  • Use a fixed vocabulary of action names (contacts.export, role.change) so searches and alerts stay simple.
  • Show customers their own audit log in your dashboard; enterprise buyers increasingly expect it.
  • Test the log in incident drills: can you say who exported which list last Tuesday within ten minutes?

Audit Log FAQs

What is the difference between an audit log and an application log?
An audit log records who did what for accountability; an application log records what the software did for debugging. Audit entries are complete, protected and kept long; application logs are high-volume, often sampled and short-lived.
What events should an audit log capture?
Anything that changes access, data or money. That includes sign-ins and failures, role changes, token and API key creation, template edits, bulk sends, exports, deletions, webhook and configuration changes.
How long should audit logs be kept in India?
At least 180 days for ICT system logs under the CERT-In Directions. Sector regulators, customer contracts and your own investigation needs often call for longer, so set retention per log type.
How do you make an audit log tamper-proof?
Make it append-only and tamper-evident. Revoke update and delete rights, write a copy to write-once storage in a separate account, and hash-chain entries so any edit or deletion breaks the chain.

Put Audit Log to work

InfiQ is an official Meta Business Partner. Start a 7-day free trial — no card needed — and see this running on your own number.