Why Your M&E Tool Needs an Audit Trail (DPDP + Donor Compliance)

Disclaimer: This article is educational and does not constitute legal advice. Consult a qualified legal professional for advice specific to your organisation.

Our DPDP Act guide and our post on consent and retention both cover what you must do at the point of data collection. This post covers what happens after — the record-keeping layer that proves, months or years later, that your data was handled correctly. That layer has a name: the audit trail.

Most organisations think of audit trails as an IT nicety — something that exists for developers debugging a system, not something a programme manager needs to think about. That's a mistake. An audit trail is one of the few pieces of infrastructure that satisfies two entirely separate compliance obligations at once: your obligations under the DPDP Act, and your obligations to the donors and funders whose money paid for the survey.

Two Masters, One Trail

It's worth being explicit about why the same log serves both purposes, because the reasoning behind each is different, even though the record they need looks nearly identical.

Master 1: DPDP — who accessed or modified personal data, and why

If a data breach occurs, or a Data Principal (a respondent) exercises their right to know what data you hold on them or requests correction, you need to be able to answer specific questions quickly: Who has accessed this respondent's record? Has it been modified since collection, and by whom? Was it shared with anyone outside the organisation? Without a logged answer, you are reconstructing this from memory — which is not credible to a Data Protection Board inquiry and is often simply impossible once the relevant staff member has left or forgotten.

An audit trail is also your best evidence in your own defence. If a Data Principal claims their data was altered improperly, a clean, tamper-evident log showing exactly who changed what and when is what separates "we have reasonable security safeguards in place" from an unsupported claim.

Master 2: Donors and funders — evidence of data integrity at grant closeout

Separately from DPDP, most institutional funders — CSR programmes, bilateral donors, foundations, government grant schemes — require evidence during grant closeout that the data underlying your reported results is trustworthy. This is not a legal requirement in the same sense as DPDP; it's a contractual one, embedded in the grant agreement and enforced by the funder's own M&E or finance team during closeout review.

A funder reviewer is typically not asking "did you comply with a privacy law" — they're asking "can I trust these numbers." If a submission's value changed between initial collection and the number that ended up in your final report, they want to know who changed it, when, and on what basis. Undocumented edits to primary data are one of the most common findings in a negative audit, and they're avoidable with the same infrastructure that satisfies DPDP.

What a Proper Audit Trail Actually Captures

A log that just says "record updated" is not an audit trail — it's a timestamp with no evidentiary value. A usable audit trail captures, at minimum, five elements for every access or change to personal or survey data:

• Timestamp — precise date and time, in a consistent timezone, of the access or change.
• User identity — which named individual (not a shared login) performed the action. Shared credentials break audit trails entirely; if three enumerators log in as "field1", you cannot attribute any single edit to a person, which defeats the purpose.
• Action type — view, create, edit, delete, export, restore.
• Before/after values — for edits specifically, what the field's value was before the change and what it became. "Income edited" tells an auditor nothing; "income changed from ₹18,000 to ₹8,000 by supervisor Priya S. on 14 June, citing enumerator data-entry error" tells them everything they need.
• Device/IP where relevant — useful for investigating suspicious patterns (e.g., a batch of edits from a device or location inconsistent with where fieldwork was happening), though less central for routine closeout review than the first four.

How This Maps to Real Product Features

In practice, "audit trail" is not one feature — it's the sum of several distinct pieces of infrastructure working together. It's worth naming them separately, because a tool that has one but not the others gives you a false sense of coverage.

Submission edit logs

Every survey response gets edited at some point — an enumerator correcting a typo, a supervisor resolving a data-quality flag, a research lead fixing a coding error after review. Each of those edits should be individually logged with the before/after value and the editor's identity, at the field level, not just "this submission was touched."

Form version history

Separately from individual submission edits, the survey instrument itself changes over the life of a study — a question gets reworded, a skip-logic rule is fixed, a new consent purpose gets added mid-fieldwork. If you can't tell which version of the form a given respondent actually answered, you can't correctly interpret their response later, and a reviewer checking data integrity has no way to confirm a mid-study question change wasn't used to quietly alter what was being measured. FieldGovern's Form Builder keeps a full version history for every form, including diffs between versions and a restore function — so you can see exactly what changed, when, and roll back to an earlier version if a change needs to be reverted. This is concrete audit-trail infrastructure, not just a nice-to-have: it's the difference between being able to answer "what did respondents actually see on 3 March" and having to guess.

Access logs

Who viewed or exported a dataset containing personal data is itself a loggable, reviewable event — relevant both to a DPDP breach investigation (was this respondent's data accessed by someone without a legitimate reason) and to a funder's data-security review (can you demonstrate that access to personal data was restricted to staff with a genuine need).

Why "We'll Reconstruct It Later" Doesn't Work

A pattern we see repeatedly with organisations that haven't formalised an audit trail: the intent is there, but the record only exists in people's memory, a WhatsApp thread, or scattered comments in a shared spreadsheet. This fails in three predictable ways once an actual review happens.

First, staff turnover. Field research runs on short-term enumerators, seasonal supervisors, and consultants brought on for a single evaluation. By the time a funder's closeout review happens — often six months to a year after fieldwork ends — the person who made a specific data correction may no longer be reachable, and nobody else can explain why a value changed.

Second, spreadsheet edits are invisible by design. Excel and Google Sheets do not, by default, keep a durable, exportable record of who changed which cell and why — version history exists but is not built for producing an audit-ready report, and it is trivial to overwrite without anyone noticing. A "final_v3_FINAL_reallyfinal.xlsx" file naming convention is itself a symptom of an organisation without a real audit trail.

Third, and most costly: without a log, every question from an auditor turns into an investigation. "Why does this respondent's income figure differ between the raw export and the final report?" should be a five-second lookup. Without a trail, it becomes hours of cross-referencing files and emailing former staff — during a review window that is usually measured in days, not weeks.

What Auditors Typically Request During a Grant Closeout Review

If you've been through a donor closeout review before, some version of this list will be familiar. If you haven't, treat it as a preparation checklist:

Notice that almost every row is satisfied by the same underlying infrastructure — a structured, append-only, user-attributed log of changes — applied to a slightly different object each time (a submission, a form, an access event, a deletion). This is why it pays to solve "audit trail" once, properly, rather than bolting on separate half-solutions per requirement as each new funder asks a slightly different question.

A Practical Checklist: Is Your Audit Trail Actually Audit-Ready?

That last point matters more than it sounds. An audit trail that exists somewhere in a database table but takes a developer half a day to extract into a readable report is not, in any practical sense, ready for a funder review that has to happen on a deadline. Build or buy for the export, not just the logging.

For the consent and retention side of this same compliance picture — what to capture at the point of collection, and how long to keep it — see our companion post on consent and data retention under DPDP. Together, the two form a reasonably complete picture of what "DPDP-and-donor-ready" actually requires operationally, beyond the high-level obligations covered in our main DPDP guide.