Audit Trails and DPDP: Metrics That Trigger Action

Ask a finance lead to show who opened a customer's ledger last quarter and the answer usually comes from memory, not a log. Under the DPDP Act, 2023, personal data sitting inside invoices, payout files and vendor records is regulated, and "we trust the team" is not a lawful basis for anything. The gap is rarely malice. It is that nobody wrote down which numbers to watch, or what number turns a curiosity into an incident.

Which audit-trail metrics should finance track each month?

Five are enough: access volume per user, after-hours activity, bulk exports, permission changes, and failed access attempts. Most teams either log everything and review nothing, or stare at a dashboard nobody trusts. A set this small can be read in half an hour by one person who knows the business.

• Access volume per user. An accounts person who normally opens 20 invoices a day and suddenly opens 400 is your cheapest early warning.
• After-hours and weekend access, particularly from devices or locations outside your usual range.
• Bulk exports of customer, vendor or payroll records, with row counts written into the log rather than guessed at later.
• Permission and role changes, reviewed as a diff against the previous week.
• Failed access attempts per account, which catch stale credentials and quiet probing alike.

What thresholds should trigger action, not a discussion?

Set the number before the incident, because a threshold invented afterwards reads like an excuse. Nothing here is universal, but the shape is always: a baseline, a multiple, and a named person who gets told.

A workable starting set for a 30-60 person company:

• More than 200 rows exported by a role that normally handles under 20 — review within one business day.
• Five failed logins on one account inside ten minutes — lock the account and tell the controller.
• Any change to who can see invoice or payout data — re-verified in the next weekly review.
• After-hours access from an unrecognised device — checked the same day, not the same month.

Take a distributor doing roughly 9,000 invoices a month with three people sharing a collections login. Suppose one month's log shows 41 bulk exports against a baseline of six, and 380 after-hours record views against a baseline of 20. Neither number proves anything. Both are conversations you want in week two rather than at the end of the quarter, and the shared login is the reason you cannot tell who to have it with.

What must an audit-trail record contain to be defensible?

Every event needs five fields: who, what, when, from where, and the before-and-after values. A line reading "invoice updated" is a rumour; a line reading "user 41 changed payment terms on INV-2291 from Net 30 to Net 90 at 21:14 IST from 10.4.2.19" is evidence.

Two implementation details decide whether the trail survives scrutiny. First, identity must be per person — shared logins collapse an audit trail into a guess, which is why the collections inbox above is a problem worth fixing on its own. Second, the log must be append-only and stored somewhere the application cannot rewrite, with timestamps in a single timezone. If an admin can edit the log, you have a diary, not an audit trail.

How does DPDP change retention and deletion of financial data?

DPDP asks you to erase personal data once its purpose is served, but tax and company law tell you to keep records — so your retention schedule has to work per data category, not per system. GST records run to 72 months from the annual return due date, company books to eight years, and transaction records under anti-money-laundering rules to five.

That means the invoice stays; the personal data inside it that is not needed for the statutory purpose does not automatically stay with it. Call recordings, KYC scans past their use, marketing consent records and candidate CVs all run on their own clocks. The awkward part: your audit log contains personal data too, so the record of who viewed a customer's data is itself subject to a retention limit. Decide that limit deliberately.

Who should own the review, and how often?

One named person — usually the finance controller, sometimes the CTO — with a 30-minute monthly review and a same-day path for the hard triggers. Diffused ownership is why these reviews quietly stop happening after the second month.

Make the output a record: who reviewed, what the numbers were, what was found, what was done. That note is the artefact you produce if a Data Protection Board query or a customer's vendor audit ever arrives, and it takes four lines to write. As volumes grow past the point where a person can eyeball exports, anomaly detection on the access log is usually the first automation worth paying for — before any dashboard.

Where to start

Pick the five metrics, write the thresholds down in a document someone else can read, and run one review by hand before buying a tool. Most companies find two or three genuine problems in the first month, nearly always shared logins and an export button nobody restricted. If invoices are generated in a system that does not record who changed what, that is the upstream fix — billing automation that writes its own audit trail is cheaper than reconstructing one after a query. Maysan Labs builds exactly this kind of thing for finance teams, and we would rather you started with the checklist.